linux-lts and linux-hwe autopkgtests fail due to version mismatch

For example, here is a autopkgtest failure that was flagged by my update to initramfs-tools package:

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty/trusty/ppc64el/l/linux-lts-xenial/20171012_183054_740b6@/log.gz

the failure is simply due to the ubuntu-regression-suite test:

autopkgtest [18:30:28]: test ubuntu-regression-suite: [-----------------------
Source Package Version: 4.4.0-97.120~14.04.1
Running Kernel Version: 3.13.0-133.182
ERROR: running version does not match source package

the failing test was added by bug 1385330

This unfortunately is not a simple fix.

To start with, the core problem is that the 'ubuntu-regression-suite' assumes that the currently installed kernel == the built kernel, but that is not guaranteed by the test, because it defines 'Depends:' values, but does not include the @ dependency (which autopkgtest resolves to all the binaries defined by this source package).

Now we get into deeper problems:

Unfortunately, we can't simply add @ to the test Depends: entries, because autopkgtest includes the dbgsym ddebs files but isn't able to actually find the ddeb file (likely because it ends with 'ddeb' instead of 'deb'). This is work-around-able by adding the line 'Package-type: ddeb' (or anything not 'deb') to the dbgsym entry in the control file.

That gets us past the missing dbgsym ddeb, but autopkgtest can't tell that the kernel is built in different 'flavours', and the kernel currently only builds the first 'flavour' during autopkgtest runs, assuming that testing all flavours isn't necessary. But, adding @ to Depends: adds the binary files from all flavours, not just the one that was built. So, autopkgtest is not able to find the (e.g.) -lowlatency flavoured files, because only (e.g.) -generic flavoured files have been built.

The rules file could be changed to build all flavours, even if only running autopkgtests, but that would be a significant increase in time and computing power, just to work around an annoying issue.

Instead of adding @ to the ubuntu-regression-suite, we could add the specific linux-image-VERSION and linux-image-extra-VERSION files that are built for this specific kernel version source package; but the test control file is currently static, at debian/tests/control. That would need to be changed to be auto-created similar to the debian/control file.

autopkgtest may also be fixable to do a better job of replacing @ with only the files that were actually built.

or, the 'ubuntu-regression-suite' test could simply be skipped if the package under test isn't 'linux' - assuming that its regression test suite only really needs to be applied to the normal 'linux' source package, not any of the lts/hwe/hwe-edge backports. That's certainly the easiest way to fix this.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1723223

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html

@builddeps@ will be replaced by the package's Build-Depends:, Build-Depends-Indep:, and build-essential. This is useful if you have many build dependencies which are only necessary for running the test suite and you don't want to replicate them in the test Depends:. However, please use this sparingly, as this can easily lead to missing binary package dependencies being overlooked if they get pulled in via build dependencies.

After a discussion with vorlon, his proposal is to blacklist the "special" kernels so they're ignored for autopkgtests.

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Expired for linux (Ubuntu Trusty) because there has been no activity for 60 days.]

[Expired for linux (Ubuntu Bionic) because there has been no activity for 60 days.]

[Expired for linux (Ubuntu Cosmic) because there has been no activity for 60 days.]

[Expired for linux (Ubuntu Xenial) because there has been no activity for 60 days.]

[Expired for linux (Ubuntu Disco) because there has been no activity for 60 days.]