Source: gnupg2
Version: 2.2.9-1
X-Debbugs-CC: debian-ci@lists.debian.org, release@lists.debian.org
User: debian-ci@lists.debian.org
Usertags: flaky
Dear maintainers,
Last month we discussed the fact that the autopkgtest of gnupg2 was
fragile in the ci.debian.net setup which is used for unstable-to-testing
migration. Apparently your package can not always be tested on the
architecture the test runs on (amd64 needs i386 packages, arm64 needs
armhf). Due to that discussion, I have marked gnupg2 as flaky (which
means failures will be ignored) in the unstable-to-testing migration
software as I believe there are two issues here:
1) your are testing packages in a different release than the test runs on.
2) when installation of the package in your test fails, you may delay
packages for the wrong reason, as happened to glibc.
I have multiple suggestions to improve the situation. I'll write them
down in *my* (and hopefully the release teams) preferred order, but I
can understand it when you chose another alternative due to
ci.debian.net not running an architecture yet where you can test natively.
a) add wine32 to the test dependencies, but you may want to wait with
that until we fixed bug 905311 [905311].
b) mark your test as skippable (that is a relative new restriction) and
exit 77 on architectures (yes, also the one you currently exit 0) that
can't run the test natively.
c) mark your test as skippable and exit 77 when apt-get install fails.
d) [please don't do this] dive into the code of autopkgtest, learn how
package pinning is set up for migration testing, and imitate the correct
fall backs in case the apt install fails.
Note: you can find this in your log:
'''
WARNING: apt does not have a stable CLI interface. Use with caution in
scripts.
'''
=> apt-get is preferred in scripts over apt.
Paul
[905311] https://bugs.debian.org/905311
-------- Forwarded Message --------
Subject: Re: gnupg2 autopkgtest uses multi-arch which seems fragile
Date: Mon, 9 Jul 2018 15:20:23 +0200
From: Paul Gevers <elbrus@debian.org>
To: gnupg2@packages.debian.org, Debian CI team
<debian-ci@lists.debian.org>, glibc@packages.debian.org
Hi Ian,
Thanks for helping out.
On 09-07-18 15:02, Ian Jackson wrote:
> Ian Jackson writes ("Re: gnupg2 autopkgtest uses multi-arch which seems fragile"):
>> I looked in:
>>
>> * debian/tests/control in the gnupg2 source tree.
>> One test, of gpgv-win32. Depends on gpgv-win32, gnupg2,
>
> I have found it:
>
> debian/tests/gpgv-win32 manually installs wine32 using apt.
I noticed my original e-mail wasn't very clear because I thought the
above was obvious.
> This seems quite wrong. If a package needs to be installed, it should
> be handled via Depends in debian/tests/control. Otherwise all of the
> machinery to select which packages are being tested is utterly
> defeated.
Some packages have the purpose of installing stuff, so they may want to
do so I guess (e.g. apt does that). So I nearly agree with your
argument, but not fully. But as an example of your argument we already
have bug #900470 where syslog-ng tries to upgrade upgrade itself but
fails to do so due to our setup. The argument should be that in
autopkgtests the setup may be weird and tests should not need to know. I
guess what gnupg2 wants/needs is a way to either declare multi-arch
(maybe a new restriction?) with semantics to declare the dependencies
there or maybe they would be happy with an i386 test only, but ci.d.n
doesn't have that yet.
Paul
Attachment:
signature.asc
Description: OpenPGP digital signature