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
