[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ci.debian.org and pkg-perl packages

On Tue, 09 Sep 2014 08:04:16 +0200, Martin Pitt wrote:

> gregor herrmann [2014-09-08 22:40 +0200]:
> > I'd just take something like
> > % grep-available -s Package -FMaintainer pkg-perl-maintainers /var/lib/apt/lists/ftp.ch.debian.org_debian_dists_unstable_main_source_Sources | sort -u
> Ah, good. I did that. I created https://titanpad.com/jQv06Sq0up to
> coordinate this, I also added the command for the testing loop that I
> use.

Great, thanks!

I looked at a handful of failure reports at

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

(2) Another interesting case, discovered by Niko and mentioned on IRC,
are packages like
(and I've seen similar things with adt-run locally yesterday as well
without understanding them):

The first test (smoke) passes, and then the second (syntax.t) fails

#   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.
/usr/share/pkg-perl-autopkgtest/runtime-deps.d/syntax.t .. 
ok 1 - Package libautodie-perl is known to dpkg
not ok 2 - Got file list for package libautodie-perl
ok 3 # skip nothing to test
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/3 subtests 
    (less 1 skipped subtest: 1 okay)

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.

If this is the case, that would hit a whole group of dual-lifed
modules, and probably needs to be dealt with at the autopkgtest side
(at least I have no idea what we could do here) ...

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

    # Can't locate AnyEvent/Redis.pm in @INC (you may need to install the AnyEvent::Redis module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.0 /usr/local/share/perl/5.20.0 /usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl .) at /usr/share/perl5/App/Alice/MessageStore/Redis.pm line 4.
    # BEGIN failed--compilation aborted at /usr/share/perl5/App/Alice/MessageStore/Redis.pm line 4.
    not ok 2 - /usr/bin/perl -wc /usr/share/perl5/App/Alice/MessageStore/Redis.pm exited successfully

Similar is https://people.debian.org/~mpitt/tmp/perl-failures/libapache-session-browseable-perl/log:

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

Other example: https://people.debian.org/~mpitt/tmp/perl-failures/libauthen-sasl-perl/log

(4) Next failure type, e.g. in

Tests pass but produce warnings in use.t:

    # Subtest: all modules in libalien-wxwidgets-perl pass the syntax check
    # Name "Alien::wxWidgets::Config::gtk2_3_0_1_uni_gcc_3_4::VAR1" used only once: possible typo at /usr/lib/x86_64-linux-gnu/perl5/5.20/Alien/wxWidgets/Config/gtk2_3_0_1_uni_gcc_3_4.pm line 10.
    ok 1 - /usr/bin/perl -wc /usr/lib/x86_64-linux-gnu/perl5/5.20/Alien/wxWidgets/Config/gtk2_3_0_1_uni_gcc_3_4.pm exited successfully
    # Possible precedence issue with control flow operator at /usr/lib/x86_64-linux-gnu/perl5/5.20/Alien/wxWidgets/Utility.pm line 77.
    # Name "Alien::wxWidgets::dont_remap" used only once: possible typo at /usr/lib/x86_64-linux-gnu/perl5/5.20/Alien/wxWidgets/Utility.pm line 271.
    ok 2 - /usr/bin/perl -wc /usr/lib/x86_64-linux-gnu/perl5/5.20/Alien/wxWidgets/Utility.pm exited successfully
    # Possible precedence issue with control flow operator at /usr/lib/x86_64-linux-gnu/perl5/5.20/Alien/wxWidgets/Utility.pm line 77.
    ok 3 - /usr/bin/perl -wc /usr/lib/x86_64-linux-gnu/perl5/5.20/Alien/wxWidgets.pm exited successfully
ok 3 - all modules in libalien-wxwidgets-perl pass the syntax check
All tests successful.
Files=1, Tests=3,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.06 cusr  0.00 csys =  0.08 CPU)
Result: PASS

#   Failed test '/usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1 produced no output'
#   at /usr/share/pkg-perl-autopkgtest/runtime-deps.d/use.t line 73.
# Looks like you failed 1 test of 2.
/usr/share/pkg-perl-autopkgtest/runtime-deps.d/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
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/2 subtests 

Other example:

(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

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?

Ok; this was only from looking at the failure in packages from a* to
liba* ...


 .''`.  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

Attachment: signature.asc
Description: Digital Signature

Reply to: