[02:28] <Shinobi> perl module Curses::UI::Grid errors out. Could not load Curses::UI::0 from Curses/UI/0.pm   Any ideas?
[03:12] <lool> slangasek: Just saw your ping, I'm in HK for Connect and have a couple of days off after returning; I also miss a testcase for it because I found the bug by reading the code, I didn't really face any symptom; that said, I'll try testing this end of next week by running pieces of the new code manually
[03:35] <pitti> Good morning
[03:36] <pitti> bdmurray: ah thanks; NB that you committed this to the quantal branch :)
[03:36] <pitti> bdmurray: I'll reject and reupload
[03:38] <pitti> bdmurray: ok, reuploaded
[03:47] <pitti> cjohnston: hourly updates - niiice!
[03:48] <cjohnston> :-)
[03:54] <pitti> cjwatson: remove-package> \o/, thanks!
[03:54] <cjwatson> very slowly we approach sanity
[03:55] <StevenK> Oooh, where's that?
[03:55] <cjwatson> lp:ubuntu-archive-tools
[03:56] <pitti> StevenK: see the ubuntu-archive@ announcement
[03:56] <pitti> cjwatson: wow, I hadn't actually expected you to be awake at this hour..
[03:57] <cjwatson> I woke up at 1:30am and couldn't get back to sleep until I'd dealt with some of the stuff in my head.  I'm about to go back to bed
[03:58] <cjwatson> StevenK: I have an MP up with the obvious nuke-from-orbit, too :)
[03:59] <StevenK> cjwatson: Ah, I was wondering about that.
[03:59] <cjwatson> (hardly a rush, but why not)
[04:00] <StevenK> cjwatson: Approved.
[04:01] <StevenK> cjwatson: One thing to jot down somewhere is you can probably kill SoyuzScript at some point too.
[04:55] <pitti> cjwatson: reverted https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/queue-tables/+merge/108073 FYI (see my followup)
[04:55] <pitti> just in case you wonder where it was gone
[05:07] <toabctl> does anybody have an example how i can get the codename for a specific package with python-apt ? i had a look at http://apt.alioth.debian.org/python-apt-doc/ but found nothing.
[05:07] <pitti> toabctl: what is a "code name"?
[05:10] <toabctl> pitti, afaik "precise" is a codename. i use reprepro to setup some private repositories and try to get the codename of a package.
[05:10] <pitti> oh, the release name
[05:10] <pitti> toabctl: there really is no way to tell from a .deb
[05:11] <toabctl> pitti, eg here is the codename set: http://archive.ubuntu.com/ubuntu/dists/precise/Release
[05:11] <pitti> toabctl: right, usually you set up debmirror, reprepro and other mirroring by release, which will use the dists/.../Pacakges.gz indexes
[05:11] <toabctl> pitti, imho apt should know the codename.
[05:12] <pitti> toabctl: you can, by looking at the .origins property
[05:12] <pitti> e. g.
[05:12] <pitti> cache['coreutils'].candidate.origins
[05:12] <pitti> there can be multiple origins, potentially from multiple releases
[05:13] <pitti> but that really sounds backwards
[05:13] <toabctl> pitti, i did this but there is no codename
[05:13] <pitti> you want to ask your mirroring script "give me all precise packages"
[05:13] <pitti> not iterate over all pacakges and pick out the precise one
[05:13] <pitti> s
[05:13] <pitti> toabctl: sure there is
[05:13] <pitti> >>> c['coreutils'].candidate.origins[0]
[05:13] <pitti> <Origin component:'main' archive:'quantal' origin:'Ubuntu' label:'Ubuntu' site:'archive.ubuntu.com' isTrusted:True>
[05:14] <pitti> >>> c['coreutils'].candidate.origins[0].archive
[05:14] <pitti> 'quantal'
[05:14] <pitti> but really, this is not what you are looking for for mirroring..
[05:14] <toabctl> pitti, i don't want to mirror. i use this for private stuff
[05:15] <pitti> toabctl: ok; so the origins are the place to look for then
[05:15] <pitti> either the .candidate or .installed, depending on what you are looking for
[05:16] <toabctl> pitti, where is the codename in your example? there's an archive. is that the same?
[05:17] <pitti> yes
[05:17] <toabctl> hm. that's not set in my repository. maybe there's something wrong with reprepro then.
[05:17] <pitti> toabctl: it's taken from the "Suite:" field in e. g. http://archive.ubuntu.com/ubuntu/dists/precise/Release
[05:17] <pitti> toabctl: you need the Release file, perhaps you don't have this?
[05:18] <toabctl> pitti, i have one, but Suite is missing. there is only a "Codename" field.
[05:18] <slangasek> lool: ok; I'll ask for the package to be promoted in the meantime because the other bugs are high-impact, so maybe we'll drop the un-verified fix from the SRU
[05:20] <pitti> toabctl: just checked the source; it only looks at Suite:, not Codename:
[05:21] <toabctl> pitti, where's the upstream source? imho that should be fixed.
[05:22] <pitti> Vcs-Bzr: says http://anonscm.debian.org/bzr/apt/python-apt/debian-sid/
[05:25] <toabctl> pitti, i added the Suite-Field to the Release file and i the the archive now. thanks!
[05:25] <pitti> works now? yw
[07:02] <dholbach> good morning
[07:14] <infinity> doko: Stop doing toolchain uploads from conferences.
[07:14] <doko> ?
[07:15] <infinity> ;)
[07:15] <infinity> doko: I was just checking on the buildds after I uploaded eglibc to see that you'd done gcc-4.7 just before that.
[07:16] <infinity> If both break the world, can we blame the tropical heat?
[07:17] <micahg> infinity: will your eglibc upload fix all the broken armel bits? :)
[07:17] <infinity> micahg: Which bits are those?
[07:17] <infinity> micahg: It fixed the last broken bit on armel that I know of... If you know of more, speak up.
[07:19] <micahg> infinity: I'm not sure if it's stuff still trying to do armv7 stuff or something else (and the porter boxen for armel are currently unhappy, rt open)
[07:19] <infinity> micahg: Stuff doing stuff or other stuff isn't all that specific.  What issue were you seeing?
[07:20] <micahg> {standard input}:135: Error: selected processor does not support ARM mode `smulbb r9,r9,r3'
[07:20] <infinity> micahg: libc.so and ld.so on armel were both armv7 by accident (fixed now), but that's perhaps unrelated to your issue.
[07:20] <infinity> micahg: What build was that in?
[07:20] <micahg> that was firefox, ghc seems to have some similar does not support errors
[07:21] <infinity> Oh, right, GHC was pointed out to me earlier.  Probably won't be fixed by my upload, no.  I'll have to look at it later.
[07:21] <infinity> Unsure about firefox too, but when I find some round tuits, I can help investigate.
[07:21] <doko> firefox builds should be fixed with the recent upload
[07:21] <doko> chrisccoulson, ^^^
[07:21] <micahg> firefox can wait for later, ghc is more important as I'm not sure if we should start the rebuilds until it's built on all archs
[07:22] <micahg> doko: chrisccoulson will be relieved to play angry birds again
[07:22] <doko> I wouldn't like to play happy birds ...
[07:22] <infinity> micahg: I'll be looking at ghc shortly.
[07:22]  * infinity runs off now.
[07:23] <micahg> infinity: thanks, we'll rebuild firefox soon enough anyways and see if it cures itself
[07:25] <micahg> doko: sorry, I didn't get to chromium yesterday, hope to look at it today, are you blocked on anything?
[07:25] <doko> micahg, no
[08:29] <cjwatson> StevenK: Yeah, I grep for stuff in it every time I kill something.  Killing change-override.py will probably manage to drop a method or two from it.
[08:30] <cjwatson> pitti: Ah, hmm, I'll see if I can find a workaround
[08:30] <pitti> cjwatson: I already had a workaround for the non-working len()
[08:31] <pitti> cjwatson: but it still didn't work, all the queues reported 0, at least back in the days when I tried it
[08:31] <pitti> perhaps LP got fixed in the meantime to deal with lucid's lplib
[08:53] <pitti> ogra_: hey Oliver
[08:54] <pitti> ogra_: FYI, I gave you a WI on https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-third-party-driver-installation for pvr-omap4, mostly because you know best how to detect whether the driver is necessary, and you can check "modinfo omapdrm_pvr"
[08:55] <pitti> ogra_: if that doesn't have any modaliases, we can add a custom detection plugin, like we had in jockey; but if it can be detected with modaliases, that'd be a lot more flexible
[08:57] <pitti> ogra_: of course I can help you wit this, but I'll need the initial investigation
[09:09] <skunk> I want to start developing for ubuntu.. can someone walk me through it??
[09:10] <skunk> is anyone even here??
[09:11] <elky> skunk, sure. Most of them are probably asleep, at work, or doing other daily routine things. People tend to read scrollback though.
[09:14] <elky> skunk, I can't walk you through it, but perhaps pointing you to the http://wiki.ubuntu.com/UbuntuDevelopment link in the topic would be a good starting point?
[09:17] <dholbach> http://developer.ubuntu.com/packaging/html/ probably too :)
[09:18] <skunk> kk one more question
[09:19] <skunk> I have a java background.. should just touch up on it before learning Vala and C? i mean.. I do have to relearn how all these algorithms works eh??
[09:20] <dholbach> that entirely depends on what you want to do - there's java work to be done in Ubuntu as well :)
[09:21] <skunk> I want to be working with pixel perfect scrolling.. and improving that
[09:21] <skunk> as well as work to better develop multitouch
[09:21] <skunk> especially with synaptics touchpads
[09:25] <ogra_> pitti, i plan to do some work on the panda anyway today, will get you the bits, np
[09:25] <pitti> ogra_: danke
[09:29] <skunk> what can i do if i have a synaptics touchpad, but ubuntu doesn't recognize it as one
[09:42] <cjwatson> pitti: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/464 - you may vomit now
[09:42] <cjwatson> (note you still can't actually index the members of getPackageUploads() without authenticating)
[09:42] <pitti> haha
[09:43] <pitti> cjwatson: ah, that was it then -- this should work with login_anonymously(), and queue access doesn't work with that
[09:43] <cjwatson> No, that's incidental
[09:43] <pitti> cjwatson: thanks for fixing
[09:43] <cjwatson> This code doesn't attempt to index the members, just to get the length - I'm just noting that indexing the members still won't work
[09:44] <cjwatson> The wadllib monkey-patch is what fixes getting the length
[09:45] <cjwatson> Though that said one of my near-term work items involves creating a bot account on lillypilly, so all this can be authenticated; the LP team isn't actually desperately keen on anonymous access for various reasons, mostly monitoring/load-related
[09:45] <pitti> cjwatson: right, but my previous attempt on a workaround used len(list(getPackageUploads()), which requires accessing the members
[09:45] <cjwatson> Right
[09:45] <pitti> so that failed
[09:45] <cjwatson> This one's tested
[09:45] <pitti> screenscraping-b-gone
[09:45] <cjwatson> And deployed now
[09:46] <cjwatson> Maybe I should do that bot account now actually, after the next cup of coffee; we need that to move copy-report off cocoplum, and other suchlike things
[09:47] <cjwatson> I did check with the LP team about it; it's a bit alarming 'cos it's a privileged account, but it's essentially no worse than the alarming privilege of cocoplum
[09:47] <cjwatson> and at least oauth tokens are revocable
[09:47] <pitti> the old levels (such as "readonly") are gone now, right? (too bad, it was handy for things like that)
[09:48] <pitti> or do you want to automatically copy anyway?
[09:48] <cjwatson> copy-report doesn't want readonly
[09:48] <cjwatson> I want to preserve the automatic copy, it at least used to save Canonical roughly my salary per year in bandwidth :-P
[09:48] <pitti> *nod*
[09:49] <pitti> cjwatson: I still wonder whether it wouldn't be easier to just integrate this into whatever release script the security team uses (i. e. also copy to -updates, instead of mass-copying from cron)
[09:50] <micahg> pitti: you would need to give the security team access to -updates then ;)
[09:50] <cjwatson> We need the bot account for other reasons anyway
[09:50] <pitti> micahg: don't you?
[09:50] <micahg> nope, just -security AIUI
[09:50] <pitti> micahg: I wasn't aware that you need special upload privileges for -updates
[09:50] <cjwatson> The privilege around -security is specially hardcoded in LP
[09:51] <pitti> ah
[09:51] <cjwatson> Other reasons> for example it would allow auto-syncs to be actually automated
[09:51] <cjwatson> Rather than cron.cjwatson
[10:46] <xnox> Can I rely on update-manager / do-release-upgrade to remove `oldlibs`, i.e. dummy transitional packages? Or shall I write a hook for update-manager because I am reverting the transitional package rename which was done in Lucid.
[10:51] <skunk> cjwatson, are you still here?\
[10:54] <skunk> well, cjwatson. I don't know if you're gonna see this message. But out of the six years i've used ubuntu the work you've done with the installer is incridble
[10:54] <cjwatson> skunk: thanks, and you're welcome
[10:55] <seb128> xnox, check with mvo but I don't think it does magically clean old stuff
[10:55] <skunk> 15 minute install, then im surfing the web, writing documents.. this kinda sound like Mac territory
[10:56] <skunk> cjwatson, who do I contact for uTouch issues??
[10:56] <cjwatson> skunk: I'd start with cnd
[10:56] <xnox> seb128: i distincly remember the 'Remove old unneeded packages: Y/n' question from do-release-upgrade, But I usually dist-upgrade to +1 release, and end up not using the upgrade-manager.
[10:56] <cjwatson> (though it's not a field I know much about)
[10:57] <seb128> xnox, right, I just don't know if that list is computed in a smart way or if you need to teach update-manager about it
[10:57] <xnox> mvo: ^^^ can you check my message at :46 above.
[10:57] <skunk> cjwatson: honestly I want my synaptics touchpad to work like one.. instead of a standard touchpad
[10:57] <xnox> seb128: ok. I will test the upgrade in chroot =)
[11:04] <mvo> xnox: its not looking at transitional packages specifically, it does look at unused dependencies though, that might (or might not) help you
[11:06] <ev> pitti: am I reading this correctly that we do not have the ability to retrace VmCore files yet?
[11:06] <ev> in apport-retrace, that is
[11:07] <mvo> xnox: it could do heurisitc like looking at "transitional" or "dummy"in the description summary, but that is not deal, ideally there would be something formal identifying the transitional pkg
[11:08] <xnox> mvo: 'Section: oldlibs' is standard way to identify transitional packages, unless i am wrong. let me check the policy.
[11:08] <xnox> mvo: and they should be cruft to be removed.
[11:08] <cjwatson> Yeah, though we could do better about actually moving transitional packages there in Ubuntu in practice.  But that's eminently fixable.
[11:09] <xnox> hmm policy says 'kept for legacy'
[11:09] <xnox> and some are not actually transitional nor dummy
[11:09] <mvo> xnox: right, iirc oldlibs was overloaded with multiple meanings
[11:10] <xnox> yeap
[11:10] <xnox> looks like so
[11:10] <mvo> I whish there was "section: transitional" or something similar or a debtag
[11:10] <xnox> I will do a test and hopefully I will be ok with depends/replaces/conflicts etc.
[11:10] <mvo> thanks
[11:13] <ev> pitti, apw: also, we don't seem to have a close to unique identifier for KernelOops failures. Any objection to parsing the call trace out of OopsText (https://launchpadlibrarian.net/79771442/OopsText.txt) and generating a signature in the same manner as crash_signature (so concatenate the first few)?
[11:13]  * ev lunches
[11:14]  * xnox read * ev launches
[11:15] <ogra_> but where to ?
[11:15]  * xnox To the cloud! And beyond!
[11:15] <ogra_> :)
[11:15] <ogra_> charming :)
[11:15]  * xnox loves ToyStory
[11:16] <apw> ev, that doesn't sound like a bad plan, though in theory ignore the ? entries in the list ... also include the type of OOPS, the top line hints at th type, and the IP: as part of it
[11:16] <ogra_> isnt that a requirement to become a DD ? :
[11:16] <Daviey> xnox: launching stuff at poor infinity.. that is just mean.
[11:16] <apw> Daviey, worse leaving him behind ... "and beyond"
[11:17] <ogra_> nah, that just means infinity+1 :)
[11:17] <xnox> Daviey: I was certian that infinity is deployed with juju these days
[11:56] <doko> chrisccoulson, bug #1003733 is fixed, you can't verify when building with 4.6 :-/
[11:58] <xnox> oh my angry birds =)
[11:58] <xnox> that must be critical priority =)
[12:06] <pitti> ev: that's right
[12:07] <pitti> ev: sure, if the succession of addresses in OopsText is reasonably reliable
[12:22] <astraljava> xnox: Our offices are within 300 feet to their HQ, should I pay them a visit? :D
[12:23] <ogra_> how would you pay this ... in icecream ?
[12:24] <astraljava> I dunno, but I could sell them an ERP at the same time. :D
[12:24] <xnox> astraljava: yes, plese. show up and say that `doko is not happy and wants an angry bird stuffed animal shipped to germany`
[12:24] <ev> xnox: lol
[12:24] <astraljava> xnox: some of their employees walk around in pig caps, would that do?
[12:25] <ev> pitti: awesome
[12:26] <ev> apw: cheers for that - once I have an algorithm I'll run it by you
[12:26] <xnox> astraljava: yeap, don't forget another one to be shipped for me to uk offices =)
[12:28] <astraljava> :)
[12:33] <apw> ev, excellent thanks
[12:34] <doko> micahg, ping
[12:46] <chrisccoulson> doko, the new gcc appears to fix the issues btw (just did a test build here)
[12:47] <doko> \o/
[12:48] <chrisccoulson> thanks! :)
[13:12] <jamespage> doko, any chance you could take a look at https://bugs.launchpad.net/ubuntu/+source/xmlgraphics-commons/+bug/888129/+attachment/3169273/+files/fix_icc_handling.debdiff before I upload?
[13:14] <doko> jamespage, looks fine. sorry for the delay
[13:15] <jamespage> doko, ack - thanks
[13:20] <mpt> mterry, I have no strong opinion either way. But if the badge is kept, maybe it should count the top-level groups of updates, not the individual packages.
[13:20] <mterry> mpt, hmm, k
[13:21] <mpt> mterry, but on the other hand, that seems a bit weird
[13:38] <mterry> mvo, let me ask you the other question from last night in this quieter channel
[13:39] <mterry> mvo, so update-manager --no-update.  What is it supposed to do?  I see the code it affects, but still not sure what exactly it means
[13:44] <mvo> mterry: my memory is not the best, but I think this got added for automatic testing via mago
[13:45] <mvo> mterry: I think its ok to kill it off
[13:46] <mterry> mvo, I want to recycle it.  The new spec requires doing an apt-get update when a user opens update-manager, but we need a way to turn that off, for testing and for when we pop up automatic updates.  --no-update seemed logical
[13:48] <mvo> mterry: yeah, that sounds reasonable
[13:48] <mterry> mvo, also, what's the story with the DBus API that update-manager exposes?  Who consumes that?
[13:50] <mvo> mterry: update-manager itself to implement a poor mans singleton window
[13:51] <mvo> mterry: see setupDbus() but meh, its pretty rusty, need proper dbus names for example
[13:52] <mterry> mvo, OK, so it uses whether the name is claimed or not, much like modern GtkApplication.  But does anyone consume the actual calls like "update()" or "upgrade()" that you know of?
[13:53] <mvo> mterry: those were added for mago as well
[13:53] <mterry> mvo, ah OK
[13:54] <mterry> mvo, (in the branch where I'm doing the update-on-start, I'm removing the ability to initiate updates elsewhere in the UI and was wondering about the dbus method to do so.  Sounds like I should drop it too)
[13:54] <mvo> brendand: hi, iirc you added the update dbus stuff, is that actually being used these days in the test environment?
[13:55] <brendand> mvo - i'd have to check
[13:55] <brendand> mvo - i do know we have an apt-get-update test in our SRU suitew
[13:56] <brendand> mvo - whether it actually uses that functionality i can't recall
[13:56] <brendand> mvo, probably not
[13:56] <mterry> mvo, brendand: well regardless, if the purpose of the tests is to mimic the UI, if the UI is dropping the ability to kick of an update willy-nilly, the dbus API should to I suppose
[13:57] <brendand> mvo - what's the ui doing?
[13:57] <mterry> brendand, how do you mean that?  The UI is moving to a "do an apt-get update on startup" and dropping the buttons to initiate one manually
[13:58] <brendand> mterry, oh right, i see
[13:59] <brendand> mvo, mterry - so i can say that *i* won't complain if it's removed. i can't promise no-one else will. i seem to recall that stuff was put in at the request of the QA team as well
[14:03] <stgraber> NCommander: 12.04.1 meeting in #ubuntu-meeting
[15:06]  * ogra_ sighs about linux-base
[15:06] <ogra_> that postinst is a pain
[15:11] <ogra_> slangasek, FYI support for the arm server arches is in flash-kernel now, the only thing i'm struggling with is linux-base atm which needs to be MIRed (its postinst tries to rewrite all config files that could use UUIDs though, and there is no debconf option to switch that off)
[15:13] <slangasek> ogra_: hmm, if we don't need/want that rewriting (which should be obsolete for years now), why not drop the dep?
[15:13] <slangasek> is linux-base needed for something else?
[15:14] <ogra_> slangasek, it ships linux-version (which is actually the only binary in there after tgardner dropped perf from it), which flash-kernel uses to determine the laters kernel version
[15:15] <ogra_> *latest
[15:17] <ogra_> i'm incliend to just put an exit 0 at the top of the postinst
[15:18] <pitti> ogra_, slangasek: I filed a MIR for linux-base this morning, FYI
[15:18]  * ogra_ hugs pitti 
[15:18] <pitti> it seems fairly harmless
[15:18] <ogra_> pitti, what else does use it ?
[15:18] <pitti> but I subscribed you and infinity to the bug for further comments
[15:18] <pitti> ogra_: just flash-kernel
[15:18] <pitti> bug 1006717
[15:19] <ogra_> it would be if the postinst wouldnt fiddle with hdparm.conf or udev rule rewriting
[15:19] <ogra_> or bootloader configs
[15:20] <slangasek> ogra_: so anything that would still be using /dev/[hs]d[a-z]* style names in any of these config files is already buggy, and *should* have been rewritten long ago (like, before we started having an armel port)... so I wouldn't worry about disabling it
[15:20] <pitti> erk, yes
[15:22] <ogra_> slangasek, well, the prob is that the script doesnt take any arm bootloaders into account, so it will always show a debconf error that you have to rewrite your configs by hand
[15:22] <ogra_> we need to get at least this bit quiet
[15:23] <ogra_> (and i really dont like the idea that it touches your grub config if you manually forced it to i.e. /dev/sdx1)
[15:23] <cjwatson> it was sane for transitional purposes, but as slangasek says it sounds obsolete now
[15:24] <slangasek> ogra_: really?  The code looks like it's not supposed to trigger on first install
[15:24] <slangasek> is_fresh_installation()
[15:25] <ogra_> well, i just had that message on both, precise (using --force-overwrite to overcome the perf conflict)  as well as on quantal
[15:27] <slangasek> oh, sorry, the definition of is_fresh_installation() keys on whether there are linux-image-* packages installed
[15:28] <slangasek> rather than on whether this is the first installation of linux-base
[15:28] <slangasek> phooey
[15:28] <ogra_> and if fstab exists :)
[15:29] <ogra_> sigh, my perl is so rusty ... thats what years of ubuntu work do to you
[15:30] <ogra_> funnily i indeed have an fstab file as well as a linux-image-* package installed on both test systems i tested on
[15:30] <ogra_> which somewhat indicates it doesnt even work
[15:31] <slangasek> well, no, the check is to not migrate if you *don't* have an fstab (or don't have linux-image-* packages)
[15:31] <slangasek> so that makes sense.. I just made a bad assumption based on the function name :)
[15:32] <ogra_> oh
[15:32] <ogra_> yeah, and i read it vbackwards :)
[15:33] <slangasek> ogra_: yeah, I would just disable this then
[15:33] <ogra_> you mean the whole postinst ?
[15:33] <slangasek> yeah
[15:33] <slangasek> it's definitely not worth porting it to other bootloaders
[15:34] <ogra_> right, i'll just remove it from the package completely then
[16:13] <stgraber> stokachu: hi. I'm currently looking at your isc-dhcp SRU. I merged the pid bug with the one I used for the other SRUs (bug 985417) and am now looking at bug 588635
[16:14] <stgraber> stokachu: for that second bug, can you update the bug report with the required SRU tags? (rational, test case, regression potential)?
[16:14] <stgraber> stokachu: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[16:16] <stgraber> stokachu: I have the SRU ready for upload here, so as soon as the bug is updated I'll upload it
[16:43] <ari-tczew> one question: does quantal have the same toolchain like unstable right now? e.g. does it have gcc 4.7 default?
[16:46] <stokachu> stgraber: yea ill get that updated shortly for you
[16:49] <ikonia> ari-tczew: could you please check your pm when you get a moment
[16:51] <bregma> I need to upload an SRU change for 12.04 that has the same package version as the latest package in quantal -- should I add ~precise to the SRU package version, er sumpin'?
[16:53] <cjwatson> bregma: I would probably recommend appending ~ubuntu12.04.1
[16:53] <cjwatson> or something like that
[16:54] <cjwatson> (assuming that the delta from current precise to this meets the SRU guidelines)
[17:36] <Laney> jcastro: yo, I don't see a tenant or account ID on the page you linked from HPCloud. Just "Access Key ID"
[17:36] <Laney> do I need to do anything else?
[17:37] <jcastro> refresh the wiki page
[17:37] <jcastro> I just added it
[17:37] <jcastro> "Note that the Tenet ID doesn't show up on that page until you've clicked on "Activate Now: for one of the availability zones in the Dashboard."
[17:37] <Laney> hah, you did /just/ add it indeed.
[17:37] <Laney> thanks.
[17:39]  * Laney wonders how to make that choice
[17:41] <jcastro> Laney: anything you can add from the "I started with nothing on hp cloud" to the instructions would be appreciated
[17:41] <jcastro> a bunch of us were already on it so it's difficult to figure out what starting from zero is like
[17:42] <Laney> sure
[17:42] <Laney> the account ID is on a different page, so I'll add a link to that
[17:42] <jcastro> <3
[17:43] <stokachu> stgraber: re: SRU 588635 is done
[17:43]  * xnox can't find my USD credit card
[17:43] <xnox> for hp cloud thing =)
[17:45] <Laney> I just used my UK one
[17:46] <stgraber> stokachu: thanks
[17:46] <stokachu> stgraber: anytime
[17:46] <stokachu> stgraber: now im off to wrestle autofs :D
[17:46] <stgraber> have fun ;)
[17:51] <xnox> stokachu: i have been merging autofs today, what's up?
[17:51] <xnox> or is it for stable release? =)
[17:51] <stokachu> xnox: hey, im working an issue where automount is hanging on reloading 11k mounts
[17:51] <stokachu> :X
[17:52] <stokachu> yea its for lucid atm
[17:52] <xnox> ... enjoy =)
[17:52] <stokachu> haha taking the hands off approach wish i was you :D
[17:56] <penguin42> 11k mounts?!
[18:01] <stokachu> penguin42: thats just a rough estimate i haven't actually looked at the mount table yet
[18:03]  * penguin42 has plenty of sympathy for the automounter in that case
[18:04]  * stokachu agrees
[18:54] <micahg> doko: pong
[19:01]  * xnox Ladies and Gentlemen, Minions and Overlords 2 hours left until FeatureDefinitionFreeze
[19:11] <ScottK> StevenK: I just did my first package removal.  Feels good.
[19:11] <highvoltage> nice
[19:15] <xnox> ScottK: I got a feeling =) that tonight gonna be a real good night =)
[19:15] <ScottK> ;-)
[19:16] <xnox> ScottK: can you remove stale binaries of bitcoin on powerpcc only?
[19:17] <dobey> bdmurray: hey, can you remove one of the requested reviews on https://code.launchpad.net/~brian-murray/lptools/grab-descriptions/+merge/106469 ? then i can review it and get it landed (i added lptools to a tarmac instance to land the branches)
[19:17] <xnox> although it will be dealt as part of powerpc port cruft
[19:20] <bdmurray> dobey: either one of them?
[19:21] <dobey> bdmurray: yeah
[19:23] <bdmurray> dobey: there is only a possibility to reassign not remove.  should I resubmit then?
[19:23] <dobey> hmm, weird. nah
[19:38] <ScottK> xnox: I can.  Please file a bug explaining what you want removed and why and subscribe (not assign) ubuntu-archive.
[20:08] <xnox> Ok.
[20:08] <xnox> ScottK: ok, thanks.
[20:35] <tjaalton> why does sbuild fail with "E: Can't determine architecture of chroot:" these days, on precise?
[20:35] <tjaalton> only thing i've chagned is the kernel (3.4 from quantal)
[20:37] <xnox> pae kernel?
[20:37] <tjaalton> amd64
[20:37] <xnox> hmm. no clue. pass.
[20:38] <geser> and when you boot the old kernel it works again?
[20:39] <tjaalton> i'll try, but it's too unstable to use
[20:41] <tjaalton> geser: exactly
[20:43] <geser> if my perl foo is good enough this error happens if "dpkg --print-architecture" fails
[20:43] <tjaalton> I'll try with a backport kernel, this one was built on quantal
[20:44] <tjaalton> dpkg --print-architecture worked fine though
[20:49] <barry> stgraber: could i ask a favor of you to bump this build: https://launchpad.net/~barry/+archive/python/+build/3539392
[20:49] <stgraber> barry: done
[20:50] <barry> stgraber: thanks!
[21:22] <hallyn> all right.  my struct has (more than) two fields, 'char *name' and 'char *error_string'.  when i set 'c->error_string = NULL;', the previously correctly set c->name becomes "".  Does this ring any bells with anyone?
[21:22] <hallyn> I can't reproduce it with a minimal testcases
[21:25] <geser> you sure that setting error_string destroys your name?
[21:25] <hallyn> i print it out right before, and right after
[21:26] <hallyn> well, clearly i'm corrupting my stack somewhere
[21:26] <hallyn> i'll look tomorrow, need to clear my head.  thanks
[21:40] <YokoZar> Is there a set group of Ubuntu Ruby folks like there is for Python or do we just inherit from Debian?
[21:42] <slangasek> what do you mean by "set group"?  I'm not aware there's a set group of Ubuntu Python folks either
[21:43] <YokoZar> slangasek: What I mean is when I think of python packages I tend to think of folks like scottk and doko
[21:43] <YokoZar> even though it's informal
[21:45] <slangasek> ah, well, the ruby packages seem to be in sync with Debian at the moment, so I don't know
[21:49] <ScottK> No.  There isn't.
[22:02] <barry> stgraber: one more favor ;)   https://launchpad.net/~barry/+archive/python/+build/3539477
[22:03] <stgraber> barry: done
[22:03] <barry> stgraber: thx!
[23:42] <psusi> cjwatson, how does d-i locate the installation cdrom?  in particular when it's actually a usb flash drive?  it works fine for me on real hardware, but when I boot a qemu vm from my flash stick, d-i says it can't find the cdrom... the desktop image works fine though, it's just a problem with d-i
[23:56] <micahg> roaksoax: you seem to be forgetting to pass -v when creating the .changes files