[16:36] <hallyn> has anyone already complained about latest natty kernel upgrade with respect to broadcom wireless and nvidia?
[16:42] <smb> hallyn, Sort of Henrik was running into it (at least broadcom) when he was around Andy
[16:43] <smb> hallyn, So nvidia has the same wrapper problem?
[16:44] <hallyn> smb: don't know if it's the same.  on first login it told me i couldn't run unity, but then i coudl run it by hand, and on another attempt to instal lkernel, I got:
[16:44] <hallyn> run-parts: executing /etc/kernel/postinst.d/nvidia-common 2.6.37-12-generic /boot/vmlinuz-2.6.37-12-generic
[16:45] <hallyn> /etc/kernel/postinst.d/nvidia-common: line 8: [: too many arguments
[16:45] <hallyn> sound like nvidia-detector is bogus i guess
[16:45] <smb> yeah that at least for a starter sounds like something not correctly catched in the script
[16:46] <hallyn> oh, haha - i have intel graphics.  weird
[16:46] <elm_> how to do a make install for all kernel modules?
[16:47] <smb> hallyn, So at least that would not be your problem with unity then. )
[16:47] <smb> :)
[16:47] <hallyn> smb: at any rate, i'm having to tether right now...  should i file a bug, or is Henrik on top of it?
[16:47] <smb> For the broadcom problem afaik he had a patch ready and just needed to bring it on
[16:47] <hallyn> well lemme reboot one more time :)
[16:47] <hallyn> oh, cool
[16:48] <hallyn> thanks
[16:52] <elm_> make install does not install my radeon kernel modulewhat can I do?
[18:55] <towolf> hello. here's something i don’t understand concerning wireless regulatory domains. my regdomain is as such: http://paste.ubuntu.com/552544 but i’m still getting this least common denominator world domain: http://paste.ubuntu.com/552526
[18:56] <towolf> is this an ubuntu specific thing? on my openwrt i get the officially approved channel configuration.
[18:57] <teamnoir> I'm getting: "fatal: The remote end hung up unexpectedly" when I try to git a copy of the kernel.  Is the git server messed up?  Or am I doing something wrong?
[18:58] <ohsix> towolf: what wifi hw?
[18:58] <towolf> iwlagn 5000 series
[18:58] <towolf> on natty
[18:59] <ohsix> ah hm, dunno; does it have an eeprom that sets the region? cuz those can get in the way
[18:59] <towolf> could it be that the crypto verification of the regdb doesn’t work at all? this is just a hunch though.
[19:00] <towolf> ohsix, shouldn’t be. and if at all it should be overridden.
[19:00] <ohsix> if you can see it in iw get it's already been applied i think, you can check in dmesg for crda's/the kernels message that it loaded the regulatory info
[19:00] <towolf> yes, it did apply it, but that isnßt reflected in the channel list.
[19:01] <ohsix> read the regulatory compliance stuff on the kernel.org wireless section; generally the regdb complements the eeprom and the compliance
[19:01] <towolf> ohsix, on my openwrt the eeprom says US, but then openwrt overrides that and sets DE.
[19:02] <ohsix> they have hacked up stuff :] and i dunno if they even use crda
[19:03] <towolf> yes, they do. and there i can even use /sbin/crda, on natty it fails with -22, which i’ve read is due to failed signature verification.
[19:05] <ohsix> hrmph, that sucks
[19:07] <ohsix> i wish they'd use openssl instead of gcrypt in the ubuntu package, so you can just drop in your own signing certificate instead of having to rebuild it
[19:08] <towolf> ohsix, how would i do that? and by the way, the regulatory.bin has identical SHA1 on kernel.org, on natty, and in openwrt. somethign else is going awry
[19:13] <towolf> essentially "iw reg set" has no effect, but it doesn’t fail, and that puzzles me.
[19:13] <ohsix> try iw reg set US and look in dmesg; it should show it changing the regdomain
[19:19] <towolf> yes. it shows it. but then "iw phy0 list": no change at all. still world regdomain.
[19:19] <ohsix> that might be an eeprom thing, crda doesn't change what the card does; it just applies channel policies on top of it
[19:19] <towolf> can i query eeprom to see what’s in there?
[19:19] <ohsix> i don't have an iwlwifi device in front of me, but there's usually a tool to poke at the eeprom parameters
[19:19] <towolf> ooh. you might be right and this is iwlwifi specific. just cross-checked with b43 driver.
[19:19] <towolf> and that works.
[20:25] <\sh> guys, is there an easy way (which could be done e.g. via break=premount into initramfs) to debug a kernel network module, and why so ever it take ages to initialize?
[21:04] <lamont> apw: any estimate on when bug 693401 will hit hardy-updates?
[21:04] <ubot2> Launchpad bug 693401 in linux (Ubuntu Hardy) (and 1 other project) "hardy kernel lacks support for ICH10 controller in Intel Server System SR1600UR (affects: 1) (heat: 238)" [Wishlist,In progress] https://launchpad.net/bugs/693401
[21:07] <bjf> lamont, am looking into it
[21:07] <lamont> ta
[21:14] <bjf> lamont, it looks like it has been applied to the tree and we are at the beginning of an SRU cycle, it "should" hit -updates in 2 weeks
[21:17] <lamont> awesome
[21:17] <lamont> that's the blocker for 2 reasonably phat ppa builders
[21:41] <virtuald> for someone in my loco channel (she /quit), with the latest maverick kernel she said, the kernel didn't recognize her phone when plugged in with a usb cable, and there was no mention of usb dmesg (http://paste.ubuntu.com/552589/). when she tried with the previous kernel it worked.
[21:51] <virtuald> anyone know how that could be?
[22:06] <Q-FUNK> wrt bug #396286 exactly what is the point of not attempting to backport ext3/ext4 fixes to Lucid?
[22:06] <ubot2> Launchpad bug 396286 in linux (Ubuntu) (and 1 other project) "[Geode LX] [ION603] kernels >= 2.6.31 fail to boot [initramfs] (affects: 2) (heat: 15)" [High,Won't fix] https://launchpad.net/bugs/396286
[22:34] <kees> smb: should linux-ec2 in -proposed be promoted to -updates yet?
[22:36] <smb> kees, I think I did test that ok. So I would promote it
[22:37] <kees> smb: okay, thanks
[22:47] <virtuald> did you guys see my question? what should i ask for the next time she comes online, more than ubuntu-bug linux? i don't think she's the bisecting type… unless the problem persists
[22:57] <JFo> virtuald, what bug are you referring to?
[22:58] <virtuald> jfo: no bug#
[22:58] <JFo> then I am not sure to what you are referring
[22:58] <virtuald> 22:41 < virtuald> for someone in my loco channel (she /quit), with the latest maverick kernel she said, the kernel didn't recognize her phone when plugged in with a  usb cable, and there was no mention of usb dmesg (http://paste.ubuntu.com/552589/). when she tried with the previous kernel it worked.
[22:58] <virtuald> 22:51 < virtuald> anyone know how that could be?
[22:59] <JFo> virtuald, not without a bug and the relevant logging (as supplied by 'ubuntu-bug linux))
[22:59] <JFo> sorry, that first end-parens should have been a '
[22:59] <virtuald> ok
[23:00] <JFo> virtuald, that way we can see what information there is from her attempt to connect the phone
[23:00] <JFo> it is possible there is some error
[23:00]  * virtuald googles if there's some command line option to turn on usb debugging
[23:00] <JFo> also, if her phone charges from the usb cable, I would be interested to see if it does that when plugged in
[23:01] <JFo> virtuald, it would be helpful as well if she did a lsusb from the command line and attached that data
[23:01] <virtuald> 8]
[23:02] <JFo> that lsusb should be done when the phone is attached
[23:02] <JFo> preferably
[23:04]  * hallyn hopes that the upload to fix broadcom chips will be hitting natty archive soon...
[23:06] <JFo> hallyn, me too :-/
[23:09] <JFo> hallyn, I am told you should hassle tseliot to make sure it is happening :)
[23:10]  * hallyn wonders where to find tseliot :)
[23:14] <hallyn> JFo: do you have a workaround?
[23:17] <ogra> JFo, why do you unassign people from bugs if you mark them fix released ? that steals their LP karma ...
[23:23] <JFo> then LP karma is broken, becasue I remove them after I set it Fix Released
[23:23] <JFo> hallyn, I don't
[23:23] <ogra> JFo, but why do you remove them at all ?
[23:24] <JFo> because once a bug is 'closed' there shouldn't be an assignee as far as I have been told
[23:25] <ogra> well, its one thing that can turn people down ... its credit thats gone then 
[23:26] <JFo> if you are a developer that really cares about karma......
[23:26] <ogra> if its fix released why would it matter if there is an asignee
[23:26] <ogra> many newcomers in the community do care about karma
[23:26] <JFo> but they are not likely to be the ones fixing any of the kernels bugs
[23:27] <ogra> why ? 
[23:27] <JFo> seriously?
[23:28] <JFo> were I to be a developer working on kernel bugs, I can't honestly say that karma would be the reason I would work bugs for Ubuntu.
[23:28] <ogra> why wouldnt a teenie who wants to be a developer not file and fix a kernel bug he finds a patch for in some other distro for example
[23:28] <ogra> karma is a thing to encourage people to contribute
[23:29] <ogra> you and i might not care about it much ... community people do
[23:39] <JFo> I guess I just don't see a Ubuntu Kernel Dev, Ted T'so or some Upstream level developer being all excited because his karma went up a few points.
[23:39] <JFo> I supppose I am hindered by the high level of ability needed
[23:40] <JFo> in order to solve the vast majority of these
[23:40] <JFo> I could be wrong, and to be honest, I have almost no energy around the issue
[23:40] <JFo> I'm just perplexed that it is, in fact, an issue
[23:41] <JFo> I don't mean to imply that karma is useless, far from it
[23:41] <ogra> i'm not talking about a ted t'so :)
[23:42] <JFo> in other packages I am sure there is a bit of energy around it
[23:42] <JFo> I just never have seen some teenager fixing kernel bugs.
[23:42] <ogra> i'm talking about the teenage guy who does one of his first contributions and is excited
[23:42] <JFo> I seriously doubt they are contributing in the kernel here rather than on the main kernel 
[23:43] <JFo> but like I said, maybe I am wrong
[23:43] <ogra> well, apparently the kernel team has its own bug policies (emmet just told me) so do as you like, i just noticed it and found it weird
[23:43] <ogra> the bug control team has no policy to unassign closed bug
[23:43] <ogra> s
[23:44] <JFo> yeah, I work waaaaay outside of that
[23:44] <JFo> well, time for a beer