[PING to debian-release] Re: Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel

["Theodore Y. Ts'o" <tytso@mit.edu>]

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