On Mon, Nov 23, 2020 at 11:35:17AM +0100, Andreas Tille wrote: > 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).
Maybe it is possible to do something similar to wanna-build and use the output of dose-debcheck to determine the packages that have unsatisfiable test dependencies ? -Ralf.