Bug#806654: libtool: FTBFS when built with dpkg-buildpackage -A
On Sat, Aug 06, 2016 at 08:49:24PM +0200, Kurt Roeckx wrote: > Version: 2.4.6-1 > > On Sat, Aug 06, 2016 at 07:11:50PM +0200, Santiago Vila wrote: > > On Sat, Aug 06, 2016 at 05:57:20PM +0200, Kurt Roeckx wrote: > > > > > 2.4.6-0.1 builds fine for me using -A. > > > > Please provide a build log for any of your successful > > "dpkg-buildpackage -A" builds of libtool 2.4.6-0.1 in stretch. > > That was stupid of me. Not wanting to wait for the test suite, it > takes a long time, I skipped the test suite. And of course the > problem you reported was that that test suite gave errors. > > So I could reproduce it with 2.4.6-0.1 but not with 2.4.6-1. Finally. Thank you.
Bug#806654: libtool: FTBFS when built with dpkg-buildpackage -A
On Sat, Aug 06, 2016 at 05:57:20PM +0200, Kurt Roeckx wrote: > 2.4.6-0.1 builds fine for me using -A. Please provide a build log for any of your successful "dpkg-buildpackage -A" builds of libtool 2.4.6-0.1 in stretch. Thanks.
Bug#806654: libtool: FTBFS when built with dpkg-buildpackage -A
On Tue, Aug 02, 2016 at 01:04:31AM +0200, Santiago Vila wrote: > On Mon, 1 Aug 2016, Kurt Roeckx wrote: > > > Can you still reproduce the problem? I see you marked it as RC > > now, but the buildds actually build it succesful. > > I raised to serious because I raised to serious all the bugs that were > still open. > > Sorry if I answer your question by making another one: > > Are you still unable to reproduce the problem with the previous version? I can reproduce your original issue about version.texi not being found in the 2.4.2-1.11 version when you try to build it using -A. That is, I can reproduce your original issue, not the one you reported afterwards. Like you said yourself, this issue was fixed already in 2.4.6-0.1 and you can't reproduce that anymore. 2.4.6-0.1 builds fine for me using -A. 2.4.6-1 even builds fine on the buildds. But you didn't try -1 yet afaik. This might solve the problem with your setup, or not. Kurt
Bug#806654: libtool: FTBFS when built with dpkg-buildpackage -A
On Mon, 1 Aug 2016, Kurt Roeckx wrote: > Can you still reproduce the problem? I see you marked it as RC > now, but the buildds actually build it succesful. I raised to serious because I raised to serious all the bugs that were still open. Sorry if I answer your question by making another one: Are you still unable to reproduce the problem with the previous version? See, I don't want to see this bug closed if I'm the only one able to reproduce it with the previous version, because in such case there would still be a problem somewhere (even if it's in another unrelated package) and we could not consider the bug solved. So: Could you please try "dpkg-buildpackage -A" on both the previous version and the current one (in your own computer) and compare the results? Thanks.
Bug#806654: libtool: FTBFS when built with dpkg-buildpackage -A
On Mon, Jul 25, 2016 at 08:31:02PM +0200, Kurt Roeckx wrote: > On Mon, Jul 25, 2016 at 07:36:55PM +0200, Santiago Vila wrote: > > On Mon, 25 Jul 2016, Kurt Roeckx wrote: > > > > > The error you get is a testsuite failure. It outputs this to > > > stderr: > > > ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be > > > preloaded (cannot open shared object file): ignored. > > > > > > And then the testsuite fails because it wasn't expecting any > > > output on stderr. > > > > > > Anyway, this seems like a setup problem, not a problem with the > > > package, and cleary unrelated to using -A. > > > > Well, it only happens when using -A, so it's clearly related. > > > > I already explained the reason: Because of the way debian/rules is > > written, the test suite runs as root when built with "dpkg-buildpackage -A". > > So that should have been fixed i the upload I did earlier today. Can you still reproduce the problem? I see you marked it as RC now, but the buildds actually build it succesful. Kurt
Bug#806654: libtool: FTBFS when built with dpkg-buildpackage -A
On Mon, Jul 25, 2016 at 07:36:55PM +0200, Santiago Vila wrote: > On Mon, 25 Jul 2016, Kurt Roeckx wrote: > > > The error you get is a testsuite failure. It outputs this to > > stderr: > > ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be > > preloaded (cannot open shared object file): ignored. > > > > And then the testsuite fails because it wasn't expecting any > > output on stderr. > > > > Anyway, this seems like a setup problem, not a problem with the > > package, and cleary unrelated to using -A. > > Well, it only happens when using -A, so it's clearly related. > > I already explained the reason: Because of the way debian/rules is > written, the test suite runs as root when built with "dpkg-buildpackage -A". So that should have been fixed i the upload I did earlier today. Kurt
Bug#806654: libtool: FTBFS when built with dpkg-buildpackage -A
On Mon, 25 Jul 2016, Kurt Roeckx wrote: > the thing > mentioned in this bug seems to have been fixed and works for me. > [...] > I just think the reason this bug was opened is already fixed. This bug was opened because "dpkg-buildpackage -A" does not work. It did not work before, and it still does not work (but for a different reason). If you really feel this "different reason" is enough to close this report and open a new one, I will gladly open a new one if it makes you to feel better. But IMHO, this would not be practical, because my intent was always to report an effect (failing "dpkg-buildpackage -A"), not a cause. Thanks.
Bug#806654: libtool: FTBFS when built with dpkg-buildpackage -A
On Mon, 25 Jul 2016, Kurt Roeckx wrote: > The error you get is a testsuite failure. It outputs this to > stderr: > ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be > preloaded (cannot open shared object file): ignored. > > And then the testsuite fails because it wasn't expecting any > output on stderr. > > Anyway, this seems like a setup problem, not a problem with the > package, and cleary unrelated to using -A. Well, it only happens when using -A, so it's clearly related. I already explained the reason: Because of the way debian/rules is written, the test suite runs as root when built with "dpkg-buildpackage -A". Then it fails because there is some sort of conflict with fakeroot. But this is a bug in debian/rules for running the test suite as root, not a setup problem. If you do not believe that the test suite runs as root when built with "dpkg-buildpackage -A", try this simple patch: --- a/debian/rules +++ b/debian/rules @@ -132,6 +132,8 @@ build-stamp: config-stamp ifeq ($(make_check), yes) # Now make sure it works + echo I am `whoami` + false -$(MAKE) check || touch tests-failed -cat test-suite.log -cat tests/testsuite.log and then try "dpkg-buildpackage -A". You will see "I am root".
Bug#806654: libtool: FTBFS when built with dpkg-buildpackage -A
On Mon, Jul 25, 2016 at 04:47:12PM +0200, Santiago Vila wrote: > [ Cc:ing Matthias, as he did the last NMUs for this package ] > > On Mon, 25 Jul 2016, Kurt Roeckx wrote: > > > I can't reproduce this. [...] > > Indeed, the error you quoted does not happen anymore, but the package > still would not autobuild in the "Arch: all" autobuilder. > > Please note that this bug is about "dpkg-buildpackge -A" not working. > > I think the error is somewhere in debian/rules. Let's take a look: > > > build: build-arch build-indep > > build-arch: build-stamp > build-stamp: config-stamp > [ standard package build ] > > So far, so good. > > build-indep: build-indep-stamp > build-indep-stamp: > # This generated HTML page goes into libtool-doc. > cd doc && $(MAKEINFO) libtool.texi > cd doc && $(MAKEINFO) --html --no-split libtool.texi > touch build-indep-stamp > > So far, so good. > > Based on this, it's clear that there is an *intent* to split the build > between build-arch and build-indep. > > The binary-* targets, however, seem to "spoil" this intent: > > install: build > [ rules to install things in debian/tmp ] > > binary-indep: build-indep install > [ rules to create arch-independent packages ] > > binary-arch: build-arch install > [ rules to create arch-dependent packages ] > > See the problem? > > Target "binary-indep" depends on "install", "install" depends on > "build". Target "build" builds everything, so the "split" > does not really work because trying to create only arch-independent packages > ends up building everything. I actually fixed all this yesterday, started writing all of this, and then decided to remove it and just say that the thing mentioned in this bug seems to have been fixed and works for me. Anyway, there has been a bunch on NMUs (like 12) in which they changed "libtool" from an arch any to an arch all package, and have the libtool-bin package as the binary arch package. But everything that was in the build-arch target is something I actually want to run all the time now, including the test suite. So I moved everything to a build target and have build-indep and build-arch depend on it. > This didn't work because some files disappear. (See debdiff in the > second attach). Those files are in debian/libtool.install but we can't > use dh_install because the files simply do not exist. I was still working on this yesterday evening. The bootstrap thing generates a ChangeLog file based on git, which ends up empty ... So there are things I'm working on, I just think the reason this bug was opened is already fixed. Kurt
Bug#806654: libtool: FTBFS when built with dpkg-buildpackage -A (@include: could not find version.texi)
On Mon, Jul 25, 2016 at 12:39:27AM +0100, Santiago Vila wrote: > retitle 806654 libtool: FTBFS in stretch when built with "dpkg-buildpackage > -A" > thanks > > On Mon, Jul 25, 2016 at 12:18:09AM +0200, Kurt Roeckx wrote: > > > > libtool.texi:553: warning: undefined flag: VERSION > > > libtool.texi:586: warning: undefined flag: VERSION > > > libtool.texi:2097: warning: undefined flag: VERSION > > > debian/rules:153: recipe for target 'build-indep-stamp' failed > > > make: *** [build-indep-stamp] Error 1 > > > dpkg-buildpackage: error: debian/rules build-indep gave error exit status > > > 2 > > > > > > > I can't reproduce this. This might have been fixed in 2.4.6-0.1 > > with: > > * Build-depend on texinfo needed by bootstrap. > > The error is now quite different, but it still fails for me every time I try: The error you get is a testsuite failure. It outputs this to stderr: ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. And then the testsuite fails because it wasn't expecting any output on stderr. Anyway, this seems like a setup problem, not a problem with the package, and cleary unrelated to using -A. Kurt
Bug#806654: libtool: FTBFS when built with dpkg-buildpackage -A
[ Cc:ing Matthias, as he did the last NMUs for this package ]
On Mon, 25 Jul 2016, Kurt Roeckx wrote:
> I can't reproduce this. [...]
Indeed, the error you quoted does not happen anymore, but the package
still would not autobuild in the "Arch: all" autobuilder.
Please note that this bug is about "dpkg-buildpackge -A" not working.
I think the error is somewhere in debian/rules. Let's take a look:
build: build-arch build-indep
build-arch: build-stamp
build-stamp: config-stamp
[ standard package build ]
So far, so good.
build-indep: build-indep-stamp
build-indep-stamp:
# This generated HTML page goes into libtool-doc.
cd doc && $(MAKEINFO) libtool.texi
cd doc && $(MAKEINFO) --html --no-split libtool.texi
touch build-indep-stamp
So far, so good.
Based on this, it's clear that there is an *intent* to split the build
between build-arch and build-indep.
The binary-* targets, however, seem to "spoil" this intent:
install: build
[ rules to install things in debian/tmp ]
binary-indep: build-indep install
[ rules to create arch-independent packages ]
binary-arch: build-arch install
[ rules to create arch-dependent packages ]
See the problem?
Target "binary-indep" depends on "install", "install" depends on
"build". Target "build" builds everything, so the "split"
does not really work because trying to create only arch-independent packages
ends up building everything.
(I also fear that the build-indep target is executed as a normal user,
then the binary-indep target is executed as root, which makes the whole
build process to be executed by root. This might have something to do
with the fact that it fails, but I'm not sure).
I tried to fix this by dropping "install" as a dependency for
binary-indep. I found a problem with the symlinks so I decided
to use dh_link and debian/libtool.links instead.
(See patch in the first attach).
This didn't work because some files disappear. (See debdiff in the
second attach). Those files are in debian/libtool.install but we can't
use dh_install because the files simply do not exist.
At this point, I can only suggest two possible fixes:
1. Make "libtool" package to be "Arch: any".
2. Build the package the traditional way:
build-arch: build
build-indep: build
build:
[ Build everything ]
Thanks.diff --git a/debian/libtool.links b/debian/libtool.links
new file mode 100644
index 000..920f0e9
--- /dev/null
+++ b/debian/libtool.links
@@ -0,0 +1,2 @@
+usr/share/misc/config.guess usr/share/libtool/build-aux/config.guess
+usr/share/misc/config.sub usr/share/libtool/build-aux/config.sub
diff --git a/debian/rules b/debian/rules
index c9ff1ff..1e71df3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -161,16 +161,10 @@ install: build
--fail-missing --sourcedir=debian/tmp
# Build architecture-independent files here.
-binary-indep: build-indep install
+binary-indep: build-indep
dh_testdir -i
dh_testroot -i
- # Create symlinks to the one in autotools-dev
- rm -f debian/libtool/usr/share/libtool/build-aux/config.guess
- ln -s ../../misc/config.guess debian/libtool/usr/share/libtool/build-aux
- rm -f debian/libtool/usr/share/libtool/build-aux/config.sub
- ln -s ../../misc/config.sub debian/libtool/usr/share/libtool/build-aux
-
dh_installdocs -i
dh_installinfo -plibtool-doc
dh_installexamples -i
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/share/aclocal/libtool.m4
-rw-r--r-- root/root /usr/share/aclocal/ltargz.m4
-rw-r--r-- root/root /usr/share/aclocal/ltoptions.m4
-rw-r--r-- root/root /usr/share/aclocal/ltsugar.m4
-rw-r--r-- root/root /usr/share/aclocal/ltversion.m4
-rw-r--r-- root/root /usr/share/aclocal/lt~obsolete.m4
-rw-r--r-- root/root /usr/share/libtool/build-aux/ltmain.sh
-rw-r--r-- root/root /usr/share/man/man1/libtoolize.1.gz
-rwxr-xr-x root/root /usr/bin/libtoolize
-rwxr-xr-x root/root /usr/share/libtool/build-aux/compile
-rwxr-xr-x root/root /usr/share/libtool/build-aux/depcomp
-rwxr-xr-x root/root /usr/share/libtool/build-aux/install-sh
-rwxr-xr-x root/root /usr/share/libtool/build-aux/missing
Control files: lines which differ (wdiff format)
Installed-Size: [-894-] {+60+}
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/share/info/libtool.info-1.gz
-rw-r--r-- root/root /usr/share/info/libtool.info-2.gz
-rw-r--r-- root/root /usr/share/info/libtool.info.gz
Control files: lines which differ (wdiff format)
Installed-Size: [-712-] {+613+}
Bug#806654: libtool: FTBFS when built with dpkg-buildpackage -A (@include: could not find version.texi)
retitle 806654 libtool: FTBFS in stretch when built with "dpkg-buildpackage -A" thanks On Mon, Jul 25, 2016 at 12:18:09AM +0200, Kurt Roeckx wrote: > > libtool.texi:553: warning: undefined flag: VERSION > > libtool.texi:586: warning: undefined flag: VERSION > > libtool.texi:2097: warning: undefined flag: VERSION > > debian/rules:153: recipe for target 'build-indep-stamp' failed > > make: *** [build-indep-stamp] Error 1 > > dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2 > > > > I can't reproduce this. This might have been fixed in 2.4.6-0.1 > with: > * Build-depend on texinfo needed by bootstrap. The error is now quite different, but it still fails for me every time I try: Status: attempted libtool_2.4.6-0.1_amd64-20160213-1207 Status: attempted libtool_2.4.6-0.1_amd64-20160302-1319 Status: attempted libtool_2.4.6-0.1_amd64-20160321-2228 Status: attempted libtool_2.4.6-0.1_amd64-20160505-1253 Status: attempted libtool_2.4.6-0.1_amd64-20160526-1139 Status: attempted libtool_2.4.6-0.1_amd64-20160621-1424 Status: attempted libtool_2.4.6-0.1_amd64-20160725-0113 I attach the last build log. I also attach a small collection of testsuite.log files I could rescue before compilation ended and sbuild removed everything. Hope this helps. libtool_2.4.6-0.1_amd64-20160725-0113.gz Description: application/gzip 57.tgz Description: application/gtar-compressed
Bug#806654: libtool: FTBFS when built with dpkg-buildpackage -A (@include: could not find version.texi)
On Sun, Nov 29, 2015 at 08:25:03PM +, Santiago Vila wrote: > Package: src:libtool > Version: 2.4.2-1.11 > User: sanv...@debian.org > Usertags: binary-indep > Severity: important > > Dear maintainer: > > I tried to build this package with "dpkg-buildpackage -A" > (i.e. only architecture-independent packages), and it failed: > > > [...] > debian/rules build-indep > cd doc && makeinfo libtool.texi > libtool.texi:9: @include: could not find version.texi > libtool.texi:27: warning: undefined flag: VERSION > libtool.texi:48: warning: undefined flag: VERSION > libtool.texi:48: warning: undefined flag: UPDATED > libtool.texi:82: warning: undefined flag: VERSION > libtool.texi:553: warning: undefined flag: VERSION > libtool.texi:586: warning: undefined flag: VERSION > libtool.texi:2097: warning: undefined flag: VERSION > debian/rules:153: recipe for target 'build-indep-stamp' failed > make: *** [build-indep-stamp] Error 1 > dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2 > I can't reproduce this. This might have been fixed in 2.4.6-0.1 with: * Build-depend on texinfo needed by bootstrap. So we should probably just close this. Kurt
Bug#806654: libtool: FTBFS when built with dpkg-buildpackage -A (@include: could not find version.texi)
Greetings. I have the ok from the Release Managers to consider this issue as RC for stretch. I'm going to wait at least one week before raising this to "serious". If you need help to fix this bug, please tag it as "help". Thanks.
Bug#806654: libtool: FTBFS when built with dpkg-buildpackage -A (@include: could not find version.texi)
Package: src:libtool Version: 2.4.2-1.11 User: sanv...@debian.org Usertags: binary-indep Severity: important Dear maintainer: I tried to build this package with "dpkg-buildpackage -A" (i.e. only architecture-independent packages), and it failed: [...] debian/rules build-indep cd doc && makeinfo libtool.texi libtool.texi:9: @include: could not find version.texi libtool.texi:27: warning: undefined flag: VERSION libtool.texi:48: warning: undefined flag: VERSION libtool.texi:48: warning: undefined flag: UPDATED libtool.texi:82: warning: undefined flag: VERSION libtool.texi:553: warning: undefined flag: VERSION libtool.texi:586: warning: undefined flag: VERSION libtool.texi:2097: warning: undefined flag: VERSION debian/rules:153: recipe for target 'build-indep-stamp' failed make: *** [build-indep-stamp] Error 1 dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2 Sorry not to have a fix, as I am reporting many bugs similar to this one. The common hints are: * If the only architecture-independent packages are dummy transitional ones and they were released with jessie, the easy fix is to drop them now. * When using "dh", it is allowed to use (independently) optional targets override_dh_foo-arch and override_dh_foo-indep (for several values of "foo"). Once that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work properly, the package would be suitable to be uploaded in source-only form if you wish. Thanks.
