Bug#836230: [Debian-med-packaging] Bug#836230: genometools: FTBFS in testing (a2x: ERROR: "xsltproc" returned non-zero exit status 6)
Hi, […] > I'm not going to ask for a "mathematical proof" that the code is correct > as a condition to close the bug, but on the other hand, the fact that > it FTBFS for me not once but several times (on different machines) is > an indication that there is a bug somewhere, so if there is a bug, it > should be investigated, not closed. Point taken, maybe suggesting to close it was a bit premature. > My recommended debug procedure for this is not to build it many times > as if we were rolling a dice, but instead examine the code, examine > the build log, and try to see how such thing may happen based > on what the makefile and build system does. IMHO the question is what code to look at. The information the build log provides ends at xsltproc called by a2x and the nondescriptive error message you encountered. I admit that it can’t be ruled out that GenomeTools (or its build system) might trigger the problem by, for example, nondeterministically creating bad AsciiDoc input. I have just revisited at the GenomeTools code creating the input and I can’t see a problem; it has worked well for years for me, in Debian builds and otherwise. Another possibility would be the a2x wrapper in the strip-nondeterminism directory which wraps the call in faketime to create reproducible manpages — but given that a2x gets indeed run up to the point of calling xsltproc I’d say that’s unlikely. Doing some research on existing bugs, #753166 [1] seems to address a similar case and it was fixed by the maintainer by adding a build-dep on docbook-xml. This sounds reasonable, given that the code snippet in [2] seems to set exit code 6 when some XML file could not be read. I can add a dependency on docbook-xml to be on the safe side (up to now, docbook-xsl had been enough for me) but it’s difficult to even find out what file it’s trying to access without a means to reproduce a failure. Outside of Debian this issue [3] also seems to have popped up in an unrelated project, interestingly also with regard to manpage creation. They also state that it is 'a rare issue and can hardly be reproduced’ and only suggest as a workaround to ‘run make […] again’. Since I also have other things on my agenda ATM I will for now do an upload adding the new build dependency and fixing #836283, keeping this bug open (and a watchful eye on rebuilds in the meantime). > In many cases, a close look at the code and the way it fails leads to > the reason for the random failures. Example: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817033#15 Interesting read indeed! Anyway, thanks for noticing this and for doing regular rebuilds at all. I wasn’t meaning to discourage being inquisitive :) Cheers Sascha [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753166 [2] https://codesearch.debian.net/search?q=errorno+%3D+6+package%3Alibxslt [3] https://knowledge.windriver.com/en-us/000_Products/000/010/040/060/000/000_CGP8-291_%3A_cluster-glue_1.0.12_failed_to_compile_rarely_-_target_'hb_report.8'_failed signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#836230: [Debian-med-packaging] Bug#836230: genometools: FTBFS in testing (a2x: ERROR: "xsltproc" returned non-zero exit status 6)
On Sat, Sep 03, 2016 at 12:50:35AM +0100, Sascha Steinbiss wrote: > I must admit that I’m inclined to either close this bug or leave it > open with the comment that the issue is currently not > reproducible. At least it’s difficult to debug if I can’t get it to > fail… This reminds me of Kunth's quote: "Beware of bugs in the above code; I have only proved it correct, not tried it". I'm not going to ask for a "mathematical proof" that the code is correct as a condition to close the bug, but on the other hand, the fact that it FTBFS for me not once but several times (on different machines) is an indication that there is a bug somewhere, so if there is a bug, it should be investigated, not closed. My recommended debug procedure for this is not to build it many times as if we were rolling a dice, but instead examine the code, examine the build log, and try to see how such thing may happen based on what the makefile and build system does. In many cases, a close look at the code and the way it fails leads to the reason for the random failures. Example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817033#15 Thanks.
Bug#836230: [Debian-med-packaging] Bug#836230: genometools: FTBFS in testing (a2x: ERROR: "xsltproc" returned non-zero exit status 6)
Hi Santiago, >> Ah, this looks suspicious indeed and falls directly into the gap. (By >> the way, are these build logs available somewhere? Sounds quite useful >> to have such a build history!) > > I have put 15 different build logs here, temporarily: > > https://people.debian.org/~sanvila/genometools/genometools.tar.gz > > (I did more tests and now it does not fail anymore!) I noticed the same, I couldn’t get it to fail at all on my side, even on a VM with 512MB RAM and no swap! See https://paste.debian.net/805247/ > Here, machines called "uranio*" have 768 MB of RAM (plus 1 GB swap). > The others have 3GB RAM at least. > > Also, "Distribution: stretch" means I'm using eatmydata, while > "Distribution: stretch-keepmydata" means I'm not. Yes, doesn’t look like it’s dependent on that. Very mysterious. > Just please make sure first (well, reasonably) that genometools is not > contributing to the problem before reassigning. Sure. > For example, I set DEB_BUILD_OPTIONS = 'parallel=1' in the environment. > When a package does not honor that, it ends up using double amount of > memory without it being really necessary. This is true (and I will keep it in mind). However, the situation you mention in #836283 only affects the build-time tests, which are not likely to use a lot of memory here because they are extremely slimmed down and only act on small inputs (btw, I’m also upstream for GenomeTools). > Also, if you are calling external programs which accept command line > options to enable/disable parallel processing, make sure that no > parallel processing is happening (when DEB_BUILD_OPTIONS is setup > that way). OK. The default for these tests, for example, is to use 1 thread by default if no specific value is given. I must admit that I’m inclined to either close this bug or leave it open with the comment that the issue is currently not reproducible. At least it’s difficult to debug if I can’t get it to fail… What do you think? Cheers Sascha
Bug#836230: [Debian-med-packaging] Bug#836230: genometools: FTBFS in testing (a2x: ERROR: "xsltproc" returned non-zero exit status 6)
Hi Santiago, >>> This used to work in the past, so I would look for build-dependencies >>> which may have changed their behaviour recently. >> >> Both docbook-xsl and asciidoc, which may be the relevant build-deps here, >> didn’t have any recent uploads. > > I found a good candidate: > > https://packages.qa.debian.org/libx/libxslt.html Yup, one of these transitive dependencies... > This is the timeline: > > 2016-08-21 successful build in stretch in low memory machine > 2016-08-23 xsltproc (from source package libxslt) version 1.1.29-1 reaches > testing > 2016-08-31 failed build in stretch in a low memory machine Ah, this looks suspicious indeed and falls directly into the gap. (By the way, are these build logs available somewhere? Sounds quite useful to have such a build history!) > Should I reassign this to xsltproc, asking for the error message to be > improved? Yes please. In any case, I can't see what I could do in the genometools package: it calls a2x, which is part of asciidoc, which in turn uses xsltproc. As it seems to be the culprit, maybe their maintainer can have a look at error reporting. In any case, I will try to confirm the connection with memory shortage in any case later. Thanks, Sascha -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Bug#836230: [Debian-med-packaging] Bug#836230: genometools: FTBFS in testing (a2x: ERROR: "xsltproc" returned non-zero exit status 6)
On Wed, 31 Aug 2016, Sascha Steinbiss wrote: > > This used to work in the past, so I would look for build-dependencies > > which may have changed their behaviour recently. > > Both docbook-xsl and asciidoc, which may be the relevant build-deps here, > didn’t have any recent uploads. I found a good candidate: https://packages.qa.debian.org/libx/libxslt.html This is the timeline: 2016-08-21 successful build in stretch in low memory machine 2016-08-23 xsltproc (from source package libxslt) version 1.1.29-1 reaches testing 2016-08-31 failed build in stretch in a low memory machine Should I reassign this to xsltproc, asking for the error message to be improved? Thanks.
Bug#836230: [Debian-med-packaging] Bug#836230: genometools: FTBFS in testing (a2x: ERROR: "xsltproc" returned non-zero exit status 6)
On Thu, Sep 01, 2016 at 09:52:28AM +0100, Sascha Steinbiss wrote: > Hi Santiago, > > thanks for this useful info. > > > Status: successful genometools_1.5.9+ds-2_amd64-20160811T2351Z > > Status: successful genometools_1.5.9+ds-2_amd64-20160816T1151Z > > Status: successful genometools_1.5.9+ds-2_amd64-20160821T235102Z > > Status: failed genometools_1.5.9+ds-2_amd64-20160831T144105Z > > Status: failed genometools_1.5.9+ds-2_amd64-20160831T152720Z > > > > All those builds were done in machines with 768 MB of RAM > > (and 1GB of swap). > > > > Why it built ok in the past and now it does not build? > > Good question. It could have to do with overall memory availability on > this machine? That "has" to be the reason, because I don't have a better theory. But the only task those machines have is building packages. The timestamp for /etc/fstab is 2016-08-10, so they have used the same swap file (and therefore the same amount of swap) for all the builds. It is still unknown why it built in the past and not anymore. > Did the run you started on the machine with more memory > eventualy finish? Yes, on three other machines having 4 GB of swap and at least 3GB of RAM the build succeeded. > When I have some time I will try to reduce the amount of memory in my > building VM to find out what the critical value is. Thanks.
Bug#836230: [Debian-med-packaging] Bug#836230: genometools: FTBFS in testing (a2x: ERROR: "xsltproc" returned non-zero exit status 6)
Hi Santiago, thanks for this useful info. > Status: successful genometools_1.5.9+ds-2_amd64-20160811T2351Z > Status: successful genometools_1.5.9+ds-2_amd64-20160816T1151Z > Status: successful genometools_1.5.9+ds-2_amd64-20160821T235102Z > Status: failed genometools_1.5.9+ds-2_amd64-20160831T144105Z > Status: failed genometools_1.5.9+ds-2_amd64-20160831T152720Z > > All those builds were done in machines with 768 MB of RAM > (and 1GB of swap). > > Why it built ok in the past and now it does not build? Good question. It could have to do with overall memory availability on this machine? Did the run you started on the machine with more memory eventualy finish? When I have some time I will try to reduce the amount of memory in my building VM to find out what the critical value is. Cheers Sascha -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Bug#836230: [Debian-med-packaging] Bug#836230: genometools: FTBFS in testing (a2x: ERROR: "xsltproc" returned non-zero exit status 6)
This is my build history: Status: successful genometools_1.5.9+ds-2_amd64-20160811T2351Z Status: successful genometools_1.5.9+ds-2_amd64-20160816T1151Z Status: successful genometools_1.5.9+ds-2_amd64-20160821T235102Z Status: failed genometools_1.5.9+ds-2_amd64-20160831T144105Z Status: failed genometools_1.5.9+ds-2_amd64-20160831T152720Z All those builds were done in machines with 768 MB of RAM (and 1GB of swap). Why it built ok in the past and now it does not build?
Bug#836230: [Debian-med-packaging] Bug#836230: genometools: FTBFS in testing (a2x: ERROR: "xsltproc" returned non-zero exit status 6)
severity 836230 normal retitle 836230 FTBFS in a low memory machine with poor error message thanks On Wed, Aug 31, 2016 at 10:10:40PM +0100, Sascha Steinbiss wrote: > > I tried to build this package in stretch with "dpkg-buildpackage -A" > > (which is what the "Arch: all" autobuilder would do to build it) > > but it failed: > […] > > a2x: ERROR: "xsltproc" --stringparam callout.graphics 0 --stringparam > > navig.graphics 0 --stringparam admon.textlabel 1 --stringparam > > admon.graphics 0 "/etc/asciidoc/docbook-xsl/manpage.xsl" > > "/<>/genometools-1.5.9+ds/doc/manpages/gt.xml" returned non-zero > > exit > > Unfortunately, I can not reproduce this. For me the package builds with no > problem (-A and -B with gbp-buildpackage and cowbuilder in a freshly updated > stretch chroot). Build logs can be found at > http://dropbox.tetrinetsucht.de/debian/ (too large for paste.debian.net). > > > This used to work in the past, so I would look for build-dependencies > > which may have changed their behaviour recently. > > Both docbook-xsl and asciidoc, which may be the relevant build-deps here, > didn’t have any recent uploads. > > I am wondering if anyone may have any hints? Sorry, I thought this was easily reproducible because it happened in two different machines. But now I see that the two machines have 768 MB of RAM. I'm now building on machines with more memory, and so far it does not seem to fail when I have 3GB of RAM. To reproduce, please try building on a machine with only 768 MB of RAM. If that's the reason for the build failure, then the problem is that the build does not say "out of memory" or anything like that. Instead it says "exit status 6" which does not help very much to know what exactly went wrong. Thanks.
Bug#836230: [Debian-med-packaging] Bug#836230: genometools: FTBFS in testing (a2x: ERROR: "xsltproc" returned non-zero exit status 6)
Hi Santiago, thanks for reporting this. > I tried to build this package in stretch with "dpkg-buildpackage -A" > (which is what the "Arch: all" autobuilder would do to build it) > but it failed: […] > a2x: ERROR: "xsltproc" --stringparam callout.graphics 0 --stringparam > navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics > 0 "/etc/asciidoc/docbook-xsl/manpage.xsl" > "/<>/genometools-1.5.9+ds/doc/manpages/gt.xml" returned non-zero > exit Unfortunately, I can not reproduce this. For me the package builds with no problem (-A and -B with gbp-buildpackage and cowbuilder in a freshly updated stretch chroot). Build logs can be found at http://dropbox.tetrinetsucht.de/debian/ (too large for paste.debian.net). > This used to work in the past, so I would look for build-dependencies > which may have changed their behaviour recently. Both docbook-xsl and asciidoc, which may be the relevant build-deps here, didn’t have any recent uploads. I am wondering if anyone may have any hints? Cheers Sascha signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#836230: genometools: FTBFS in testing (a2x: ERROR: "xsltproc" returned non-zero exit status 6)
Package: src:genometools Version: 1.5.9+ds-2 Severity: serious Dear maintainer: I tried to build this package in stretch with "dpkg-buildpackage -A" (which is what the "Arch: all" autobuilder would do to build it) but it failed: [...] debian/rules build-indep dh build-indep --with python2 dh_testdir -i dh_update_autotools_config -i dh_auto_configure -i debian/rules override_dh_auto_build make[1]: Entering directory '/<>/genometools-1.5.9+ds' faketime -f "`TZ=UTC date -d @1469271266 +'%Y-%m-%d %H:%M:%S'`" dh_auto_build -- useshared=yes x32=no 64bit=yes errorcheck=no all docs manuals make -j1 useshared=yes x32=no 64bit=yes errorcheck=no all docs manuals make[2]: Entering directory '/<>/genometools-1.5.9+ds' [create obj/gt_config.h] [compile alphabet.o] [compile array.o] [... snipped ...] cp -r gtdata /<>/genometools-1.5.9+ds/debian/tmp/usr/bin test -d /<>/genometools-1.5.9+ds/debian/tmp/usr/include/genometools/core \ || mkdir -p /<>/genometools-1.5.9+ds/debian/tmp/usr/include/genometools/core cp src/core/*_api.h /<>/genometools-1.5.9+ds/debian/tmp/usr/include/genometools/core test -d /<>/genometools-1.5.9+ds/debian/tmp/usr/include/genometools/extended \ || mkdir -p /<>/genometools-1.5.9+ds/debian/tmp/usr/include/genometools/extended cp src/extended/*_api.h /<>/genometools-1.5.9+ds/debian/tmp/usr/include/genometools/extended test -d /<>/genometools-1.5.9+ds/debian/tmp/usr/include/genometools/annotationsketch \ || mkdir -p /<>/genometools-1.5.9+ds/debian/tmp/usr/include/genometools/annotationsketch cp src/annotationsketch/*_api.h \ /<>/genometools-1.5.9+ds/debian/tmp/usr/include/genometools/annotationsketch test -d /<>/genometools-1.5.9+ds/debian/tmp/usr/include/genometools/ltr \ || mkdir -p /<>/genometools-1.5.9+ds/debian/tmp/usr/include/genometools/ltr cp src/ltr/*_api.h /<>/genometools-1.5.9+ds/debian/tmp/usr/include/genometools/ltr cp obj/gt_config.h /<>/genometools-1.5.9+ds/debian/tmp/usr/include/genometools cp src/genometools.h /<>/genometools-1.5.9+ds/debian/tmp/usr/include/genometools test -d /<>/genometools-1.5.9+ds/debian/tmp/usr/lib || mkdir -p /<>/genometools-1.5.9+ds/debian/tmp/usr/lib cp lib/libgenometools.a /<>/genometools-1.5.9+ds/debian/tmp/usr/lib cp lib/libgenometools.so.0 /<>/genometools-1.5.9+ds/debian/tmp/usr/lib ln -fs /<>/genometools-1.5.9+ds/debian/tmp/usr/lib/libgenometools.so.0 /<>/genometools-1.5.9+ds/debian/tmp/usr/lib/libgenometools.so [build config script install] sed -e 's!@CC@!cc!' -e 's!@CFLAGS@!-g -O2 -fdebug-prefix-map=/<>/genometools-1.5.9+ds=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security!' \ -e 's!@CPPFLAGS@!-I\\"/<>/genometools-1.5.9+ds/debian/tmp/usr/include\\" -Wdate-time -D_FORTIFY_SOURCE=2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_MEMMOVE -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DLUA_DL_DLOPEN -DLUA_USE_MKSTEMP -DHAVE_SQLITE!' \ -e 's!@CXX@!g++!' -e 's!@CXXFLAGS@!-g -O2 -fdebug-prefix-map=/<>/genometools-1.5.9+ds=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security!' \ -e 's!@LDFLAGS@!-L/<>/genometools-1.5.9+ds/debian/tmp/usr/lib -fPIE -pie -Wl,-z,relro -Wl,-z,now -L/usr/local/lib!' \ -e 's!@LIBS@! -lm -lbz2 -lz -lexpat -llua5.1 -llua5.1-lpeg -llua5.1 -llua5.1-md5 -llua5.1 -llua5.1-filesystem -llua5.1 -llua5.1-des56 -llua5.1 -lbam -ltre -Wl,-z,relro -lm -lpthread -ldl -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lcairo -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lcairo -lsqlite3!' -e "s!@VERSION@!`cat VERSION`!" \ -e 's!@BUILDSTAMP@!"2016-08-31 16:47:11"!' \ -e 's!@SYSTEM@!Linux!' /<>/genometools-1.5.9+ds/debian/tmp/usr/bin/genometools-config chmod 755 /<>/genometools-1.5.9+ds/debian/tmp/usr/bin/genometools-config bin/gt -createman /tmp/gtmanpages warning: skipping tool 'mgth' in iterator (not a GtTool object) warning: skipping tool 'mkfmindex' in iterator (not a GtTool object) warning: skipping tool 'suffixerator' in iterator (not a GtTool object) warning: skipping tool 'chkintegrity' in iterator (not a GtTool object) warning: skipping tool 'chksearch' in iterator (not a GtTool object) warning: skipping tool 'mkctxmap' in iterator (not a GtTool object) warning: skipping tool 'mkindex' in iterator (not a GtTool object) warning: skipping tool 'trsuftab' in iterator (not a GtTool object) test -d /<>/genometools-1.5.9+ds/doc/manpages || mkdir -p /<>/genometools-1.5.9+ds/doc/manpages rm -f /<>/genometools-1.5.9+ds/doc/manpages/* scripts/create_manpages /tmp/gtmanpages /<>/genometools-1.5.9+ds/doc/manpages .a2x: WARNING: --destination-dir option is only applicable to HTML based outputs a2x: ERROR: "xsltproc" --stringparam callout.graphics 0 --stringparam navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 "/etc/asciidoc/docbook-xsl/manpage.xsl" "/<>/genometools-1.5.9+ds/doc/manpages/gt.xml" returned
