[06:41] <pitti> Good morning
[06:42] <pitti> bdmurray: darn, it got its core dump removed already; but I'll look for a few apport-failed-retrace armhf bugs
[06:45] <pitti> infinity: I don't think that putting upstream changelogs into any .deb is making good use of storage space and download bandwidth; but for -doc packages I'm okay with letting them back in
[06:53] <infinity> pitti: Well, in the case of glibc-doc, the upstream changelogs are intentionally included as part of documenting the package.
[06:53] <infinity> pitti: I don't feel particularly strongly about it, mind you.
[06:54] <infinity> pitti: (I only noticed because of a lintian warning in Debian about the upstream changelog having a non-conforming name, and then noticed we don't ship it at all in Ubuntu) :P
[07:48] <dholbach> good morning
[07:58] <ion> that
[11:28] <ogra> wow, seems Laney had a busy weekend
[11:28] <Laney> heh
[11:28] <Laney> scripts are powerful things :P
[11:32] <ogra> W:Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/raring/main/source/Sources  406  Not Acceptable
[11:32] <ogra> *sigh*
[11:32] <ogra> why the heck do i randomly see 406 errors since last week
[11:39] <ogra> oh
[11:40] <ogra> http://de.archive.ubuntu.com/ubuntu/dists/raring/main/source/Sources actually tells me there is no uncompressed file named "Sources", there are .gz and .bz2 variants though ... do we have an apt bug ?
[11:40] <cjwatson> Always been that way
[11:40] <ogra> hmm, why does apt try to download the uncompressed file then
[11:41] <cjwatson> I think the URL in the error is just misleading
[11:41] <cjwatson> strace or tcpdump or whatever if you want to see what it's actually doing
[11:41] <ogra> well, the url actually gives me an apache error page
[11:41] <ogra> "Not Acceptable"
[11:41] <cjwatson> Sure, but I doubt that's the URL it actually got the root-cause error from
[11:41] <ogra> pointing out that there are gz and bz2 files of this file available
[11:41] <cjwatson> Like I say, get a proper trace rather than relying on that error message
[11:42] <cjwatson> Because it was probably a knock-on error from something else
[11:42] <cjwatson> (Yes, it might have got some other error, tried to fall back to the uncompressed variant, and then got 406 - but that just means the 406 is hiding some real error behind it)
[11:44] <ogra> ok, server side i can at least grab the gz and bz2 files manually so yeah, your theory sounds right
[11:44]  * ogra wonders why his 12.04 desktop feels so much more buggy than raring in so many areas 
[11:47] <ogra> (screen locking doesnt work properly, update-manager is undiscoverable once it auto-started and sits in your launcher (you can click it doesnt come up) ... and now since mid last week this apt issue))
[11:48] <ogra> oh, and we should consider ripping the weather indicator out of precise if nobody fixes it
[11:53] <Laney> it's had several SRUs
[11:55] <sladen> ogra: then people would just go back to using windows
[11:55] <ogra> Laney, none that fixed anything (at least for me)
[11:57] <ogra> it reliably crashes after about a day
[11:57] <ogra> stat("/var/lib/apt/lists/de.archive.ubuntu.com_ubuntu_dists_raring_main_source_Sources", {st_mode=S_IFREG|0644, st_size=4104933, ...}) = 0
[11:57] <ogra> write(1, "\r                               "..., 214) = 214
[11:57] <ogra> write(16, "600 URI Acquire\nURI: http://de.a"..., 546) = 546
[11:57] <ogra> hmpf
[11:57] <ogra> is there any way to see the full URL here in strace ?
[11:58] <ion> -s10000
[12:00] <ogra> hmm, intresting, with that it hangs with "Waiting for headers" at some point at the end
[12:01] <ogra> ah, there we go ... it hung for nearly 2min
[12:05]  * cjwatson scratches his head
[12:05] <cjwatson> jdstrand: Do you know how chromium-browser got from raring-proposed to raring?  The proposed-migration logs don't mention it anywhere, and it seems to have been done slightly incorrectly (i.e. left in -proposed)
[12:05] <cjwatson> And +publishinghistory doesn't say who copied it, which is weird
[12:09] <Laney> Does it usually? I thought that it only shows the user for deletes
[12:09] <Laney> From: in -changes is the copier AFAIK
[12:11] <cjwatson> Laney: I fixed +publishinghistory to show the copying user back in August
[12:11] <cjwatson> But yes, raring-changes shows it copied manually by jdstrand
[12:11] <cjwatson> jdstrand: Please don't ever do this
[12:12] <cjwatson> If you find you need to, (a) you're probably hiding a problem somewhere else, (b) there are other ways to do it (britney hints)
[12:12] <cjwatson> (I suspect perhaps my +publishinghistory fix only shows the copier when the publication record was copied from another distribution)
[12:13] <Laney> The one I was looking at was an SRU, so that would match
[12:13] <cjwatson> jdstrand: Did you check update_excuses before doing the copy?
[12:14] <cjwatson> Unfortunately we don't log that so I can't retroactively check what might now be uninstallable as a result of the copy
[12:14] <zequence> Hi, I'd like a bit of help regarding a SRU. bug 956438. I've got a branch of jackd2 whcih fixes a bug in quantal and precise, which I would like to get uploaded to proposed. I've followed all the procedures from what I can see.
[12:16] <zequence> I've got testing packages (still building) at ppa:zequence/sru
[12:17] <zequence> My branch is this lp:~zequence/ubuntu/raring/jackd2/fix-for-956438
[12:21] <zequence> ah, I see ScottK was doing some work on the bug
[13:23] <jdstrand> cjwatson: hi
[13:25] <jdstrand> cjwatson: I did do the copy, yes. chromium-browser was rather horribly out of date on raring and while the armhf patches are being worked on, I decided that it was more important for our i386 and amd64 users to have the security update, and then to have the armhf fix uploaded soon
[13:26] <cjwatson> jdstrand: If you're going to do such things, please do them by the medium of britney hints, not by manual copies to the development release
[13:26] <cjwatson> Ah, you're not in ~ubuntu-release, so you'll need to get a member of that team to do it
[13:27] <jdstrand> cjwatson: I was unware of britney hints, and I don't see it documented in ArchiveAdministration. can you point me to how to do this?
[13:27] <cjwatson> jdstrand: Archive admins technically still can copy to raring, but must not
[13:27] <cjwatson> jdstrand: you'll have to get one of the release team to do it, but plenty of us are around at all kinds of strange hours ...
[13:28] <jdstrand> I don't plan on doing this regularly or anything-- I didn't know it was a horrible no no. I knew armhf was broken, and I figured we'd got an out of date for it , which would be fixed soon. I figured the security update for rariing was more important than that line item
[13:29] <jdstrand> I'm sorry if it caused a problem
[13:29] <cjwatson> It's bad because we have no way to track what it broke
[13:30] <cjwatson> With britney hints, you can override specific things ("OK, I understand that excuses says that this is wrong, but try the update anyway") and still have checks for other things
[13:30] <cjwatson> And it gives us a record in bzr of what's been done manually
[13:30] <cjwatson> In general since we have this mechanism available we shouldn't bypass it
[13:30] <jdstrand> cjwatson: can you add something to ArchiveAdminstration stating something appropriate for archive admins? I would, but probably wouldn't be able to convey what you would want me to
[13:31] <cjwatson> Well - this kind of copy isn't documented at all in ArchiveAdministration right now
[13:31] <cjwatson> So it's hard to find something to attach it to
[13:32] <jdstrand> I was thinking conceptually it wasn't any different than copying from -proposed to -updates
[13:32] <cjwatson> That isn't owned by a mechanism
[13:32] <cjwatson> So it's quite different
[13:32] <jdstrand> I'm not saying I was right, just that it seemed the same
[13:32] <jdstrand> or rather, similar
[13:33] <jdstrand> hey, my wrist was slapped (sorry) and I won't do it again. I'm just saying I didn't know I should not and that documenting it might help someone in the future
[13:36] <jdstrand> (well, I knew I shouldn't generally, but I didn't know that an aa wasn't allowed to do what I did in exceptional cases)
[13:36] <cjwatson> jdstrand: How about https://wiki.ubuntu.com/ArchiveAdministration#Other_copies ?
[13:37] <jdstrand> cjwatson: I think that works very well. thanks
[13:38] <cjwatson> Thanks - I was mostly surprised because I thought I had disseminated this information, but it's possible I only did so by IRC, which wouldn't be atypical for me :-)
[13:38]  * ogra sets up a mail redirect for all the ARM whiners to jdstrand's inbox
[13:38] <jdstrand> ogra: they are no worse off than before. the patches are actively be worked on :)
[13:39]  * jdstrand redirects the redirect to chromium devs
[13:39] <ogra> well, curerent chromium trashes all my arm desktops anyway (likely due to an incompatible cairo it ships)
[13:40] <ogra> cant be worse ... but we have a lot of people complaining since a while
[13:40] <jdstrand> ogra: if he doesn't already know, you might let chad know about that
[13:41] <ogra> jdstrand, well, what we have is horridly outdated anyway  and only broken like this in raring atm (wehich will soon get updated)
[13:41] <jdstrand> right, so hopefully once the new one is working, maybe it'll be fixed
[13:41] <ogra> if it still shows after the update i'll talk to him
[13:41] <jdstrand> fair enough. fyi, chad from the desktop team is your man
[13:41] <jdstrand> cool
[13:42] <ogra> (you can easily try on a nexus7 btw, after a while all fonts get corrupted)
[13:46] <test___> a dev told me to ping him on IRC because of a bug (he gave me his username and said on freenode. Please forgive me the stupid question but how to ping someone, if i do not know the channel?
[13:47] <mjt> test___: /msg somewhere sometest
[13:47] <mjt> someONE not someWHERE ofcourse
[13:48] <test___> mjt ist it possible to do this with http://webchat.freenode.net/
[13:48] <mjt> oh no idea.
[13:48] <mjt> i never used webchat
[13:48] <test___> what client to use on ubuntu?
[13:48] <ogra> test___,  you usually just type: <nickname> ping
[13:49] <mjt> if he's in the channel
[13:49] <ogra> directly messaging someone without asking first is usually considered kind of rude
[13:49] <mjt> yesterdays talk is more or less an agreement in this case
[13:50] <test___> orga, he asked me to do so ...  i do not know the channel, just the username and freenode
[13:50] <ogra> he said to ping him
[13:50] <ogra> and if he is an ubuntu dev he is most likely around here
[13:58] <infinity> ogra: I'm not sure which culture that "ask me in public if you can ask me in private" thing came from, but some of us find it irritating. :P
[13:59] <infinity> ogra: It's like asking if you can ask a question.  You've just wasted my time with something completely devoid of content.
[13:59] <infinity> (Now, public *questions* are better than private, cause someone else might jump in and answer, but if I ask someone to poke me, I actually prefer a direct query, easier to track)
[13:59] <ogra> infinity, well, i tend to ignore unasked pings (especially if the content just says "ping" without any question)
[14:00] <infinity> ogra: I only get completely contentless pings from people I work with.  *cough*
[14:00] <infinity> ogra: Community people are, on the whole, much better about braindumping at me in query windows.
[14:00] <ogra> heh
[14:00] <test___> okay i installed xchat and user "/msg someone test , but how can i be sure this user exists?
[14:00] <ogra> lucky you
[14:01] <infinity> test___: It should whine at you if you tried to send a /msg to no one.
[14:02] <cjwatson> Yeah, in particular the "ask me in public if you can ask me in private" thing often enough causes me to have to catch up on scrollback in some window just to find out that it lit up due to somebody who could just have queried me directly
[14:02] <cjwatson> (OK, this is a slight artifact of the way I read IRC, but still)
[14:03] <test___> it does not, i tried many random names, which cannot exist all for sure
[14:03] <infinity> cjwatson: I suspect you and I IRC very similarly. :P
[14:03] <ogra> test___, check the server tab in xchat
[14:04] <ogra> server error messages usually show up there
[14:04] <infinity> ogra: I don't use xchat, but I assume it would have opened a query tab with the user he was /msging, if it had worked, no?
[14:04] <ogra> yes
[14:04] <ogra> but it wont print errors in there
[14:04] <infinity> No, but you'd also have no tab.
[14:05] <infinity> Which is, itself, an indication of an error. :P
[14:05] <ogra> err, /msg doesnt open a tab anyway
[14:05] <ogra> i think thats /query
[14:06] <ogra>  /query ogra12345 foo
[14:06] <ogra> that properly opens an empty tab here
[14:06] <ogra> and the server tab has:
[14:06] <ogra> * ogra12345 :No such nick/channel
[14:06] <infinity> That's... Rather unintuitive.
[14:06] <ogra> thats how xchat handles it
[14:06] <ogra> server msgs go to the server tab
[14:07] <ogra> (i agree though)
[14:07] <infinity> If I chant "abra-cadabra, make me a shawarma", and lack magical skills to actually make sandwiches happen, I don't expect an empty wrapper to appear.
[14:07] <infinity> I want a sandwich, or nothing. :P
[14:07] <infinity> ogra: No, no.  The error going to the server tab is fine, it's the query tab being spawned with no query that's unintuitive, IMO.
[14:07] <ogra> but now you obnly need the sandwich, not the wrapooer anymore :P
[14:08] <ogra> in case you want to take your sandwich with you in the bus
[14:09] <davmor2> ogra: do you get drawing issues with onboard?  for example if I hit the shift button the top of the arrow disappears leaving me with a squared u.
[14:09] <ogra> davmor2, rarely but yes
[14:09] <ogra> lets see how maliit behaves in that regard, it should have entered the archive by now i guess
[14:09]  * ogra didnt check
[14:10] <ogra> its on my plan this week to test maliit integration
[14:13] <scott-work> infinity: do you have a minute to talk about a possible SRU? i wanted some advice before preceeding
[14:14] <infinity> scott-work: Sure, shoot.
[14:15] <davmor2> ogra: also I get really inconsistent keyboard popup on dash home.  First time seems fine but any time after that seems to be a 50-50 chance on it opening.
[14:15] <scott-work> after 12.04 we (ubuntu studio) added a few new metas for publishing and photography. these aren't being picked up during 12.04 -> 12.10 upgrade. we have an idea on fixing this but wasn't sure it was the "proper" way to handle this
[14:15] <scott-work> infinity: oops ^^^
[14:15] <ogra> davmor2, yeah, thats supposed to be fixed in upstream onboard already
[14:16] <scott-work> infinity: our thought was to update the -desktop meta and explicitly include these two metas, but it seemed a little hacky
[14:17] <davmor2> ogra: nice, btw if there is anything you need testing confirming I got my nexus 7 just to play with ubuntu on so feel free to ping me
[14:17] <infinity> scott-work: Well, if you want people to be able to have desktop installed, but remove the other metas, that's not a good solution.
[14:17] <infinity> scott-work: Are they meant to be there on a "default install", but readily removable?
[14:17] <ogra> davmor2, i just uploaded a fix for the sound issue, see if you have sound on boot (still muted, but should work without suspend cycle)
[14:17] <infinity> scott-work: If so, you probably want to quirk the release-upgrader to add them on upgrades.
[14:18] <scott-work> infinity: if possible, that would be prefered
[14:19] <scott-work> infinity: is there any information on how to do this that i can read or an example already being used?
[14:26] <davmor2> ogra: are you using proposed for this other wise I don't have it yet
[14:28] <infinity> scott-work: It might be as simple as adding those packages to PostUpgradeInstall in the [ubuntustudio-desktop] section of data/DistUpgrade.cfg
[14:29] <scott-work> infinity: super cool. i'll dig into that. thank you very much :)
[14:30] <infinity> scott-work: There was a "might" in that sentence for a reason, you'll definitely want to do some testing. :P
[14:31] <scott-work> infinity: oh yeah, i caught that ;)
[14:31] <ogra> davmor2, it was just uploaded, be patient until the next publisher run :)
[14:31] <infinity> scott-work: And doing only that will probably have the unfortunate side effect of reintrodcing those packages after every upgrade (when you really only want it from 12.04 to 12.10 and 12.04 to 14.04), but either that's a wart you can live with, or you get to look at more fine-grained quirking.
[14:32] <infinity> scott-work: (By "every upgrade", I mean between releases, of course, not every single time a user upgrades packages or anything silly like that)
[14:33] <infinity> scott-work: But maybe that's exactly the behaviour you want anyway, so users get reset to a known good state on each dist upgrade (which is sort of one of the primary goals of ubuntu-release-upgrader)
[14:33] <scott-work> infinity: right, right. that seem a very reasonable wart though to make sure these packages are installed upgrading from 12.04 -> 12.10
[14:37] <zequence> infinity: I wonder if it would be possible to add a query about it for the user upgrading the system
[14:38] <infinity> zequence: Anything is possible, I suppose, though release-upgrader currently tries really hard not to ask questions.
[15:17] <dholbach> stgraber, highvoltage: I didn't notice that a regular call of mine was moved permanently - I thought it was a one-off. This would mean we would have to move our hangout either an hour earlier or half an hour later - I'm sorry about that. :-/ Would that still work for you? Or would it have to be another day?
[15:29] <stgraber> dholbach: half an hour later should be fine
[15:29] <dholbach> yeehaw
[15:29] <dholbach> that'll be the last move of this hangout now :)
[15:36] <bdmurray> pitti: did you find armhf crash?
[15:37] <davmor2> ogra: still no sound fix however there are now 2 bluetooth indicators that both work and look different
[15:37] <ogra> intresting, thats a virgin image ?
[15:38] <ogra> i surely dont have that here
[15:38] <ogra> davmor2, rm /var/lib/alsa/asound.state ... reboot and see if sound works then
[15:39] <ogra> (sudo indeed)
[15:40] <Laney> cjwatson: Do I remember correctly that copyPackages doesn't generate -changes emails?
[15:40] <davmor2> ogra: this was a fresh install on friday an then updates over the weekend, I enabled proposed and backports just to pull in your sound fix and that is the only non vanilla part
[15:40] <cjwatson> Laney: Correct
[15:40] <ogra> very strange i dont have two BT indicators here
[15:40] <cjwatson> Indeed that's its purpose
[15:41] <cjwatson> Laney: What are you trying to do, though?  Generally copyPackages should only be used by auto-sync
[15:41] <ogra> though i havent changed my sources.list, using all defaults here
[15:42] <Laney> Considering using it when syncing zillions of a certain class of package at once to avoid being complained at
[15:42] <Laney> Not sure the complaints are justified though
[15:42] <davmor2> ogra: I have one that has 2 switches and one that has a list similar to quantal and precise I'll take a couple of screenshots in a second
[15:43] <cjwatson> Laney: I wouldn't, personally ...
[15:44] <davmor2> ogra: sound fix no in place and working as you say sound is still muted on start up but then is fine after
[15:44] <ogra> davmor2, right, thats known and we already have a better fix, good to know it works though
[15:44] <davmor2> s/no/now
[15:45] <Laney> well I don't consider it a problem. It would be only in the interests of inter-developer harmony
[15:50] <seb128> davmor2, ogra: unity trunk (and the upload from today) recommends the new indicator-bluetooth, that will duplicate the indicator
[15:50] <davmor2> ogra: this http://ubuntuone.com/68vJk5z8TAtGgZJdTuxtQs vs this http://ubuntuone.com/48NahUoCdw6FMvMb26TTUX
[15:51] <ogra> seb128, aaah, thanks !
[15:51] <seb128> davmor2, ogra: I need to drop the old indicator but I was waiting for unity to get upload ... do you guys run unity ppa?
[15:51] <davmor2> seb128: that would do it then
[15:51] <ogra> davmor2, so ignore it ;)
[15:51] <ogra> seb128, no, but unity entered the archive today i think
[15:51] <davmor2> seb128: I don't this was just with proposed and backport enabled
[15:52] <seb128> davmor2, oh, proposed enabled, ok
[15:52] <ogra> if i read that right between all the haskell spam
[15:52] <seb128> ogra, well, it was uploaded 50min ago, that's what I call jumping on updates :p
[15:52] <ogra> haha
[16:01] <davmor2> seb128: to be fair I was trying repeatedly to pull in the update for sound and there were no updates that made me think to add proposed and try again then I got a bunch of update
[16:04] <pitti> bdmurray: sorry, still on my list
[16:05] <cjwatson> davmor2: raring-proposed?
[16:05] <davmor2> cjohnston: yes
[16:05] <cjwatson> davmor2: I really, really don't recommend that even for QA - the point of raring-proposed is to perform automatic checks before humans have to waste their time with things
[16:05] <davmor2> cjwatson: yes even
[16:05] <davmor2> cjohnston: sorry
[16:06] <cjwatson> (And raring-backports is probably empty)
[16:06] <davmor2> cjwatson: indeed I'm going to switch it back off again now :)
[16:16] <xnox> BenC: infinity: how come powerpc is so oversized compared with the rest of desktop images? ubuntu/daily-live: raring-desktop-powerpc.iso oversized by 139128256 bytes (940128256)
[16:28] <cjwatson> tjaalton: Do you know if anyone can verify bug 804109
[16:28] <cjwatson> ?
[16:30] <cjwatson> mterry: Are you able to verify bug 1083237?
[16:30] <mterry> cjohnston, not on my current machine, and I'm in a coffee shop.  But I can tomorrow
[16:31] <mterry> cjwatson, ^ whoops
[16:31] <infinity> xnox: Probably because someone thought that shipping 4 kernels on it would be a swell idea.
[16:31] <cjwatson> Daviey: Can anyone on your team verify that the fix for bug 901600 meets your needs?
[16:32] <Daviey> cjwatson: wilco, thanks
[16:32] <xnox> infinity: =( and no magic to make them smaller / combined (e.g. is stuff for arm kernel consolidation applicable to powerpc at all?!)
[16:32] <infinity> BenC: Do you actually do desktop installs on your server kit?  Is there any value at all in having -e500* on the desktop CDs?
[16:33] <infinity> xnox: ppc/ppc64 obviously can't be combined anymore than i386/amd64 can be, as for the e500 stuff, there are apparently fundamental platform reasons why they can't be a single zImage right now, though I keep forgetting what those reasons are. :/
[16:33] <xnox> fair enough.
[16:34] <xnox> It's just 140MB oversize is excessive....
[16:34] <infinity> (It's a bit ironically tragic, given that PPC has some of the best multi-platform support in the kernel tree)
[16:34] <infinity> (And most of that was cargo-culted for the ARM consolidation)
[16:34] <bdmurray> barry: could you have a look at bug 1112496?
[16:35] <xnox> infinity: might as well build 4x images, since the test matrix has been exploded anyway. (reuse squashfs but add/rm different kernels?!)
[16:35] <infinity> xnox: Ew.  No.
[16:36] <infinity> xnox: If one image can boot on all the hardware, validating 4 images is silly.
[16:36] <infinity> xnox: That said, the e500 kit is pretty much all server kit anyway, so dropping those two kernels from the desktop image may well be sane.
[16:36] <barry> bdmurray: i've been more or less deferring that one to doko because he uploaded the pillow support and (i think) wasn't to thrilled with my previous attempts at packaging that stuff up. ;)  dunno if/when he's around (he's not right now), but perhaps we should just assign the bug to him for now and i can look at it if he's going to be away for a while
[16:36] <infinity> xnox: (There's also the part where, since we ditched CD-sized images, we have some leeway here, and can just declare that PPC gets to be bigger and be done with it)
[16:37] <bdmurray> barry: I'll assign it to him and we can talk about it Wed if need be
[16:37] <xnox> infinity:  yeah, i know. 4 ppc images would be silly =) bigger is fine, but 140MB is a bit too big. Do all of the supported systems have dvd drives & drivers?
[16:37] <barry> bdmurray: +1 thanks
[16:38] <infinity> xnox: A bit "too big", why?
[16:38] <infinity> xnox: Once it's bigger than a CD, how big is too big?
[16:38] <xnox> infinity: was quantal ppc bigger than cd?
[16:39] <xnox> infinity: i thought that somebody complained about lack of dvd, but now i can't remember if it was lack of blanks to burn or lack of dvd-drive in the powerpc box.
[16:39] <infinity> xnox: I don't see quantal/desktop for PPC at all.
[16:39] <xnox> quite a difference there.
[16:39] <infinity> xnox: Lots of old PPC kit won't have shipped with DVD drives.  This is no different from lots of old x86 kit.
[16:41] <xnox> cause e.g. pointless to have old powerpc kernels on the desktop DVD, if none of those machines had a dvd drive =)))))
[16:41] <xnox> anyway, not terribly important for now =)
[16:41] <infinity> Define "old".
[16:41] <infinity> ppc64 boots hardware that ships today.
[16:41] <xnox> kk.
[16:42] <infinity> e500 isn't "the new PPC platform", it's just "a different one".
[16:42] <infinity> And yes, ideally, it should be consolidated into the ppc32 kernel.
[16:42] <infinity> (and e6500 should be consolidated into the ppc64 one)
[16:42] <infinity> But, as I said, there are currently technical difficulties with that.
[16:43] <infinity> I'm still all for dropping those kernels from the desktop media, though, if BenC concurs.
[16:43] <stokachu> cyphermox: ping
[16:51] <bdmurray> slangasek: bug 1096022 doesn't seem to be occurring much anymore and the virtual machine I finally created is not encountering it either.
[16:51] <bdmurray> https://jenkins.qa.ubuntu.com/view/Precise/view/Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-universe/
[16:51] <bdmurray> the last failure was on 1/21
[16:52] <slangasek> bdmurray: well, that's vaguely satisfying then ;)
[16:54]  * infinity raises an eyebrow.
[16:54] <bdmurray> psivaa: Please let us know if that upgrade fails again.
[16:55] <infinity> I kinda want to know how we accidentally fixed it.
[16:56] <cjwatson> jdstrand: Any reason secureboot-db shouldn't be copied to {precise,quantal}-updates?  There's no verification bug for it.
[16:56] <cjwatson> Oh, yes there is, the report just isn't finding it ...
[16:56] <psivaa> bdmurray: ok, will do, but did not see this after 21st Jan
[16:57] <infinity> cjwatson: I was going to wait until we finished maining it and getting something(s) to depend on it.
[16:57] <cjwatson> infinity: I'm not sure that's going to happen for .2.
[16:58] <infinity> cjwatson: Well, you need a new grub2-signed anyway, and I'm told that was one of the things they wanted to depend on it.
[16:58] <cjwatson> But it seems potentially useful for OEMs even without that.
[16:58] <infinity> Oh, crap.  Does grub2-signed land in d-i images?
[16:58] <cjwatson> I mean, it's currently empty anyway :-)
[16:58] <cjwatson> infinity: Yah
[16:58] <cjwatson> Don't they build from -proposed though?
[16:58] <infinity> Poo.  Then that last upload was a wash.
[16:59] <cjwatson> How come?  The grub2-signed in -proposed will be fine for .2, I expect ...
[16:59] <cjwatson> Just needs the server team to get round to verifying one last bug
[16:59] <cjwatson> Which should be an easy one
[16:59] <infinity> cjwatson: grub2-signed in proposed is out of sync with grub2 in proposed...
[16:59] <cjwatson> Oh, hmm
[16:59] <cjwatson> Yeah, this secureboot-db package in -proposed is trivial.  I'm going to copy it just to make reports shorter, even though it's currently pretty useless.
[17:00] <infinity> Alright, I can promote it later.
[17:01] <cjwatson> Yeah, we should update grub2-signed.  I'll do that now.
[17:01]  * jdstrand read the backscroll but seems there is nothing to do
[17:01] <infinity> cjwatson: So, if you're doing that, you could make it pull in secureboot-db too. :P
[17:01] <cjwatson> I guess.
[17:02] <cjwatson> jdstrand: ^- confirm that that's wanted?
[17:02] <jdstrand> we want shim-signed and grub2-signed to Recommends it
[17:02] <tjaalton> cjwatson: yeah, i could..
[17:02] <infinity> Or recommends, yes. Sorry.
[17:03] <cjwatson> jdstrand: Could I have a bug report for this, please?
[17:03] <cjwatson> If there isn't one already ...
[17:03] <infinity> I was going to add tasks to the MIR.
[17:03] <infinity> Once I'd done reviewing it.
[17:03] <infinity> cjwatson: How about we don't upload grub2-signed just yet, and I'll do the MIR review first. :P
[17:06] <mterry> jbicha, heyo.  Does the GNOME Remix want to keep patches that change "..." to the proper unicode char?  (I'm going through gnome-bluetooth's patches, now that Unity will use indicator-bluetooth
[17:18] <jbicha> mterry: which patch? we might not even be using that code so it may not be worth maintaining the patch in Ubuntu
[17:19] <jbicha> I'm pretty sure GNOME would take an ellipsis patch though for https://live.gnome.org/GnomeGoals/UnicodeUsage
[17:25] <cjwatson> infinity: Well, I have grub2-signed uploads ready to go whenever you say the word; the sooner the better
[17:27] <cjwatson> bdmurray: Will you be able to verify bug 984276?
[17:33] <cjwatson> Sweetshark: Do you know how far off we are with verification of bug 1037111 for precise?  Since it's a big download, it'd be nice to have it in 12.04.2.
[17:33] <infinity> cjwatson: The last comment seems to imply it's well on its way.
[17:33] <cjwatson> Indeed, but I want to make sure it finishes :-)
[17:34]  * infinity nods.
[17:34] <bdmurray> cjwatson: yes, I'll do that now
[17:35] <infinity> cjwatson: Let me go stab secure-whoever-whatsit for you for MIR goodness.
[17:35] <infinity> Maybe after I have a midnight snack.
[17:36] <zequence> infinity: Where is the code for the ISOs, exactly? (Ubuntu, and other flavors)
[17:36] <cjwatson> bdmurray: Thanks
[17:36] <cjwatson> tjaalton: Also, do you know what's happening about verification of bug 1064192?  I think we want all the driver packages in .2 ...
[17:37] <zequence> infinity: Never mind :)
[17:40] <tjaalton> cjwatson: hum, no.. tseliot ^
[17:50] <tseliot> cjwatson: unfortunately I don't own a graphics card to test that driver
[17:50] <tseliot> tjaalton: ^
[17:52] <infinity> jdstrand: So, I only have one concern with this secureboot-db thing.  Why does the postinst ignore errors from sbkeysync?
[17:53] <jdstrand> infinity: right, I did that on purpose. let me try to rethink why
[17:54] <smoser> psusi, ping.
[17:58] <jdstrand> infinity: I have in my notes is that sbkeysync doesn't actually exit with error under certain conditions. That coupled with the fact that I tend not to want to break upgrades, I opted for '|| true'. I also thought it conceivable that sbkeysync could have updated db/dbx but grub wasn't setup yet to use the knew kernel (resulting in an unbootable system)
[17:59] <tjaalton> tseliot: does it support gf8600gt?
[17:59] <jdstrand> (plus I didn't want different postinst behavior if sbkeysync changed its error handling)
[17:59] <infinity> jdstrand: Well, given that we're upstream for sbkeysync, I'd like to think that if it ever exits with an error that's because we think something bad has happened.
[18:00] <infinity> jdstrand: And if that's not true, perhaps we should fix it. :P
[18:01] <jdstrand> infinity: "I also thought it conceivable that sbkeysync could have updated db/dbx but gru wasn't setup yet to use the knew[sic] kernel" because we exited with error
[18:01] <tjaalton> tseliot: seems like it does, so i can verify it..
[18:01] <tjaalton> cjwatson: ^
[18:01] <jdstrand> infinity: I hear what your saying, but I felt that erring on the side of caution (ie, making sure the system is at least bootable) was paramount
[18:02] <infinity> jdstrand: Assuming that's what this does, sure.  I was envisoning the opposite, I suppose.  sbkeysync tells us something went horribly wrong, we ignore it, the user has no unfriendly "egads, stuff broke" error messages and reboots into a brick.
[18:04] <jdstrand> infinity: the only way that I can imagine that a system would become unbootable is if sbkeysync ran and updated db/dbx, but we didn't finishing setting up booting the non-blacklisted new grub/shim/kernel/...
[18:04] <jdstrand> the || true was an attempt to guard against that
[18:05] <infinity> jdstrand: Fair enough.
[18:05] <jdstrand> I suppose a firmware bug would be possible there, but... /me moves hands around
[18:06] <infinity> jdstrand: Thankfully, we've not seen any UEFI firmware bugs that brick systems.
[18:06] <jdstrand> most of those would likely cause an unbootable situation regardless
[18:06] <jdstrand> hehe
[18:06] <jdstrand> true
[18:07] <jtaylor> doko: can you please comment on bug 1112496
[18:07] <smoser> infinity, what is the lkelyhood of getting a newer util-linux?
[18:08] <doko> jtaylor, later, just back from travelling
[18:08] <cjwatson> mlankhorst: while I'm nagging people about X-related updates - any chance of verifying bug 1070481?
[18:08] <infinity> cjwatson: https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1087843 is a go.  I'll pre-promote now, feel free to upload grub2-signed with the recommends.
[18:08] <cjwatson> infinity: Right.  In progress.
[18:08] <smoser> ours is quite old. i'm specifically interested in gpt features and 'partx --update' (bug 1096999 and bug 1087526)
[18:08] <mlankhorst> cjwatson: oh go right ahead and close it, the patch has been tested so many times that as long as it's applied it works :P
[18:09] <infinity> smoser: I keep meaning to set up a proper shared repository so lamont and I can co-maintain it more sanely.
[18:09] <infinity> smoser: But I can certainly see about updating it in experimental/raring.  I assume you're not looking for SRU backports here, right?
[18:10] <lamont> infinity: I support this plan.
[18:10] <lamont> infinity: well, actually I support the plan where you actually create a shared repo, rather than the plan where you keep meaning to, but don't. :p
[18:10] <cjwatson> mlankhorst: tag it verification-done then :)
[18:10] <smoser> infinity, i'm not looking for SRU for those, no.
[18:11] <infinity> lamont: Heh.  Yeah, I'm terminally lazy when it comes to anything alioth-related.  I'll get to it.
[18:11] <smoser> but at the moment it looks to me that gpt support in trunk is much newer than any released.
[18:12] <infinity> smoser: Sure, I'm not averse to backporting select patches from trunk, but may as well make sure we're at a current release version first.
[18:12] <smoser> right.
[18:12] <mlankhorst> cjwatson: done
[18:12] <smoser> i was going to suggest that 2.22 would be a better starting point for cherry picking than where we are now
[18:12] <cjwatson> mlankhorst: ta
[18:12] <smoser> that said, psusi cherry picked the partx patches anad has a branch for that.
[18:13] <smoser> but i'd like the gpt support also.
[18:13] <infinity> smoser: Tell you what.  I'll get that done, if you find some free time to fix eglibc on Debian/kfreebsd.  Thanks in advance.
[18:13] <smoser> infinity, you're welcome
[18:14] <smoser> i hope i didn't sound ungrateful
[18:14] <infinity> smoser: :)
[18:15] <infinity> Ugh, 520 open util-linux bugs.  I sure do know how to pick the wrong packages to co-maintain.
[18:16] <infinity> smoser: I'll put the Debian update on my hobbyist TODO.  I'm sick of glibc this week anyway.
[18:20] <lamont> infinity: +500 - halp welcome
[18:20] <smoser> infinity, the good thing is that its such a fringe package, that an upgrade of a years worth of upstream development (2.20.1 -> 2.22.2) is not likely to cause any fallout.
[18:21] <jdstrand> infinity: thanks for the review :)
[18:21] <infinity> smoser: Yeah, no one really uses it anyway.
[18:21] <infinity> smoser: S'ok, I have a knack for adopting fringe cruft that no one uses.
[18:38] <ogra> ogra@nexus7:~$ ps ax|grep -c "udevd --daemon"
[18:38] <ogra> 17
[18:38] <ogra> hmm, that cant be right
[18:45] <mlankhorst> pgrep udevd ?
[18:46] <ogra> it had different PIDs, werent threads
[18:46] <Esokrates> hi, i have compiled both, compiz and unity. If i log in with lightdm i can only see the wallpaper, so i change to a virtual terminal and type:  env DISPLAY=:0  --replace composite opengl move resize decor compiztoolbox mousepoll wall expo animation switcher unityshell
[18:46] <Esokrates> but what i get is different from how things are configured in default ubuntu
[18:47] <Esokrates> (workspaces all in a row, minimize animation mac -like
[18:47] <Esokrates> cannot snap windows etc. ...
[18:47] <Esokrates> how to configure to get the ubuntu default experience?
[18:55] <ogra> cjwatson, 393MB for the idling desktop (after i restarted udev to get rid of the piling up daemons) with your libgtk-3.0  \o/
[18:57] <seb128> ogra, how much was it before the update?
[18:57] <ogra> cjwatson, that should be a good 30M
[18:57] <ogra> seb128, above 400 ... somewheer around 420
[18:57] <seb128> nice
[18:58] <ogra> hmm, i have a pulseaudio daemon go crazy here
[19:04] <cyphermox> stokachu: pong
[19:09] <ogra> oh, it even dropped to 375 now
[19:09] <ogra> ah, 17M swap :P
[19:10] <xxiao> saw a few old connections leaving cannonical for linaro
[19:26] <smoser> infinity, would you be opposed to me grabbing psusi's backport for util-linux ?
[19:26] <smoser> as it seems to "work for me"
[19:27] <infinity> smoser: That has pretty much zero context.
[19:27] <smoser> well, context was provided earlier , https://code.launchpad.net/~psusi/ubuntu/raring/util-linux/cherry-pick-resize
[19:29] <infinity> smoser: Yeah, if you need that right freakin' now, that seems like a reasonably self-contained backport.
[19:29] <smoser> infinity, well even if you pulled 2.22.2, it wouldn't have that
[19:29] <infinity> smoser: I'm certainly not going to get to a new upstream tonight or anything.
[19:30] <infinity> smoser: *nod*
[19:30] <smoser> i dont need it *right now*
[19:30] <smoser> but at som epoint i want it
[19:31] <smoser> so if you're not opposed to getting it before you were to do a potential update, then i might just do that.
[19:31] <infinity> Yeah, I have no objections to it.
[19:34] <cjwatson> ogra: rock
[19:34] <ogra> yeah
[19:35] <ogra> we'll end up on 256M if it moves on like that !
[19:35] <cjwatson> I wonder if we've hit the second memory target yet
[19:36] <ogra> not yet, there is still something weird going on right after boot
[19:37] <ogra> it peaks above 500M and then goes down to the state it keeps
[19:37] <ogra> once we have that we should be able to tick off 2 and 3
[19:38] <BenC> infinity: I have no problem with e500* being left off of desktop media
[19:38] <cjwatson> ogra: does bootchart reveal anything interesting?
[19:38] <ogra> cjwatson, to me it looks like 2 and 3 are actually flipped, shouldnt the standlone desktop be 2 and desktop +app be 3 ?
[19:38] <cjwatson> I didn't set the targets :-)
[19:39] <ogra> cjwatson, not checked yet, its on my plan for tomorrow ... together with finding out why i have 17 udevd's running
[19:39] <infinity> BenC: I know we had this conversation before, and I've entirely forgotten the technical reasons given, but is there zero chance that e500* (and e6500 or whatever the 64-bit one is) will ever be able to be built into generic ppc32/ppc64 zImages?
[19:39] <cjwatson> It depends whether browser+mail-client were >512MB at the time that list was compiled
[19:40] <cjwatson> Doesn't udev keep a worker pool or something?
[19:40] <ogra> they surely were >1G
[19:40] <BenC> infinity: at this point, that's a negative
[19:40] <BenC> ppc32 will never happen
[19:40] <ogra> cjwatson, with a daemon for each of them ?
[19:40] <cjwatson> ogra: I mean on their own, without the desktop
[19:40] <infinity> BenC: Yes, I know it's not likely "at this point", I meant "in the future".
[19:40] <BenC> ppc64 will take great effort, but I'm going to push Freescale as much as I can to do the mmio work
[19:40] <cjwatson> ogra: they'll be forks of the original
[19:40] <ogra> i literally had /sbin/udevd --daemon running 17 times here
[19:40] <ogra> each with its own PID
[19:40] <cjwatson> yes, it forks to run rules
[19:40] <ogra> oh, ok
[19:41] <infinity> BenC: Kay.  In theory, if the ppc64 single zImage could happen, wouldn't the same work apply to ppc32 with some judicious cargo-culting?
[19:41] <ogra> hmm
[19:41] <BenC> infinity: Not really...
[19:41] <BenC> There's a lot more than mmio work to be done there
[19:42] <cjwatson> hm, it doesn't look as though it's supposed to keep a pool around though
[19:42] <kentb> where can I get some help with getting some packages into quantal/precise-backports from raring?  I've got the bug requests filed and done the testing, etc.
[19:42] <infinity> BenC: Irksome.
[19:43] <cjwatson> but I can't easily look through any more than small amounts of the code from here
[19:43] <xxiao> what's the benefit to get freescale e5** to zImage?
[19:43] <infinity> kentb: Did you subscribe ~ubuntu-backporters to your bugs?
[19:44] <kentb> infinity, yes. several months ago
[19:44] <infinity> xxiao: Not building and shipping several redundant kernels?
[19:44] <BenC> It's not "zImage" it's getting them to be built in the same image
[19:45] <BenC> xxiao: I think the idea is more like being able to build IBM Power kernel and Freescale Power kernels together
[19:45] <infinity> xxiao: Oh, yes, when I say "single zImage", it's the "single" part that matters.  I wasn't actually referring to the binary format.
[19:45] <xxiao> not sure if each side will ever prioritize this effort
[19:46] <infinity> And, up until recently, PPC was kinda the poster child for disparate platform support in a single kernel.
[19:46] <infinity> It's a bit sad that's now becoming gratuitously untrue.
[19:47] <xxiao> not sure who is funding fedora's ppc64 release
[19:47] <BenC> infinity: to be fair, not many platforms have a bookS and bookE type of platform seperation
[19:48] <xxiao> i don't see the point for 64bit user space, will give fedora ppc64 rootfs a try sometime though
[19:49] <xxiao> BenC: there is at least one FPU instruction difference between ibm and fsl e5500/e6500, that only matters if hard-float is used correct?
[19:53] <infinity> jdstrand: Oh, bah.  Second problem qith secureboot-db.  It depends on sbsigntool, but is arch:all, so is "broken" on non-x86.
[19:53] <infinity> s/qith/with/
[19:55] <slangasek> infinity: why does that bother us?
[19:55] <infinity> jdstrand: You've taken away my precious beer on http://people.canonical.com/~ubuntu-archive/testing/raring_probs.html
[19:55] <slangasek> aren't there a number of such "broken" packages?
[19:55] <infinity> slangasek: Not in main, there aren't.
[19:56] <slangasek> hmm
[19:56] <jdstrand> huh
[19:56] <slangasek> I consider this an artificial requirement
[19:56] <jdstrand> I didn't realize sbsigntool was only i386 and amd64
[19:57] <slangasek> Debian has never held that rule
[19:57] <infinity> sbsigntool probably shouldn't be x86-only in the long term.  But it is for now.
[19:57]  * jdstrand wonders why, since arm is supposed to have secure boot
[19:57] <slangasek> jdstrand: IIRC it has to do with architecture dependence of the PE format we're signing
[19:57] <jdstrand> that makes sense
[19:57] <infinity> jdstrand: No ARM devices we care about (yet) have EFI or SB.
[19:57] <slangasek> bug #1020771
[19:58] <jdstrand> infinity: I can fix this in a bit, I'm training someone atm
[19:58] <infinity> jdstrand: Yeah, I'm in no rush.  Was just pointing it out.
[19:59] <xxiao> a newbie question, if soft-float and math-emulation are both turned on, which one will be used by default?
[19:59] <infinity> slangasek: And, you're right, Debian's never required that arch:all deps be satisfiable on all arches, though it is mildly irksome when they can't be.
[20:01] <infinity> slangasek: For something less strangely esoteric than secureboot-db, see usb-creator, which used to be arch:all, but it's actually really frustrating when some guide says "do this with usb-creator", and you try to install it and it's "broken" on your arch.  Better to just not have it available at all.
[20:01]  * slangasek nods
[20:24] <smoser> infinity, one other thing.. if you do ever update util-linux, change debian/source/format to something other than 1.0 please.
[20:24] <smoser> it just feels dirty to change code without quilt
[20:26] <infinity> smoser: lamont's been maintaining it in git, where 1.0 makes some sense.
[20:26] <smoser> yeah, ok. i haven't any experience with that.
[20:27] <infinity> (Basically, the same way we maintain the kernel packages in Ubuntu)
[20:27] <infinity> If your upstream is just another git remote, you can cherrypick patches to your heart's content, and have a sane history.
[20:28] <smoser> when you cherry-pick is there some git knowledge of the source ?
[20:28] <infinity> There doesn't need to be, since git hashes are unique unlike, say, bzr revisions.
[20:28] <smoser> well, bzr revisions are not, but the revision-id is in bzr
[20:29] <smoser> anyway.
[20:29] <smoser> i just uploaded psusi's branch.
[20:29] <smoser> sanity checked that it generally functioned for what i was wanting
[20:30] <smoser> (and it seems to work for gpt stuff, not sure really how)
[20:30] <lamont> smoser: do not make me get upset at you by suggesting that the VCS belongs in the source package.  source-format = 1.0 is the only sane state
[20:31] <smoser> i dont think its the *only* sane state.
[20:31] <lamont> smoser: there was a brief period where I went with 3.0 for either bind or postfix, and I've been sad about that ever since.  OTOH, hardy EOLs soon
[20:32] <lamont> smoser: for the same reason that I hate quilt and dpatch, I find absolutely no benefit to 3.0
[20:33] <lamont> of course, that's mostly because when I check out the tree, I want to actually have the patched tree, not a tree with lots of unapplied patches
[20:33] <lamont> if I were to majorly fork from upstream, that might make a differnce
[20:34] <infinity> Yeah.  I'm finding 3.0 makes some sense with glibc.
[20:34] <cjwatson> 3.0 can give you a patched tree, FIW
[20:34] <cjwatson> FWIW
[20:34] <infinity> Not that we're "majorly forked", but we carry a lot of patches.
[20:34] <smoser> right.
[20:34] <cjwatson> It always gives you a patched tree on dpkg-source -x
[20:34] <cjwatson> Whether it does on VCS checkout depends how you lay out your VCS
[20:34] <smoser> bzr with patches appplied seems to work reasonably well recently.
[20:34] <infinity> cjwatson: But that's not generally how one wants to check it into git.  Unless you really want all your patched files duplicated in .pc
[20:34] <smoser> and doesn't bother showing you the .pc/ changes.
[20:35] <smoser> its not perfect, but it is loads better than it was.
[20:35] <cjwatson> infinity: The way I run my 3.0 (quilt) trees in bzr (when not using UDD) is to commit debian/patches/ but not .pc/
[20:35] <cjwatson> Which is not without its problems but works reasonably OK
[20:35] <smoser> cjwatson, if you stop fighting UDD, its really not terrible any more :)
[20:36] <cjwatson> It does mean that to get quilt working to actually develop against the checkout you have to run a script to unapply/apply
[20:36] <smoser> i followed your lead and had the non-applied .pc
[20:36] <cjwatson> smoser: I use UDD too elsewhere so have plenty of opportunity to compare
[20:36] <smoser> now i just try to let it handle it.
[20:36] <cjwatson> I still prefer my approach :)
[20:36] <cjwatson> But it's true that you have to handhold sometimes - there's really no perfect approach without additional tooling
[20:37] <smoser> much of my battle wounds were from fighting the importer
[20:37] <smoser> as it gets all ticked off with your way
[20:37] <cjwatson> Yeah, I only do this on branches the importer doesn't touch
[20:37] <cjwatson> Fighting the importer is definitely a mug's game
[20:37] <smoser> yeah, i just wanted it to work in both ways, so people (other people) could "just upload"
[20:41] <cjwatson> My most complex package maintained this way is grub2; and my intended solution for that is to get it in sync with Debian so that I no longer have to care about the importer
[20:41] <cjwatson> (In fact I don't right now, I use a different branch, but)
[20:53] <cjwatson> pitti: TB meeting in <10/
[20:53] <cjwatson> ?
[20:54] <pitti> cjwatson: thanks for reminder, I'm back onlne
[20:54] <pitti> just with missing 'i's
[21:19] <jdstrand> infinity: ok, secureboot-db uploaded to raring-proposed. shall I also upload it to precise-proposed and quantal-proposed? (note, that -updates for precise and quantal has secureboot-db)
[21:28] <infinity> jdstrand: Yeah, please do.
[21:28] <jdstrand> cool
[21:36] <smoser> Daviey, to follow up, my initial thought on how to preseed cloud-init for nocloud wont work.
[21:36] <smoser> the way i was oding it for fast path installer also requires modification of the command line (kernel cmdline)
[21:36] <smoser> adding 'ds=nocloud'
[21:38] <smoser> hm... actually i dont know.
[21:43] <smoser> well... i suspect i can get it to work on quantal, but not on precise cloud-init.
[21:48] <tseliot> tjaalton: great, thanks!
[21:50] <jdstrand> infinity: uploaded. I'm stepping away for a couple/few hours but will be back later if you need anything else
[21:56] <xxiao> http://paste.ubuntu.com/1610479/
[21:56] <xxiao> mk-sbuild for ppc core-dump
[21:56] <xxiao> on precise
[21:57] <cjwatson> More precisely, qemu-ppc-static core dumps.
[21:57] <cjwatson> It'd be pretty surprising for mk-sbuild to core dump given that it's a shell script.
[21:57] <xxiao> u r right :)
[21:57] <cjwatson> qemu from raring might do better.
[21:58] <xxiao> a bit surprised on doing this basic thing on LTS though
[22:04] <infinity> xxiao: qemu-user-static is known-broken on a lot of architectures.
[22:05] <infinity> xxiao: As a general rule, you're better off building natively anyway, since PPC hardware is far faster than anything x86 could emulate.
[22:07] <xxiao> infinity: true, it's just my ppc boards(not Apple machines) are a little noise here :)
[22:07] <xxiao> noisy
[22:07] <xxiao> i'll live with that...
[22:07]  * xxiao puts on his Optime95
[23:54] <psusi> smoser, pong