Bug#1031589: Handling of RC bugs in firefox-esr
On Fri, Feb 24, 2023 at 12:27:35PM +0100, Emilio Pozuelo Monfort wrote:
> On 24/02/2023 09:48, Adrian Bunk wrote:
> > On Fri, Feb 24, 2023 at 09:19:40AM +0100, Emilio Pozuelo Monfort wrote:
> > > ...
> > > Also note that one of the concerns was for armhf, which is now being built
> > > from arm64 buildds.
> > > ...
> >
> > On armhf there is a 4 GB FTBFS for the future (like on i386),
> > and a 3 GB FTBFS today that still seems to be present on some buildds.
> >
> > While some armhf buildds have a 4 GB userspace address space that is
> > sufficient at least today, several buildds still run into the
> > debian/rules test for 64bit:
> > https://buildd.debian.org/status/logs.php?pkg=firefox=armhf
> > https://buildd.debian.org/status/logs.php?pkg=firefox-esr=armhf
> >
> > arm-ubc-0* had out of memory before the debian/rules test for 64bit,
> > so there might be a genuine issue that firefox-esr cannot be built
> > on these buildds and still might have to be blacklisted:
> > https://buildd.debian.org/status/logs.php?pkg=firefox-esr=armhf=91.11.0esr-1
>
> My understanding was that those buildds were going to be decommissioned. But
> if that's not going to happen in the short term, a blacklist for firefox-esr
> and thunderbird would be in order.
antheil/hartmann/hasse/henze/hoiby have been decommissioned as planned.
I do not know whether arm-ubc-0{4,5,6} are also planned to be
decommissioned, as of right now they are still running.
> Cheers,
> Emilio
cu
Adrian
Bug#1031589: Handling of RC bugs in firefox-esr
On 24/02/2023 09:48, Adrian Bunk wrote: On Fri, Feb 24, 2023 at 09:19:40AM +0100, Emilio Pozuelo Monfort wrote: ... Also note that one of the concerns was for armhf, which is now being built from arm64 buildds. ... On armhf there is a 4 GB FTBFS for the future (like on i386), and a 3 GB FTBFS today that still seems to be present on some buildds. While some armhf buildds have a 4 GB userspace address space that is sufficient at least today, several buildds still run into the debian/rules test for 64bit: https://buildd.debian.org/status/logs.php?pkg=firefox=armhf https://buildd.debian.org/status/logs.php?pkg=firefox-esr=armhf arm-ubc-0* had out of memory before the debian/rules test for 64bit, so there might be a genuine issue that firefox-esr cannot be built on these buildds and still might have to be blacklisted: https://buildd.debian.org/status/logs.php?pkg=firefox-esr=armhf=91.11.0esr-1 My understanding was that those buildds were going to be decommissioned. But if that's not going to happen in the short term, a blacklist for firefox-esr and thunderbird would be in order. Cheers, Emilio
Bug#1031589: Handling of RC bugs in firefox-esr
On Fri, Feb 24, 2023 at 09:19:40AM +0100, Emilio Pozuelo Monfort wrote: >... > Also note that one of the concerns was for armhf, which is now being built > from arm64 buildds. >... On armhf there is a 4 GB FTBFS for the future (like on i386), and a 3 GB FTBFS today that still seems to be present on some buildds. While some armhf buildds have a 4 GB userspace address space that is sufficient at least today, several buildds still run into the debian/rules test for 64bit: https://buildd.debian.org/status/logs.php?pkg=firefox=armhf https://buildd.debian.org/status/logs.php?pkg=firefox-esr=armhf arm-ubc-0* had out of memory before the debian/rules test for 64bit, so there might be a genuine issue that firefox-esr cannot be built on these buildds and still might have to be blacklisted: https://buildd.debian.org/status/logs.php?pkg=firefox-esr=armhf=91.11.0esr-1 > Cheers, > Emilio >... cu Adrian
Bug#1031589: Handling of RC bugs in firefox-esr
Control: severity 1021810 important Hi, On 19/02/2023 21:23, Sebastian Ramacher wrote: On 2023-02-19 01:03:34 +0200, Adrian Bunk wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: Maintainers of Mozilla-related packages Control: block 1021810 982794 992150 993659 993660 by -1 popcon is no longer a criteria for key packages, which makes firefox-esr subject to autoremoval that would be permanent for bookworm at this point of the freeze. Currently firefox-esr is on the autoremoval list due to 5 RC bugs. While my personal opinion is that Debian should follow Ubuntu which is now providing Chromium and Firefox only as snap (perhaps using a different similar technology like flatpak), not providing Firefox as a package in bookworm due to autoremoval based on some random RC bug would be wrong. If for some reason firefox-esr would intentionally not be shipped in bookworm, then reverse dependencies currently on the autoremoval list should get RC bugs for getting the chance to adapt. It would be good if a release team member could review which RC bugs in firefox-esr should be downgraded/ignored/fixed for bookworm. We are down to #1021810 and #982794 which are both about support for 32 bit architectures. If we end up dropping 32 bit architectures from firefox-esr, #982794 won't be an issue any more. If not, I think we can ignore #982794 as it's not a regression compared to stable. As Emilio commented in #1021801, I would defer to him on these two bugs. As I said on #1021810 about possible build issues due to address space in the future, I think we should tackle those when the time comes. It may be true that some future Firefox updates will fail to build due to needing more memory, however it's also possible that we may be able to fix those issues by reducing the memory usage with some build flags. Also note that one of the concerns was for armhf, which is now being built from arm64 buildds. Thus I don't think removal on those arches based on that is warranted, and I'm downgrading that bug's severity. As for #982794 and #1019246, I'm not sure which way to lean. Currently Firefox is broken on the baseline for i386 and armhf, but that only affects some hardware. We're doing a disservice to some users by shipping software that they can't run, but OTOH we would do a disservice to those other users who can (and do) run it. One option would be to depend on sse2-support / neon-support etc, but that probably leaves the system in a bad state. Note that there's a MR to support the i386 baseline, which doesn't seem too unreasonable. Cheers, Emilio Perhaps a bookworm-ignore is the less evil solution, but I'm open to other options. Cheers, Emilio
Bug#1031589: Handling of RC bugs in firefox-esr
On 2023-02-19 01:03:34 +0200, Adrian Bunk wrote: > Package: release.debian.org > Severity: normal > X-Debbugs-Cc: Maintainers of Mozilla-related packages > > Control: block 1021810 982794 992150 993659 993660 by -1 > > popcon is no longer a criteria for key packages, which makes > firefox-esr subject to autoremoval that would be permanent > for bookworm at this point of the freeze. > > Currently firefox-esr is on the autoremoval list due to 5 RC bugs. > > While my personal opinion is that Debian should follow Ubuntu > which is now providing Chromium and Firefox only as snap > (perhaps using a different similar technology like flatpak), > not providing Firefox as a package in bookworm due to autoremoval > based on some random RC bug would be wrong. > > If for some reason firefox-esr would intentionally not be shipped > in bookworm, then reverse dependencies currently on the autoremoval > list should get RC bugs for getting the chance to adapt. > > It would be good if a release team member could review which RC bugs > in firefox-esr should be downgraded/ignored/fixed for bookworm. We are down to #1021810 and #982794 which are both about support for 32 bit architectures. If we end up dropping 32 bit architectures from firefox-esr, #982794 won't be an issue any more. If not, I think we can ignore #982794 as it's not a regression compared to stable. As Emilio commented in #1021801, I would defer to him on these two bugs. Cheers -- Sebastian Ramacher
Bug#1031589: Handling of RC bugs in firefox-esr
Package: release.debian.org Severity: normal X-Debbugs-Cc: Maintainers of Mozilla-related packages Control: block 1021810 982794 992150 993659 993660 by -1 popcon is no longer a criteria for key packages, which makes firefox-esr subject to autoremoval that would be permanent for bookworm at this point of the freeze. Currently firefox-esr is on the autoremoval list due to 5 RC bugs. While my personal opinion is that Debian should follow Ubuntu which is now providing Chromium and Firefox only as snap (perhaps using a different similar technology like flatpak), not providing Firefox as a package in bookworm due to autoremoval based on some random RC bug would be wrong. If for some reason firefox-esr would intentionally not be shipped in bookworm, then reverse dependencies currently on the autoremoval list should get RC bugs for getting the chance to adapt. It would be good if a release team member could review which RC bugs in firefox-esr should be downgraded/ignored/fixed for bookworm.
