Hi Andreas, On 19-11-2020 08:22, Andreas Tille wrote: >> I have the strong impression that we're talking past each other. The log >> message that you quoted in your initial e-mail said "uninstallable on >> arch *, not running autopkgtest there". This means the test is not >> triggered *and* that fact will *not* block the package. However, you are >> now saying we're scheduling the test which fails. That's a completely >> different category. > > 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. > 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? > 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. > 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. >>> I'm wondering whether it would >>> be easy to find out in advance whether it is possible to install that >>> package on that architecture (for instance by an UDD query whether >>> all dependencies are available or whatever) and just stop if it turns >>> out that the package is not installable. >> >> Yes, we can (and do) that, but what then? If the non-installability is a >> regression, we should block the package. > > This is definitely a good question. > >> If the non-installablility is >> already existing, the package should just move on. We already do that >> (or at least try very hard). So, which *exact* use case do you consider >> here (real life examples help). > > 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)? >>> As I tried to say above: I would prefer to find out before apt runs >>> in a fully setup test environment whether the package is installable >>> at all. >> >> As I tried to say above, we already don't schedule the test in *most* >> cases and as far as I'm aware, we only have some issues where arch:all >> packages are involved. In some cases, I don't think there is a "right" >> answer, so we need to get the most acceptable solution. > > 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. >>> 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). Paul
Attachment:
signature.asc
Description: OpenPGP digital signature