[Debian-med-packaging] Bug#753485: Bug#753485: Status of samtools

Andreas Tille andreas at an3as.eu
Thu Sep 18 07:22:45 UTC 2014


Hi Charles,

On Thu, Sep 18, 2014 at 07:42:52AM +0900, Charles Plessy wrote:
> 
> Hi Andreas,
> 
> thanks for pinging the FTP team.
> 
> I have not uploaded yet samtools 1.0 to Unstable, because it strangely fails to
> build in a chroot, where two regression tests do not pass.
> 
> When comparing the logs of the building with git-buildpackage (local, works)
> and sbuild (chroot, fails), the only significant difference that I see is for
> the failure itself:
> 
> 	 test_usage_subcommand:
> 		samtools stats
> 	-.. ok
> 	+
> 	+       did not have Usage:
> 	+.. failed ...
> 	+
> 	+
> 	+       usage did not mention samtools stats
> 	+.. failed ...
> 
> I am very puzzled and for the moment I could not find any hint on why only
> these tests fail, that is: I am blocked.

Is this for the current state of Git?  I tried with this and got in a pbuilder
environment:

$ grep -B 7 "^\.\. failed ..." samtools_1.0-1_amd64.build 

test_mpileup:
        /tmp/buildd/samtools-1.0/samtools mpileup -b /tmp/QYt0ped2xw/mpileup.cram.list -f /tmp/QYt0ped2xw/mpileup.ref.fa.gz -r17:100-150

        The outputs stderr differ:
                /tmp/buildd/samtools-1.0/test/dat/mpileup.err.1
                /tmp/buildd/samtools-1.0/test/dat/mpileup.err.1.new
.. failed ...
--
        Usage on stderr rather than stdout
.. expected failure

test_usage_subcommand:
        samtools stats

        did not have Usage:
.. failed ...


        usage did not mention samtools stats
.. failed ...


I usually try to track down these things with a simple "debuild" but I
guess the versioned Build-Depends are not properly set, since the build
fails with:

...
make[2]: Entering directory '/home/andreas/debian-maintain/alioth/debian-med_git/samtools'
gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_CURSES_LIB=1 -I. -I/usr/include -D_FORTIFY_SOURCE=2 -c -o bam_index.o bam_index.c
bam_index.c: In function ‘bam_idxstats’:
bam_index.c:92:9: warning: assignment makes pointer from integer without a cast
     idx = sam_index_load(fp, argv[1]);
         ^
bam_index.c:105:5: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘int’ [-Wformat=]
     printf("*\t0\t0\t%" PRIu64 "\n", hts_idx_get_n_no_coor(idx));
     ^
make[2]: *** No rule to make target '/usr/include/htslib/khash_str2int.h', needed by 'bam_plcmd.o'.  Schluss.
make[2]: Leaving directory '/home/andreas/debian-maintain/alioth/debian-med_git/samtools'
dh_auto_build: make -j1 HTSDIR=/usr/include HTSLIB=/usr/lib/x86_64-linux-gnu/libhts.a CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security CPPFLAGS=$(DFLAGS) $(INCLUDES) -D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-z,relro LDLIBS=-lhts returned exit code 2

 
> By the way, I just saw on BioStars that we will need to patch at least TopHat
> does not work with samtools 1.0…
> 
>     https://www.biostars.org/p/112749/

You mean the patch available here:

   https://groups.google.com/forum/#!topic/tuxedo-tools-users/BVNDDmInU0A

?

We should regard this once tophat might have the slightest chance and we
have fought through seqan - bowtie* dependency hell.  Tophat did not
migrate to testing for ages which concerns me a lot. :-(

Kind regards

         Andreas.

-- 
http://fam-tille.de



More information about the Debian-med-packaging mailing list