[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.  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.  :-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 |  <IP_ADDRESS>-3 | karmic/universe | source, amd64, i386
[17:13] <apw>  g15daemon | <IP_ADDRESS>-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


[00:55] <dashua> nicee
[02:52] <verb3k> In checkinstall, what does the --backup option do exactly?
[05:56] <psusi> if there is a bug in the toolchain, what should it be filed against?  gcc?
[05:59] <persia> psusi, Depends which part of the toolchain :)
[06:00] <psusi> I *THINK* it's ld
[06:00] <psusi> I filed this bug all the way back in 2005 and it has not gotten any attention yet the problem has actually grown worse... I think it's because I never targeted it at a specific package.  bug #24692
[06:01] <psusi> in maverick it seems we now have a default alighment of 2 mb, not just 1
[06:03] <persia> psusi, Might track down whoever uploaded the alignment change.
[06:03] <psusi> I don't even know where the setting is ;)
[06:03] <persia> Might be nobody else does, hence the uncommented bug report :)
[06:04] <psusi> hehe... maybe I check the logs and see who usually uploads gcc... someone has to be an expert on it ;)
[06:05] <ebroder> Ugh. We need a duplicate bug finder for dkms failures
[06:06] <ebroder> I'm up to...37 dupes of this fglrx bug?
[06:13]  * psusi is glad he doesn't use fglrx anymore.... hooray open source drivers!
[06:14] <persia> ebroder, I think the bugsquad has something called "recipes" that helps merge mass-duplicates.  Ask someone in #ubuntu-bugs.
[06:14] <persia> I strongly believe it's harmful to claim bugs are duplicate without deep information.
[06:15] <ebroder> Deep information? What do you mean? I'm reading the description (making sure they're installing fglrx, whether they know it or not) and checking the build log to make sure it's the same build error
[06:16] <micahg> ebroder: the Ubuntu X team likes a separate bug for each piece of hardware
[06:16] <persia> It's the making sure it's precisely the same error because one understands how the software works that is the deep information to which I refer.
[06:16] <persia> micahg, Only where it's hardware-specific (and it very often is)
[06:16] <micahg> persia: right and unknown = don't dupe
[06:16] <ebroder> persia: I'm fairly confident on this one - the build-logs look *identical* with the exception of timestamps and l10n
[06:17] <ebroder> And it's a build error - how can it be hardware specific?
[06:17] <ebroder> (the bug I'm using as a parent for everything is bug #642518)
[06:17] <persia> I don't mean to criticise your desire to duplicate them: I'm uninformed, and presume you to be informed.
[06:17] <micahg> ebroder: same with me, just providing info here
[06:18] <persia> I mean to explain why I think it's a good idea for the reporters to have filed the duplicates in the first place, and point you at a resource so you can clean up more easily.
[06:18] <ebroder> persia: I understand; sorry for getting defensive. I did probably jump in a bit aggressively, but this bit me indirectly, and seemed like something I could take care of
[06:18] <persia> So, please, mark them as duplicates.  You may find "bug recipe"s useful in doing so.
[06:18] <ebroder> I think I've got them all by now, but I'll keep that in mind next time :)
[06:18] <persia> No worries.  Just wanted to make sure we understood each other :)
[07:19] <ebroder> Ok, this sucks. The security update made compat_alloc_user_space GPL-only, when it wasn't before
[13:13] <mdke> grateful if a release team member could have a look at / approve ubuntu-docs 10.10.3 when convenient
[14:17] <lucidfox> Okay, bug #615300 just feels like one slap in the face too many
[14:17]  * lucidfox considers filing "Evolution should *not* have a default signature enabled"
[16:23] <ScottK> ebroder: Sounds like a bug that should be reported and brought to the attention of the security team.
[16:49] <kees> ebroder: are you on maverick or an earlier release?
[16:58] <ebroder> kees: Lucid. The issue is that the new compat_alloc_user_space is EXPORT_SYMBOL_GPL, while it used to be an inlined function declared in a header
[16:59] <ebroder> And that's breaking fglrx - bug #642518
[16:59] <ebroder> I have a fix, although I don't really like it, and I want someone more familiar with fglrx than me to pass judgement before I start pushing for sponsorship
[17:01] <kees> ebroder: okay, thanks. this is a bug in the kernel update and we'l get it fixed asap; sorry for the glitch!
[17:02] <ebroder> kees: Hmm, really? Are you guys allowed to decide that the symbol should be exported to non-GPL modules? I thought there was legal mumbo-jumbo surrounding all that
[17:03] <kees> ebroder: it's a backported fix; it just wasn't backported correctly. it'll still be a problem for maverick.
[17:05] <ebroder> Ok, great. fglrx will still need a patch, because it's looking for the function in the wrong header file, but that's easier to deal with
[17:18] <ebroder> kees: Do you want me to file a bug about this?
[18:29] <kees> ebroder: I think the existing uninstallability bug is enough, but thanks!
[19:49] <lucidfox> So
[19:49] <lucidfox> is bug #615300 going to be set to something other than "Fix Released" and reopened for discussion?
[19:52] <fagan> lucidfox: I presume there will be more talk tomorrow about it when the canonical crowd are around
[20:01] <vish> lucidfox: hmm , did anyone test the change?
[20:01] <vish> i need to use evolution in Maverick
[20:05] <lifeless> wheee
[20:05] <lifeless> thats a fun bug :P
[20:08] <fagan> lifeless: ill check it
[20:10] <fagan> its not showing up on the bottom of my messages
[20:11] <fagan> I sent a few messages today but its not showing up
[20:11] <vish> fagan: might it just be a preference ?
[20:11] <lifeless> AIUI its in your signatures lists you can choose from
[20:11] <fagan> maybe
[20:11] <lifeless> so you can turn it on
[20:11] <lifeless> and for new accounts it may default on
[20:11] <vish> something that the user can change if they want
[20:11] <fagan> yeah its for new accounts
[20:12] <vish> it seems to be another huge fuss over nothing.. or just  a preference but need to actually check it in action though ;)
[20:12] <lifeless> it is minor; I don't really see the point though.
[20:12] <lucidfox> Making this default for new account would be a huge mistake.
[20:12] <lucidfox> No it's not minor
[20:12] <fagan> Well id like the wording to be a lot better
[20:12] <lucidfox> it's a recurring pattern
[20:12] <fagan> thats all
[20:12] <lifeless> lucidfox: snarfing passwords and mailing them to me would be major
[20:12] <vish> lucidfox: is it not possible to change it?
[20:12] <fagan> I dont mind it in there I just dont like the wods
[20:12] <fagan> words
[20:13] <vish>  to me it just sounds like using @"gmail"
[20:13] <lucidfox> It's possible. I still don't like this being by default. And I don't like Canonical forcing a closed-doors decision on the users yet *again*.
[20:13] <vish> but i wouldnt use it though .. i'd just change it to what i want to use..
[20:14] <fagan> well lucidfox they are a private company they dont really have to run most things past the community
[20:14] <fagan> its hard to dictate to someone thats giving you stuff for free
[20:15] <lucidfox> If they care about their reputation, yes they need to cooperate with the community at large
[20:15] <vish> lucidfox: so how to communicate?
[20:16] <vish> lucidfox: the bug was a public bug..
[20:17] <lucidfox> It wasn't. It went from filing to implementation in the span of... less than a day, I think. And by the form it was posted, it seems it was already decided behind closed doors by then.
[20:17] <vish> lucidfox: why do people always assume the worst? :)
[20:18] <lucidfox> I'm just judging by the history of Canonical's prior initiatives
[20:19] <lucidfox> Rick Spencer filed the bug, then Sebastien Bacher almost immediately assigned it to the beta milestone. Then a package was uploaded implementing it, with no comments in between.
[20:38] <fagan> lucidfox: well it might have been talked about on IRC beforehand
[20:42] <avi__> Hey guys, so I've written this cool app in PyGTK and Glade. How can I package this up and distribute it?
[20:42] <luca> hi everyone
[20:43] <fagan> avi__: you should ask that on #ubuntu-app-devel
[20:43] <avi__> awesome, will do. thanks!
[20:44] <luca> I would need some help, but none is available in @ubuntu+1 currently .. maverick, kernel 2.6.32-23 (latest) refuses to install
[20:45] <luca> currently I am without a workable kernel installed. Anyone with the same problem?
[20:46] <micahg> luca: maverick should have a 2.6.35 kernel unless this is special hardware
[20:46] <luca> sorry
[20:46] <luca> 2.6.35
[20:47] <luca> misspelled the kernel name
[20:47] <luca> there seems to be some problem in the transition between 2.6.35-22 to 2.6.35-23
[20:47] <luca> wondering if someone was having the same problem, maybe a fix.
[20:48] <mdke> lucidfox: I agree with you, thanks for raising it
[20:48] <ebroder> luca: Are you using proprietary drivers?
[20:48] <ebroder> There's a known bug compiling fglrx against the most recent Lucid and Maverick kernels
[20:49] <luca> broadcom for wireless, but it is not installed right now
[20:49] <ebroder> Ok, never mind, then
[20:49] <luca> (I know about the bug, I have been without fgrlx for some days now)
[20:58] <avi__> _is
[21:21] <kklimonda> lucidit would make more sense to bring this subject to u-d-d instead. Most developers don't ead forums nor use IRC at sunday.
[21:21] <kklimonda> meh
[21:21] <kklimonda> great, she's gone...
[21:22] <kklimonda> anyone else cares about it enough to raise it on ML? ;)
[22:34] <YokoZar> did ulimit -n change in maverick? It seems to be way too low 1024, iirc we had it much higher in previous releases
[22:47] <rishi> I have a stripped down Ubuntu 10.04 which I am using as an appliance for collecting behavioral data for research. Part of it involves recording audio/video from an USB camera. The recording is initiated from an initscript. Now I find that if I am not running a desktop, ALSA finds plughw:1,0 to be busy. The open system call reports EBUSY. It looks like something changed in 10.04's boot sequence which is causing this.
[22:48] <rishi> I ran a quick test on Ubuntu 9.10 and Fedora 13 and they seemed to be fine.
[22:48] <rishi> Can anyone suggest what might be going on?
[22:49] <rishi> I have run lsof, etc. on almost everything imaginable and there is no other process using the device.
[22:49] <rishi> Now the funny part is that if I try to record manually, ie. log in and then use a shell, then everything is fine.
[23:57] <bdrung_> doko: no time and no clue for fixing bug #643107.
[23:58] <doko> bdrung_: modularizing the ant script might help


[07:06] <Montresor> mitya57: I did a thing, https://salsa.debian.org/python-team/packages/python-secretstorage/-/merge_requests/3
[07:07] -ubottu:#ubuntu-devel- Merge 3 in python-team/packages/python-secretstorage "d/control: Update dbus depends, dbus → dbus-session-bus." [Opened]
[07:07] <Montresor> ...Then forgot about it, but details.
[08:12] <mitya57> Unit193: wrap-and-sort'ed and merged
[08:13] <Unit193> Thank you!
[08:14] <mitya57> Thank you :)
[08:16] <Unit193> I think this was the last blocker on one server for dbus-broker, if I so choose. :3
[11:13] <tobikoch> I wonder it there is a problem with the jammy docker images? I don`t seem to be able to do an apt-get update because something is amiss with the apt keys.
[11:20] <athos> tobikoch: would you mind filing a bug on https://bugs.launchpad.net/ubuntu-docker-images? It would be nice to include the image ID and your container runtime setup there (where are you running it from, docker version, etc)
[11:21] <tobikoch> Ah, I see, I need a more recent Docker.
[11:21] <tobikoch> athos: found this https://stackoverflow.com/questions/72624687/apt-get-update-fails-on-ubuntu-22-base-docker-image I'm running the Docker from Debian Bullseye.
[11:22] <tobikoch> I wasn't planning on upgrading, it's a bit annoying but apparently not Ubuntu's fault :)
[11:37] <tobikoch> Oh, blimey, this machine is still running Buster...pardon!
[12:00] <tobikoch> Everything is just fine on Bullseye, sorry again.
[12:37] <athos> tobikoch: good to know everything is fine :) I have seen ppl with that issue a bit often, but no one filed a bug yet. Thanks for the url :)
[13:39] <rbasak> utkarsh2102: hi! Do you expect to be able to get to https://bugs.launchpad.net/ubuntu/+source/tmux/+bug/1976110 soon please, or should we unassign it and see if someone else on the server team can take it?
[13:39] -ubottu:#ubuntu-devel- Launchpad bug 1976110 in tmux (Ubuntu Jammy) "`tmux -d -x ... -y ...` does not respect sizing" [Medium, Triaged]
[16:55] <jdstrand> rbasak: hi! when are the images in https://hub.docker.com/_/ubuntu updated? I can't remember and I don't see anything in https://wiki.ubuntu.com/SecurityTeam/UpdatePublication (I asked someone from the security team who also didn't know)
[19:19] <rbasak> jchittum: ^ maybe you know?


[04:32] <cancer> can any one help me contributing to Ubuntu ? I wanna start fast and fix some bugs
[04:34] <pangolin> cancer: join #ubuntu-bugs and start asking questions in there, also check the topic there should be links with info to get you started
[04:35] <pangolin> patience is a requirement :)


[21:06] <mobile-mech> exit
[21:06] <mobile-mech> exit
[21:06] <mobile-mech> exit
[22:57] <mobile-mech> whats good yall?
[23:03] <mobile-mech> join #asahi
[23:47] <cmaloney> not much. just sitting downto try playing a game of Ironsworn (ironswornrpg.com)


[03:05] <zul> hey
[04:31] <milosz> damn i keep getting a SharingViolation when I try to create XmlTextWriter
[04:31] <milosz> even tho i explictly make sure to Close the text reader I was using before
[04:37] <milosz> lol wrong channel
[06:22] <bernard_> does anybody have any thoughts about vesafb-tng? (ie, good idea, bad idea, ugly code)
[06:56] <stefg> I'm suffering from a bug in the recent kernel which (stupidly) waits for a nonexisting medium in my dvd-drive at boottime. Is there some ubergeeky clever boot-parameter to override that?
[06:56] <stefg> (2.6.15-25-k7)
[09:02] <crimsun_> gah, missed Ben.
[09:02] <crimsun_> flight delay/cancellation is no fun


[01:27] <teward> are quilt patches allowed to modify items inside the debian/ folder or is that a nono
[01:29] <Noskcaj> teward, Why would you?
[01:30] <teward> Noskcaj: the fix for LP Bug #1264674 is to modify a third-party module inside the debian/ folder (nginx)
[01:30] <teward> i have an upstream diff (from Debian) that fixes this for the nginx-extras module, but the question is do I manually modify it or have it as a quilt patch
[01:30] <teward> s/modify it/apply the patch/
[01:31] <teward> (it's rare I have to touch the third-party modules :/)
[01:31] <Noskcaj> I'm guessing it's allowed to patch, debian-mentors is usually best for these questions though
[01:31] <teward> well, i'll see if debuild whines.
[01:31] <teward> it occasionally does that
[01:31]  * teward shrugs
[01:33] <cjwatson> I think you can probably modify files under debian/ in quilt patches in theory, at least with some source formats, but it's really really confusing and you shouldn't.
[01:34] <cjwatson> I would expect any sponsor who's paying attention to kick that back to you.
[01:35] <teward> cjwatson: that's what i thought, but it's been a while since i messed with the third-party modules in nginx, I can prep a debdiff for either, then if the sponsor wants to kick back the "This modifies debian/..." thing at me there's an alternate debdiff
[01:35] <teward> I have a feeling rbasak is keeping an eye on the bug, but I might be wrong.
[01:36] <cjwatson> I would recommend just preparing the one with the files under debian/ changed directly and not in quilt, rather than wasting a sponsor's time
[01:36] <teward> meh, that's equally easy
[01:36] <cjwatson> It's the right thing to do.  Conceptually the quilt patch series should apply to the upstream tarball without debian/ even there.
[01:37] <cjwatson> Tools such as git-dpm would probably fail if that weren't the case.
[01:39] <teward> yeah, makes sense.
[01:39] <teward> in other news, thank god I can have amd64 AND i386 builds within sbuild, it prevents me having to use the PPA builders to build-test things. ^.^
[08:14] <dholbach> good morning
[09:10] <rbasak> teward: the debdiff in bug 1264674 looks fine.  When should I write a test case for a bug? What if I don't see a "test" folder for a package?
[15:53] <rbasak> fully_human: when it would be useful. On a bug-by-bug basis, I'd say. Do you want to describe the bug to get a more helpful response?
[15:54] <fully_human> An inkscape bug where a color swatch contains an incorrect color. Inkscape does not have a "test" folder already.
[15:55] <fully_human> But I suppose test folders can be per-branch and the package maintainer will just apply the patch without the test. :-|
[15:55] <rbasak> Ah. I'm not sure about desktop bugs, sorry. Perhaps a test case that a human can follow will do.
[15:55] <fully_human> So a little note with the patch saying "See what you expect? This is what the patch returns!"
[15:56] <rbasak> Are you talking about a test case for an SRU?
[15:57] <fully_human> SRU?
[20:41] <fully_human> Sorry, I'm really confused here. I've seen three or four different tutorials on fixing a bug on Ubuntu/Launchpad and they all seem to say different things. For example http://packaging.ubuntu.com/html/fixing-a-bug-example.html has me create a new branch while http://packaging.ubuntu.com/html/fixing-a-bug.html just tells me to create a patch, edit it (should I do it before or after `patch`?) and export to a patch.
[20:43] <Noskcaj> fully_human, The simplest way is just make a patch however you think and submit it to a launchpad bug
[20:44] <fully_human> So it's all about diffing...how I go about it is up to me.
[20:44] <fully_human> Maybe I should write something about that in the docs so no one else is confused. :-\
[20:53] <rbasak> fully_human: personally I find a debdiff the easiest. Prepare the new source package you're proposing, and then attach the output of "debdiff <old_dsc> <new_dsc>".
[20:53] <fully_human> Thanks. :)
[20:54] <fully_human> So, basically I can do: 'cp -R foo foo-bug-1', edit some file in foo-bug-1, then do a 'debdiff foo foo-bug1' ?
[20:55] <fully_human> And I assume debuild -S and pbuilder just make a debian I can test?
[20:56] <jtaylor> the non vcs apparoch is: quilt add <files you want to edit>
[20:56] <jtaylor> edit them
[20:56] <jtaylor> quilt refresh
[20:56] <jtaylor> dch -i, write changelog
[20:56] <jtaylor> debuild -S; debdiff old-dsc new-dsc
[20:56] <jtaylor> oh quilt new <patch-name> first
[21:04] <fully_human> When I do debdiff, should I be one level up from the package directory?
[21:04] <jtaylor> doesn't matter it just needs two dsc
[21:04] <jtaylor> after debuild they are usually in ../
[21:05] <fully_human> And so debdiff will automatically try to find them?
[21:05] <jtaylor> no you need to tell it the path of the dsc
[21:05] <jtaylor> it will find the rest by itself
[21:05] <fully_human> Oh, yeah, I suppose since you said "old-dsc." :P
[21:06] <jtaylor> debuild will create a new dsc if you updated the version with dch -i
[21:06] <jtaylor> see ls ../*dsc
[21:09] <fully_human> Okay, I think I'll just see what happens here...I'm still a bit confused but I think I understand what's going on up until dch -i.
[21:15] <fully_human> Ah, should I test the package before or after I run dch -i?
[21:15] <fully_human> (well, too late because I'm already writing the changelog. :P)
[21:16] <jtaylor> you should do it before you debuild, else you overwrite the old dsc
[21:16] <jtaylor> but its not a big deal just download it again
[21:17] <fully_human> And pbuilder will create the new deb file to install, right?
[21:17] <jtaylor> yes
[21:17] <fully_human> Aha! I think I'm getting it!
[21:17] <jtaylor> debuild can also do it
[21:17] <jtaylor> without -S
[21:17] <jtaylor> you do that to get it right, then test with pbuilder because its slower
[21:18] <fully_human> Yes, I discovered this. o.O
[21:19] <jtaylor> there are many tricks to speed up pbuilder
[21:20] <jtaylor> using eatmydata, special buildplace mountoptions, using apt-cachers etc
[21:20] <jtaylor> worth looking into when you do more packaging work
[21:20] <fully_human> Hm...yelling at my computer (expletives included) didn't help...
[21:20] <fully_human> Your suggestion will probably work better. :)
[22:43] <fully_human> Which makes sense, because installing modified binaries. Any way to reset the build?
[22:44] <fully_human> So I tested my patch. It tried doing `debuild -S` to generate dsc files, but I got a bunch of errors like this one: dpkg-source: error: cannot represent change to share/extensions/Barcode/__init__.pyc: binary file contents changed
[22:44] <fully_human> dpkg-source: error: add share/extensions/Barcode/__init__.pyc in debian/source/include-binaries if you want to store the modified binary in the debian tarball
[22:44] <fully_human> Which makes sense, because installing modified binaries. Any way to reset the build?
[22:44] <jtaylor> hm that means the clean target of rules does not do what it should
[22:44] <jtaylor> that is an unfortunate annoyance
[22:45] <jtaylor> the easiest way around this is to use version control to reset the build
[22:47] <jtaylor> without that you could extract a new copy and apply your debdiff on it
[22:47] <jtaylor> or fix the clean rule for testing (and file a bug in debian)
[22:53] <fully_human> Even when I do a bzr revert I get the same debuild errors (or does bzr revert revert back to *my* patch?). I must be doing something wrong.
[22:53] <jtaylor> bzr clean-tree
[22:53] <jtaylor> make sure your patch is commited first
[23:14] <fully_human> With 'bzr commit'?
[23:14] <jtaylor> bzr add <file>
[23:14] <jtaylor> bzr status will show you what willb e commited
[23:14] <jtaylor> it should only be stuff in debian


[04:49] <mhall119> is this a good channel for asking Unity Lens development questions?
[15:02] <birdman_> Hello
[15:04] <birdman_> Is there anyway to make the launcher bar ignore all the other workspaces?
[15:04] <birdman_> Actually nevermind, this is the wrong place to ask that.
[15:04] <birdman_> Sorry
[18:30] <MaMaGoody> hi, can I use unity-2d-launcher icons as dock app? is it possible to map an x window or paint it with app?
[18:33] <MaMaGoody> hmmm I think so, as update manager can do it
[18:37] <MaMaGoody> Is it good to update the content intensively ?
[18:37] <MaMaGoody> like a clock application
[18:39] <AlanBell> MaMaGoody: there is a progress indicator on it you can update
[18:40] <MaMaGoody> AlanBell: ah, thanks.
[18:40] <AlanBell> https://wiki.ubuntu.com/Unity/LauncherAPI
[18:40] <AlanBell> and a count
[18:41] <MaMaGoody> very kind of you, thanks a lot.
[18:44] <MaMaGoody> bye.