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
