On Tue, Oct 10, 2017 at 2:11 AM, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Mon, Oct 09, 2017 at 03:37:43PM -0500, Tom Gall wrote: >> On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman >> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >> >> kernel: 4.9.54-rc1 >> >> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git >> >> git branch: linux-4.9.y >> >> git commit: 1852eae92c460813692808234da35d142a405ab7 >> >> git describe: v4.9.53 >> >> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53 >> >> >> >> >> No regressions (compared to build v4.9.52-65-gaceea42c68d9) >> > >> > How did your arm64 test build? There was a build regression in the -rc1 >> > release, are you sure you actually ran the correct image? >> >> So the header in that report was wrong. That's a c/n/p error on my >> part. I was in a rush to get you data before I was going to be gone >> for the day on Sat and wanting to get what we had into your hands >> before the Sunday deadline. >> >> The test results was for the RC as of commit >> 0e59436504287cddb9663857ae69c100b55f5e85 >> >> If you want to see the 'ugly' raw data it's all here : >> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/ > > I still don't understand. That _build_ should have failed, how did it > succeed enough to actually run the tests at all? Looks like it's because we don't build with CONFIG_KASAN. In the case where the build fails, the system won't run tests since there's no image to run. Likewise if we have a situation where the build fails for some arches but not all we'll only get partial test results for the builds that succeeded and likewise nothing for what failed. The results reported were based on commit id 0e59436504287cddb9663857ae69c100b55f5e85 Unfortunately that commit id doesn't exist anymore since it was replaced by the 4.9.54 release which was commit ID f37eb7b586f1dd24a86c50278c65322fc6787722 (and yes the release test results == rc test results that were reported) Things get a little confusing when one can't go back and compare commit ids. Losing history kinda sucks. I've thought about some other way to uniquely tie results to an rc patch maybe working off of : https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/ But like in this instance if there isn't both the rc1 and rc2 for posterity it wouldn't help. Least for now we have commit ids, git describe and kernel version from the Makefile. Why wasn't there an rc2 patch file? > thanks, > > greg k-h -- Regards, Tom Director, Linaro Mobile Group Linaro.org │ Open source software for ARM SoCs irc: tgall_foo | skype : tom_gall "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian