[Debian-med-packaging] bedtools autopkgtest fails due to missing htsutil

John Marshall John.W.Marshall at glasgow.ac.uk
Tue Dec 22 14:40:29 GMT 2020


On 22 Dec 2020, at 12:59, Andreas Tille <andreas at an3as.eu> wrote:
> your patch[1] makes use of a tool htsutil that is build from
> htsutil.cpp.  Unfortunately this does not exist any more.

htsutil.cpp was introduced by my upstream PR #818 [1] and exists on master and will be present in future bedtools releases, but appeared after the 2.92.2 release. Michael Crusoe backported this PR to your packaging of 2.92.2 as patches/no-samtools; I don't recall being involved with that.

The htsutil executable is not installed alongside the bedtools executable as it is not of interest to users -- instead it's just used when running bedtools's tests via "make test". Hence it would appear that the way to get it to appear on your autopkgtest environment would be to have the htsutil executable installed by the bedtools-test package (in the same directory alongside /usr/share/bedtools/test/test.sh perhaps). (Currently debian/rules explicitly deletes(!) the htsutil executable to prevent it from being packaged into the main bedtools package.)

This perhaps answers a question I have about Debian's htslib-test package. Is the purpose of packages like bedtools-test and htslib-test essentially purely to be a mechanism for getting test data and scripts onto your autopkgtest systems? There's no particular expectation that end users would ever want to install these packages themselves?

> Simply skipping those patches would be the only clue I have for the moment.

If you skip the patch you will rediscover why I made the PR and why Michael backported it: the bedtools test suite does not work with samtools >= 1.10 due to its view command emitting an @PG header by default.

   John


[1] https://github.com/arq5x/bedtools2/pull/818



More information about the Debian-med-packaging mailing list