[00:19] <elementofone> !ops
[00:20] <elementofone> !ops
[00:31] <elementofone> !ops
[00:35] <elementofone> !OPS
[00:38] <JanC> elementofone: stop that please
[00:39] <elementofone> !ops janc
[00:39] <elementofone> !ops | JanC 
[00:40] <elementofone> !ops | JanC \
[00:55] <elementofone> !ops | JanC \
[08:34] <apw> dsmythies, thanks for the update
[11:45] <NikTh> How can one identify the kernel version from Linus git tree in comparison with the kernel.ubuntu.com/~kernel-ppa/mainline ? This does not help in my case (http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html_
[11:47] <NikTh> I can understand that 3.17-rc4 it's the same version as v3.17-rc4 (in Linus git), and 3.17-utopic = v3.17(in Linus git), but what about 3.17.1-utopic ? which version is this under Linus git ? 
[11:48] <smb> NikTh, That is the first stable release from upstream stable compiled with mostly the config from utopic
[11:49] <smb> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
[11:49] <apw> NikTh, as smb says, this is a stable update kerenl, it is therefore _not_ in linus' tree, it is in the stable tree
[11:50] <smb> there ^
[11:50] <apw> NikTh, separatly each of those builds includes a COMMIT file which contains the tag/commit id which was used to build it
[11:54] <NikTh> So, if one wants to bisect an rc kernel upstream, should clone the Linus git, but if wants to bisect lets say 3.17-utopic and 3.17.1-utopic should clone the stable git ?
[11:54] <apw> yes the two tags you need are in there
[11:55] <NikTh> and if the last bad kernel is rc-7 and the next good one is a stable, lets say 3.17-rc7 = the last bad one and 3.17-utopic = the first good one. 
[11:56] <apw> well those are both linus' releases, so they are in either
[11:56] <apw> those versions literally represent v<nnnn> tags
[11:56] <NikTh> Yes. Correct apw. Thanks
[11:57] <apw> correct ?
[11:57] <NikTh> The difference would be if the last bad one was , lets say 3.17-utopic and the first good one was 3.17.1-utopic, then one should clone the stable git. Correct ? 
[11:58] <apw> well yes, but you would never find that situation, as if you had v3.17-rc7 as bad and v3.17.1 as good, the next test would be v3.17
[11:58] <apw> moving you into one or the other
[12:06] <NikTh> Lets say that the last bad kernel is 3.17-utopic and the exact following is the first good one (3.17.1-utopic). How one can reverse bisect ? From stable git ? Or this situation would never happen ?
[12:07] <apw> stable yes, those tags are both in there
[12:11] <NikTh> apw: Thanks for all the answers and explanations, this is the yet another time helping me :-) 
[12:12] <NikTh> smb: same too you 
[12:12] <NikTh> if you put a candidate for president and you need my vote, just let me know :P 
[12:14] <apw> heh ..
[12:16] <NikTh> Oh, and a last one.. because I don't want to building kernels in vain... I have spotted the bad and good kernels. And I want to start bisecting. I want to build the bad kernel with the first commit from the good one.. will I do "git checkout COMMIT" and then start building ? 
[12:22] <apw> NikTh, doesn't "git bisect" offer you a sensible commit to bisect?
[12:23] <NikTh> apw: Yes. It offers me a commit, but I want to build and test the kernel with this commit and particular I'm speaking about a reverse bisection. 
[12:24] <apw> it will have check that commit out when it selected it, iirc
[12:24] <NikTh> I've read the wiki, but I'm afraid if I don't understand something.. so I'm asking to be sure.
[12:28] <NikTh> apw: For starters, I did a "git checkout COMMIT" where commit is the offered commit from the bisection and I'm building the bad kernel with this commit. Is that right ? 
[12:29] <apw> my memory is the bisect itself checked out the suggested commit for you
[12:31] <NikTh> Ok, but is there something wrong with the procedure I followed? I mean, the "git checkout COMMIT" breaks something maybe ? or building an incorrect kernel ?
[12:31] <apw> if you were on that commit, the git checkout would be a noop
[12:34] <NikTh> noop? sorry, what is noop ? you mean something unnecessary ? 
[12:58] <apw> a no-operation indeed
[13:04] <rtg> cking_, would you mind answering this one when you've a moment ? https://bugs.launchpad.net/bugs/1387144
[13:04] <cking_> yup
[13:11] <apw> cking_, it is possible that could be a recommended, so it would be uninstallable, but also remain installed by default, something to consider
[13:12] <cking_> I think that would be better, so users can chose to remove it
[13:13] <rtg> cking_, thermald does bail out on platforms for which it can do no good, right ? like virt instances, etc.
[13:14] <cking_> rtg, it does indeed
[13:14] <cking_> I should add that too to the bug report
[13:16] <cking_> making it a recommended is the best plan, this way users can remove it if thermald is too agressive for there liking and they like seeing their H/W shutdown when it gets too hot
[13:30] <NikTh> As an addition thermald sometimes needs a special configuration in order to identify the components correctly.  https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1367946
[13:34] <cking_> rtg, apw, are you ok to make that change, or do you want me to? (I'm not upto speed with the packaging foo that's needed to do that)
[13:35] <rtg> cking_, you could certainly write the patch and send it on the list.
[13:47] <cking_> rtg, i'm not sure how the original change was made in utopic
[13:47] <rtg> cking_, debian.master/control.stub.in I think
[13:48] <cking_> yep, I grep'd for thermald in that in utopic, I can't see it
[13:48] <rtg> hmm, lemme check
[13:49] <rtg> cking_, its in the Utopic meta package
[13:50] <cking_> hrm, never futzed with that before
[13:58] <apw> yeah that is actually on linux-image-generic meta package ...
[13:58] <apw> cking_, that is more of a "normal" package so you have to edit changelog by hand, no insertchanges help
[14:03] <cking_> apw, hold on, I'm sucked into some phablety issue at the mo
[14:03] <apw> cking_, np
[14:39] <dgadomski> hello everyone
[14:40] <dgadomski> stgraber: do you still have your hardware for bug #1104230?
[14:48] <dgadomski> stgraber: I have provided some kernel builds there for testing, unfortunately I have no hardware to test it by myself so I would appreciate any feedback, thanks!
[15:01] <rtg> apw, i fired up a vivid kernel to the kernel PPA. meta package to follow soon. If testing on various bits of kits seems OK then I'll dump it into the archive (after consulting infinity)
[15:18] <apw> rtg, yeah we need some dkms testing i ugess, which is ... not working right now
[15:19] <rtg> apw, what better way to acquire some launchpad bugs :)
[15:19] <apw> true we don't have very many right now
[19:03] <rtg> tseliot, we've got a 3.18 based kernel for you to test your DKMS packages against in the kernel PPA
[21:22] <JayJ> On ubuntu 14.04 host runing 3.13.0-24-generic kernel, Guests are freezing and I see "BUG: soft lockup - CPU#x stuck for 22s!" Anybody help me narrowing the issue? HW is Supermicro with Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz. I need anybody help. 
[21:47] <neoark> JayJ bad hardware?
[21:50] <JayJ> neoark: What I don't understand is that the host is running the same version of ubuntu and kernel. There are no issues with the host. However, teh guest running has all the issues.
[21:51] <NikTh> And why this could ever happen ? Am I noob regarding the reverse commit bisect procedure ? Yes I am, but I've followed the procedure step by step.  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386695/comments/23