On Tue, 27 Dec 2016 at 12:22:03 +0100, Santiago Vila wrote:
> Cc:ing the submitter, who also happen to be a Release Manager.
> I wish we would not lower our standards to allow packages like
> this one to FTBFS as much as they want as a normal thing.
Speaking as a maintainer of a package whose tests intermittently fail
(ostree), I'd love to have a standard way to get test results recorded,
without partial/intermittent test failures being treated as RC or
preventing testing migration. The bugs that cause the test failure would
often not qualify to be RC if the tests weren't run at build time or
weren't hooked up to autopkgtest, but many packages' tests can only be
run at build time or have better coverage when run at that time.
> Cc:ing also Simon McVittie: I have not tested version 2.56.0-2 yet,
> sorry. Is it likely or possible that the changes in such version make
> the failing tests I experience to disappear, or are they unrelated?
Looking at the first couple of failures, a segmentation fault in a
test whose name mentions "async" seems like it might be the bug fixed
in 2.56.0-2. That bug was a lack of thread safety, and GLib APIs like
libsoup frequently use a worker thread to make a blocking operation
asynchronous; in particular it was one of at least two root causes
for ostree's tests intermittently failing.
ostree's tests are *still* intermittently failing (with a timeout,
so probably a deadlock or something, which I haven't been able to fix),
but I've made them non-fatal at build time because that isn't a
regression. I don't know whether the timeout is libsoup's fault or
ostree's fault (or something else).
S
