On Sun, Feb 21, 2021 at 10:39:45AM +0100, Bastian Germann wrote:
> This is a change introduced in 5.10.0-2ubuntu2 with the changelog:
>
> > xfsprogs upstream has regressed config.guess, so use
> > dh_update_autotools_config.
>
> The 5.10.0 tarball has a config.guess that breaks builds on RISC-V:
> ...
> UNAME_MACHINE = riscv64
> UNAME_RELEASE = 5.0.0+
> UNAME_SYSTEM = Linux
> UNAME_VERSION = #2 SMP Sat Mar 9 22:34:53 UTC 2019
> configure: error: cannot guess build type; you must specify one
> make[1]: *** [Makefile:131: include/builddefs] Error 1
> ...
>
> Reported-by: Steve Langasek <steve.langasek@xxxxxxxxxx>
> Signed-off-by: Bastian Germann <bastiangermann@xxxxxxxxxxx>
> ---
> debian/changelog | 7 +++++++
> debian/rules | 1 +
> 2 files changed, 8 insertions(+)
>
> diff --git a/debian/changelog b/debian/changelog
> index 5421aed6..679fbf03 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,10 @@
> +xfsprogs (5.11.0-rc0-1) experimental; urgency=medium
> +
> + [ Steve Langasek ]
> + * Regenerate config.guess using debhelper
> +
> + -- Bastian Germann <bastiangermann@xxxxxxxxxxx> Sat, 20 Feb 2021 11:57:31 +0100
> +
> xfsprogs (5.10.0-3) unstable; urgency=medium
>
> * Drop unused dh-python from Build-Depends (Closes: #981361)
> diff --git a/debian/rules b/debian/rules
> index c6ca5491..fe9a1c3a 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -43,6 +43,7 @@ config: .census
> @echo "== dpkg-buildpackage: configure" 1>&2
> $(checkdir)
> AUTOHEADER=/bin/true dh_autoreconf
> + dh_update_autotools_config
Hm. The manual page says "dh_update_autotools_config replaces all
occurrences of config.sub and config.guess in the source tree by the
up-to-date versions found in the autotools-dev package."
autoreconf does not itself examine config.{guess,sub}. automake can
override those files if someone passes it --force --add-missing, but
nobody does. The build then kicks off with an ancient config.guess.
Hence this patch forcibly overrides config.guess (and config.sub) after
autoreconf, but before debuild gets to ./configure, thereby solving the
build failure on riscv.
Eric could also not to ship config.guess files at all, but that would
break the age-old "download and unpack tarball, ./configure && make"
workflow. Overriding the files also works, though I have not focused
on repercussions for reproducible builds while examining this patch.
----------
As for the question of why the config.guess file versions keep
changing in the .orig and kernel.org tarballs--
[1] is a tarball with a 2013 era config.guess and files owned by
'sandeen', which I guess means that Eric generates the config.guess file
on a machine with fairly old devel packages before uploading to
kernel.org.
[2] is a tarball with a 2016 era config.guess and files owned by
'nathans'. I suspect this means that Nathan Scott generated his own
.orig tarball when creating the 5.6.0 package, and as part of that
generated config.guess from a (somewhat more up to date) system?
[3] is a tarball with a 2013 era config.guess and files owned by
'sandeen', which I guess means that four releases later, Eric still
generates the config.guess file on a machine with fairly old devel
packages before uploading to kernel.org. Though weirdly now he's doing
this as root (or I really hope fakeroot?)
[4] appears to be the same tarball as [3].
So reading between the lines here, I speculate that Eric runs 'make
xfsprogs-5.6.0.tar.xz' on (who are we kidding here, RHEL) and so that
tarball gets the 2013 era config.guess. Nathan ran 'make
xfsprogs-5.6.0.tar.gz' on Debian and uploaded that to Debian, whereas
Bastian is pulling tarballs straight from kernel.org? Then Ubuntu
pulled the Debian sources, found that riscv regressed, hence this patch
to reset config.guess?
(And the reason I never noticed is that I build from git on Ubuntu
20.04. There's no config.guess in the build directory so the build
scripts install config.guess from autotools-dev; the one I get is from
2018 or so...)
Insofar as I avoid have strong opinions about packaging, I don't think
it's unreasonable for a distro to override autotools files with the
versions that they're shipping in that distro. Who knows what kinds of
adjustments Debian makes to autotools, and it's certainly their right to
do that.
Reviewed-by: Darrick J. Wong <djwong@xxxxxxxxxx>
<flame>
Personally I also think the upstream tarball should not ship with any of
those autotools files at all because they are not revision-controlled in
upstream git. Anyone building from source ought to have autotools and
can generate their own.
</flame>
--D
[1] https://mirrors.edge.kernel.org/pub/linux/utils/fs/xfs/xfsprogs/xfsprogs-5.6.0.tar.gz
[2] http://archive.ubuntu.com/ubuntu/pool/main/x/xfsprogs/xfsprogs_5.6.0.orig.tar.gz
[3] https://mirrors.edge.kernel.org/pub/linux/utils/fs/xfs/xfsprogs/xfsprogs-5.10.0.tar.xz
[4] http://deb.debian.org/debian/pool/main/x/xfsprogs/xfsprogs_5.10.0.orig.tar.xz
> $(options) $(MAKE) $(PMAKEFLAGS) include/platform_defs.h
> touch .census
>
> --
> 2.30.1
>
