=== kamal is now known as kamal-away === pgraner-afk is now known as pgraner [06:00] mfedyk in #btrfs has just updated the btrfs wiki with instructions for setting btrfs to build from git via dkms in ubuntu and debian; anyone care to proofread? [08:09] * smb sips some coffee [08:13] * jk- remembers that he started making a coffee about 30 mins ago, and goes to finish it [08:14] That's the worst kind of morning tiredness :) [08:15] Too true [08:20] unfortunately, it's 3:20pm :) [08:21] Just a hell of a long morning then. :-P [08:24] heh, "for large values of 'morning'" [08:27] * abogani waves [08:29] * apw yawns [08:29] morning lag [08:30] Morning [08:30] I have my Launchpad set-up now :D [08:33] lag: I see you muscled-out the inactive user :) [08:33] Damn tootin' [08:34] How do you lot keep tabs on everything that happens on all these channels and keep up with your work? [08:34] lag, You don't [08:35] smb: Phew [08:37] smb just tells us all to shut up until he has time to read IRC [08:37] You can set up a few words that trigger highlighting (potentially with sound) so it gets your attention. But otherwise you normally can only pay attention to one thing. [08:37] jk-, No I am telling you I ignore you most of the time. :-P [08:38] good advice. [08:39] lag, Except your name is apw, which means you are present and chatting in all channels 24hrs a day. (joking) [08:39] smb, no that is master wats-o-n who will still detect his nick dispite heavy stealthing [08:39] lag: you ignore the channels unless they are pings to you. And once in a while you scan all of them if you care... [08:40] apw, This has the sound of you-know-who. :) [08:41] * persia notes that several clients allow advanced regexes for highlighting [08:41] not everyone is cjwatson and can hold 12 simultaneous IRC conversations [08:41] No he said the name. *panic* [08:41] though it is claimed that irssi highlight window is the way [08:42] The irssi highlight window *is* made of awesome. [08:43] * persia has started to prefer the quassel "Chat Monitor" window [08:43] persia, is that something in addition to your normal irc client, or do you use quassel [08:44] apw: Right now, I'm only using two clients (my laptop power switch broke), but I usually use several simultaneously to provide the views I prefer. [08:45] The trick is to have some proxy (irssi can do this, and there are many others) so you can have single identity with multiple clients. [08:45] smb: May I disturb you for a minute? [08:45] abogani, sure [08:45] persia, ahh, i use a bip proxy in general too [08:45] bip+quassel+/bip blreset leaves something to be desired, but ... :) [08:46] smb: I have placed an update -rt kernel package for Lucid at https://launchpad.net/~abogani/+archive/broken. How I should proceed now? Should I write a SRU justification? [08:48] apw, persia: I was told XChat was the way to go =:-S [08:49] s'what a lot of us use, its one of the easier ones to get going in IMO, it may not be the most powerful [08:49] your irc client is like your editor something you grow into [08:49] lag: I like xchat a lot myself, but the key is to find the client that works best *for you*. if you set up a proxy, you can try them all with relatively low interference. [08:49] I think emacs does IRC *dribbles* [08:49] abogani, I guess this can be treated a bit like the arm or ec2 packages. In that case I would welcome a short mail to kernel-team list to tell the rational for this change and point to the place on launchpad. Then its possible to discuss it and proceed. [08:51] abogani, Being not the "main" kernel package, the SRU policy can be less strict [08:53] smb: The problem as you surely know is that a kernel update can contains a lot of commits so it is very hard to write a justification for each of these. :-/ [08:53] smb: In particularly when the packaging is maintained by one only person... [08:53] abogani, Yeah. Having a less-strict policy means, you should get away with general improvement and lots of bug fixes [08:54] abogani, Just generally describe what you have done. Like updated to the latest rt patchset, included the latest stable patches, ... [08:55] smb: Could I ignore commits introduced by you (in Karmic kernel which are used as base for rt) ? [08:56] abogani, I'd at least say that you rebased (from?) to Ubuntu-2.6.x-y.z whatever. You don't need to go into details. But it is good to know the fact which is the new base of the kernel. [08:57] smb: Ok, thanks. [08:58] abogani, no problem [09:02] smb, abogani, we should remember that the update should be applied in maverick 'first' according to the rules. i assume linux-rt is the same in maverick [09:05] apw, abogani As long as it is the same maybe. The kernel package was always problematic with that. If you have individual fixes yes, but the whole package... [09:05] smb: I would want update -rt kernel in Maverick with 2.6.33 (the latest release by Gleixner). [09:05] in which case its all moot and you can ignore it [09:06] abogani, if you are going to base off of .33 then we should consider using the .33 based ogasawara did during maverick roll forward [09:06] smb, and stable needs to think about how we could maintain that base for ti-omap and this perhaps [09:07] apw, The package in the repo abogani mentioned seems 2.6.31 based (for lucid) [09:08] We may speak of two different versions [09:08] smb, yeah i mean that we will have an updated ti-omap and we'd like that to be on a real ubuntu 2.6.33, and any .33-rt for maverick would like to be on the same base to get all the ubuntu goodness. seems like an oppotunity to share the base should we do it right [09:12] apw, I partially understand. Though 2.6.33 is sort of a lost thing right now. I have not looked how far that got with upstream stable releases and from now or soon its off for normal updates. [09:12] smb, yeah its not all clear right now [09:24] ericm|ubuntu, https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick perhaps ? [09:25] or http://people.ubuntu.com/~pitti/workitems/canonical-kernel-team.html [09:31] apw, exactly these two URLs [09:31] ericm|ubuntu, in that case i have no idea :)h [09:32] apw, both are useful [09:32] :) [09:32] though the color "green" is making my eyes bleeding [09:39] ericm|ubuntu, its not the best colour [09:40] ericm|ubuntu, if you are adding blueprint work items remember that the work items section and the items themselves are computer readable and have a specific format [09:44] apw, so once blueprint is modified to a correct format, the work items will be automatically updated? [09:45] ericm|ubuntu, thats right, they will move to those summary pages by magic [09:45] apw, cool - thanks [09:47] apw, so for a new item, it should be something like: [eric.y.miao] xxxxx: TODO? [09:48] yep [09:48] and in a section [09:48] Work items for maverick-alpha-1: [09:48] item [09:48] item [09:48] [09:50] apw, I see - and I don't need to delete the original descriptions in the whiteboard, sections/workitems in such format will be scanned right? [09:50] that is correct [09:50] one section per milestone though [09:50] apw, I see [09:51] apw, but we can first target for alpha-1, postpone it for alpha-2 right? [09:52] yep, you can move then around as you see fit yes [09:52] though try and be realistic [09:52] apw, OK [09:52] you can have sections for many milestones, see https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-misc as an example [10:09] jk-, mind if I assign the common clock framework in blueprint kernel-maverick-arm-single-zimage to you? [10:09] apw, got you [10:46] ericm|ubuntu: I already have that line item in the ARM blueprint [10:47] * psurbhi eyeballing the btrfs tools code [10:47] * cking does yet another S3 cycle [10:49] ... but we can track it in two places, if that helps [10:54] jk-, ok - let's track it in two places, what's the milestone target then? [10:55] ericm_: well, when are you looking to have the blueprint completed? [10:58] ericm_: I could take a look at some items on that blueprint [10:58] amitk, let me know which items you are interested [10:59] jk-, possibly end of this week - that was what Leann suggested [10:59] oh, i mean the actual items on it :) [11:10] * cking suffering from the uds-flubug [11:10] jk-, could be any time you think appropriate, maybe target at 10.10 and postpone it? I understand it's quite a long term thing [11:11] cking: i'm sorry, you can't have the flu unless you have it assigned to you in a blueprint :) [11:11] jk-, now that's amusing! [11:11] ericm_: target it at 10.10 if you like, I hope to have something upstreamed before then. However, I think that there are much larger items on the blueprint that will take longer. [11:13] apw, how do you think about some kernel items both in kernel-maverick-arm-kernel-as-bootloader and arm-maverick-softboot-loader [11:13] jk-, yeah I fully understand [11:13] ericm_, there is no point in having the same item in two places [11:14] apw, mmm.... just wondering which side to delete them from [11:14] you could easily make arm-maverick-softboot-loader point to kernel-maverick-arm-kernel-as-bootloader [11:14] if it makes sens you can also just close off the kernel one and consolidate onto the other one [11:14] if its really a single subject [11:15] or just add a note in one saying that the kernel items are on the kernel one [11:15] but duplicating them will just confuse === smb is now known as smb-afk [11:17] apw, ok - I'd prefer to make softboot-loader point back, I'll talk with NCommander on that later [11:18] ericm_, if they are items on us, feel free to put them where they make sense [11:18] apw, ok [11:18] just leave him a note in the whiteboard saying where they are [11:18] apw, and I noted that the work items should be placed in the front of the whiteboard, yeah? [11:21] ericm_, there is no requirement, i tend to put them there to make them more obvious when there is lots of text [11:21] apw, got you [11:23] ericm_: so do you want to remove the clk stuff from the single-zimage bp then? [11:24] jk-, yes I'll do that later, and point it to your DT blueprint then [11:24] cool :) [11:28] jk-, can't see your blueprint on the list ? [11:29] apw: yeah, it seems to be somewhat invisible, want a link? [11:29] yep [11:29] want to know why its not on my list yet [11:29] well leanns list, but hey [11:29] because it's an arm- one? [11:29] does it have work items on you? [11:29] yup [11:29] then it should appear, unless its wrong :) [11:30] * jk- guesses the latter [11:30] https://blueprints.edge.launchpad.net/ubuntu-arm/+spec/arm-m-using-device-tree-on-arm [11:30] link ? [11:30] 'work items' -> 'workitems' ? [11:32] nope [11:33] maybe that you need it to have a series goal of maverick [11:34] hm [11:34] "m-release" [11:34] or "trunk" [11:34] those crazy arm people. [11:37] jk-, heh :-) [11:37] apw: will either of those suit you? [11:38] jk-, mine are pointed to maverick i think [11:38] i don't get a "maverick" option :/ [11:38] but i can't point them to find out :) [11:38] hi anyone can provide a tip how to configure udev (udisks/create_floppy_devices (default floppy creation in ubuntu 10.04) to pass codepage=866,iocharset=utf8 parameters to correctly mount floppy? [11:45] http://patchwork.ozlabs.org/project/ubuntu-kernel/list/ [11:48] apw: you're coming a close second behind dave miller :) [11:48] http://patchwork.ozlabs.org/project/netdev/list/ [12:02] jk-, heh ... joy [12:04] jk-, see how this one has 'accepted for maverick' in the series goal section [12:04] https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-easy-wayland-testing [12:04] i suspect yours needs that [12:05] i just don't have that option though [12:06] only "ubuntu-arm m-release" and "ubuntu-arm trunk" [12:06] i guess becuase this blueprint is for the "ubuntu-arm" project instead of the "ubuntu" one [12:07] i could "retarget" it maybe? [12:08] Unfortunately, that's incredibly difficult, because of how LP works. [12:08] but then the arm folks might miss it [12:08] So it's kinda stuck where it is (when we decided to never use "ubuntu-mobile" we copied the specs that seemed interesting) [12:38] jk-, hrm thats a bit crap, work to be done by our team really should be visible. perhaps we can make a dependant blueprint and put that in ubuntu [12:39] there is the concept of a depeancy tree of blueprints, persia do you know if an arm one could depend on an ubuntu one? [12:40] I don't know, sorry. The conclusion of the experiment with the "ubuntu-mobile" project was to try to forget it ever happened. Unfortunately, it seems we were successful. [12:52] jk-, do you have an 'add dependancy' button on your blueprint details view? if so try adding kernel-maverick-misc === smb-afk is now known as smb [13:02] hi. ive got an very curios problem with my logitech g15 keyboard. after a few minutes or sometimes hours my keyboard dies. i cant type anything. power's still there and the display works fine, too. i use the 2.6.32-22 kernel with lucid [13:06] Deem, is that an external keybaord? [13:06] Deem, As I have no idea what a g15 keyboard is (certainly I could look). But I assume it might be connected via usb. If you can remotely log in if that happens maybe you see some messages in dmesg [13:08] ... removing "quiet" from the kernel command line could potentially show more info [13:09] Deem, But as apw says, if you can tell us what kind of keyboard this is. Internal, external (connected via ps2 or usb)? [13:09] smb: its connected via usb [13:09] and its an external keyboard [13:10] so does it come back if you pull it out and re-plug it in ? [13:11] apw: no. it still keeps dead [13:11] One other thing to test might be any other usb device. see whether thats dead as well [13:12] (in the same port) [13:12] smb: its only happen to my keyboard... if i plug it in another port it got dead too [13:13] ive plugged my external hdd in the first port and it works fine [13:13] Deem, does the cursor look different when the issue occurs? [13:13] it seems like lucid doesnt like my keyboard [13:13] apw: no. it all looks like always [13:13] Ok, that rules out the usb subsystem generally [13:13] smb, remember those cases where you had to press all the modfieres to sort out the keyboard [13:14] but in that case the cursor was a the normal text cursor i think, but didn't change on window boundaries any more [13:15] smb, its not obvious how the keybaord could not recover on removal and insertion into a different usb port and yet be ok on a reboot ... [13:15] apw, The cases I saw would at least resolve by unplugging. And usually its not dead but repeats some keystrikes [13:15] maybe its the special on my keyboard. i have such keys that ae called "g"-key and ive got an switch to disable the windows key... maybe its one of this [13:15] apw, I could only think that there is one input device created and this might stay open... not sure [13:16] dmesg at the time of the failure might say something, worth checkng [13:17] yeah [13:17] apw: how should i type dmesg if i cant type anything? :D [13:17] Deem, ssh? Assuming there is another computer arround [13:17] smb: sry. no second computer [13:18] well if its only the keyboard presumably you open a terminal in advance and pre-type 'dmesg | tee -a DMESG' [13:18] Deem, I guess you are neither blessed with a second keyboard for emergencies. ;--) [13:18] and then cut-n-paste a newline into the window to trigger the command [13:18] after the keyboard is dead [13:19] Deem, but if the computer does not lock up completely there might be something in the /var/log/syslog after reboot... [13:19] smb: ok. ill take a look. just a sec [13:19] or actually as apw sais [13:19] says even [13:20] On-screen keyboard? [13:20] Or even tail -f /var/log/syslog [13:20] is entiryly possible, that if you can use mouse to reboot that the logs already contain the informaiton [13:22] apw, Not sure I got this right but in my mind the stack is somewhat like usb->hid->input device->X with a lot of places to consistently go bonkers [13:25] smb: cant find anything in the syslog file [13:26] Deem, then I'd try two terminal windows [13:26] smb: how do you mean that? [13:26] in one do a tail -f /var/log/syslog and in the other [13:27] tail -f /var/log/Xorg.0.log [13:28] Deem, In X open two windows from applications->accesoiries->terminal [13:28] And then run one of both tail commands in one of them [13:28] Then wait until the keyboard goes doead [13:28] dead i mean [13:29] smb: ok. i'll write again. if it happens [13:29] Deem, Sure. Hopefully one of them contains something [14:06] tgardner, seems we can nolonger make git directories on zinc, who do we hastle? [14:07] apw: lamont [14:07] * apw waits :) [14:07] apw, 3.1G available. getting pretty close [14:07] heh yay [14:13] tgardner, smb, how far back do you think we need 'daily' builds for linus ? [14:14] apw, I don't think they are of much use once he's released an official version. [14:14] tgardner, apw Dunno, somehow it feels anything between 2.6.25 and 2.6.30 could go... [14:14] at least [14:15] so i could do some hybrid of that, everything before say 'lucid' release version [14:16] apw, we cold certainly drop the 2.6.27* kernels. [14:16] could* [14:16] so apw or smb or tgardner I have a bossman bug 581312 [14:16] Launchpad bug 581312 in linux (Ubuntu) "Unknown key fee[x] pressed (affects: 1) (heat: 8)" [Undecided,Triaged] https://launchpad.net/bugs/581312 [14:16] Malone bug 581312 in linux "Unknown key fee[x] pressed" [Undecided,Triaged] https://launchpad.net/bugs/581312 [14:16] Launchpad bug 581312 in linux (Ubuntu) "Unknown key fee[x] pressed (affects: 1) (dups: 1) (heat: 8)" [Undecided,Triaged] [14:16] apw, True. Cannot think of a reason to have anything beside the rc levels of something released [14:16] ubot3: Bug 581312 on http://launchpad.net/bugs/581312 is private [14:16] ubot2: Error: I am only a bot, please don't think I'm intelligent :) [14:16] ubot3: Error: I am only a bot, please don't think I'm intelligent :) [14:16] ubot2: Error: I am only a bot, please don't think I'm intelligent :) [14:17] ubot3: Error: I am only a bot, please don't think I'm intelligent :) [14:17] ubot2: Error: I am only a bot, please don't think I'm intelligent :) [14:17] ubot3: Error: I am only a bot, please don't think I'm intelligent :) [14:17] ubot2: Error: I am only a bot, please don't think I'm intelligent :) [14:17] ubot3: Error: I am only a bot, please don't think I'm intelligent :) [14:17] ubot2: Error: I am only a bot, please don't think I'm intelligent :) [14:17] ubot3: Error: I am only a bot, please don't think I'm intelligent :) [14:17] ubot2: Error: I am only a bot, please don't think I'm intelligent :) [14:17] ubot3: You've given me 5 invalid commands within the last minute; I'm now ignoring you for 10 minutes. [14:17] ubot2: Error: I am only a bot, please don't think I'm intelligent :) [14:17] fail [14:17] * smb slaps JFo [14:17] wtf [14:17] bot fight [14:18] somebody kickban one of those [14:18] Gosh, before we were happy to have one, now there are two trying to fight each other [14:18] who is the channel op? bjf? [14:18] apw [14:19] now [14:19] I see that now [14:19] i would but the chanserv is mute [14:19] oh finally ... stupid thing [14:20] lol [14:20] apw, so, you're gonna dump all the -rc candidates except maverick? [14:20] get the hell off of my channel you argumentative bot === apw changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/KernelTeam/ || Lucid Kernel Version: 2.6.32 || Ubuntu Kernel Team Meeting - May-17- 17:00 UTC === apw changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/KernelTeam/ || Lucid Kernel Version: 2.6.32 || Ubuntu Kernel Team Meeting - May-18 - 17:00 UTC [14:20] tgardner, I thought we keep the rc candidates but get rid of the dailies [14:21] smb, what good are the rc's for released kernels? [14:21] yeah tend to keep the recent -rcNs for a couple of releases in case they are useful for regression-release bisect [14:21] and drop the dailies [14:21] tgardner, Rough bisecting if something got introduced then [14:22] I disagree. only the vanilla stable kernels are useful _after_ the release [14:22] we don't have unlimited storage [14:22] tgardner, There might be bugs introduced during 2.6.32 timeline... [14:23] tgardner, Thats why we likely could dump most of pre-lucid [14:24] tgardner, ok back to 21G [14:24] dropped the last years dailies and some of the very old -rcNs we had [14:24] we can now argue more sedatly abuot where the boundary should be [14:24] apw, how about v2.6.31-rc* [14:24] ? [14:25] Guess those could go [14:25] probabally 31-rcN are now lower usefuless, on the cusp as far as i am concerned [14:26] ??? parse error [14:26] longer* [14:26] i think 32 is deffo useful, 30 is deffo not useful, and 31 is hard to say you could convince me either way [14:27] is intrepid off support now ? [14:27] Yes [14:27] apw, as of Lucid release [14:27] and if so, that was .27 right ? === kamal-away is now known as kamal [14:27] Reminds me to move the git trees [14:27] so i could zap most of those [14:27] yep [14:27] vanhoof, you around? [14:27] tgardner, Will I step on you when I go to do that? [14:28] smb, archinving intrepid? dunno [14:28] ok 24GB available [14:28] tgardner, I guess no, if you are not just doing the same. ;-) [14:29] smb, no, I'm not messing with it right now. go ahead [14:29] apw, are you cleaning stuff out of /home/kernel-ppa/public_html/mainline ? [14:29] tgardner, yes [14:30] apw, tgardner Ok, gone to ubuntu-archive now [14:31] apw, you still plan on dumping *2.6.27* kernels? [14:31] that'll free up a bunch more space [14:31] yeah i had previous reaped back to just every 5 of the stables, but as its dead [14:31] i recon the last one maybe [14:32] kamal: sorry i missed you yesterday. yeah, if you could clean up that tag for me, it would be great [14:33] achiang: I've lost the bug number [14:34] achiang: found it 578138 [14:35] achiang: done [14:35] kamal: heh, you're faster than me. [14:35] thanks. [14:35] achiang: np :-) [14:35] -ENOCAFFEINE [14:35] JFo, Re bossman bug: might be useful to ask for "sudo lsinput" to see what shows up as an input device. lsinput is from input-utils iirc [14:35] achiang: yeah I need another cup too === kamal is now known as kamal-away [14:36] smb, cool [14:36] how do we feel on importance? [14:37] JFo, Normally low to medium but... [14:37] ok [14:37] just wanted to check [14:37] apw, Would you know magic to let an input stream be ignored? [14:38] ignored in what sense? [14:38] Like ignore all key comming from this [14:39] i don't know of a way no, now that X handles devices direclty i suspect there might be a way there [14:39] But probably this is just incorrectly detected as keyboard. If _his_ guess is right. It sounds reasonable [14:40] request sent [14:45] do we use linux-ports (Ubuntu) package anymore? [14:46] I haven't been watching it and someone changed a but to that [14:46] * JFo plans to change it back if we don't [14:47] JFo, Not an explicit. The ports are build from the main package [14:47] (lucid) [14:48] yeah, apparently there are 25 bugs against the package [14:48] that I was unaware of [14:50] JFo, From my feeling it would be Luke and ncommander that would need to be aware. apw ? [14:50] linux-ports would be old releases no? [14:50] for karmic on they probabally are meaningless [14:51] apw, Was it already Karmic when the sources were combined again. Drat, were do you buy your brain extensions? [14:52] heh [14:52] heh [14:52] I'm up for doing whatever. just need to know what that is [14:52] yeah karmic has ports in it [14:52] and jaunty does not [14:53] so they can only apply to hardy and jaunty i think [14:53] dapper had them built in too right> [14:53] https://bugs.edge.launchpad.net/ubuntu/+source/linux-ports [14:53] there are some old ones in there [14:53] So reports on linux-ports package likely is Jaunty or Intrepid. For hardy the ports were part of support [14:54] https://edge.launchpad.net/ubuntu/+source/linux-ports [14:54] Dapper too, though maybe slightly different archs [14:54] heh look its only jaunty now [14:54] so any bugs which arn't jaunty can be closed outright [14:54] ok [14:55] JFo, you could apply the tagger thing to linux-ports and zap all that pre jaunty can go, any later than jaunty are likely on the wrong package, and move to linux [14:55] then my next Q is. who owns this packages bugs? I assume me [14:55] ok [14:55] apw, And bugs on jounty, if not killer bugs won't quilify either [14:55] k [14:55] well i'd say, anything left is not our problem, and can be stuck from our stats [14:55] * JFo writes some notes [14:55] apw, I'm not sure they are currently on there anyway [14:56] * JFo makes a note to check [14:56] ahh good [14:56] but yeah agressive closing seems also ok [14:56] k [14:56] * smb desperately tries to remember which clever note he was about to write before [14:57] apologies smb :-/ [14:58] JFo, No worries. Maybe apw reveals where he gets his brain extensions from, then I can increase my stack size. :-P [14:58] JFo: sure, whats up [14:58] let me know, maybe we can get a bulk discount [14:58] smb, i make space by dropping useless information like names and birthdays [14:58] vanhoof, hey man, qa is pinging me about OEM escalations [14:58] smb: Please don't forget me! :-) [14:58] think we need to come up with a good flow for now on them [14:59] apw, Good plan, beside of girl friends... [14:59] on where they go so they don't get dropped [14:59] JFo, i think those bugs belong to architecture teams by the looks of it [14:59] the ports ones apw? [14:59] JFo: sounds like a plan [14:59] JFo: give me 5, ill ping you [14:59] yeah, looking at a few, they often are subscribed to like 'powerpc team' [14:59] vanhoof, cool [14:59] apw, ok === cking is now known as cking-afk [15:02] * cking-afk visits local hospital, back later [15:06] cnd, you around? [15:06] JFo: yep [15:06] care to take a look at bug 580305? [15:06] you better not give me any work :) [15:06] Launchpad bug 580305 in linux (Ubuntu) "Version of hid-quanta in Lucid kernel is broken (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/580305 [15:06] looks like quick review/fix maybe [15:07] cnd :-) [15:07] it is opt-in [15:07] JFo: I'm actually caught up with oem work right now [15:07] cool! :) [15:07] but I won't bug you [15:07] just saw this and wondered if you were interested [15:07] JFo: hopefully there's some resolution soon [15:07] so I can start working on other things [15:07] but not quite yet [15:07] yeah [15:08] * apw has to run do an errand ... paperwork, shmaperwork [15:08] well, there is hope [15:08] enjoy apw [15:08] where did the day go i wonder [15:08] apw, it came over to the US apparently... [15:08] I wouldn't have minded it staying across the pond for a while ... [15:10] same here [15:10] i feel very bad [15:10] may take off in a bit [15:10] I was feeling great until I got a new code drop to slog through :( [15:14] I've been quite sick since yesterday [15:14] nothing seems to help [15:22] smb, tgardner are we having a meeting today/ [15:22] JFo, Yes, [15:22] k, thanks [15:36] smb: it happend again, my keyboard dies and these are the msg from the syslog http://paste.pocoo.org/show/215273/ [15:40] Deem, Looks useful. If there is a bug on it that should ggo in. g15daemin, hm. Not heard of that before... [15:41] smb: the g15daemon is for the display, that in integrated in my keyboard. it shows time and date and other things [15:42] Deem, While I cannot tell what exactly happens this very likely causes the keyboard to go dead [15:43] smb: with 9.10 it works perfectly [15:43] and there i used the g15daemon,too [15:44] Deem, That is a good data point to know. Still either the code there or the infrastructure around it can have changed [15:45] smb: the package g15daemon is also in the universe repo [15:45] maybe its one of the extensions for the daemon that causes the problem [15:46] i dont have installed all off the plugins for it under karmic. now i have all plugins integrated... i'll try without the extensions and only with the daemon, mybe it solves the problem [15:49] smb: if i start the g15daemon with debug ill get this http://paste.pocoo.org/show/215281/ maybe theres a problem with the library under lucid [15:49] That sounds like a useful debugging step. I am not sure whether the usb_kill_urb in the backtrace is called as a part of the lockup or as a result of it. Overall it sounds like some usb communication locks up and probably because the daemon keeps the device open it will be reused whenever it is re-connected and still stays in the locked state [15:50] erm.. ok.. sudo helps :D [15:50] now the daemon runs in debug [15:51] i'll do the same like a few hours ago. if it dies again i look what the debugging says and tell it to you, ok? [15:51] Deem, Is the old one (PID 911) still hanging around? [15:52] Deem, Ok, also answers sort of my last question. :) [15:52] smb: it was there, yea. i killed it with "sudo g15daemon -k" [16:04] smb: it happend again, but nothing in the debugging msg of the g15daemon [16:05] Deem, *sigh* probably not expected that it can tell when it is about to get locked up. [16:06] Deem, Was this with the new plugins removed? [16:07] smb: yes. its only the daemon [16:10] Deem, So its either changes in the daemon (if there were any) or maybe something changed around the used ioctls in the kernel. I wonder whether stracing the daemon would reveal anything... [16:10] stracing? [16:10] sry, my english is not so good =) [16:11] sudo strace g15daemon [16:11] its producing a lot of output [16:12] yes. "lot" is the right word :D [16:12] but the last line(s) when it hangs would be what syscall locks up [16:12] you mean "socket" "connect" and "sendto" ? [16:14] i think i just paste it http://paste.pocoo.org/show/215295/ [16:15] Deem, already locked up again? [16:15] erm.. no [16:15] should i do this when its looked up? =) [16:16] * JFo goes to try and eat [16:16] Heh, actually it might be good to attach to its pid after it has gone into the background. Doh!. That would be sudo strace -p . And then, yes wait what would be the last thing when the keyboard locks. [16:18] maybe its an issue if the daemon is running by the user "nobody" ? [16:19] imo that would either be an immediate fail or does not matter [16:31] apw: or any of the other sysadmins for zinc dir-fixing [16:37] ogasawara, not sure what they are asking for here, but thought I'd show you: bug 493156 [16:37] even though it is "WONTFIX" [16:37] Launchpad bug 493156 in linux (Ubuntu) "Please enable CONFIG_TASK_DELAY_ACCT (affects: 26) (dups: 3) (heat: 70)" [Wishlist,Won't fix] https://launchpad.net/bugs/493156 [16:37] JFo: I'll take a look [16:38] JFo, this config option has run time impact which we deemed unacceptable [16:38] tgardner, I was sure there was a reason, but I didn't want their complaint to go unanswered [16:38] and I have no idea what the config is for [16:38] :) [16:39] thanks for giving it a quick once over ogasawara [16:39] IIRC the code does some math for each task switch [16:39] I think my calendar is messed up for some reason, how many hrs do you have on your calendar for the meeting? so that I can fix it... [16:48] manjo, how many would be one. start is 5pm UTC (whatever that means for you) [16:51] Trying to create KERNEL/debian/control with kernel-wedge, but it dies with: kernel-versions: No such file or directory at /usr/share/kernel-wedge/commands/gen-control line 22 [16:52] Do I need to setup some environment variables or such? [16:52] lag, do you have kernel-wedge installed ? [16:52] Yes :) [16:52] Half way there [16:52] morning [16:53] lag, try 'fakeroot debian/rules clean' first [16:54] Same error [16:54] This kernel comes from a brand new clone [16:54] lag, lucid ? [16:55] *and branch [16:55] Yes [16:55] ti-omap branch (or head) [16:56] kernel-versions minssing classically means you didi not clean the tree with fdr clean [16:56] if you think you did fdr clean, then could you see if you have a kernel-versions file anywhere in debian* [16:57] apw, he's doing armel, so you also need to specify an arch IIRC [16:57] fdr clean arch=armel [16:57] hmmm [16:57] never did that [16:57] _and_ have the cross compile tools installed. [16:57] ./debian.ti-omap/d-i/kernel-versions [16:57] i prolly always build in a chroot, and fdr clean in the chroot [16:57] smb: and now it happend again, bit i cant strace the deamon cause i cant type in my sudo password :D [16:58] apw, what chroot has arch==armel ? [16:58] lag, where did you try and build it [16:58] tgardner, i use an i386 chroot, with some env mangling [16:58] I don't have the fdr script yet [16:58] echo "Setting environment for armel cross-compile" [16:58] export CROSS_COMPILE=arm-none-linux-gnueabi- [16:58] export PATH=$HOME/toolchains/arm-2009q1/bin:$PATH [16:58] export DEB_BUILD_ARCH=armel [16:58] apw, bad boy [16:58] export DEB_HOST_ARCH=armel [16:58] I haven't tried to build anything yet [16:58] Does the kernel-wedge command insinuate a build? [16:59] lag, fdr is an alias that we all use as shorthand. it refers to 'fakeroot debian/rules' [16:59] k [16:59] clean insinuates a lots of building of required files [16:59] kernel-wedge is used when processing the debian installer bits under the d-i directory [16:59] but if you arn't trying to build, what produces the error [17:00] tgardner, apw I don't use any armel chroot for the source package processing. And it used to work [17:01] I guess I'd better install my cross-tools at some point then [17:01] yeah i just use the i386 chroot to do source builds normally [17:01] never had any issues that i know of [17:01] And lucid does not sufffer from stabe debian/debian.env that used to cause some trouble [17:01] I'm just trying to create the 'control' directory [17:02] I'm not at the compile stage yet [17:02] debian/control is made by fdr clean [17:02] control should be a file, no? [17:02] or do you mean something else [17:02] # [17:02] # ONE HOUR TO TEAM MEETING IN #ubuntu-meeting [17:02] # [17:02] smb: A directory I think? [17:02] Deem, Naturally I meant attach to the daemon _before_ it hangs... :-P [17:03] smb: thats the problem i dont know when the daemon is going to hanf [17:03] hang* [17:03] Deem, You can just let the strace run and wait. Ok, the output is a bit mind blurring but you could minimize the window [17:03] crap apw, I don't have the metrics pulled together [17:04] good job you have an hour then :) [17:04] JFo, I haven't prepared either. Yet [17:04] smb: i cant let the strace run. it terminates always [17:04] sigh [17:05] Deem, Even if using the -p variant? [17:05] apw: Do we have cross-tools available, or should I build my own? [17:05] smb i bet its a deamon so you need to use the follow thing, strace -f [17:05] smb: ive only got this Process 1273 attached - interrupt to quit [17:05] pause( [17:06] Deem, try starting it strace -f [17:06] apw, Or isn't pause jaust the daemon waiting [17:06] apw: with -f it gives allways the same output [17:06] pause would be wait8ing for a signal, which implies its waiting for a child i suspect [17:06] again and again [17:07] which is probabally the child being a piece of crap and polling all the time [17:07] Deem, That is called polling. :P [17:07] polling? [17:07] Deem, what does the g15 daemon do, just allow you to update the screen part of the keyboard? [17:07] ie if its not running can you type? if so have you tried running without it for some time to see if that is the trigger? [17:08] apw: its for the plugins. it makes an clock on my lcd :D [17:08] smb, where are you link KernelTeam/StableHandbook/UpstreamStableReview from? [17:08] an no. i doesnt tried without it [17:08] gonna link* [17:08] well first test should be to turn that off and confirm its that that breaks things [17:08] then at least we can file a bug on the right thing [17:08] tgardner, To the non-existent-yet StableHandbook and that somewhere into Team docs [17:09] smb, good, just so long as I can find it without having to search the name space [17:09] apw: ok. i killed the daemon. [17:09] it seems likely this will be the cause [17:10] tgardner, No, its just that I started sort of bottom up [17:10] you don't happen to have another keyboard lying about do you? a usb one? you could add and see if that one continues past the failure mode -- a next step once confirmed that no hangs without daemon [17:10] apw: maybe. but then something should be different from lucid to karmic. because on karmic it works properly [17:10] apw: sry. got no other keyboard [17:10] Deem, right, yuo have about 20k differences between the two [17:11] knowing exactly which bit cuts it down [17:13] Deem, you may find you need to find a friend either to borrow a keyboard or to borrow their machine to login from to diagnose this further ... but do confirm the daemon not running works [17:13] apw: but, when the daemon is the problem. how would you find out, which difference will harm the daemon? [17:13] well the daemon itself has changes from karmic to lucid, so that is suspect one [17:13] g15daemon | 1.9.5.3-3 | karmic/universe | source, amd64, i386 [17:13] g15daemon | 1.9.5.3-8ubuntu1 | lucid/universe | source, amd64, i386 [17:14] Deem, That was the intention of letting it follow the trace === cking-afk is now known as cking [17:14] smb: Did you read my email? :) [17:14] Deem, It should at least give a hint what the daemon did last [17:14] abogani, email, I guess no [17:14] Oh, actually yes [17:14] darn [17:15] abogani, the answer is looks good [17:15] smb: but when i start a strace with -f it attaches 6 processes [17:15] abogani, sorry [17:15] smb: Don't mention it! Thank you instead! [17:17] smb, i wonder if he could boot back to the karmic kerenl if its still there as a test later too [17:18] Deem, This would be 6 childs that the daemon has forked (or threads)... If this are real childs, you see multiple g15daemons in "ps ax|grep g15daemon" ? [17:18] smb: no, theres only 1 g15daemon [17:18] then I guess those are threads oly [17:19] only [17:20] Deem, ps -efT | grep g15daemon [17:20] Well I guess first running without the daemon. This will prive it is the daemon [17:20] how many does that list [17:21] right, that has to be the first test, can you get 5x the normal time without it [17:21] Deem please record everything you test and the outcome clearly in the bug [17:22] apw: what bug? o.O [17:22] * apw suggests we ignore you until you have one :) [17:22] Deem, The one you will open [17:22] file one against g15daemon i recon [17:23] ah... ok. then i will do this. but i think i should wait if it happens again without the daemon, then its not the daemon who causes the error =) [17:24] you can move the bug from g15daemon to something else once you find out it is something else no problem [17:24] but with a bug there you can record these facts as you discover them, i bet you have forgotten the first ones already ... i know i have [17:25] apw: no. i dont think i forgot it :D im logging all channls so i have the msg from tail :D === kamal-away is now known as kamal [17:33] # [17:33] # meeting in 30 mins in #ubuntu-meeting [17:33] # [17:33] apw: smb: do you want the bug id? [17:33] Deem, sure [17:33] 582352 [17:34] bug 582352 [17:34] Launchpad bug 582352 in g15daemon (Ubuntu) "keyboard dies when using g15daemon (affects: 1)" [Undecided,New] https://launchpad.net/bugs/582352 [17:35] smb, have a look at the syslog, did you know about these backtraces : [17:36] apw, If those are the same I saw them earlier. It is obvious that the daemon is stuck. Did not seem to be obvious where and whether its the only problem [17:44] * psurbhi quitting for today.. have to run to a dr [17:55] # [17:55] # 5 mins to meeting in #ubuntu-kernel [17:55] # [17:57] apw: is the meeting here or #ubuntu-meeting then? [17:58] #ubuntu-meeting [17:58] <- tool [17:58] !apw /query location meeting [17:58] smb: Error: I am only a bot, please don't think I'm intelligent :) [17:59] smb: i am only a tool, expect nothing useful === jjohansen1 is now known as jjohansen [18:18] * JFo is gonna go to sleep now. I need to take some meds and rest methinks [18:19] JFo: take care, that ubuflu sucks [18:19] * ogasawara tucks JFo into bed [18:19] smb, if you have a wiki on sru policy can you please add a link to the https://wiki.ubuntu.com/KernelTeam/KnowledgeBase ? [18:19] thanks ogasawara :) [18:19] thanks jjohansen [18:19] this sucks === JFo is now known as JFo-afk [18:19] * cking thinks JFo burnt himself singing at the end of UDS [18:19] I think so too cking [18:20] manjo, There is one I will point to you as soon as I find it again [18:20] smb, sure I can add a link to the https://wiki.ubuntu.com/KernelTeam/KnowledgeBase [18:20] * cking grabs some food and ponders on a msleep() hang [18:21] cking->food->msleep() [18:21] apw: bug 571980 confirms that re-enabling KMS for i855 allows the reporter to boot successfully once again. I presume we're suggesting these reporters use the workaround rather than us backing out the blacklist patch. [18:21] Launchpad bug 571980 in linux (Ubuntu) "crash on boot with kernel 2.6.32-21 (affects: 1) (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/571980 [18:22] apw: when doing work items is there a way to do conditional items. ie. only do this item if investigation/testing of item X fails? [18:22] no there is no way to express that, i would say just add them and they go DONE if they arn't needed [18:23] manjo, Its is linked though not obvious. https://wiki.ubuntu.com/KernelTeam/KernelUpdates And probably needs more explicitely mention bug fixes at the beginning [18:24] manjo, But its contained in the "make it available in upstream stable" [18:25] smb, probably needs a new wiki [18:26] ie cut & paste info [18:26] * smb hands manjo the task [18:27] manjo, But serious, yes. I already thought of that being part of the new things I do [18:27] Especially as I need minutes to dig through to it everytime [18:28] smb, I can put together a page from the 2 pages you pointed me to and you can fix it up ? [18:29] smb, coz it really bugs me everytime I look at a bug and I need to figure out if will make sru or not ... if not what I need to do ... if it does what is the process .. [18:29] often I am wrong .. [18:29] cnd, can one make ftrace start tracking function calls once it's hit a specified function? [18:29] cking: yep! [18:30] woot [18:30] say the function is "blah" [18:30] echo ":blah:traceon" > /sys/kernel/debug/tracing/set_ftrace_filter [18:30] I think that's right [18:30] sweet [18:30] you can cat set_ftrace_filter and it will tell you if it set it properly [18:30] manjo, Thanks. Though atm I only remember me pointing you at one. And probably I should rework it better and not only merging two pages. [18:31] cking: it's an undocumented functionality, but I sent a patch upstream to add it to the docs, and I assume it will make it into .35 [18:32] manjo, Assume for the moment SRU is allowed for real bugs which have a lp report. And the preferred way if not critical is to go via stable [18:33] cnd, no wonder I could not see it in the docs [18:33] cking: this is where I tried to send a patch upstream to turn off tracing when you hit schedule_bug and other bugs [18:34] and I got smacked down when it was pointed out that the functionality already exists [18:34] though no one bothered to note how to find the functionality [18:34] * smb feels a little flu-ish too, atm. Guess I call it a day [18:35] * cnd feels like the last man standing... [18:35] time for some lunch me thinks [18:36] cnd, I'm getting Invalid argument on that, does it work on 2.6.32? [18:37] cking: it should [18:37] let me find the upstream docs :) [18:38] cking: http://git.kernel.org/?p=linux/kernel/git/rostedt/linux-2.6-trace.git;a=blob;f=Documentation/trace/ftrace.txt;h=557c1edeccaf72535464298743cddd3c8eb01bea;hb=refs/heads/tip/tracing/core-6#l1830 [18:39] cking: looks like it should be: 'blah:traceon' [18:39] cnd, yep - that matches the docs and works too [18:39] ta [18:51] cnd, seems to fail on my kernel when coming out of S3 with the console still blank. Oh well, you never know until you try [19:06] cking: rats... [19:07] cnd, no worries - I will fall back to my devious tricks [19:54] * cking calls it a day === rsalveti_ is now known as rsalveti [21:47] Hello. I can't find any lucid packages of kernel sources with ubuntu patches applied on http://kernel.ubuntu.com/~kernel-ppa/mainline/ . There is just dummy package (size 2.2Kb). Where can I get 2.6.34 kernel source with ubuntu patches applied? [21:50] braintorch: do you need lucid (ie 2.6.32 based) or maverick (ie 2.6.34 based) ? [21:51] braintorch: you can find the git repo's for either at http://kernel.ubuntu.com/git [21:52] oh. Thank you. I completely forgot about git. [21:53] braintorch: I should clarify maverick is currently 2.6.34 based but we'll be rebasing to 2.6.35 for final === kamal is now known as kamal-afk === TheMuso` is now known as TheMuso === kamal-afk is now known as kamal