ci.debian.org and pkg-perl packages

Wed Sep 10 16:19:15 UTC 2014

On Tue, 09 Sep 2014 20:14:59 +0300, Niko Tyni wrote:

> > (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.

Thanks for your commit!

I've tested it now with kephra, and it works.
(The tests fail later but for different reasons ...)

I've just pushed a cosmetic change.

> > (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.

Should be (temporarily fixed) with Martin's change to autopkgtest;
thanks!

> > (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.

Thanks for the commit for this issue as well.
Tested with alice, and it works as well for me:

1..4
ok 1 - Package alice is known to dpkg
ok 2 - Got status information for package alice
ok 3 # skip alice has Recommendations or Suggestions
ok 4 # skip alice has Recommendations or Suggestions
ok
All tests successful.
Files=1, Tests=4,  0 wallclock secs ( 0.04 usr  0.00 sys +  0.04 cusr  0.00 csys =  0.08 CPU)
Result: PASS

> > (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?

Ok.

> > (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...

And another commit - thanks :)

Tested with libapache-authenhook-perl, and it works as well:

t/99pod.t ....... 
1..1
ok 1 - POD test for blib/lib/Debian/pkg-perl/Foobar.pm (no pod)
ok

> > Ok; this was only from looking at the failure in packages from a* to
> > liba* ...
> Looks like there's plenty to do, yeah :)

Looks like we (well, mostly you :)) have solved 4 issues!

So I guess we can upload a new pkg-perl-tools ...

What are the next steps afterwards? Check for other build failures in
the logs? Re-try the failed packages with the newer
pkg-perl-autopktest?

Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Joint Venture: Ne Frau, die sich mich leisten kann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital Signature
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20140910/6d410ca4/attachment.sig>