Re: Update on Trinityrnaseq packaging

[Andreas Tille]

Hi Michael,

On Tue, Feb 24, 2015 at 03:03:16PM +, Michael Crusoe wrote:
> >
> > I admit that I became optimistic after the latest discussion, that we
> > have good chances to see libcolt-java in main in a sensible time frame
> > (3-6 monthes ??).  I'm definitely not sure about libjai-core-java.  Do
> > You see chances to extract this dependency as well?
> >
> 
> Ah, okay. I'll keep the libcolt-java on the contrib side.

I hope you noticed that there is now a libcolt-free-java package which
should work as a libcolt-java (from non-free) package.
 
> I have no plans on finding a Free replacement for libjai-core-java; related
> classes will also be part of the libjung-contrib-java source and binary
> package.

There also seems to be some hope for a libjai replacement:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715530#50

Would you volunteer to check whether these replacements will work with
libjung?

BTW, I noticed tham rsem and prokka which you commited to Git do not
seem to have any blocking issues in principle.  Rsem might need some
polishing regarding propagating of hardening options and perhaps some
help2man based manpages.  Prokka does not have a proper pristine-tar
for the version mentioned in d/changelog.

Could you gice an update about your plans with these packages?

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150415110041.ge...@an3as.eu

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Emmanuel Bourg]

Le 03/03/2015 17:17, Andreas Tille a écrit :

> To make sure we will not loose track here:  Could you provide either a
> tarball of the freehep-aida source (or a rule how you did created it)?
> I'd volunteer to spend some time into the packaging but I'm afraid I
> might pick the wrong code and thus I'd like to be sure to get the one
> your did the successful experiment.

Hi Andreas,

I described all the changes I made in my previous mail. It's as simple
as removing the files I mentioned and modifying the toString() and
viewSorted() methods in the DoubleMatrix{1,2,3}D and Property classes.
This gives a codebase with no dependency on the classes not found in
freehep, but you still have to replace the remaining src/hep/aida files
with the equivalent ones from freehep.

Emmanuel Bourg


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54f5e0c2.7080...@apache.org

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Andreas Tille]

Hi again,

On Sun, Feb 22, 2015 at 10:59:02PM +0100, Andreas Tille wrote:
> 
> > At this point I think freehep aida/jaida should be packaged, then a new
> > colt-free package could be created using freehep-aida and the
> > modifications I made. This will allow you to free at least 3 packages
> > from contrib.
> 
> This sounds very promising.  Would you mind commiting the results of
> your experiment to the Git repository of colt which I just created.  Is
> there any volunteer for packaging freehep-aida?  If not I could try to
> do my best to at least give it a try (but I admit I would be even more
> happy if somebody else would do it ;-)).

To make sure we will not loose track here:  Could you provide either a
tarball of the freehep-aida source (or a rule how you did created it)?
I'd volunteer to spend some time into the packaging but I'm afraid I
might pick the wrong code and thus I'd like to be sure to get the one
your did the successful experiment.

So if you could share the work you did in some form I'd be happy to
work into this direction.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150303161736.gh26...@an3as.eu

Re: Update on Trinityrnaseq packaging

[Michael Crusoe]

On Tue Feb 24 2015 at 2:23:26 AM Andreas Tille  wrote:

> Hi Michael,
>
> On Mon, Feb 23, 2015 at 10:37:43PM +, Michael Crusoe wrote:
> > > To explain the problem:  We need to build the package in the main
> > > universe and the build-dependency libcolt-java is missing there.  I
> > > tried to simply drop this build-dependency (+libjai-core-java) and
> > > looked what happened.  I tried this approach and it might be possible
> > > with some heavier patching but the very simple try failed.
> > >
> > > BTW, the situation is even worse since libjai-core-java is non-free and
> > > previous discussion have shown that chances are close to zero to get
> > > this old SUN code freed.  There were some opinions raised that there
> are
> > > better imaging libraries which could replace JAI but my question to
> more
> > > details were not answered.
> > >
> > >
> > Okay. I'll split the source packages. Shall I assume that colt is going
> to
> > end up in main?
>
> I admit that I became optimistic after the latest discussion, that we
> have good chances to see libcolt-java in main in a sensible time frame
> (3-6 monthes ??).  I'm definitely not sure about libjai-core-java.  Do
> You see chances to extract this dependency as well?
>

Ah, okay. I'll keep the libcolt-java on the contrib side.

I have no plans on finding a Free replacement for libjai-core-java; related
classes will also be part of the libjung-contrib-java source and binary
package.

Re: Update on Trinityrnaseq packaging

[Andreas Tille]

Hi Michael,

On Mon, Feb 23, 2015 at 10:37:43PM +, Michael Crusoe wrote:
> > To explain the problem:  We need to build the package in the main
> > universe and the build-dependency libcolt-java is missing there.  I
> > tried to simply drop this build-dependency (+libjai-core-java) and
> > looked what happened.  I tried this approach and it might be possible
> > with some heavier patching but the very simple try failed.
> >
> > BTW, the situation is even worse since libjai-core-java is non-free and
> > previous discussion have shown that chances are close to zero to get
> > this old SUN code freed.  There were some opinions raised that there are
> > better imaging libraries which could replace JAI but my question to more
> > details were not answered.
> >
> >
> Okay. I'll split the source packages. Shall I assume that colt is going to
> end up in main?

I admit that I became optimistic after the latest discussion, that we
have good chances to see libcolt-java in main in a sensible time frame
(3-6 monthes ??).  I'm definitely not sure about libjai-core-java.  Do
You see chances to extract this dependency as well?

Kind regards

 Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150224072308.ga4...@an3as.eu

Re: Update on Trinityrnaseq packaging

[Michael Crusoe]

On Sun Feb 22 2015 at 3:23:53 AM Andreas Tille  wrote:

> On Sun, Feb 22, 2015 at 08:50:37AM +0100, Andreas Tille wrote:
> >
> > That could be a workaround.  Since you can not create such binary
> > packages from one source package you need to create different source
> > packages.  I admit I'm fine if you ignore the contrib part for the
> > moment if you only need the part without libcolt-java.
>
> To explain the problem:  We need to build the package in the main
> universe and the build-dependency libcolt-java is missing there.  I
> tried to simply drop this build-dependency (+libjai-core-java) and
> looked what happened.  I tried this approach and it might be possible
> with some heavier patching but the very simple try failed.
>
> BTW, the situation is even worse since libjai-core-java is non-free and
> previous discussion have shown that chances are close to zero to get
> this old SUN code freed.  There were some opinions raised that there are
> better imaging libraries which could replace JAI but my question to more
> details were not answered.
>
>
Okay. I'll split the source packages. Shall I assume that colt is going to
end up in main?

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Andreas Tille]

Hi Emmanuel,

On Sun, Feb 22, 2015 at 10:31:13PM +0100, Emmanuel Bourg wrote:
> Le 22/02/2015 22:06, Andreas Tille a écrit :
> 
> > As far as I understand ftpmaster everything needs to be removed in
> > src/hep/aida (including bin and ref).
> 
> Yes they are right, but except for the src/hep/aida/bin classes the
> src/hep/aida ones can be replaced by their equivalent in freehep.

Sounds very good!
 
> I conducted a quick experiment: I removed the hep.aida.bin package from
> Colt, removed/patched the code using it and built the reverse
> dependencies. I ended up with these classes removed:
> 
> src/cern/colt/GenericSortingTest.java
> src/cern/colt/matrix/bench/BenchmarkMatrix.java
> src/cern/colt/matrix/doublealgo/DoubleMatrix1DComparator.java
> src/cern/colt/matrix/doublealgo/DoubleMatrix2DComparator.java
> src/cern/colt/matrix/doublealgo/Formatter.java
> src/cern/colt/matrix/doublealgo/Partitioning.java
> src/cern/colt/matrix/doublealgo/Sorting.java
> src/cern/colt/matrix/doublealgo/Statistic.java
> src/cern/colt/matrix/doublealgo/Stencil.java
> src/cern/colt/matrix/doublealgo/Transform.java
> src/cern/colt/matrix/doublealgo/package.html
> src/cern/colt/matrix/impl/BenchmarkMatrix2D.java
> src/cern/colt/matrix/impl/TestMatrix2D.java
> src/cern/jet/random/Benchmark.java
> src/cern/jet/stat/quantile/Quantile1Test.java
> src/hep/aida/ref/Converter.java
> src/hep/aida/ref/Test2.java
> 
> 
> and I also had to make minor modifications to the following classes (I
> commented the toString() and viewSorted() methods):
> 
> src/cern/colt/matrix/DoubleMatrix1D.java
> src/cern/colt/matrix/DoubleMatrix2D.java
> src/cern/colt/matrix/DoubleMatrix3D.java
> src/cern/colt/matrix/linalg/Property.java
> 
> I've successfully rebuilt beast-mcmc, spread-phy and libjung-java with
> this stripped down version of libcolt-java.

Cool!

> I haven't been able to
> create a source tarball for beast2-mcmc, libdsol1-java and libssj-java
> so I don't know for these packages, but this result is promising.

No problem.  I guess this is due to the fact that there are some SVN
addicts in the Debian Med team.  If we care for the existing packages
you mentioned above first I'd happily work on the latter according to
the existing templates.

> At this point I think freehep aida/jaida should be packaged, then a new
> colt-free package could be created using freehep-aida and the
> modifications I made. This will allow you to free at least 3 packages
> from contrib.

This sounds very promising.  Would you mind commiting the results of
your experiment to the Git repository of colt which I just created.  Is
there any volunteer for packaging freehep-aida?  If not I could try to
do my best to at least give it a try (but I admit I would be even more
happy if somebody else would do it ;-)).

That's good news for a Sunday evening

 Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2015015902.ge20...@an3as.eu

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Emmanuel Bourg]

Le 22/02/2015 22:06, Andreas Tille a écrit :

> As far as I understand ftpmaster everything needs to be removed in
> src/hep/aida (including bin and ref).

Yes they are right, but except for the src/hep/aida/bin classes the
src/hep/aida ones can be replaced by their equivalent in freehep.

I conducted a quick experiment: I removed the hep.aida.bin package from
Colt, removed/patched the code using it and built the reverse
dependencies. I ended up with these classes removed:

src/cern/colt/GenericSortingTest.java
src/cern/colt/matrix/bench/BenchmarkMatrix.java
src/cern/colt/matrix/doublealgo/DoubleMatrix1DComparator.java
src/cern/colt/matrix/doublealgo/DoubleMatrix2DComparator.java
src/cern/colt/matrix/doublealgo/Formatter.java
src/cern/colt/matrix/doublealgo/Partitioning.java
src/cern/colt/matrix/doublealgo/Sorting.java
src/cern/colt/matrix/doublealgo/Statistic.java
src/cern/colt/matrix/doublealgo/Stencil.java
src/cern/colt/matrix/doublealgo/Transform.java
src/cern/colt/matrix/doublealgo/package.html
src/cern/colt/matrix/impl/BenchmarkMatrix2D.java
src/cern/colt/matrix/impl/TestMatrix2D.java
src/cern/jet/random/Benchmark.java
src/cern/jet/stat/quantile/Quantile1Test.java
src/hep/aida/ref/Converter.java
src/hep/aida/ref/Test2.java


and I also had to make minor modifications to the following classes (I
commented the toString() and viewSorted() methods):

src/cern/colt/matrix/DoubleMatrix1D.java
src/cern/colt/matrix/DoubleMatrix2D.java
src/cern/colt/matrix/DoubleMatrix3D.java
src/cern/colt/matrix/linalg/Property.java

I've successfully rebuilt beast-mcmc, spread-phy and libjung-java with
this stripped down version of libcolt-java. I haven't been able to
create a source tarball for beast2-mcmc, libdsol1-java and libssj-java
so I don't know for these packages, but this result is promising.

At this point I think freehep aida/jaida should be packaged, then a new
colt-free package could be created using freehep-aida and the
modifications I made. This will allow you to free at least 3 packages
from contrib.

Emmanuel Bourg


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54ea4aa1.4010...@apache.org

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Andreas Tille]

Hi Sune,

On Sun, Feb 22, 2015 at 06:12:55PM +, Sune Vuorela wrote:
> On 2015-02-22, Andreas Tille  wrote:
> > I tried the stupid approach and simply replaced the affected files
> >
> >   IAxis.java  IHistogram*.java
> >
> > by the equally named files I found in SVN.  But this was probably to
> > simple and did not build.  I guess this approached needs somebody who
> > has some basic Java experience.
> >  
> >> That leaves src/hep/aida/bin where I couldn't find correspondent files
> >> on freehep.org. That means you probably have to remove the whole
> >> directory and try to recompile colt. Every class that imports
> >> "hep.aida.bin" will need a patch or has to be excluded as well.
> >
> > I could imagine that this would work.  Any volunteer?
> 
> I do imagine it be easier for people to jump in if there was a git
> branch or similar with your not working stuff, and a quick introduction
> to how to attempt to build it.

OK, point taken.  I moved the repository to

   Vcs-Git: git://anonscm.debian.org/debian-med/colt.git

Respositories of Debian Med have ACLs set so any DD can commit.  If you
are no DD and no member of Debian Med team I'd happily forward any
patches.  When doing so I realised the changes commited by Tim Booth
that try to tackle the issue in a similar as suggested manner (I somehow
forgot this over time) but there are remaining issues brought up by
ftpmaster which are documented in the header of the patch:

   
https://anonscm.debian.org/cgit/debian-med/colt.git/tree/debian/patches/build_without_aida_interface_defs.patch

As far as I understand ftpmaster everything needs to be removed in
src/hep/aida (including bin and ref).  I did not manage to remove
since it is used in the cern code:

$ grep -R hep\.aida\. | grep \.java:
src/cern/colt/matrix/bench/BenchmarkMatrix.java:
hep.aida.bin.BinFunctions1D F = hep.aida.bin.BinFunctions1D.functions;
src/cern/colt/matrix/bench/BenchmarkMatrix.java:
hep.aida.bin.BinFunction1D[] aggr = null; //{F.mean, F.median, F.sum};
src/cern/colt/matrix/bench/BenchmarkMatrix.java:
hep.aida.bin.BinFunctions1D F = hep.aida.bin.BinFunctions1D.functions;
src/cern/colt/matrix/bench/BenchmarkMatrix.java:
hep.aida.bin.BinFunction1D[] aggr = null; //{F.mean, F.median, F.sum};
src/cern/colt/matrix/doublealgo/Sorting.java: 
hep.aida.bin.BinFunctions1D.sum
src/cern/colt/matrix/doublealgo/Sorting.java:DoubleMatrix2D sorted = 
quickSort(matrix,hep.aida.bin.BinFunctions1D.median);
src/cern/colt/matrix/doublealgo/Sorting.java://DoubleMatrix2D sorted = 
quickSort(matrix,hep.aida.bin.BinFunctions1D.sumOfLogarithms);
src/cern/colt/matrix/doublealgo/Sorting.java:public DoubleMatrix2D 
sort(DoubleMatrix2D matrix, hep.aida.bin.BinFunction1D aggregate) {
src/cern/colt/matrix/doublealgo/Sorting.java:   hep.aida.bin.BinFunction1D[] 
func = {aggregate};
src/cern/colt/matrix/doublealgo/Sorting.java:   A = 
sort.sort(A,hep.aida.bin.BinFunctions1D.median);
src/cern/colt/matrix/doublealgo/Sorting.java:   //A = 
sort.sort(A,hep.aida.bin.BinFunctions1D.sumLog);
src/cern/colt/matrix/doublealgo/Sorting.java:   
hep.aida.bin.BinFunction1D[] funs = {hep.aida.bin.BinFunctions1D.median, 
hep.aida.bin.BinFunctions1D.sumLog, hep.aida.bin.BinFunctions1D.geometricMean};
src/cern/colt/matrix/doublealgo/Formatter.java: 
hep.aida.bin.BinFunctions1D F = hep.aida.bin.BinFunctions1D.functions; // 
alias
src/cern/colt/matrix/doublealgo/Formatter.java: 
hep.aida.bin.BinFunction1D[] aggr = {F.mean, F.rms, F.quantile(0.25), F.median, 
F.quantile(0.75), F.stdDev, F.min, F.max};
src/cern/colt/matrix/doublealgo/Formatter.java:hep.aida.bin.BinFunctions1D F = 
hep.aida.bin.BinFunctions1D.functions;
src/cern/colt/matrix/doublealgo/Formatter.java:hep.aida.bin.BinFunction1D[] 
aggr = {F.mean, F.rms, F.quantile(0.25), F.median,F.quantile(0.75), F.stdDev, 
F.min, F.max};
src/cern/colt/matrix/doublealgo/Formatter.java://hep.aida.bin.BinFunction1D[] 
aggr = {F.mean, F.median, F.sum};
src/cern/colt/matrix/doublealgo/Formatter.java:@see hep.aida.bin.BinFunction1D
src/cern/colt/matrix/doublealgo/Formatter.java:@see hep.aida.bin.BinFunctions1D
src/cern/colt/matrix/doublealgo/Formatter.java:public String 
toTitleString(DoubleMatrix2D matrix, String[] rowNames, String[] columnNames, 
String rowAxisName, String columnAxisName, String title, 
hep.aida.bin.BinFunction1D[] aggr) {
src/cern/colt/matrix/doublealgo/Formatter.java:@see hep.aida.bin.BinFunction1D
src/cern/colt/matrix/doublealgo/Formatter.java:@see hep.aida.bin.BinFunctions1D
src/cern/colt/matrix/doublealgo/Formatter.java:public String 
toTitleString(DoubleMatrix3D matrix, String[] sliceNames, String[] rowNames, 
String[] columnNames, String sliceAxisName, String rowAxisName, String 
columnAxisName, String title, hep.aida.bin.BinFunction1D[] aggr) {
src/cern/colt/matrix/doublealgo/Statistic.java:import hep.aida.bin.DynamicBin1D;
src/cern/colt/matrix/doublealgo/Statistic.java:Also see {@link cern.jet.stat} 
and {@

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Sune Vuorela]

On 2015-02-22, Andreas Tille  wrote:
> I tried the stupid approach and simply replaced the affected files
>
>   IAxis.java  IHistogram*.java
>
> by the equally named files I found in SVN.  But this was probably to
> simple and did not build.  I guess this approached needs somebody who
> has some basic Java experience.
>  
>> That leaves src/hep/aida/bin where I couldn't find correspondent files
>> on freehep.org. That means you probably have to remove the whole
>> directory and try to recompile colt. Every class that imports
>> "hep.aida.bin" will need a patch or has to be excluded as well.
>
> I could imagine that this would work.  Any volunteer?

I do imagine it be easier for people to jump in if there was a git
branch or similar with your not working stuff, and a quick introduction
to how to attempt to build it.

/Sune


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/mcd677$545$1...@ger.gmane.org

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Andreas Tille]

Hi Emmanuel,

On Sun, Feb 22, 2015 at 11:19:37AM +0100, Emmanuel Bourg wrote:
> There is something else you could try, you may remove the non free parts
> of colt and try rebuilding the reverse dependencies with this stripped
> down version. If it works you could then derive a new colt-free package
> from this version.

Unfortunately this does not work since the package does not build after
removing src/hep.aida.* :-(

Thanks for the hint anyway

 Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150222175211.gc20...@an3as.eu

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Andreas Tille]

Hi Markus,

On Sun, Feb 22, 2015 at 06:11:47PM +0100, Markus Koschany wrote:
> I think Emmanuel has already pointed in the right directions. Just to
> clarify what exactly is controversial or difficult and has to be done.
> 
> The *.java files under src/hep/aida/ in Colt belong to the freehep-aida
> project at http://aida.freehep.org/ and are licensed under LGPL-2.1. I
> have checked out the CVS repository and the source files are accompanied
> by the full LGPL license in LGPL.txt. No signs of exceptions.
> 
> The files under src/hep/aida/ref can be traced back to freehep-jaida
> http://java.freehep.org/jaida/. The source files are located in a SVN
> repository:
> 
> svn checkout svn://svn.freehep.org/svn/freehep/trunk/jaida jaida
> 
> See freehep-jaida/src/main/java/hep/aida/ref
> 
> It looks like most of them are very similar to the ones you can find in
> colt. All jaida files are also licensed under the LGPL-2.1.

I tried the stupid approach and simply replaced the affected files

  IAxis.java  IHistogram*.java

by the equally named files I found in SVN.  But this was probably to
simple and did not build.  I guess this approached needs somebody who
has some basic Java experience.
 
> That leaves src/hep/aida/bin where I couldn't find correspondent files
> on freehep.org. That means you probably have to remove the whole
> directory and try to recompile colt. Every class that imports
> "hep.aida.bin" will need a patch or has to be excluded as well.

I could imagine that this would work.  Any volunteer?
 
> I have not verified how Apache Mahout can replace the affected
> functionality and whether it is possible at all.
> 
> So far
 
Thanks for your helpful hints

 Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150222174907.gb20...@an3as.eu

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Markus Koschany]

On 22.02.2015 09:47, Andreas Tille wrote:
[...]
> Whatever helps to get a free functionality of libcolt-java would be
> really helpful.
>  

I think Emmanuel has already pointed in the right directions. Just to
clarify what exactly is controversial or difficult and has to be done.

The *.java files under src/hep/aida/ in Colt belong to the freehep-aida
project at http://aida.freehep.org/ and are licensed under LGPL-2.1. I
have checked out the CVS repository and the source files are accompanied
by the full LGPL license in LGPL.txt. No signs of exceptions.

The files under src/hep/aida/ref can be traced back to freehep-jaida
http://java.freehep.org/jaida/. The source files are located in a SVN
repository:

svn checkout svn://svn.freehep.org/svn/freehep/trunk/jaida jaida

See freehep-jaida/src/main/java/hep/aida/ref

It looks like most of them are very similar to the ones you can find in
colt. All jaida files are also licensed under the LGPL-2.1.

That leaves src/hep/aida/bin where I couldn't find correspondent files
on freehep.org. That means you probably have to remove the whole
directory and try to recompile colt. Every class that imports
"hep.aida.bin" will need a patch or has to be excluded as well.

I have not verified how Apache Mahout can replace the affected
functionality and whether it is possible at all.

So far

Markus





signature.asc
Description: OpenPGP digital signature

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Emmanuel Bourg]

There is something else you could try, you may remove the non free parts
of colt and try rebuilding the reverse dependencies with this stripped
down version. If it works you could then derive a new colt-free package
from this version.

Emmanuel Bourg


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e9ad39.9030...@apache.org

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Andreas Tille]

Hi Emmanuel,

On Sun, Feb 22, 2015 at 09:52:48AM +0100, Emmanuel Bourg wrote:
> Le 22/02/2015 09:41, Andreas Tille a écrit :
> 
> > This would be really good news.  I'd be really happy about this but I
> > personally have no idea what exactly needs to be done to approach it.
> > Any help would be more than welcome.
> 
> The classes of the Mahout fork reside in a different package. If they
> preserved the class structure using this fork may be as simple as
> renaming the import statements in the projects depending on Colt.

This would be very good news.  If you could provide some more details
we could tackle the currently existing packages

   spread-phy (probably simple)
   beast-mcmc (more complex)
   svn://anonscm.debian.org/debian-med/trunk/packages/libdsol1-java/trunk/
   svn://anonscm.debian.org/debian-med/trunk/packages/libssj-java/trunk/
   svn://anonscm.debian.org/debian-med/trunk/packages/beast2-mcmc/trunk/
   git://anonscm.debian.org/debian-med/libjung-java.git

I remember there are also some other packages in Debian Science which
were somehow depending from libcolt-java (I would need to check this).

Any more detailed hint (patch?) would be more than welcome

 Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150222090520.gh28...@an3as.eu

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Emmanuel Bourg]

Le 22/02/2015 09:41, Andreas Tille a écrit :

> This would be really good news.  I'd be really happy about this but I
> personally have no idea what exactly needs to be done to approach it.
> Any help would be more than welcome.

The classes of the Mahout fork reside in a different package. If they
preserved the class structure using this fork may be as simple as
renaming the import statements in the projects depending on Colt.

Emmanuel Bourg


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e998e0.3090...@apache.org

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Andreas Tille]

Hi Markus,

thanks for checking this.

On Sun, Feb 22, 2015 at 12:47:00AM +0100, Markus Koschany wrote:
> 
> Where could one find the aida code replacement on java.freehep.org? So
> far I found

As far as I understood Emmanuel he has answered the question in his
mail.
 
> http://aida.freehep.org/license.thtml
> 
> which indicates that the code is licensed under LGPL but I'm not sure if
> this is not just the same aida code from 2004 which is already present
> in colt. Perhaps they changed the license and removed the non-free
> exception?
> 
> When I download AIDA 3.2.1 they refer to a LGPL.txt file but I can't
> find it. If this one was really the free replacement it would be
> possible to replace src/aida by either repacking the colt source package
> or by packaging the version on aida.freehep.org and adding aida to the
> classpath of libcolt-java.

Whatever helps to get a free functionality of libcolt-java would be
really helpful.
 
Kind regards

 Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150222084753.gg28...@an3as.eu

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Andreas Tille]

On Sun, Feb 22, 2015 at 01:40:22AM +0100, Emmanuel Bourg wrote:
> I just found out the Apache Mahout project maintains a fork of Colt [1],
> they kept only the free bits. Maybe it could be used as a replacement
> for the projects based on Colt that don't use the non free part?

This would be really good news.  I'd be really happy about this but I
personally have no idea what exactly needs to be done to approach it.
Any help would be more than welcome.

Kind regards

   Andreas.

> [1] https://github.com/apache/mahout/tree/master/math

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150222084137.gf28...@an3as.eu

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Andreas Tille]

Hi Emmanuel,

On Sun, Feb 22, 2015 at 01:01:39AM +0100, Emmanuel Bourg wrote:
> 
> I got a quick look and it seems some of these classes are available in
> the aida and jaida modules of freehep. The main issue seems to be the
> hep.aida.bin package, it doesn't exist in freehep and depends on Colt
> classes. It was also written by Wolfgang Hoschek which is the author of
> Colt.
> 
> If the no military clause came from the old aida classes maybe the
> package hep.aida.bin created by Wolfgang Hoschek isn't affected? If this
> hypothesis is confirmed it should be possible to depend on freehep-aida,
> otherwise Colt is doomed to remain in non-free :(

I have not checked myself but as far as I understood freehep-aida is
really free.

> Were you able to
> contact Wolfgang Hoschek?

We tried several times [1] but failed to get any answer at all. :-(

Thanks for spending time into this.

Kind regards

   Andreas.

[1] https://lists.debian.org/debian-med/2013/12/msg00094.html
https://lists.debian.org/debian-med/2012/01/msg00239.html
https://lists.debian.org/debian-med/2012/08/msg3.html
 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150222083647.ge28...@an3as.eu

Re: Update on Trinityrnaseq packaging

[Andreas Tille]

On Sun, Feb 22, 2015 at 08:50:37AM +0100, Andreas Tille wrote:
> 
> That could be a workaround.  Since you can not create such binary
> packages from one source package you need to create different source
> packages.  I admit I'm fine if you ignore the contrib part for the
> moment if you only need the part without libcolt-java.

To explain the problem:  We need to build the package in the main
universe and the build-dependency libcolt-java is missing there.  I
tried to simply drop this build-dependency (+libjai-core-java) and
looked what happened.  I tried this approach and it might be possible
with some heavier patching but the very simple try failed.

BTW, the situation is even worse since libjai-core-java is non-free and
previous discussion have shown that chances are close to zero to get
this old SUN code freed.  There were some opinions raised that there are
better imaging libraries which could replace JAI but my question to more
details were not answered.

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150222082339.gd28...@an3as.eu

Re: Update on Trinityrnaseq packaging

[Andreas Tille]

Hi Michael,

On Sun, Feb 22, 2015 at 01:20:55AM +, Michael Crusoe wrote:
> 
> Fully aware. It looks like the parts of libjung-java that trinityrnaseq
> uses aren't the parts that use classes from libcolt-java. I'm going to
> split libjung-java into two packages, on main and one contrib.

That could be a workaround.  Since you can not create such binary
packages from one source package you need to create different source
packages.  I admit I'm fine if you ignore the contrib part for the
moment if you only need the part without libcolt-java.

Perhaps we might be lucky with my question to debian-java ...

Kind regards

 Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150222075037.gc28...@an3as.eu

Re: Update on Trinityrnaseq packaging

[Michael Crusoe]

On Sat Feb 21 2015 at 8:20:55 PM Michael Crusoe 
wrote:

> On Sat Feb 21 2015 at 4:19:41 PM Andreas Tille  wrote:
>
>> Hi Michael,
>>
>> On Sat, Feb 21, 2015 at 08:54:50PM +, Michael Crusoe wrote:
>> > >
>> > > Uhmm, only for contrib since it depends libcolt-java. :-( :-( :-(
>> >
>> > Ugh.
>> >
>> > I've removed the bundled collections15 library via patching and updated
>> > control to use contrib.
>>
>> Are you aware about the consequences that all further dependencies need
>> to go to contrib as well and thus do not profit from several QA means
>> inside Debian?  I really, really wish we could find a better solution.
>> Libcolt is on top position on my to-be-freed list since we have several
>> dependencies which all suffer from this stupid license of these few
>> outdated files. :-(
>>
>
> Fully aware. It looks like the parts of libjung-java that trinityrnaseq
> uses aren't the parts that use classes from libcolt-java. I'm going to
> split libjung-java into two packages, on main and one contrib.
>

This has been pushed to the debian-med git repository. My first mixed
section package; feedback is very welcome!

Bonus: all the JARs that are apart of JUNG are now packaged (not just the
couple I needed for Trinity).

Re: Re: Update on Trinityrnaseq packaging

[Michael Crusoe]

Thanks!

On Sat Feb 21 2015 at 10:05:36 PM "Steffen Möller" 
wrote:

> transdecoder went exceptionally smoothly.
>
> Cheers,
>
> Steffen
>
> *Gesendet:* Sonntag, 22. Februar 2015 um 03:33 Uhr
> *Von:* "Steffen Möller" 
> *An:* "Michael Crusoe" 
> *Cc:* debian-med@lists.debian.org
> *Betreff:* Aw: Re: Update on Trinityrnaseq packaging
>
> Hello,
>
>
> I added an express-doc package and uploaded. That was OK, I hope.
>
> @Andreas, I will address Transdecoder next.
>
> Concerning the git repository I failed to get the upstream/1.5.1 branch -
> so I just decided to get the orig.tar.gz myself and work as if it was a
> good old subversion repository :)
>
> Cheers,
>
> Steffen
>
>
>
>
>  *Gesendet:* Dienstag, 17. Februar 2015 um 04:46 Uhr
> *Von:* "Michael Crusoe" 
> *An:* debian-med@lists.debian.org
> *Betreff:* Re: Update on Trinityrnaseq packaging
>  On Mon Feb 16 2015 at 11:09:37 AM Andreas Tille 
> wrote:
>>
>> Hi Michael,
>>
>> On Mon, Feb 16, 2015 at 07:09:18AM +, Michael Crusoe wrote:
>> > To-do:
>> > dependencies needing review & uploading to Debian:
>> > - [ ] libjung-java
>
>
> Ready for sponsoring
>
>
>> > - [ ] rsem
>
>
> Has a dependency that I just packaged: r-bioc-ebseq (also needed for
> Trinity); of course that had its own dependency: r-cran-blockmodeling. Both
> are ready for sponsoring.
>
> rsem itself needs manpages & testing
>
>
>> > - [ ] express
>
>
> Ready for sponsoring
>
>
>> > - [ ] transdecoder
>>
>> OK, just ping me if one or more are ready for sponsering.
>
>
>
>
>
>>
>> > - [ ] jaligner
>>
>> Just uploaded after some slight changes.
>
>
>   Thanks!
>
>
>>
>> Thanks for your work
>>
>> Andreas.
>>
>> --
>> http://fam-tille.de
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact
>> listmas...@lists.debian.org
>> Archive: https://lists.debian.org/20150216090920.gb23...@an3as.eu
>>
>
> -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with
> a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive:
> https://lists.debian.org/trinity-5f3867fb-077c-4abc-9a2a-e0a5d1b9b5c8-1424572406307@3capp-gmx-bs66
>

Aw: Re: Update on Trinityrnaseq packaging

[Steffen Möller]

transdecoder went exceptionally smoothly.

 

Cheers,

 

Steffen

 

Gesendet: Sonntag, 22. Februar 2015 um 03:33 Uhr
Von: "Steffen Möller" 
An: "Michael Crusoe" 
Cc: debian-med@lists.debian.org
Betreff: Aw: Re: Update on Trinityrnaseq packaging



 

Hello,

 

 

I added an express-doc package and uploaded. That was OK, I hope.

 

@Andreas, I will address Transdecoder next.

 

Concerning the git repository I failed to get the upstream/1.5.1 branch - so I just decided to get the orig.tar.gz myself and work as if it was a good old subversion repository :)

 

Cheers,

 

Steffen

 

 

 

 


Gesendet: Dienstag, 17. Februar 2015 um 04:46 Uhr
Von: "Michael Crusoe" 
An: debian-med@lists.debian.org
Betreff: Re: Update on Trinityrnaseq packaging



On Mon Feb 16 2015 at 11:09:37 AM Andreas Tille <andr...@an3as.eu> wrote:

Hi Michael,

On Mon, Feb 16, 2015 at 07:09:18AM +, Michael Crusoe wrote:
> To-do:
> dependencies needing review & uploading to Debian:
> - [ ] libjung-java

 

Ready for sponsoring

 

> - [ ] rsem

 

Has a dependency that I just packaged: r-bioc-ebseq (also needed for Trinity); of course that had its own dependency: r-cran-blockmodeling. Both are ready for sponsoring.

 

rsem itself needs manpages & testing

 

> - [ ] express

 

Ready for sponsoring

 

> - [ ] transdecoder

OK, just ping me if one or more are ready for sponsering.

 

 

 


> - [ ] jaligner

Just uploaded after some slight changes.

 




Thanks!





 


Thanks for your work

        Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150216090920.gb23...@an3as.eu
 








-- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/trinity-5f3867fb-077c-4abc-9a2a-e0a5d1b9b5c8-1424572406307@3capp-gmx-bs66





-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/trinity-01dee7d2-da0d-4297-b439-7cc5902da045-1424574335792@3capp-gmx-bs66

Aw: Re: Update on Trinityrnaseq packaging

[Steffen Möller]

 

Hello,

 

 

I added an express-doc package and uploaded. That was OK, I hope.

 

@Andreas, I will address Transdecoder next.

 

Concerning the git repository I failed to get the upstream/1.5.1 branch - so I just decided to get the orig.tar.gz myself and work as if it was a good old subversion repository :)

 

Cheers,

 

Steffen

 

 

 

 


Gesendet: Dienstag, 17. Februar 2015 um 04:46 Uhr
Von: "Michael Crusoe" 
An: debian-med@lists.debian.org
Betreff: Re: Update on Trinityrnaseq packaging



On Mon Feb 16 2015 at 11:09:37 AM Andreas Tille <andr...@an3as.eu> wrote:

Hi Michael,

On Mon, Feb 16, 2015 at 07:09:18AM +, Michael Crusoe wrote:
> To-do:
> dependencies needing review & uploading to Debian:
> - [ ] libjung-java

 

Ready for sponsoring

 

> - [ ] rsem

 

Has a dependency that I just packaged: r-bioc-ebseq (also needed for Trinity); of course that had its own dependency: r-cran-blockmodeling. Both are ready for sponsoring.

 

rsem itself needs manpages & testing

 

> - [ ] express

 

Ready for sponsoring

 

> - [ ] transdecoder

OK, just ping me if one or more are ready for sponsering.

 

 

 


> - [ ] jaligner

Just uploaded after some slight changes.

 




Thanks!





 


Thanks for your work

        Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150216090920.gb23...@an3as.eu
 









-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/trinity-5f3867fb-077c-4abc-9a2a-e0a5d1b9b5c8-1424572406307@3capp-gmx-bs66

Re: Update on Trinityrnaseq packaging

[Michael Crusoe]

On Sat Feb 21 2015 at 4:19:41 PM Andreas Tille  wrote:

> Hi Michael,
>
> On Sat, Feb 21, 2015 at 08:54:50PM +, Michael Crusoe wrote:
> > >
> > > Uhmm, only for contrib since it depends libcolt-java. :-( :-( :-(
> >
> > Ugh.
> >
> > I've removed the bundled collections15 library via patching and updated
> > control to use contrib.
>
> Are you aware about the consequences that all further dependencies need
> to go to contrib as well and thus do not profit from several QA means
> inside Debian?  I really, really wish we could find a better solution.
> Libcolt is on top position on my to-be-freed list since we have several
> dependencies which all suffer from this stupid license of these few
> outdated files. :-(
>

Fully aware. It looks like the parts of libjung-java that trinityrnaseq
uses aren't the parts that use classes from libcolt-java. I'm going to
split libjung-java into two packages, on main and one contrib.


>
> Kind regards
>
>  Andreas.
>
> --
> http://fam-tille.de
>
>
> --
> To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/20150221211926.ga27...@an3as.eu
>
>

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Emmanuel Bourg]

I just found out the Apache Mahout project maintains a fork of Colt [1],
they kept only the free bits. Maybe it could be used as a replacement
for the projects based on Colt that don't use the non free part?

Emmanuel Bourg

[1] https://github.com/apache/mahout/tree/master/math


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e92576.2050...@apache.org

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Emmanuel Bourg]

Le 21/02/2015 22:32, Andreas Tille a écrit :

> Unfortunately nobody in the team is skilled anough in Java to do the job
> (or at least confirm that it is as simple as I assume) and thus I wonder
> whether there is some kind soul on Debian Java having a look into this.

Hi Andreas,

I got a quick look and it seems some of these classes are available in
the aida and jaida modules of freehep. The main issue seems to be the
hep.aida.bin package, it doesn't exist in freehep and depends on Colt
classes. It was also written by Wolfgang Hoschek which is the author of
Colt.

If the no military clause came from the old aida classes maybe the
package hep.aida.bin created by Wolfgang Hoschek isn't affected? If this
hypothesis is confirmed it should be possible to depend on freehep-aida,
otherwise Colt is doomed to remain in non-free :( Were you able to
contact Wolfgang Hoschek?

Emmanuel Bourg


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e91c63.9040...@apache.org

Re: Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Markus Koschany]

On 21.02.2015 22:32, Andreas Tille wrote:
> Hi Java programmers,

Hi Andreas,

> 
> I wonder whether you could help to replace some outdated code in
> libcolt-java which has some old code from src/hep.aida.* which is LGPL
> but no military exception.  The code is old, was rewritten in
>http://java.freehep.org/ (???)
> which has a free license and all our tries to reach the original author
> for some clarification failed. 
[...]

Where could one find the aida code replacement on java.freehep.org? So
far I found

http://aida.freehep.org/license.thtml

which indicates that the code is licensed under LGPL but I'm not sure if
this is not just the same aida code from 2004 which is already present
in colt. Perhaps they changed the license and removed the non-free
exception?

When I download AIDA 3.2.1 they refer to a LGPL.txt file but I can't
find it. If this one was really the free replacement it would be
possible to replace src/aida by either repacking the colt source package
or by packaging the version on aida.freehep.org and adding aida to the
classpath of libcolt-java.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Please help freeing libcolt-java [Was: Update on Trinityrnaseq packaging]

[Andreas Tille]

Hi Java programmers,

I wonder whether you could help to replace some outdated code in
libcolt-java which has some old code from src/hep.aida.* which is LGPL
but no military exception.  The code is old, was rewritten in
   http://java.freehep.org/ (???)
which has a free license and all our tries to reach the original author
for some clarification failed.  Debian Med and Debian Science need
libcolt-java for several reverse dependencies which unfortunately all
need to go in contrib because of a few files with old code.

Unfortunately nobody in the team is skilled anough in Java to do the job
(or at least confirm that it is as simple as I assume) and thus I wonder
whether there is some kind soul on Debian Java having a look into this.

Kind regards

   Andreas.

- Forwarded message from Andreas Tille  -

Date: Tue, 17 Feb 2015 09:50:35 +0100
From: Andreas Tille 
To: debian-med@lists.debian.org
Subject: Re: Update on Trinityrnaseq packaging

Hi Michael,

On Tue, Feb 17, 2015 at 03:46:09AM +, Michael Crusoe wrote:
> On Mon Feb 16 2015 at 11:09:37 AM Andreas Tille  wrote:
> > > dependencies needing review & uploading to Debian:
> > > - [ ] libjung-java
> 
> Ready for sponsoring

Uhmm, only for contrib since it depends libcolt-java. :-( :-( :-(
This libcolt issue is beating us over and over again.  My last longer
explanation was here:

   
http://lists.alioth.debian.org/pipermail/debian-med-packaging/2014-June/027387.html

For me it seems pretty clear that for some interested Java programmer
this issue could be solved in a dcent time frame by upgrading to
freehep.  Alternatively some interested non-programmer could try even
harder to push the original author changing the broken license.  But as
long as this is not solved at least four of our packages in interest
will end up in contrib only (which all the nasty consequences). :-(
 
> Has a dependency that I just packaged: r-bioc-ebseq (also needed for
> Trinity); of course that had its own dependency: r-cran-blockmodeling. Both
> are ready for sponsoring.

r-cran-blockmodeling uploaded to new.  It would be safer to ping me
again about r-bioc-ebseq once r-cran-blockmodeling might have hit
unstable to make sure I will not loose the chain of dependency amongst
the other things I'm doing.
 
> rsem itself needs manpages & testing

OK.
 
> > > - [ ] express
> 
> Ready for sponsoring

I'll have a look.

Thanks for your effort

Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150217085035.gc10...@an3as.eu



- End forwarded message -

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150221213212.gb27...@an3as.eu

Re: Update on Trinityrnaseq packaging

[Andreas Tille]

Hi Michael,

On Sat, Feb 21, 2015 at 08:54:50PM +, Michael Crusoe wrote:
> >
> > Uhmm, only for contrib since it depends libcolt-java. :-( :-( :-(
> 
> Ugh.
> 
> I've removed the bundled collections15 library via patching and updated
> control to use contrib.

Are you aware about the consequences that all further dependencies need
to go to contrib as well and thus do not profit from several QA means
inside Debian?  I really, really wish we could find a better solution.
Libcolt is on top position on my to-be-freed list since we have several
dependencies which all suffer from this stupid license of these few
outdated files. :-(

Kind regards

 Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150221211926.ga27...@an3as.eu

Re: Update on Trinityrnaseq packaging

[Michael Crusoe]

On Tue Feb 17 2015 at 3:50:50 AM Andreas Tille  wrote:

> Hi Michael,
>
> On Tue, Feb 17, 2015 at 03:46:09AM +, Michael Crusoe wrote:
> > On Mon Feb 16 2015 at 11:09:37 AM Andreas Tille 
> wrote:
> > > > dependencies needing review & uploading to Debian:
> > > > - [ ] libjung-java
> >
> > Ready for sponsoring
>
> Uhmm, only for contrib since it depends libcolt-java. :-( :-( :-(
>

Ugh.

I've removed the bundled collections15 library via patching and updated
control to use contrib.

libjung-java is ready for sponsoring

Re: Update on Trinityrnaseq packaging

[Andreas Tille]

On Tue, Feb 17, 2015 at 09:50:35AM +0100, Andreas Tille wrote:
> > > > - [ ] express
> > 
> > Ready for sponsoring
> 
> I'll have a look.

I had a look and pushed some small changes to fix some lintian issues
and uploaded. 

Thanks for your preparation

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150217110255.ge10...@an3as.eu

Re: Update on Trinityrnaseq packaging

[Andreas Tille]

Hi Michael,

On Tue, Feb 17, 2015 at 03:46:09AM +, Michael Crusoe wrote:
> On Mon Feb 16 2015 at 11:09:37 AM Andreas Tille  wrote:
> > > dependencies needing review & uploading to Debian:
> > > - [ ] libjung-java
> 
> Ready for sponsoring

Uhmm, only for contrib since it depends libcolt-java. :-( :-( :-(
This libcolt issue is beating us over and over again.  My last longer
explanation was here:

   
http://lists.alioth.debian.org/pipermail/debian-med-packaging/2014-June/027387.html

For me it seems pretty clear that for some interested Java programmer
this issue could be solved in a dcent time frame by upgrading to
freehep.  Alternatively some interested non-programmer could try even
harder to push the original author changing the broken license.  But as
long as this is not solved at least four of our packages in interest
will end up in contrib only (which all the nasty consequences). :-(
 
> Has a dependency that I just packaged: r-bioc-ebseq (also needed for
> Trinity); of course that had its own dependency: r-cran-blockmodeling. Both
> are ready for sponsoring.

r-cran-blockmodeling uploaded to new.  It would be safer to ping me
again about r-bioc-ebseq once r-cran-blockmodeling might have hit
unstable to make sure I will not loose the chain of dependency amongst
the other things I'm doing.
 
> rsem itself needs manpages & testing

OK.
 
> > > - [ ] express
> 
> Ready for sponsoring

I'll have a look.

Thanks for your effort

Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150217085035.gc10...@an3as.eu

Re: Re: Update on Trinityrnaseq packaging

[Michael Crusoe]

On Mon Feb 16 2015 at 2:02:12 AM "Steffen Möller" 
wrote:

>
> Hi Michael,
>
>
> > On Mon Feb 16 2015 at 5:46:42 PM Andreas Tille 
> wrote:Hi Michael,
>
> On Mon, Feb 16, 2015 at 07:09:18AM +, Michael Crusoe wrote:
>
> >> I had some quick look into this and did some changed (please pull).
> >> Thanks for the changes.  I realised that some large files are installed
> into
> >>
> >>   /usr/lib/transdecoder/sample_data
> >>
> >>The name of this dir might support the suspicion that these data are not
> >>necessary for using transdecoder but rather for testing.  If this is
> >>true I'd recommend separating these files into a package
> >>
> >>   transdecoder-data
> >>
> >> (which has architecture all).
> >>
> >Since this is a Perl program I guess the entirety should be Architecture:
> all? Since there is less than 10 MB of sample data I prefer to keep it with
> the main program. Sample >data with example usage helps users understand
> how the program works, with what file formats, and how to use it.
>
> I propose having the sample data together with a -doc package. The
> separation
> of the executable parts into a package of its own is meant to help the I/O
> for the dynamic construction of some runtime environment (chroot, docker,
> vm, cloud instance ...) when some workflow specification refers to Trinity
> as a dependency.
>

Okey, dokey: done!


>
> Many thanks for your tremendous effort on all those packages!
>

You are very welcome. I'll be glad when this crop is done :-)


>
> Best,
>
> Steffen
>
>
> --
> To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/trinity-e9f44d4e-e4b8-4ad2-
> ae56-24d7b28e7347-1424131315342@3capp-gmx-bs24
>
>

Re: Update on Trinityrnaseq packaging

[Michael Crusoe]

On Mon Feb 16 2015 at 11:09:37 AM Andreas Tille  wrote:

> Hi Michael,
>
> On Mon, Feb 16, 2015 at 07:09:18AM +, Michael Crusoe wrote:
> > To-do:
> > dependencies needing review & uploading to Debian:
> > - [ ] libjung-java
>

Ready for sponsoring


> > - [ ] rsem
>

Has a dependency that I just packaged: r-bioc-ebseq (also needed for
Trinity); of course that had its own dependency: r-cran-blockmodeling. Both
are ready for sponsoring.

rsem itself needs manpages & testing


> > - [ ] express
>

Ready for sponsoring


> > - [ ] transdecoder
>
> OK, just ping me if one or more are ready for sponsering.





>
> > - [ ] jaligner
>
> Just uploaded after some slight changes.
>

Thanks!


>
> Thanks for your work
>
> Andreas.
>
> --
> http://fam-tille.de
>
>
> --
> To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/20150216090920.gb23...@an3as.eu
>
>

Aw: Re: Update on Trinityrnaseq packaging

[Steffen Möller]

Hi Michael,
 

> On Mon Feb 16 2015 at 5:46:42 PM Andreas Tille  wrote:Hi 
>Michael,

On Mon, Feb 16, 2015 at 07:09:18AM +, Michael Crusoe wrote:

>> I had some quick look into this and did some changed (please pull).
>> Thanks for the changes.  I realised that some large files are installed into
>>
>>   /usr/lib/transdecoder/sample_data
>>
>>The name of this dir might support the suspicion that these data are not
>>necessary for using transdecoder but rather for testing.  If this is
>>true I'd recommend separating these files into a package
>>
>>   transdecoder-data
>>
>> (which has architecture all).
>> 
>Since this is a Perl program I guess the entirety should be Architecture: all? 
>Since there is less than 10 MB of sample data I prefer to keep it with the 
>main program. Sample >data with example usage helps users understand how the 
>program works, with what file formats, and how to use it.

I propose having the sample data together with a -doc package. The separation
of the executable parts into a package of its own is meant to help the I/O
for the dynamic construction of some runtime environment (chroot, docker,
vm, cloud instance ...) when some workflow specification refers to Trinity
as a dependency.

Many thanks for your tremendous effort on all those packages!

Best,

Steffen


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/trinity-e9f44d4e-e4b8-4ad2-ae56-24d7b28e7347-1424131315342@3capp-gmx-bs24

Re: Update on Trinityrnaseq packaging

[Michael Crusoe]

On Mon Feb 16 2015 at 5:46:42 PM Andreas Tille  wrote:

> Hi Michael,
>
> On Mon, Feb 16, 2015 at 07:09:18AM +, Michael Crusoe wrote:
> >
> > To-do:
> > dependencies needing review & uploading to Debian:
> > ...
> > - [ ] transdecoder
>
> I had some quick look into this and did some changed (please pull).
>
Thanks for the changes.

> I realised that some large files are installed into
>
>/usr/lib/transdecoder/sample_data
>
> The name of this dir might support the suspicion that these data are not
> necessary for using transdecoder but rather for testing.  If this is
> true I'd recommend separating these files into a package
>
>transdecoder-data
>
> (which has architecture all).
>

Since this is a Perl program I guess the entirety should be Architecture:
all? Since there is less than 10 MB of sample data I prefer to keep it with
the main program. Sample data with example usage helps users understand how
the program works, with what file formats, and how to use it.

Cheers,


>
> Kind regards
>
> Andreas.
>
> --
> http://fam-tille.de
>
>
> --
> To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/20150216154625.ga1...@an3as.eu
>
>

Re: Update on Trinityrnaseq packaging

[Andreas Tille]

Hi Michael,

On Mon, Feb 16, 2015 at 07:09:18AM +, Michael Crusoe wrote:
> 
> To-do:
> dependencies needing review & uploading to Debian:
> ...
> - [ ] transdecoder

I had some quick look into this and did some changed (please pull).
I realised that some large files are installed into

   /usr/lib/transdecoder/sample_data

The name of this dir might support the suspicion that these data are not
necessary for using transdecoder but rather for testing.  If this is
true I'd recommend separating these files into a package

   transdecoder-data

(which has architecture all).

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150216154625.ga1...@an3as.eu

Re: Update on Trinityrnaseq packaging

[Andreas Tille]

Hi Michael,

On Mon, Feb 16, 2015 at 07:09:18AM +, Michael Crusoe wrote:
> To-do:
> dependencies needing review & uploading to Debian:
> - [ ] libjung-java
> - [ ] rsem
> - [ ] express
> - [ ] transdecoder

OK, just ping me if one or more are ready for sponsering.

> - [ ] jaligner

Just uploaded after some slight changes.

Thanks for your work

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150216090920.gb23...@an3as.eu

Re: Update on Trinityrnaseq packaging

[Michael Crusoe]

Done:
parafly has been submitted to the NEW queue (tille)
Trinity has a man page (tille)
hardening-no-relro usr/lib/trinityrnaseq/Chrysalis/* fixed
jar-not-in-usr-share usr/lib/trinityrnaseq/Butterfly/Butterfly.jar
update to release 2.0.4

To-do:
dependencies needing review & uploading to Debian:
- [ ] libjung-java
- [ ] rsem
- [ ] express
- [ ] transdecoder
- [ ] jaligner

Almost done!

Re: Update on Trinityrnaseq packaging

[Michael Crusoe]

On Fri Feb 13 2015 at 10:37:29 AM Andreas Tille  wrote:

> Hi Michael,
>
> On Thu, Feb 12, 2015 at 11:03:48PM +, Michael Crusoe wrote:
> > > > Nothing coming up. Probably Broad Foundation employees / interns. I
> think
> > > > they are covered by the existing entry.
> > >
> > > Finally it does not matter what you think but what you can convince
> > > ftpmaster to accept. ;-)
> > >
> >
> > Indeed, but it'll get properly packaged with transdecoder. Lacking an
> > upstream distribution site makes a pretty clear case for not having its
> own
> > package.
>
> Well, fine for me whatever you consider the most promising approach.  I
> just wanted to make you aware that there might be other hurdles if you
> avoid this one. :-)
>

Transcoder is basically done.

I found an upstream source for ParaFly: http://parafly.sourceforge.net/ &
am packaging it now.


>
> Kind regards
>
>   Andreas.
>
> --
> http://fam-tille.de
>
>
> --
> To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/20150213083712.gf30...@an3as.eu
>
>

Re: Update on Trinityrnaseq packaging

[Michael Crusoe]

On Fri Feb 13 2015 at 2:31:21 PM Andreas Tille  wrote:

> On Thu, Feb 12, 2015 at 11:03:48PM +, Michael Crusoe wrote:
> > > a cleaned up archive.  You can get this by
> > >
> > > debian/rules get-orig-source
> > >
> > > ... or if you want to save your bandwidth via
> > >
> > > mk-origtargz --repack --compress xz  source>
> > >
> >
> > Yeah, I had tried that; I get this head-scratching response:
> >
> > mcrusoe@athyra:~/debian/trinityrnaseq$ mk-origtargz --repack --compress
> xz
> > ../v2.0.3.tar.gz
> > tar: trinityrnaseq-2.0.3/Butterfly/src/lib/jung-graph-impl-2.0.1.jar:
> Not
> > found in archive
> > tar: trinityrnaseq-2.0.3/Butterfly/src/lib/jung-api-2.0.1.jar: Not
> found in
> > archive
> > tar: trinityrnaseq-2.0.3/Butterfly/src/lib/jung-algorithms-2.0.1.jar:
> Not
> > found in archive
> > tar: trinityrnaseq-2.0.3/Butterfly/src/lib/java-getopt-1.0.13.jar: Not
> > found in archive
> > tar: trinityrnaseq-2.0.3/Butterfly/src/lib/collections-generic-4.01.jar:
> > Not found in archive
> > tar: trinityrnaseq-2.0.3/Butterfly/src/lib/Jaligner.jar: Not found in
> > archive
> > tar: trinityrnaseq-2.0.3/Butterfly/prev_vers/Butterfly_r2013_08_14.jar:
> Not
> > found in archive
> > tar: Exiting with failure status due to previous errors
>
> I created trinityrnaseq_2.0.3+dfsg.orig.tar.xz from pristinetar and
> renamed
> it to trinityrnaseq_2.0.3+dfsg__.orig.tar.xz.  Than I tried:
>
> $ mk-origtargz ../trinityrnaseq_2.0.3+dfsg__.orig.tar.xz
> Successfully repacked ../trinityrnaseq_2.0.3+dfsg__.orig.tar.xz as
> ../trinityrnaseq_2.0.3+dfsg.orig.tar.xz, deleting 15 files from it.
>
> which looks good ... at least when using some random older version of
> devscripts which I had by chance installed on the box I used to try
> (2.14.10).  After installing the current devscipts 2.15.1 I can
> reproduce the problem above.  I remember that I needed to change some
> Files-Excluded expressions recently for the very same reason.  I'll
> track this down further and will come up with a solution later (today or
> tomorrow).
>

Thanks for tracking this down.


>
> BTW, thanks for flooding our reporitory with more and more great
> software.  That's a very appreciated effort and I really like this
> effect after sprints.
>

You are very welcome. We are all in this together!

Re: Update on Trinityrnaseq packaging

[Andreas Tille]

On Thu, Feb 12, 2015 at 11:03:48PM +, Michael Crusoe wrote:
> > a cleaned up archive.  You can get this by
> >
> > debian/rules get-orig-source
> >
> > ... or if you want to save your bandwidth via
> >
> > mk-origtargz --repack --compress xz 
> >
> 
> Yeah, I had tried that; I get this head-scratching response:
> 
> mcrusoe@athyra:~/debian/trinityrnaseq$ mk-origtargz --repack --compress xz
> ../v2.0.3.tar.gz
> tar: trinityrnaseq-2.0.3/Butterfly/src/lib/jung-graph-impl-2.0.1.jar: Not
> found in archive
> tar: trinityrnaseq-2.0.3/Butterfly/src/lib/jung-api-2.0.1.jar: Not found in
> archive
> tar: trinityrnaseq-2.0.3/Butterfly/src/lib/jung-algorithms-2.0.1.jar: Not
> found in archive
> tar: trinityrnaseq-2.0.3/Butterfly/src/lib/java-getopt-1.0.13.jar: Not
> found in archive
> tar: trinityrnaseq-2.0.3/Butterfly/src/lib/collections-generic-4.01.jar:
> Not found in archive
> tar: trinityrnaseq-2.0.3/Butterfly/src/lib/Jaligner.jar: Not found in
> archive
> tar: trinityrnaseq-2.0.3/Butterfly/prev_vers/Butterfly_r2013_08_14.jar: Not
> found in archive
> tar: Exiting with failure status due to previous errors

I created trinityrnaseq_2.0.3+dfsg.orig.tar.xz from pristinetar and renamed
it to trinityrnaseq_2.0.3+dfsg__.orig.tar.xz.  Than I tried:

$ mk-origtargz ../trinityrnaseq_2.0.3+dfsg__.orig.tar.xz 
Successfully repacked ../trinityrnaseq_2.0.3+dfsg__.orig.tar.xz as 
../trinityrnaseq_2.0.3+dfsg.orig.tar.xz, deleting 15 files from it.

which looks good ... at least when using some random older version of
devscripts which I had by chance installed on the box I used to try
(2.14.10).  After installing the current devscipts 2.15.1 I can
reproduce the problem above.  I remember that I needed to change some
Files-Excluded expressions recently for the very same reason.  I'll
track this down further and will come up with a solution later (today or
tomorrow).

BTW, thanks for flooding our reporitory with more and more great
software.  That's a very appreciated effort and I really like this
effect after sprints.

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150213123104.gh30...@an3as.eu

Re: Update on Trinityrnaseq packaging

[Andreas Tille]

Hi Michael,

On Thu, Feb 12, 2015 at 11:03:48PM +, Michael Crusoe wrote:
> 
> > [Reply to list only]
> 
> We are oppositely calibrated :-D I prefer to be CC'd even when I am a
> subscriber and you don't.

Well, I've got my calibration as a beginner @lists.debian.org.
Sometimes you get rude comments if you ignore the list policy which is
to not CC subscribers.  I like to propagate this message in a nicer way.
:-)  Just to let you know when posting to other lists ...
 
> >
> > debian/rules get-orig-source
> >
> > ... or if you want to save your bandwidth via
> >
> > mk-origtargz --repack --compress xz 
> >
> 
> Yeah, I had tried that; I get this head-scratching response:
> 
> mcrusoe@athyra:~/debian/trinityrnaseq$ mk-origtargz --repack --compress xz
> ../v2.0.3.tar.gz
> tar: trinityrnaseq-2.0.3/Butterfly/src/lib/jung-graph-impl-2.0.1.jar: Not
> found in archive
> tar: trinityrnaseq-2.0.3/Butterfly/src/lib/jung-api-2.0.1.jar: Not found in
> archive
> tar: trinityrnaseq-2.0.3/Butterfly/src/lib/jung-algorithms-2.0.1.jar: Not
> found in archive
> tar: trinityrnaseq-2.0.3/Butterfly/src/lib/java-getopt-1.0.13.jar: Not
> found in archive
> tar: trinityrnaseq-2.0.3/Butterfly/src/lib/collections-generic-4.01.jar:
> Not found in archive
> tar: trinityrnaseq-2.0.3/Butterfly/src/lib/Jaligner.jar: Not found in
> archive
> tar: trinityrnaseq-2.0.3/Butterfly/prev_vers/Butterfly_r2013_08_14.jar: Not
> found in archive
> tar: Exiting with failure status due to previous errors
> 
> (I checked and they do exist)

I'll check later - I'm in a hurry, right now.

Just watch the commits.
 
> > > Nothing coming up. Probably Broad Foundation employees / interns. I think
> > > they are covered by the existing entry.
> >
> > Finally it does not matter what you think but what you can convince
> > ftpmaster to accept. ;-)
> >
> 
> Indeed, but it'll get properly packaged with transdecoder. Lacking an
> upstream distribution site makes a pretty clear case for not having its own
> package.

Well, fine for me whatever you consider the most promising approach.  I
just wanted to make you aware that there might be other hurdles if you
avoid this one. :-)

Kind regards

  Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150213083712.gf30...@an3as.eu

Re: Update on Trinityrnaseq packaging

[Michael Crusoe]

On Fri Feb 13 2015 at 12:55:49 AM Andreas Tille  wrote:

> [Reply to list only]
>

We are oppositely calibrated :-D I prefer to be CC'd even when I am a
subscriber and you don't.

> On Thu, Feb 12, 2015 at 09:42:45PM +, Michael Crusoe wrote:
> > > > - [ ] binary-without-manpage usr/bin/Trinity
> > >
> > > Same as above.  It would be nice to have (even nicer than hardening)
> > > there are cases where it is hard to write a sensible manpage.
> >
> > I've produced one with help2man.
>
> That's usually the cheapest way and fine for the most cases.
> Unfortunately it did not worked in this case - I commited a manually
> edited manpage based on yours.  The result at least fits nroff syntax.
> :-)

Thanks!


> > >  * trinity-plugins/Trimmomatic-0.32: Binary without source!
> > >Trimmomatic is packaged in this version anyway - so this should
> > >be simply dropped via Files-Excluded
> > >
> >
> > Done
>
> OK - but the dir remains in the Git repository.  You should import
> a cleaned up archive.  You can get this by
>
> debian/rules get-orig-source
>
> ... or if you want to save your bandwidth via
>
> mk-origtargz --repack --compress xz 
>

Yeah, I had tried that; I get this head-scratching response:

mcrusoe@athyra:~/debian/trinityrnaseq$ mk-origtargz --repack --compress xz
../v2.0.3.tar.gz
tar: trinityrnaseq-2.0.3/Butterfly/src/lib/jung-graph-impl-2.0.1.jar: Not
found in archive
tar: trinityrnaseq-2.0.3/Butterfly/src/lib/jung-api-2.0.1.jar: Not found in
archive
tar: trinityrnaseq-2.0.3/Butterfly/src/lib/jung-algorithms-2.0.1.jar: Not
found in archive
tar: trinityrnaseq-2.0.3/Butterfly/src/lib/java-getopt-1.0.13.jar: Not
found in archive
tar: trinityrnaseq-2.0.3/Butterfly/src/lib/collections-generic-4.01.jar:
Not found in archive
tar: trinityrnaseq-2.0.3/Butterfly/src/lib/Jaligner.jar: Not found in
archive
tar: trinityrnaseq-2.0.3/Butterfly/prev_vers/Butterfly_r2013_08_14.jar: Not
found in archive
tar: Exiting with failure status due to previous errors

(I checked and they do exist)


> > >  * trinity-plugins/fstrozzi-Fastool-7c3e034f05: While mentioned
> > >properly in d/copyright I'd at least refer to the download
> > >location
> > >  https://github.com/fstrozzi/Fastool
> > >in a Comment: field.  I'd regard it as the better solution to
> > >create a separate package since it might be considered useful
> > >for people not only using it via trinityrnaseq
> >
> > I've added the comment. As for packaging it separately I'll leave this to
> > some other motivated individual to do so. There are a lot of
> bioinformatics
> > libraries that are functionally single use.
>
> May be I'll care for this in some MoM project.  Usually these small
> tools are easy targets and than it should be done also for the sake of
> separate testing.
>

Have fun!


>
> > >  * trinity-plugins/parafly/src/ParaFly.cpp:
> > > Authors of this wrapper are MB Couger (mbcouger(AT Symbol)
> gmail.com,
> > > Matt Stowe mstowe(AT Symbol)okstate.edu
> > >This should at least deserve an extra d/copyright line and you
> > >should also dig for the original download location.  I can
> > >not evaluate the sense of a separate package.
> > >
> >
> > Nothing coming up. Probably Broad Foundation employees / interns. I think
> > they are covered by the existing entry.
>
> Finally it does not matter what you think but what you can convince
> ftpmaster to accept. ;-)
>

Indeed, but it'll get properly packaged with transdecoder. Lacking an
upstream distribution site makes a pretty clear case for not having its own
package.

Re: Update on Trinityrnaseq packaging

[Andreas Tille]

[Reply to list only]

Hi Michael,

On Thu, Feb 12, 2015 at 09:42:45PM +, Michael Crusoe wrote:
> > ...
> > code I have seen (not too much admittedly) had extra *.so files in
> > /usr/lib.  If you are unsure asking on debian-j...@lists.debian.org is
> > the best way to clarify.
> 
> Upon review they are pure Java

:-)
 
> > > - [ ] binary-without-manpage usr/bin/Trinity
> >
> > Same as above.  It would be nice to have (even nicer than hardening)
> > there are cases where it is hard to write a sensible manpage.
> 
> I've produced one with help2man.

That's usually the cheapest way and fine for the most cases.
Unfortunately it did not worked in this case - I commited a manually
edited manpage based on yours.  The result at least fits nroff syntax.
:-)
 
> > > - [ ] script-not-executable: several
> >
> > Usually this is either easy to fix or contains a hidden problem that
> > should be fixed.
> 
> Fixed

Good!
 
> >  * `licensecheck -r *` did not uncover anything suspicious to me
> >  * trinity-plugins/GAL_0.2.1: This third party code should be
> >specified separately with the license that can be found in the
> >downloadable archive at
> > http://www.sequenceontology.org/software/GAL_Code/
> >However, I'd prefer packaging GAL separately (in the latest
> >version)
> 
> Sure, for another day :-)

:-)
 
> >  * trinity-plugins/Trimmomatic-0.32: Binary without source!
> >Trimmomatic is packaged in this version anyway - so this should
> >be simply dropped via Files-Excluded
> >
> 
> Done

OK - but the dir remains in the Git repository.  You should import
a cleaned up archive.  You can get this by

debian/rules get-orig-source

... or if you want to save your bandwidth via

mk-origtargz --repack --compress xz 

Afterwards do

git import-orig --pristine-tar 

> >  * trinity-plugins/collectl: Packaged for Debian.  Once you are
> >removing files via Files-Excluded the most easy thing would be
> >to delete this as well which saves you the work of mentioning
> >it in d/copyright
> 
> Only used via a hidden option. Excluded and added as a 'suggests'

If you are sure that it should not be Recommends that's fine for me.

> >  * trinity-plugins/fstrozzi-Fastool-7c3e034f05: While mentioned
> >properly in d/copyright I'd at least refer to the download
> >location
> >  https://github.com/fstrozzi/Fastool
> >in a Comment: field.  I'd regard it as the better solution to
> >create a separate package since it might be considered useful
> >for people not only using it via trinityrnaseq
> 
> I've added the comment. As for packaging it separately I'll leave this to
> some other motivated individual to do so. There are a lot of bioinformatics
> libraries that are functionally single use.

May be I'll care for this in some MoM project.  Usually these small
tools are easy targets and than it should be done also for the sake of
separate testing.

> >  * trinity-plugins/parafly/src/ParaFly.cpp:
> > Authors of this wrapper are MB Couger (mbcouger(AT Symbol)gmail.com,
> > Matt Stowe mstowe(AT Symbol)okstate.edu
> >This should at least deserve an extra d/copyright line and you
> >should also dig for the original download location.  I can
> >not evaluate the sense of a separate package.
> >
> 
> Nothing coming up. Probably Broad Foundation employees / interns. I think
> they are covered by the existing entry.

Finally it does not matter what you think but what you can convince
ftpmaster to accept. ;-)

> >  * trinity-plugins/slclust: Same as for Fasttool - I'd really
> >love to see a separate package from
> >  http://sourceforge.net/projects/slclust/
> 
> See above :-)

Yup.
 
> >  * trinity-plugins/TransDecoder_r20140704.tar.gz:
> >Same as for Fasttool / slclust:
> >  https://transdecoder.github.io/
> 
> 
> Gah, this contains two programs already packaged (cd-hit & ffindex (two
> versions!)) and another copy of Parafly. Looks like this will require a
> separate package just to keep the source clean. Trinity can use the Parafly
> from this (yet to be created) package.
 
Sometimes the packaging view uncovers this kind of ugly things ...
 
> >  * trinity-plugins/jellyfish-2.1.4.tar.gz: --> Files-Excluded
> >since we have a separate package
> >  * trinity-plugins/rsem-1.2.19.tar.gz: --> Files-Excluded since
> >you ITP it as you wrote below
> 
> Done.

OK.
 
> > Please feel free to ask for help here if you agree that Fastool, slclust
> > and transdecoder should be packaged separately.  I could even try to
> > work in a MoM project with some potential student on these.
> >
> > > trinityrnaseq has two unfulfilled dependencies: rsem & express
> > >
> > > rsem
> > > - [ ] lacks manpages
> > > - [ ] lacks ITP
> > >
> > > express:
> > > - [ ] lacks ITP
> >
> > Thanks for sending this kind of status messages.  That's really helpful
> > and enables team input.
> 
> Go team!

... nice you like the cooperation

 Andreas.

-- 
http://fam

Re: Update on Trinityrnaseq packaging

[Michael Crusoe]

On Thu Feb 12 2015 at 9:53:12 AM Andreas Tille  wrote:

> On Thu, Feb 12, 2015 at 12:16:57AM +, Michael Crusoe wrote:
> > - [ ] hardening-no-relro usr/lib/trinityrnaseq/Chrysalis/*
> > Needs investigation
>
> While fixing this is nice to have I would not insist on it for sponsoring
> the package.
>

Good to know!


>
> > - [ ] jar-not-in-usr-share usr/lib/trinityrnaseq/
> Butterfly/Butterfly.jar,
> > usr/lib/trinityrnaseq/util/support_scripts/ExitTester.jar
> > May be fixable with a move + symlink. Need to make sure that they are
> pure
> > Java
>
> I'm not a Java expert but IMHO all JARs are machine independent and thus
> should reside in /usr/share.  All Java packages with machine dependant
> code I have seen (not too much admittedly) had extra *.so files in
> /usr/lib.  If you are unsure asking on debian-j...@lists.debian.org is

the best way to clarify.
>

Upon review they are pure Java


>
> > - [ ] binary-without-manpage usr/bin/Trinity
>
> Same as above.  It would be nice to have (even nicer than hardening)
> there are cases where it is hard to write a sensible manpage.
>

I've produced one with help2man.


> > - [ ] script-not-executable: several
>
> Usually this is either easy to fix or contains a hidden problem that
> should be fixed.
>

Fixed


>
> > - [ ] debian/copyright needs audit
>
>  * lacking "Files: debian/*" paragraph
>

Fixed.


>  * `licensecheck -r *` did not uncover anything suspicious to me
>  * trinity-plugins/GAL_0.2.1: This third party code should be
>specified separately with the license that can be found in the
>downloadable archive at
> http://www.sequenceontology.org/software/GAL_Code/
>However, I'd prefer packaging GAL separately (in the latest
>version)
>

Sure, for another day :-)


>  * trinity-plugins/Trimmomatic-0.32: Binary without source!
>Trimmomatic is packaged in this version anyway - so this should
>be simply dropped via Files-Excluded
>

Done


>  * trinity-plugins/collectl: Packaged for Debian.  Once you are
>removing files via Files-Excluded the most easy thing would be
>to delete this as well which saves you the work of mentioning
>it in d/copyright
>

Only used via a hidden option. Excluded and added as a 'suggests'


>  * trinity-plugins/fstrozzi-Fastool-7c3e034f05: While mentioned
>properly in d/copyright I'd at least refer to the download
>location
>  https://github.com/fstrozzi/Fastool
>in a Comment: field.  I'd regard it as the better solution to
>create a separate package since it might be considered useful
>for people not only using it via trinityrnaseq
>

I've added the comment. As for packaging it separately I'll leave this to
some other motivated individual to do so. There are a lot of bioinformatics
libraries that are functionally single use.


>  * trinity-plugins/parafly/src/ParaFly.cpp:
> Authors of this wrapper are MB Couger (mbcouger(AT Symbol)gmail.com,
> Matt Stowe mstowe(AT Symbol)okstate.edu
>This should at least deserve an extra d/copyright line and you
>should also dig for the original download location.  I can
>not evaluate the sense of a separate package.
>

Nothing coming up. Probably Broad Foundation employees / interns. I think
they are covered by the existing entry.


>  * trinity-plugins/slclust: Same as for Fasttool - I'd really
>love to see a separate package from
>  http://sourceforge.net/projects/slclust/


See above :-)

>
>  * trinity-plugins/TransDecoder_r20140704.tar.gz:
>Same as for Fasttool / slclust:
>  https://transdecoder.github.io/


Gah, this contains two programs already packaged (cd-hit & ffindex (two
versions!)) and another copy of Parafly. Looks like this will require a
separate package just to keep the source clean. Trinity can use the Parafly
from this (yet to be created) package.


>  * trinity-plugins/jellyfish-2.1.4.tar.gz: --> Files-Excluded
>since we have a separate package
>  * trinity-plugins/rsem-1.2.19.tar.gz: --> Files-Excluded since
>you ITP it as you wrote below
>

Done.



> Please feel free to ask for help here if you agree that Fastool, slclust
> and transdecoder should be packaged separately.  I could even try to
> work in a MoM project with some potential student on these.
>
> > trinityrnaseq has two unfulfilled dependencies: rsem & express
> >
> > rsem
> > - [ ] lacks manpages
> > - [ ] lacks ITP
> >
> > express:
> > - [ ] lacks ITP
>
> Thanks for sending this kind of status messages.  That's really helpful
> and enables team input.
>

Go team!

Re: Update on Trinityrnaseq packaging

[Andreas Tille]

On Thu, Feb 12, 2015 at 12:16:57AM +, Michael Crusoe wrote:
> - [ ] hardening-no-relro usr/lib/trinityrnaseq/Chrysalis/*
> Needs investigation

While fixing this is nice to have I would not insist on it for sponsoring
the package.

> - [ ] jar-not-in-usr-share usr/lib/trinityrnaseq/Butterfly/Butterfly.jar,
> usr/lib/trinityrnaseq/util/support_scripts/ExitTester.jar
> May be fixable with a move + symlink. Need to make sure that they are pure
> Java

I'm not a Java expert but IMHO all JARs are machine independent and thus
should reside in /usr/share.  All Java packages with machine dependant
code I have seen (not too much admittedly) had extra *.so files in
/usr/lib.  If you are unsure asking on debian-j...@lists.debian.org is
the best way to clarify.

> - [ ] binary-without-manpage usr/bin/Trinity

Same as above.  It would be nice to have (even nicer than hardening)
there are cases where it is hard to write a sensible manpage.

> - [ ] script-not-executable: several

Usually this is either easy to fix or contains a hidden problem that
should be fixed.

> - [ ] debian/copyright needs audit

 * lacking "Files: debian/*" paragraph
 * `licensecheck -r *` did not uncover anything suspicious to me
 * trinity-plugins/GAL_0.2.1: This third party code should be
   specified separately with the license that can be found in the
   downloadable archive at
http://www.sequenceontology.org/software/GAL_Code/
   However, I'd prefer packaging GAL separately (in the latest
   version)
 * trinity-plugins/Trimmomatic-0.32: Binary without source!
   Trimmomatic is packaged in this version anyway - so this should
   be simply dropped via Files-Excluded
 * trinity-plugins/collectl: Packaged for Debian.  Once you are
   removing files via Files-Excluded the most easy thing would be
   to delete this as well which saves you the work of mentioning
   it in d/copyright
 * trinity-plugins/fstrozzi-Fastool-7c3e034f05: While mentioned
   properly in d/copyright I'd at least refer to the download
   location
 https://github.com/fstrozzi/Fastool
   in a Comment: field.  I'd regard it as the better solution to
   create a separate package since it might be considered useful
   for people not only using it via trinityrnaseq
 * trinity-plugins/parafly/src/ParaFly.cpp: 
Authors of this wrapper are MB Couger (mbcouger(AT Symbol)gmail.com, Matt 
Stowe mstowe(AT Symbol)okstate.edu
   This should at least deserve an extra d/copyright line and you
   should also dig for the original download location.  I can
   not evaluate the sense of a separate package.
 * trinity-plugins/slclust: Same as for Fasttool - I'd really
   love to see a separate package from
 http://sourceforge.net/projects/slclust/
 * trinity-plugins/TransDecoder_r20140704.tar.gz:
   Same as for Fasttool / slclust:
 https://transdecoder.github.io/
 * trinity-plugins/jellyfish-2.1.4.tar.gz: --> Files-Excluded
   since we have a separate package
 * trinity-plugins/rsem-1.2.19.tar.gz: --> Files-Excluded since
   you ITP it as you wrote below

Please feel free to ask for help here if you agree that Fastool, slclust
and transdecoder should be packaged separately.  I could even try to
work in a MoM project with some potential student on these.

> trinityrnaseq has two unfulfilled dependencies: rsem & express
> 
> rsem
> - [ ] lacks manpages
> - [ ] lacks ITP
> 
> express:
> - [ ] lacks ITP

Thanks for sending this kind of status messages.  That's really helpful
and enables team input.

Kind regards

  Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150212075253.gb28...@an3as.eu

Update on Trinityrnaseq packaging

[Michael Crusoe]

- [ ] hardening-no-relro usr/lib/trinityrnaseq/Chrysalis/*
Needs investigation
- [ ] jar-not-in-usr-share usr/lib/trinityrnaseq/Butterfly/Butterfly.jar,
usr/lib/trinityrnaseq/util/support_scripts/ExitTester.jar
May be fixable with a move + symlink. Need to make sure that they are pure
Java
- [ ] binary-without-manpage usr/bin/Trinity
- [ ] script-not-executable: several
- [ ] debian/copyright needs audit

trinityrnaseq has two unfulfilled dependencies: rsem & express

rsem
- [ ] lacks manpages
- [ ] lacks ITP

express:
- [ ] lacks ITP