[ 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

this is awesome!

this is awesome!

Thanks for bootstrapping the discussion. I fully agree that we
should limit Firefox/Thunderbird to 64 archs for bookworm.

Cheers,
        Moritz

why are you so dense? i was thanking you. sincerely

FWIW, ironically, it's not the new version of Firefox that has these
needs in memory, it's the new version of rustc (the memory usage
regression is there) and/or llvm.

As a matter of fact, firefox-esr 91 started to fail to build on 32bits
architectures on unstable when some new version of rustc went into
unstable.

Mike

I see there is already a patch in there that changes from fulllto
link mode to thinlto, which uses less memory. It might be worth
investigating if it is still possible to build firefox-esr with
LTO disabled altogether, as that should use drastically less
address space at build time, at the expense of runtime performance.

     Arnd

I see there is already a patch in there that changes from fulllto
link mode to thinlto, which uses less memory. It might be worth
investigating if it is still possible to build firefox-esr with
LTO disabled altogether, as that should use drastically less
address space at build time, at the expense of runtime performance.

     Arnd

That is about to change (once linux-signed hits bullseye-backports). All armhf
builds will be running on arm64 buildds.

I don't see why we should preemptively remove firefox from architectures for a
build issue that may or may not happen 3 years from now. If it happens and we
can't fix/workaround it, then we can discontinue FF security updates there. But
until then, I think providing FF is better than not providing it.

Cheers,
Emilio

Hi,

Emilio Pozuelo Monfort wrote:

Excatly that. Seconded.

P.S.: Due to making this bug report "release critical", automatic
updates on stable with apt-listbugs stopped applying firefox-esr
security updates. Otherwise I wouldn't have noticed it. :-P

		Regards, Axel

The bug is tagged "bookworm, sid", which makes it clear that it does not
apply to stable.

Looking at the BTS, apt-listbugs seems to have some problems with
version tracking that should be fixed there.

cu
Adrian

Hi Adrian,

Adrian Bunk wrote:

Indeed.

Ack, this is not the first such case and I assume that many of them
before were also properly tagged.

Will file a bug report against apt-listbugs as there seems currently
none related to release-name tags.

Thanks for reminding me of this!

		Regards, Axel

Actually, firefox-esr doesn't even work on real x86_32 CPUs (except
Pentium 4) since years.
It requires SSE2 without the sse2-support package, so basically it is
committing a baseline violation on i386.
Currently, due to some random GCC behavior, it doesn't crash instantly
when I try to open any page. But this can change in any upcoming
versions.

There is a fix, but it is not merged since months:
https://salsa.debian.org/mozilla-team/firefox/-/merge_requests/7

If it was merged, it would close the following bugs:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923785
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961663
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009808
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002600
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019246

Alternatively, epiphany-browser could be used instead of firefox-esr
on i386, because that works without SSE or even without MMX.