[12:48] <rtg> apw, pushed raring rebased on v3.7-rc4, build testing now
[13:06] <cking> rtg, I'll be happy to give it a test spin on various boxes
[13:08] <rtg> cking, I had a docs build failure that I'm still tracking down, but the kernel binary builds OK if you want to give it a go
[13:09] <cking> ack
[13:10] <cking> rtg, have you any .debs that I can download?
[13:11] <rtg> cking, working on it. the docs failure stops the build before the kernel binaries are packaged. should have them in 10 mins or so (on gomeisa)
[13:13] <ricotz> rtg, hi, i ran into having broken input (keyboard/mouse) earlier (raring master-next with rc4 merged)
[13:14] <rtg> ricotz, I've only _just_ [ushed -rc4. are you sure it wasn't an earlier version ?
[13:14] <rtg> *pushed
[13:15] <ricotz> rtg, i merged it myself yesterday
[13:16] <rtg> ricotz, well, if you have a kernel version that does work, then how about starting a bug report and working with jsalisbury to bisect the issue ?
[13:16] <ricotz> rtg, i am not sure if this is something real, i guess i will try to reproduce it with the new rebased branch
[13:17] <ricotz> also having nvidia-blob around might be doing this
[13:17] <ricotz> just wanted to mention it, but you probably not running it yet
[13:18] <rtg> nope, haven't tested it. I've asked Alberto to have a look
[13:19] <ricotz> patched nvidia works fine with the rc3
[13:46] <rtg> cking, I turned on signed modules. do you have an external module you could build and install to make sure the kernel complains ? Isn't there something in fwts ?
[13:47] <cking> rtg, I will give it a spin
[13:48] <rtg> cking, we decided to not make requiring signed modules the default, but there some Xen folks that would like to use it.
[14:52] <cking> rtg, the skarkbay laptop works so much batter with that 3-7rc4 kernel
[14:53] <rtg> cking, haswell ?
[14:53] <cking> rtg, yep
[14:53] <rtg> huh
[14:53] <rtg> I guess thats a good thing
[14:54] <cking> well, I get get a desktop now that works, and 3D games render OK w/o it dying
[15:39]  * ogasawara back in 20
[16:16] <bjf> rtg, got that -rc4 kernel somewhere handy
[16:16] <bjf> ?
[16:17] <rtg> bjf, gomeisa.buildd:~rtg/ukb/raring/amd64/master-next
[16:37] <apw> bjf, i need to drop an patch for the linux-lts-quantal package on the branch see any issues with that?
[16:37] <bjf> apw, you need to commit a patch to quantal master-next branch ?
[16:38] <apw> bjf, nope specially to the lts-quantal version in precise, to the branch specific machinary, to enabled signed kernels there
[16:39] <bjf> apw, ah! i see no problem there
[16:39] <bjf> apw, you are free to maneuver
[16:39] <apw> bjf, thrusters to one half indeed
[16:41] <bjf> rtg, how come only the -generic headers were built and not the -all?
[16:41] <rtg> bjf, likely because of the way I built. lemme check
[17:46] <apw> bjf, herton, does shankbot know about when -signed is needed yet.  if not we likely need to codify that too
[17:46] <bjf> apw, i believe it is already on heron's todo list
[17:46] <apw> purr'fec
[17:47] <apw> we probabally talked about it over beer, and that is what i am blaming for me not remembering
[17:47] <infinity> bjf, herton: While we're talking shankbot wishlists, it's getting unwieldly for people who aren't intimately familiar with the process to hunt down all related/dependant packages.  Maybe the description should list them all, so we don't miss any on promotions? (linux, lbm, meta, signed, etc)
[17:47] <infinity> bjf, herton: Granted, that can be worked out from the prepare-* tasks (well once there's a prepare-signed), so maybe it would be duplicate info, I dunno.
[17:48] <infinity> None of this is a huge deal while I'm the one doing the AA side of all of this, cause I know what's up, but I imagine it'll make someone's head explode if they have to cover for me on vacation.
[17:48] <bjf> infinity, i'm not sure what you'd like to see .. a wiki page explaining the relationships?
[17:48] <infinity> bjf: No, a list in the description of "these are the packages involved in this SRU".
[17:49] <bjf> infinity, ah, ok, that seems reasonable
[17:49] <infinity> bjf: Since the bug is (technically) only against linux (or linux-flavour), it's not immediately obvious that "promoting this also means promoting meta, lbm, signed...)
[17:50] <bjf> infinity, wouldn't they get "the idea" when we pocket copy those packages?
[17:51] <infinity> bjf: Well, I tend to do all the PPA copies too.  But, even if that weren't the case, you/me doing the PPA copy today, and someone else doing the promotion in two weeks, is a fair bit of disconnect.
[17:52]  * infinity shrugs.
[17:52] <infinity> It's not a huge deal, and I'd like to think I'll train someone a bit before they cover for me anyway.
[17:53] <infinity> And, to me, the relationships are obvious.
[17:53] <bjf> infinity, i'm not disagreeing, i'm just thinking about it
[17:53] <infinity> But I can see how the list on sru-report.html would be mind-bending to someone who's not used to reading it. ;)
[17:53] <infinity> Actually, maybe we could just make the report more clever.
[17:54] <bjf> i was thinking that as well
[17:54] <infinity> If it could group things in related units, so the base/meta/lbm/signed were always together.
[19:08]  * rtg -> lunch
[19:17] <herton> apw, yes shank bot should be covering the signed packages only for quantal and later now
[19:18] <herton> we will need to update this though on the backport for precise and may be precise when it's done there too
[19:22] <infinity> apw: When is the first kernel upload for raring going to happen, BTW?  Trying to decide if I should care about copying qunatal SRU kernels to raring, or just leave it be.
[19:23] <infinity> ogasawara: ^
[19:24] <ogasawara> infinity: I say just leave it be, we just rebased to v3.7-rc4 today so I suspect we'll attempt an upload of this soon baring anything catastrophic
[19:24] <infinity> ogasawara: Shiny, thanks.
[19:25] <infinity> ogasawara: If some dreadful security vuln shows up in the next SRU cycle and R still doesn't have its own kernel, I'll reevaluate. :P
[19:27] <bjf> rtg, rc4 working ok on my macbook air
[19:36] <bjf> rtg, also on SandyBridge HEDT
[20:03] <jdstrand> jjohansen: hey, so this linux-lowlatency, is that a supported kernel (ie, it gets USNs)?
[20:04] <jjohansen> jdstrand: no, its community supported
[20:04] <jdstrand> jjohansen: so, how does that work with the process?
[20:04] <jdstrand> ie, the cadence process
[20:05] <jjohansen> jdstrand: its just not part of the process, they rebase on our kernels
[20:05] <jdstrand> oh I see. it is entirely driven by them. cool
[20:06] <jdstrand> jjohansen: thanks
[20:15] <arges> jsalisbury, hi
[20:27] <jsalisbury> arges, hey
[20:27] <arges> jsalisbury,  were you able to re-open the upstream bug for bug 922906
[20:27] <ubot2`> Launchpad bug 922906 in linux (Ubuntu) "Kernel Oops - BUG: unable to handle kernel NULL pointer dereference at 0000009c; EIP is at __ticket_spin_lock+0x8/0x30" [High,Triaged] https://launchpad.net/bugs/922906
[20:28] <arges> jsalisbury, i was going to start investigating this a bit more
[20:28] <jsalisbury> arges, I wasn't able to, I didn't have the appropiate premissions
[20:29] <arges> jsalisbury, ok should i reopen after i take a look at it a bit?
[20:29] <jsalisbury> arges, I noticed Ben Hutchings requested that it get reopened as well, but never got a respnse
[20:29] <arges> i mean file a new bug not re-open
[20:29] <jsalisbury> arges, sure, that may get it moving again
[20:31] <jsalisbury> arges, there were a couple of discussions on LKML about it as well, but none ever went anywhere.
[20:32] <jsalisbury> arges, I think it was left off around March of 2011
[20:32] <jsalisbury> maybe april
[20:32] <arges> ok i'll get more data first
[20:34] <jsalisbury> arges, I think henrix and apw also looked at this for a while and there was even a test kernel.
[20:37] <jsalisbury> arges, Actually there was a fix upstream on fsdevel: http://marc.info/?t=130806561400010&r=1&w=2  I don't think it was ever picked up in mainline though.
[20:40] <arges> jsalisbury, yea i'll have to dig on this a bit more
[20:51]  * rtg bugs out
[21:11] <bjf> ogasawara, i just boot tested rc4 on two server systems, it's up on both however, the emerald ridge system has no video and lots of backtrace in the dmesg
[21:12] <ogasawara> bjf: ack
=== yofel_ is now known as yofel
[21:38] <akhileshss> Hi, I am trying to add a new system call to kernel 3.6.5. I followed the steps here: http://goo.gl/f0hk7 . But I hit the error "arch/x86/built-in.o: …: undefined reference to "sys_foo".  I am trying to put new sys call foo. Can anyone help me figure out what is missing ?
[22:01] <bjf> ogasawara, i tested rc4 on 7 systems, only the one had any issues
[22:02] <ogasawara> bjf: ok good to know.  are you able to pull the logs from that emerald ridge?
[22:02] <bjf> ogasawara, sure, it's up and running if anyone wants to also poke at it
[22:03] <ogasawara> bjf: I'll sync with rtg in the morning about debugging it
[22:04] <bjf> ogasawara, it's "statler" in the lab
[22:04] <ogasawara> bjf: ack