[RFS] streamz

[Nilesh Patra]

Hi,
I've packaged a NEW module: streamz - Helps build pipelines to manage
continuous streams of data.
It builds in a clean chroot with passing tests.
I've pushed my changes to team-repo[1].

*NB: The license on the repo looks like an exact copy of BSD-3-clause
license.  However, it has some missing cosmetic changes (Missing numbering
for example).
It would be great if it could be confirmed that using BSD-3-clause license
here is OK*

This needs review and sponsorship.

Thanks and regards
Nilesh

Re: RFS: insilicoseq [ITP]

[Sao I Kuan]

Hi, Andreas,

Thanks for your careful review.

On Thu, Jun 11, 2020 at 2:16 AM Andreas Tille  wrote:
>
> Ahhh and please check calling /usr/bin/iss without any
> argument throws a strange warning...

I patched argument error and forwarded the bug to upstream[1].
[1] https://github.com/HadrienG/InSilicoSeq/issues/177

> On Wed, Jun 10, 2020 at 07:11:54PM +0200, Andreas Tille wrote:
> > Hi,
> > Very short notice since I'm busy with real life:
> > I've added a primitive manpage.  Would you be able to
> > check whether you can write a simple autopkgtest using
> > the provided data?  I browsed the README quickly and
> > it should be possible (at least at first sight)

Thanks a lot :) and I have added autopkgtest and it worked.

Sincerely,

Sao I Kuan
saoik...@gmail.com

RFS: seirsplus [ITP]

[Sao I Kuan]

Hi,

I'm looking for a sponsor for the package:
  * seirsplus (#962942)

The package is on:
https://salsa.debian.org/med-team/seirsplus

The package is lintian-clean.

Please consider reviewing and sponsoring this. Any kind of suggestions
are appreciated.

Thank you!

Sincerely,

Sao I Kuan
saoik...@gmail.com

Re: Tandem Repeats Finder License Terms

[Andreas Tille]

Hi again,

in my talk I simply assumed that Tandem Repeats Finder will be released
soon with a free license.  The Debian Med team is now running the second
COVID-19 sprint.  So more packaging power is available for this week and
it would be really great if you could put some part of it into trf.

Are there any stumbling stones with the free release?

Kind regards

  Andreas.

On Sat, May 30, 2020 at 04:52:27PM +0200, Andreas Tille wrote:
> Hi again Gary,
> 
> I do not want to sound impatient.  I'm just drafting my talk for
> MiniDebConf online which I will hold tomorrow.  I would like to report
> about success of our sprint.  I would love to point to a repository with
> freely licensed Tandem Repeats Finder if it exists.  So just not missing
> some important outcome of our sprint.
> 
> So is there any progress from your side or should we keep on waiting
> patiently?
> 
> Kind regards
> 
>  Andreas.
> 
> On Sun, May 10, 2020 at 01:26:08PM +0200, Étienne Mollier wrote:
> > Dear Gary,
> > 
> > This is amazing!  Thank you so much for your decision!
> > Yes please, let us know once the source code is available, so
> > the packaging of Tandem Repeats Finder can start.
> > 
> > Kind Regards,
> > Étienne Mollier 
> > for the Debian Med Team 
> > 
> > Gary Benson, on 2020-05-09 16:32:03 -0400:
> > > Dear Étienne,
> > > 
> > > I'm making TRF open source with an AGPL license.  Hopefully this
> > > will be completed in a week or two.
> > > 
> > > I'll send a link to the github repository when it's ready.
> > > 
> > > Sincerely,
> > > Gary Benson
> > > 
> > > On 5/8/20 1:18 PM, Étienne Mollier wrote:
> > > > Greetings Mr. Gary Benson and Yözen Hernández,
> > > > 
> > > > I'm in the process of giving a hand to the Debian Med Team with
> > > > maintaining several applications for the Debian project.  In the
> > > > context of the Covid-19 pandemic, the need for easing access to
> > > > applications related to the medical field, notably virology, has
> > > > become dire, and there is a list of projects that has been
> > > > established by the Debian Med Team which is considered a
> > > > priority work, see:
> > > > 
> > > > 
> > > > https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/COVID-19-Hackathon-packages-needing-work
> > > > 
> > > > So in this context, I've begun packaging VirusSeeker, initially
> > > > written in the Washington University in St. Louis, and this
> > > > program makes use of RepeatMasker for one of its processing
> > > > steps.  This program, in turn, depends on Tandem Repeats Finder.
> > > > However, the current licensing terms are making TRF incompatible
> > > > with integration into the main Debian repository, thus render
> > > > RepeatMasker and VirusSeeker both ineligible to it as well.
> > > > 
> > > > I was wondering if it were possible to open the source code of
> > > > TRF, and choose licensing terms that would be compatible with an
> > > > integration into Debian main repository, for instance by using
> > > > the GPL-3 or the MIT license, or whichever terms suits your
> > > > taste among the ones considered DFSG compatible:
> > > > 
> > > > https://wiki.debian.org/DFSGLicenses#DFSG-compatible_Licenses
> > > > 
> > > > In hope your licensing change will help us all moving forward,
> > > > Kind Regards,
> 
> 
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Re: RFS: insilicoseq [ITP]

[Andreas Tille]

Hi Sao,

On Tue, Jun 16, 2020 at 08:09:39PM +0900, Sao I Kuan wrote:
> Thanks for your careful review.

The main thanks goes to you for the tough work.
 
> On Thu, Jun 11, 2020 at 2:16 AM Andreas Tille  wrote:
> 
> I patched argument error and forwarded the bug to upstream[1].
> [1] https://github.com/HadrienG/InSilicoSeq/issues/177

Very good.  Forwarding the issue with a solution is the perfect
way to deal with this.
 
> > On Wed, Jun 10, 2020 at 07:11:54PM +0200, Andreas Tille wrote:
> > > Very short notice since I'm busy with real life:
> > > I've added a primitive manpage.  Would you be able to
> > > check whether you can write a simple autopkgtest using
> > > the provided data?  I browsed the README quickly and
> > > it should be possible (at least at first sight)
> 
> Thanks a lot :) and I have added autopkgtest and it worked.

Also very good.  The only thing is that I get a single failure:


test_util.test_concatenate ... ok
test_util.test_concatenate_read_only ... FAIL
test_util.test_compress ... ok

==
FAIL: test_util.test_concatenate_read_only
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File "/usr/lib/python3/dist-packages/nose/tools/nontrivial.py", line 67, in 
newfunc
raise AssertionError(message)
AssertionError: test_concatenate_read_only() did not raise SystemExit
 >> begin captured logging << 
iss.util: INFO: Stitching input files together
- >> end captured logging << -

--
Ran 41 tests in 34.881s

FAILED (failures=1)
autopkgtest [13:25:22]: test run-unit-test: ---]
autopkgtest [13:25:22]: test run-unit-test:  - - - - - - - - - - results - - - 
- - - - - - -
run-unit-testFAIL non-zero exit status 1


I admit it happened that my pbuilder had tricked me in the past and for
unknown circumstances some test failed.  So if you confirm again it
works for you I'd consider uploading and once the package might be
accepted we'll see how it behaves on debci and can act accordingly.

Thanks again for your contribution

 Andreas.

-- 
http://fam-tille.de

[RFS] shovill

[Nilesh Patra]

Hi,
I've packaged a NEW module: shovill - Assemble bacterial isolate genomes
from Illumina paired-end reads
It builds in a clean chroot. I've not added autopkgtests at the moment
since some of the dependencies are still in NEW, and it would be better
suited (for me) to add these once the dependencies are accepted.
I've pushed my changes to team-repo[1].
This needs review and sponsorship.

[1]: https://salsa.debian.org/med-team/shovill

Thanks and regards
Nilesh

Re: RFS: seirsplus [ITP]

[Andreas Tille]

Dear Sao,

On Tue, Jun 16, 2020 at 08:14:36PM +0900, Sao I Kuan wrote:
> I'm looking for a sponsor for the package:
>   * seirsplus (#962942)
> 
> The package is on:
> https://salsa.debian.org/med-team/seirsplus
> 
> The package is lintian-clean.
> 
> Please consider reviewing and sponsoring this. Any kind of suggestions
> are appreciated.

Uploaded with a slight fix for a lintian info (please git pull).

Thanks a lot for your work

 Andreas.

PS: Do you think you can make it to our video conference today? 

-- 
http://fam-tille.de

Re: [RFS] shovill

[Andreas Tille]

On Tue, Jun 16, 2020 at 07:08:04PM +0530, Nilesh Patra wrote:
> Hi,
> I've packaged a NEW module: shovill - Assemble bacterial isolate genomes
> from Illumina paired-end reads
> It builds in a clean chroot. I've not added autopkgtests at the moment
> since some of the dependencies are still in NEW, and it would be better
> suited (for me) to add these once the dependencies are accepted.
> I've pushed my changes to team-repo[1].
> This needs review and sponsorship.

Reviewed and sponsored.  Thanks a lot for your work on this

 Andreas.

-- 
http://fam-tille.de

Re: [RFS] streamz

[Andreas Tille]

On Tue, Jun 16, 2020 at 04:09:05PM +0530, Nilesh Patra wrote:
> Hi,
> I've packaged a NEW module: streamz - Helps build pipelines to manage
> continuous streams of data.
> It builds in a clean chroot with passing tests.
> I've pushed my changes to team-repo[1].
> 
> *NB: The license on the repo looks like an exact copy of BSD-3-clause
> license.  However, it has some missing cosmetic changes (Missing numbering
> for example).
> It would be great if it could be confirmed that using BSD-3-clause license
> here is OK*

I think its OK.
 
> This needs review and sponsorship.

Reviewed and sponsored.

Thanks for your work on this
Andreas.

-- 
http://fam-tille.de

[RFS] yanosim

[Nilesh Patra]

Hi,
I've packaged a NEW module: shovill - Assemble bacterial isolate genomes
from Illumina paired-end reads
It builds in a clean chroot. There are no autopkgtests yet - since I'm not
very sure
of the exact data this needs.
I've pushed my changes to team-repo[1].
This needs review and sponsorship.

[1]: https://salsa.debian.org/med-team/yanosim

Thanks and regards
Nilesh

Re: [RFS] yanosim

[Nilesh Patra]

On Tue, 16 Jun 2020 at 21:43, Nilesh Patra  wrote:

> Hi,
> I've packaged a NEW module: shovill - Assemble bacterial isolate genomes
> from Illumina paired-end reads
>

OOPS!!! It's yanosim -  Read simulator nanopore DRS datasets
Pardon me :P

It builds in a clean chroot. There are no autopkgtests yet - since I'm not
> very sure
> of the exact data this needs.
> I've pushed my changes to team-repo[1].
> This needs review and sponsorship.
>
> [1]: https://salsa.debian.org/med-team/yanosim
>
> Thanks and regards
> Nilesh
>

RFS: drop-seq

[Pranav Ballaney]

Hi,
I've added autopkgtests to drop-seq. Please review and sponsor.
https://salsa.debian.org/med-team/drop-seq

Regards,
Pranav
ᐧ

RFS: ivar

[Pranav Ballaney]

Hi,
I've added autopkgtests to ivar. Please review and sponsor.
https://salsa.debian.org/med-team/ivar

Regards,
Pranav
ᐧ

Re: RFS: drop-seq

[Steffen Möller]

I'll do that.

On 16.06.20 18:29, Pranav Ballaney wrote:

Hi,
I've added autopkgtests to drop-seq. Please review and sponsor.
https://salsa.debian.org/med-team/drop-seq


Regards,
Pranav
ᐧ

Re: RFS: ivar

[Steffen Möller]

And that, too.

On 16.06.20 18:30, Pranav Ballaney wrote:

Hi,
I've added autopkgtests to ivar. Please review and sponsor.
https://salsa.debian.org/med-team/ivar


Regards,
Pranav
ᐧ

[covid-19] RFS: scrappie

[Steffen Möller]

Hi,

I've packaged scrappie, i.e. an Open Source basecaller for the Nanopore.
Here the paper accompanying it:
https://genomebiology.biomedcentral.com/articles/10.1186/s13059-019-1727-y

I digress - there the tool: https://salsa.debian.org/med-team/scrappie

Please kindly review and - either tell me to upload it or .. just upload.

Man thanks and best regards,

Steffen

Re: PhyML error - does that ring any bell? Re: RFS: python-biopython

[Étienne Mollier]

Greetings,

mer...@debian.org, on 2020-06-15 14:48:07 +0300:
> On 2020-06-12 20:40, Steffen Möller wrote:
> > I found this
> >
> > Bio.PDB.mmtf docstring test ... skipped, missing Python dependency
> > Bio.PDB.mmtf.DefaultParser docstring test ... skipped, missing Python 
> > dependency
> > Bio.PDB.mmtf.mmtfio docstring test ... skipped, missing Python dependency
> >
> > to suggest packaging https://github.com/rcsb/mmtf-python - sigh. Any 
> > takers? Would be quite a fit for next week's hackathon, I presume. 
> 
> FYI, mmtf-python was accepted to unstable today.

Now that python3-mmtf is available for the testsuite, I had the
occasion to witness the PhyML error too on Intel platform while
working on #962944.  Will see if I can do something about it.

As a side note, I remarked that t_coffee dislikes it when its
PID is greater than 26:

$ t_coffee -version
PROGRAM: T-COFFEE Version_13.41.0.28bdc39 (2019-11-30 10:21:53 - 
Revision 5d5a1c1 - Build 465)

--ERROR: MAX_N_PID exceded -- Recompile changing the value of MAX_N_PID 
(current: 26 Requested: 371481)

The version check loops in memory allocation, filling memory
until I SIGUSR1 it away, or the kernel unleashes the OOM reaper.
It looks like a bug if Debian 11 needs to be able to run
smoothly while allowing PIDs greater than 32768.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/


signature.asc
Description: PGP signature

Re: [covid-19] RFS: scrappie

[merkys]

Hi Steffen,

On 2020-06-16 19:37, Steffen Möller wrote:
> Please kindly review and - either tell me to upload it or .. just upload. 

debian/copyright seems to contain dh-make templates:

Upstream-Contact: 
Source: 

Otherwise looks good.

Best,
Andrius

Re: PhyML error - does that ring any bell? Re: RFS: python-biopython

[merkys]

Hi Étienne,

On 2020-06-16 19:41, Étienne Mollier wrote:
> As a side note, I remarked that t_coffee dislikes it when its
> PID is greater than 26:
>
>   $ t_coffee -version
>   PROGRAM: T-COFFEE Version_13.41.0.28bdc39 (2019-11-30 10:21:53 - 
> Revision 5d5a1c1 - Build 465)
>   
>   --ERROR: MAX_N_PID exceded -- Recompile changing the value of MAX_N_PID 
> (current: 26 Requested: 371481)
>
> The version check loops in memory allocation, filling memory
> until I SIGUSR1 it away, or the kernel unleashes the OOM reaper.
> It looks like a bug if Debian 11 needs to be able to run
> smoothly while allowing PIDs greater than 32768.

Great catch - could you please file a bug report on t_coffee? I admit I
don't know what is the maximum PID value one could expect.

Best,
Andrius




signature.asc
Description: OpenPGP digital signature

Re: PhyML error - does that ring any bell? Re: RFS: python-biopython

[Étienne Mollier]

Hi Andrius,

mer...@debian.org, on 2020-06-16 19:46:00 +0300:
> Hi Étienne,
> 
> On 2020-06-16 19:41, Étienne Mollier wrote:
> > As a side note, I remarked that t_coffee dislikes it when its
> > PID is greater than 26:
> >
> > $ t_coffee -version
> > PROGRAM: T-COFFEE Version_13.41.0.28bdc39 (2019-11-30 10:21:53 - 
> > Revision 5d5a1c1 - Build 465)
> > 
> > --ERROR: MAX_N_PID exceded -- Recompile changing the value of MAX_N_PID 
> > (current: 26 Requested: 371481)
> >
> > The version check loops in memory allocation, filling memory
> > until I SIGUSR1 it away, or the kernel unleashes the OOM reaper.
> > It looks like a bug if Debian 11 needs to be able to run
> > smoothly while allowing PIDs greater than 32768.
> 
> Great catch - could you please file a bug report on t_coffee? I admit I
> don't know what is the maximum PID value one could expect.

I'm on it.  I'm a bit unsure of the maximum possible, but having
left my machine compute rosetta jobs for more than 80
consecutive days, all I can say is that the limit is well over
the million.

Cheers,  :)
-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/


signature.asc
Description: PGP signature

Re: PhyML error - does that ring any bell? Re: RFS: python-biopython

[Étienne Mollier]

Étienne Mollier, on 2020-06-16 18:51:52 +0200:
> I'm on it.  I'm a bit unsure of the maximum possible, but having
> left my machine compute rosetta jobs for more than 80
> consecutive days, all I can say is that the limit is well over
> the million.

It is pid_max according to Linux documentation, apparently:

$ cat /proc/sys/kernel/pid_max
4194304

IIRC, there has been a change of default value a few versions
ago.

Cheers,
-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/


signature.asc
Description: PGP signature

Re: [covid-19] RFS: scrappie

[Steffen Möller]

On 16.06.20 18:40, mer...@debian.org wrote:

Hi Steffen,

On 2020-06-16 19:37, Steffen Möller wrote:

Please kindly review and - either tell me to upload it or .. just upload.

debian/copyright seems to contain dh-make templates:

Upstream-Contact: 
Source: 

Otherwise looks good.

Thank you, Andrius. Have revised it.

Re: RFS: ivar

[Steffen Möller]

drop-seq and ivar are uploaded.

yamllint d/u/metadata was not happy, which I have fixed. But that was
something ancient.

As another sidenote - lintian warns about
W: ivar-doc: privacy-breach-generic
usr/share/doc/ivar/html/cookbookpage.html [https://raw.githubusercontent.com/andersen-lab/ivar/master/pipeline/pipeline.png";
width="500"/
>]
(https://raw.githubusercontent.com/andersen-lab/ivar/master/pipeline/pipeline.png)

which should be fixed, indeed.

Many thanks

Steffen


On 16.06.20 18:32, Steffen Möller wrote:

And that, too.

On 16.06.20 18:30, Pranav Ballaney wrote:

Hi,
I've added autopkgtests to ivar. Please review and sponsor.
https://salsa.debian.org/med-team/ivar


Regards,
Pranav
ᐧ

Re: [RFS] yanosim

[Andreas Tille]

On Tue, Jun 16, 2020 at 09:44:42PM +0530, Nilesh Patra wrote:
> > I've packaged a NEW module: shovill - Assemble bacterial isolate genomes
> > from Illumina paired-end reads
> >
> 
> OOPS!!! It's yanosim -  Read simulator nanopore DRS datasets
> Pardon me :P

I've got it from the subject. ;-)
 
Please add it your packages (also the other ones from today) to the new
request wiki[1] - I'm busy with other stuff currently.

Thank you for your work

  Andreas.

[1] 
https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/NEW-Requests

-- 
http://fam-tille.de

Re: [covid-19] RFS: scrappie

[Andreas Tille]

On Tue, Jun 16, 2020 at 07:17:08PM +0200, Steffen Möller wrote:
> 
> On 16.06.20 18:40, mer...@debian.org wrote:
> > Hi Steffen,
> > 
> > On 2020-06-16 19:37, Steffen Möller wrote:
> > > Please kindly review and - either tell me to upload it or .. just upload.
> > debian/copyright seems to contain dh-make templates:
> > 
> > Upstream-Contact: 
> > Source: 
> > 
> > Otherwise looks good.
> Thank you, Andrius. Have revised it.

ftpmaster will most probably stumble upon

   python/OPENBLAS_LICENSE

I admit I can not find any trace of blas code inside the source tarball
- but there is this file and this will end in a reject.  May be
repackaging makes sense to spare this discussion - or I'm misleaded and
there is actual blas code in and it should be mentioned.

There is also

   src/kseq.h

which is MIT licensed.  Its somehow code copy 17 of this header file
and I wonder whether we should normalise this over all our packages.
Not sure whether this is the right moment but it should be mentioned
in d/copyright.

Also src/sse_mathfun.h has a copyright that should be mentioned.

BTW, for MPL-2.0 you do not need to include the full text - its in
/usr/share/common-licenses/MPL-2.0 and you can refer to this.

Hope this helps

   Andreas.

-- 
http://fam-tille.de

Re: [covid-19] RFS: scrappie

[Steffen Möller]

On 16.06.20 19:59, Andreas Tille wrote:

On Tue, Jun 16, 2020 at 07:17:08PM +0200, Steffen Möller wrote:

On 16.06.20 18:40, mer...@debian.org wrote:

Hi Steffen,

On 2020-06-16 19:37, Steffen Möller wrote:

Please kindly review and - either tell me to upload it or .. just upload.

debian/copyright seems to contain dh-make templates:

Upstream-Contact: 
Source: 

Otherwise looks good.

Thank you, Andrius. Have revised it.

ftpmaster will most probably stumble upon

python/OPENBLAS_LICENSE

I admit I can not find any trace of blas code inside the source tarball
- but there is this file and this will end in a reject.  May be
repackaging makes sense to spare this discussion - or I'm misleaded and
there is actual blas code in and it should be mentioned.

There is also

src/kseq.h

which is MIT licensed.  Its somehow code copy 17 of this header file
and I wonder whether we should normalise this over all our packages.
Not sure whether this is the right moment but it should be mentioned
in d/copyright.

Also src/sse_mathfun.h has a copyright that should be mentioned.

BTW, for MPL-2.0 you do not need to include the full text - its in
/usr/share/common-licenses/MPL-2.0 and you can refer to this.

Hope this helps


I does. Very much so. Many thanks. I had ignored the Python interface.
It does not build and
drives me crazy. Will give it a break and will cry for help if I cannot
fix it later today.

Many thanks again

Steffen

What is the best way to refresh a 2to3 patch ?

[Charles Plessy]

Hello everybody,

I was trying to update LAST (fortunately I saw I will not have to do so
anymore), but struggled for half an hour on the 2to3 patch...

I fixed it partly by hand, and partly with "quilt refresh".  But when I
inspected the patch, I realised that this approach just makes it bitrot:
the parts newly written upstream are simply not going to be covered.

Could routine-update update these patches automagicallly ?

(By the way if quilt is not the state of the art anymore, please let me
know. It took me plenty of time to find on the Internet the magic `for
where in ./ ../ ../../ ../../../ ../../../../ ../../../../../` command
that would make `.quiltrc` work; not sure why I did not paste it
to the group policy at the time...)

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Akano, Uruma, Okinawa, Japan

Re: PhyML error - does that ring any bell? Re: RFS: python-biopython

[Étienne Mollier]

Howdy,

I pushed a little change in the d/control file of the package
python-biopython in version 1.77+dfsg-2.  This was the suggested
way to address the bug #962944:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962944

I couldn't reproduce any particular problem with the few last
rounds of `gbp buildpackage` and `autopkgtest`, and `lintian`
has nothing outstanding to complain about, so it is ready for
review.

Unfortunately, the PhyML issue below is left aside for the
moment.

Steffen Möller, on 2020-06-12 19:40:37 +0200:
> FAIL: test_phyml (test_phyml_tool.AppTests)
> Run PhyML using the wrapper.
> --
> Traceback (most recent call last):
>  File 
> "/home/moeller/git/med-team/python-biopython/.pybuild/cpython3_3.8/build/Tests/test_phyml_tool.py",
> line 51, in test_phyml
>    self.assertEqual(len(err), 0)
> AssertionError: 192 != 0

It is sad to only have the length of the error message, so  I
tried to get the full error message with a litte patch for
debug, but have been at loss to reproduce the PhyML issue after
having reduced my pid_max to not be affected by #962974 anymore;
I am wondering if the two problems are related somehow, or if I
just didn't trigger the test in the proper environment.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962974

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/


signature.asc
Description: PGP signature

Re: What is the best way to refresh a 2to3 patch ?

[Andreas Tille]

Hi Charles,

the short answer is: Convincing upstream to write Python3 and removing
the 2to3 patch at all is the best way.

On Wed, Jun 17, 2020 at 04:31:38AM +0900, Charles Plessy wrote:
> Hello everybody,
> 
> I was trying to update LAST (fortunately I saw I will not have to do so
> anymore), but struggled for half an hour on the 2to3 patch...
> 
> I fixed it partly by hand, and partly with "quilt refresh".  But when I
> inspected the patch, I realised that this approach just makes it bitrot:
> the parts newly written upstream are simply not going to be covered.

I'm afraid there is not really a generic way to approach thi.
 
> Could routine-update update these patches automagicallly ?

I do not think so.

> (By the way if quilt is not the state of the art anymore, please let me
> know. It took me plenty of time to find on the Internet the magic `for
> where in ./ ../ ../../ ../../../ ../../../../ ../../../../../` command
> that would make `.quiltrc` work; not sure why I did not paste it
> to the group policy at the time...)

But

https://med-team.pages.debian.net/policy/#using-quilt

has all relevant information IMHO.  I have no idea what you mean, sorry.
 
> Have a nice day,

... day is over at my side - but hope you will have a nice one ;-)

  Andreas. 

-- 
http://fam-tille.de

Can someone else check and sponsor (Was: nanofilt ready for upload)

[Andreas Tille]

Hi Shayan,

On Tue, Jun 16, 2020 at 08:48:51PM +0100, Shayan Doust wrote:
> 
> I believe nanofilt[1] is ready. Please check and, if green light given,
> upload :)

I've done some minor changes and was building the package.  Unfortunately
my computer crashed when ... or rather after(!) ... running the test.  I've
seen

[1] PASS

on the screen and than my screen froze.  No ssh login possible any more.
Waiting for more than 10min.  I switched power-off and reboot worked
fine (so no harm done) but I'm tired now and want to go to bed.  I do
not think that its actually related to the test - since the

   echo "[1] PASS"

is actually the end of the script and syslog also looks harmless.  But
I'm to tired for today now.

Thanks for your preparation

 Andreas.

> Kind regards,
> Shayan Doust
> 
> [1]: https://salsa.debian.org/med-team/nanofilt

pub   RSA 4096/19D02395 2019-09-04 Shayan Doust (Personal EMAIL) 

> 




-- 
http://fam-tille.de

Re: Can someone else check and sponsor (Was: nanofilt ready for upload)

[Andreas Tille]

Hi Étienne,

hmmm, while checking all other activities of my computer while
crashing I stumbled upon 

...
test_SeqIO_Insdc ... 
/build/python-biopython-1.77+dfsg/.pybuild/cpython3_3.8/build/Bio/GenBank/Scanner.py:304:
 BiopythonParserWarning: Non-standard feature line wrapping (didn't break o
  warnings.warn(
ok
test_SeqIO_NibIO ... ok
test_SeqIO_PdbIO ... ok
test_SeqIO_QualityIO ... ok
test_SeqIO_SeqXML ... ok
test_SeqIO_SnapGene ... ok
test_SeqIO_Xdna ... ok
test_SeqIO_features 


as last entries in

   python-biopython_1.77+dfsg-2_amd64.build

May be somebody else can also have a look at sponsoring biopython?

Kind regards

  Andreas.

On Tue, Jun 16, 2020 at 11:28:21PM +0200, Andreas Tille wrote:
> Hi Shayan,
> 
> On Tue, Jun 16, 2020 at 08:48:51PM +0100, Shayan Doust wrote:
> > 
> > I believe nanofilt[1] is ready. Please check and, if green light given,
> > upload :)
> 
> I've done some minor changes and was building the package.  Unfortunately
> my computer crashed when ... or rather after(!) ... running the test.  I've
> seen
> 
> [1] PASS
> 
> on the screen and than my screen froze.  No ssh login possible any more.
> Waiting for more than 10min.  I switched power-off and reboot worked
> fine (so no harm done) but I'm tired now and want to go to bed.  I do
> not think that its actually related to the test - since the
> 
>echo "[1] PASS"
> 
> is actually the end of the script and syslog also looks harmless.  But
> I'm to tired for today now.
> 
> Thanks for your preparation
> 
>  Andreas.
> 
> > Kind regards,
> > Shayan Doust
> > 
> > [1]: https://salsa.debian.org/med-team/nanofilt
> 
> pub   RSA 4096/19D02395 2019-09-04 Shayan Doust (Personal EMAIL) 
> 
> > 
> 
> 
> 
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Re: Can someone else check and sponsor (Was: nanofilt ready for upload)

[Shayan Doust]

Hello Andreas,

> I've done some minor changes and was building the package.  Unfortunately
> my computer crashed when ... or rather after(!) ... running the test.
 I've
> seen
>
> [1] PASS
>
> on the screen and than my screen froze.  No ssh login possible any more.
> Waiting for more than 10min.  I switched power-off and reboot worked
> fine (so no harm done) but I'm tired now and want to go to bed.  I do
> not think that its actually related to the test - since the
>
>echo "[1] PASS"

That's very odd. I know that NanoFilt will either pass or fail when
executing the command, but I like checking and making sure the filesize
is greater than 0 bytes as a double defense of making sure the program
*actually* does work properly as I have nothing to diff against.

Also this standard version changing is a bad practice for me, as I use
Buster for my main workstation, and it seems like cme loves changing the
standards version to a lower one (and I keep forgetting to set it back
to 4.5.0.

Thanks for letting me know about not needing to add GPL text. I didn't
think twice of it because I used the full license text within another
package (mmseqs2?), at least that saves time now. :)

> I'm to tired for today now.

Good night and kind regards,
Shayan Doust

On 16/06/2020 22:28, Andreas Tille wrote:
> Hi Shayan,
> 
> On Tue, Jun 16, 2020 at 08:48:51PM +0100, Shayan Doust wrote:
>>
>> I believe nanofilt[1] is ready. Please check and, if green light given,
>> upload :)
> 
> I've done some minor changes and was building the package.  Unfortunately
> my computer crashed when ... or rather after(!) ... running the test.  I've
> seen
> 
> [1] PASS
> 
> on the screen and than my screen froze.  No ssh login possible any more.
> Waiting for more than 10min.  I switched power-off and reboot worked
> fine (so no harm done) but I'm tired now and want to go to bed.  I do
> not think that its actually related to the test - since the
> 
>echo "[1] PASS"
> 
> is actually the end of the script and syslog also looks harmless.  But
> I'm to tired for today now.
> 
> Thanks for your preparation
> 
>  Andreas.
> 
>> Kind regards,
>> Shayan Doust
>>
>> [1]: https://salsa.debian.org/med-team/nanofilt
> 
> pub   RSA 4096/19D02395 2019-09-04 Shayan Doust (Personal EMAIL) 
> 
>>
> 
> 
> 
> 


0x6D7D441919D02395.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Can someone else check and sponsor (Was: nanofilt ready for upload)

[Nilesh Patra]

On Wed, 17 Jun 2020, 03:08 Shayan Doust,  wrote:

> Hello Andreas,
>
> > I've done some minor changes and was building the package.  Unfortunately
> > my computer crashed when ... or rather after(!) ... running the test.
>  I've
> > seen
> >
> > [1] PASS
> >
> > on the screen and than my screen froze.  No ssh login possible any more.
> > Waiting for more than 10min.  I switched power-off and reboot worked
> > fine (so no harm done) but I'm tired now and want to go to bed.  I do
> > not think that its actually related to the test - since the
> >
> >echo "[1] PASS"
>
> That's very odd. I know that NanoFilt will either pass or fail when
> executing the command, but I like checking and making sure the filesize
> is greater than 0 bytes as a double defense of making sure the program
> *actually* does work properly as I have nothing to diff against.
>

If I may suggest ...
You can run the test on your machine manually once and you'll get output
file(s). This is something you can diff against.

Add those files to say "debian/tests/expected/" and install these files as
examples and take diff with what you get when you run-unit-test.


> Also this standard version changing is a bad practice for me, as I use
> Buster for my main workstation, and it seems like cme loves changing the
> standards version to a lower one (and I keep forgetting to set it back
> to 4.5.0.
>

+1: I use stable as well.
I have another debian-sid "schroot" made.
For cme I always do this:

$ schroot -c debian-sid
$ cme fix dpkg
$ exit

Works out of the box.


> Thanks for letting me know about not needing to add GPL text. I didn't
> think twice of it because I used the full license text within another
> package (mmseqs2?), at least that saves time now. :)
>
> > I'm to tired for today now.
>
> Good night and kind regards,
> Shayan Doust
>
> On 16/06/2020 22:28, Andreas Tille wrote:
> > Hi Shayan,
> >
> > On Tue, Jun 16, 2020 at 08:48:51PM +0100, Shayan Doust wrote:
> >>
> >> I believe nanofilt[1] is ready. Please check and, if green light given,
> >> upload :)
> >
> > I've done some minor changes and was building the package.  Unfortunately
> > my computer crashed when ... or rather after(!) ... running the test.
> I've
> > seen
> >
> > [1] PASS
> >
> > on the screen and than my screen froze.  No ssh login possible any more.
> > Waiting for more than 10min.  I switched power-off and reboot worked
> > fine (so no harm done) but I'm tired now and want to go to bed.  I do
> > not think that its actually related to the test - since the
> >
> >echo "[1] PASS"
> >
> > is actually the end of the script and syslog also looks harmless.  But
> > I'm to tired for today now.
> >
> > Thanks for your preparation
> >
> >  Andreas.
> >
> >> Kind regards,
> >> Shayan Doust
> >>
> >> [1]: https://salsa.debian.org/med-team/nanofilt
> >
> > pub   RSA 4096/19D02395 2019-09-04 Shayan Doust (Personal EMAIL) <
> he...@shayandoust.me>
> >>
> >
> >
> >
> >
>

RFS: flash

[Pranav Ballaney]

Hi,
I've added autopkgtests to flash. Please review and sponsor.
https://salsa.debian.org/med-team/flash

Regards,
Pranav
ᐧ

[covid-19] r-bioc-beachmat

[Steffen Möller]

Hello,

I just went through

https://salsa.debian.org/r-pkg-team/r-bioc-beachmat

which is contributing to several single-cell RNA-seq suites on BioConductor.

Builds with cowbuilder.

Please kindly comment/upload.

Many thanks!

Steffen

Uploaded Re: RFS: flash

[Steffen Möller]

Many thanks!

On 17.06.20 02:38, Pranav Ballaney wrote:

Hi,
I've added autopkgtests to flash. Please review and sponsor.
https://salsa.debian.org/med-team/flash


Regards,
Pranav
ᐧ

Re: What is the best way to refresh a 2to3 patch ?

[Aaron M. Ucko]

Andreas Tille  writes:

> the short answer is: Convincing upstream to write Python3 and removing
> the 2to3 patch at all is the best way.

Meanwhile, if you do need to patch in Python 3 support, you may be able
to reduce the opportunity for bitrot by doing so in the form of *two*
patches: one for the formal changes 2to3 generates itself, which you can
readily recreate by running that tool again, and a second for any
additional changes you need to make.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

RFS: pilon

[Pranav Ballaney]

Hi,
I've added autopkgtests to pilon. Please review and sponsor.
https://salsa.debian.org/med-team/pilon

Regards,
Pranav
ᐧ

Re: Can someone else check and sponsor (Was: nanofilt ready for upload)

[merkys]

Hi Nilesh,

On 2020-06-17 00:47, Nilesh Patra wrote:
Add those files to say "debian/tests/expected/" and install these 
files as examples and take diff with what you get when you run-unit-test.


Why do you need to install these files as examples? Doing so 
unnecessarily bloats packages. Autopkgtests are always run inside the 
source tree, so you find your files in debian/tests/expected/.


Best wishes,
Andrius

Re: Can someone else check and sponsor (Was: nanofilt ready for upload)

[Andreas Tille]

Hi Andrius,

On Wed, Jun 17, 2020 at 08:05:59AM +0300, mer...@debian.org wrote:
> Why do you need to install these files as examples? Doing so unnecessarily
> bloats packages. Autopkgtests are always run inside the source tree, so you
> find your files in debian/tests/expected/.

You need to blame me about this.  I consider it a good idea if users can
reproduce the tests on their local machines and the tests usually can
nicely serve as usage examples of the programs.  However, to not bloat
the binary packages to much the example data should go to a separate
binary package (if the data are large compared to the real binary).

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Can someone else check and sponsor (Was: nanofilt ready for upload)

[Andreas Tille]

Hi Shayan,

On Tue, Jun 16, 2020 at 10:37:17PM +0100, Shayan Doust wrote:
> > on the screen and than my screen froze.  No ssh login possible any more.
> > Waiting for more than 10min.  I switched power-off and reboot worked
> > fine (so no harm done) but I'm tired now and want to go to bed.  I do
> > not think that its actually related to the test - since the
> >
> >echo "[1] PASS"
> 
> That's very odd. I know that NanoFilt will either pass or fail when
> executing the command, but I like checking and making sure the filesize
> is greater than 0 bytes as a double defense of making sure the program
> *actually* does work properly as I have nothing to diff against.

I do *not* think nanofilt has caused the crash.  As I said in my other
mail probably biopython caused it for whatever reason.  I've build
biopython successfully this morning.  I can upload nanofilt later.
 
> Also this standard version changing is a bad practice for me, as I use
> Buster for my main workstation, and it seems like cme loves changing the
> standards version to a lower one (and I keep forgetting to set it back
> to 4.5.0.

I've also running some machines under stable.  Regarding cme I'm using

$ cat /etc/apt/preferences.d/01-cme.pref 
Package: libconfig-model-dpkg-perl
Pin: release a=unstable
Pin-Priority: 605

which pretty much does the trick to always have the latest cme even
on a stable machine.  I also have

$ cat /etc/apt/preferences.d/01-lintian.pref 
Package: lintian
Pin: release a=unstable
Pin-Priority: 601

Package: lintian-brush
Pin: release a=unstable
Pin-Priority: 601

 
> Thanks for letting me know about not needing to add GPL text. I didn't
> think twice of it because I used the full license text within another
> package (mmseqs2?), at least that saves time now. :)

:-)
 
> > I'm to tired for today now.
> 
> Good night and kind regards,

Thanks :-)

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: PhyML error - does that ring any bell? Re: RFS: python-biopython

[Andreas Tille]

Hi Étienne,

On Tue, Jun 16, 2020 at 10:41:28PM +0200, Étienne Mollier wrote:
> I pushed a little change in the d/control file of the package
> python-biopython in version 1.77+dfsg-2.  This was the suggested
> way to address the bug #962944:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962944
> 
> I couldn't reproduce any particular problem with the few last
> rounds of `gbp buildpackage` and `autopkgtest`, and `lintian`
> has nothing outstanding to complain about, so it is ready for
> review.

I've just uploaded (today the build went smoothly).
 
> Unfortunately, the PhyML issue below is left aside for the
> moment.

As far as I can see this was the urgent issue that was
reflected in a RC bug that should be fixed quickly.
 
> Steffen Möller, on 2020-06-12 19:40:37 +0200:
> > FAIL: test_phyml (test_phyml_tool.AppTests)
> > Run PhyML using the wrapper.
> > --
> > Traceback (most recent call last):
> >  File 
> > "/home/moeller/git/med-team/python-biopython/.pybuild/cpython3_3.8/build/Tests/test_phyml_tool.py",
> > line 51, in test_phyml
> >    self.assertEqual(len(err), 0)
> > AssertionError: 192 != 0
> 
> It is sad to only have the length of the error message, so  I
> tried to get the full error message with a litte patch for
> debug, but have been at loss to reproduce the PhyML issue after
> having reduced my pid_max to not be affected by #962974 anymore;
> I am wondering if the two problems are related somehow, or if I
> just didn't trigger the test in the proper environment.
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962974

Thanks a lot for your investigation

  Andreas.

-- 
http://fam-tille.de