Bug#793495: xfsprogs fails to build on debian ppc64el

2015-08-06 Thread Nathan Scott 


- Original Message -
 On Wed, Aug 05, 2015 at 12:52:50PM -0300, Fernando Seiti Furusato wrote:
  [...]
  It is the Debian source package that fails, exclusively.
 [...]
 That hunk shows why it is failing - no ppc64le:Linux match in the
 old script. Nathan is already looking into it...

So, yeah, its definitely got something to do with the local setup here
inserting configure-generated files that are dated.  I build the .debs
from a tagged git repo checkout (without the generated files initially)
so they do get inserted locally.

Having re-installed all autoconf-related packages now on that machine,
as well as constructing an entirely new unstable VM for builds :P  ...
the problem has resolved itself and I see config.sub with ppc64le bits
too.

I'll do a build and upload (source-unchanged) 3.2.4-1 package to make
sure its resolved on the build servers.

Thanks to all for looking into it so closely!

cheers.

--
Nathan


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793495: xfsprogs fails to build on debian ppc64el

2015-08-05 Thread Dave Chinner 
On Wed, Aug 05, 2015 at 10:00:02AM -0300, Fernando Seiti Furusato wrote:
 On 08/04/2015 07:58 PM, Dave Chinner wrote:
 
 That makes distclean do the same thing that realclean does and, as
 that commit I pointed out previously, has been intentionally
 separated in the build system. You could make the debian/rules file
 simply call 'make realclean' rather than 'make distclean' to acheive
 this without changing the main makefile. Either way, however, I
 don't think that's the problem.
 Yes, except I tried changing debian/rules to use realclean before coming up
 with that idea and it broke the build.
 
  make[1]: Entering directory '/home/xfsprogs/xfsprogs-3.2.4'
  ./configure $LOCAL_CONFIGURE_OPTIONS
  configure: error: cannot find install-sh, install.sh, or shtool in . ./.
  Makefile:89: recipe for target 'include/builddefs' failed
  make[1]: *** [include/builddefs] Error 1
  make[1]: Leaving directory '/home/xfsprogs/xfsprogs-3.2.4'
  debian/rules:36: recipe for target '.census' failed
  make: *** [.census] Error 2

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.

 Darrick Wong noted on #xfs that his builds of xfsprogs on ppc64el
 from a tarball don't fail at all. His libtool chain is:
 When I build xfsprog on ppc64el from a tarball, it does not fail at all 
 either.
 But in my case, specifically, it is because the tarball does not come with
 a configure file (which would solve the problem I pointed out), so Makefile
 generates it and runs libtoolize -c -i which updates the configuration files
 needed.

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/dave469084 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.

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?

host-triplet: powerpc64le-unknown-linux-gnu
libtoolize:   (GNU libtool) 2.4.2 Debian-2.4.2-1.7ubuntu1
automake: automake (GNU automake) 1.14.1
autoconf: autoconf (GNU Autoconf) 2.69
 
 Which is similar to mine, but libtoolize is slightly older (and I'm
 on x86_64-pc-linux-gnu). It turns out that the reason the build
 works on his machines is that someone had made a small manual change
 to /usr/share/aclocal/libtool.m4:
 
 --- a/libtool.m4   2014-02-11 04:58:49.0 -0800
 +++ b/libtool.m4  2015-07-31 13:48:23.375432372 -0700
 @@ -1312,7 +1312,7 @@
 rm -rf conftest*
 ;;
 
 -x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
 +x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
   s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
 # Find out which ABI we are using.
 echo 'int i;'  conftest.$ac_ext
 
 i.e. the problem looks to be that the libtool package shipped in
 debian/unstable does not support ppc64el correctly
 
 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? 

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.

And it still doesn't change the situation: we can't fix the problem
until we understand what is causing it

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793495: xfsprogs fails to build on debian ppc64el

2015-08-05 Thread Fernando Seiti Furusato 

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/dave469084 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
dpkg-buildpackage: source package xfsprogs
dpkg-buildpackage: source version 3.2.4
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Nathan Scott nath...@debian.org
 dpkg-source --before-build xfsprogs-3.2.4
dpkg-buildpackage: host architecture ppc64el
 debian/rules clean
== dpkg-buildpackage: clean
test -f debian/rules
rm -f built .census mkfs/mkfs.xfs-xfsprogs-udeb
/usr/bin/make distclean
make[1]: Entering directory '/home/xfsprogs/xfsprogs-3.2.4'
make[1]: Leaving directory '/home/xfsprogs/xfsprogs-3.2.4'
rm -rf debian/xfsprogs debian/xfslibs-dev debian/xfsprogs-udeb
rm -f debian/*substvars debian/files* debian/*.debhelper
dh_autoreconf_clean
dh_clean
	rm -f debian/xfsprogs.substvars
	rm -f debian/xfsprogs.*.debhelper
	rm -rf debian/xfsprogs/
	rm -f debian/xfslibs-dev.substvars
	rm -f debian/xfslibs-dev.*.debhelper
	rm -rf debian/xfslibs-dev/
	rm -f debian/xfsprogs-udeb.substvars
	rm -f debian/xfsprogs-udeb.*.debhelper
	rm -rf debian/xfsprogs-udeb/
	rm -f debian/*.debhelper.log
	rm -f debian/files
	find .  \( \( \
		\( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o -path .\*/.hg -o -path .\*/CVS \) -prune -o -type f -a \
	\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
		 -o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
		 -o -name '.*.orig' -o -name

Bug#793495: xfsprogs fails to build on debian ppc64el

2015-08-05 Thread Fernando Seiti Furusato 

On 08/04/2015 07:58 PM, Dave Chinner wrote:


That makes distclean do the same thing that realclean does and, as
that commit I pointed out previously, has been intentionally
separated in the build system. You could make the debian/rules file
simply call 'make realclean' rather than 'make distclean' to acheive
this without changing the main makefile. Either way, however, I
don't think that's the problem.

Yes, except I tried changing debian/rules to use realclean before coming up
with that idea and it broke the build.

 make[1]: Entering directory '/home/xfsprogs/xfsprogs-3.2.4'
 ./configure $LOCAL_CONFIGURE_OPTIONS
 configure: error: cannot find install-sh, install.sh, or shtool in . ./.
 Makefile:89: recipe for target 'include/builddefs' failed
 make[1]: *** [include/builddefs] Error 1
 make[1]: Leaving directory '/home/xfsprogs/xfsprogs-3.2.4'
 debian/rules:36: recipe for target '.census' failed
 make: *** [.census] Error 2


Darrick Wong noted on #xfs that his builds of xfsprogs on ppc64el
from a tarball don't fail at all. His libtool chain is:

When I build xfsprog on ppc64el from a tarball, it does not fail at all either.
But in my case, specifically, it is because the tarball does not come with
a configure file (which would solve the problem I pointed out), so Makefile
generates it and runs libtoolize -c -i which updates the configuration files
needed.




   host-triplet: powerpc64le-unknown-linux-gnu
   libtoolize:   (GNU libtool) 2.4.2 Debian-2.4.2-1.7ubuntu1
   automake: automake (GNU automake) 1.14.1
   autoconf: autoconf (GNU Autoconf) 2.69


Which is similar to mine, but libtoolize is slightly older (and I'm
on x86_64-pc-linux-gnu). It turns out that the reason the build
works on his machines is that someone had made a small manual change
to /usr/share/aclocal/libtool.m4:

--- a/libtool.m4   2014-02-11 04:58:49.0 -0800
+++ b/libtool.m4  2015-07-31 13:48:23.375432372 -0700
@@ -1312,7 +1312,7 @@
rm -rf conftest*
;;

-x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
+x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
  s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
# Find out which ABI we are using.
echo 'int i;'  conftest.$ac_ext

i.e. the problem looks to be that the libtool package shipped in
debian/unstable does not support ppc64el correctly


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.

IMHO, if the debian src package xfsprogs came just like it comes in 
git://oss.sgi.com/xfs/cmds/xfsprogs, ie clean, the build would not fail.


Thanks and regards.
--

Fernando Seiti Furusato
IBM Linux Technology Center


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793495: xfsprogs fails to build on debian ppc64el

2015-08-05 Thread Dave Chinner 
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/dave469084 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
da...@fromorbit.com


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793495: xfsprogs fails to build on debian ppc64el

2015-08-04 Thread Fernando Seiti Furusato 

Hi Dave.

I have just noticed that for config.guess and config.sub to be updated, no
autoreconf or dh_autotools-dev is needed, because of how Makefile was made.

In Makefile, @row 80:

 LIBTOOLIZE_INSTALL = `libtoolize -n -i /dev/null 2/dev/null  echo -i`

 configure:
 libtoolize -c $(LIBTOOLIZE_INSTALL) -f
 cp include/install-sh .
 aclocal -I m4
 autoconf

This runs libtoolize -c -i which updates those files.

The file debian/rules runs `make default`, which at some point calls the target
above (`make configure`). But the file configure already exists, so it does not
run.

Curiously, running `dpkg-buildpackage` twice, causes configure file to be
deleted, and the build completes without errors.

So, answering to your question:

 Nowdays, the generated files in the 3.2.4 tarball created via a
 'make dist' rule. I run that on an up to date debian unstable box
 with autoconfig 2.69 installed to generate the files, so the
 question I have is this: why is an up-to-date build box generating
 out of date configure/m4 scripts? What, exactly, is out of date,
 and how do I ensure that the pre-build config files are correctly
 up-to-date?

The configure file comes shipped with the debian package, so that specific file
is not re-generated and is always out of date.
By the looks of the Makefile, there is no need to include autoreconf or 
autotools-dev in debian/rules, but to force `make distclean` to `rm configure`.


Attached is a patch that summarizes that, but for some reason it does not work
when running with parallel jobs enabled. But you can get the idea :)

Regards.
--

Fernando Seiti Furusato
IBM Linux Technology Center
diff -Nru xfsprogs-3.2.4/debian/changelog 
xfsprogs-3.2.4ppc64el1/debian/changelog
--- xfsprogs-3.2.4/debian/changelog 2015-07-30 03:45:12.0 -0400
+++ xfsprogs-3.2.4ppc64el1/debian/changelog 2015-08-04 11:07:37.0 
-0400
@@ -1,3 +1,10 @@
+xfsprogs (3.2.4ppc64el1) UNRELEASED; urgency=medium
+
+  * debian/rules: removed usage of dh_autoreconf since it is not necessary.
+  * Makefile: change distclean target to remove configure every time. 
+
+ -- Fernando Seiti Furusato ferse...@br.ibm.com  Tue, 04 Aug 2015 11:07:01 
-0400
+
 xfsprogs (3.2.4) unstable; urgency=low
 
   * New upstream release
diff -Nru xfsprogs-3.2.4/debian/rules xfsprogs-3.2.4ppc64el1/debian/rules
--- xfsprogs-3.2.4/debian/rules 2014-11-09 19:51:18.0 -0500
+++ xfsprogs-3.2.4ppc64el1/debian/rules 2015-08-04 11:06:56.0 -0400
@@ -35,7 +35,6 @@
 .census:
@echo == dpkg-buildpackage: configure 12
$(checkdir)
-   AUTOHEADER=/bin/true dh_autoreconf
$(options) $(MAKE) include/platform_defs.h
touch .census
 
@@ -58,7 +57,6 @@
$(MAKE) distclean
-rm -rf $(dirme) $(dirdev) $(dirdi)
-rm -f debian/*substvars debian/files* debian/*.debhelper
-   dh_autoreconf_clean
dh_clean
 
 binary-indep:
diff -Nru xfsprogs-3.2.4/Makefile xfsprogs-3.2.4ppc64el1/Makefile
--- xfsprogs-3.2.4/Makefile 2013-10-10 17:07:16.0 -0400
+++ xfsprogs-3.2.4ppc64el1/Makefile 2015-08-04 11:06:40.0 -0400
@@ -116,7 +116,7 @@
$(Q)$(MAKE) $(MAKEOPTS) -C $* install-qa
 
 distclean: clean
-   $(Q)rm -f $(LDIRT)
+   $(Q)rm -f $(LDIRT) $(CONFIGURE)
 
 realclean: distclean
$(Q)rm -f $(CONFIGURE) .gitcensus

Bug#793495: xfsprogs fails to build on debian ppc64el

2015-08-04 Thread Dave Chinner 
On Tue, Aug 04, 2015 at 12:24:06PM -0300, Fernando Seiti Furusato wrote:
 Hi Dave.
 
 I have just noticed that for config.guess and config.sub to be updated, no
 autoreconf or dh_autotools-dev is needed, because of how Makefile was made.
 
 In Makefile, @row 80:
 
  LIBTOOLIZE_INSTALL = `libtoolize -n -i /dev/null 2/dev/null  echo -i`
 
  configure:
  libtoolize -c $(LIBTOOLIZE_INSTALL) -f
  cp include/install-sh .
  aclocal -I m4
  autoconf
 
 This runs libtoolize -c -i which updates those files.
 
 The file debian/rules runs `make default`, which at some point calls the 
 target
 above (`make configure`). But the file configure already exists, so it does 
 not
 run.

Right. Intentionally so.



 diff -Nru xfsprogs-3.2.4/Makefile xfsprogs-3.2.4ppc64el1/Makefile
 --- xfsprogs-3.2.4/Makefile   2013-10-10 17:07:16.0 -0400
 +++ xfsprogs-3.2.4ppc64el1/Makefile   2015-08-04 11:06:40.0 -0400
 @@ -116,7 +116,7 @@
   $(Q)$(MAKE) $(MAKEOPTS) -C $* install-qa
  
  distclean: clean
 - $(Q)rm -f $(LDIRT)
 + $(Q)rm -f $(LDIRT) $(CONFIGURE)
  
  realclean: distclean
   $(Q)rm -f $(CONFIGURE) .gitcensus

That makes distclean do the same thing that realclean does and, as
that commit I pointed out previously, has been intentionally
separated in the build system. You could make the debian/rules file
simply call 'make realclean' rather than 'make distclean' to acheive
this without changing the main makefile. Either way, however, I
don't think that's the problem.

Darrick Wong noted on #xfs that his builds of xfsprogs on ppc64el
from a tarball don't fail at all. His libtool chain is:

   host-triplet: powerpc64le-unknown-linux-gnu
   libtoolize:   (GNU libtool) 2.4.2 Debian-2.4.2-1.7ubuntu1
   automake: automake (GNU automake) 1.14.1
   autoconf: autoconf (GNU Autoconf) 2.69

Which is similar to mine, but libtoolize is slightly older (and I'm
on x86_64-pc-linux-gnu). It turns out that the reason the build
works on his machines is that someone had made a small manual change
to /usr/share/aclocal/libtool.m4:

--- a/libtool.m4   2014-02-11 04:58:49.0 -0800
+++ b/libtool.m4  2015-07-31 13:48:23.375432372 -0700
@@ -1312,7 +1312,7 @@
   rm -rf conftest*
   ;;

-x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
+x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
 s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
   # Find out which ABI we are using.
   echo 'int i;'  conftest.$ac_ext

i.e. the problem looks to be that the libtool package shipped in
debian/unstable does not support ppc64el correctly

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793495: xfsprogs fails to build on debian ppc64el

2015-08-02 Thread Daniel Bast 
 
 Am 02.08.2015 um 00:52 schrieb Dave Chinner da...@fromorbit.com:
 
 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 
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 
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
 da...@fromorbit.com
 
 ___
 xfs mailing list
 x...@oss.sgi.com
 http://oss.sgi.com/mailman/listinfo/xfs

Bug#793495: xfsprogs fails to build on debian ppc64el

2015-08-02 Thread Dave Chinner 
On Sun, Aug 02, 2015 at 03:06:50PM +0200, Daniel Bast wrote:
  Am 02.08.2015 um 00:52 schrieb Dave Chinner
  da...@fromorbit.com:
  
  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?

Goes back to 2009:

commit 1eb10ccb85261931d5401adbff11acd2dbc5bf63
Author: Christoph Hellwig h...@lst.de
Date:   Wed Apr 29 15:32:28 2009 +0200

keep autoconf-generated files over make distclean

We do want to ship the autoconf-generated files over make distclean and
pick them up in Makepkgs so that a user compiling the program doesn't
require autoconf.

For that split up make distclean from make realclean and exclude the
files we want to keep form the former.

To make this easier to maintain adher to stricter rules of use for
CONFIGURE and LDIRT.  CONFIGURE now includes all generated files from
autoconf (or for it like our copied install-sh) and gets only removed
on make realclean, but added to LSRCFILES so that Makepkgs can pick it
up.  Everything else than needs to be removed on a realclean gets
assigned to LDIRT.

Also split up the configure rule into one to generate the configure
script and one to run it.

Signed-off-by: Christoph Hellwig h...@lst.de
Reviewed-by: Mike Frysinger vap...@gentoo.org

So we've been doing this with release tarballs for more than 6
years - I checked and found these files in the tarballs back to
3.0.1. The above commit is the last commit prior to the release of
3.0.1...

Nowdays, the generated files in the 3.2.4 tarball created via a
'make dist' rule. I run that on an up to date debian unstable box
with autoconfig 2.69 installed to generate the files, so the
question I have is this: why is an up-to-date build box generating
out of date configure/m4 scripts? What, exactly, is out of date,
and how do I ensure that the pre-build config files are correctly
up-to-date?

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793495: xfsprogs fails to build on debian ppc64el

2015-08-01 Thread Dave Chinner 
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?

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
da...@fromorbit.com


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793495: xfsprogs fails to build on debian ppc64el

2015-07-31 Thread Daniel Bast 

Hi,

xfsprogs 3.2.4 fails to build on ppc64el, see log below or full build 
log 
https://buildd.debian.org/status/fetch.php?pkg=xfsprogsarch=ppc64elver=3.2.4stamp=1438318450

(xfsprogs 3.2.3 already failed with the same error)

What is the reason for this, libtool to old?


This potentially prevents the migration of the package to testing, which 
leaves CVE-2012-2150 open in testing on all arches.


Cheers,

Daniel


== dpkg-buildpackage: configure
test -f debian/rules
AUTOHEADER=/bin/true dh_autoreconf
find ! -ipath ./debian/* -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o 
-path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f -exec md5sum {} \; 
 debian/autoreconf.before
autoreconf -f -i
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.
find ! -ipath ./debian/* -a ! \( -path '*/.git/*' -o -path '*/.hg/*' -o 
-path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a  -type f -exec md5sum {} \; 
 debian/autoreconf.after
export DEBUG=-DNDEBUG DISTRIBUTION=debian INSTALL_USER=root INSTALL_GROUP=root 
LOCAL_CONFIGURE_OPTIONS=--enable-readline=yes --enable-blkid=yes ; 
/usr/bin/make include/platform_defs.h
make[1]: Entering directory '/«PKGBUILDDIR»'
./configure $LOCAL_CONFIGURE_OPTIONS
./config.guess: unable to guess system type

This script, last modified 2012-02-10, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

  
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
  
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD

If the version you run (./config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to config-patc...@gnu.org in order to provide the needed
information to handle your system.

config.guess timestamp = 2012-02-10

uname -m = ppc64le
uname -r = 3.16.0-4-powerpc64le
uname -s = Linux
uname -v = #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17)

/usr/bin/uname -p =
/bin/uname -X =

hostinfo   =
/bin/universe  =
/usr/bin/arch -k   =
/bin/arch  =
/usr/bin/oslevel   =
/usr/convex/getsysinfo =

UNAME_MACHINE = ppc64le
UNAME_RELEASE = 3.16.0-4-powerpc64le
UNAME_SYSTEM  = Linux
UNAME_VERSION = #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17)
configure: error: cannot guess build type; you must specify one
make[1]: *** [include/builddefs] Error 1
checking build system type... Makefile:89: recipe for target 
'include/builddefs' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
make: *** [.census] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debian/rules:36: recipe for target '.census' failed

Bug#793495: xfsprogs fails to build on debian ppc64el

2015-07-31 Thread Fernando Seiti Furusato 

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.

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.

Regards.
--

Fernando Seiti Furusato
IBM Linux Technology Center


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org