Re: mcaller - may be ready

[Andrius Merkys]

Hi Nilesh,

On 2021-06-21 17:10, Nilesh Patra wrote:
> On Mon, 21 Jun 2021 at 11:27, Andrius Merkys  > wrote:
> 
> Hello,
> 
> On 2021-06-21 08:16, Andreas Tille wrote:
> >>> Repository data is changed during the tests, which I dislike,
> but ...
> >>> well ... we need to get somewhere.
> >> * And I dislike this as well, so I simply removed the build time
> test, and
> >> running that as autopkgtest. IMO doing this is even better since this
> >> tests that the binary is actually installed.
> > Another way would be to do some
> >
> >    override_dh_auto_test:
> >       cp -a testdata testdata_save
> >       dh_auto_test
> >       rm -rf testdata
> >       mv testdata_save testdata
> >
> > or something like this.  While I agree that autopkgtest is more
> important
> > than build time test both falvours make sense.
> Build time tests are very important for apriori (pre-upload) detection
> of breakages introduced by updates/modifications of reverse
> dependencies. ratt loses much of its power without these tests.
> 
> OK, added.
> But you might want to check out ruby-team/meta[1] script, which also
> checks for
> autopkgtest breakeages. Admittedly, I've always liked this more.
> Here's the results for this, if you'd like to have a look just as an example
> 
> [1]: https://salsa.debian.org/ruby-team/meta
> 
> [2]: https://lists.debian.org/debian-med/2020/07/msg00160.html
> 

Thanks for letting me know - ruby-team/meta looks very helpful indeed!

Best,
Andrius

Re: mcaller - may be ready

[Steffen Möller]

Hi,

> Gesendet: Montag, 21. Juni 2021 um 16:38 Uhr
> Von: "Andreas Tille" 
> An: debian-med@lists.debian.org
> Betreff: Re: mcaller - may be ready
>
> Hi,
>
> On Mon, Jun 21, 2021 at 07:40:47PM +0530, Nilesh Patra wrote:
> > > >override_dh_auto_test:
> > > >   cp -a testdata testdata_save
> > > >   dh_auto_test
> > > >   rm -rf testdata
> > > >   mv testdata_save testdata
> > > >
> > > > or something like this.  While I agree that autopkgtest is more 
> > > > important
> > > > than build time test both falvours make sense.
> > > Build time tests are very important for apriori (pre-upload) detection
> > > of breakages introduced by updates/modifications of reverse
> > > dependencies. ratt loses much of its power without these tests.
> >
> > OK, added.
>
> Good!
>
> > But you might want to check out ruby-team/meta[1] script, which also checks
> > for
> > autopkgtest breakeages. Admittedly, I've always liked this more.
> > Here's the results for this, if you'd like to have a look just as an example
> >
> > [1]: https://salsa.debian.org/ruby-team/meta
> > [2]: https://lists.debian.org/debian-med/2020/07/msg00160.html
>
> That's all perfect.  However, we just have seen that not all team members
> are even building in a chroot.  My guess is that not everybody is running
> autopkgtest before uploading.  Thus just running the build time test if
> available can at least ensure proper builds.
>
> > On Mon, 21 Jun 2021 at 10:46, Andreas Tille  wrote:
> > > H, but this looks like an attempt to access some remote location.
> >
> > Works now
> > https://salsa.debian.org/med-team/mcaller/-/jobs/1716727
>
> Nice.
>
> > > I'm not sure.  The *.pkl files do not really look "binary" but rather
> > > badly saved UTF-8 code.  But I agree that there is a slight chance that
> > > ftpmaster will stumble upon it.  Thus clarifying how that files were
> > > created (=can be changed) makes sense.
> >
> > Looks like it has been trained with passing the --train argument to
> > mCaller.py
> > Do you think asking upstream about it, and put the way to reproduce that
> > file in d/README.Source can
> > help there?
>
> Whatever might be faster out of "asking upstream" or running with --train
> argument and make a diff.  If the latter works its IMHO relatively safe
> to assume that this method was used and mentioning this in d/README.Source
> as "it was verified that the data can be reprocuded by" should do the
> trick.

I like it. Well done, all.

In general I would not expect a binary identity in a stochastic learning 
process. But, whatever works for now.

Steffen

Re: mcaller - may be ready

[Andreas Tille]

Hi,

On Mon, Jun 21, 2021 at 07:40:47PM +0530, Nilesh Patra wrote:
> > >override_dh_auto_test:
> > >   cp -a testdata testdata_save
> > >   dh_auto_test
> > >   rm -rf testdata
> > >   mv testdata_save testdata
> > >
> > > or something like this.  While I agree that autopkgtest is more important
> > > than build time test both falvours make sense.
> > Build time tests are very important for apriori (pre-upload) detection
> > of breakages introduced by updates/modifications of reverse
> > dependencies. ratt loses much of its power without these tests.
> 
> OK, added.

Good!

> But you might want to check out ruby-team/meta[1] script, which also checks
> for
> autopkgtest breakeages. Admittedly, I've always liked this more.
> Here's the results for this, if you'd like to have a look just as an example
> 
> [1]: https://salsa.debian.org/ruby-team/meta
> [2]: https://lists.debian.org/debian-med/2020/07/msg00160.html

That's all perfect.  However, we just have seen that not all team members
are even building in a chroot.  My guess is that not everybody is running
autopkgtest before uploading.  Thus just running the build time test if
available can at least ensure proper builds.
 
> On Mon, 21 Jun 2021 at 10:46, Andreas Tille  wrote:
> > H, but this looks like an attempt to access some remote location.
> 
> Works now
> https://salsa.debian.org/med-team/mcaller/-/jobs/1716727

Nice.
 
> > I'm not sure.  The *.pkl files do not really look "binary" but rather
> > badly saved UTF-8 code.  But I agree that there is a slight chance that
> > ftpmaster will stumble upon it.  Thus clarifying how that files were
> > created (=can be changed) makes sense.
> 
> Looks like it has been trained with passing the --train argument to
> mCaller.py
> Do you think asking upstream about it, and put the way to reproduce that
> file in d/README.Source can
> help there?

Whatever might be faster out of "asking upstream" or running with --train
argument and make a diff.  If the latter works its IMHO relatively safe
to assume that this method was used and mentioning this in d/README.Source
as "it was verified that the data can be reprocuded by" should do the
trick.
 
Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: mcaller - may be ready

[Nilesh Patra]

Hi Andrius, Hi Andreas,

On Mon, 21 Jun 2021 at 11:27, Andrius Merkys  wrote:

> Hello,
>
> On 2021-06-21 08:16, Andreas Tille wrote:
> >>> Repository data is changed during the tests, which I dislike, but ...
> >>> well ... we need to get somewhere.
> >> * And I dislike this as well, so I simply removed the build time test,
> and
> >> running that as autopkgtest. IMO doing this is even better since this
> >> tests that the binary is actually installed.
> > Another way would be to do some
> >
> >override_dh_auto_test:
> >   cp -a testdata testdata_save
> >   dh_auto_test
> >   rm -rf testdata
> >   mv testdata_save testdata
> >
> > or something like this.  While I agree that autopkgtest is more important
> > than build time test both falvours make sense.
> Build time tests are very important for apriori (pre-upload) detection
> of breakages introduced by updates/modifications of reverse
> dependencies. ratt loses much of its power without these tests.
>

OK, added.
But you might want to check out ruby-team/meta[1] script, which also checks
for
autopkgtest breakeages. Admittedly, I've always liked this more.
Here's the results for this, if you'd like to have a look just as an example

[1]: https://salsa.debian.org/ruby-team/meta
[2]: https://lists.debian.org/debian-med/2020/07/msg00160.html


On Mon, 21 Jun 2021 at 10:46, Andreas Tille  wrote:

> > However salsa CI shows a fail on autopkgtest with:
> >
> > ""
> > HTTP request sent, awaiting response... 404 Not Found
> > 2021-06-20 20:44:08 ERROR 404: Not Found.
> > ""
> >
> > I guess this is a temporary error, and nothing related with package
> > test. I'll hit the retry after a few hours
>
> H, but this looks like an attempt to access some remote location.
>

Works now
https://salsa.debian.org/med-team/mcaller/-/jobs/1716727


> > > Peer review and (if not too bad) upload would be appreciated.
> >
> > I was going to upload, but found out that there's testdata/*.fast5, all
> > of which is binary data. This makes me feel not too good, and maybe this
> > can trigger a rejection from ftp master.
> > Since this file is not in use, I think this can simply be dropped.
> >
> > Also, the *.pkl files have several huge strings like "\x03\xab" etc
> > To my understanding, the *.pkl files have been used to save model's
> > training parameters, and the script loads model's training parameters
> > from that file if you pass it in as an argument (-d flag)
> > And looks like they are binary files as well -- with those sorts of
> binary
> > strings, and that too makes me feel not too good about it, since ftp
> > master can again _potentially_ reject this.
> >
> > On the other hand, removing these files from the package would mean we
> > cannot run autopkgtests, and hence I'm unsure about this. Would you have
> > an opinion about this?
> > Also @Andreas, what do you think?
>
> I'm not sure.  The *.pkl files do not really look "binary" but rather
> badly saved UTF-8 code.  But I agree that there is a slight chance that
> ftpmaster will stumble upon it.  Thus clarifying how that files were
> created (=can be changed) makes sense.
>

Looks like it has been trained with passing the --train argument to
mCaller.py
Do you think asking upstream about it, and put the way to reproduce that
file in d/README.Source can
help there?

Nilesh

Re: mcaller - may be ready

[Andrius Merkys]

Hello,

On 2021-06-21 08:16, Andreas Tille wrote:
>>> Repository data is changed during the tests, which I dislike, but ...
>>> well ... we need to get somewhere.
>> * And I dislike this as well, so I simply removed the build time test, and
>> running that as autopkgtest. IMO doing this is even better since this
>> tests that the binary is actually installed.
> Another way would be to do some
> 
>override_dh_auto_test:
>   cp -a testdata testdata_save
>   dh_auto_test
>   rm -rf testdata
>   mv testdata_save testdata
> 
> or something like this.  While I agree that autopkgtest is more important
> than build time test both falvours make sense.
Build time tests are very important for apriori (pre-upload) detection
of breakages introduced by updates/modifications of reverse
dependencies. ratt loses much of its power without these tests.

I really like Andreas's suggestion for preserving the original test
data. It should do the trick.

Best,
Andrius

Re: mcaller - may be ready

[Andreas Tille]

Hi,

On Mon, Jun 21, 2021 at 02:23:53AM +0530, Nilesh Patra wrote:
> * Do not create manpages while build, rather maintain maintainer
> manpages. Doing the former actually breaks cross building.
> So I added in maintainer manpages with createmanpages script

I confirm that I somehow stopped calling help2man at build-time
since it always creates hassle.
 
> * Add missing B-D on python3-sklearn

+1
 
> > Repository data is changed during the tests, which I dislike, but ...
> > well ... we need to get somewhere.
> 
> * And I dislike this as well, so I simply removed the build time test, and
> running that as autopkgtest. IMO doing this is even better since this
> tests that the binary is actually installed.

Another way would be to do some

   override_dh_auto_test:
cp -a testdata testdata_save
dh_auto_test
rm -rf testdata
mv testdata_save testdata

or something like this.  While I agree that autopkgtest is more important
than build time test both falvours make sense.

> However salsa CI shows a fail on autopkgtest with:
> 
> ""
> HTTP request sent, awaiting response... 404 Not Found
> 2021-06-20 20:44:08 ERROR 404: Not Found.
> ""
> 
> I guess this is a temporary error, and nothing related with package
> test. I'll hit the retry after a few hours

H, but this looks like an attempt to access some remote location.
 
> > Peer review and (if not too bad) upload would be appreciated.
> 
> I was going to upload, but found out that there's testdata/*.fast5, all
> of which is binary data. This makes me feel not too good, and maybe this
> can trigger a rejection from ftp master.
> Since this file is not in use, I think this can simply be dropped.
> 
> Also, the *.pkl files have several huge strings like "\x03\xab" etc
> To my understanding, the *.pkl files have been used to save model's
> training parameters, and the script loads model's training parameters
> from that file if you pass it in as an argument (-d flag)
> And looks like they are binary files as well -- with those sorts of binary
> strings, and that too makes me feel not too good about it, since ftp
> master can again _potentially_ reject this.
> 
> On the other hand, removing these files from the package would mean we
> cannot run autopkgtests, and hence I'm unsure about this. Would you have
> an opinion about this?
> Also @Andreas, what do you think?

I'm not sure.  The *.pkl files do not really look "binary" but rather
badly saved UTF-8 code.  But I agree that there is a slight chance that
ftpmaster will stumble upon it.  Thus clarifying how that files were
created (=can be changed) makes sense.

> On Mon, 21 Jun 2021 at 01:03, Andreas Tille  wrote:
> 
> > dh_auto_build
> > help2man ./mCaller.py --version-string=`head -n1 debian/changelog |cut -f1 
> > -d- | cut -f2 -d'(' ` --no-info > debian/mCaller.1
> > help2man: can't get `--help' info from ./mCaller.py
> 
> And salsa CI shows this too :-)
> 
> https://salsa.debian.org/med-team/mcaller/-/jobs/1714653
> 
> I'm happy enabling this was useful

+1
 
> > My guess is it works on your local machine and I'd like to repeat my
> > plea to build in a chroot at least once before asking for review.
> 
> +1

Kind regards

Andreas.

-- 
http://fam-tille.de

Re: mcaller - may be ready

[Steffen Möller]

Am 20.06.2021 um 21:32 schrieb Andreas Tille:

Hi Steffen,

thanks for working on this package.

On Sun, Jun 20, 2021 at 01:22:56PM +0200, Steffen Möller wrote:

Peer review and (if not too bad) upload would be appreciated.

dh_auto_build
help2man ./mCaller.py --version-string=`head -n1 debian/changelog |cut -f1 -d- | 
cut -f2 -d'(' ` --no-info > debian/mCaller.1
help2man: can't get `--help' info from ./mCaller.py


My guess is it works on your local machine and I'd like to repeat my
plea to build in a chroot at least once before asking for review.


Right. I had only updated the build environment but not actually run it :o/

Sorry and thanks! I saw a bunch of nice changes by Nilesh, and was also
happy when I saw that Nilesh had prepared the libmmmulti library last
year, you did libflathashmap, so I gave seqwish another look.
routine-update was busy with a version bump but somehow I did not take
the first (should be easy) hurdle of a pthread link error. Another day.
There is a submodule "gzip_reader" that we have not yet packaged, but I
would like to see how far we get without it.

These packages are from the "virus" tab. We truly need to finish some
more columns.

It does not help (or it does since this does not seem to have many
dependencies) that by reading my notes to the right of that tab, I was
pointed to https://github.com/ncbi/vadr. This seems very interesting and
still timely to have, so I added it as one of our workflows. If I get
this right then you use it to submit viral genome sequences and this
tool tells you what they are and is special about them. I had a quick
look at the documentation and this depends on the typical blast, hmmer
and cmbuild (== infernal) tools - we have all that.

Steffen

Re: mcaller - may be ready

[Nilesh Patra]

Hi,

On 20/06/21 01:22 PM, Steffen Möller wrote:
> Hello,
> 
> I finally got around a revisit of
> g...@salsa.debian.org:med-team/mcaller.git . I think it is read to be
> uploaded, in the sense that it compiles nicely and does not give any
> testing errors.

I did the following changes:

* Do not create manpages while build, rather maintain maintainer
manpages. Doing the former actually breaks cross building.
So I added in maintainer manpages with createmanpages script

* Add missing B-D on python3-sklearn

> Repository data is changed during the tests, which I dislike, but ...
> well ... we need to get somewhere.

* And I dislike this as well, so I simply removed the build time test, and
running that as autopkgtest. IMO doing this is even better since this
tests that the binary is actually installed.

However salsa CI shows a fail on autopkgtest with:

""
HTTP request sent, awaiting response... 404 Not Found
2021-06-20 20:44:08 ERROR 404: Not Found.
""

I guess this is a temporary error, and nothing related with package
test. I'll hit the retry after a few hours

> Peer review and (if not too bad) upload would be appreciated.

I was going to upload, but found out that there's testdata/*.fast5, all
of which is binary data. This makes me feel not too good, and maybe this
can trigger a rejection from ftp master.
Since this file is not in use, I think this can simply be dropped.

Also, the *.pkl files have several huge strings like "\x03\xab" etc
To my understanding, the *.pkl files have been used to save model's
training parameters, and the script loads model's training parameters
from that file if you pass it in as an argument (-d flag)
And looks like they are binary files as well -- with those sorts of binary
strings, and that too makes me feel not too good about it, since ftp
master can again _potentially_ reject this.

On the other hand, removing these files from the package would mean we
cannot run autopkgtests, and hence I'm unsure about this. Would you have
an opinion about this?
Also @Andreas, what do you think?

On Mon, 21 Jun 2021 at 01:03, Andreas Tille  wrote:

> dh_auto_build
> help2man ./mCaller.py --version-string=`head -n1 debian/changelog |cut -f1 
> -d- | cut -f2 -d'(' ` --no-info > debian/mCaller.1
> help2man: can't get `--help' info from ./mCaller.py

And salsa CI shows this too :-)

https://salsa.debian.org/med-team/mcaller/-/jobs/1714653

I'm happy enabling this was useful

> My guess is it works on your local machine and I'd like to repeat my
> plea to build in a chroot at least once before asking for review.

+1

Nilesh


signature.asc
Description: PGP signature

Re: mcaller - may be ready

[Andreas Tille]

Hi Steffen,

thanks for working on this package.

On Sun, Jun 20, 2021 at 01:22:56PM +0200, Steffen Möller wrote:
> 
> Peer review and (if not too bad) upload would be appreciated.

dh_auto_build
help2man ./mCaller.py --version-string=`head -n1 debian/changelog |cut -f1 -d- 
| cut -f2 -d'(' ` --no-info > debian/mCaller.1
help2man: can't get `--help' info from ./mCaller.py


My guess is it works on your local machine and I'd like to repeat my
plea to build in a chroot at least once before asking for review.

Thank you

  Andreas.

-- 
http://fam-tille.de

mcaller - may be ready

[Steffen Möller]

Hello,

I finally got around a revisit of
g...@salsa.debian.org:med-team/mcaller.git . I think it is read to be
uploaded, in the sense that it compiles nicely and does not give any
testing errors.

Repository data is changed during the tests, which I dislike, but ...
well ... we need to get somewhere.

Peer review and (if not too bad) upload would be appreciated.

Best,

Steffen