[09:55] <xnox> Ubuntu-4.8.0-11.12 tag does not appear to be in the yakkety repository
[09:59] <apw> xnox, i have it here, and it was a leann one so i must have gotten it from the cental repository
[10:00] <apw> xnox, it might not be in linear history, so you would need to git fetch --tags origin
[10:05] <xnox> oooh, let me try that.
[10:05] <xnox> i already see Ubuntu-4.8.0-12.13, so yeah i must be post-rebase.
[10:06] <xnox> $ git fetch yakkety Ubuntu-4.8.0-11.12 -> was quicker
[10:06] <xnox> apw, thanks! i had no idea that git does not fetch unreachable tags by default.
=== sts is now known as Guest8435
=== JanC is now known as Guest12202
=== JanC_ is now known as JanC
[16:29] <elmo> rtg: hey - so 4.8 is much worse for me
[16:29] <elmo> [25358.449193] CPU0: Core temperature above threshold, cpu clock throttled (total events = 42960)
[16:29] <elmo> rtg: and my laptop hard locked over night and when I found it in the morning, every possible fan was at full speed and it was very hot
[16:30] <rtg> elmo, thermald is installed I presume ? this could be something cking might wanna look at (when he's not totally buried)
[16:30] <elmo> rtg: it's installed, but broken
[16:30] <elmo> on 4.8 - it worked on Xenial
[16:30] <elmo> rtg: http://paste.ubuntu.com/23207813/
[16:31] <cking> elmo, can you file a bug, I'll try and get onto this ASAP
[16:31] <elmo> cking: will do
[16:31] <cking> elmo, can you boot with the previous 4.4 kernel just to double check it's the new 4.8 kernel
[16:31] <elmo> OK
[16:40] <elmo> cking: back on 4.4 - seems better; less thermald spew, but it's a bit early to tell
[16:41] <cking> elmo, OK, well lets keep it monitored. my laptop suddenly got hotter when I moved to 4.7 - but I tracked that down to the thermal paste giving up on me and not the kernel
[16:41] <elmo> cking: bug against thermald or the kernel?
[16:41] <cking> thermald please
[16:41] <elmo> cking: this is a weeks old laptop; I'll be grumpy with Lenovo if it's failed paste :)
[16:42] <cking> elmo, ok, that's less likely to be a paste issue then :-/
[17:01] <slangasek> apw: so if ioctl(fd, KDGKBMODE, &addr) takes an unsigned long * but only fills the bottom 32 bits of it, whose bug is that?
[17:04] <apw> slangasek, it would depend how the thing is documented
[17:04] <apw> it might be a kernel bug in compatibility mode of course
[17:05] <slangasek> and where in the world would I find the documentation? :)
[17:05] <apw> slangasek, or you might be passing the wrong size thing to it ?
[17:05] <apw> normally there is a manual page for the device the ioctl is on, ifyou are lucky
[17:05] <slangasek> apw: ok, so ioctl_list(2) claims it should be int *, not long *
[17:05] <slangasek> interesting
[17:06] <apw> so then it filling in 32 bits is fine, on a BE it would fill in the top half :)
[17:06] <slangasek> yeah, context is LP: #1621824
[17:06] <ubot5`> Error: Could not gather data from Launchpad for bug #1621824 (https://launchpad.net/bugs/1621824). The error has been logged
[17:07] <apw> slangasek, if the docs say 32 bits, then it is a caller bug i recon
[17:07] <slangasek> apw: is that manpage the "right" docs?
[17:08] <apw> phththt now that is a difficult question
[17:09] <apw>                 ret = put_user(uival, (int __user *)arg);
[17:09] <apw> it is cirtainly sending you and int
[17:09] <slangasek> apw: well, turns out that every other call to KDGKBMODE in kbd source uses an int, but cjwatson's patch uses a long, whoops :)
[17:10] <apw> slangasek, then yes, lets suggest an _unknown_ actor has gotten their size wrong :)
[17:10] <slangasek> heh
[20:17] <gpiccoli> Hi, sorry to bother. Just wanna know if there are some really easy way to build a kernel debian package from a kernel tree
[20:17] <gpiccoli> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel <= is this updated enough?
[20:17] <gpiccoli> Never done this before, sorry if this is a silly question