Hi, > Gesendet: Montag, 21. Juni 2021 um 16:38 Uhr > Von: "Andreas Tille" <andr...@an3as.eu> > 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 <andr...@an3as.eu> wrote: > > > Hmmmm, 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
