Comment 3 for bug 1723223

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.