On Wed, Aug 05, 2015 at 12:52:50PM -0300, Fernando Seiti Furusato wrote:
> 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?
I released 4.2.0-rc1 to the dev tree on kernel.org. I didn't update
the tree on oss.sgi.com or make an official release tarball because
it's a developer pre-release. And there's a couple of things under
discussion that that might require a rebase of the tree, so that's
another reason for not making an "official" release.
....
> A correction though: mine builds from the official xfsprogs source or tarballs
> without problems too.
> It is the Debian source package that fails, exclusively.
Ok, that clears up the confusion. Thanks for explaining what is
happening to the dummy in the audience (me).
> 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.
No idea - that's definitely a distro issue ;)
> make[1]: Entering directory '/home/xfsprogs/xfsprogs-3.2.4'
> ./configure $LOCAL_CONFIGURE_OPTIONS
> checking build system type... ./config.guess: unable to guess system type
>
> This script, last modified 2012-02-10, has failed to recognize
This is what I found about an hour before reading this email. On
#xfs:
[06/08/15 09:32] <dchinner_> now that "last modified <$timestamp>" is important
[06/08/15 09:33] <dchinner_> because that tells us what version was used to generate the script
[06/08/15 09:34] <dchinner_> in the version shipped in the 3.2.4 tarball, it is:
[06/08/15 09:34] <dchinner_> timestamp='2014-03-23'
[06/08/15 09:34] <dchinner_> and it clearly has entries for ppc64le in it
> ppc64:Linux:*:*)
> - echo powerpc64-unknown-linux-gnu
> + echo powerpc64-unknown-linux-${LIBC}
> exit ;;
> ppc:Linux:*:*)
> - echo powerpc-unknown-linux-gnu
> + echo powerpc-unknown-linux-${LIBC}
> + exit ;;
> + ppc64le:Linux:*:*)
> + echo powerpc64le-unknown-linux-${LIBC}
> + exit ;;
> + ppcle:Linux:*:*)
> + echo powerpcle-unknown-linux-${LIBC}
> exit ;;
That hunk shows why it is failing - no ppc64le:Linux match in the
old script. Nathan is already looking into it...
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
