[Debian-med-packaging] Bug#836230: Bug#836230: genometools: FTBFS in testing (a2x: ERROR: "xsltproc" returned non-zero exit status 6)

[Santiago Vila]

> > 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!)

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!)

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.

(I thought this had something to do, but it seems it does not).

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

Well, I'm going to leave the reassign to you.

Just please make sure first (well, reasonably) that genometools is not
contributing to the problem before reassigning.

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.

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).

Thanks.