Please continuously backport autopkgtest (main) from xenial

[Martin Pitt]

Please backport autopkgtest 3.17.4 (main) from xenial to trusty and intermediate releases. I'm actually requesting a permanent approval so that I can do the backports of future releases without having to re-seek approval for every version.

Reason for the backport:
========================
autopkgtes keeps evolving and getting fixes for e. g. newer phone releases, adding support for running in the cloud and on MaaS, etc. Production CI always uses latest autopkgtest git for testing packages for all supported Ubuntu releases. I make sure that the latest package is always backportable to >= precise. The test suite runs during package build, and more tests as autopkgtest (for itself).

Right now developers on trusty or e. g. wily often complain that they get failures with the old adt-run, and we ask them to download the latest .deb from the development series and install it with dpkg -i.

Testing:
========
* trusty/vivid/wily:
[X] Package builds without modification
[X] autopkgtest installs cleanly and runs

Reverse dependencies:
=====================
The following reverse-dependencies need to be tested against the new version of autopkgtest. For reverse-build-dependencies (-Indep), please test that the package still builds against the new autopkgtest. For reverse-dependencies, please test that the version of the package currently in the release still works with the new autopkgtest installed. Reverse- Recommends, Suggests, and Enhances don't need to be tested, and are listed for completeness-sake.

autopkgtest
-----------
* autopkgtest-xenlvm (built from same source package, but this has never been used/tested and we stopped supporting it for lack of interest)
* python-jsonschema
  [ ] trusty (Reverse-Build-Depends) (not used at all, b-d is wrong)
* packaging-dev
  [ ] trusty (Reverse-Recommends) (meta-package)
* pytest-instafail
  [ ] trusty (Reverse-Build-Depends) (not used at all, b-d is wrong)

[Iain Lane (laney)]

This seems fine, as long as you smoke test each time (or have CI?) before uploading.

We've been doing a similar-ish thing for LXC, although there Stéphane has been filing new bugs each time. I don't think we need to bother with that for autopkgtest (maybe it makes more sense for LXC as the backport has a source change).

Do you want to try preparing and uploading the source package using backportpackagE?

[Martin Pitt (pitti)]

> This seems fine, as long as you smoke test each time (or have CI?) before uploading.

Tests run during package build and autopkgtest has an autopkgtest for itself too (http://autopkgtest.ubuntu.com/packages/a/autopkgtest/ -- does that make some logic circuits explode?). We use the latest autopkgtest in production on a trusty host.

I know several users who run the latest versions on vivid and wily (which is where this backport request is coming from), but we don't have systematic automatic testing of the QEMU and LXC backends on these releases. I can commit to manually giving these a spin on my own machine before I issue a backport request, though.

> Do you want to try preparing and uploading the source package using backportpackage?

Done now, for trusty, vivid, and wily.

Thanks!

[Iain Lane (laney)]

Accepted!