Created attachment 793124 [details] emerge --info Here's the first/original build error: --- /var/tmp/portage/www-client/firefox-102.0.1/work/firefox-102.0.1/toolkit/components/remote/nsXRemoteServer.cpp:17:10: fatal error : 'mozilla/X11Util.h' file not found --- With `USE=-X`, I would've expected that building components like `nsXRemoteServer` would be skipped, but that's apparently not so.
A full build.log is needed to do anything here. You can compress it with xz -9 to make it smaller. But -X is possible, [ebuild R ] www-client/firefox-102.0.1:rapid::gentoo USE="clang dbus gmp-autoupdate openh264 system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-webp wayland -X -debug -eme-free -geckodriver -hardened -hwaccel -jack -libproxy -lto -pgo -pulseaudio -screencast (-selinux) -sndio -system-png (-system-python-libs) -wifi" There used to be "automagic" dependency finders for x11 libs if they were found, but those should be patched out from the ::gentoo ebuild.
Comparing our USE flags, I see the following differences: USE flag | yours | mine ---------------------------------- dbus | + | - geckodriver | - | + gmp-autoupdate | + | (-) hardened | - | + hwaccel | - | + system-png | - | + The usual suspect here is my +hardened, but I'm guessing +geckodriver may also cause havoc... I'll do some testing and revert with a build log.
Created attachment 795320 [details] XZ-compressed firefox-102.0.1 build.log Alright... so, the culprit was dbus of all things. With -X +dbus, the build completes just fine. I find that curious, given that dbus isn't actually needed, as evidenced by the other successful combination +X -dbus. (Well, I do have to set MOZ_NO_REMOTE=1 when running firefox built without dbus, but getting rid of dbus is well worth that. The build log for my desired USE flag combination -X -dbus, which fails to build (also for v103.0), is now included... I'd love to have this resolved.
So there's a requirement in the ebuild that if you enable "wayland" use flag you also must enable "dbus". It was added due to: https://bugs.gentoo.org/822237 But after compiling with -X +wayland I see this: /usr/lib64/firefox/libxul.so libmozsandbox.so,liblgpllibs.so,libmozsqlite3.so,libmozgtk.so,libmozwayland.so,libicui18n.so.71,libicuuc.so.71,libaom.so.3,libdav1d.so.6,libasound.so.2,libm.so.6,libc.so.6,ld-linux-x86-64.so.2,libffi.so.8,libplc4.so,libnspr4.so,libz.so.1,libssl3.so,libsmime3.so,libnss3.so,libnssutil3.so,libfreetype.so.6,libfontconfig.so.1,libgtk-3.so.0,libgdk-3.so.0,libpango-1.0.so.0,libharfbuzz.so.0,libatk-1.0.so.0,libcairo-gobject.so.2,libcairo.so.2,libgdk_pixbuf-2.0.so.0,libgio-2.0.so.0,libgobject-2.0.so.0,libglib-2.0.so.0,libgraphite2.so.3,libwebpdemux.so.2,libwebp.so.7,libevent-2.1.so.7,libvpx.so.7,libpixman-1.so.0,libdbus-glib-1.so.2,libdbus-1.so.3,libstdc++.so.6,libgcc_s.so.1 so at least from this, the dbus requirement seems pretty necessary. Maybe it worked in >102 before "-X" option became available? Your build fails to fatal error: [0m[1m'gdk/gdkx.h' file not found[0m[m[m which _should_ be patched in our builds (and by upstream for 103), but maybe the "-dbus" flag is trying to enable conditions for building with +X... To conclude: whatever you're trying to do is unsupported unfortunately, and you have to take this to upstream to be fixed. Not much I can do here.
I wonder if Joe in that bug was using MOZ_NO_REMOTE or not.
Interesting... I thought the relevant bug report, and the culprit behind the `wayland? (dbus)` stanza, was this one: https://bugs.gentoo.org/762035 Personally, I would've much preferred the alternative of providing a warning message, and I've been removing that line in my local overlay, and without that line, building with +X -dbus **still** works **all** versions upto and including the current 103.0 (in other words, `dbus` is NOT a hard requirement). My guess is that the reason my uploaded `build.log` shows a **different** error than what I reported is that I had rebuilt `gtk+` with -X to see if that made any difference. Apparently, it did, but it didn't help. On a closer inspection, the error location in https://bugs.gentoo.org/762035#c5 seems quite relevant to the original error I reported. It's in the same file, and seems to align with the guess that disabling `dbus` may just enable an X-based alternative. I'll probably figure out a patch when I get some time. If that's of general interest, let me know and I'll share.
(In reply to Another Mortal from comment #6) > I'll probably figure out a patch when I get some time. > If that's of general interest, let me know and I'll share. Could you upstream that? In general I'm kind of fed up carrying our custom patches around since after some releases I have to manually update them because not everything has been accepted by upstream. If you can get it upstreamed (most likely to versions 105+ at this point) I'm willing to include the patch until the release where it's included is out. Or, well, I guess it's about the complexity of that patch in the end. Please include an upstream bug link if you approach them!
I *think* I've hit this bug once in a chroot, when cross compiling for arm/arm64 and therefore without a proper set of Xorg libs for the host. I'll bookmark it and come back with logs if I hit it again.
> Please include an upstream bug link if you approach them! Sure, albeit that's a sizeable IF. > Summary: =www-client/firefox-102.0.1 fails to build without X (USE=-X) → www-client/firefox:rapid always requires dbus with wayland I for one do not particularly appreciate trying to reinforce a decision appareanty made for convenience over choice in the summary of my bug report; especially because that's NOT the bug I reported. As I had reported, and you can simply test yourself, www-client/firefox builds and works fine *without* dbus under Wayland (not XWayland) with a few caveats (at least, for now): * the _unnecessary_ "wayland? ( dbus )" line in the ebuild needs to be removed (best done in a local overlay) * the +X USE flag needs to be enabled for Firefox * the resulting binary needs to be started with either --no-remote or MOZ_NO_REMOTE=1 in env...
(In reply to Another Mortal from comment #9) > > As I had reported, and you can simply test yourself, > www-client/firefox builds and works fine *without* dbus > under Wayland (not XWayland) with a few caveats > (at least, for now): > * the _unnecessary_ "wayland? ( dbus )" line in the ebuild > needs to be removed (best done in a local overlay) > * the +X USE flag needs to be enabled for Firefox > * the resulting binary needs to be started with > either --no-remote or MOZ_NO_REMOTE=1 in env... Thanks for explaining, this much should be fixable already in the ebuild. We can switch the REQUIRED_USE to have !X? for now (to detect -X) and modify our wrapper script to include MOZ_NO_REMOTE=1. Although I got to test this all first, which I can do next week.
Created attachment 796153 [details, diff] firefox-wayland-no-remote.patch Here's a relatively simple patch that "works for me". The patch essentially DISABLES remote functionality on Wayland when Firefox is built without DBus. The end result is similar to building with DBus, but not actually running a DBus daemon/service, EXCEPT that this now works WITHOUT the need for either `--no-remote` or `MOZ_NO_REMOTE=1`, which is arguably simpler... I also included TODO notes for using an eventual pure Wayland implementation. Unfortunately, writing the relevant code is beyond my current time budget and personal interest. Feel free to remove those notes, if you take on this patch. The patch was generated on 102.0.1, but seems to also apply cleanly aganst 103.0, which is what I'm currently using (with the enclosed patch applied by `eapply_user`). Naturally, I had to remove the `wayland? ( dbus )` line in the ebuild for the build to proceed.
It allows building -dbus +wayland, but I missed the opportunity and can't do runtime testing with -X. I can carry the patch around as long as it works, so when it breaks we're back at REQUIRED_USE _unless_ you upstream it. Which I encourage you to try at least!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6b527e4251e01cec1919c9de84f7961d4b6f38a6 commit 6b527e4251e01cec1919c9de84f7961d4b6f38a6 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-08-01 11:02:42 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-08-01 11:03:01 +0000 www-client/firefox: add 103.0.1 Closes: https://bugs.gentoo.org/860033 Signed-off-by: Joonas Niilola <juippis@gentoo.org> www-client/firefox/Manifest | 99 +++ www-client/firefox/firefox-103.0.1.ebuild | 1286 +++++++++++++++++++++++++++++ 2 files changed, 1385 insertions(+)
> It allows building -dbus +wayland, but I missed the opportunity and can't do runtime testing with -X. That's OK. I'm running with -X -dbus +wayland and it works. > _unless_ you upstream it. Which I encourage you to try at least! https://phabricator.services.mozilla.com/D153890
Created attachment 799475 [details, diff] Disable `remote` with +wayland -X -dbus Here's a much cleaner patch following the "correct" and definitely simpler approach suggested in review. BTW, it's still unclear if the patch will be accepted.
(In reply to Another Mortal from comment #15) > Created attachment 799475 [details, diff] [details, diff] > Disable `remote` with +wayland -X -dbus > > Here's a much cleaner patch following the "correct" > and definitely simpler approach suggested in review. > > BTW, it's still unclear if the patch will be accepted. Thanks! As said, I'll keep the patch until it breaks. I'm not too keen in trying to fix it on my own :P Looks like this patch and the recent incident (bmo#1782147) spawned some important discussion about dbus's optionality in the future. Unfortunately for us though, they want to make it mandatory.
