ungoogled-chromium-bin/ungoogled-chromium-bin-84.0.4147.89_p1: neither the suid nor the convert-dict use flags work about gentoo-overlay

[PF4Public]

Which use flags are you installing it with?

Oh right, I've forgot to include this file.

Wrt suid — it might have been mistakenly included into -bin ebuild as I don't build suid support actually.

Please test, if this issue is fixed with the latest commit.

[tsjk]

I tried with "convert-dict -core2 -generic haswell suid widevine".
I didn't know that suid was only needed when there is no namespace support. Otherwise I would have thought that sandboxing was a bit important.

I see that you have removed suid from IUSE, and updated the update-dicts path. But there is still a reference to suid, which might make portage complain.

    152         if use suid; then
    153                 newexe chrome_sandbox ./usr/lib64/chromium-browser/chrome-sandbox
    154                 fperms 4755 "${CHROMIUM_HOME}/chrome-sandbox"
    155         fi

And I'd guess you don't need pkg_setup() either then.

[PF4Public]

sandboxing was a bit important

And it indeed is important. As far as I understand, without CONFIG_USER_NS chromium needs a suid for a sandbox to function, therefore this option exists in main ebuild. I believe this option is anyway enabled by most, so binary releases are compiled without suid support. All-in-all, there should be a sandbox one or the other way around.

I see that you have removed suid from IUSE, and updated the update-dicts path. But there is still a reference to suid, which might make portage complain.

    152         if use suid; then
    153                 newexe chrome_sandbox ./usr/lib64/chromium-browser/chrome-sandbox
    154                 fperms 4755 "${CHROMIUM_HOME}/chrome-sandbox"
    155         fi

And I'd guess you don't need pkg_setup() either then.

You're absolutely right, I should've had this done more carefully.

[tsjk]

Yeah, I mean that I would have thought that suid was a bit important. :)
The issue here is then solved.

There is however another one, which I just mention in passing, as it's a bit complicated to solve in an easy and good-for-all way. It has to do with dependencies. I think that, in order for this binary to work well, the system the package is installed to somehow (bundled or forced by ebuild) needs to have the same versions of required libs that you had when you compiled the package. When I installed the package portage warned me of some referred libs not being on my system.

[PF4Public]

needs to have the same versions of required libs that you had when you compiled the package

#39 might be related

[PF4Public]

I have established testing. Although this won't outright prevent such issues from happening, I do hope being able to catch them early on.

BTW one issue with haswell USE flag is already apparent :)