[04:51] <F40PH> !ops
[04:51] <ubot3> Help! lamont, zul, T-Bone, mdz, or jdub
[04:51] <F40PH> !ops
[08:08] <iD_J> could someone explain to me what this means by "fix released"? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/356392
[08:08] <ubot3> Malone bug 356392 in linux "[Acer, inc. Aspire 6530G] suspend/resume failure [non-free: fglrx]" [Undecided,Fix released] 
[08:37] <iD_J> could someone explain to me what this means by "fix released"? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/356392
[08:37] <ubot3> Malone bug 356392 in linux "[Acer, inc. Aspire 6530G] suspend/resume failure [non-free: fglrx]" [Undecided,Fix released] 
[08:40] <amitk> iD_J: it means that the fix is available in a kernel update. But since you reported this on a 9.10 system and the 'fix' is to upgrade to 2.6.32, that status isn't right
[08:42] <smb> Well it is right as the default task is always the development release. So if the status should be tracked for Karmic, this needs a nomination and so on
[08:43] <apw> yeah i think the status is changed incorrectly, this seems to be working with mainline 2.6.32 and not with lucid kernels
[08:44] <amitk> smb: i guess my point was the status was changed to fix released w/o opening a nomination for karmic (and probably makring it won't fix)
[08:44] <smb> amitk, Ok, yeah
[08:45] <smb> apw, I is probably working with lucid. The test was 9.10 (Kramic) with 2.6.32
[09:21] <iD_J> it doesn't work with lucid
[09:21] <iD_J> only the mainline kernel
[09:25] <smb> iD_J, Ok so then its definitely the wrong status
[09:28] <iD_J> smb: would you be able to sort it out? i don't really understand this stuff that much
[09:31] <smb> iD_J, Can do. But this looks as needing a bit more clarification / debugging. If I read this correctly it was not only the kernel that got changed, but also the graphics driver. Is that right?
[09:33] <iD_J> smb: the driver doesn't make a difference
[09:34] <iD_J> the problem occurs with the open source one and the proprietary one
[09:35] <smb> iD_J, Ok, yeah I saw there is a previous comment which is clearer. Which version of the mainline kernel did you use? And is it possible to go backwards in the mainline build to see when it stops working?
[09:35] <iD_J> smb: i used the one i was asked to use, 2.6.32
[09:35] <iD_J> i can do that, but it would have to be later today or maybe tomorrow
[09:36] <smb> iD_J, That would be ok. I add some comments to the bug and set it back to triaged (open)
[09:53] <iD_J> smb: thank you =]
[09:54] <smb> iD_J, np :)
[10:22] <matti> ;]
[10:53]  * apw slams the lucid build system into karmic as an experiment
[10:58] <abogani> Are there problems running a .31 kernel on Lucid? For example with udev or usplash?
[10:59] <apw> abogani, a stock .31 is not expected to boot
[11:00] <abogani> apw: Ok. How can armel kernel boot?
[11:01] <apw> its not a stock .31 kernel, it is a kernel we have crafted for the purpose
[11:02] <apw> why do you want to put a .31 kernel on lucid?
[11:04] <abogani> apw: linux-rt is stick on .31
[11:05] <apw> i don't suppose i want to know why you need an -rt kernel
[11:06] <apw> at a minimum you would need the devfs patches and module.builtin patches from the fsl-imx51 branch to have a hope of booting correctly
[11:07] <abogani> apw: Ok. I'll take a look. Thanks!
[11:07] <apw> is there not an rt patch set for .32 yet?
[11:18] <abogani> apw: No unfortunately
[15:10] <hyperair> has anyone heard of an issue where touchpad and keyboard of a notebook doesn't work under any linux kernel? workaround being passing this kernel option: i8042.noaux
[15:15] <smb> Hm noaux, I thought disables the use of the auxillary ports which normally ps/2 mice are connected to. But in general there were cases where that was broken. 
[15:15] <hyperair> yeah, the touchpad doesn't work in either case.
[15:15] <hyperair> but the keyboard only works with noaux set
[15:16] <smb> Ah, ok. Make more sense that way
[15:16] <hyperair> weird
[15:16] <hyperair> http://ubuntuforums.org/showthread.php?t=1098767 <-- this
[15:17] <hyperair> a friend of mine
[15:22] <smb> Well it sounds as enabling the aux port causes so much noise/problems that the keyboard gets affected as well. The best chance is to create an upstream bugzilla report (probably after testing the latest mainline build) and try to get the attention of Dmitry Torokhov, who is the maintainer
[15:24] <smb> If you boot with i8042.debug=1, you can gather a lot of debugging data in dmesg for him
[15:24] <hyperair> smb: there was some. but i can't make head of tail out of it
[15:24] <hyperair> smb: i've got his /var/log/kern.log here.
[15:25] <hyperair> smb: also, windows works fine, it seems
[15:25] <smb> Yes, the output is horribly cryptic, a very basic protocol.
[15:26] <hyperair> smb: http://people.ubuntu.com/~hyperair/kern.log
[15:28] <hyperair> it's kinda huge, but there are several test cases -- with noaux, with nomux, and with debug
[15:28] <smb> While that is a lot, I don't see any messages that would be there if using the i8042.debug=1
[15:29] <hyperair> all the way at the bottom
[15:29] <hyperair> look for "i8042"
[15:34] <smb> Ah, ok. Let me see whether I can find my ps2 cheat-sheet
[16:00] <smoser> jjohansen, ping
[16:00] <smoser> bug 520015
[16:00] <ubot3> Malone bug 520015 in linux-meta-ec2 "bad dependencies on karmic linux-ec2, linux-image-ec2" [Undecided,New] https://launchpad.net/bugs/520015
[16:04] <smb> hyperair, Hm ok: 20->read command byte returns 47 (does not decode well on my sheet, maybe too old), then 60 sets a new value. d3 tries to echo the value 5a back trough a loopback which fails. Then a9 is a aux test which seems to timeout (fe) Then the command byte is updated again with 47 and finally a f2 which I don't find in my doc.
[16:05] <smoser> last night my karmic build ended up with 2 -virtual kernels and 2 -ec2 kernels in the image. i think its related to bug above. maybe it will fix itself?  something in the dependency resolution of linux-virtual and linux-ec2 ended up pulling 2 '-image' packages.
[16:05] <smb> Bah, gone already. No patience those guys
[16:06] <smb> smoser, There had been a mismatch in the meta and the kernel version numbers. In theory it should be fixed by now... Though I need to look
[16:20] <jjohansen> smoser: I am hoping it will correct it self
[16:21] <smoser> me too :)
[16:21] <jjohansen> smoser: if it shows up again tonight, we will take another look at it
[17:18] <Laibsch> Hi
[17:26] <Laibsch> Keybuk suggested that bug 375148 may be a kernel bug.  Is it true that recent kernels don't allow nonfree drivers to have device nodes?
[17:26] <ubot3> Malone bug 375148 in sl-modem "no more /dev/ttySL0 device node" [Medium,Confirmed] https://launchpad.net/bugs/375148
[17:29] <Keybuk> not a kernel bug
[17:29] <Keybuk> a change
[17:29] <tgardner> Keybuk, one of the GPL only functions?
[17:30] <Keybuk> tgardner: yeah, I have a vague feeling/memory about it
[17:31] <tgardner> it wouldn't surprise me
[17:31] <Keybuk> was wrt to the nvidia driver at plumbers last year
[17:32] <Keybuk> drivers/base/core.c:EXPORT_SYMBOL_GPL(device_register);
[17:32] <AnAnt> Hello
[17:33] <Keybuk> though in the sl-modem case, tty_register_device() is still permitted
[17:33] <Keybuk> __register_chrdev is permitted too
[17:35] <Keybuk> so it should be possible to make the driver work given the current permitted interfaces
[17:36] <tgardner> Laibsch, ^^
[17:37] <Laibsch> great news
[17:37] <Laibsch> unfortunately, something does not work
[17:37]  * Laibsch needs to compile the latest package and restest
[17:39] <Keybuk> Laibsch: you don't even need udev now of course
[17:39] <Keybuk> we switched to devtmpfs in lucid
[17:39] <Keybuk> so if the module is right, the kernel will make the device node in /dev for you
[17:48] <AnAnt> Keybuk: thanks
[18:11] <AnAnt> Keybuk: how about device_create, that's GPL only ?
[18:12] <AnAnt> Keybuk: I found some old code for sl-modem that uses device_create, device_destroy, class_create, class_destroy
[18:17] <Keybuk> those are GPL only
[18:19] <AnAnt> is device_create similar to tty_register_device ?
[18:20] <Keybuk> device_create is the underlying function
[18:20] <Keybuk> I think it's ok if you register a tty device
[18:20] <Keybuk> which is ultimately what you're after
[18:20] <Keybuk> afaict the intent is that out-of-kernel non-GPL drivers can't invent new subsystems
[18:20] <Keybuk> or new classes of devices
[18:20] <Keybuk> but can implement a device which is handled by a kernel subsystem
[18:21] <Keybuk> ie. you can write a non-GPL network driver, serial driver, tty driver, etc.
[18:21] <Keybuk> but you can't write a non-GPL driver for something interesting ;)
[18:22] <AnAnt> so, what should I use instead of the device_destroy, class_create, class_destroy for tty ?
[18:23] <Keybuk> tty_register_device I guess
[18:23] <Keybuk> if it does what you need
[18:24] <AnAnt> ok
[18:25] <Keybuk> then the ttySL0 will actually come from the tty subsystem
[18:25] <Keybuk> which is probably right too
[18:25] <AnAnt> tty_{un}register_driver instead of  class_{create,destroy} ?
[18:25] <Keybuk> that kind of thing yeah
[18:25] <Keybuk> the struct would change
[18:26] <Keybuk> look at the existing modem drivers
[18:26] <AnAnt> Keybuk: can you tell me of an existing modem driver ?
[18:26] <Keybuk> the entire contents of driver/serial ?
[18:29] <smb> iD_J, So you need more info on the suspend bug from this morning? So just for recap: 2.6.31 (ubuntu) works, 2.6.32 (ubuntu) not, 2.6.32 (mainline) does work and 2.6.32.6 and 2.6.32.8 work as well
[18:29] <AnAnt> ok, thanks
[18:31] <iD_J> nobody's tested 2.6.31 ubuntu
[18:32] <iD_J> i remember it didn't work from karmic though
[18:32] <smb> iD_J, Ok, so 2.6.31 was just a misunderstanding on my side
[18:39] <iD_J> what happens next then?
[18:40] <manjo> iD_J, do you have a launchpad bug ? 
[18:41] <smb> iD_J, In theory this info gives the chance to find out what is different between Lucid kernel and 2.6.32.8 and try to think of what might cause it
[18:41] <smb> manjo, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/356392
[18:41] <ubot3> Malone bug 356392 in linux "[Acer, inc. Aspire 6530G] suspend/resume failure [non-free: fglrx]" [Medium,Triaged] 
[18:41] <manjo> smb, thanks 
[18:44] <iD_J> that doesn't sound easy
[19:01] <abogani> Is it possible that a .31 kernel is able to boot on a Lucid system? If I don't misunderstand this don't should be possible.
[19:02] <iD_J> it booted fine
[19:06] <abogani> Someone told me that there are problems with udev and usplash if the kernel is < .32
[19:07] <iD_J> i didn't have any problems
[19:07] <iD_J> plymouth didn't work with any of the mainline kernels though
[19:09] <abogani> iD_J: Ok so I have misunderstand all. Do you know what commit fix this?
[19:11] <iD_J> commit fix?
[19:11] <bjf> abogani, you don't want to mix new userspace with older kernels
[19:11]  * JFo thinks that would break in nefarious ways
[19:11] <abogani> bjf: I don't have choice.
[19:12] <bjf> abogani, why would you not have a choice?
[19:12] <abogani> bjf: linux-rt
[19:12] <bjf> abogani, you can expect breakage in stange and interesting ways
[19:14] <abogani> bjf: Are there some documentation about this problem?
[19:15] <bjf> abogani, not specifically, you are just mixing abi's and that's not good
[19:15] <tgardner> you guys are just being paranoid. .31 works fine with Lucid
[19:16] <tgardner> note that we have 2 ARM branches based on .31 working under Lucid.
[19:17] <abogani> tgardner: Could you confirm that problems with udev and usplash simply don't exists? And with Plymouth?
[19:18] <tgardner> abogani, plymouth is a known issue. I've removed it for the time being. other then that things ought to "just work"
[19:19] <abogani> tgardner: Ok thanks.
[19:20] <iD_J> what happens with my problem now then?
[19:20] <iD_J> is there anything i can do to move things along a bit?
[20:02] <iD_J> bad times...
[20:11] <Laibsch> I'd like to see if http://bugzilla.kernel.org/show_bug.cgi?id=15180 is fixed for karmic.  But I'm not sure anymore how to recompile a Ubuntu kernel. 
[20:11] <ubot3> bugzilla.kernel.org bug 15180 in Wireless "new atheros chipset" [Normal,Resolved: code_fix] 
[20:11] <Laibsch> http://blog.avirtualhome.com/2009/11/03/how-to-compile-a-kernel-for-ubuntu-karmic/ used to work nicely, but broke recently (just a few days ago)
[20:11] <Laibsch> how am I supposed to recompile a kernel with a patch that is not in mainline, yet?