Hi Dave!

On 08/05/2015 10:47 AM, Dave Chinner wrote:

> make realclean also removes the .census file, so it appears that
> the debian package build has a dependency on it. Still, that's a
> side issue, because we still don't exactly what is causing the
> configure script to fail.
Right. The immediate reason is because config.guess and config.sub are not
being updated. Once they are updated, configure will not fail. When I copy them,
manually, from /usr/share/libtool/config/, the build does not fail.

> You seem to be talking about 2 different tarballs here.  The
> tarballs I release most definitely have a configure script in them:
>
> $ tar tfv xfsprogs-4.2.0-rc1.tar.gz |grep configure
> -rw-r--r-- dave/dave      3098 2015-08-04 11:16 xfsprogs-4.2.0-rc1/configure.ac
> -rwxr-xr-x dave/dave    469084 2015-08-04 14:25 xfsprogs-4.2.0-rc1/configure
>
> So I don't know where you are getting xfsprogs tarballs without
> configure scripts from.
My apologies, it was a confusion of my part. I was looking at the git tree.
The tarball does come with configure. But the config.{guess,sub} that come with
it are up-to-date, differently of what comes with the debian src package.
I generated a diff from them, which is attached.
Also, the version I have here is not 4.2.0-rc1, it is the one found at the git
repository I mentioned. Is that not correct?

>
> To clear up any confusion, can you please explain exactly what you
> are building (step by step for the dummies in the audience like me)
> so we all understand exactly what context the build is failing in?
>
Ok. Just clarifying that what actually fails is the debian package, exclusively.
The ones found in xfs.org (actually oss.sgi.com/xfs) build flawlessly.

Originally I used sbuild, but manually this is what I do:

# apt-get source xfsprogs
# cd xfsprogs-3.2.4/
# apt-get build-dep xfsprogs
...
# dpkg-buildpackage
I am attaching the build log because it is a bit long.

>> Actually powerpc*-*linux* covers the triplet for ppc64el, as seen in:
>>>>         host-triplet:     powerpc64le-unknown-linux-gnu
>> So ppc*-*linux* does not make difference for  ppc64el, if that is what you
>> refer to.
>
> Did you actually try it?
Yes, I changed that line 1315 in /usr/share/aclocal/libtool.m4 to look the same
as you showed, but the build failed anyway.
>
> Sure, it may not be the reason that it builds correctly on Darrick's
> machine, but the fact is that Darricks' environment successfully
> builds packages from the official xfsprogs tarballs without
> problems and yours doesn't. The above change is the only thing that
> is non-standard in Darrick's environment, so it's an obvious change
> to try even if it makes no sense to you.
I understand that.
A correction though: mine builds from the official xfsprogs source or tarballs
without problems too.
It is the Debian source package that fails, exclusively.

>
> And it still doesn't change the situation: we can't fix the problem
> until we understand what is causing it....
What is causing it is: the old files config.guess and config.sub in the source 
package. Whether shipping updated ones or not shipping the configure file would
be the quick solution to this. Again, it is an exclusive problem with the
Debian package.

I am curious about something I have just noticed (while writing this e-mail).
Running apt-get source xfsprogs gets a tarball xfsprogs_3.2.4.tar.gz
Shouldn't it be the exact same file I get from:
http://ftp.br.debian.org/debian/pool/main/x/xfsprogs/xfsprogs_3.2.4.tar.gz
Because they differ. And the latter does not fail at all.

I am sorry for any confusion I might be causing :)

Thanks and regards.
-- 

Fernando Seiti Furusato
IBM Linux Technology Center