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. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1723223 Title: linux-lts and linux-hwe autopkgtests fail due to version mismatch Status in linux package in Ubuntu: Invalid Status in linux source package in Trusty: In Progress Status in linux source package in Xenial: In Progress Bug description: the autopkgtests for the kernel include 'ubuntu-regression-suite' which contains this test: sver=`dpkg-parsechangelog -SVersion` read x rver x </proc/version_signature flavour=${rver#*-*-} rver=${rver%-$flavour} echo "Source Package Version: $sver" echo "Running Kernel Version: $rver" if [ "$sver" != "$rver" ]; then echo "ERROR: running version does not match source package" 1>&2 exit 1 fi However, when testing a -lts or -hwe kernel build, the running kernel will not match because the running kernel is the stock version while the building/testing kernel is the newer -lts/-hwe version. This failure results in autopkgtest errors for all other packages that invoke linux autopkgtests - for example, initramfs-tools, systemd, ... This requires unnecessary work to investigate the autopkgtest errors every time, only to find it's a autopkgtest error. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1723223/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp