Summary: | www-client/firefox-78.1.0 version bump | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sylvia <fierevere> |
Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexander, bgo-7187AEA9-brand, bugs, esteve.varela, flyser42, gentoo, herrtimson, jaak, martin.cibule |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | gzip tar containing ebuild and patches for firefox 78.3 |
Description
Sylvia
2020-07-31 09:13:36 UTC
We don't have the man power to support multiple ESR branches. The switch to next ESR version is planned for end of Q3/2020. *** Bug 735822 has been marked as a duplicate of this bug. *** (In reply to Thomas Deutschmann from comment #1) > We don't have the man power to support multiple ESR branches. > The switch to next ESR version is planned for end of Q3/2020. So do I understand it correctly that you plan to ride out the 68ESR branch and switch to 78.3 at the earliest according to the FF release calendar? https://wiki.mozilla.org/Release_Management/Calendar I try to target 78.2 relase but yes. Fwiw, I repurposed the firefox-78.0.2.ebuild for 78.1.0 ESR (setting MOZ_ESR="1") and have been happily using it for a week. Seems solid with USE="bindist eme-free hardened hwaccel lto openh264 pulseaudio screenshot system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-webp wayland" CPU_FLAGS_X86="avx2" L10N="et" The only problem I've seen with this so far is that at least one of its requirements conflict with that of mail-client/thunderbird-68.11.0, namely libvpx if built with USE="system-libvpx". However, regardless of this dependency issue both www-client/firefox-78.1.0[system-libvpx] and mail-client/thunderbird-68.11.0[system-libvpx] both seem to work properly with media-libs/libvpx-1.8.2 installed. But maybe I have just not yet triggered any Thunderbird code which calls into libvpx. (In reply to Sylvia from comment #0) > firefox-78.1.0 is in new ESR channel. > Currently Gentoo offers only old ESR and 79 > Available versions: 68.11.0^td ~79.0^td > > > 78ESR should be available too. +1 (In reply to Jaak Ristioja from comment #5) > Fwiw, I repurposed the firefox-78.0.2.ebuild for 78.1.0 ESR (setting > MOZ_ESR="1") and have been happily using it for a week. Seems solid with > USE="bindist eme-free hardened hwaccel lto openh264 pulseaudio screenshot > system-av1 system-harfbuzz system-icu system-jpeg system-libevent > system-libvpx system-webp wayland" CPU_FLAGS_X86="avx2" L10N="et" > > The only problem I've seen with this so far is that at least one of its > requirements conflict with that of mail-client/thunderbird-68.11.0, namely > libvpx if built with USE="system-libvpx". However, regardless of this > dependency issue both www-client/firefox-78.1.0[system-libvpx] and > mail-client/thunderbird-68.11.0[system-libvpx] both seem to work properly > with media-libs/libvpx-1.8.2 installed. But maybe I have just not yet > triggered any Thunderbird code which calls into libvpx. gcc or llvm? (In reply to CaptainBlood from comment #7) > gcc or llvm? Excuse me? I'm sorry, but couldn't unambiguously infer the whole question from these three words. Could you please expand the wording of your question? to everyone's surprise, there's new release bump sooner then expected. now esr users are uncovered for as long as it takes to bump that ebuild, and to upgrade to 81.0 and downgrade later isn't an option since profile downgrade isn't supported by mozilla anymore as it can silently break things. why don't you ask for help on the mailing list with this? I'm sure people will rush in to help out, as they did to help you fixing the spidermonkey:78 ebuild Created attachment 662932 [details]
gzip tar containing ebuild and patches for firefox 78.3
The firefox-78.0.2.ebuild renamed to firefox-78.3.0.ebuild with MOZ_ESR="1" and the removal of 0029-bmo-1632429-enum34-and-enum-virtualenv-packages-are-.patch seems to work fine.
The USE=dbus fix for the firefox-80.0.1.ebuild along with the two included patches I backported allow dbus to be disabled.
The included ebuild removes the 0029 patch and includes the USE=dbus code. The other two patches must be placed in /etc/portage/patches/www-client/firefox/ until a new patch set file is created.
(In reply to Brand Huntsman from comment #10) > Created attachment 662932 [details] > gzip tar containing ebuild and patches for firefox 78.3 > > The firefox-78.0.2.ebuild renamed to firefox-78.3.0.ebuild with MOZ_ESR="1" > and the removal of > 0029-bmo-1632429-enum34-and-enum-virtualenv-packages-are-.patch seems to > work fine. > > The USE=dbus fix for the firefox-80.0.1.ebuild along with the two included > patches I backported allow dbus to be disabled. > > The included ebuild removes the 0029 patch and includes the USE=dbus code. > The other two patches must be placed in > /etc/portage/patches/www-client/firefox/ until a new patch set file is > created. You don't have to create a new patchset, old one can be used. You'll edit the ebuild anyway to activate ESR branch, so just add: ---------- src_prepare() { # Remove outdated patches from 78.0-patches-3 rm "${WORKDIR}"/firefox/0029-bmo-1632429-enum34-and-enum-virtualenv-packages-are-.patch eapply "${WORKDIR}/firefox" ---------- Note this is just for testing / personal use. The final patch set will be of course updated. I can't build the 78.3 release on gcc, but with clang it works. Did you have similar problems? If not, what may your USE flags be? For 78.3.0 at first I just took my ebuild for 78.1.0 (see comment #5), but it failed to apply one or more of the musl patches as well. Since I'm not using musl, I simply opted out of all the musl patches, and ended up adding this to src_prepare(): rm ${WORKDIR}/firefox/00??-musl-* ${WORKDIR}/firefox/0029-* And it worked for me with USE="bindist eme-free hardened hwaccel lto openh264 pulseaudio screenshot system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-webp wayland" @Joonas Niilola, The ebuild I attached has that exact line to remove 0029. I compiled with USE="gmp-autoupdate hwaccel openh264 system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-webp", so gcc. @Jaak Ristioja, It is weird that the same patchset (05?) wouldn't apply to the same source for you. (In reply to Brand Huntsman from comment #13) > @Jaak Ristioja, It is weird that the same patchset (05?) wouldn't apply to > the same source for you. Now that you mention this, I think I might have remembered incorrectly. I now recall that I might have attempted to minimize the set of patches, but abandoned the effort half-way when I got it to compile. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=eaf416cbcda53918cbd9250877bf1bd76ed5f5c1 commit eaf416cbcda53918cbd9250877bf1bd76ed5f5c1 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2020-09-30 01:02:06 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2020-09-30 01:05:11 +0000 www-client/firefox: bump to v78.3.0 Closes: https://bugs.gentoo.org/698978 Closes: https://bugs.gentoo.org/734924 Bug: https://bugs.gentoo.org/744208 Package-Manager: Portage-3.0.8, Repoman-3.0.1 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> www-client/firefox/Manifest | 97 +++ www-client/firefox/firefox-78.3.0.ebuild | 1028 ++++++++++++++++++++++++++++++ 2 files changed, 1125 insertions(+) |