Re: Packaging SMALT for Debian
Hi Hannes,
many thanks for your quick response.
On Tue, Apr 08, 2014 at 04:07:24PM +0100, Hannes Ponstingl wrote:
> Thanks for your interest in SMALT. I have cleaned up the test
> routines for the installation/distribution somewhat with the latest
> release 0.7.6 which you can download from smalt.sourceforge.net.
Yes, this is where we are taking the source from.
> > 1. Since we always want to honour scientist work we would like to
> > add some citation information to the package metadata (you can
> > see the result when visiting the page above). Are there any
> > publications about SMALT?
> There still is no publication describing SMALT - although a number
> of high-profile papers have appeared that use it. So if you could
> mention smalt.sourceforge.net and my name and affiliation in the
> citation info. I would let you know once I have the paper accepted.
The author and homepage are usual metadata in Debian packages.
> > 2. The installation puts a set of binaries next to the main binary
> > smalt in the users path (basqcol, fetchseq, ...). Is it correct
> > that in principle only smalt is the user interface and these
> > additional binaries are only helpers called by smalt?
> > If this is the case I tend to use a wrapper script /usr/bin/smalt
> > which calls these exectuables from /usr/lib/smalt. This would
> > avoid potential name space conflicts with generic names like
> > readstats.
> Yes, smalt is the only user interface. The other binaries can be
> used to generate simulated data and to inspect files ets. They are
> undocumented and I should probably remove them from the installation
> to avoid confusion. Version 0.7.6 should have been cleaned up
> somewhat in that respect. There is no need for a wrapper and smalt
> does not call any other binaries.
OK, this simplifies things.
> > 3. What is the role of the Python script the installation procedure
> > is moving to /usr/share by default. With the exception of SAM.py
> > the scripts seem to belong to a test suite. Usually in Debian
> > Python scripts are installed in a different PATH. Is SAM.py also
> > a user application or just a helper for the smalt binary?
> The python scripts are for testing during development except for a
> number of installation test drivers *_test.py that are packaged in
> the distribution. Please refer to smalt/test/Makefile.am which is
> also the test harness (make check). Let me know if you need help
> with that.
I get the tests running now on my workstation installation. However,
when I'm running the build process in a clean chroot (which is mandatory
for a package build) I seem to miss some precondition. I have inspected
the *.py sources and guessed from
from formats import Cigar
that BioPython is needed. So I added this to the chroot but the tests
are not working better. So most probably I'm lacking some dependency
which is available on my workstation - but which one?
Also the last test is failing. I get:
PASS: splitReads_test.py
PASS: results_split_test.py
PASS: ouform_cigar_test.py
PASS: sample_test.py
PASS: cigar_test.py
PASS: mthread_test.py
ERROR when mapping: returned with code 1
FAIL: bam_cigar_test.py
=================================
1 of 7 tests failed
Please report to hp3@sanger.ac.uk
=================================
I think this might also be connected to some missing dependency.
> > 4. In Debian we try to run any test suite if available but I somehow
> > failed to find the documentation how to exactly run the full
> > test suite.
> The test suite is run with 'make check' from the distribution (make
> dist). Binaries are wrapped with python drivers in
> smalt/test/*_test.py. The harness is the automake 'make check'
> facility.
Thanks - at least the test procedure is started now.
> Please let me know if you nee more help.
I'm happy about your very constructive response.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: