[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mcaller - may be ready



Hi Andrius, Hi Andreas,

On Mon, 21 Jun 2021 at 11:27, Andrius Merkys <merkys@debian.org> 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 <andreas@an3as.eu> 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

Hmmmm, but this looks like an attempt to access some remote location.

Works now
 
> > 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
 

Reply to: