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
Attachment:
signature.asc
Description: Digital Signature