[00:08] <hggdh> phillw: this is, indeed, the current kernel for yakkety. Why the version string, though, I do not know
[00:09] <phillw> hggdh: thank you, sir. I'll *carry on testing* :)
[00:10] <hggdh> :-)
[02:52] <bjf> phillw, from the changelog the odd abi number is to avoid namespace clash with xenial kernels while yakkety ist still a 4.4 kernel (which hopefully isn't for much longer)
[09:19] <phillw> bjf: thankyou for the clarification :)
[09:33] <xnox> phillw, hggdh: the version string is correct.
[09:33] <xnox> all other kernels in 4.4 series were built for xenial and copied into yakkety.
[09:33] <xnox> this one was built in yakkety  with sources different from xenial.
[09:34] <xnox> hence the probably-will-never-class-with-xenial version number.
[09:34] <xnox> in theory this would not be required at all, as by now, one usually has a new kernel series in the development release - e.g. v4.6/v4.7/v4.8 but we are not there yet.
[09:34] <xnox> phillw, also see #ubuntu-release backlog from last week.
[09:35] <phillw> xnox: I'm on the mailing lists, but missed this one.. Would it be possible to put out a mail to clarify for any others who are testing and scratching their heads? :)
[09:36] <xnox> phillw, #ubuntu-release is IRC channel.
[09:36] <xnox> phillw, there is nothing to clarify and nobody is scratching their heads =)
[09:36] <phillw> xnox: okies, just me being dumb, in that case :)
[09:36] <xnox> version strings really do not matter at all, and encode ABI
[09:37] <xnox> phillw, to be honest we could be using ephemeral key hash in the package names, to encode the ABI.
[09:37] <xnox> just to make sure the abi tag is meaningless fingerprint like string.
[09:37] <phillw> that is something else you've just taught me! I was under the false impression that grub always chose the highest number for the default kernel :)
[09:38] <xnox> nope.
[09:38] <xnox> it picks last configured kernel.
[09:38] <xnox> ubuntu -> vmlinuz -> symlink to last kernel image that dpkg postinst was called on.
[09:38] <xnox> that has always been the case.
[09:41] <phillw> thanks, I'll leave you good people in peace!! On the plus side, if I do get asked I can reply... saves another person landing here asking!!!
[13:30] <xnox> Your kernel's Performance Events Subsystem does not support your processor type.
[13:30] <xnox> horum, but ibm say it should be....
[13:31] <chrisccoulson> does the kernel in yakkety support MADV_FREE?
[13:33] <apw> chrisccoulson, that is documented as 4.5+ so we will, and currently don't
[13:34] <chrisccoulson> apw, ah thanks. See bug 1613258 for context - the new glibc defines MADV_FREE
[13:35] <apw> chrisccoulson, that may have been built with the 4.6 which was in -proposed for a time (glibc)
[13:35] <apw> that said, i am supprised that glibc is assuming it can use it
[13:35] <apw> infinity, ^
[13:39] <apw> chrisccoulson, oh but it is likely the seccomp bits right?  so just a profile change ?
[13:41] <apw> chrisccoulson, in the sense it is resonable for glibc to define it, and the kernel to return EINVAL or indeed work, but we need the seccomp profile to reflect that possibility
[13:43] <chrisccoulson> apw, we'll probably end up doing the same as http://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?h=49-based&id=b12ffcd411d4776f7120ccecb3be34344d930d2b
[13:45] <apw> chrisccoulson, wouldn't it make more sense to try MADV_FREE and if it fails ENOSUPPORT or whatever dropback to whatever it does when it doesn't have _FREE ?
[13:45] <apw> so one uses it in 4.5 and not before that all shiney and automatically 
[13:45] <chrisccoulson> apw, we could probably do that
[13:46] <apw> i assume it uses like _DONTNEED or similar instead