[07:00]  * lag waves
[07:09] <cking> lag, morning!
[07:24] <lag> cking, Hi ya!
[07:24] <lag> You're up early
[07:25] <cking> lag, you up early too!
[07:26] <lag> cking: I'm always up at this time. I like to start early - finish early
[07:26] <lag> Although I haven't been very good at finishing :s
[07:27] <cking> lag, me neither
[07:27] <lag> cking: I'll have to change that soon - I don't want to burn myself out
[07:28] <cking> lag, indeed
[07:30]  * abogani waves
[07:31] <cking> hi abogani
[07:32] <lag> cking: How's your scripting?
[07:32] <abogani> cking: Good morning!
[07:32] <cking> lag, scripting? please elaborate?
[07:33] <lag> What does "cat <<EOD" mean/do?
[07:33] <cking> lag, it will write out the text upto but not including the EOD marker
[07:33] <lag> Oh, excellent!
[07:34] <lag> :)
[07:34] <lag> Can EOD be anything? Or is it defined?
[07:35] <cking> technically called "here strings", can be any terminal word, man bash, look for "Here Strings"
[07:37] <cking-afk> back in 10
[07:39]  * abogani is wondering if exist a way to temporarily turn off Ubuntu kernel bugs email notifications...
[07:40] <abogani> Sorry for my English: it is usually horrible but today I'm moreover particularly sleepy...
[07:46] <cking> abogani, no idea - it would be good to stop the incoming deluge!
[07:47] <abogani> cking: Perhaps Leann could know that.
[07:47] <abogani> ogasawara: ^
[07:49] <abogani> cking: It is very easy to have a full mailbox it you left your pc for a couple of days...
[07:49] <cking> abogani, too right
[08:48]  * abogani is wondering why embedded youtube video don't work anymore...
[08:57]  * apw ywans
[08:57] <cking> morning apw
[08:58]  * lag waves at apw
[08:58] <apw> morning all
[08:59] <abogani> apw: morning
[09:05] <abogani> I would want rename two kernels. -preempt to -lowlatency and -rt to -realtime. Why? Because -preempt and -rt sound really geek names. Those are totally meaningless for "human beings" :-) So -lowlatency and -realtime are better self-explained words. That sounds reasonable to you?
[09:24] <apw> i guess i have no real objection to those new names, though i suspect anyone who has any understanding that there are multiple kerenls and indeed that you have a choice and why you might want to make such as choise, is going to be unfazed by the current names
[09:25] <cking> more explicit the naming the better in my opinion as long as it does not involve much more typing
[09:29] <abogani> cking: Normal users use GUI so no matter how long the name is.
[09:30] <cking> abogani, true
[09:32] <abogani> I also think renaming is right because we have -server not -srv and -generic not -gen so I think than "align" name conventions.
[09:36] <abogani> Moreover when someone speak about -preempt we'll know immediately than he are talking about the kernel which is in Lucid into main component. 
[09:48] <apw> though any report without version numbers is useless and those would tell us, plus any apport reported bug should get filed against the correct source package name
[09:52] <lag> Okay, I'm working on bug583128
[09:52] <lag> I think I have fixed it
[09:53] <lag> Who to I commit it with the commit messages in debian/commit-templates?
[09:53] <lag> How*
[09:53] <lag> do*
[09:53] <lag> Blimey! Start as you mean to go on lag!
[09:53]  * cking thinks lag needs more coffeee
[09:54]  * lag thinks he needs to get off the water and start drinking coffee
[09:57] <apw> lag, what sort of fix is it
[09:57] <jk-> i believe that is in the New Starter document
[09:57] <apw> jk-, what how much coffee to drink :)
[09:58] <jk-> .. and apw will tell you how much beer to drink
[09:58] <apw> good point
[09:58] <jk-> we have quotas to meet
[09:58]  * lag looks for the New Starter document 
[09:59] <jk-> lag: oh, i meant about the coffee, no the commit details :)
[09:59] <jk-> *not
[09:59] <lag> Phew!
[10:00] <jk-> I think the Packaging guide has those details?
[10:00]  * jk- looks
[10:00] <jk-> lag: https://wiki.ubuntu.com/PackagingGuide/Complete is a good reference in general
[10:01] <apw> but basically the form is common pretty much, its the prefixes on the subject line which differ based on source of the fix
[10:01] <lag> Woo, another Wiki - joy!
[10:01] <lag> ;)
[10:01] <apw> if its an upstream cherry pick we do it one way, if its a local only patch we do it another, there are about 5 categories
[10:03] <jk-> lag: https://wiki.ubuntu.com/KernelTeam/KernelBugFixing#Commit%20the%20Patch
[10:03] <lag> jk: That's the badger 
[10:03] <lag> jk-: Thank you
[10:03] <jk-> lag: no problem
[10:04] <apw> BAH its out of date already
[10:05] <jk-> it does mention the "hardy tree" :)
[10:05] <apw> heh i think i might have written it given the s-o-b
[10:06] <lag> apw: Does it need changing before I use it?
[10:06] <apw> you should be using -F debian/commit-templates/sauce-patch ... if its that template
[10:06] <apw> that has the up to date version of the contents, indeed as the page there tells you
[10:06] <apw> i've updated the example to make it right
[10:22] <apw> gah the wiki is as slow as hell, all those stooopid emails being synchronous
[10:29] <persia> lag, apw: Would you guys like a quick outline of how to set up auto-emulating chroots?
[10:30] <lag> persia: Can't hurt :)
[10:30] <jk-> yes
[10:30] <lag> persia: I'm currently hacking smb's remote-scripts to work
[10:31] <persia> Do you already use mk-sbuild to set up the schroots you use to build?
[10:32] <lag> persia: Nope
[10:32] <lag> I use smb's scripts
[10:32] <lag> To start the builds remotely
[10:33] <lag> They're good
[10:33] <persia> Right, but what's the source of your chroots?
[10:33] <lag> Fire and forget
[10:33] <persia> How do they get created in the first place?
[10:34] <lag> They already exist on emerald 
[10:34] <lag> dchroot -l
[10:34] <lag> Available chroots: doko-lucid, doko-lucid32, hardy-amd64, hardy-i386, hardy-lpia, intrepid-amd64, intrepid-i386, intrepid-lpia, jaunty-amd64, jaunty-i386, karmic-amd64, karmic-i386, karmic-lpia, lucid-amd64 [default], lucid-i386, maverick-amd64, maverick-i386
[10:34] <persia> You're still using dchroot!  That's been obsolete for years!
[10:35] <persia> You so want to migrate to schroot.
[10:35]  * persia has been using schroot since feisty with happy results
[10:37] <apw> persia, i think i inadvertantly got a pointer to the 'arm emulation way' last night from kees
[10:37] <apw> i used mk-sbuild --architecture=armel maverick
[10:37] <apw> and then used sbuild *.dsc
[10:37] <apw> and ... hours later i got a native-ish arm build ...
[10:37] <apw> persia, about right ?
[10:37] <persia> Yep, that's the way it works.
[10:38] <apw> man it was slow, and made my build box scream in agony for the whole time
[10:38] <persia> The hours later bit happens on native hardware too, except if you have a RAM intensive build (like the kernel), it's even more hours.
[10:38] <apw> yeah was about 2 hours i would guess for a flavour, so about 3x quicker than a native one
[10:39] <persia> Mostly a matter of RAM.  Stick 8G on a native box, and it would be that fast too.
[10:40] <apw> yeah its not got quite that much unfortuantly, though it seemed to be CPU bound from the groaning from the fans
[10:42] <persia> heh.  Emulation isn't cheap :)
[10:43] <apw> no, but at least it did build so i could 'test' the userspace
[10:44] <apw> persia, the resulting chroot, is that setup to be arm-like should you just schroot into it?
[10:45] <persia> You can, if you like.
[10:45] <apw> apw      16963 16904  0 10:44 pts/2    00:00:00 /usr/bin/qemu-arm-static /bin/bash
[10:45] <apw> apw      16980 16963  0 10:45 pts/2    00:00:00 /usr/bin/qemu-arm-static /bin/ps -ef
[10:46] <apw> euuuwwwww :)
[10:46] <persia> The way it works is through a binfmt-misc hook, that then uses the static qemu as an interpreter for any foreign binaries.
[10:46] <persia> You don't like that?  Do yo have a better suggestion?
[10:46] <lifeless> hardware!
[10:47] <lifeless> get an ia-64 personality for arm into the next rev of the chips
[10:47] <apw> persia, no i think its an amazing abuse of the world order to make it work
[10:49] <persia> lifeless: Um, there's not enough bits (although I'm hoping to get qemu working on/for ia64 this cycle)
[10:49] <lifeless> not enough bits ?
[10:50] <lifeless> for cpu personality ? I'd need to review the spec
[10:50] <persia> But, yeah, hardware is always better (although I often find local schroots more convenient than remote schroots on real hardware, for some reason)
[10:50] <lifeless> I'm sure they had room for expansion earmarked
[10:50] <persia> lifeless: armel is 32-bit: can it handle a 64-bit personality?
[10:50] <lifeless> eys
[10:51] <persia> Interesting...
[10:52] <lifeless> http://en.wikipedia.org/wiki/Itanium#Architectural_changes
[10:53] <lifeless> as originally conceived it ran ia-64, ia-32 and (IIRC) sparc
[10:53] <lifeless> I may be misremembering the third instruction set
[10:54] <persia> Indeed, but that went away.  As far as I understand, Ubuntu doesn't even run well on that generation (without customimsed kernels)
[10:54] <lifeless> nothing does ;P
[10:55] <persia> No, some stuff does.  stgraber has a couple of them running Ubuntu, and then using LXC to run x86 stuff.  It just requires some extra effort.
[10:56] <lifeless> 'well'
[10:56] <lifeless> the key word
[10:56] <lag> apw, persia: So what conclusion did we come to? Am I sticking with the scripts?
[10:56] <persia> But I *don't* think there's any way to get armel hardware to run ia64 code without using an emulation layer, and I don't expect that to be working cleanly until maverick+1 (and not even then unless someone decides to do the integration work after qemu-static-ia64 works properly)
[10:57] <apw> for me i am continuing as i am, but i am adding this new armel thingy to my arsenal
[10:58] <persia> lag: There wasn't a conclusion.  We briefly discussed how foreign schroot works.  Making this work with your scripts means minimally migrating from the long-deprecated dchroot (which is implemented as a compatibility layer in schroot these days), and then setting up a schroot.
[10:58] <apw> its far to slow for test builds, but for when you need to know if linux-tools will build its invaluable
[10:58] <apw> and tgarder was looking at the migration i think himself
[11:02] <lag> I think I'm mainly interested in test builds?
[11:03] <persia> Probably.  It's near native-speed on test builds, but that's still slow.
[11:03] <persia> That said, it actually exercises the toolchain, whereas some cross-build doesn't provide any assurance that something will actually build with the native toolchain.
[11:04] <persia> (although it's usually 95+% similar)
[11:15] <apw> persia, right, there is always a risk of differences tehre
[11:15] <apw> it is definatly the righter way forward compared to native cross compilers
[11:16] <persia> Well, I'd be less against cross-compilers if we were building clean cross-toolchains from the same sources in the archive.
[11:16] <persia> My big objection is about using some random cross-toolchain (even if well-respected) and expecting it to magically work.
[11:16] <persia> That said, I agree with lifeless that the real solution is hardware.
[11:17] <persia> (for all that I'm often too lazy to dispatch a remote build, and end up doing it locally in emulation)
[11:31] <lag> apw: If a local repo is on branch x and a remote one is on branch y and a 'git push' is actioned, what happens?
[11:31] <apw> you are only changing where the branch points to, not what the working directory contains
[11:32] <apw> ie the remote x changes to be the same as the local one, but Y and the checkout of Y in the working directory are unaffected
[11:32] <apw> indeed if remote is on X and you allow overwriting, then X on remote will change, but the checkout will not
[11:32] <apw> you need to reset it to get the working directory in sync
[11:35] <lag> But in my case the remote hasn't even checked out x yet - so what happened in the push? Nothing?
[11:40] <lag> apw: ?
[11:40] <apw> no the remote branch now is the new version
[11:40] <lag> doh
[11:40] <lag> :)
[11:40] <apw> that is it is not the checked out one is unrelated
[12:39] <lag> apw: Playing with git again
[12:39] <lag> I've checked out master on both local and remote repos
[12:39] <lag> Then did a "git push --dry-run <servername>"
[12:40] <lag> And received this:    f0819aa..eb33bb9  lp583128 -> lp583128
[12:40] <lag> Neither repos are on branch lp583128?
[12:41] <apw> well you asked ti to push _all_ branches right
[12:42] <lag> Then why doesn't it attempt to push master or ti-omap?
[12:43] <apw> are they arready the same ?
[12:43] <apw> it may be only telling you about the changes it would make, not the checks it checked
[12:44] <lag> Ah, because it is the only with commits?
[12:44] <apw> because the local and remote are identicle perhaps ?
[12:45] <apw> you could test by commiting something to one of the others
[12:45] <apw> and see if it then appears
[12:47] <lag> k
[13:00] <Amarendra> can any body tell me how to install usb modem in ubuntu?
[13:00] <Amarendra> is anybody there in this room??
[13:00] <popey> yes, but this probably isnt the right place for your question Amarendra 
[13:01] <Amarendra> where should i go?
[13:10] <popey> #ubuntu probably
[13:23] <cking-afk> food
[13:47] <apw> lag, target-scripts/run-clean:               git checkout -f "${BRANCH}"
[13:48] <lag> apw: ack
[13:53] <tgardner> apw, is mumble up? I keep getting rejected.
[13:54] <apw> tgardner, yes we are on it
[13:54] <apw> check it remembered your new username
[13:54] <tgardner> apw, it did, but I'm not sure it saved the certificate. I'll keep messing with it
[13:55] <apw> tgardner, i think it asks me for my password every time
[13:55]  * apw tries
[13:56] <apw> hrm, not its remembered something somwhere
[13:56] <cking-afk> fail
[13:56] <apw> cking, fail ?
[13:56] <cking> apw, mumble passwd recall
[13:57] <apw> yeah need to find its brain and move it into Private
[13:57] <apw> cking, ahh it has a certificate recorded it is using in the stead of password
[13:59] <apw> tgardner, it seems to record everything in .config/Mumble, so if you get desperate removing that may help
[14:00] <tgardner> apw, gosh, thats so handy having to delete that file every time.
[14:00] <apw> not had to do that yet myself, but if it helps :/
[15:25] <vanhoof> pgraner: tgardner: ping
[15:25] <vanhoof> can either of you set ~ayan up in c-k-t and u-k lp groups?
[15:28] <tgardner> vanhoof, can do. gimme a bit
[15:28] <vanhoof> tgardner: thanks, just helping him get setup :)
[15:31] <tgardner> vanhoof, whats his LP ID? There are a bunch of ayan's
[15:31] <vanhoof> tgardner: https://edge.launchpad.net/~ayan
[15:56] <TeTeT> tgardner: Hi Tim, I've queried you on 5 May on a module for 3g connection on x201, can this be included in a Lucid kernel?
[15:58] <tgardner> TeTeT, that was on the k-t list, right?
[15:58] <TeTeT> tgardner: nope, private email
[15:59] <TeTeT> tgardner: subject: Lenovo x201 WWAN module in Lucid kernel
[15:59] <tgardner> TeTeT, send it on the list please.
[15:59] <TeTeT> tgardner: list address is?
[15:59] <tgardner> TeTeT, my private  email SPAM muncher likely ate it
[15:59] <tgardner> kernel-team@lists.ubuntu.com
[16:00] <TeTeT> tgardner: it's customer related, I'm not sending it to a public list, sorry
[16:00] <tgardner> TeTeT, then I'm not adding it to a public
[16:00] <tgardner> public kernel
[16:01] <TeTeT> tgardner: fair enough, thanks
[16:01] <tgardner> you don't have to explain for whom the request is submitted
[16:03] <TeTeT> tgardner: ok, I've anonymized the email, that shall do
[16:04] <tgardner> TeTeT, ok, we'll take a look
[16:17] <cnd> ogasawara: how do you want to handle stuff as we move to maverick where the lucid patch isn't what ended up upstream:
[16:17] <cnd> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commitdiff;h=0d843425672f4d2dc99b9004409aae503ef4d39f;hp=ee60ece93253a9c202e31672e37c513e9ff2d917
[16:17] <cnd> vs
[16:17] <cnd> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=74f5187ac873042f502227701ed1727e7c5fbfa9;hp=09a40af5240de02d848247ab82440ad75b31ab11
[16:17] <cnd> the upstream will hit in .35
[16:18] <cnd> so do you want to just handle it when it hits, or should I send a revert for it now?
[16:19] <ogasawara> cnd: I'll try and remember to drop it when I rebase to .35
[16:19] <cnd> actually, it's already landed in upstream, so you'll hit it as soon as you do your next merge
[16:20] <cnd> ogasawara: ok, I'll let you handle it all then, and that's the end of my patch upstreaming work :)
[16:20] <ogasawara> cnd: sweet
[16:20] <ogasawara> cnd: just so I don't forget, maybe I'll just revert it now and cherry-pick the upstream patch
[16:21] <cnd> there are other changes to upstream sched.c though, so you may hit conflicts if you pick it now
[16:22] <cnd> but if you plan to pull in upstream before the next drop anyways, you can just revert it now and everything should be fine
[16:22] <cnd> pull in upstream before the next maverick release that is
[16:23] <ogasawara> cnd: just depends when -rc1 drops
[16:23] <shawncm217> I've Googled and looked all over the Ubuntu website. What is the RAM limitation for 64-bit desktop Ubuntu 10.04?
[16:24] <tgardner> shawncm217, there is no practical limit
[16:24] <cnd> shawncm217: should be beyond the limits of hw
[16:24] <cnd> technically, amd64 has 48 bits of memory addression I think, so 2^48 bits :)
[16:24] <cnd> oops, bytes :)
[16:25] <TeTeT> tgardner: thanks for the swift answer
[16:26] <tgardner> TeTeT, np
[16:27] <jjohansen> cnd: yeah but that is just a current implementation limit to the virtual address space, the spec allows for an implementation to do 64 bits of virtual address space
[16:27] <cnd> jjohansen: ahhh, didn't know that
[16:27] <vanhoof> apw: sconklin: tgardner: if you guys have a chance, any thoughts on my email to you all would be appreciated
[16:28] <shawncm217> Thanks for your help.
[16:28] <vanhoof> I'm going to start putting something more official tog this weekend
[16:28] <sconklin> vanhoof: you mean the "SRU policy wrt . . . "?
[16:29] <vanhoof> sconklin: sugar bay email from last evening
[16:29] <sconklin> vanhoof: ok, see - I'm already ignoring HWE type email :). I'll have a look
[16:29] <vanhoof> sconklin: lol!
[16:30] <vanhoof> sconklin: i was nominated for this one, not by choice ;)
[16:30] <tgardner> vanhoof, thats 'cause you're the new guy and don't know what you're getting into.
[16:32] <sconklin> vanhoof: as it turns out, I do have some opinions about this :) I'll compose a response
[16:34] <jjohansen> hehe: http://www.google.com/
[16:35] <jjohansen> and its playable
[16:37]  * cnd just beat lvl 1
[16:37] <cnd> ogasawara: JFo-swap: ogasawara is still the bug overlord for the "linux" package (not the "linux (ubuntu)" package)
[16:38] <cnd> I assume that probable should be swapped as well?
[16:38] <JFo-swap> more than likely
[16:38] <vanhoof> sconklin: i assumed you would :)
[16:38] <ogasawara> cnd, JFo: hrm, I'm not even sure how to swap myself out :)
[16:41] <kamal> jjohansen: wow, that's awesome
[16:42] <jjohansen> :)
[16:43] <JFo-swap> ogasawara, I've no clue how linux(
[16:43] <JFo-swap> Ubuntu) was changed
[16:44] <ogasawara> JFo-swap: yah, I'm a bit confused too as both packages show the Ubuntu Kernel Team as being the maintainer
[16:45] <JFo-swap> hmmm, that also begs the question, Does it really have to be just me.
[16:45] <JFo-swap> or is it ok that it is the team
[16:45] <JFo-swap> I am not sure what the benefit of being the sole bug supervisor would be
[16:46] <ogasawara> JFo-swap: you're name is listed as being notified in some stock reply
[16:46] <JFo-swap> hmmm
[16:46] <ogasawara> JFo-swap: but if you want to subscribe to the bugmail https://edge.launchpad.net/linux/+subscribe
[16:47] <JFo-swap> I think I already am
[16:47] <JFo-swap> oh, that is the capital L one
[16:47] <JFo-swap> yeah
[16:49]  * ogasawara back in 30min
[16:52] <eagles0513875> hey guys can any one let me know the status of this bug https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/578210 
[16:52] <ubot2> Launchpad bug 578210 in ubiquity (Ubuntu) "ubiquity fails to install kubuntu on lucid 64bit (affects: 1) (heat: 6)" [Undecided,New]
[16:53] <eagles0513875> ikonia:  helped me determine that the bug is due to the gpt not being compiled into the desktop kernels. i can confirm that using ubuntu server kernel fixes the issue that i was having trying to get lucid installed on a 2tb hard drive
[17:13] <tgardner> eagles0513875, what is a gpt?
[17:13] <tgardner> ginormous partition table?
[17:14] <eagles0513875> tgardner: no gpt = guid partition table
[17:14] <tgardner> eagles0513875, what is the config option?
[17:14] <eagles0513875> tgardner: what do you men
[17:14] <eagles0513875> mean
[17:15] <tgardner> 'the bug is due to the gpt not being compiled into the desktop kernels'. That requires a config option.
[17:15] <shadeslayer> eagles0513875: he means if there are any compile time arguments to be passed while compiling
[17:15] <eagles0513875> shadeslayer: tgardner from what i have seen its a module that needs to be compiled with it
[17:16] <shadeslayer>  /whois tgardner 
[17:16] <shadeslayer> whopps :P
[17:16]  * shadeslayer thinks tgardner is probably doing the same thing back right now :P
[17:17] <tgardner> eagles0513875, there are no differences between the desktop and server kernel configs that would affect partition tables or sizes.
[17:25] <eagles0513875> tgardner: thing is only recently large hard drives over 1tb are becoming more main stream in desktops
[17:26] <eagles0513875> its compiled into the server kernel as server have had drivers over 1tb long before desktop use
[17:26] <eagles0513875> the desktop doesnt have it compiled into it
[17:26] <eagles0513875> and with out it i was running into some super nasty issues 
[17:26] <tgardner> eagles0513875, 'it' being specifically what?
[17:26] <eagles0513875> gpt
[17:27] <tgardner> apw, do you know what gpt is 'cause I'm not finding it ?
[17:28] <eagles0513875> tgardner: look up guid partition table = gpt
[17:28] <cnd> tgardner: apw: what are we doing about arm branches in maverick?
[17:28] <cnd> will there be any?
[17:28] <tgardner> cnd, not yet
[17:28] <apw> there will be omap in a branch probabally
[17:28] <tgardner> only omap3 in master
[17:28] <eagles0513875> tgardner: http://en.wikipedia.org/wiki/GUID_Partition_Table
[17:28] <apw> eagles0513875, is that uefi related ?
[17:29] <tgardner> perhaps omap4
[17:29] <cnd> tgardner: apw: ok, I will want to check their ftrace config, but I suppose that will have to wait
[17:29] <eagles0513875> apw: i dunno but it already exists in the kernel
[17:29] <mjg59> efi requires gpt, but gpt doesn't inherently require efi
[17:29] <cnd> I've found an issue with the mvl-dove config right now
[17:29] <cnd> and it prevents ureadahead from working
[17:29] <eagles0513875> apw: thing is its not compiled into the desktop versions of the kernel
[17:29] <apw> whats the confiuration option for that
[17:30] <eagles0513875> apw: i dunno take a look at ubuntu server kernel 
[17:30] <eagles0513875> as its already in there 
[17:30] <apw> or i could wait for you to tell me
[17:30] <eagles0513875> apw: im not a kernel expert never really messed with the kernel
[17:31] <eagles0513875> apw: the bug is 578210 and i have the backing of ikonia to get an updated kernel for lucid that has it in it as well as included for future releases
[17:31] <mjg59> CONFIG_EFI_PARTITION
[17:31] <eagles0513875> ?
[17:31] <apw> mjg59, man they didn't try to make it easy did they
[17:32] <tgardner> debian.master/config/config.common.ubuntu:CONFIG_EFI_PARTITION=y
[17:32] <apw> eagles0513875, that config option is the same in gneric and server
[17:32] <eagles0513875> apw: without gpt compiled into the generic kernel i was getting shared object errors with ubiquity
[17:32] <eagles0513875> using ubuntu server i didnt have that issue what so ever
[17:33] <apw> CONFIGS/amd64-config.flavour.generic:CONFIG_EFI_PARTITION=y
[17:33] <eagles0513875> gpt seems to be listed under partition types on the 
[17:34] <apw> CONFIGS/i386-config.flavour.generic:CONFIG_EFI_PARTITION=y
[17:34]  * eagles0513875 goes to download kernel source code
[17:34] <apw> well its truned on and compiled in on both of them
[17:34] <apw> so i suspect its not that that is triggering its lack for you
[17:34] <apw> perhaps its a CD generation related thing
[17:35] <eagles0513875> well i have ikonias backing on this as he is saying its not compiled into the kernel as well if you look at the bug i filed
[17:36] <apw> bug 578210
[17:36] <ubot2> Launchpad bug 578210 in ubiquity (Ubuntu) "ubiquity fails to install kubuntu on lucid 64bit (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/578210
[17:37] <mjg59> eagles0513875: The errors you're reporting have nothing to do with gpt
[17:37] <eagles0513875> mig read down though
[17:37] <eagles0513875> ikonia:  posted something and his recommendation
[17:37] <mjg59> eagles0513875: The errors you're reporting have nothing to do with gpt
[17:37] <vanhoof> May 10 10:46:34 ubuntu ubiquity: WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.
[17:38] <vanhoof> would the server installer use parted by default?
[17:38] <eagles0513875> vanhoof: it must have cuz thats what i used to install no problem
[17:38] <eagles0513875> then proceeded to install kubuntu-desktop
[17:38] <apw> well from the kernel point of view both kernels you site have the same configuration options for GPT
[17:39] <mjg59> sda has a gpt partition table
[17:39] <mjg59> So the fact that you have sda2 means that the kernel supports gpt
[17:39] <mjg59> Otherwise the kernel wouldn't have found the partitions
[17:39] <eagles0513875> mjg59: ok so the problem lies with the installer not using the right program
[17:39] <eagles0513875> mjg59: feel free to make comments on the bug
[17:40] <apw> I've pasted in the configuration options too
[17:41] <mjg59> eagles0513875: You got an input/output error when ubiquity was trying to read the CD
[17:41] <mjg59> eagles0513875: Your CD is bad
[17:41] <eagles0513875> mjg59: i was using a live usb 
[17:41] <eagles0513875> used cd as well
[17:41] <eagles0513875> when i used the ubuntu server cd i didnt have tha tissue
[17:42] <mjg59> It's also nothing to do with the installer using the wrong program
[17:42] <mjg59> partman supports gpt fine
[17:46] <eagles0513875> mjg59: what doesnt make sense is why even after check summing and making sure the cd was fine which it was 
[17:47] <eagles0513875> of kubuntu then why on earth didnt i have the same issues with an ubuntu server cd
[17:47] <mjg59> There may be some other kernel issue that causes corrupted reads
[17:47] <mjg59> But I can't see any way for it to be related to gpt
[17:48] <eagles0513875> mjg59: what my digging dug up originally was that it wasnt compiled into the kernel 
[17:49] <mjg59> eagles0513875: It is compiled into the kernel
[17:49] <eagles0513875> ok 
[17:49] <eagles0513875> ill talk to apachelogger in offtopic about it 
[17:49] <eagles0513875> thanks guys
[17:51] <jjohansen> heading into portland back on in a bit
[18:22] <kees> tgardner: thanks for the acks.  heheh "I ... can find no obvious signs of carnage."  :)
[18:24] <kees> tgardner: any verdict on the ptrace stuff?  it will cause a few surprises for developers, so I want to "announce" it a bit more widely when it does finally land in maverick.
[18:26] <tgardner> kees, well, I never really saw any compromise between you and Scott so I was waiting on that a bit. you seem to be at loggerheads.
[18:26] <kees> no, no, it's simple, he's wrong.  ;)
[18:26] <tgardner> ok :)
[18:27] <kees> like I said in the thread, I acknowledge there will be some pain, but I think the safety of the distro as a whole will improve in the general case.
[18:27] <tgardner> kees, I'm still catching up a bit from UDS. gimme a few days to tinker with it.
[18:34] <kees> tgardner: sure thing, no rush
[20:30] <bladernr> This might be a stupid question, but... is there some way I can, programmatically (in python or shell) set power-management policies without relying on window-manager focused tools?  I was just wondering how to go about setting things like "Sleep after 20 minutes on battery" without needing tools like PowerDevil or GConf
[20:32]  * bladernr is trying to write a test tool that can set idle timeouts on Xubuntu, Ubuntu and Kubuntu without having to rely on tools that are specific to each one individually
[20:32] <kees> bladernr: power management policy is implemented in gnome-power-manager, so gconf is the way to tweak it. the are commandline tools to manipulate gconf
[20:32] <bladernr> kees:  but gnome-power-manager doesn't work in Kubuntu :( at least not without installing it (and potentially other GNOME specific things)
[20:33] <kees> yup :(
[20:33] <bladernr> I guess I was just hoping there was something central in /sys or /proc that gnome-power-manager and KDEs version both touch in the kernel to set these things
[20:33] <kees> it sue seems like something freedesktop should standardize
[20:34] <kees> *sure
[20:34] <bladernr> Honestly, I'm really surprised that it isn't... I was sure that this was going to be a trivial test case to write... now not so much :(
[20:35] <kees> ultimately something needs to determine what "idle" means, and that's what not common to each windowing system
[20:35] <bladernr> kees:  yeah... good point.  
[21:09] <jjohansen> ogasawara: can you change priority on a couple blue prints for me
[21:15] <ogasawara> jjohansen: sure, which ones
[21:16] <jjohansen> ogasawara: https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-pv-ops-ec2-kernel
[21:16] <jjohansen> https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-apparmor
[21:17] <ogasawara> jjohansen: what priority do you want me to set for em?
[21:18] <jjohansen> ogasawara: I not sure, medium or high for a couple of the items best the rest are low
[21:18] <jjohansen> can we reset the priority after alpha-1
[21:18] <ogasawara> jjohansen: sure, I'll just set to medium for now
[21:18] <jjohansen> ogasawara: thanks