[07:46] morning [07:47] Morning [07:50] Morning [08:10] morning, eu [08:37] moin [08:45] hey apw [08:45] hi [08:59] apw, cking, is smb on vacation this week? [09:00] all of the UK is taking a swap day tomorrow [09:01] i'm trying to create an lvm-snapshot. my machine just hungs there. here's the kern.log http://pastebin.com/KUzVGZSQ [09:02] jk-, ok [09:02] apw, so I have to bug you again [09:02] ericm_, smb is in today [09:03] 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] ericm_, the tags are correct in that the point to the tree at the time the release was made [09:03] morning smb [09:03] the release commits in the latest copy of the tree do not correspond to the tags ... but the tags are right [09:04] apw, yeah - but now the rebased commit isn't [09:04] I mean the equivalent one, you know what I mean [09:04] right ... that is correct, but only the tag matters [09:04] apw, ok I see [09:04] The tags should still be there but point to something not linearly connectect to the releas [09:05] 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] smb, apw, OK I see [09:07] smb, one other thing - why don't we just put maint-startnewrelease to replace the fdr startnewrelease? [09:07] ericm_, Mostly because I just recently wrote it [09:08] smb, mostly I much enjoyed using that script :-) [09:08] ericm_, Another thing that is a bit of a problem it that those scripts use other libraries in the kteam-tools domain [09:09] ericm_, Thanks, I enjoy those too. Take some of the manual labour away [09:10] smb, ok - I copied the lib directly to my /usr/lib/python, though not sure if that's the right way [09:11] smb, maybe for the scripts in kernel package, we could just hardcode those libs into the scripts, but that creates maintenance problems :-/ [09:11] ericm_, From my intention you would just add the kteam-tools/maintsacripts to your PATH and all should work [09:12] All scripts look for libraries relative to their own path in kteam-tools/lib [09:12] Grr.... I copied those to ~/bin, ugly hacks [09:13] 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] apw, That dir? Which one [09:15] kteam-tools/maint-scripts [09:15] 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] Ah, ok. Understand now [09:15] 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] apw Hm, well should be a relative simple fix [09:16] yep, should be, just not obthered to look yet [09:16] apw, Just that I never saw that much need as I got it in my path [09:17] its a proformer fragment of code needed to do it [09:17] Because I am lazy and don't want to type the complete path all the time [09:17] apw, The problem likely is this needs to go into all scripts looking for a lib [09:18] and everything looking for a binary too [09:18] Huh? [09:18] other binaries called from the binaries (or scripts) needs it too, so i don't have to add the path [09:19] Well, thats what PATH is for [09:19] but for a small code change it can work both ways and ~/git/kteam-tools/maint-foo/maint-bar [09:19] I find it somewhat strange to expect a script or binary will find anything somewhere [09:19] will work as expected instread of exploding randomly for some commands [09:20] plus actually just using path is dangerous as i could have two versions installed [09:20] and get the libraries or binaries from the other one [09:20] the tools come as a kit, and should ensure they use the ones from the kit [09:21] i am not asking you to do the work, i'll get to it when it next annoys me [09:21] apw, Somehow you sound like asking for bulletproof shoes while waving around your gun :-P [09:22] smb, its a personal way of working that i use commonly with other applications is all [09:22] and its odd that that one does not follow the same rule [09:22] i tend to not have random scripts on my path that have low utility, by which i mean i use them seldom [09:22] As odd as it is to me that you don't work like me. [09:22] But ok [09:22] especially ones which mess arround with the current directory state [09:23] as there is inhearnt risk of running the wrong thing and shitting all over what you are doing [09:23] 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] but normally to just get one function out of it, i'll just pick it by absolute path [09:23] I can try to put in a more robust lookup and you can do the others [09:24] as i say, don't feel you need to do anything [09:24] i have lots of experience of doing this mod, as i have it in everything i write for the same reason :) [09:25] I would do it just once in one script to have a reference for it. Also in case I do more scripts [09:26] 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] 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] I believe there is an abspath which returns the complete path, which I can use instead of getcwd alone [09:27] yeah there may even be a python lib fn for finding 'here' [09:28] here=`dirname $0` [09:28] case "$here" in [09:28] *) here="`pwd`/$here" ;; [09:28] esac [09:28] is what i do in shell [09:28] here = os.path.abspath(os.getcwd()) [09:28] I think [09:29] no that is 'here' of the user, not the here of the program [09:29] ok a line is missing from that fragment ... cause it starts with a / [09:29] damn irc client [09:29] right, replace that the path of the program [09:29] here=`dirname $0` [09:29] case "$here" in [09:29] /*) ;; [09:29] *) here="`pwd`/$here" ;; [09:29] esac [09:30] the problem is that $0 is not always fully qualified [09:30] it is generally what the user typed, which can be relative [09:30] so you have to be sneaky [09:31] Hm, so does maint-getabis currently fail for you that way. It seems at least for the libpath I already use abspath [09:37] 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] it's in maint-getabis [09:37] ericm_, Did you tag it like that? [09:37] smb, oh no - let me tag it again [09:38] smb, now it works [09:39] smb, hrmm... downloading abi failed [09:39] smb, it's an OEM kernel, so the kernel image package isn't on the server [09:39] Well the script is geared towards official releases. So it looks on official host archives only [09:40] smb, yeah - that makes sense - but is it possible to provide kernel package manually? [09:40] smb, I'm thinking of maintaining the OEM kernel tree as our official ones with same branch management [09:40] ericm_, Not yet. You could add that to a wish list. [09:41] ericm_, Though I probably would make it an additional 'location' to look for packages [09:41] smb, yeah that's a good idea === ogra_ is now known as ogra [09:55] apw: just saw your patch about readahead, will this one be summitted to upstream? [09:57] cooloney, likely yes, whether they will take it is another question as it uses a page bit, and they are very scarese [09:58] 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] smb ta, will try it out [09:59] apw: understood [10:00] apw: ureadahead needs this patch, i guess. [10:00] ureadahead2 needs it yes [10:05] 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] each team agrees with the other teams what it will deliver for the release [10:06] so both i think [10:06] apw: thanks [10:06] * ikepanhc hates writing slide :( [10:23] ike: if you like, I'm happy to read & review [10:27] jk-: sure, but please wait me finish :) [10:27] ikepanhc: of course :) [10:49] smb, in maint-getabis:DownloadPackage(), it looks like if I download the .deb package manually, it won't bother to download === ericm_ is now known as ericm|ubuntu [10:50] 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] ericm|ubuntu, Might work, though you would have to do it either on the remote host or say --local === amitk is now known as amitk-afk [10:52] smb, but maint-startnewrelease doesn't accept --local [10:53] Hm, I should add that as passthrough then [10:56] what (Maverick) kernel repo/ppa should I enable if I want to help out with testing? [11:00] ~kernel-ppa/pre-proposed [11:02] whoa! That was an interesting resume effect [11:03] heh what did you see ? [11:03] 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] 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] hmm...seem to have settled as being grey + black now [11:06] a few blue pixels in the top and bottom though === ericm|ubuntu is now known as ericm-afk [11:17] hello anybody here in this room [11:17] I have a problem concerning the ubuntu-kernel of Lucid [11:17] can anybody help me? [11:34] wtf why to people just appear ask and go without waiting? [11:35] diwic, sounds mad enugh [11:36] oh _and_ logoff irc completely ... [11:36] cking, hey === apw changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Maverick Kernel Version: 2.6.35 || Ubuntu Kernel Team Meeting - August-03 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! [11:44] apw, what? [11:45] cking, was trying to work out if you could hear me on mbl [11:45] as you clearly wern't there ... === amitk-afk is now known as amitk [12:41] apw, you have a movie in bug #611254 [12:41] 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] diwic, what do you use to play it? totem just ignores it [12:49] apw, it works in VLC. It's straight from the phone [12:50] diwic, so it does, cute effect [12:55] 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] cking, http://launchpadlibrarian.net/52687216/MOV00503.MP4 [13:10] diwic, i wonder if thats just the video ram decaying cause its not being refreshed cause we are crashed [13:10] diwic: does booting with vesafb=fubar fix it? :) [13:11] literally =fubar ? [13:11] invalid parameter so it wont load [13:12] Sarvatt, do we have any idea why vesafb is relevant ? [13:13] If that matters, it's Via/OpenChrome [13:14] i'm just curious because i've seen similar caused by vga16fb. I saw it was openchrome, I'm sorry diwic :) [13:15] framebuffer handling is mostly broken .. i am working on what is becoming a major patch for it now [13:17] Sarvatt, I tried it and as we already suspected, it didn't work, i e no difference [13:18] 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] smb, these new ext4 patches are they the ones we already have or new ones? [13:45] (the ones in the stable queue for .32) [13:45] apw, May or may not. I have not done a comparison yet to find out whether the sets are 1:1 [13:46] there seems to be 52 of them [13:46] that sounds not too bad [13:46] 142 in total on the queue, 52 ext4 [13:46] Let me run over them with a script to be sure its all we had [13:50] should I put something into a git kernel commit to make it automatically close a LP bug? [13:51] diwic, yep, a BugLink: link [13:51] * smb is too slow [13:51] BugLink: http://bugs.launchpad.net/bugs/581525 [13:51] 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] apw, how does that automatically close an LP bug ? [13:52] apw, thanks [13:52] insert changes copied them over to LP: #nnnnn in the debian changelog [13:52] and things so marked in there are closed by the janitor when the package is published [13:53] manjo, ^^ [13:53] did now know that ... thanks [13:53] t'is why they are important to have in the bugs [13:53] the - LP: bits of the debian changelog are made from them [13:54] apw, I always added them not knowing their side effects [13:54] * SAUCE: Yama: search for PTRACE exceptions via thread group leader [13:54] - LP: #603716 [13:54] like that ... and that is grepped out by the janitor [13:56] 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] soren, heh even more complex [13:57] Well, the magic has to happen somewhere :) [13:57] * manjo is feeling dizzy [13:57] 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] /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] and there it is lurking in the changes file [13:59] Ok, so no "X-" prefix. My bad :) [13:59] so if a patch fixes multiple bugs we need to have multiple Buglink: ... in the commit comments ? [13:59] yeah such inaccuracy you should be fired [13:59] manjo, yes [13:59] apw: You can't fire people who've already left. :) [13:59] and they end up as - LP: #xxx, #yyy [13:59] and so on [14:00] soren, i didn't say who should fire you did i ? :) [14:00] apw: point :) [14:00] cease fire === ericm-afk is now known as ericm [14:02] 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 mvl-dove' [14:02] ericm, The second form [14:03] smb, as I expected, ok [14:03] ericm, Though I started to run it as a script: maint-rebase-branch === yofel_ is now known as yofel [14:05] 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] smb, ah - script again, thanks - I love your scripts :-) [14:07] ericm, Thanks :) These are quite ego-centric for the moment, so feel free to let me know anything that can be improved. === gnomefreak76 is now known as gnomefreak === bjf[afk] is now known as bjf === BenC__ is now known as BenC [15:32] * manjo going down for reboot === sconklin-gone is now known as sconklin [17:05] I will be offline for a few mts my electric company is cutting my power to replace the meter [17:12] yeah right :) [17:12] you will be gone for HOURS :) [17:33] days even [17:34] * cking hopes manjo has a lot of batteries [18:07] 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] jjohansen: cool, I'll wait for it then [18:08] 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] its done now, just waiting on feedback [18:09] 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] 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] ogasawara: also I have a pv-ops request coming too, no nasty xen branch :) [18:10] jjohansen: sweet [18:15] jjohansen, that sounds good [18:15] 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] 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] sounds good. doesn't solve the fact that plymout [18:17] 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] vanhoof, watch out - you may become a wiki gardener soon [19:00] cking: beat me too it [19:06] lol [19:06] * vanhoof *hides* === sconklin is now known as sconklin-lunch === sconklin-lunch is now known as sconklin [20:09] -> lunch [20:19] jjohansen, i added you as UDS-N roomie :-) [20:42] bjf: wow you are on top of things :) [20:43] * ogasawara lunch [21:34] * manjo going to post office ... brb 30mts === achiang is now known as smallakin1 === smallakin1 is now known as achiang [22:19] ogasawara, hope you don't mind if i poke at qa about testing proposed :-) [22:19] bjf: don't mind at all, was actually hoping others would chime in :) [22:19] bjf: I was thinking the exact same questions you posted. [22:20] bjf: have fun tilting at windmills [22:20] heh [22:21] 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] :) [22:22] 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] bjf: I swear ronald even sent an email about it [22:23] ogasawara, yes i had the same thoughts as well, I guess we were mistaken [22:49] ogasawara: hi there! :) [22:49] * komputes hands ogasawara a present - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/611474 [22:49] Ubuntu bug 611474 in linux (Ubuntu) "boot failure SAS hard drives controller (affects: 1) (heat: 6)" [Undecided,New] [22:50] ogasawara, yo ... checking in ... all good? any problems? [22:52] apw: all good [22:52] apw: just have one more system I want to install and test on [22:56] cool, the touchscreen on the hp-mini is working again [23:30] ogasawara, awsome :) ... night [23:58] 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?