Starting from version 101 firefox supports building without X11 support and dependencies with wayland only. I'd like that to be implemented in the ebuild. Reproducible: Always
FWIW, the Firefox maintainers in Gentoo are aware: https://gitweb.gentoo.org/repo/gentoo.git/commit/www-client/firefox?id=520a4ac06b9830c368ca333165072af7c970e1d8 From 520a4ac06b9830c368ca333165072af7c970e1d8 Mon Sep 17 00:00:00 2001 From: Joonas Niilola <juippis@gentoo.org> Date: Tue, 31 May 2022 21:12:24 +0300 Subject: www-client/firefox: add 101.0 - bump EAPI to 8, - rebase a lot of our patches in patchset, - wayland-only build looks _possible_ in this release, but libwebrtc still depends on X11 so more work is required to reach that full-wayland goal, as webrtc seems more important when serving majority of the users. There's supposed to be a way to --disable-webrtc (not quite so simple though) so a _concept_ ebuild may be pushed later as package.masked. Signed-off-by: Joonas Niilola <juippis@gentoo.org> ---
As you can see from the bug you linked, these are the problematic parts: Bug 1661450 - 1/2 Make webrtc depend on MOZ_X11 Bug 1661450 - 2/2 Make webrtc depend on MOZ_X11 I understand it so they had to back off from some patches. Even if I apply https://bug1661450.bmoattachments.org/attachment.cgi?id=9270621 I can't get pure wayland to build. So help me find patches that are _upstreamed_ and make pure wayland build possible. As I don't use wayland I'm not going to spend huge amounts of time achieving this.
I've submitted the patches for mozilla Bug 1661450. The build should work with webrtc enabled, @Joonas the patches are already accepted and applied to 101, you shouldn't have to apply them again. But it is definitely not tested as much as it should be. At time of submission everything worked on pure wayland including webrtc, but now I get build errors related to GdkPixbuf introduced by https://phabricator.services.mozilla.com/D141775, reverting D141775 effectively makes the build successful, but I did not figure out how to properly fix it yet (and don't understand why it only fails on wayland builds). There are other issues with lto and pgo use flags: * lto basically strips gtk from libxul because of widget/gtk/mozgtk/mozgtk.c becoming empty when MOZ_X11 is undefined. I proposed a temporary workaround by adding a random gtk function to mozgtk.c, but mozilla maintainers' rejected it (potentially introducing regression) and said that mozgtk should go away anyway in upcoming releases. * for pgo, firstly it requires lto. And secondly the ebuild currently runs a nested X using virtualx eclass. Support for wayland should be added. I've successfully tested it with a headless sway (basically start sway with XDG_RUNTIME_DIR and SWAYSOCK in $T temp directory), but I am far from having a drop-in replacement virtualwayland eclass equivalent to virtualx. Regarding disabling webrtc I've done it with mozconfig_add_options_ac '' --disable-webrtc in the ebuild. I've tested it for firefox without any issues, and also for thunderbird 91 (backporting the wayland patches to thunderbird and why does an email client require webrtc?)
(In reply to Michel Ganguin from comment #3) > Thanks for the very thorough input! > > At time of submission everything worked on pure wayland including webrtc, > but now I get build errors related to GdkPixbuf introduced by > https://phabricator.services.mozilla.com/D141775, reverting D141775 > effectively makes the build successful, but I did not figure out how to > properly fix it yet (and don't understand why it only fails on wayland > builds). I also haven't been able to get it to build with cairo-gtk3-wayland-only. There seems to be some automagic detection logic with cairo-gtk3-wayland, where it seems you can build it without x11 libs, but if you have x11 libs installed they get linked. > > There are other issues with lto and pgo use flags: > > * lto basically strips gtk from libxul because of widget/gtk/mozgtk/mozgtk.c > becoming empty when MOZ_X11 is undefined. I proposed a temporary workaround > by adding a random gtk function to mozgtk.c, but mozilla maintainers' > rejected it (potentially introducing regression) and said that mozgtk should > go away anyway in upcoming releases. > > * for pgo, firstly it requires lto. And secondly the ebuild currently runs a > nested X using virtualx eclass. Support for wayland should be added. I've > successfully tested it with a headless sway (basically start sway with > XDG_RUNTIME_DIR and SWAYSOCK in $T temp directory), but I am far from having > a drop-in replacement virtualwayland eclass equivalent to virtualx. Yeah, pgo wasn't a priority yet since it requires updating virtualx.eclass. I did start to think about it this already (we can see from fedora's spec how they run wayland-pgo-server), but ambasta offered to maintain their virtualwl.eclass in ::gentoo. https://github.com/ambasta/ambasta/blob/main/eclass/virtualwl.eclass Although I should and am planning on writing a new mozilla-100.eclass to serve packages based on firefox's ebuild (firefox, thunderbird, spidermonkey, seamonkey) and maybe all of the required bits to get X/wayland pgo build should be written there. That lto bug is good to know, though, since I haven't been able to get as far as to test lto yet :) > > Regarding disabling webrtc I've done it with > > mozconfig_add_options_ac '' --disable-webrtc > > in the ebuild. I've tested it for firefox without any issues, and also for > thunderbird 91 (backporting the wayland patches to thunderbird and why does > an email client require webrtc?) I couldn't disable webrtc with that flag. Check your build.log, search for MOZ_WEBRTC or ENABLE_WEBRTC - it always seems to get enabled regardless of that option. Then you can clearly see code being built by searching "webrtc". People without x11 libs should be able to build wayland-only firefox by using https://github.com/ambasta/ambasta or I'll attach the ebuild I've been working on for anyone to modify locally. I'm going to revert the linked patch next!
> I also haven't been able to get it to build with cairo-gtk3-wayland-only. There seems to be some automagic detection logic with cairo-gtk3-wayland, where it seems you can build it without x11 libs, but if you have x11 libs installed they get linked. Yes, cairo-gtk3-wayland does automagic x11 detection. And cairo-gtk3-wayland-only should avoid automagic, however, I mainly tested it for mozilla internal webrtc build scripts (using mozilla's sysroot dependencies, not even involved when you build firefox). What should be working is building firefox with mesa[-X] and no x11 libs in the system (global use -X with ::gentoo by only modifying firefox's ebuild). I am not very surprised that there are other automagic anomalies. > I couldn't disable webrtc with that flag. Check your build.log, search for MOZ_WEBRTC or ENABLE_WEBRTC - it always seems to get enabled regardless of that option. Then you can clearly see code being built by searching "webrtc". Never looked at that, what I can confirm is that with a system without the webrtc patches, the build fails when x11 is missing. But by disabling webrtc, it builds fine. In this case webrtc really gets disabled. But again there is probably some automagic here too when x11 libs (or mesa[X]) are in the system. Thanks for the feedback, I will make tests based on that. I introduced cairo-gtk3-wayland-only because of the automagic problem, but didn't realize the issue was bigger.
Created attachment 782807 [details, diff] fix build cairo-gtk3-wayland-only with mesa[X] this patch fixes building firefox with --enable-default-toolkit=cairo-gtk3-wayland-only when system mesa is build with X use flag (and x11 libs are present in the system). There should not be any automagic X11 detection. there are 4 possible gtk3 toolkits: * cairo-gtk3: mandatory X11, no wayland * cairo-gtk3-wayland: autodetect X11, mandatory wayland * cairo-gtk3-wayland-only: no X11, mandatory wayland * cairo-gtk3-x11-wayland: mandatory X11, autodetect wayland
Created attachment 782810 [details, diff] workaround linking black magic of mozgtk When building firefox without X11, mozgtk becomes empty and is stripped away by the linker (--as-needed). But mozgtk is still required to load gtk3 libraries before mozwayland get loaded (see comments in toolkit/library/moz.build). As mozgtk is mostly empty (just one remaining function related to X11, historically it was a shim allowing loading both gtk2 and gtk3 which would otherwise not be possible). Mozilla developers expect to remove in the future. But until then, a workaround is required. widget/gtk/nsWindow.cpp:5310 makes a dumb call to mozgtk such that the linker does not strip it away. The chosen dumb gtk function is gtk_get_debug_flags because it is not used in firefox and it has a simple function signature (guint gtk_get_debug_flags(void)). Note that it overrides the original gtk function, therefore the functions cannot be randomly chosen and must not be used within the codebase.
I attached 2 patches * the first one should fix the build with mesa[X], I will make a merge request to mozilla. (mesa[-X] should work without this patch) * the second allows firefox to run (without it it segfaults on startup). I tried different combinations of use flags (clang/lto/pgo), but none is working. Firefox only starts if you run ./mach run in the source tree. I will try to submit it to mozilla, too. Let me know if it fixes your builds.
Created attachment 782834 [details, diff] add use "X" to firefox ebuild Applied Michel's patches and successfully build firefox on a wayland only Gentoo install. Works like a charm. Epic work Michel! Here is my firefox ebuild patch.
Thanks Michel for your work on this! Indeed I got it to build now. As I don't run any wayland compositor, I can't test runtime, but looks promising. One question for anyone with wayland-only currently running: I get: 0:05.62 DEBUG: Executing: `/usr/bin/x86_64-pc-linux-gnu-pkg-config --shared --cflags 'gtk+-wayland-3.0 >= 3.14 xkbcommon >= 0.4.1 libdrm >= 2.4'` 0:05.62 DEBUG: The command returned non-zero exit status 1. 0:05.62 DEBUG: Its output was: 0:05.62 DEBUG: | 0:05.62 DEBUG: Its error output was: 0:05.62 DEBUG: | Package gl was not found in the pkg-config search path. 0:05.62 DEBUG: | Perhaps you should add the directory containing `gl.pc' 0:05.62 DEBUG: | to the PKG_CONFIG_PATH environment variable 0:05.62 DEBUG: | Package 'gl', required by 'epoxy', not found 0:05.62 ERROR: Command `/usr/bin/x86_64-pc-linux-gnu-pkg-config --shared --cflags 'gtk+-wayland-3.0 >= 3.14 xkbcommon >= 0.4.1 libdrm >= 2.4'` failed with exit status 1. *** Fix above errors and then restart with "./mach build" * ERROR: www-client/firefox-101.0-r1::gentoo failed (configure phase): * (no error message) so can you tell me what provides gl.pc for you? equery b /usr/lib64/pkgconfig/gl.pc if I symlink egl.pc to gl.pc it works, but I'm not super comfortable about this solution. media-libs/libglvnd[X] pulls it, along with dozens of x11 libs... maybe media-libs/libglvnd[-X] should have logic so egl.pc gets symlinked as gl.pc?
^ or alternatively, can you paste the result for these two commands: emerge -pv --nodeps libepoxy cat /usr/lib64/pkgconfig/epoxy.pc
(In reply to Joonas Niilola from comment #11) > ^ or alternatively, can you paste the result for these two commands: > emerge -pv --nodeps libepoxy > cat /usr/lib64/pkgconfig/epoxy.pc Yes I have media-libs/libglvnd built with "X" use flag. I am also not comfortable with it bug since 1. x11-libs/libxkbcommon pulls x11-misc/compose-tables which also pulls most of those x11 libs, 2. dev-qt/qtgui also force media-libs/libglvnd[X], I guess it is unavoidable. > maybe media-libs/libglvnd[-X] should have logic so egl.pc gets symlinked as gl.pc? It would be great if this could be a proper solution.
> I am also not comfortable with it bug since s/bug/but/
(In reply to Joonas Niilola from comment #11) > ^ or alternatively, can you paste the result for these two commands: > emerge -pv --nodeps libepoxy > cat /usr/lib64/pkgconfig/epoxy.pc Oh, I reinstalled dev-qt/qtgui[gles2-only] and media-libs/libglvnd[-X] and the built and ran wayland only firefox successfully. Maybe the check for gl.pc came from other packages?
Never seen the gl.pc issue (I don't have /usr/lib64/pkgconfig/gl.pc). I modified few ebuilds to add an X useflag: * virtual/opengl/opengl-7.0-r2.ebuild * x11-misc/xdg-utils/xdg-utils-1.1.3_p20200220-r5.ebuild * media-gfx/inkscape/inkscape-1.1.2-r1.ebuild * media-gfx/gimp/gimp-2.99.10-r1.ebuild * dev-qt/qtwebengine/qtwebengine-5.15.3_p20220406.ebuild (Bug 774717) And yes, compose-tables pulls in a bunch of x11 dependencies, but they are build time dependencies. So I'm building it as a binpkg and thus don't pull build time deps. FTR I submitted the patches to mozilla: * https://bugzilla.mozilla.org/show_bug.cgi?id=1772719 * https://bugzilla.mozilla.org/show_bug.cgi?id=1772721
(In reply to stshine from comment #14) > (In reply to Joonas Niilola from comment #11) > > ^ or alternatively, can you paste the result for these two commands: > > emerge -pv --nodeps libepoxy > > cat /usr/lib64/pkgconfig/epoxy.pc > > Oh, I reinstalled dev-qt/qtgui[gles2-only] and media-libs/libglvnd[-X] and > the built and ran wayland only firefox successfully. Maybe the check for > gl.pc came from other packages? It does come from libepoxy, as it says: 0:05.62 DEBUG: | Package 'gl', required by 'epoxy', not found so I do agree it may be on my environment. However if I'm hit by it, then someone else will be hit by it too. Thanks again Michel :) I'm currently running on 9/12 test builds with the updated ebuild, and it looks promising. I'm going to push it first as package.masked, trying to figure out the gl issue. I believe the libepoxy package is broken. It _could_ also somehow be multi-lib related, as my test system is multi-lib. PGO will be disabled with wayland for now, but this is definitely a great start for us!
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ba0e63579dd2cfc90112d305971590a3bbb3bfe0 commit ba0e63579dd2cfc90112d305971590a3bbb3bfe0 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-06-05 13:34:52 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-06-05 13:34:52 +0000 profiles: mask experimental www-client/firefox-101.0-r10 Bug: https://bugs.gentoo.org/848858 Signed-off-by: Joonas Niilola <juippis@gentoo.org> profiles/package.mask | 6 ++++++ 1 file changed, 6 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1d0fae1958a7d239ab8d4877567074c026b92145 commit 1d0fae1958a7d239ab8d4877567074c026b92145 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-06-05 13:31:34 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-06-05 13:34:41 +0000 www-client/firefox: introduce 'X' use flag - which allows wayland-only build. Huge thanks to Michel Ganguin in bgo#848858 for providing patches, and working with upstream in prior to have wayland-only build possible. PGO is still X-only, as it requires an update to virtualx.eclass first. - will be package.mask'd for further testing. Bug: https://bugs.gentoo.org/848858 Signed-off-by: Joonas Niilola <juippis@gentoo.org> www-client/firefox/Manifest | 1 + www-client/firefox/firefox-101.0-r10.ebuild | 1282 +++++++++++++++++++++++++++ 2 files changed, 1283 insertions(+)
So looks like with "-lto -X +wayland" I can start the browser but it's just a black windows since I'm not running a wayland compositor. With "+lto -X +wayland" it instatly segfaults. So while it may build, I'm not super confident it runs? Someone else needs to test that. As said, pgo is still unavailable with wayland.
I built firefox in official repository with "+lto -X +wayland" and run without problems.
firefox[-X] works well on sway 1.7
FTR patches at mozilla: * https://bugzilla.mozilla.org/show_bug.cgi?id=1772719 => accepted * https://bugzilla.mozilla.org/show_bug.cgi?id=1772721 => should be accepted soon (reviews are positive), but different from my original patch PGO also works in my testing with headless sway, so it should work when virtualwl gets merged.
https://bugzilla.mozilla.org/show_bug.cgi?id=1772513 should also be backported IMO.
(In reply to stshine from comment #22) > https://bugzilla.mozilla.org/show_bug.cgi?id=1772513 should also be > backported IMO. Sure, will see how they apply after the previous ones are merged. Gonna update all-at-once then.
Nevermind, let's apply them to 101.0.1.
Some of the ^ patches break compiling with gcc+bfd: 20:17.04 /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: /var/tmp/ portage/www-client/firefox-101.0.1-r10/work/firefox_build/toolkit/library/build/../../../widget/gtk/ nsWindow.o: in function `nsWindow::nsWindow()': 20:17.04 nsWindow.cpp:(.text._ZN8nsWindowC2Ev+0x2c0): undefined reference to `mozgtk_linker_holder' 20:18.01 /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: libxul.so: hidden symbol `mozgtk_linker_holder' isn't defined 20:18.01 /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld.bfd: final link failed: bad value 20:18.09 collect2: error: ld returned 1 exit status clang+lld works. Since this will, too, be package.masked I wonder if I should just push it up for test...
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b542319a39dcf9489eb75dae6d5b48049d56d6fd commit b542319a39dcf9489eb75dae6d5b48049d56d6fd Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-06-09 16:47:16 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-06-09 17:00:10 +0000 profiles: keep the new wayland-only firefox-101.0.1-r10 masked Bug: https://bugs.gentoo.org/848858 Signed-off-by: Joonas Niilola <juippis@gentoo.org> profiles/package.mask | 1 + 1 file changed, 1 insertion(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1c8562a5ea506ad21c44329625f43d510d8e823e commit 1c8562a5ea506ad21c44329625f43d510d8e823e Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-06-09 16:45:39 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-06-09 17:00:10 +0000 www-client/firefox: add the "wayland-only" version for 101.0.1 - gcc+bfd is currently broken (ie "-clang" use flag), clang+lld works. See bug #848858. Will get fixed as this masked version is worked on. Bug: https://bugs.gentoo.org/848858 Signed-off-by: Joonas Niilola <juippis@gentoo.org> www-client/firefox/Manifest | 1 + www-client/firefox/firefox-101.0.1-r10.ebuild | 1292 +++++++++++++++++++++++++ 2 files changed, 1293 insertions(+)
So, is GCC build going to be fixed?
(In reply to Sorrow from comment #27) > So, is GCC build going to be fixed? https://bugzilla.mozilla.org/show_bug.cgi?id=1772721 from what I read this (unfinished) patch seems more important :\
Hello waylanders, please try the firefox in that linked PR. Seems to compile for me with and mozgtk seems to be linking properly, even with gcc. But I can't do runtime testing... but the build reports look promising. If that works I guess we're ready to unmask it and release it to the wild. PGO is only available when using +X. Enabling wayland+pgo is the next step once this is finished.
care to explain a bit what you changed to make it compile with bfd+gcc?
I just dropped the problematic patch... I think. And applied the one which hasn't been merged into upstream yet. The one attached in here too. So for me, libxul links to libmozgtk and libmozgtk links to libgtk & libgdk. It seems to be working as it should, but maybe I got lucky... both clang and gcc works for me.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9b4128afe15b72e9a75fabd674e7576f2d4cba49 commit 9b4128afe15b72e9a75fabd674e7576f2d4cba49 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-06-17 19:26:47 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-06-19 08:34:23 +0000 profiles: release wayland-only firefox Bug: https://bugs.gentoo.org/848858 Signed-off-by: Joonas Niilola <juippis@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/25942 profiles/package.mask | 7 ------- 1 file changed, 7 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=55dab4ff34008b06adc25b088d8abfc5c199606a commit 55dab4ff34008b06adc25b088d8abfc5c199606a Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-06-17 19:25:30 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-06-19 08:34:23 +0000 www-client/firefox: update wayland and vaapi patches - prepare wayland-only ebuild to be unmasked. Bug: https://bugs.gentoo.org/852299 Bug: https://bugs.gentoo.org/848858 Signed-off-by: Joonas Niilola <juippis@gentoo.org> www-client/firefox/Manifest | 1 + www-client/firefox/firefox-101.0.1-r11.ebuild | 1293 +++++++++++++++++++++++++ 2 files changed, 1294 insertions(+)
Applied this suggestion, https://bugzilla.mozilla.org/show_bug.cgi?id=1772721#c13 Ran ~20 tests through the night and all compiled. Let's try it out. Again, wayland+pgo will be the next task but can take some time.
i have a much simpler virtualwl.eclass in my overlay: https://cgit.alxu.ca/gentoo-overlay.git/tree/eclass/virtualwl.eclass, along with firefox patches. apart from being excessively complex, ambasta's virtualwl is wrong: unlike Xvfb, sway determines its own display number; WAYLAND_DISPLAY is the outer display to nest in, not the inner display. it only happens to work here because WLR_BACKENDS=headless is also set, so WAYLAND_DISPLAY is ignored. there are also various other minor issues, such as that sandbox does not need to be disabled, einfo "Starting sway on \$WAYLAND_DISPLAY=${WAYLAND_DISPLAY} ..." is in the totally wrong place (sway is already started here), there is a wrong colon in ":${SWAY}", and some others.
Thanks for the tip, definitely helps to see a working implementation already. I was thinking of building something on top of this: https://src.fedoraproject.org/rpms/firefox/blob/rawhide/f/run-wayland-compositor but I need to setup a vm to test etc since I'm not running a wayland session on a computer capable of building firefox.
the fedora one is wrong in a similar way: if [ -z "$WAYLAND_DISPLAY" ] ; then export WAYLAND_DISPLAY=wayland-0 else export WAYLAND_DISPLAY=wayland-1 fi is not a correct method. there is also unnecessary complexity, such as using .xsessionrc instead of just exporting the variables. env | grep "DISPLAY" is insane. most of their justifiable complexity comes from insisting on mutter. while that's arguably suitable for (gnome) fedora, gentoo does not have an official DE, and should either have a configurable option (better but not realistic) or otherwise just pick the simplest option, which is probably tinywl or cage, followed by weston.
Could someone running wayland test https://github.com/gentoo/gentoo/pull/27512 ? I can build wayland+pgo with this, but the browser doesn't launch for me because I'm not running wayland. I guess in future there should be a list of wayland-capable compositors and if one is installed (and most likely being used), it's enough as a requirement.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=063b3e0e3d31acd88f453831f71d74d976d66359 commit 063b3e0e3d31acd88f453831f71d74d976d66359 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-09-28 15:42:23 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-10-03 13:27:11 +0000 www-client/firefox: enable wayland+pgo build on rapid - virtwl() function copied from https://cgit.alxu.ca/gentoo-overlay.git/tree/eclass/virtualwl.eclass Closes: https://bugs.gentoo.org/848858 Closes: https://bugs.gentoo.org/767997 Signed-off-by: Joonas Niilola <juippis@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/27512 www-client/firefox/firefox-105.0.1.ebuild | 39 ++++++++++++++++++++++++++----- 1 file changed, 33 insertions(+), 6 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a5d952b94841d874c47714eb7e4e52d6594c137e commit a5d952b94841d874c47714eb7e4e52d6594c137e Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-10-03 17:06:00 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-10-03 17:08:05 +0000 Revert "www-client/firefox: enable wayland+pgo build on rapid" This reverts commit 063b3e0e3d31acd88f453831f71d74d976d66359. - forgot to include the part which disables virtualx.eclass's dependency on x11-base/xorg-server[xvfb]. Bug: https://bugs.gentoo.org/848858 Bug: https://bugs.gentoo.org/767997 Signed-off-by: Joonas Niilola <juippis@gentoo.org> www-client/firefox/firefox-105.0.1.ebuild | 39 +++++-------------------------- 1 file changed, 6 insertions(+), 33 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=15ac4bb53f345968163553213bf2f018a7249ab6 commit 15ac4bb53f345968163553213bf2f018a7249ab6 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-10-04 14:56:50 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-10-04 14:56:50 +0000 www-client/firefox: add 105.0.2 - enable wayland+pgo, - virtwl() function copied from https://cgit.alxu.ca/gentoo-overlay.git/tree/eclass/virtualwl.eclass Closes: https://bugs.gentoo.org/848858 Closes: https://bugs.gentoo.org/767997 Signed-off-by: Joonas Niilola <juippis@gentoo.org> www-client/firefox/Manifest | 98 +++ www-client/firefox/firefox-105.0.2.ebuild | 1317 +++++++++++++++++++++++++++++ 2 files changed, 1415 insertions(+)
