[00:08] phillw: this is, indeed, the current kernel for yakkety. Why the version string, though, I do not know [00:09] hggdh: thank you, sir. I'll *carry on testing* :) [00:10] :-) === JanC is now known as Guest98943 === JanC_ is now known as JanC [02:52] 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] bjf: thankyou for the clarification :) [09:33] phillw, hggdh: the version string is correct. [09:33] all other kernels in 4.4 series were built for xenial and copied into yakkety. [09:33] this one was built in yakkety with sources different from xenial. [09:34] hence the probably-will-never-class-with-xenial version number. [09:34] 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] phillw, also see #ubuntu-release backlog from last week. [09:35] 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] phillw, #ubuntu-release is IRC channel. [09:36] phillw, there is nothing to clarify and nobody is scratching their heads =) [09:36] xnox: okies, just me being dumb, in that case :) [09:36] version strings really do not matter at all, and encode ABI [09:37] phillw, to be honest we could be using ephemeral key hash in the package names, to encode the ABI. [09:37] just to make sure the abi tag is meaningless fingerprint like string. [09:37] 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] nope. [09:38] it picks last configured kernel. [09:38] ubuntu -> vmlinuz -> symlink to last kernel image that dpkg postinst was called on. [09:38] that has always been the case. [09:41] 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!!! === mhcerri_ is now known as mhcerri [13:30] Your kernel's Performance Events Subsystem does not support your processor type. [13:30] horum, but ibm say it should be.... [13:31] does the kernel in yakkety support MADV_FREE? [13:33] chrisccoulson, that is documented as 4.5+ so we will, and currently don't [13:34] apw, ah thanks. See bug 1613258 for context - the new glibc defines MADV_FREE [13:34] bug 1613258 in glibc (Ubuntu) "signal 4 ILL_ILLOPN in webbrowser-app tests (glibc upgrade?)" [Critical,Triaged] https://launchpad.net/bugs/1613258 [13:35] chrisccoulson, that may have been built with the 4.6 which was in -proposed for a time (glibc) [13:35] that said, i am supprised that glibc is assuming it can use it [13:35] infinity, ^ [13:39] chrisccoulson, oh but it is likely the seccomp bits right? so just a profile change ? [13:41] 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] 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] 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] so one uses it in 4.5 and not before that all shiney and automatically [13:45] apw, we could probably do that [13:46] i assume it uses like _DONTNEED or similar instead === ghostcube__ is now known as ghostcube === unixabg_ is now known as unixabg