ci.debian.org and pkg-perl packages
On Tue, Sep 09, 2014 at 05:58:57PM +0200, gregor herrmann wrote:
> I looked at a handful of failure reports at
Thanks for this.
> (1) One pattern I saw was (in this case from
> 08:07:25: Error: Unable to initialize GTK+, is DISPLAY set properly?
> not ok 7 - require Wx;
> That's where the test suite needs DISPLAY / an X server, and where we
> run the tests during package build with xvfb-run:
> xvfb-run -a dh_auto_test
> Not sure how/where this can happen for our autopkgtest tests?
We could make the smoke test check for /usr/bin/xvfb-run and use
it if available. The build dependencies will have pulled it in
if it's used by debian/rules.
> (2) Another interesting case, discovered by Niko and mentioned on IRC,
> are packages like
> # Failed test 'Got file list for package libautodie-perl'
> # at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/syntax.t line 49.
> # Looks like you failed 1 test of 3.
> which looks like autopkgtest doesn't test the code from the actual
> separate libautodie-perl package but is "satisfied" by the virtual
> libautodie-perl provided by perl-modules.
Yes, this seems to happen with all dual life modules (libio-compress-perl,
libjson-pp-perl, libhttp-tiny-perl, ....) It's clearly a bug
in autopkgtest: even though there's an '@' in the Depends line in
debian/tests/control, the actual package is not installed if it's already
Provided by another installed package.
> (3) Another failure type seems to be packages with "missing" build
> dependencies, like
> "Missing" under quotation marks since they are not missing for the
> tests at build time and therefor also not for the smoke tests, but
> missing for the syntax.t test:
> In this case libdbi-perl etc. are in Build-Depends, so the smoke test
> passes, but syntax.t fails because they are no runtime dependencies.
> (Which might be a mistake but it's not so uncommon that dependencies
> for optional modules are in Recomends or Suggests.)
We could skip the syntax.t check if there are Recommendations or
Suggestions in debian/control. The alternative is to maintain
a list of modules that we don't want to check, and that smells
a bit too much like busywork.
> (4) Next failure type, e.g. in
> Tests pass but produce warnings in use.t:
> # Possible precedence issue with control flow operator at /usr/lib/x86_64-linux-gnu/perl5/5.20/Alien/wxWidgets/Utility.pm line 77.
> ok 1 - /usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1 exited successfully
> not ok 2 - /usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1 produced no output
Given bugs like #759329, I believe this is a real bug and we actually want
failures on it. But we can remove the -w part if others disagree?
> (5) https://people.debian.org/~mpitt/tmp/perl-failures/libapache-authenhook-perl/log
> is a different version of the POD problem; in this case t/99pod.t
> tries to assemble a list of files to test in the source tree and
> finds none since we're moving the tests away.
> Maybe we should add a dummy $TDIR/blib/Foo/Bar.pm with '1;' for those
This might be on the diminishing returns side, not sure how common
this pattern is? OTOH it's simple enough to implement.
> I've seen something similar yesterday in libtest-cleannamespaces-perl
> and tried this hack:
> Depending on the general aesthetic feelings, we might do something
> like this from the smoke test script?
I guess it doesn't hurt...
> Ok; this was only from looking at the failure in packages from a* to
> liba* ...
Looks like there's plenty to do, yeah :)
Niko Tyni ntyni at debian.org