Re: Migration of packages blocked if (Build-)Depends are missing on some test architectures
Hi Paul,
On Wed, Nov 18, 2020 at 08:18:01PM +0100, Paul Gevers wrote:
> > Well, the test is not actually run - since it can not be run. In those
> > cases we see a long log to create the debci environment and try to
> > install the package ... which fails.
>
> 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
autopkgtest [21:46:22]: @@@@@@@@@@@@@@@@@@@@ test bed setup
Get:1 http://incoming.debian.org/debian-buildd buildd-experimental InRelease [39.8 kB]
Get:2 http://incoming.debian.org/debian-buildd buildd-experimental/main armhf Packages [26.3 kB]
Fetched 66.1 kB in 1s (71.0 kB/s)
Reading package lists...
Get:1 http://deb.debian.org/debian experimental InRelease [72.3 kB]
Get:2 http://deb.debian.org/debian experimental/contrib Sources [2,052 B]
Get:3 http://deb.debian.org/debian experimental/non-free Sources [3,416 B]
Get:4 http://deb.debian.org/debian experimental/main Sources [334 kB]
Get:5 http://deb.debian.org/debian experimental/main armhf Packages [400 kB]
Get:6 http://deb.debian.org/debian experimental/contrib armhf Packages [2,500 B]
Get:7 http://deb.debian.org/debian experimental/non-free armhf Packages [1,776 B]
Fetched 816 kB in 0s (2,498 kB/s)
and way later in the end it says
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
drop-seq-tools : Depends: libgkl-java but it is not installable
Depends: libpicard-java but it is not installable
Depends: picard-tools but it is not installable
E: Unable to correct problems, you have held broken packages.
run-unit-test FAIL badpkg
blame: drop-seq
badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U.
autopkgtest [21:46:47]: @@@@@@@@@@@@@@@@@@@@ summary
run-unit-test FAIL badpkg
For me that's an attempt to run a test when apt starts getting files.
That's what I was talking about. 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.
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).
> > 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.
> > 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.
> > 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?
> 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).
>
> > Than there would be no pressure on maintainers side to actively exclude
> > these architectures from tests.
>
> Indeed. That should be hardly needed.
Kind regards
Andreas.
[1] https://ci.debian.net/data/autopkgtest/unstable/armhf/d/drop-seq/7114930/log.gz
[2] https://ci.debian.net/data/autopkgtest/unstable/arm64/d/drop-seq/8106496/log.gz
[3] https://ci.debian.net/packages/d/drop-seq/unstable/arm64/
--
http://fam-tille.de
Reply to: