On Mon, Feb 22, 2021 at 09:04:43AM +1100, Dave Chinner wrote:

quoted

This upstream release ended up with an older version of config.guess in
the tarball.  Specifically, it was too old to recognize RISC-V as an
architecture.

So was the RISC-V architecture added to the ubuntu build between the
uploads of the previous version of xfsprogs and xfsprogs-5.10.0? Or
is this an actual regression where the maintainer signed tarball had
RISC-V support in it and now it doesn't?

This is a regression.  The previous tarball (5.6.0) had a newer config.guess
that recognized RISC-V, the newer one (5.10.0) had an older config.guess.

FWIW, where are you getting the tarballs from? Are you downloading
the maintainer signed tarballs from here:

https://mirrors.edge.kernel.org/pub/linux/utils/fs/xfs/xfsprogs/

Or pulling the git.kernel.org built tarball that is autogenerated
from the release tag?

I don't know the answer to this; we in Ubuntu take the tarballs from Debian.

quoted

quoted

quoted

 	@echo "== dpkg-buildpackage: configure" 1>&2
 	$(checkdir)
 	AUTOHEADER=/bin/true dh_autoreconf
+	dh_update_autotools_config
 	$(options) $(MAKE) $(PMAKEFLAGS) include/platform_defs.h

quoted

quoted

Why would running at tool that does a search-n-replace of built
config.guess files do anything when run before the build runs
libtoolize to copy in the config.guess file it uses? I'm a bit
confused by this...

quoted

Autoreconf was not copying in a newer version of config.guess from the
system, because of the specific subset of autotools used by this
project.

That sounds wrong. AIUI, autoreconf doesn't copy in anything.

$ man 7 dh-autoreconf
....
CAVEATS
       dh_autoreconf is mostly a superset of the
       dh_update_autotools_config debhelper command included in
       debhelper since version 9.20160115. When using the dh
       sequencer, dh_update_autotools_config is run before
       dh_autoreconf and updates the config.guess and config.sub
       files. This is required in cases where autoreconf does not
       update config.guess and config.sub itself.

So isn't the dh_update_autotools_config call in the wrong place
here?

Documentation notwithstanding, dh_autoreconf was definitively NOT copying in
the newer config.guess, and we have the build logs to prove it.

https://launchpad.net/ubuntu/+source/xfsprogs/5.10.0-2ubuntu1/+build/20952006

I don't know in what sense this would be the "wrong" place to call it,
because it fixes the build failure, which is what I care about.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org