[09:38] <apw> lamont, if you always get asked on reconnect I found on upgrade to oneiric (i think) i managed to somehow end up with two entries for the same network name in the NM database, that meant it always used the wrong one until you typed in the right one which it correctly wrote over the right one, but continued to load the wrong one on boot.  removing both and lettting it make a fresh new one fixed it up 
[09:38] <apw> for me
[12:10] <maxime_> apw, any clue about my yesterday question, if dkms incorrectly ask for the full kernel source or if i should install the source ?
[15:40] <lamont> apw: thanks for the tip.  I shall check into that
[15:57] <apw> lamont, luck with it
[15:57] <tgardner> apw, what was the tip ?
[16:00] <arges> apw, tgardner : whats the easiest way to find if a particular patch has made it into lucid/natty/oneiric? should i check the git logs of my trees, or is there a web tool ? thanks
[16:01] <tgardner> arges, I typically look ni my local git repos for that release
[16:01] <arges> tgardner, so you check everything before the tag of the latest release? how do I tell what version in the mainline / proposed? 
[16:02] <tgardner> arges, grep on 'git log --prettyprint=oneline' ?
[16:02] <tgardner> git describe --contains SHA1 ?
[16:06] <arges> tgardner, jsalisbury just pointed me to the kernel versions webpage, thanks for the help!
[16:06] <jsalisbury> np
[16:11] <apw> tgardner, oh just that in the past i have found that i got two entries for the same network in nm, which made it always use the wrong password until you entered it.  deleting both then sorted it out
[16:12] <tgardner> apw, ah, editing the wireless connections. I kind of wish NM had a "flush" button.
[16:14] <arges> tgardner, was looking at : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/902317, when will this SRU be released? 
[16:14] <ubot2> Launchpad bug 902317 in linux "Lucid update to 2.6.32.50 stable release" [Undecided,Fix committed]
[16:14] <arges> for lucid
[16:15] <tgardner> arges, sometime in January guess
[16:15] <arges> tgardner, ok. 
[16:15] <apw> tgardner, yeah in there.  it seemed that it used the wrong one to find the password then wrote it to the right one when you entered it, so then it worked until you s/r or whatever, then it broke again
[16:16] <brendand> tgardner - sudo rm -rf /etc/NetworkManager/system-connections
[16:16] <apw> arges, yeah nothing much will move forward until after the 3rd over there unless there is huge whining and gnashing
[16:16] <tgardner> apw, my travel laptop seems to accumulate connection info. I see brendand has posted a handy flush mechanism.
[16:16] <brendand> whoopsie. don't do that :)
[16:17] <brendand> i meant /etc/NetworkManager/system-connections/*
[16:17] <brendand> i.e. everything in it. DON'T delete the directory itself :)
[16:17] <arges> apw, understood.
[16:22]  * jsalisbury thinks the passwords stored in the /etc/NetworkManager/system-connections/* files should be encrypted :-/
[16:23] <brendand> jsalisbury - you need to be root to view the files, soooo
[16:24] <jsalisbury> brendand, that's true
[16:24] <tgardner> brendand, think theft, loss, etc
[16:24] <jsalisbury> or giving the wrong person sudo privs
[16:25] <brendand> tgardner - sure, but all OS's have a way to view the stored keys
[16:25] <brendand> i know OSX does anyway
[16:26] <brendand> not saying that means it's a good idea :)
[16:26]  * jsalisbury just hates and/or loves seeing passwords stored in plain text :-D
[16:26] <brendand> jsalisbury - to be fair i thought precisely the same thing :)
[16:26] <tgardner> yeah, seems like it ought to be stored in the key-rimg
[16:26] <tgardner> key-ring*
[16:26] <brendand> tgardner - i could swear it used to be. cyphermox?
[16:27] <tgardner> yeah, it used to ask me for my key-ring password all the time
[16:28] <brendand> tgardner - in most cases, if they have your root password they're going to be able to unlock the key-ring though, right?
[16:29] <brendand> i assume we're talking about the case of somebody stealing your laptop with the root password somehow obtained and then using your wifi
[16:29] <tgardner> not if that stuff is stored encrypted
[16:29] <tgardner> brendand, how about if the just boot with a live CD, then mount the drive and look at the cleartext password.
[16:30] <jsalisbury> or the laptop owners works wifi ;-)
[16:30] <jsalisbury> s/works/place of employment/
[16:30] <brendand> tgardner - can you view files owned by root with a live CD?
[16:31] <tgardner> brendand, of course.
[16:32]  * brendand is curious now
[16:32] <tgardner> brendand, try 'sudo su -' from a Live CD terminal
[16:36] <brendand> jsalisbury - i wanted to ask if there's anything i can do to help with the Suspend bug in the Oneiric SRU. Any ideas yet what hardware it's limited to?
[16:36] <jsalisbury> brendand, if you can reproduce the bug, it would be great if you can test some kernels I build in the bisect process
[16:37] <brendand> jsalisbury - yeah, that would be the trick. we haven't reproduced it on any certified systems.
[16:38] <brendand> jsalisbury - i'll have a look at the bug and see if i can get any leads
[16:38] <jsalisbury> brendand, ok, if you get to the point where you can reproduce the bug it would be great to have you test some kernels.
[16:49] <jsalisbury> brendand, The bug reporter confirmed the issue happens between mainline v3.0.12 and v3.0.13, so I'm building a test kernel halfway between the two that will be tested next.
[16:50] <brendand> jsalisbury - where does that map in ubuntu kernels?
[16:50] <jsalisbury> brendand, well it tells us the bug was introduced in a mainline commit and not an Ubuntu specific patch.
[16:52] <brendand> jsalisbury - ok. i guess that's good info. i'm just wondering does that mean it only is in the -proposed kernel or could it have been in 3.0.0-14 too?
[16:52] <jsalisbury> brendand, It appears to only be in the -proposed kernel and not in -14
[16:53] <brendand> jsalisbury - very good
[16:54] <jsalisbury> brendand, indeed.  It makes me wonder though if this bug reporter realizes he has -proposed enabled :-)  I'm going to ask.
[16:57] <jsalisbury> brendand, So to more clearly answer your question on how this maps into Ubuntu kernels, the bug existes in: 3.0.0-15.24 but not in: 3.0.0-14.23
[16:58] <brendand> jsalisbury - thanks
[17:02] <cyphermox> brendand: it was, now is in /etc/NetworkManager/system-connections on purpose; since connections are usually system-wide. if you make it per-user it will still end up in the keyring
[18:15] <Kano> hi, found one commit that breaks suspend on some systems (incl. one of mine)
[18:15] <Kano> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904569
[18:16] <ubot2> Launchpad bug 904569 in linux "Linux 3.0.0-15-generic-pae causes laptops to fail to resume from suspend (Dell XPS 1645, Sony Vaio VPCF1390)" [Medium,Confirmed]
[18:17] <tgardner> jsalisbury, ^^
[18:18] <jsalisbury> tgardner, Kano, Thanks!
[18:18] <jsalisbury> Kano, I'm running a bisect now, can you provide the SAH1?
[18:18] <tgardner> jsalisbury, its in the bug
[18:19] <jsalisbury> tgardner, awesome.  Thanks, Kano!
[18:19] <tgardner> jsalisbury, be95a75a786d05896e8f12ad374fc5ab88232682
[18:19] <apw> heh ... just replied to jsalisbury's email not realising the info in the bug was 1m old ...
[18:19] <apw> thanks Kano for the bisect
[18:19] <apw> jsalisbury, i say revert that and put some test kernels out and lets confirm it fixes the remainder of the reporters
[18:20] <Kano> apw: best update to 3.0.14 as it is out
[18:20] <apw> jsalisbury, as that will give us something to let them chew on over xmas
[18:20] <jsalisbury> apw, sounds good
[18:20] <tgardner> jsalisbury, you should also notify stable and tglx when you get results
[18:20] <apw> Kano, so 3.0.14 is also ok ?
[18:21] <jsalisbury> tgardner, will do.  Who is tglx?
[18:21] <tgardner> jsalisbury, Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[18:21] <Kano> apw: after you revert that 
[18:21] <apw> thomas gliexner (spelling?)
[18:21] <jsalisbury> tgardner, doh, :-)
[18:21] <apw> ok ... so for this bit we'll just want the quick revert as its mid test and out
[18:21] <Kano> apw: i mean i see no reason to test with 3.0.13
[18:22] <apw> its the way the process works, if we add .14 and there is another regression we can get stuck in a loop unable to release
[18:22] <Kano> whatever you want
[18:22] <apw> .14 will be in the first jan one i am sure
[18:22] <apw> as tim will get bored and apply it to master-next by now i am sure
[18:23] <Kano> well as the problem is upstream as well i think .15 ;)
[18:24] <jsalisbury> Kano, apw, the bug reporter tested upstream .12 and .13 and reports the bug exists in .13
[18:24] <Kano> jsalisbury: i know, it is in every newer kernel, also 3.1/3.2
[18:24] <tgardner> jsalisbury, how about 3.2-rc6 ?
[18:25] <Kano> well 3.2rc6 did not boot on the problematic system. it only likes to boot on 1 out of 3 of my boxes
[18:25] <apw> yeah, jsalisbury my reading of the bug is that all kernels are affected yet the title mentions generic-pae, have i missed sometihng in the bug or is the title skewed
[18:25] <jsalisbury> tgardner, I don't know about 3.2-rc6.  I'll ask the bug reporter to test it.
[18:25] <Kano> i just tested the revert of the bug with 3.0.14
[18:26] <jsalisbury> apw, all the kernels are affected, not just generic-pae
[18:26] <apw> jsalisbury, ok perhaps change the title next time you have it open else we get more dogpiling
[18:26] <jsalisbury> apw, will do
[18:26] <apw> ta
[18:51]  * tgardner -> lunch
[21:09] <jsalisbury> tgardner, I'm still building the reverted kernel for bug 904569 I should be done shortly.  I rebuilt it a couple of time to make the build process muscle memory :-)
[21:09] <ubot2> Launchpad bug 904569 in linux "Linux 3.0.0-15 causes laptops to fail to resume from suspend (Dell XPS 1645, Sony Vaio VPCF1390)" [Medium,Confirmed] https://launchpad.net/bugs/904569
[23:00] <Kano> hi, did anybody notice that suspend usually kills usb 3 ports (xhci-hcd)?
[23:01] <Kano> upgraded a few systems with usb 3 cards (nec+via) now
[23:54] <thegreyspot> Is there a PAE release of kernel 2.6 On. that I could use? Or was that never release?