SRUs which cause autopkgtest regressions in reverse-dependencies

Christopher James Halse Rogers christopher.halse.rogers at canonical.com
Wed Jun 10 02:11:00 UTC 2015


So, the SRUs in pending-sru which cause autopkgtest regressions in their
reverse-dependencies have started to bug me.

On inspection it seems that a significant fraction are due to changes in
the test environment - some have been obviously broken by default
dependency changes (dbus-test-runner expects libtool-bin to have been
installed, deja-dup expects dbus-launch to be installed, and so on).

In fact, of all the failures that I've checked, there's not a single one
that I'm certain is _not_ due to unrelated test environment changes.

I've released gvfs, as all those failures look slam-dunk environment
changes and the bug looked sufficiently annoying.

What should we do with the others? Should we ignore autopkgtest failures
entirely prior to vivid? Should we ignore autopkgtest failures that look
test-environment related? Should we require SRU uploaders to SRU not just
their package, but also SRU DEP-8 fixes for any of their
reverse-dependencies?

Hm. Can we post-hoc mark an autopkgtest as always-failed, and so not
trigger the regression detection?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-archive/attachments/20150610/72462355/attachment.html>


More information about the ubuntu-archive mailing list