ci.debian.org and pkg-perl packages
Hello all,
Niko Tyni [2014-09-09 20:14 +0300]:
> > (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.
Yes, that seems robust and a good idea. Indeed I ran the first couple
of tests with my existing $DISPLAY until I saw perl-tk windows flying
around, then I ran the remaining ones with env -u DISPLAY. So adding
that automatic "run under xvfb-run -a if available" to
pkg-perl-autopkgtest seems fine to me.
> > (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.
This is fixed now in autopkgtest, but the first half of the tests
didn't yet run with that.
> > (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.
I don't understand that fully, but I want to point out that we have
the "needs-recommends" restriction in autopkgtest which will cause
the test dependencies' recommends to be installed. Would that help?
Alternatively, could the syntax check be done in the build-deps check
instead of the runtime-deps check?
Together with your couple of other proposals I think we have enough
fixes to re-run the ~ 370 failures once they are in
pkg-perl-autopkgtest (and of course the fixes which were committed
recently to autopkgtest itself). Let me know when you'd like this to
get done.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Reply to: