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