[13:00]  * henrix -> lunch
[13:58] <ppisati> brb
[14:09] <arges> rtg, hi. I noticed that those 9 fsnotify patches landed in raring, when does the state of bug 922906 change to reflect Fix Commited/Released ?
[14:09] <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,In progress] https://launchpad.net/bugs/922906
[14:13] <rtg> arges, thy'll go to fix released when the kernel is promoted out of -proposed. apw tells me we are frozen for kubuntu/edubuntu betas right now.
[14:13] <rtg> should get relaxed today I think
[14:13] <arges> rtg, ok cool. should I wait for that to get those SRUed for precise/quantal?
[14:14] <rtg> arges, it wouldn't hurt to get a little testing, but you might as well start the SRU process.
[14:14] <arges> ok thanks
[14:53]  * ppisati back in 20
[15:02] <rtg> ogasawara, so what is the advantage of dropping beta milestones if kubuntu/edubuntu can put a freeze on the archive? I uploaded on _Monday_ . That kernel is still stalled in -proposed. wtf ?
[15:02] <ogasawara> rtg: in theory, we are not supposed to be bottlenecked by the flavors choosing to freeze for the optional alpha/beta milestones
[15:03] <rtg> sounds more like a hypothesis then a theory.
[15:03] <rtg> and a weak one at that
[15:27] <rtg> bjf, seen this ? http://ltsi.linuxfoundation.org/what-is-ltsi
[15:40]  * ogasawara back in 20
[15:54] <infinity> rtg: It didn't actually prevent you from doing anything, did it?  The kernel built, and was just in proposed, s'all.
[15:55] <rtg> infinity, but it wasn't getting any test time
[15:55] <infinity> (Except in the rare case when your new kernel is fixing something that's specifically an ISO-image-only problem, I'm not sure I see the issue)
[15:56] <rtg> infinity, nobody has -proposed enabled for the devel release
[15:56] <infinity> Granted, I'd also prefer to see flavours not do alphas, but we'll revisit this again (and again) as time goes on.
[15:56] <infinity> rtg: Sure, it gets less exposure while it's in proposed, not arguing that it doesn't.
[15:56] <infinity> Anyhow, it'll move right shortly, the matching d-i is just publishing now.
[15:58] <rtg> infinity, I saw that in the release channel
[15:58] <rtg> thanks
[16:21] <bjf> rtg, at uds wasn't it decided that there would be monthly milestones which flavours could opt in/out of?
[16:22] <rtg> bjf, right. but opting in has the knockon effect of holding up the show for the other flavours.
[16:22] <bjf> rtg, right, so aren't we going to have this issue every month?
[16:22] <rtg> bjf, well, every alpha/beta milestone for sure
[16:23] <bjf> rtg, i had seen the LTSI thing. it's something gregkh was initiating 
[17:12] <rtg> cking, just wrote a patch for this: 'drivers/gpu/drm/i915/intel_display.c:7019 intel_set_mode() warn: function puts 500 bytes on stack'. Do you agree 500 bytes is a bit much ?
[17:14] <cking> rtg, it depends if we're in a leaf and so we won't push anything else onto the stack, and how short term the space is going to be used  I suppose
[17:20] <cking> rtg, it is a hard one to call really, perhaps it's worth punting this patch as the data structures may grow over time rather than shrink, so it's not going to get better over time
[17:21] <rtg> cking, yep, I'm gonna punt it upstream. they worst they can say is no. 
[17:21] <cking> indeed
[17:29] <cking> bah, oom'd my machine 
[17:59]  * ppisati -> EOD
[18:31] <rtg> sforshee, cking: please give me a quick review on 'UBUNTU: SAUCE: iwlwifi: iwlagn_request_scan: Fix check for priv->scan_request' which is tip of Raring master-next
[18:32]  * rtg -> lunch
[18:35] <cking> rtg, looks good to me
[19:07] <rtg> cking, thanks
[19:21] <sforshee> rtg, looking at the rest of the driver I get the idea that it might be attempting to support scan_request == NULL if scan_type != IWL_SCAN_NORMAL
[19:21] <sforshee> the checking in that function is definitely broken though
[19:27] <rtg> sforshee, it looked to me like that function would oops if scan_request were NULL
[19:29] <sforshee> rtg, afaict only cases where scan_type == IWL_SCAN_NORMAL dereference the pointer, but I'm not 100% certain
[19:29] <sforshee> but it also looks like scan_request is only set when a scan is invoked by mac80211
[19:30] <sforshee> sometimes the driver starts scans internally, and I don't see those setting scan_request
[19:30] <sforshee> I haven't had time to grok the whole thing yet though
[19:32] <rtg> sforshee, ok, I'll look a little closer
[19:35] <sforshee> rtg, I suspect maybe the condition should be (priv->scan_type == IWL_SCAN_NORMAL && (!priv->scan_request || priv->scan_request->n_channels > MAX_SCAN_CHANNEL))
[19:36] <sforshee> rtg, probably worth running by Johannes & co. in any case
[19:40] <rtg> sforshee, I think you're right about priv->scan_type == IWL_SCAN_NORMAL
[20:06] <rtg> sforshee, repushed master-next if you'd have a look again. 
[20:06] <EntropyWorks> so what is the process of adding network drivers to the nic-modules.udeb for the netboot install initrd.gz 
[20:07] <rtg> EntropyWorks, start a bug report, then email the kteam list
[20:07] <rtg> EntropyWorks, is it for a released kernel ?
[20:08] <EntropyWorks> its for quantal 12.10. I originally have this bug which was precise https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1015339
[20:08] <ubot2> Launchpad bug 1015339 in debian-installer (Ubuntu) "Missing kernel modules for Mellanox ConnectX HCA Ethernet " [Medium,Confirmed]
[20:09] <rtg> EntropyWorks, so it requires SRU justification which means you have to have a bug report....
[20:10] <EntropyWorks> in quantal besides not having the network driver it also wasn't able to find the local disk without me adding more kernel modules to the initrd.gz http://goo.gl/PfOZd. 
[20:10] <EntropyWorks> point me to the URL and I will write one up :)
[20:11] <rtg> EntropyWorks, start a bug by entering 'ubuntu-bug linux' from a command line
[20:11] <EntropyWorks> gotcha
[20:11] <rtg> EntropyWorks, preferably from the machine that requires these drivers.
[20:11] <sforshee> rtg, that looks right to me
[20:12] <rtg> sforshee, ack
[20:12] <rtg> thanks
[20:38]  * rtg -> EOD
[21:31] <hallyn> stgraber: apw: I haven't had time to look deeper (hoping to tonight) but last night i was having a funky problem where a lot of stat+chown+chmod(stat.st_mode) ended up not retaining setuid/setgid on files in raring.
[21:31] <hallyn> it was *probably* my fault, something stupid in userspace, but i'm nto convinced
[23:11] <apw> hallyn, chown would drop setid bits ... but
[23:15] <arges> apw, hey.  still around
[23:16] <hallyn> apw: right, and so i stat it before hand and, if i've chowned, then i chmod back to the original st_mode
[23:17] <hallyn> works one file at a time, and used to work in a loop over a whole rootfs
[23:17] <hallyn> only started failing yesterday <shrug>
[23:17] <arges> apw, i have a 3 line cherry-pick that doesn't apply cause the file was moved, if I just apply it to the correct file it works. Is this still considered a cherry-pick or is it a 'backport'  (just trying to figure out how to format the commit)
[23:18] <arges> apw, n/m i see (backported from commit XXXXX)
[23:19] <bjf> arges, yeh, it's black or white. if it doesn't cherry-pick it's a backport
[23:20] <arges> bjf, ok that makes sense.  so I should keep the original author?
[23:20] <bjf> yup
[23:20] <bjf> actually ...
[23:21] <bjf> arges, in ones that i've done, i think i generally try to keep the original author
[23:21] <bjf> arges, however, now that you ask that question, i'm not sure
[23:22] <arges> bjf, ok well for now i'll build and test, tomorow i can clear it up before posting
[23:22] <bjf> arges, i'm looking in the tree for an example
[23:22] <apw> bjf, i tend to keep the original author, and sign it off and put the [apw@xxx: did this to it] stuff in
[23:22] <bjf> apw, that's what i normally do as well
[23:22] <bjf> arges, ^
[23:23] <arges> apw, bjf ok thanks