Re: Migration of packages blocked if (Build-)Depends are missing on some test architectures
Hi Paul,
On Sun, Nov 22, 2020 at 10:24:25PM +0100, Paul Gevers wrote:
> > What I mean when looking at the armhf log[1] this starts with>
> > autopkgtest [21:45:36]: host ci-worker-armhf-01; command line: /usr/bin/autopkgtest --no-built-binaries '--setup-commands=echo '"'"'drop-seq unstable/armhf'"'"' > /var/tmp/debci.pkg 2>&1 || true' --user debci --apt-upgrade '--add-apt-source=deb http://incoming.debian.org/debian-buildd buildd-experimental main contrib non-free' --add-apt-release=experimental --pin-packages=experimental=src:plexus-archiver --output-dir /tmp/tmp.R29JBBc7iX/autopkgtest-incoming/unstable/armhf/d/drop-seq/7114930 drop-seq -- lxc --sudo --name ci-265-4a1a79f8 autopkgtest-unstable-armhf
>
> This log was used to test plexus-archiver. Indeed, when we schedule
> tests for other packages, we don't check if the package we schedule is
> installable. I don't think there's much harm though, as this is not a
> regression, so this isn't in the way of any maintainer.
My point is that the reault is "FAIL" but I think this is not sensible
in the case I was talking about. It makes no sense to declare a package
broken on some architecture if its clear from the beginning that it can
not be installed there. But I agree that it is hard to distinguish from
cases where exactly this non-installability is the error debci should
detect.
> > For me that's an attempt to run a test when apt starts getting files.
> > That's what I was talking about.
>
> Ok. Do you think this is a problem somehow?
It looks like a waste of resources (not only on the computing time also
for the maintainer who needs to scroll down a longish log instead of a
log that yould be way shorter).
> > I think this has changed now since
> > for arm64[2]. This log is way shorter and ends with
> >
> > run-unit-test SKIP Test lists explicitly supported architectures, but the current architecture amd64 isn't listed.
>
> That's because the maintainer added the Architecture field to
> debian/tests/control.
OK, I was doing this and I think I simply keep on doing this in
similar cases.
> > The result is "neutral" - and I think you was talking about the
> > latter which seems to be relatively new when looking at the overview
> > page[3]. The log from 2020-11-08 looks similar to the armhf log
> > above but since 2020-11-11 it has the neutral result (which is
> > what I tried to suggest).
>
> That's for a different reason though, that was due to the maintainer. I
> think you are (or were) suggesting we should fix this automatically.
Yes, that's my suggestion.
> > I think my real life example drop-seq was a good one.
>
> I still don't see the problem. You're right, that test was scheduled in
> vain, but was any harm done (except climate heating)?
Making me wondering what the issue was, dragging maintainers attention
to a non-issue.
> > That's true and I agree that the decision whether the missing of a
> > package has to be considered a failure or not is a hard one.
>
> I think the exact use case you gave above with drop-seq could be fixed,
> but there are quite a lot more pressing use cases I want to work on.
Fair enough. I do not want to set debian-ci members schedule. But
I simply wanted bring this up.
> >>> My idea is to find out whether a package is installable on some
> >>> architecture and add a new test result say "NOT_INSTALLABLE" or
> >>> "NOT_INSTALLABLE_ON_ARCH" which is considered "neutral" as test result.
> >>
> >> We don't schedule those cases we can catch. So we don't need to have a
> >> new state. If we can find the exact problem you're describing we can try
> >> to add it to the set we don't trigger. (By the way, are you aware of the
> >> skip-not-installable restriction?
> >
> > No, sorry. Where can I read about it?
>
> In the autopkgtest spec:
> https://salsa.debian.org/ci-team/autopkgtest/-/raw/master/doc/README.package-tests.rst
>
> But again:
> >> It's not great, as it hides real
> >> issues, but could be a solution for a class of packages, maybe the ones
> >> you worry about).
In this case it is better than explicitly restricting the architectures.
I'll upload a new version of the package soon.
Thanks for the hint and your patience
Andreas.
--
http://fam-tille.de
Reply to: