Re: .py endings or no .py endings for scientific packages

2018-06-15 Thread Charles Plessy
Le Fri, Jun 15, 2018 at 03:52:08PM +0100, Tony Travis a écrit : > > I use Debian-Med packages every day for my scientific work and I really > appreciate the hard work that the Debian-Med team have done to make this > software available via the Debian Sid repositories that Ubuntu is based > on, but

Re: .py endings or no .py endings for scientific packages

2018-06-15 Thread Tony Travis
On 15/06/18 13:58, Charles Plessy wrote: > Le Fri, Jun 15, 2018 at 01:48:17PM +0200, Steffen Möller a écrit : >> >> I just updated cnvkit locally and found Michael's patch "Remove .py >> extensions as per Debian policy". I personally came to the conclusion >> that differences to upstream in the nam

Re: .py endings or no .py endings for scientific packages

2018-06-15 Thread Charles Plessy
Le Fri, Jun 15, 2018 at 01:48:17PM +0200, Steffen Möller a écrit : > > I just updated cnvkit locally and found Michael's patch "Remove .py > extensions as per Debian policy". I personally came to the conclusion > that differences to upstream in the naming of binaries is detrimental > for the accep

.py endings or no .py endings for scientific packages

2018-06-15 Thread Steffen Möller
Hello, I just updated cnvkit locally and found Michael's patch "Remove .py extensions as per Debian policy". I personally came to the conclusion that differences to upstream in the naming of binaries is detrimental for the acceptance of our distribution in the scientific community. Just, nobody wa

Autopkgtest fails if kmer is built with sbuild, but doesn't—with dpkg-buildpackage

2018-06-15 Thread Liubov Chuprikova
Hi Afif, Hi Andreas, I faced a problem while building kmer package and after that trying to test it with autopkgtest. Initially, I built kmer in a sbuild chroot environment and run autopkgtest: it failed. After that, I run autopkgtest so that it built the package itself from the local source prov