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

Sascha Steinbiss satta at debian.org
Fri Sep 2 23:50:35 UTC 2016


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


More information about the Debian-med-packaging mailing list