ci.debian.org and pkg-perl packages

[Niko Tyni]

On Tue, Sep 09, 2014 at 05:58:57PM +0200, gregor herrmann wrote:
 
> I looked at a handful of failure reports at
> https://people.debian.org/~mpitt/tmp/perl-failures/

Thanks for this.

> (1) One pattern I saw was (in this case from
> https://people.debian.org/~mpitt/tmp/perl-failures/kephra/log):
> 
> 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:
> 
> override_dh_auto_test:
>     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
> https://people.debian.org/~mpitt/tmp/perl-failures/libautodie-perl/log

> #   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
> https://people.debian.org/~mpitt/tmp/perl-failures/alice/log
> 
> "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
> https://people.debian.org/~mpitt/tmp/perl-failures/libalien-wxwidgets-perl/log
> 
> 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
> cases?

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:
> https://anonscm.debian.org/cgit/pkg-perl/packages/libtest-cleannamespaces-perl.git/commit/?id=5a7a6fcdd2533f9c3e35216867bf31d576f55b65
> 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