[09:14]  * apw yawns
[09:15]  * apw yawns
[09:15]  * ppisati hands apw some coffee
[09:15]  * apw bites your hand off :)
[09:52] <ppisati> brb
[10:31] <ppisati> every time i send a patch upstream i tend to create new and creative ways to bork it...
[11:16] <cking> ppisati, practice makes perfect I suppose
[11:17] <ppisati> cking: right :)
[11:29] <zequence> apw: both kernels ready at ppa:ubuntustudio-kernel/linux-lowlatency-sru
[11:29] <apw> zequence, ta
[11:32] <zequence> apw: Should I do the metas too?
[11:32] <apw> you should, do you know what to do there?
[11:33] <apw> it is a matter of making a new section with the right numbers
[11:33] <apw> in debian/changelog ... typically for lowlatency i have _not_ had a git repo for the metas
[11:33] <apw> as it is not worth it, i just get the one from the archive with pull-lp-source, edit it, and dpk-buildpackage -S
[11:34] <zequence> I was suspecting as much. Alright, I'll prepare them in a moment
[11:53] <apw> zequence, if you want to make a debdiff and pastebin it, i can verify
[11:53] <apw> though they are very simple :)
[11:53] <zequence> apw: sure
[11:55] <zequence> apw: http://paste.ubuntu.com/5646132/
[11:55] <apw> why do you have a nochange on ther ?
[11:56] <apw> and your diff is backwards ?
[11:56] <apw> zequence, ^^
[11:56] <zequence> apw: I set the release to raring the first time I uploaded
[11:57] <zequence> So, I rebuilt
[11:57] <apw> ahh ... doh
[11:57] <apw> zequence, you'll need to be careful about that one ... you can wreck your PPA and have to dlete it to recover
[11:58] <apw> if you get the series wrong in the wrong way, a later one is probabally ok
[11:58] <apw> and previous one, and all bets are off
[11:59] <apw> zequence, so on your nochange you really should have used -v like for the main kernel
[11:59] <apw> you should use -v always really
[12:01] <zequence> apw: Ok. This is quantal http://paste.ubuntu.com/5646142/
[12:03] <zequence> apw: So, I'll do another nochange build, with -v<previous-published-release>?
[12:08] <apw> zequence, i guess so yes ... it is all a learning experience
[12:08] <apw> zequence, the other one looks great
[12:08] <zequence> apw: O/win50
[12:09] <zequence> sorry :P
[12:09] <apw> heh i do that all the time tooo
[12:18] <zequence> apw: all uploaded. let me know if I should do anything else
[12:59] <rtg_> cking, jsalisbury: rebooting gomeisa for kernel update
[13:09] <rtg_> AceLan_, jjohansen: rebooting tangerine for kernel update
[13:10] <jjohansen> rtg_: ack
[14:23] <ppisati> apw: when yuo have time, can you point me to the script you use for the config review? thanks
[14:38]  * ogasawara back in 20
[14:43]  * henrix -> *really* late lunch
[15:50] <apw> ppisati, kteam-tools.git ... devel ... devel-config-sumarry --html ubuntu-raring outprefix>
[15:50] <apw> ppisati, kteam-tools.git ... devel ... devel-config-sumarry --html <ubuntu-repo> <outprefix>
[15:54] <bjf> apw, heads-up, quantal and precise kernel respins are coming
[15:55] <apw> bjf, again ... sigh
[16:12] <rtg_> apw, can you have a look at raring unstable-3.9 to determine why aufs-update mis-applies aufs3-standalone.patch ? it appears to _not_ get the patch to '+EXPORT_SYMBOL(iterate_mounts);' correctly, causing build failure.
[16:16] <apw> rtg_, will do
[16:16] <rtg_> apw, thanks, back in a few
[16:25] <ppisati> apw: thanks
[16:31] <apw> rtg_, ok ... just rememberd the base and standalone patches arn't updated with the current script, i've just done them by hand and all builds ok
[16:33] <tseliot> apw, cking: do you have any ideas as to what could be causing rfkill to report my wireless card as "Hard blocked"? (the card is enabled in the BIOS)
[16:36] <apw> rtg_, as this builds i'll push it anyhow
[16:36] <rtg_> apw, ack
[16:36] <rtg_> apw, what did you have to so beyond running the aufs-update script ?
[16:36] <rtg_> to do*
[16:37] <apw> rtg_, i just manually reverted and reapplied t
[16:37] <apw> the two anciallary patches
[16:37] <apw> they so rarely change once -rc2 is past the script doesn't track them
[16:37] <apw> maybe it should
[16:38] <apw> in the past they used to have to be wiggled cause they collided with overlayfs, but that seems to not happen now
[16:38] <apw> which can only be luck
[16:39] <rtg_> apw, I'm trying to get sbuild to run with the 3.9 kernel. it insists on having overlayfs and aufs.
[16:39] <apw> it should only need one or the other i would have thoruhg
[16:39] <apw> it seems odd to need both
[16:39] <rtg_> kind of what I thot
[16:42] <cking> tseliot, which card, driver and kernel are you using?
[16:43] <cking> hard to guess w/o being specific..
[16:45] <tseliot> cking: I'm using Broadcom's proprietary driver and here's the rest of the data: http://pastebin.ubuntu.com/5646858/
[16:50] <cking> tseliot, hrm, is there some physical switch to toggle?
[16:54] <tseliot> cking: no, I don't see any
[16:54] <cking> what machine is it?
[16:54] <apw> tseliot, have you tried toggling it with rfkill, i assume that fails
[16:55] <tseliot> apw: yes, nothing changes
[16:56] <tseliot> cking: it's a Lenovo B475e
[16:58] <cking> tseliot, just curious, but does Fn+F5 do anything?
[17:00] <tseliot> cking: it switches "Soft blocked" in rfkill but that's it
[17:00] <tseliot> it's always Hard blocked
[17:00]  * cking running out of ideas
[17:02] <rtg_> apw, hmm, sbuild seems to be happy now since your aufs update.
[17:07] <apw> rtg_, odd
[17:08] <rtg_> apw, well, I'm good with it.
[17:08] <apw> heh
[17:10] <tseliot> cking, apw: it seems to be a driver regression...
[17:10] <apw> tseliot, as in the binary drivers have regressed
[17:10] <cking> oh joy
[17:11] <tseliot> :)
[17:14] <ogra_> tseliot, did that laptop run windows recently ? 
[17:15] <tseliot> ogra_: I have no idea. They shipped it to me last week
[17:15]  * ogra_ remembers a bunch of bcm cards that get into a completely locked state by the windows driver, you can only get them unlocked by using the windows driver again
[17:16] <cking> bet you can faff with the nvram settings to coerce it back
[17:16] <tseliot> loading the previous driver seems to unlock it
[17:16] <ogra_> ah
[17:17]  * ppisati -> workout
[17:17] <ppisati> later
[17:20]  * rtg_ -> lunch
[18:22] <rtg_> bjf, 'causes the hand of cartridge' seems ungrammatical in bug #1159863
[18:22] <ubot2> Launchpad bug 1159863 in linux (Ubuntu Quantal) "udevadm info --attribute-walk command hangs on Marvel 9125 controller" [Undecided,In progress] https://launchpad.net/bugs/1159863
[18:25] <bjf> rtg_, fixed
[18:25] <rtg_> tanks
[19:14] <jdstrand> jjohansen: hey, sorry to bother you-- I was looking at CVE-2013-1858 and it seems that only kernels that have CLONE_NEWUSER are affected, no? the CVE in the tracker is missing the 'break' bit of 'break-fix' which is why, for example, hardy is marked as affected
[19:14] <jdstrand> jjohansen: iiuc
[19:16] <jdstrand> jjohansen: hmm, maybe not, I see that on precise we have CONFIG_USER_NS=y
[19:17] <jdstrand> jjohansen: that said, https://bugzilla.redhat.com/show_bug.cgi?id=917708#c5 seems to suggest that 5eaf563e53294d6696e651466697eb9d491f3946 is the candidate for 'break'
[19:17] <ubot2> bugzilla.redhat.com bug 917708 in kernel "Re-enable CONFIG_USER_NS" [Unspecified,New]
[19:18] <jjohansen> jdstrand: hrmmm, I'll have to look at it closer but yeah my guess is me need to fill in a commit where this starts causing problems, hardy certainly should not be affected
[19:18] <jdstrand> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5eaf563e53294d6696e651466697eb9d491f3946
[19:18] <jdstrand> jjohansen: I'm happy to update the CVE to use 5eaf563e53294d6696e651466697eb9d491f3946
[19:19] <jjohansen> jdstrand: be my guest :)
[19:19] <jdstrand> jjohansen: ok, once I do, can you do/coordinate the magic to update the CVE?
[19:20] <jdstrand> jjohansen: it is a 'high', which is why I am in your hair (again, sorry about that)
[19:20] <jjohansen> jdstrand: well there shouldn't be much to coordinate, if all goes well it should work automagically
[19:22] <jdstrand> jjohansen: ok, cool
[19:46]  * ogasawara lunch
[20:01]  * rtg_ -> EOD