[Debian-med-packaging] Please consider tagging librdp-readseq releases

Andreas Tille andreas at an3as.eu
Tue Mar 10 07:57:37 UTC 2015

Hi Qiong,

the delay in my response is caused by the time the first of our packages
needed to wait in the Debian new queue.  Now I've got a report from our 
ftpmaster who has the obligation to check every single piece of code for
proper licensing.  Infortunately he stumbled upon

  ReadSeq-2.0.1\src\edu\msu\cme\rdp\readseq\utils\IUBUtilities.java doesn't 
  have a proper license and is not distributable (Ryan Farris is not mentioned

(see his full mail at

Are you able to clarify the license of this file please.  (The other
issue of the missing mentioning of a GPLv2+ licensed file is just my
turn as packager and you can ignore this.)

Kind regards


On Thu, Feb 26, 2015 at 02:09:15PM -0500, Qiong Wang wrote:
> Hi Andreas,
> Glad to know it works for you. Thanks for using our tools.
> Qiong
> On Feb 25, 2015, at 4:53 PM, Andreas Tille <andreas at fam-tille.de> wrote:
> > Hi Qiong,
> > 
> > On Wed, Feb 25, 2015 at 12:31:36PM -0500, Qiong Wang wrote:
> >> I am sorry for the error messages you received during compiling. It was due to missing test files used by a Junit test. Thanks for pointing out the problem. I have updated our GitHub and tagged a new release for the affected repo. 
> > 
> > I can confirm that ReadSeq now builds nicely and the test runs fine.
> > 
> >> I encourage you to consider including our entire RDPTools module for its nice collection of tools that should be interesting to your clients. In addition to the well-know RDP Classifier, SeqMatch,  and ProbeMatch, it includes newer tools including FrameBot, a frameshift co rrection and nearest neighbor assignment tool and Xander, our latest gene-targeted metagenomic assembler tool. It also includes many important utility functions useful in microbial ecological analysis. Most of these tools have been recently published and detailed tutorials or workflow are provided on GitHub.    
> > 
> > I agree that this would be really interesting.  However, I'd like to
> > point out that the download tarball remains basically empty.  As I said
> > while we would prefer tarballs in general in principle we could also
> > deal with Git clones as a fallback.  I do not think that delivering an
> > empty tarball is a good idea.  We had some previous discussion (about a
> > different problem) on our mentors mailing list.  May be this is of any
> > help:
> > 
> >   https://lists.debian.org/debian-mentors/2014/06/msg00203.html
> > 
> > I can not promise when we will create packages of RDPTools but I can
> > confirm that I'll put it on our agenda.
> > 
> > Kind regards
> > 
> >    Andreas.
> > 
> > -- 
> > http://fam-tille.de


More information about the Debian-med-packaging mailing list