Ping to the debian-release bug. Do you want me to upload a fix to this bug where e2fsprogs fails its regression test (and thus its package build) when armhf and armel are running on a 64-bit ARM platform, but they were built successfully when run on a 32-bit ARM builder?
No question this is a real bug, and it is fixed upstream already. But do you want me to upload a fix *now*, during the hard freeze, given the impact on the installer, et. al.? Thanks! - Ted On Mon, May 03, 2021 at 06:24:54PM -0400, Theodore Ts'o wrote: > On Mon, May 03, 2021 at 11:00:37PM +0200, Aurelien Jarno wrote: > > > > Maybe I should give a bit of context here. First of all, there is one armhf > > buildd, arm-arm-01, setup as an arm64 machine with a 32-bit armhf chroot. It > > has been setup following [1] a study from Steve McIntyre [1]. It appears > > that e2fsprogs first failed to build there [2] and got requeued on another > > buildd where it succeed. > > > > Now with my DSA and buildd maintainer hat on, we have been experiencing for > > quite a lot of VM crashes when building packages in 32-bit armhf/armel VMs > > on arm64 machines, so we have recently stopped using VMs to build them and > > instead rely on chroots. > > Thanks for the context. I had indeed noticed shortly after 1.46.2-1 > was released that it had failed on the first armhf buildd, and then > when it was retried, it got successfully built. Given that this was > right before the bulleye release freeze hardened, this had been on my > radar screen to fix, since it was clearly non-optimal, but I had > assumed that it would be OK to let things slide until after the > Bullseye release, since after all e2fsprogs 1.46.2-1 *did* > successfully get built on armhf. > > For me, this is really a question of timing. It will definitely be > the case that the next source upload of e2fsprogs will have the > armhf/armel build fix. The question I have is should I upload the fix > before Bullseye releases, or after the Bullseye release. > > What is the impact on the buildd and DSA support effort if we wait > until after the Debian 11.0 release? What is the pain if we leave > this unfixed until Bullseye releases (I'm assuming that it's going to > be released soon)? The buildd's aren't going to be rebuilding > e2fsprogs until the next source upload, I would think. > > Contrawise, what is the impact on the Debian Release and Debian > Installer teams if I push out a bug-fix-only e2fsprogs source package > in the next week or so? > > I'll do what is least disruptive for all of the relevant teams. Let > me know what's preferred. > > Cheers, > > - Ted