Hi Andrius, Hi Andreas, On Mon, 21 Jun 2021 at 11:27, Andrius Merkys <[email protected]> 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 <[email protected]> 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 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
