Re: picard-tools updated, and ready?

2018-05-24 Thread Olivier Sallou


On 05/24/2018 03:27 PM, Andreas Tille wrote:
> On Thu, May 24, 2018 at 03:14:29PM +0200, Olivier Sallou wrote:
>>
>> On 05/24/2018 08:35 AM, Andreas Tille wrote:
>>> Hi Olivier,
>>>
>> I can't upload to unstable as one of the deps (gkl) depends on htsjdk ,
>> and need a *recent* one (the one in experimental works, the one in sid
>> fails).
>> So to upload those picard-tools deps, we first need to put htsjdk in sid
> If this is needed we might go for it and file a fake RC bug so people
> can fall back to the version in testing.
 What do you think about this? Do we want to upload htsjdk to unstable?
>>> I've uploaded to unstable now.  Hope the currently quiete slow new 
>>> processing
>>> will speed up again soon for the dependencies. :-)
>> will you create a RC bug to prevent testing migration?
> I can do - however, I'm afraid this will not help htsjdk in testing since
> bug #877590 remains unfixed there.
>
> So what do you think, will be the best thing to do?
Bug is shown as fixed in version htsjdk/2.8.1+dfsg-2
>
> Kind regards
>
>  Andreas. 
>

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438



Re: picard-tools updated, and ready?

2018-05-24 Thread Andreas Tille
On Thu, May 24, 2018 at 03:14:29PM +0200, Olivier Sallou wrote:
> 
> 
> On 05/24/2018 08:35 AM, Andreas Tille wrote:
> > Hi Olivier,
> >
>  I can't upload to unstable as one of the deps (gkl) depends on htsjdk ,
>  and need a *recent* one (the one in experimental works, the one in sid
>  fails).
>  So to upload those picard-tools deps, we first need to put htsjdk in sid
> >>> If this is needed we might go for it and file a fake RC bug so people
> >>> can fall back to the version in testing.
> >> What do you think about this? Do we want to upload htsjdk to unstable?
> > I've uploaded to unstable now.  Hope the currently quiete slow new 
> > processing
> > will speed up again soon for the dependencies. :-)
> will you create a RC bug to prevent testing migration?

I can do - however, I'm afraid this will not help htsjdk in testing since
bug #877590 remains unfixed there.

So what do you think, will be the best thing to do?

Kind regards

 Andreas. 

-- 
http://fam-tille.de



Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-05-24 Thread Liubov Chuprikova
Hi Aaron,

On Wed, 23 May 2018 at 20:36 Aaron M. Ucko  wrote:

> Liubov Chuprikova  writes:
>
> > Please, have a look at my two last commits (
> > https://salsa.debian.org/med-team/ncbi-tools6/commits/master). Actually,
> > the first one was made a month ago.
>
> All looks good except for one formality -- Lintian considers your
> additions to debian/copyright to be incomplete:
>
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 16)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 16)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 24)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 24)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 30)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 30)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright license (paragraph
> at line 35)
> W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> (paragraph at line 35)


Andreas helped me to figure out how to fill in the copyright and license
fields for the test data. I have just pushed these changes. Let me know if
something wrong.

With regards,
Liubov


Re: picard-tools updated, and ready?

2018-05-24 Thread Olivier Sallou


On 05/24/2018 08:35 AM, Andreas Tille wrote:
> Hi Olivier,
>
> On Sat, May 19, 2018 at 08:52:50AM +0200, Andreas Tille wrote:
>> On Fri, May 04, 2018 at 04:44:20PM +0200, Andreas Tille wrote:
>>> On Fri, May 04, 2018 at 04:03:48PM +0200, Olivier Sallou wrote:
>> I tested it with htsjdk from experimental.
> I guess there is no other chance since it depends from the version
> there, right?
 I can't upload to unstable as one of the deps (gkl) depends on htsjdk ,
 and need a *recent* one (the one in experimental works, the one in sid
 fails).
 So to upload those picard-tools deps, we first need to put htsjdk in sid
>>> If this is needed we might go for it and file a fake RC bug so people
>>> can fall back to the version in testing.
>> What do you think about this? Do we want to upload htsjdk to unstable?
> I've uploaded to unstable now.  Hope the currently quiete slow new processing
> will speed up again soon for the dependencies. :-)
will you create a RC bug to prevent testing migration?
>
> Kind regards
>
>Andreas.
>

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438



Re: picard-tools updated, and ready?

2018-05-24 Thread Olivier Sallou


On 05/24/2018 08:35 AM, Andreas Tille wrote:
> Hi Olivier,
>
> On Sat, May 19, 2018 at 08:52:50AM +0200, Andreas Tille wrote:
>> On Fri, May 04, 2018 at 04:44:20PM +0200, Andreas Tille wrote:
>>> On Fri, May 04, 2018 at 04:03:48PM +0200, Olivier Sallou wrote:
>> I tested it with htsjdk from experimental.
> I guess there is no other chance since it depends from the version
> there, right?
 I can't upload to unstable as one of the deps (gkl) depends on htsjdk ,
 and need a *recent* one (the one in experimental works, the one in sid
 fails).
 So to upload those picard-tools deps, we first need to put htsjdk in sid
>>> If this is needed we might go for it and file a fake RC bug so people
>>> can fall back to the version in testing.
>> What do you think about this? Do we want to upload htsjdk to unstable?
> I've uploaded to unstable now.  Hope the currently quiete slow new processing
> will speed up again soon for the dependencies. :-)
one of deps was accepted in experimental, still waiting for others
once all are accepted, will push them to unstable (as already in NEW queue)

Olivier
>
> Kind regards
>
>Andreas.
>

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438



Re: [d...@earth.li: Bug#899129: prime-phylo: FTBFS: cd obj-x86_64-linux-gnu && make -j8 -Oline returned exit code 2]

2018-05-24 Thread Andreas Tille
Hi Lars and Erik,

On Thu, May 24, 2018 at 12:27:36PM +, Lars Arvestad wrote:
> I think Erik is right. I don’t have time to maintain the code and there is 
> better code to use out there.
> 
> Thanks a lot for having this code in Debian, but I think it is time to pull 
> the plug.

Thanks for the clarification.  From a Debian point of view its probably the
best curse of action to package the replacement first and later remove what
we have.

> But since I have the two of you on the line: what does it take to distribute 
> what essentially is a JAR-file as a Debian package? One would probably want 
> to wrap it with an additional shell-script, but that is all. Any pointers 
> appreciated.

You can not simply wrap a JAR into a DEB package - at least not into an
official Debian package.  You need all Java sources and build from
source.  That's the very short version.  In general we have quite some
record to teach interested people how to package some software.  If
you want to speed up jprime integration into Debian that would be really
appreciated.

Kind regards

   Andreas.
 
> On 24 May 2018, at 14:16, Erik Sjölund 
> mailto:erik.sjol...@gmail.com>> wrote:
> 
> Hi Andreas,
> 
> I think the future for prime-phylo (C++) does not look that good.
> No development has happened for many years as the project was abandoned
> for a Java implementation.
> https://github.com/arvestad/jprime
> 
> Although I maintained the web site
> http://prime.sbc.su.se
> before, now the DNS has changed to point to another web server
> where I don't have any log in permission.
> 
> I CC Lars Arvestad (the owner of the project), if there is anything he
> wants to add.
> 
> Best regards,
> Erik
> 
> 
> 
> 
> 
> 
> 
> 
> On Sun, May 20, 2018 at 6:31 AM, Andreas Tille  wrote:
> Hi Erik,
> 
> besides this issue (and others that where solved inside Debian
> meanwhile) I realised that the download location of PrIME has vanished.
> 
> Could you please check this?
> 
> Kind regards
> 
>   Andreas.
> 
> - Forwarded message from Dominic Hargreaves  -
> 
> Date: Sat, 19 May 2018 18:01:53 +0200
> From: Dominic Hargreaves 
> To: sub...@bugs.debian.org
> Subject: Bug#899129: prime-phylo: FTBFS: cd obj-x86_64-linux-gnu && make -j8 
> -Oline returned exit code 2
> X-Debian-PR-Message: report 899129
> X-Debian-PR-Package: src:prime-phylo
> X-Debian-PR-Keywords:
> X-Debian-PR-Source: prime-phylo
> 
> Source: prime-phylo
> Version: 1.0.11-4
> Severity: serious
> Justification: FTBFS
> User: debian-p...@lists.debian.org
> Usertags: hh2018
> 
> When testing packages against the upcoming release of perl, we found
> an unrelated FTBFS on a clean sid chroot:
> 
> cd /<>/obj-x86_64-linux-gnu/src/cxx/libraries/prime && 
> /usr/bin/c++  -DONLY_ONE_TIMESAMPLE -DPERTURBED_NODE -Dprime_phylo_EXPORTS 
> -I/<>/obj-x86_64-linux-gnu/src/cxx/libraries/prime 
> -I/<>/src/cxx/libraries/prime 
> -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi 
> -I/usr/lib/x86_64-linux-gnu/openmpi/include 
> -I/usr/lib/x86_64-linux-gnu/openmpi/include/ompi/mpi/cxx 
> -I/usr/include/libxml2 -I/<>/src/cxx/libraries 
> -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/ompi/mpi/cxx 
> -I/usr/lib/openmpi/include/openmpi/ompi/mpi/cxx  -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wreorder -Wall 
> -fexceptions -g -fPIC   -std=gnu++98 -o 
> CMakeFiles/prime-phylo.dir/TreeIO.cc.o -c 
> /<>/src/cxx/libraries/prime/TreeIO.cc
> make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> make[2]: *** [CMakeFiles/Makefile2:137: 
> src/cxx/libraries/prime/CMakeFiles/prime-phylo.dir/all] Error 2
> make[1]: *** [Makefile:155: all] Error 2
> dh_auto_build: cd obj-x86_64-linux-gnu && make -j8 -Oline returned exit code 2
> make: *** [debian/rules:10: build] Error 25
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 
> - End forwarded message -
> 
> --
> http://fam-tille.de
> 
> 
> --
> Swedish e-Science Research Center
> Science for Life Laboratory
> Dept of Mathematics
> Stockholm University
> 

-- 
http://fam-tille.de



Re: Bug#879619: Autopkgtest for ncbi-tools6

2018-05-24 Thread Liubov Chuprikova
Hi Andreas,

Thank you for your detailed answer!

On Thu, 24 May 2018 at 07:44 Andreas Tille  wrote:

> On Wed, May 23, 2018 at 10:14:56PM +0200, Liubov Chuprikova wrote:
> > > W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> > > (paragraph at line 30)
> > > W: ncbi-tools6 source: missing-field-in-dep5-copyright license
> (paragraph
> > > at line 35)
> > > W: ncbi-tools6 source: missing-field-in-dep5-copyright copyright
> > > (paragraph at line 35)
> > >
> > > (It also issues a few unrelated complaints, which I'll be happy to
> > > address myself.)
> > >
> >
> > I cannot reproduce the same lintian output on my computer.
>
> You should always install lintian from unstable.  To do so create two
> files:
>
> $ cat /etc/apt/sources.list.d/01-unstable.list
> deb http://httpredir.debian.org/debian unstable main
>
> $ cat /etc/apt/preferences.d/01-lintian.pref
> Package: lintian
> Pin: release a=unstable
> Pin-Priority: 601
>
> Package: debian-policy
> Pin: release a=unstable
> Pin-Priority: 601
>
>
> Try first
>
> $ apt-cache policy lintian
>
> which should show
>
>Candidate: 2.5.88
>
> and to make sure that your general preferences are set correctly
>
> $ apt-cache policy dpkg
>
> This should *not* have a candidate from unstable.  Otherwise add
>
> $ cat /etc/apt/preferences.d/01-unstable.pref
> Package: *
> Pin: release a=unstable
> Pin-Priority: 50
>
>
> to make sure you will not upgrade your whole system to unstable which is
> probably not what you want.  Than do
>
>sudo apt-get install lintian debian-policy
>
> (This also pulls debian-policy from unstable which is also what you
> want.)
>

I have updated lintian and debian-policy as you wrote. Now they are of
2.5.88 and 4.1.4.1 versions, respectively.


> > I tried it like
> > this:
> > lintian -i -I --show-overrides
> ncbi-tools6_6.1.20170106-3_amd64.changes
>

After that I've also noticed a mentioning of "ncbi-tools6 source" in the
warnings above and realised that I should use .dsc instead of .changes to
reproduce them.


>
> > trnascan-se_sample.output
> > I generated that file by running *trnascan-se* (another Debian Med
> > package), so I have no
> > idea what the license and copyright should be written for it. Could you
> > help me with this
> > problem?
>
> I admit I'm unsure myself.  Either it inherits the copyright of the
> original data file (which should be mentioned in trnascan-se) or you
> become the copyright owner.  Besides this I doubt that data are
> copyright-able at all.  So I would not see any problem to use
>
>   Copyright: Liubov Chuprikova
>   License: public_domain
>

Ok, I've decided to mention myself as a copyright owner. By the way,
trnascan-se_sample.output already has a mentioning about tRNAscan-SE
(including tRNAscan-SE's copyright and license info). But, as you wrote,
the data itself can hardly follow the same license as the program.

Thanks again!
Liubov