Re: mcaller - may be ready
Hi,
> Gesendet: Montag, 21. Juni 2021 um 16:38 Uhr
> Von: "Andreas Tille" <andreas@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 <andreas@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
Reply to: