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

Test suite failures after DepMap merge



Hi,

I've just updated my local copy of the lintian repo, thus pulling in the
DepMap changes.  Running the testsuite now produces a number of failures
which did not previously occur.

Some appear to be due to the output being sorted in a different manner;
the lintian-output-{colons, letter,xml} tests are affected here.

Some others are related to options to include or exclude checks or tags:

Running test runtests-options 1.0... building... testing... FAILED:
--- t/tests/runtests-options/tags       2009-01-25 18:15:02.000000000 +0000
+++ debian/tests/tags.runtests-options  2010-03-26 10:22:25.000000000 +0000
@@ -1 +0,0 @@
-E: runtests-options source: invalid-standards-version 1.2.3

Some investigation reveals that this is due to the use of -C.  Inserting a
print to stderr at the start of checks/standards-version and running "
LINTIAN_ROOT=. ./frontend/lintian -C standards-version -d
debian/tests/runtests-options_1.0.dsc" reveals that the check script is
never executed.

Dropping the -C and rerunning the test with all options enabled correctly
outputs the tag and the extra stderr output.

--- t/tests/lintian-check-tags-file/tags        2009-12-24
09:24:12.000000000 +0000
+++ debian/tests/tags.lintian-check-tags-file   2010-03-26
10:23:15.000000000 +0000
@@ -1,2 +0,0 @@
-E: lintian-check-tags-file: section-is-dh_make-template
-W: lintian-check-tags-file source: debhelper-but-no-misc-depends
lintian-check-tags-file

Finally, the generic-empty test seems to loop forever.  In one case it had
been running for about five minutes before I hit ^C, giving:

Running test generic-empty 1.0... building... testing... make: make: ***
wait: No child processes.  Stop.
make: *** Waiting for unfinished jobs....
make: *** wait: No child processes.  Stop.

As a further test I tried running just that one test on another machine
from a fresh checkout - after an hour, it was still running and I had to
SIGKILL it as it wasn't responding to SIGTERM.

Adam


Reply to: