Re: Bug#793495: xfsprogs fails to build on debian ppc64el

[Daniel Bast <daniel.bast@xxxxxxx>]

Am 02.08.2015 um 00:52 schrieb Dave Chinner <david@xxxxxxxxxxxxx>:

On Fri, Jul 31, 2015 at 06:57:35PM -0300, Fernando Seiti Furusato wrote:

That error is common when configure is generated using out-of-date config.guess
and config.sub.
The ones that come with the package are, in fact, old.

config.sub and config.guess are generated by the build, we don't
ship them directly from the git repository. Perhaps you are building
from a release tarball rather than from a clean git repository
working area? Can you confirm this is the case?

Just some observations from my side:

Extracting the released tarball over a clean xfsprogs git repo and removing the .gitignore file, then git status reveals:

Untracked files:

  (use "git add <file>..." to include in what will be committed)

.gitcensus

aclocal.m4

config.guess

config.sub

configure

install-sh

ltmain.sh

m4/libtool.m4

m4/ltoptions.m4

m4/ltsugar.m4

m4/ltversion.m4

m4/lt~obsolete.m4

po/xfsprogs.pot

Looks like there are a lot of untracked file. Is this intentional, to have potentially auto-generated but un-versioned files in a release tarball?

It gets even more interesting, comparing debian source vs official release:

http://http.debian.net/debian/pool/main/x/xfsprogs/xfsprogs_3.2.4.tar.gz

ftp://oss.sgi.com/projects/xfs/cmd_tars/xfsprogs-3.2.4.tar.gz

There are differences in the following files:

modified:   aclocal.m4

modified:   config.guess

modified:   config.sub

modified:   configure

modified:   ltmain.sh

modified:   m4/libtool.m4

modified:   po/xfsprogs.pot

So, imho the debian source tarball also doesn’t look clean, neither against the release tarball nor against a clean git checkout.

Just my 2 cents, maybe that helps someone to solve this.

Cheers,

Daniel

If so, can you remove the configure, config.sub and config.guess
files and see if you get the same problem?

This package used to run dh_autotools-dev_updateconfig and
dh_autotools-dev_restoreconfig, which worked because it only updates those
files.

They were replaced by dh_autoreconf and dh_autoreconf_clean, which should
update them, but does not run flawlessly.
I think something is wrong with the m4 macros but I am not sure what.
There are errors when running dh_autoreconf alone.

# dh_autoreconf
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoheader: warning: missing template: HAVE_UMODE_T
autoheader: Use AC_DEFINE([HAVE_UMODE_T], [], [Description])
autoheader: warning: missing template: HAVE___PSINT_T
autoheader: warning: missing template: HAVE___PSUNSIGNED_T
autoheader: warning: missing template: HAVE___U32
autoreconf: /usr/bin/autoheader failed with exit status: 1
dh_autoreconf: autoreconf -f -i returned exit code 1

I will keep working on it, but all I will be able to do if I get to a conclusion
is send a patch here.
Thus it will have to be dealt with by the maintainers anyway.

The XFS list is cc'd on the bug, so the upstream maintainers are
watching and will see the patch when you post it. ;)

Cheers,

Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs