<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><br class="">Am 02.08.2015 um 00:52 schrieb Dave Chinner <<a href="mailto:david@fromorbit.com" class="">david@fromorbit.com</a>>:</div><br class="Apple-interchange-newline"><div class="">On Fri, Jul 31, 2015 at 06:57:35PM -0300, Fernando Seiti Furusato wrote:<br class=""><blockquote type="cite" class="">That error is common when configure is generated using out-of-date config.guess<br class="">and config.sub.<br class="">The ones that come with the package are, in fact, old.<br class=""></blockquote><br class="">config.sub and config.guess are generated by the build, we don't<br class="">ship them directly from the git repository. Perhaps you are building<br class="">from a release tarball rather than from a clean git repository<br class="">working area? Can you confirm this is the case?<br class=""><br class=""></div></blockquote><div><br class=""></div><div>Just some observations from my side:</div><div><br class=""></div><div>Extracting the released tarball over a clean xfsprogs git repo and removing the .gitignore file, then git status reveals:</div><div><br class=""></div><div>Untracked files:</div><div> (use "git add <file>..." to include in what will be committed)</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>.gitcensus</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>aclocal.m4</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>config.guess</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>config.sub</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>configure</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>install-sh</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>ltmain.sh</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>m4/libtool.m4</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>m4/ltoptions.m4</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>m4/ltsugar.m4</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>m4/ltversion.m4</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>m4/lt~obsolete.m4</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>po/xfsprogs.pot</div><div><br class=""></div><div>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?</div><div><br class=""></div><div>It gets even more interesting, comparing debian source vs official release:</div><div><a href="http://http.debian.net/debian/pool/main/x/xfsprogs/xfsprogs_3.2.4.tar.gz" class="">http://http.debian.net/debian/pool/main/x/xfsprogs/xfsprogs_3.2.4.tar.gz</a></div><div><a href="ftp://oss.sgi.com/projects/xfs/cmd_tars/xfsprogs-3.2.4.tar.gz" class="">ftp://oss.sgi.com/projects/xfs/cmd_tars/xfsprogs-3.2.4.tar.gz</a></div><div><br class=""></div><div>There are differences in the following files:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>modified: aclocal.m4</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>modified: config.guess</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>modified: config.sub</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>modified: configure</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>modified: ltmain.sh</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>modified: m4/libtool.m4</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>modified: po/xfsprogs.pot</div><div><br class=""></div><div><br class=""></div><div>So, imho the debian source tarball also doesn’t look clean, neither against the release tarball nor against a clean git checkout.</div><div><br class=""></div><div>Just my 2 cents, maybe that helps someone to solve this.</div><div><br class=""></div><div>Cheers,</div><div><br class=""></div><div>Daniel</div></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">If so, can you remove the configure, config.sub and config.guess<br class="">files and see if you get the same problem?<br class=""><br class=""><blockquote type="cite" class="">This package used to run dh_autotools-dev_updateconfig and<br class="">dh_autotools-dev_restoreconfig, which worked because it only updates those<br class="">files.<br class=""><br class="">They were replaced by dh_autoreconf and dh_autoreconf_clean, which should<br class="">update them, but does not run flawlessly.<br class="">I think something is wrong with the m4 macros but I am not sure what.<br class="">There are errors when running dh_autoreconf alone.<br class=""><br class=""># dh_autoreconf<br class="">libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'.<br class="">libtoolize: copying file `./ltmain.sh'<br class="">libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.<br class="">libtoolize: copying file `m4/libtool.m4'<br class="">libtoolize: copying file `m4/ltoptions.m4'<br class="">libtoolize: copying file `m4/ltsugar.m4'<br class="">libtoolize: copying file `m4/ltversion.m4'<br class="">libtoolize: copying file `m4/lt~obsolete.m4'<br class="">libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.<br class="">autoheader: warning: missing template: HAVE_UMODE_T<br class="">autoheader: Use AC_DEFINE([HAVE_UMODE_T], [], [Description])<br class="">autoheader: warning: missing template: HAVE___PSINT_T<br class="">autoheader: warning: missing template: HAVE___PSUNSIGNED_T<br class="">autoheader: warning: missing template: HAVE___U32<br class="">autoreconf: /usr/bin/autoheader failed with exit status: 1<br class="">dh_autoreconf: autoreconf -f -i returned exit code 1<br class=""><br class="">I will keep working on it, but all I will be able to do if I get to a conclusion<br class="">is send a patch here.<br class="">Thus it will have to be dealt with by the maintainers anyway.<br class=""></blockquote><br class="">The XFS list is cc'd on the bug, so the upstream maintainers are<br class="">watching and will see the patch when you post it. ;)<br class=""><br class="">Cheers,<br class=""><br class="">Dave.<br class="">-- <br class="">Dave Chinner<br class=""><a href="mailto:david@fromorbit.com" class="">david@fromorbit.com</a><br class=""><br class="">_______________________________________________<br class="">xfs mailing list<br class="">xfs@oss.sgi.com<br class="">http://oss.sgi.com/mailman/listinfo/xfs<br class=""></div></blockquote></div><br class=""></body></html>