Comment 8 for bug 1668353

> The point is not mirror lag, but that AIUI if there is a newer kernel in -proposed than the one we've booted on the instance, the tests fail due to the mismatch.

This is not generally true. Whenever the setup commands (like "upgrade testbed to -proposed") install a kernel or anythign else that affects booting from -proposed, it gets rebooted before running the test. E. g. in this one:

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/l/linux/20170111_222734_8664a@/log.gz

you see:

    autopkgtest [16:43:42]: testbed running kernel: Linux 4.9.0-12-generic #13-Ubuntu SMP Mon Jan 9 20:06:25 UTC 2017

and that's indeed the one that was previously installed from -proposed.

> http://autopkgtest.ubuntu.com/packages/l/linux/zesty/amd64 actually shows
no successful test runs except the first.

If you look at the first one more closely, it's 4.4 from April 2016. It's not a "real" zesty test, it's just the last successful result that we imported into zesty (and yakkety); we do that for all packages at the beginning of a release cycle to ensure that our "always failed vs. regression" logic works. Our kernel tests actually have been broken since then.

> But when I look at that last log, which shows in the table as: Version: 4.10.0-9.11, Triggers: gcc-6/6.3.0-8ubuntu1, this looks to me like the *wrong* version of Linux is being tested. Why are we testing a proposed-only version of the kernel to validate the new upload of gcc-6 in proposed?

Wrong way around. This tests current gcc-6 against a proposed -linux. We do that to ensure gcc gets along with the new linux-libc-dev. In particular, gcc, binutils, and linux all cross-test each other on every change.