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