On Tue, Oct 10, 2017 at 10:23:43AM -0500, Tom Gall wrote: > 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. Ick, not good, why not? Surely you enable all of the options you can for your hardware, right? And enabling stuff like this is good no matter what... > 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. Ok, good (odd line-wrapping, did I give you too many '\n'?) > 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? There was, I announced it. But oh, look, I never pushed it out to kernel.org, my fault. I guess no one actually tested it except me :) Going off of the quilt tree might be good, that's what others do today (hint...) thanks, greg k-h