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 https://people.debian.org/~mpitt/tmp/perl-failures/ (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? (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 (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 with: # 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 .. 1..3 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 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: # 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 https://people.debian.org/~mpitt/tmp/perl-failures/libalien-wxwidgets-perl/log Tests pass but produce warnings in use.t: # Subtest: all modules in libalien-wxwidgets-perl pass the syntax check 1..3 # 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 ok 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 .. 1..2 # 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: https://people.debian.org/~mpitt/tmp/perl-failures/libaudio-ecasound-perl/log (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? 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? Ok; this was only from looking at the failure in packages from a* to liba* ... 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 `-
Attachment:
signature.asc
Description: Digital Signature