Discussion:
Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel
Add Reply
Aurelien Jarno
2021-04-26 21:10:01 UTC
Reply
Permalink
Source: e2fsprogs
Version: 1.46.2-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source (but built successfully in the past)
Forwarded: https://github.com/tytso/e2fsprogs/issues/65

e2fsprogs builds fine on armel/armhf when built on a machine with a
32-bit kernel. However it fails to build on a machine with a 64-bit
kernel due to alignments issues which are not trapped by the kernel:

A build log is available there:
https://tests.reproducible-builds.org/debian/logs/unstable/armhf/e2fsprogs_1.46.2-1.build2.log.gz
Aurelien Jarno
2021-05-03 21:10:01 UTC
Reply
Permalink
Hi,
Post by Aurelien Jarno
Source: e2fsprogs
Version: 1.46.2-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source (but built successfully in the past)
Forwarded: https://github.com/tytso/e2fsprogs/issues/65
e2fsprogs builds fine on armel/armhf when built on a machine with a
32-bit kernel. However it fails to build on a machine with a 64-bit
https://tests.reproducible-builds.org/debian/logs/unstable/armhf/e2fsprogs_1.46.2-1.build2.log.gz
Hi, thanks for the bug report. I have a patch which should address
this problem. (See below).
I have a question for the Debian Release Team (cc'ed). Do you agree
this is considered "serious"? It will build from source on a system
with a arm-32 kernel. It is only when cross-compiling on armel or
armhf on a aarch64 platform that some regression tests
(j_recover_csum2_32bit, j_recover_csum2_64bit, and j_recover_fast_commit)
will fail, and it is this which causes dpkg-buildpackage when run on a
arm-32 chroot on a 64-bit arm system to fail.
So it is not completely clear to me that this qualifies as a FTBFS,
such that the release team would grant an migration into bullseye
given that we are currently in "frozen hard to get hot"[1]
[1] https://lists.debian.org/debian-devel-announce/2021/03/msg00006.html
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.

Regards,
Aurelien

[1] https://lists.debian.org/debian-arm/2019/01/msg00000.html
[2]
https://buildd.debian.org/status/fetch.php?pkg=e2fsprogs&arch=armhf&ver=1.46.2-1&stamp=1614569268&raw=0
Theodore Ts'o
2021-05-03 22:30:02 UTC
Reply
Permalink
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

Loading...