On Sat, Oct 15, 2022 at 09:27:33AM +0300, Adrian Bunk wrote:
> Package: firefox-esr
> Version: 102.3.0esr-1
> Severity: serious
> Tags: bookworm sid
> X-Debbugs-Cc: Carsten Schoenert <c.schoen...@t-online.de>,
> debian-rele...@lists.debian.org, t...@security.debian.org,
> debian-...@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.
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
