[10:01] <apw> Keybuk, pete tells me you might be interested in testing kernels with the ext4 issues sorts (this would be a .32 base) ?
[10:18] <ghostcube> hi humans logitech uvc bug fixed in 2.6.31-15 from proposed updates on 64bit
[10:18] <ghostcube> thx
[10:22] <apw> ghostcube, yay ... which bug was that?
[10:22] <ghostcube> moment pls
[10:23] <ghostcube> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/466935
[10:23] <ubot3> Malone bug 466935 in linux "No Video Output in Karmic with ID 046d:09a1 Logitech, Inc. QuickCam Communicate MP/S5500" [Undecided,New] 
[10:23] <apw> hrm, New
[10:24] <ghostcube> i reported direct aafter karmic upgrade
[10:24] <ghostcube> but no one took it :)
[10:24] <apw> heh ... sorry we have a fair few reports out there
[10:24] <ghostcube> no prob :) 
[10:24] <Appiah> :D
[10:25] <ghostcube> works again now in all apps exept camorama
[10:25] <ghostcube> claims no /dev/video0
[10:25] <ghostcube> but all others work in kubuntu 
[10:25] <ghostcube> :)
[10:25] <slytherin> Can anyone please take a look at bug 476154. I have tracked upstream change that should fix the problem. It will be great if someone could provide a test build for kernel with this patch included.
[10:25] <ubot3> Malone bug 476154 in linux "Stack trace on console, can not do clean shutdown" [Undecided,New] https://launchpad.net/bugs/476154
[10:26] <apw> ghostcube, hrm, unless htat webcam is a usb connected one its not obvious there are any fixes in there for it
[10:26] <ghostcube> its usb
[10:27] <ghostcube> anything was changed i dont know what
[10:27] <ghostcube> but it works again for all i aksed with same error
[10:27] <apw> yeah happy its working for you ... i'll close it off.  do reopen it if it breaks
[10:27] <ghostcube> ok i will do so :)
[10:27] <apw> unless we had some modules missing and the module bit fixed it ... hmmm
[10:28] <ghostcube> it was only the picture not working
[10:28] <ghostcube> cam was detected and in demesg the driver was installed fine
[10:28] <ghostcube> it was just a black picture even with 500 watt lamp infront
[10:28] <ghostcube> :D
[10:29] <apw> well i'll take any victory however won
[10:29] <ghostcube> :)
[10:31] <smb> apw, Hm, the only modules missing were in virtual. And the only usb change seems to be the sense one for the huawei's. But true enough better fixed without understanding that not at all
[10:32] <apw> yeah oddness
[10:34] <smb> slytherin, seems to be one coming down from stable. I get a test kernel build
[10:34]  * apw was just going to ask smb if that update was in stable and if os .5 or .6 ?
[10:35] <smb> apw, .6
[10:35] <apw> gah
[10:35] <apw> pre-pre-propposed
[10:36] <smb> apw, I do a special kernel and make a note to have that other bug cross-referenced
[10:36] <apw> yeah
[10:37] <apw> smb, i note its for powerpc ...
[10:38] <smb> apw, iirc the original one was 
[10:38] <smb> (the one which broke things)
[10:38] <apw> yeah i mean, i would have made x86 test kernels and looked stupid :)
[10:39] <ghostcube> ah i forgot to test the r128 modul from ppc edition in 9.10 damn
[10:39] <slytherin> smb: My machine is powerpc. So I will need a powerpc kernel.
[10:39] <smb> slytherin, ok, seems that was what apw wanted to tell me
[10:39] <slytherin> smb: I don't know how the kernel packages in Ubuntu work otherwise I could have tried to build it myself.
[10:39] <smb> :)
[10:41] <slytherin> I wish PPAs supported powerpc. :-(
[10:42] <smb> slytherin, Yeah, that would be nice. Fortunately I can use a porter...
[10:45] <slytherin> smb: By the way I didn't understand your comment - "seems to be one coming down from stable."
[10:46] <smb> slytherin, There is an upstream 2.6.31.y tree which gets fixes for a certain amount of time (usually until the next version starts being developed)
[10:46] <smb> slytherin, Some of the 2.6.32 fixes get sent to that stable tree in parallel if they are deemed to be important bug fixes
[10:47] <slytherin> smb: right, but I didn't find the fix in 2.3.31.y tree. Or may be I misread the change history of that tree.
[10:47] <smb> slytherin, No its the thing just being through review. I just happen to be on that reviewers list... ;-)
[10:48] <slytherin> Oh. That is great. So It is like that the change will land in .31 tree and eventually in karmic-updates eventually right?
[10:49] <smb> Given nobody screams it would be in 2.6.31.6 and then make its way to karmic too. Though the process is a bit slow. Definitely it will help if you can verify the fix in the test kernel 
[10:51] <smb> slytherin, The kernel is building now, I will update the bug with a link to download it, when it is finished
[10:52] <slytherin> smb: I will test it tonight (about 6 hours from now).
[10:52] <smb> slytherin, Great, the kernel should be there by then
[10:58] <smb> apw, Gah, could you have a look at bug 464552? Can't remember anything really suspend/resume related changing... You?
[10:58] <ubot3> Malone bug 464552 in linux "suspend_test_finish warning triggers too easily, increase timeout to match mainline times" [Low,In progress] https://launchpad.net/bugs/464552
[11:00] <apw> smb ... something bad happening on that bug?
[11:00] <smb> apw, sort of. someone claiming it broke his suspend (the kernel update) and this one getting marked verification-failed
[11:01]  * apw bets its just another falsey
[11:01] <apw> people do not get what that change does, not what it means
[11:01] <smb> ... which could delay the import 2.6.31.5 with 2.6.31.6 rolling its way... :(
[11:02] <smb> apw, Actually I can't really see any of the changes being related to suspend/rsume
[11:02] <apw> smb, nope none that i recall
[11:03] <smb> apw, The only one, maybe, is the change to usb which might make things half working and then breaking susp/res
[11:03] <apw> yep tend to agree there
[11:04] <smb> apw, Could you probably make a test kernel, taking out that and let that be retried?
[11:06] <apw> smb, yep ... have asked him to test the basic as he says 'doesn't work' which is no use
[11:07] <apw> will get a kernel together now
[11:08] <Keybuk> smb: did you upload a new kernel to karmic?
[11:09] <smb> Keybuk, One, yes
[11:09] <Keybuk> is that in -proposed or -updates ?
[11:09] <smb> Keybuk, -proposed
[11:09] <apw> and failing validation right now
[11:09] <Keybuk> oh, what's failing to validate?
[11:09] <smb> suspend/resume aparantly but not sure
[11:10] <apw> the problem is there are 200 bugs dup'd on that one, so we are onto a loser
[11:10] <apw> its unlikely that patch is the issue for sure
[11:11] <apw> (if there even is an issue)
[11:11] <lool> Ng: Didn't experience this Xorg thing you get; flashing capslock means kernel is alive though, so you might want to connect over SSH
[11:11] <Keybuk> err
[11:11] <Keybuk> I thought Flashing Capslock meant kernel panic? :p
[11:12] <apw> flashing by itself means panic normally, a working capslock means something else
[11:12] <Keybuk> the caps lock light should use morse to output the entire panic dump ;)
[11:13] <apw> Keybuk, that has been suggested, and actually one of our guys has played with some h/w to receieve it
[11:14] <Keybuk> that would be Colin wouldn't it?
[11:45] <apw> Keybuk, steve and colin actually yeah
[11:45] <Keybuk> apw: it had a Colinishness about it ;)
[11:47] <apw> yeah mad as a spoon :)
[11:48] <apw> smb, ok my plan is to produce two test kernels, the first will revert just the change introduced by the bug itself, to confirm (as we know) that the patch is tooo trivial to be the cause of any issues, the second to revert just the usb patch
=== tj83__ is now known as tj83_
[13:42] <Ng> lool: hrm, that's distressing in that it might mean my hardware is failing
[13:42] <Ng> I'll check with robbie and jerone too
=== dantaliz1ng is now known as dantalizing
=== ghostcube_ is now known as ghostcube
=== bjf-afk is now known as bjf
[15:14] <cking> apw, I'm not quite that mad
[17:52] <rtg> smb, apw: whats the story on those ureadahead trace patches?
[17:53] <apw> they modificy the tracing sligthly to allow ureadahead to get more information to allow it to work out wihich executabled are in use
[17:53] <rtg> are we gonna do 'em for Karmic?
[17:54] <rtg> apw, actually, I was wondering why they weren't in the last upload, but I see that they are.
[17:54] <rtg> 7423c4c3b22816168b912c39a0298227076854b8
[17:54] <apw> yep, they are in the current -proposed kernel, Keybuk has an exception for ureadahead as i understand things
[18:03] <cking_> they produce some excellent results BTW
[18:05] <cking_> http://people.canonical.com/~cking/karmic-boot-in-QEMU/boot-total-blocks-karmic-reads.png
[18:15] <ghostcube> damn i just rebootet and now cam stopped working again 
[18:15] <ghostcube> so the bug is still there and i cant tell u what its causing
[18:15] <ghostcube> grml
[18:17] <ghostcube> anyone can open this one again
[18:17] <ghostcube> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/466935
[18:17] <ubot3> Malone bug 466935 in linux "No Video Output in Karmic with ID 046d:09a1 Logitech, Inc. QuickCam Communicate MP/S5500" [Undecided,Fix released] 
[18:17] <ghostcube> same as before the kernel update
[18:24] <scroll> Why gcc throws erros when i try include "linux/module.h"?
=== maco_ is now known as maco
[20:11] <ghostcube> apw: ping
=== BenC2 is now known as BenC