[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Reply to: