| === sconklin is now known as sconklin-gone | ||
| === solarion_ is now known as solarion | ||
| === RAOF_ is now known as RAOF | ||
| * lag waves | 07:00 | |
| === lag_ is now known as lag | ||
| cking | lag, morning! | 07:09 |
|---|---|---|
| lag | cking, Hi ya! | 07:24 |
| lag | You're up early | 07:24 |
| cking | lag, you up early too! | 07:25 |
| 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:26 |
| cking | lag, me neither | 07:27 |
| lag | cking: I'll have to change that soon - I don't want to burn myself out | 07:27 |
| cking | lag, indeed | 07:28 |
| * abogani waves | 07:30 | |
| cking | hi abogani | 07:31 |
| lag | cking: How's your scripting? | 07:32 |
| abogani | cking: Good morning! | 07:32 |
| cking | lag, scripting? please elaborate? | 07:32 |
| 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:33 |
| lag | :) | 07:34 |
| lag | Can EOD be anything? Or is it defined? | 07:34 |
| cking | technically called "here strings", can be any terminal word, man bash, look for "Here Strings" | 07:35 |
| === cking is now known as cking-afk | ||
| cking-afk | back in 10 | 07:37 |
| * abogani is wondering if exist a way to temporarily turn off Ubuntu kernel bugs email notifications... | 07:39 | |
| abogani | Sorry for my English: it is usually horrible but today I'm moreover particularly sleepy... | 07:40 |
| === cking-afk is now known as cking | ||
| cking | abogani, no idea - it would be good to stop the incoming deluge! | 07:46 |
| abogani | cking: Perhaps Leann could know that. | 07:47 |
| abogani | ogasawara: ^ | 07:47 |
| 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 | 07:49 |
| * abogani is wondering why embedded youtube video don't work anymore... | 08:48 | |
| * apw ywans | 08:57 | |
| cking | morning apw | 08:57 |
| * lag waves at apw | 08:58 | |
| apw | morning all | 08:58 |
| abogani | apw: morning | 08:59 |
| 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:05 |
| 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:24 |
| cking | more explicit the naming the better in my opinion as long as it does not involve much more typing | 09:25 |
| abogani | cking: Normal users use GUI so no matter how long the name is. | 09:29 |
| cking | abogani, true | 09:30 |
| 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:32 |
| 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:36 |
| 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:48 |
| lag | Okay, I'm working on bug583128 | 09:52 |
| lag | I think I have fixed it | 09:52 |
| 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:53 | |
| * lag thinks he needs to get off the water and start drinking coffee | 09:54 | |
| 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:57 |
| 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:58 | |
| jk- | lag: oh, i meant about the coffee, no the commit details :) | 09:59 |
| jk- | *not | 09:59 |
| lag | Phew! | 09:59 |
| 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:00 |
| 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:01 |
| 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:03 |
| apw | BAH its out of date already | 10:04 |
| jk- | it does mention the "hardy tree" :) | 10:05 |
| apw | heh i think i might have written it given the s-o-b | 10:05 |
| 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:06 |
| apw | gah the wiki is as slow as hell, all those stooopid emails being synchronous | 10:22 |
| persia | lag, apw: Would you guys like a quick outline of how to set up auto-emulating chroots? | 10:29 |
| lag | persia: Can't hurt :) | 10:30 |
| jk- | yes | 10:30 |
| lag | persia: I'm currently hacking smb's remote-scripts to work | 10:30 |
| persia | Do you already use mk-sbuild to set up the schroots you use to build? | 10:31 |
| lag | persia: Nope | 10:32 |
| lag | I use smb's scripts | 10:32 |
| lag | To start the builds remotely | 10:32 |
| 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:33 |
| 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:34 |
| persia | You so want to migrate to schroot. | 10:35 |
| * persia has been using schroot since feisty with happy results | 10:35 | |
| 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:37 |
| 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:38 |
| persia | Mostly a matter of RAM. Stick 8G on a native box, and it would be that fast too. | 10:39 |
| apw | yeah its not got quite that much unfortuantly, though it seemed to be CPU bound from the groaning from the fans | 10:40 |
| persia | heh. Emulation isn't cheap :) | 10:42 |
| apw | no, but at least it did build so i could 'test' the userspace | 10:43 |
| apw | persia, the resulting chroot, is that setup to be arm-like should you just schroot into it? | 10:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:49 |
| 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:50 |
| persia | Interesting... | 10:51 |
| lifeless | http://en.wikipedia.org/wiki/Itanium#Architectural_changes | 10:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| apw | for me i am continuing as i am, but i am adding this new armel thingy to my arsenal | 10:57 |
| 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 | 10:58 |
| lag | I think I'm mainly interested in test builds? | 11:02 |
| 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:03 |
| persia | (although it's usually 95+% similar) | 11:04 |
| 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:15 |
| 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:16 |
| persia | (for all that I'm often too lazy to dispatch a remote build, and end up doing it locally in emulation) | 11:17 |
| 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:31 |
| 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:32 |
| lag | But in my case the remote hasn't even checked out x yet - so what happened in the push? Nothing? | 11:35 |
| 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 | 11:40 |
| 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:39 |
| lag | And received this: f0819aa..eb33bb9 lp583128 -> lp583128 | 12:40 |
| lag | Neither repos are on branch lp583128? | 12:40 |
| apw | well you asked ti to push _all_ branches right | 12:41 |
| lag | Then why doesn't it attempt to push master or ti-omap? | 12:42 |
| 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:43 |
| lag | Ah, because it is the only with commits? | 12:44 |
| apw | because the local and remote are identicle perhaps ? | 12:44 |
| apw | you could test by commiting something to one of the others | 12:45 |
| apw | and see if it then appears | 12:45 |
| lag | k | 12:47 |
| 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:00 |
| Amarendra | where should i go? | 13:01 |
| popey | #ubuntu probably | 13:10 |
| === cking is now known as cking-afk | ||
| cking-afk | food | 13:23 |
| apw | lag, target-scripts/run-clean: git checkout -f "${BRANCH}" | 13:47 |
| lag | apw: ack | 13:48 |
| tgardner | apw, is mumble up? I keep getting rejected. | 13:53 |
| 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:54 |
| apw | tgardner, i think it asks me for my password every time | 13:55 |
| * apw tries | 13:55 | |
| apw | hrm, not its remembered something somwhere | 13:56 |
| cking-afk | fail | 13:56 |
| === cking-afk is now known as cking | ||
| apw | cking, fail ? | 13:56 |
| cking | apw, mumble passwd recall | 13:56 |
| 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:57 |
| apw | tgardner, it seems to record everything in .config/Mumble, so if you get desperate removing that may help | 13:59 |
| 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 :/ | 14:00 |
| === sconklin-gone is now known as sconklin | ||
| vanhoof | pgraner: tgardner: ping | 15:25 |
| vanhoof | can either of you set ~ayan up in c-k-t and u-k lp groups? | 15:25 |
| tgardner | vanhoof, can do. gimme a bit | 15:28 |
| vanhoof | tgardner: thanks, just helping him get setup :) | 15:28 |
| tgardner | vanhoof, whats his LP ID? There are a bunch of ayan's | 15:31 |
| vanhoof | tgardner: https://edge.launchpad.net/~ayan | 15:31 |
| 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:56 |
| tgardner | TeTeT, that was on the k-t list, right? | 15:58 |
| TeTeT | tgardner: nope, private email | 15:58 |
| 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 | 15:59 |
| 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:00 |
| TeTeT | tgardner: fair enough, thanks | 16:01 |
| tgardner | you don't have to explain for whom the request is submitted | 16:01 |
| TeTeT | tgardner: ok, I've anonymized the email, that shall do | 16:03 |
| tgardner | TeTeT, ok, we'll take a look | 16:04 |
| 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:17 |
| cnd | so do you want to just handle it when it hits, or should I send a revert for it now? | 16:18 |
| 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:19 |
| 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:20 |
| cnd | there are other changes to upstream sched.c though, so you may hit conflicts if you pick it now | 16:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| TeTeT | tgardner: thanks for the swift answer | 16:25 |
| tgardner | TeTeT, np | 16:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| vanhoof | sconklin: i was nominated for this one, not by choice ;) | 16:30 |
| === JFo is now known as JFo-swap | ||
| tgardner | vanhoof, thats 'cause you're the new guy and don't know what you're getting into. | 16:30 |
| === kamal-away is now known as kamal | ||
| sconklin | vanhoof: as it turns out, I do have some opinions about this :) I'll compose a response | 16:32 |
| jjohansen | hehe: http://www.google.com/ | 16:34 |
| jjohansen | and its playable | 16:35 |
| * 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:37 |
| 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:38 |
| kamal | jjohansen: wow, that's awesome | 16:41 |
| jjohansen | :) | 16:42 |
| JFo-swap | ogasawara, I've no clue how linux( | 16:43 |
| JFo-swap | Ubuntu) was changed | 16:43 |
| ogasawara | JFo-swap: yah, I'm a bit confused too as both packages show the Ubuntu Kernel Team as being the maintainer | 16:44 |
| 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:45 |
| 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:46 |
| JFo-swap | I think I already am | 16:47 |
| JFo-swap | oh, that is the capital L one | 16:47 |
| JFo-swap | yeah | 16:47 |
| * ogasawara back in 30min | 16:49 | |
| 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:52 |
| 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 | 16:53 |
| tgardner | eagles0513875, what is a gpt? | 17:13 |
| tgardner | ginormous partition table? | 17:13 |
| 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:14 |
| 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:15 |
| shadeslayer | /whois tgardner | 17:16 |
| shadeslayer | whopps :P | 17:16 |
| * shadeslayer thinks tgardner is probably doing the same thing back right now :P | 17:16 | |
| tgardner | eagles0513875, there are no differences between the desktop and server kernel configs that would affect partition tables or sizes. | 17:17 |
| eagles0513875 | tgardner: thing is only recently large hard drives over 1tb are becoming more main stream in desktops | 17:25 |
| 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:26 |
| tgardner | apw, do you know what gpt is 'cause I'm not finding it ? | 17:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| apw | CONFIGS/amd64-config.flavour.generic:CONFIG_EFI_PARTITION=y | 17:33 |
| eagles0513875 | gpt seems to be listed under partition types on the | 17:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| apw | I've pasted in the configuration options too | 17:40 |
| 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:41 |
| mjg59 | It's also nothing to do with the installer using the wrong program | 17:42 |
| mjg59 | partman supports gpt fine | 17:42 |
| eagles0513875 | mjg59: what doesnt make sense is why even after check summing and making sure the cd was fine which it was | 17:46 |
| 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:47 |
| === cking is now known as cking-afk | ||
| eagles0513875 | mjg59: what my digging dug up originally was that it wasnt compiled into the kernel | 17:48 |
| 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:49 |
| jjohansen | heading into portland back on in a bit | 17:51 |
| kees | tgardner: thanks for the acks. heheh "I ... can find no obvious signs of carnage." :) | 18:22 |
| 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:24 |
| 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:26 |
| 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:27 |
| kees | tgardner: sure thing, no rush | 18:34 |
| === pgraner is now known as pgraner-afk | ||
| 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:30 |
| * 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:32 |
| 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:33 |
| 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:34 |
| 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. | 20:35 |
| jjohansen | ogasawara: can you change priority on a couple blue prints for me | 21:09 |
| ogasawara | jjohansen: sure, which ones | 21:15 |
| 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:16 |
| ogasawara | jjohansen: what priority do you want me to set for em? | 21:17 |
| 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 | 21:18 |
| === sconklin is now known as sconklin-gone | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!