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