[07:46] <amitk> morning
[07:47] <lag> Morning
[07:50] <abogani> Morning
[08:10] <cooloney> morning, eu
[08:37] <apw> moin
[08:45] <jk-> hey apw 
[08:45] <apw> hi
[08:59] <ericm_> apw, cking, is smb on vacation this week?
[09:00] <jk-> all of the UK is taking a swap day tomorrow
[09:01] <trapmax> i'm trying to create an lvm-snapshot. my machine just hungs there. here's the kern.log http://pastebin.com/KUzVGZSQ
[09:02] <ericm_> jk-, ok
[09:02] <ericm_> apw, so I have to bug you again
[09:02] <apw> ericm_, smb is in today
[09:03] <ericm_> after mvl-dove branch is rebased, all the tags could possibly be inconsistent with the current history right?
[09:03]  * smb is there
[09:03] <apw> ericm_, the tags are correct in that the point to the tree at the time the release was made
[09:03] <ericm_> morning smb
[09:03] <apw> the release commits in the latest copy of the tree do not correspond to the tags ... but the tags are right
[09:04] <ericm_> apw, yeah - but now the rebased commit isn't
[09:04] <ericm_> I mean the equivalent one, you know what I mean
[09:04] <apw> right ... that is correct, but only the tag matters
[09:04] <ericm_> apw, ok I see
[09:04] <smb> The tags should still be there but point to something not linearly connectect to the releas
[09:05] <apw> you don't use the release commit to find the tree for the release, you use the tag, that is what the release was really made from
[09:05] <ericm_> smb, apw, OK I see
[09:07] <ericm_> smb, one other thing - why don't we just put maint-startnewrelease to replace the fdr startnewrelease?
[09:07] <smb> ericm_, Mostly because I just recently wrote it
[09:08] <ericm_> smb, mostly I much enjoyed using that script :-)
[09:08] <smb> ericm_, Another thing that is a bit of a problem it that those scripts use other libraries in the kteam-tools domain
[09:09] <smb> ericm_, Thanks, I enjoy those too. Take some of the manual labour away
[09:10] <ericm_> smb, ok - I copied the lib directly to my /usr/lib/python, though not sure if that's the right way
[09:11] <ericm_> smb, maybe for the scripts in kernel package, we could just hardcode those libs into the scripts, but that creates maintenance problems :-/
[09:11] <smb> ericm_, From my intention you would just add the kteam-tools/maintsacripts to your PATH and all should work
[09:12] <smb> All scripts look for libraries relative to their own path in kteam-tools/lib
[09:12] <ericm_> Grr.... I copied those to ~/bin, ugly hacks
[09:13] <smb> Hmm, seems its only me that thinks adding a path is much simpler. :-P
[09:14]  * apw notes he mentioned that smb adds that dir to their path ...
[09:14] <smb> apw, That dir? Which one
[09:15] <apw> kteam-tools/maint-scripts
[09:15] <apw> the one you said just now, i mentioned it yesterday when i mentioned the scirpts for doing start new release, which is how he knows about it!
[09:15] <smb> Ah, ok. Understand now
[09:15] <apw> smb, that the scripts don't cope correctly still if you run them directly ... is still annoying, and something i mean to fix
[09:16] <smb> apw Hm, well should be a relative simple fix
[09:16] <apw> yep, should be, just not obthered to look yet
[09:16] <smb> apw, Just that I never saw that much need as I got it in my path
[09:17] <apw> its a proformer fragment of code needed to do it
[09:17] <smb> Because I am lazy and don't want to type the complete path all the time
[09:17] <smb> apw, The problem likely is this needs to go into all scripts looking for a lib
[09:18] <apw> and everything looking for a binary too
[09:18] <smb> Huh?
[09:18] <apw> other binaries called from the binaries (or scripts) needs it too, so i don't have to add the path
[09:19] <smb> Well, thats what PATH is for
[09:19] <apw> but for a small code change it can work both ways and ~/git/kteam-tools/maint-foo/maint-bar
[09:19] <smb> I find it somewhat strange to expect a script or binary will find anything somewhere
[09:19] <apw> will work as expected instread of exploding randomly for some commands
[09:20] <apw> plus actually just using path is dangerous as i could have two versions installed
[09:20] <apw> and get the libraries or binaries from the other one
[09:20] <apw> the tools come as a kit, and should ensure they use the ones from the kit
[09:21] <apw> i am not asking you to do the work, i'll get to it when it next annoys me
[09:21] <smb> apw, Somehow you sound like asking for bulletproof shoes while waving around your gun :-P
[09:22] <apw> smb, its a personal way of working that i use commonly with other applications is all
[09:22] <apw> and its odd that that one does not follow the same rule
[09:22] <apw> i tend to not have random scripts on my path that have low utility, by which i mean i use them seldom
[09:22] <smb> As odd as it is to me that you don't work like me. 
[09:22] <smb> But ok
[09:22] <apw> especially ones which mess arround with the current directory state
[09:23] <apw> as there is inhearnt risk of running the wrong thing and shitting all over what you are doing
[09:23] <apw> so if i am doing a review i can see adding that dir to the path for that session and using lots of scripts for a bit there
[09:23] <apw> but normally to just get one function out of it, i'll just pick it by absolute path
[09:23] <smb> I can try to put in a more robust lookup and you can do the others
[09:24] <apw> as i say, don't feel you need to do anything
[09:24] <apw> i have lots of experience of doing this mod, as i have it in everything i write for the same reason :)
[09:25] <smb> I would do it just once in one script to have a reference for it. Also in case I do more scripts
[09:26] <apw> watch out for the path case, ie there are three cases ./xxx ~/foo/xxx and xxx via path, they all present differenet via $0
[09:27] <apw> in my scripts i typically have a $here which is instantiated from $0 and basically allow me to find everything else .... include $here/../lib/foo $here/oother-binary
[09:27] <smb> I believe there is an abspath which returns the complete path, which I can use instead of getcwd alone
[09:27] <apw> yeah there may even be a python lib fn for finding  'here'
[09:28] <apw> here=`dirname $0`
[09:28] <apw> case "$here" in
[09:28] <apw> *)  here="`pwd`/$here" ;;
[09:28] <apw> esac
[09:28] <apw> is what i do in shell
[09:28] <smb> here = os.path.abspath(os.getcwd()) 
[09:28] <smb> I think
[09:29] <apw> no that is 'here' of the user, not the here of the program
[09:29] <apw> ok a line is missing from that fragment ... cause it starts with a /
[09:29] <apw> damn irc client
[09:29] <smb> right, replace that the path of the program
[09:29] <apw>         here=`dirname $0`
[09:29] <apw>         case "$here" in
[09:29] <apw>         /*) ;;
[09:29] <apw>         *)  here="`pwd`/$here" ;;
[09:29] <apw>         esac
[09:30] <apw> the problem is that $0 is not always fully qualified
[09:30] <apw> it is generally what the user typed, which can be relative
[09:30] <apw> so you have to be sneaky
[09:31] <smb> Hm, so does maint-getabis currently fail for you that way. It seems at least for the libpath I already use abspath
[09:37] <ericm_> smb, hrm... maint-getabis doesn't work with version number like: EE: Ubuntu-2.6.32-206.19foo1 does not seem to be a valid name
[09:37] <ericm_> it's in maint-getabis
[09:37] <smb> ericm_, Did you tag it like that?
[09:37] <ericm_> smb, oh no - let me tag it again
[09:38] <ericm_> smb, now it works
[09:39] <ericm_> smb, hrmm... downloading abi failed
[09:39] <ericm_> smb, it's an OEM kernel, so the kernel image package isn't on the server
[09:39] <smb> Well the script is geared towards official releases. So it looks on official host archives only
[09:40] <ericm_> smb, yeah - that makes sense - but is it possible to provide kernel package manually?
[09:40] <ericm_> smb, I'm thinking of maintaining the OEM kernel tree as our official ones with same branch management
[09:40] <smb> ericm_, Not yet. You could add that to a wish list.
[09:41] <smb> ericm_, Though I probably would make it an additional  'location' to look for packages
[09:41] <ericm_> smb, yeah that's a good idea
[09:55] <cooloney> apw: just saw your patch about readahead, will this one be summitted to upstream?
[09:57] <apw> cooloney, likely yes, whether they will take it is another question as it uses a page bit, and they are very scarese
[09:58] <smb> apw, So maint-getabis seems to work for me without having the path set. So it seems lib lookup is ok. when calling other scripts it seems to require a little more. I changed maint-startnewrelease accordingly. Maybe there is a simpler way by adding it to the right path within python but this seems to work for me.
[09:59] <apw> smb ta, will try it out
[09:59] <cooloney> apw: understood
[10:00] <cooloney> apw: ureadahead needs this patch, i guess.
[10:00] <apw> ureadahead2 needs it yes
[10:05] <ikepanhc> when sprint, Tim said when UDS, we make agreements, its means "Each team makes agreements for next release" or "Kernel team makes agreements to other team"?
[10:06] <apw> each team agrees with the other teams what it will deliver for the release
[10:06] <apw> so both i think
[10:06] <ikepanhc> apw: thanks
[10:06]  * ikepanhc hates writing slide :(
[10:23] <jk-> ike: if you like, I'm happy to read & review
[10:27] <ikepanhc> jk-: sure, but please wait me finish :)
[10:27] <jk-> ikepanhc: of course :)
[10:49] <ericm_> smb, in maint-getabis:DownloadPackage(), it looks like if I download the .deb package manually, it won't bother to download
[10:50] <ericm|ubuntu> smb, yet the problem is where, I downloaded the package in the current ubuntu-lucid/ directory, but doesn't seem to be recognized as already existing
[10:51] <smb> ericm|ubuntu, Might work, though you would have to do it either on the remote host or say --local
[10:52] <ericm|ubuntu> smb, but maint-startnewrelease doesn't accept --local
[10:53] <smb> Hm, I should add that as passthrough then
[10:56] <diwic> what (Maverick) kernel repo/ppa should I enable if I want to help out with testing?
[11:00] <apw> ~kernel-ppa/pre-proposed
[11:02] <diwic> whoa! That was an interesting resume effect
[11:03] <apw> heh what did you see ?
[11:03] <diwic> My (other) laptop makes screen effects that reminds me of the demo scene in the 90's
[11:04]  * apw is intregeded, but has no idea what that might look like
[11:05] <diwic> It purely hang under Lucid, so this is maverick. Every other scanline is black, and  the others are fading between white and blue-black
[11:06] <diwic> hmm...seem to have settled as being grey + black now
[11:06] <diwic> a few blue pixels in the top and bottom though
[11:17] <marco74> hello anybody here in this room
[11:17] <marco74> I have a problem concerning the ubuntu-kernel of Lucid
[11:17] <marco74> can anybody help me?
[11:34] <apw> wtf why to people just appear ask and go without waiting?
[11:35] <apw> diwic, sounds mad enugh
[11:36] <apw> oh _and_ logoff irc completely ... 
[11:36] <apw> cking, hey
[11:44] <cking> apw, what?
[11:45] <apw> cking, was trying to work out if you could hear me on mbl
[11:45] <apw> as you clearly wern't there ... 
[12:41] <diwic> apw, you have a movie in bug #611254
[12:41] <ubot2> Launchpad bug 611254 in linux (Ubuntu) "Resume hangs and shows funny patterns on screen (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/611254
[12:48] <apw> diwic, what do you use to play it?  totem just ignores it
[12:49] <diwic> apw, it works in VLC. It's straight from the phone
[12:50] <apw> diwic, so it does, cute effect
[12:55] <diwic> apw, I'll just wait for our suspend/resume guy (still haven't learned all names and who does what) to take care of it :-)
[12:55] <apw> cking, http://launchpadlibrarian.net/52687216/MOV00503.MP4
[13:10] <apw> diwic, i wonder if thats just the video ram decaying cause its not being refreshed cause we are crashed
[13:10] <Sarvatt> diwic: does booting with vesafb=fubar fix it? :)
[13:11] <apw> literally =fubar ?
[13:11] <Sarvatt> invalid parameter so it wont load
[13:12] <apw> Sarvatt, do we have any idea why vesafb is relevant ?
[13:13] <diwic> If that matters, it's Via/OpenChrome
[13:14] <Sarvatt> i'm just curious because i've seen similar caused by vga16fb. I saw it was openchrome, I'm sorry diwic :)
[13:15] <apw> framebuffer handling is mostly broken .. i am working on what is becoming a major patch for it now
[13:17] <diwic> Sarvatt, I tried it and as we already suspected, it didn't work, i e no difference
[13:18] <diwic> apw, video ram decaying was the best theory out of 1 theories so far
[13:33]  * apw likes those odds
[13:33]  * apw bets his theory is the closest to the truth
[13:45] <apw> smb, these new ext4 patches are they the ones we already have or new ones?
[13:45] <apw> (the ones in the stable queue for .32)
[13:45] <smb> apw, May or may not. I have not done a comparison yet to find out whether the sets are 1:1
[13:46] <apw> there seems to be 52 of them
[13:46] <smb> that sounds not too bad
[13:46] <apw> 142 in total on the queue, 52 ext4
[13:46] <smb> Let me run over them with a script to be sure its all we had
[13:50] <diwic> should I put something into a git kernel commit to make it automatically close a LP bug?
[13:51] <apw> diwic, yep, a BugLink: link
[13:51]  * smb is too slow
[13:51] <apw> BugLink: http://bugs.launchpad.net/bugs/581525
[13:51] <ubot2> Ubuntu bug 581525 in linux-meta (Ubuntu) (and 1 other project) "Lucid: system becomes unstable randomly, seems related with apparmor (affects: 5) (heat: 32)" [Undecided,In progress]
[13:52] <manjo> apw, how does that automatically close an LP bug ?
[13:52] <diwic> apw, thanks
[13:52] <apw> insert changes copied them over to LP: #nnnnn in the debian changelog
[13:52] <apw> and things so marked in there are closed by the janitor when the package is published
[13:53] <apw> manjo, ^^
[13:53] <manjo> did now know that ... thanks 
[13:53] <apw> t'is why they are important to have in the bugs
[13:53] <apw> the - LP: bits of the debian changelog are made from them
[13:54] <manjo> apw, I always added them not knowing their side effects 
[13:54] <apw>   * SAUCE: Yama: search for PTRACE exceptions via thread group leader
[13:54] <apw>     - LP: #603716
[13:54] <apw> like that ... and that is grepped out by the janitor
[13:56] <soren> manjo: Technically, it's dpkg-genchanges that does it. It spots the stuff in debian/changelog and adds a line to the _source.changes file (X-Launchpad-Bugs-Fixed, IIRC), which in turn is handled by Launchpad.
[13:56] <apw> soren, heh even more complex
[13:57] <soren> Well, the magic has to happen somewhere :)
[13:57]  * manjo is feeling dizzy 
[13:57] <soren> This way, if the distro team feels like changing preferred format for it in the debian changelog, it doesn't require changes in Launchpad.
[13:58] <apw> /home/apw/upload/arm/linux-fsl-imx51_2.6.31-104.12_source.changes:Launchpad-Bugs-Fixed: 310760 410933 410933 416325 416325 427948 430694 430694 430694 430809 430809 433904 435958 438687 445580 446595
[13:58] <apw> and there it is lurking in the changes file
[13:59] <soren> Ok, so no "X-" prefix. My bad :)
[13:59] <manjo> so if a patch fixes multiple bugs we need to have multiple Buglink: ... in the commit comments ? 
[13:59] <apw> yeah such inaccuracy you should be fired
[13:59] <apw> manjo, yes
[13:59] <soren> apw: You can't fire people who've already left. :)
[13:59] <apw> and they end up as - LP: #xxx, #yyy
[13:59] <apw> and so on
[14:00] <apw> soren, i didn't say who should fire you did i ?   :)
[14:00] <soren> apw: point :)
[14:00] <manjo> cease fire
[14:02] <ericm> smb, when you rebase mvl-dove branch against master, what is the command you use, 'git rebase Ubuntu-2.6.xx-xx.xx' or 'git rebase --onto Ubuntu-2.6.xx-xx.xx <some start point> mvl-dove'
[14:02] <smb> ericm, The second form
[14:03] <ericm> smb, as I expected, ok
[14:03] <smb> ericm, Though I started to run it as a script: maint-rebase-branch
[14:05] <smb> ericm, This would end on a branch named auto-tmp-rebase which one can check and then reset the target branch to that
[14:05] <ericm> smb, ah - script again, thanks - I love your scripts :-)
[14:07] <smb> ericm, Thanks :) These are quite ego-centric for the moment, so feel free to let me know anything that can be improved.
[15:32]  * manjo going down for reboot
[17:05] <manjo> I will be offline for a few mts my electric company is cutting my power to replace the meter 
[17:12] <apw> yeah right :)
[17:12] <apw> you will be gone for HOURS :)
[17:33] <cking> days even
[17:34]  * cking hopes manjo has a lot of batteries
[18:07] <jjohansen> ogasawara: I'm going to have another AA sync request for tonight / friday morning.  Its not that different from what we have but brings it up to match with the latest updates.
[18:07] <ogasawara> jjohansen: cool, I'll wait for it then
[18:08] <jjohansen> ogasawara: well no real need to wait, I can push it when you want.  Just the longer I wait the more likely it will match whats hopefully going upstream
[18:09] <jjohansen> its done now, just waiting on feedback
[18:09] <ogasawara> jjohansen: maybe just wait and see if you get any feedback by tomorrow.  I'd like to be as close to what's upstream as possible.
[18:09] <ogasawara> jjohansen: I'm gonna hold off the upload as long as I can anyways as I'm hoping 2.6.35 final might land
[18:10] <jjohansen> ogasawara: also I have a pv-ops request coming too, no nasty xen branch :)
[18:10] <ogasawara> jjohansen: sweet
[18:15] <apw> jjohansen, that sounds good
[18:15] <apw> ogasawara, i shot you a summary email on all the patches i've puked out today
[18:16]  * apw is wandering off for some beer shortly, i'll try and check my email tonight in case you have any issues
[18:17] <ogasawara> apw: yep, saw it.  Just getting through the last set.  looking okay so far.  I'm gonna fire up some tests across some of my systems before I push.
[18:17] <apw> sounds good.  doesn't solve the fact that plymout
[18:17] <apw> plymouth fires up too soon on a lot of drm h/w.  but at least it not longer blows the kernel up (for me at least)
[18:33]  * manjo getting lunch will be back soon
[18:43]  * vanhoof just loves updating wikis :)
[19:00] <cking> vanhoof, watch out - you may become a wiki gardener soon
[19:00] <jjohansen> cking: beat me too it
[19:06] <vanhoof> lol
[19:06]  * vanhoof *hides*
[20:09] <jjohansen> -> lunch
[20:19] <bjf> jjohansen, i added you as UDS-N roomie :-)
[20:42] <jjohansen> bjf: wow you are on top of things :)
[20:43]  * ogasawara lunch
[21:34]  * manjo going to post office ... brb 30mts 
[22:19] <bjf> ogasawara, hope you don't mind if i poke at qa about testing proposed :-)
[22:19] <ogasawara> bjf: don't mind at all, was actually hoping others would chime in :)
[22:19] <ogasawara> bjf: I was thinking the exact same questions you posted.
[22:20] <jjohansen> bjf: have fun tilting at windmills
[22:20] <ogasawara> heh
[22:21] <bjf> jjohansen, i'm willing to have a go at this one for a bit, it's been years since I sent some really flaming email
[22:21] <jjohansen> :)
[22:22] <ogasawara> bjf: after the chat with them at the rally I thought we'd figured out the preseed bit, and modification of the dist.info file to search for results of testing from -proposed, and tweaking their prober or whatever to detect new packages in -proposed
[22:23] <ogasawara> bjf: I swear ronald even sent an email about it
[22:23] <bjf> ogasawara, yes i had the same thoughts as well, I guess we were mistaken
[22:49] <komputes> ogasawara: hi there! :)
[22:49]  * komputes hands ogasawara a present - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/611474
[22:49] <ubot2> Ubuntu bug 611474 in linux (Ubuntu) "boot failure SAS hard drives controller (affects: 1) (heat: 6)" [Undecided,New]
[22:50] <apw> ogasawara, yo ... checking in ... all good?  any problems?
[22:52] <ogasawara> apw: all good
[22:52] <ogasawara> apw: just have one more system I want to install and test on
[22:56] <ogasawara> cool, the touchscreen on the hp-mini is working again
[23:30] <apw> ogasawara, awsome :)   ... night
[23:58] <daishadar> can someone give me a general idea of what will probably stop working if i install a mainline kernel?  what are ubuntu specific patches and drivers for?