Bug#1021810: Should firefox-esr be dropped on 32bit architectures in bookworm?
Package: firefox-esr
Version: 102.3.0esr-1
Severity: serious
Tags: bookworm sid
X-Debbugs-Cc: Carsten Schoenert <c.schoenert@t-online.de>, debian-release@lists.debian.org, team@security.debian.org, debian-arm@lists.debian.org
[ various potentially interested parties are Cc'ed ]
4 GB address space for one process is an absolute limit on 32bit
architectures, including for native building as is done in Debian.[1]
mipsel has 2 GB address space (all Debian buildds have 64bit kernels),
the 2020 Firefox ESR (78) was the last Firefox ESR to build there.
On i386 and 32bit arm:
4 GB address space are available with a 64bit kernel.
3 GB address space are typically available with a 32bit kernel.
All i386 buildds are using a 64bit kernel,
but armhf buildds are currently mixed.
This uncovered that the 2022 ESR of Firefox (102) already needs
more than 3 GB address space on armhf.[2]
There is a new ESR major release of Firefox every summer,
which is being used also in *stable releases of Debian since the
previous ESR branch loses upstream security support soon afterwards.
It is possible to confine building firefox{,-esr} to only the 64bit
buildds on the buildd side to address the current issue,[3] but during
the non-LTS lifetime of bookworm firefox-esr will be upgraded three
times to newer ESR major releses.
One can hope the 2023 ESR might still be buildable with 4 GB address space,
which would cover the non-LTS support time of bullseye.
I would be less optimistic that the 2025 ESR will still be buildable
with 4 GB address space, which implies that it might not be possbile
to provide security support for firefox-esr on i386 and 32bit arm
during the whole non-LTS support time of bookworm.
The above considerations might also apply to whether or not
thunderbird/i386 should be provided in bookworm.
Thanks
Adrian
[1] Cross-build discussions are irrelevant (too late) for bookworm.
[2] https://sources.debian.org/src/firefox-esr/102.3.0esr-1/debian/rules/#L233-L238
[3] Aurelien Jarno would be the person to contact
Reply to: