[00:13] <slangasek> smoser: to be clear, I'm stalled on this udev console bug until I get some more data from a system that reproduces it
[00:30] <TheMuso> Does anybody else think this update is more than just bug fixes? https://code.launchpad.net/~cairo-dock-team/ubuntu/oneiric/cairo-dock/2.4.0-1/+merge/77045
[00:31] <TheMuso> Code has been re-organised/erwritten according to that changelog, and this late in the cycle, that doesn't sit well with me...
[00:33] <slangasek> TheMuso: I wouldn't merge it.  Object lesson in feature freeze?
[00:34] <TheMuso> Thats what I'm thinking.
[00:34] <TheMuso> I'd already started writing a feature freeze response, but thought a second opinion would be useful. Thanks.
[00:54] <smoser> slangasek, yeah. i'll get you some more debug output tomorrow.
[00:54] <slangasek> smoser: ok, cheers :)
[00:55] <smoser> slangasek, one thing i fear is that the recent upgrade in canonistack improves performance of guests, and that i'm not going to see the issue any more.
[00:55] <slangasek> heh
[01:46] <happyaron> ev: would you sync translations of the slideshow from Launchpad again before final release?
[01:48] <happyaron> ev: it would be great if you can sync it again, I found some last minute changes from translators wasn't included into version 48. thank you.
[02:21] <TheMuso> `/c
[02:40] <Bijanbina> Hi does any body know how can i add a package to official ubuntu packages i mean for install a software not need to add repository
[03:01] <TheMuso> @pilot out
[03:44] <pitti> Good morning
[03:45] <TheMuso> Morning pitti.
[04:19] <YokoZar> slangasek: infinity: Not sure what to do about https://bugs.launchpad.net/ubuntu/+source/wine1.3/+bug/862925  since I had the symlinks removed.  I do think it appropriate to add libllvm2.9:i386 to ia32-libs-multiarch however.
[04:32] <Sarvatt> Yokozar: personally I think it's crazy to not sync multiarch libpciaccess from debian unstable so libgl1-mesa-dri:i386 is installable and then add that to ia32-libs-multiarch, as it is now we have no accelerated 32 bit GL on amd64
[04:32] <Sarvatt> unless you use proprietary drivers
[04:42] <pitti> cnd: still online by any chance?
[04:59] <pitti> cnd: ah, was going to ask about bug 744911 and the diverged bzr branch, followed up in the bug now
[05:00] <cnd> pitti, I'll take a look in a minute
[05:00] <cnd> while I know you're up :), I wanted to ask about ppas and dbgsym packages
[05:01] <cnd> someone said earlier this week that there's no where to publish them too
[05:01] <cnd> is that in the works?
[05:01] <pitti> cnd: dpm requested this for developer.u.c.; I can ignore the inconsistent bzr and just upload this if you say the word; otherwise I'll let you bring real world and bzr into agreement again and apply the doc patch
[05:01] <pitti> cnd: I don't think there's any actual work on this happening right now
[05:01] <cnd> hmmm… that's a shame
[05:01] <cnd> ok
[05:01] <pitti> cnd: from what wgrant told me last time, the soyuz side is pretty much ready, but there are no archives to publish them to
[05:02] <cnd> that doesn't seem like an overly complex task to me :)
[05:02] <pitti> and that's again blocked by not being able to clean up old ddebs, IIRC
[05:02] <cnd> but I don't really know
[05:02] <cnd> ahh
[05:03] <wgrant> PPA changelogs in update-manager are blocked by issues cleaning them up. ddebs are blocked by there being far too many edge cases to track down and fix.
[05:04] <wgrant> However, the bug has been escalated. So a maintenance squad may pick it up eventually.
[05:04] <wgrant> But it's unlikely to happen until I'm back on maintenance, which will probably be March-May next year.
[05:15] <cnd> wgrant: ok
[05:15] <cnd> wgrant: is there a way I can help make add my vote for the feature?
[05:15] <cnd> like a bug I can click the me too button on?
[05:18] <cnd> pitti: lp:libgrip/ubuntu is ahead of the archive
[05:18] <cnd> when you said it's out of date, did you mean that it's just different?
[05:18] <pitti> cnd: no, not ahead
[05:18] <slangasek> YokoZar: 862925 is a duplicate of bug #821100, this is the expected result
[05:18] <pitti> cnd: "besides"
[05:18] <pitti> cnd: https://launchpad.net/ubuntu/+source/libgrip/0.3.2-0ubuntu2
[05:19] <pitti> cnd: that upload isn't in bzr+ssh://bazaar.launchpad.net/%2Bbranch/libgrip/ubuntu/
[05:19] <slangasek> YokoZar: trying to fix it "better" for this cycle will just make it worse
[05:19] <wgrant> cnd: Bug #747558
[05:19] <cnd> pitti: oh, I see
[05:19] <pitti> cnd: that bzr has an unreleased 0.3.2-0ubuntu2 with a different change
[05:19] <cnd> pitti: we branched it at 0.3.2-0ubuntu1
[05:19] <cnd> so your patch is against lp:libgrip/oneiric
[05:19] <pitti> cnd: ah, should I use that?
[05:19] <cnd> but should also go into lp:libgrip/ubuntu
[05:20] <cnd> yeah
[05:20] <pitti> cnd: btw, Vcs-Bzr: is invalid
[05:20] <pitti> debcheckout -a libgrip
[05:20] <pitti> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/libgrip/ubuntu/".
[05:20] <cnd> hrmmm… ok, I'll look into it
[05:20] <pitti> cnd: want me to fix up Vcs-Bzr and apply the doc patch to ubuntu and oneiric and upload, or do you want to?
[05:20] <cnd> pitti: you can do it
[05:20] <cnd> I'm going to go to bed :)
[05:20] <pitti> cnd: ack
[05:20] <cnd> if you're not overworked that is
[05:21] <cnd> I can get to it tomorrow if you have better things to do
[05:22] <cnd> hmm… I wonder what the libgrip documention looks like...
[05:22] <cnd> gah, why does oneiric keep suspending my laptop...
[05:22] <pitti> cnd: after 30 minutes of being idle?
[05:22] <cnd> yeah
[05:22] <pitti> that's a known bug, being worked on
[05:23] <cnd> ok
[05:23] <pitti> (and yeah, it's really annoying)
[05:23] <cnd> I just upgraded my netbook today
[05:23] <cnd> it *always* decides to do stupid things when I upgrade it
[05:23] <cnd> I don't think I've ever gotten through an entire upgrade on it
[05:23] <cnd> and it was installed with lucid IIRC
[05:24] <pitti> cnd: ok, trunk branch updated, now doing /oneiric
[05:24] <cnd> this time, intel graphics decided to "lose" the framebuffer
[05:24] <cnd> awesome
[05:28] <cnd> pitti: ahh, the link I had in Vcs-Bzr works in a browser
[05:28] <cnd> so I assumed it would work for bzr
[05:28] <pitti> cnd: right, but it's not pointing to a branch
[05:29] <pitti> it's more like a project page
[05:29] <cnd> pitti: so to get around the missing dbgsyms in our daily ppas, I committed revision 34 in the ubuntu branch
[05:29] <cnd> does that seem reasonable to you?
[05:29] <pitti> cnd: sure
[05:29] <cnd> ok
[05:29] <pitti> cnd: that, or just build a -dbg package
[05:29] <pitti> but unstripped in PPA sounds fine
[05:30] <cnd> pitti: is it possible to conditionally build a package?
[05:30] <cnd> I don't want to pollute the ubuntu archive with unnecessary -dbg packages
[05:30] <pitti> cnd: yes, it is
[05:30] <cnd> but if I can conditionally build a -dbg package when it's a native daily build, then that would work
[05:30] <infinity> grep /CurrentlyBuilding for "Purpose: PPA"
[05:30] <pitti> cnd: you can do something like dh_builddeb -Nlibgrip-dbg
[05:31] <pitti> (if you are doing a PPA build)
[05:31] <pitti> (untested)
[05:31] <wgrant> infinity: EVIL
[05:31] <infinity> wgrant: Yup.
[05:31] <infinity> wgrant: The kernel packages have been doing it for years. :P
[05:31] <wgrant> Yeah :(
[05:32] <pitti> infinity: cnd has an "autogen.sh exists" test, which is good enough for daily build recipes
[05:32] <infinity> pitti: Sure. ;)
[05:32] <infinity> Version checks can work too, if you're sane about how you version.
[05:33] <infinity> Also, I seem to have just killed an external hard drive.
[05:33] <infinity> Bother.
[05:33] <pitti> eek
[05:33] <StevenK> That's what you get for propagating evil.
[05:33] <pitti> infinity: all your pr0n^Wclassic music collection gone?
[05:34] <StevenK> Haha
[05:34] <infinity> pitti: A bunch of media and full Debian and Ubuntu mirrors.
[05:34] <infinity> It's not a small hard drive.
[05:35] <cnd> pitti: I was worried the documentation would be invalid, but it seems to be reasonable
[05:35] <cnd> thanks for the patch!
[05:35] <maum> infinity: are you the one who developed wxpython toolkit?
[05:35] <pitti> cnd: looks fine in devhelp to me
[05:36] <infinity> maum: Nope.  Should I be?
[05:37] <maum> infinity: no, I just ask you because your nick is same
[05:38] <diwic> anyone in the mood for sponsoring bug 862553?
[05:38] <infinity> maum: I've been this same infinity for a couple of decades, but I assure you I had nothing to do with wxpython.
[05:39] <maum> infinity: ok nervermind, I am just curious about it.
[05:39] <didrocks> good morning
[05:39] <maum> morning didrocks
[05:39] <didrocks> hey maum
[05:40] <maum> hello
[05:41] <infinity> Friggin' hardware.
[05:42] <infinity> "Flip the power switch a few hundred times, and it'll spin up".  That needs to be in the owner's manual.
[05:42] <StevenK> Hit it with a hammer. That will help.
[05:42] <StevenK> ... your blood pressure.
[05:42] <pitti> diwic: much appreciated, will do
[05:43] <diwic> pitti, thanks
[06:04] <dholbach> good morning
[06:17] <ubuntu-baltix> hello all
[06:18] <ubuntu-baltix> Maybe someone can update http://people.ubuntu.com/~dylanmccall/ubiquity-slideshow-ubuntu/preview/ ?
[06:19] <ubuntu-baltix> Yesterday evening I've finished translations of ubiquity-slideshow-ubuntu and wanna see slides with new translation ;)
[06:22] <ubuntu-baltix> pitti: Maybe you know someone, who can update http://people.ubuntu.com/~dylanmccall/ubiquity-slideshow-ubuntu/preview/ ? ;)
[06:23] <pitti> dylanmccall presumably :)
[06:24] <ubuntu-baltix> pitti: Yea, I was afraid of this answer...
[06:47] <infinity> Dearest udev, no it's not cool to spin my CPU to 100%.  No love, Adam.
[06:48] <RAOF> Lies.
[06:49] <RAOF> It's always cool to spin!
[06:49] <infinity> Oh, look at that, restarting it made its 17 children go away.
[06:49] <infinity> Imagine that.
[06:55] <infinity> wgrant: Does the response to #276629 mean "... and we'll be fixing cruft in a better way RSN", or is it just "Ha ha ha, we removed the tool, so no more bugs"?
[06:56] <infinity> wgrant: Actually, I guess ubuntu-archive already has better NBS tools anyway. :P
[07:04] <wgrant> infinity: It's cjwatson's problem now. He deleted it from LP yesterday :)
[07:04] <wgrant> I believe it's now maintained exterally.
[07:05] <infinity> wgrant: Yeah.  Makes sense for us to claim ownership of all those tools as they become decoupled from the source itself.
[07:17] <diwic> mvo, I can take care of upstreaming bug 862553 and keep you in cc, if you like?
[07:22] <mvo> diwic: that would be nice
[07:22] <diwic> mvo, ok will do!
[07:23] <mvo> diwic: well, the fix is pretty simple, gdk_flush(); gdk_error_trap_pop() - I don't get it still, isn't that a gtk3 module?
[07:23] <diwic> mvo, the same code is compiled for both gtk3 and gtk2
[07:23] <diwic> mvo, and _pop_ignore is not present in gtk2
[07:23] <mvo> diwic: ohhhh, ok, thanks, that explains it
[07:24] <mvo> diwic: yeah, I knew that, I just did not know that it was build for gtk2 and that the build wouldn't fail. thanks a bunch for taking care of this!
[07:24] <diwic> mvo, btw, you agree that _pop would be the gtk2 equivalent of _pop_ignore in gtk3?
[07:25] <mvo> diwic: gdk_flush(); _pop() should be the same, but the flush() is important
[07:25] <mvo> diwic: in gtk3 this is done automatically by the pop_ignored(), but in gtk2 its not done automatically
[07:25] <diwic> mvo, yeah, it's a little confusing that the gtk2 module doesn't give a compile error imo
[07:25] <mvo> diwic: absolutely!
[07:29] <tumbleweed> cyphermox (and bhavi, who isn't around): Have you ever considered doing occasional backports of mobile-broadband-provider-info? It strikes me as something that'd be useful to occasionally update in older releases
[07:33] <pitti> tumbleweed, cyphermox: FYI, that even got an approved standing SRU exception: https://wiki.ubuntu.com/StableReleaseUpdates#mobile-broadband-provider-info
[07:33] <tumbleweed> I'm asking because someone was asking on a lug list, saying "obviously" it doesn't have $relatively-new-provider
[07:33] <tumbleweed> (err, asking what athe settings where)
[07:45] <infinity> Whenever I need a pick-me-up, https://bugs.freedesktop.org/show_bug.cgi?id=39752 never ceases to make me smile.
[07:48] <pitti> infinity: -08-02, is that April 1st times two?
[07:48] <infinity> pitti: Sadly, no.  I think the dude really was a nutter.
[07:49] <infinity> Almost as awesome as the guy who couldn't figure out how to attach his xorg.conf, so he printed it.  Scanned it.  And sent Daniel an image.
[07:49] <pitti> via fax?
[07:49] <infinity> Nope.  He attached the image to an email.  He knew how to do that!
[07:50] <infinity> (And I scoffed at that until I had that same conversation with my mother very recently.. "Oh, I didn't realise that word documents were like pictures, I can attach them the same way?!")
[07:51] <pitti> files are hrad
[07:51] <pitti> ... so is typing
[07:53] <dholbach> bug 10673, bug 13436 and bug 21507 will always be part of my favourites
[08:41] <ogra_> yay
[09:02] <cjwatson> wgrant: feel free to reassign such things to ubuntu-archive-tools (I've done that now for this one)
[09:02] <cjwatson> wgrant: er, "this one" being #276629
[09:24] <Daviey> cjwatson: Would you be able to look at https://code.launchpad.net/~davewalker/debian-cd/server-add-enlist/+merge/77143 today, pretty please? :)
[09:28] <bigjools> cyphermox: ping for when you are around please
[09:34] <cjwatson> Daviey: done and deployed
[09:35] <Daviey> cjwatson: Thanks!
[10:01] <wgrant> cjwatson: Ah, so that's where it lives. Thanks!
[12:08] <cyphermox> bigjools: pong.
[12:13] <cjwatson> bjf: could http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-o-tracking-bugs.html be generated more often?  it seems to be daily at the moment, which is awfully long when one is working on the list
[12:23] <Daviey> Is Desktop taking ~4 mins to boot to lightdm for anyone else?  /me notes he needs to look at his bootchart.
[12:24] <Daviey> Recent frequent mouse/touchpad lockups aswell?
[12:24] <hrw> is there a way to mark bug (against ubuntu package) as 'do not spam it with qa bot'?
[12:24] <ogra_> Daviey, its taking very long, but i'm on arm so that doesnt mean much
[12:25] <ogra_> its definitely a lot slower than nattys gdm was (havent tried oneirics gdm)
[12:26] <Daviey> :/
[12:27] <Daviey> My hunch is udev.. :)
[12:31] <jdstrand> mvo: hi! so, aiui if I have something like this in my sources.list
[12:31] <jdstrand> deb http://debmirror/...
[12:31] <jdstrand> deb http://security.ubuntu.com/...
[12:32] <jdstrand> mvo: then apt will pull from the first one, unless there is something newer in the 2nd. is that accurate? are deb-src lines supposed to work the same?
[12:32] <infinity> jdstrand: The only caveat to that is that apt will prefer signed repos first.
[12:33] <mvo> jdstrand: thats accurate, yes. I need to double check for deb-src, to  be certain but I think that is the case as well. plus what infinity said
[12:33] <infinity> (Even if they both contain the same packages with the same hashes, which I consider a bug, but whatever)
[12:33] <jdstrand> well, my debmirror is an rsync, so that should be fine
[12:41] <jdstrand> mvo: don't bother double-chcking the deb-src bit-- my debmirror seems out of date. I'm testing
[12:42] <jdstrand> mvo: yep, deb-src works the same
[12:45] <jdstrand> mvo, infinity: thanks
[12:47] <mvo> jdstrand: aha, cool. thanks
[12:48] <tgardner> is debian/files (which is created by dh_control) used for anything ?
[12:53] <cjwatson> tgardner: yes, dpkg-genchanges
[12:54] <cjwatson> it's absolutely essential
[12:54] <tgardner> cjwatson, but for what? I can't see that it has any impact.
[12:54] <cjwatson> it tells dpkg-genchanges which output files it needs to include in the .changes file
[12:54] <cjwatson> please leave it alone :-)
[12:54] <cjwatson> (binary .changes file that is)
[12:54] <tgardner> cjwatson, it doesn't exist when I package the kernel.
[12:54] <cjwatson> it's generated at run-time
[12:55] <tjaalton> uh, so are we auto-sleeping desktops too?
[12:56] <tgardner> cjwatson, well, I'm having periodic build failures when attempting to parallelize the kernel build due to occasional conflicts with competing dh_gencontrol statements.
[12:57] <cjwatson> don't parallelise dh_gencontrol
[12:57] <tgardner> cjwatson, I think I can work around it for developer builds. The archive build will continue to be single threaded.
[12:58] <cjwatson> dh_gencontrol (well, actually dpkg-gencontrol, which it calls) can't be parallelised unless somebody submits patches to dpkg to make it have some kind of lock around writing the files list
[12:59] <cjwatson> at least; I haven't looked at the rest of it
[12:59] <cjwatson> I'm guessing most of the rest is OK since it'd be under debian/foo/DEBIAN/
[12:59] <tgardner> cjwatson, yeah, I looked at the code.
[13:13] <infinity> tgardner: Why would the archive builds be single-threaded?
[13:13] <infinity> tgardner: We have multi-core buildds for a reason. :P
[13:14] <tgardner> infinity, perhaps a better way to put it is that the makefiles are single threaded
[13:14] <tgardner> CONCURRENCY_LEVEL=1
[13:14] <infinity> tgardner: Well, yes.  But if you're working on parallelising them for developers, I'm curious why you'd not do that on the buildds.
[13:15] <tgardner> infinity, I would except that I keep braking things.
[13:15] <infinity> tgardner: The buildds pass you DEB_BUILD_OPTIONS=parallel=$(nr_cores) just for that reason. :)
[13:15] <tgardner> break*
[13:16] <tgardner> infinity, the race in dh_gencontrol to update debian/files is currently an issue when running multiple packaging targets in parallel.
[13:17] <infinity> tgardner: I don't tend to parallelise binary-* rules, only build-* rules, but I know others are more daring.
[13:18] <tgardner> infinity,  the packaging phase is one of the slowest parts of the kernel build. I can get significant speedups by doing them in parallel (on a honking big machine like tangerine)
[13:18] <cjwatson> I expect you can parallelise lots of it, just not things like dpkg-gencontrol that write to shared resources
[13:18] <infinity> Fair point.  And, as Colin says, if it's all in isolated subdirectories, it shouldbe fine except for gencontrol.
[13:19] <tgardner> an therein lies the problem.
[13:19] <cjwatson> (Though I'm surprised to learn that it isn't all blocked on I/O)
[13:20] <tgardner> cjwatson, it likely is I/O bound on the puny buildds
[13:20] <infinity> The easy fix to that is to pull gencontrol out of binary-$(image), and have binary-arch depend on binary-image-* and run gencontrol once for each stamp serially.
[13:20] <infinity> Or something like that.
[13:21] <infinity> Did I really start that sentence with "easy"?
[13:22] <tgardner> infinity, I've got something like 12 kernel source packages to maintain. I'm thinking about taking a stab at patching dpkg-gencontrol
[13:22] <cjwatson> (if you do, send the patch to Debian rather than Ubuntu please - this isn't something where we should have a delta)
[13:23] <tgardner> oh, I agree
[13:23] <infinity> Implement locking for debian/files?
[13:23] <tgardner> infinity, something like that. there ought to be some kind of exclusion
[13:24] <infinity> Well, file locking in Perl shouldn't be particularly hard.
[13:25] <cjwatson> use Fcntl;
[13:25] <tgardner> I'm not exactly a perl wizard, but I used to know it once upon a time
[13:25] <infinity> I suppose that is the sane solution, given the number of people out there who just MAKEFLAGS := 16 willy-nilly without thinking about how it might affect dh
[13:25] <cjwatson> (actually 'use Fcntl qw(:flock);' probably)
[13:26] <infinity> There should be a -j in there somewhere.  Okay, it's nap time. :P
[13:26] <infinity> Clearly.
[13:26] <tgardner> infinity, nap time already? its 7:26 where you are, isn't tit ?
[13:27] <infinity> tgardner: I failed to sleep.
[13:27] <infinity> Not for lack of trying.
[13:27] <tgardner> ah, bummer
[14:01] <tseliot> cjwatson, pitti: can you reject my upload of fglrx-installer and fglrx-installer-updates, please?
[14:09] <ubuntu-baltix> hello all
[14:13] <infinity> tseliot: Done.
[14:13] <tseliot> infinity: thanks a lot
[14:14] <infinity> tseliot: (Best to ask those questions in #ubuntu-release, where people are idling for that specific purpose)
[14:14] <tseliot> infinity: good point
[14:26] <didrocks> barry: hey, small python question, from the last month (maybe a little bit more, I don't know), mvo and I started to experience a lot of bugs like bug #831652 with gettext, even with code that didn't change at all, any idea?
[14:27]  * roadmr is interested in the answer to this ^^ 
[14:28] <mvo> barry: or bug #859009, I'm pretty sure that worked for ages
[14:28] <roadmr> we had to change our code to explicitly specify encodings, even though it worked fine before
[14:28] <cjwatson> When I just fixed a bug like that in ubiquity it was because of a .encode vs. .decode mixup.
[14:36] <barry> mvo, didrocks, cjwatson yeah, that would definitely do it
[14:36] <cr3> roadmr: my favorite code relating to encoding is to expand escaped characters in a unicode string: mystring.encode('utf-8').decode('string-escape').decode('utf-8')... you need to encode and then decode the unicode string just to escape it, and this is actually the recommended way! :)
[14:37] <roadmr> cr3: well at least it's just one line, but yes, it looks weird
[14:37] <stgraber> tseliot: just saw the uploads, thanks!
[14:37] <barry> well, of course ideally, *all* your strings are unicode as early as possible.  e.g. i put this in all my python (>= 2.6) code:
[14:38] <tseliot> stgraber: thanks for bringing the bug to my attention
[14:38] <cr3> barry: do you think I should extreme negative comment that line? :)
[14:38] <barry> from __future__ import absolute_import, unicode_literals
[14:38] <barry>  
[14:38] <barry> no need to u'' your strings
[14:38] <didrocks> oh nice trick :)
[14:38] <barry> and with 2.6 you can b'' your specific byte strings
[14:38] <barry> so it will make conversion to py3 *much* easier
[14:39] <cr3> barry: I like how you slipped absolute_import in there, relative imports should be punishable by spanking :)
[14:39] <barry> cr3: when i read that subject line i thought "extremely negative" mean stuff like "i really suck for having to write this line" and that kind of thing
[14:39] <didrocks> well, a little bit late for this cycle, but definitively something to add for next cycle if projects aren't ported to 3
[14:39] <barry> cr3: *exactly* :)
[14:39] <barry> cr3: also this:
[14:39] <barry> __metaclass__ = type
[14:39] <barry>  
[14:39] <cr3> barry: same here
[14:40] <barry> now all your classes are new-style without having to inherit from object
[14:40] <pitti> ev: just reviewing lupin
[14:40] <barry> didrocks: yep, that's a big plan of mine so being very deliberate about strings vs. bytes is a huge part of that
[14:40] <cr3> barry: most of my classes use __metaclass__ = type, but I only import absolute_import when there's a relative name conflict
[14:40] <pitti> -       cp "/root/usr/share/language-support/incomplete-language-support-*.note" \
[14:40] <pitti> +       cp -af "/root/usr/share/language-support/incomplete-language-support-*.note" \
[14:41] <barry> cr3: the metaclass trick can go at module global level so it doesn't need to be put in the classes
[14:41] <pitti> ev: how does that help?
[14:41] <pitti> ev: I thought the issue was that the glob isn't resolved, for that you need to drop the quotes?
[14:41] <cr3> barry: err, I meant module... the launchpad way
[14:41] <pitti> ev: or am I misunderstanding this?
[14:41] <barry> cr3: right!
[14:41] <didrocks> barry: yeah, that's the only thing (unicode strings by default) that I feel really missing from 3 TBH, I'm not enough in 3 to see what else I miss right now, but I'm probably blind and uninformed :)
[14:41] <ev> pitti: the quotes are dropped
[14:41] <ev> oh interesting
[14:41] <pitti> ev: not in the debdiff
[14:42] <pitti> it just adds -af
[14:42] <ev> indeed, that's my mistake entirely
[14:42] <ev> apols, please reject
[14:42] <pitti> ev: no problem, thakns
[14:42] <ev> it was a bad copy of his patch
[14:42] <ev> manual copy*
[14:42] <ev> big thanks for that catch!
[14:42] <barry> didrocks: strings *are* unicode by default, by which i mean, unadorned quotes.  bytes are the oddball in py3 and need b'' prefixes for literals.  the trick is in converting from 2to3 if things aren't well defined
[14:42] <cr3> didrocks: I thought 3 was unicode by default. if not, I share the same feeling as you
[14:42] <pitti> ev: well, it's good to know that at least occasionally all this queue review actually helps :)
[14:43] <ev> most certainly :)
[14:43] <barry> actually, you can drop the "by default" :).  strings just *are* unicodes in 3
[14:43] <didrocks> barry: cr3: sorry, bad wording, the only thing I miss in my current python 2 programs compared to switch to python 3 is the unicode by default. Is that more clear? :)
[14:43] <cr3> barry: unicode as in 4 bytes per character, right? not utf-8 encoded internally
[14:44] <barry> of course, if you read a stream of stuff from a file, you need to be explicit about whether your reading bytes, or some text with a particular encoding.  that doesn't change, but i'm mostly talking about literals
[14:44] <pitti> ev: do we actually want the -f here? it might make errors less obvious
[14:44] <ev> indeed not
[14:44] <barry> didrocks: yep!  if you can target >= 2.6, definitely use the future import and that will help a lot
[14:44] <ev> I'll just drop the quotes in the new version
[14:44] <didrocks> barry: thanks for the info
[14:45] <barry> np!
[14:45] <cr3> didrocks: yes, more clear :) I share the pain but I think it's worth it, thinking in unicode eventually makes more sense
[14:45] <barry> cr3: http://docs.python.org/dev/reference/lexical_analysis.html#literals
[14:54] <mvo> barry: sorry if I missed that, but did you mention what actually changed that things are currently breaking that used to work? or is it somehting outside of python that is different now than it was before?
[14:56] <barry> mvo: i can't think of something that changed recently in python that would have started causing this.  i have another high priority bug i'm looking at atm, but can probably help with this if i get lucky with that one
[14:56] <mvo> barry: thanks, the would be much appreciated!
[14:58] <barry> mvo: np!
[15:13] <maco> ev: before i spend forever digging, why would ubi-partman.py read out both the templatey-generated-text and the filler text?
[15:14] <ev> maco: entirely not sure, sorry
[15:15] <ev> assuming that set_label/text and all that stuff gets fed back up to ATK
[15:52] <pitti> ev: lupin accepted; you didn't use -v to include previous changelog, so you need to close the bug manually
[15:52] <pitti> ev: thanks!
[15:54] <ev> pitti: sure thing, cheers
[16:18] <Daviey> slangasek: are you tracking boot speeds?
[16:18] <cnd> pitti, I'm online now
[16:35] <Sweetshark> infinity: Did I get that right, you would jump in for pitti for an upload if he is already off for the weekend?
[16:38] <slangasek> Daviey: QA is tracking them; we don't have a very streamlined reporting process for boot speed regressions yet however, so we generally fix things when someone notices
[16:38] <slangasek> Daviey: and in the case of server, everything suggests we need to slow boot down to let udev catch up ;P  why do you ask?
[16:54] <Daviey> slangasek: no, desktop is taking 4 mins to boot for me.  Seemed to be a concern :)
[16:54] <slangasek> Daviey: bootchart please
[16:54] <Daviey> Server boot speed, i don't much care for :)
[16:55] <slangasek> apt-get install bootchart, double-reboot, post /var/log/bootchart/$newest.png
[16:55] <Daviey> slangasek: let me reboot, to get a fresh one.. just need to finsh something.
[16:55] <Daviey> (i've done the first reboot)
[17:42] <Daviey> slangasek: http://bootie.daviey.com/~dave/voodoo-oneiric-20110930-3.png
[18:06] <nemo> So, I was curious...  Trying to do a build against box2d.  Path in app is Box2D/Box2D.h since that's where Box2D puts its main include
[18:06] <nemo> ubuntu though moves it one dir down
[18:07] <nemo> any particular reason for that?
[18:07] <nemo> like some ubuntu policy?
[18:29] <cjwatson> nemo: There are no Ubuntu-specific modifications to that package; we sync it unmodified from Debian, where it's had only one upload
[18:32] <cjwatson> nemo: box2d upstream doesn't appear to provide a 'make install' target, so there's precious little guidance as to how packages are meant to lay it out
[18:32] <cjwatson> nemo: so I don't think it's the result of any particular policy, just an arbitrary choice
[18:37] <nemo> ah
[18:38] <nemo> cjwatson: was just wondering.  make install for the box2d project puts it inside the box2d dir.  sooo when we run FindBox2d.cmake, we specify Box2D/Box2D.h in the cmake, and reference it as such in the #include - but that fails on the ubuntu version.
[18:38] <pitti> Sweetshark: checking in now
[18:38] <nemo> I guess the point is moot since I couldn't find any ubuntu version of 2.2.x anyway
[18:39] <SpamapS> whoa.. whats up with LP's builders?
[18:39] <SpamapS> 12 hours?
[18:46] <slangasek> Daviey: what the hell, man
[18:46] <slangasek> Daviey: loading your bootchart in my browser *consistently* makes my desktop crash!
[18:47] <cjwatson> nemo: ah, well, perhaps 'make install' was added after Debian packaged it
[18:47] <cjwatson> nemo: perhaps you'll need to detect where the include file is at configure time
[18:47] <cjwatson> slangasek: and he isn't even on the security team
[18:48] <nemo> cjwatson: yeah, I'll probably try that eventually, but since I can't even find a 2.2.1 ppa... :)
[18:48] <slangasek> cjwatson: no kidding
[18:52] <slangasek> Daviey: DUDE
[18:52] <slangasek> Daviey: it makes X crash even when I *don't* use my browser to load it
[18:52] <slangasek> Daviey: I think I see why your boot is so slow, bootchart is having to calculate an attack vector
[18:53] <slangasek> very CPU-intensive
[18:54] <stgraber> slangasek: bug confirmed ;)
[18:54] <stgraber> though I managed to see the bootchart for a few seconds before X crashed
[18:54] <slangasek> stgraber: it never loads all the way for me
[18:54] <slangasek> or it does, but my X server has better crash-speed :P
[18:55] <slangasek> anyway, it's a sigbus in the intel driver, according to logs
[18:55] <slangasek> RAOF_: how do I report an X server crash these days, given that apport seems to not be triggering (again/still)?
[18:55] <Daviey> slangasek: Ah, the png loaded trojan worked.
[18:55] <slangasek> Daviey: does it work for you? ;)
[18:55] <Daviey> yeah :/
[18:56]  * Daviey tries firefox
[18:56] <stgraber> http://paste.ubuntu.com/699998/
[18:56] <Daviey> wow, firefox is slow rendering it
[18:56] <slangasek> Daviey: what video chipset?
[18:57] <Daviey> nvidia non-free :(
[18:57] <slangasek> right
[18:57] <slangasek> this is an intel driver bug
[18:57] <slangasek> Daviey hates our freedom, all is explained
[18:57] <Daviey> I try to make my sysrtem as little free as possible.
[18:57] <Daviey> It makes me feel warm inside.  If i knew how to use OSX, i would so switch.
[18:58] <nemo> Daviey: Windows 8?
[18:58] <slangasek> fortunately the new compiz window switching model will help you get up to speed on that ;)
[18:58] <Daviey> nemo: i'm scared of change.
[18:58] <nemo> Daviey: well you're kinda screwed w/ Unity/Gnome shell then :)
[18:59] <Daviey> nemo: true :)
[18:59] <nemo> Speaking of horror of non-free, I think it is pretty darn cool that you guys added World of Goo.  I haven't gotten around to buying it yet, but I keep meaning to.   I'm a little concerned that I wouldn't be able to use the .deb on both my machines
[19:00] <Daviey> Image loads ok on ATI/AMD
[19:01] <slangasek> Daviey: yes, the crash is in the intel driver... you can stop taunting :)
[19:01] <nemo> Daviey: Also, you might enjoy this dude, who made our lives on the Hedgewars dev team unpleasant for a little while w/ his FOSS purity.  http://www.hedgewars.org/node/2480
[19:01] <slangasek> nemo: oh, is World of Goo in partner now?  Fun
[19:01] <slangasek> er, s/partner/app store/
[19:01] <nemo> yeps! nice to see more gaming under linux
[19:02] <Daviey> It took me 6 months of pondering to stump up ~$15 for minecraft.
[19:03] <slangasek> I keep missing out on the Humble Bundles because I take too long pondering them
[19:04] <slangasek> so instead I wound up shelling out the money for World of Goo on its own, ohwell
[19:04] <slangasek> (for a good cause - multiarch testing ;)
[19:05] <slangasek> ok, let's see if I can reproduce this intel crasher on my spare laptop :P
[19:05] <nemo> slangasek: oh. so. just curious. if I buy it from the App Store - is it tied to my UbuntuOne, to the computer, or is non-DRM, so I could put it on both home machines?
[19:05] <slangasek> nemo: you are certainly asking the wrong person :)
[19:05] <nemo> oh. thought you bought it
[19:05] <stgraber> nemo: it's linked to your ubuntu SSO account
[19:05] <slangasek> nemo: I bought it through the upstream website, before it was in the repo
[19:05] <stgraber> nemo: you can login on another machine with the same account in software center and install it there
[19:06] <stgraber> nemo: using the "Reinstall Previous Purchases" option from the menu
[19:06] <nemo> stgraber: nifty. I'll have to pick a better ubuntuone password and do that
[19:06] <slangasek> stgraber: but if you grab the raw .deb, that's still DRM-free, isn't it?
[19:06] <stgraber> slangasek: yep
[19:06] <slangasek> i.e., you can shuffle it around from system to system directly if you choose
[19:06]  * slangasek nods
[19:06] <nemo> slangasek: same for iphone I think. if you jailbreak the iphone you can just copy apps off
[19:06] <stgraber> you can also copy/paste the private PPA from /etc/apt/sources.list.d
[19:06] <nemo> slangasek: the signing just controls standard install
[19:06] <stgraber> and then just apt-get install it
[19:07] <nemo> they don't hash it on load or anything
[19:07] <slangasek> nemo: well, this isn't jailbreaking, this is endorsed by the authors :)
[19:07] <nemo> slangasek: yeah, but I was talking more about loose store controls :)
[19:07] <slangasek> AIUI
[19:07] <nemo> slangasek: usually such things are just to keep out the general riff-raff
[19:07] <nemo> slangasek: is why Apple gave up on DRM music.  Just annoyed people and drove more to piracy.  99% of purchasers are honest and fine w/ reasonable prices for convenience
[19:08]  * slangasek nods
[19:08]  * slangasek observes that the Humble Bundles continue to make more money from Linux users than anyone else
[19:09] <Keybuk> nemo: I don't think Apple "gave up"; I think Apple didn't like it either, but capitulated and waited until they had the music industry by the throat before taking action on it
[19:10] <Keybuk> a bit like Ubuntu's historical strategy with binary drivers, really
[19:16] <nemo> Keybuk: well, they aren't exactly into open interfaces anywhere else :-/
[19:17] <Keybuk> likewise, there wasn't a giant library of media content available from sources that did not demand DRM :)
[19:18] <mdeslaur> Apple started offering drm-free music because Amazon started selling drm-free music
[19:20] <Keybuk> mdeslaur: I don't think Apple genuinely care what Amazon do
[19:20] <Keybuk> Apple historically don't chase a minority userbase, like those who know what DRM is
[19:24] <mdeslaur> the labels wanted variable pricing from itunes, apple didn't want to give in, they started selling drm-free music to everyone else, including amazon, apple gave in to variable priced songs in exchange for drm-free music
[19:24] <slangasek> when will Amazon start selling drm-free books?
[19:26] <mdeslaur> slangasek: amazon sells drm-free books, the publisher decides when he uploads the file
[19:27] <slangasek> mdeslaur: that is not the answer to the question I was actually asking :)
[19:29] <mdeslaur> slangasek: all the kindle oreilly books are drm-free...what are you asking? when will amazon ask publishers to stop checking the drm box?
[19:29] <Daviey>  /j #ubuntu-discuss-apple-strategy
[19:30] <Daviey> Keybuk: I thought Apple DID chase a minority userbase?
[19:30] <slangasek> mdeslaur: when will Amazon stop conspiring with publishers to jerk us around wrt their ebooks being a worse value proposition than the paper ones
[19:30] <mdeslaur> heh, rathole..sorry
[19:31] <slangasek> mdeslaur: also, how do we fix the publishing industry so that places like Powell's Books can continue to exist as physical meeting / browsing spaces without the inconvenient paper inventory :)
[19:32] <Daviey> mdeslaur: and when will amazon start selling ponies?
[19:33] <ScottK> You mean they don't?
[19:33] <mdeslaur> slangasek: alas, Powell's is doomed to go the way of the record store. We've got starbucks (*$) now for that :)
[19:33] <slangasek> mdeslaur: ok, eew
[19:33] <mdeslaur> heeh
[19:33] <slangasek> starbucks does not fulfill the same function
[19:45] <Keybuk> slangasek: Books Inc in SF have an interesting gimmick, they have QR codes next to every book
[19:45] <Keybuk> scanning the QR takes you to a "buy the book" page
[19:45] <slangasek> Keybuk: that doesn't really go far enough to address the inventory problem
[19:46] <slangasek> you still have to stock the physical book to put a QR code next to it :)
[19:46] <Keybuk> only one
[19:46] <Keybuk> after all, a big part of book stores is that people come in, sit down, and read a chapter
[19:46] <Keybuk> then decide whether or not to buy
[19:47] <Daviey> i'd feel damn rude doing that.
[19:47] <slangasek> Daviey: they sell you expensive coffee drinks to assuage your conscience
[19:47] <Daviey> ah, good o
[19:48] <Keybuk> and sell you expensive books if you decide you like them :p
[19:50] <slangasek> Daviey: what is 'iwatch'?
[19:55] <nemo> Keybuk: was actually pretty amusing. last time we were in a bookstore, my SO whipped out Google Goggles to scan the barcode of the book she was interested in to add it to her amazon queue.
[19:55] <slangasek> Daviey: you have iwatch, cobblerd, smbd, and mythbackend services starting on boot, all taking up a lot of the boot time; this is not the "fast boot" target case
[19:55] <nemo> Keybuk: and here she was bemoaning the death of the bookstore she used to work at (Borders)
[19:56] <slangasek> Daviey: you also have either some unusual remote mounts (iscsi?) that cause the filesystem event to be delayed, or you have a kernel bug causing your video to be slow to init, *or* you have contention keeping dbus from starting up early, because lightdm doesn't start until 158 seconds into the boot
[19:58] <Daviey> slangasek: they didn't look to add *that* much time
[19:58] <Daviey> slangasek: I'll happily remove those things, i'm willing to bet it's still > 3.5 mins.
[19:59] <slangasek> Daviey: what does /etc/network/interfaces have in it?
[19:59] <slangasek> and do you have any remote filesystems configured?
[20:00] <Daviey> slangasek: not on that boot, i didn't
[20:00] <slangasek> iwatch is occupying your system for 30s... that's not insignificant
[20:00] <Daviey> i do have a funky bridge setup, http://pb.daviey.com/kjHS/
[20:01] <Daviey> crikey
[20:03] <slangasek> the bridge network does seem to be taking a long time to init
[20:06] <slangasek> udev rule for the interface triggers at 28s, takes 2s just to run ifconfig (!), then there's a 6s sleep... dhcp comes up fairly quickly, just 4s after that.  But somehow the ifup command doesn't return forever...
[20:06] <linuxnewb_> how can i find the ip address of a p2p (another person's notebook connected to my notebook) in linux' terminal?
[20:07] <stgraber> I've seen ifup take up to 30s per bridge on some machines (when it does, it usually prints the reason)
[20:07] <slangasek> Daviey: which probably means you're hitting the failsafe network timeout at boot, because the ifup hasn't succeeded
[20:08] <cjwatson> I think the problem is that I LD_PRELOADed gettimeofday() to sleep 200ms the last time I was near Daviey's laptop
[20:08]  * cjwatson watches Daviey go off to hunt for that
[20:08] <stgraber> ;)
[20:08] <slangasek> stgraber: yes, this is something else; the bridge initialization finishes, dhcp is up, and the ifup call hangs around for another 200s+
[20:09] <slangasek> and there's no indication on the chart of what child process it might be waiting for
[20:09] <slangasek> Daviey: is 'ifup' still running? :P
[20:10] <Daviey> slangasek: no
[20:11] <Daviey> cjwatson: hah
[20:14] <slangasek> Daviey: ok.  can you paste /run/network/ifstate, and ls -l /etc/network/if-up.d/ ?
[20:14] <siretart> infinity: I've just released Libav 0.7.2, which is pretty much what is in oneiric right now (~6 upstream patches similar to those you've already seen). Do you think it's worth uploading to oneric-proposed? I guess it makes things a bit easier for the sec-team, but YMMV of course
[20:15] <Daviey> hah, /run/network/ifstate http://pb.daviey.com/gada/
[20:15] <Daviey> *why* i pastebinted 1 line, i don't know.
[20:16] <Daviey>  ls -l /etc/network/if-up.d/ - http://pb.daviey.com/tbKF/
[20:17] <slangasek> Daviey: right; somehow the interface was never brought up, which I think means dhclient never returned success to ifup
[20:20] <Daviey> slangasek: Okay, if you think it's a configuration issue, i won't waste your time anymore.  I'll dig through it at some point, and see if i can work it out.
[20:21] <slangasek> Daviey: I *don't* think it's a configuration issue, dhcp is clearly succeeding (because it runs dhclient-script), but ifup doesn't return... that's a bug :)
[20:24] <Daviey> oh goody.
[20:27] <slangasek> Daviey: you have isc-dhcp-client installed, right?
[20:29] <Daviey> slangasek: Installed: 4.1.1-P1-17ubuntu10
[20:31] <slangasek> Daviey: ok, just checkin'
[20:33] <SpamapS> Hmm my latest dist-upgrade is stuck running this
[20:33] <SpamapS> root     26177  0.0  0.0   4264   580 pts/6    D+   12:19   0:00 /bin/sh -e /usr/lib/os-probes/mounted/20macosx /dev/sda2 /mac hfsplus
[20:37] <slangasek> SpamapS: subprocesses? dmesg?
[20:39] <SpamapS> slangasek: subprocesses were tr and paste..
[20:39] <SpamapS> slangasek: killed them both
[20:39] <slangasek> ... paste?
[20:41] <soren> Darn it. man dpkg-genchanges(1) lies. :(
[20:41] <SpamapS> hmm.. not sure what the D+ is for ..
[20:41] <slangasek> SpamapS: I can't see how that script should ever hang, barring disk problems
[20:41] <slangasek> SpamapS: does accessing the /mac mountpoint hang?
[20:42] <cjwatson> or bug in hfsplus.ko perhaps
[20:42] <cjwatson> I'm sure it's not the best-tested fs implementation
[20:42] <slangasek> ah, I mentally included that in "disk problems" :)
[20:42] <SpamapS> actually yes its hanging.. doh
[20:42] <soren> "There's no distinction between -b, -B and -A, the produced .changes file will include whatever files were created by the binary-* target(s) of the package being built." <--- Except it won't include Arch: all packages if run with -B. :(
[20:43] <slangasek> soren: you have an Arch: all package being built when running with -B?
[20:43] <SpamapS> GPF in hfsplus
[20:43] <soren> slangasek: Yeah. I was having fun :)
[20:43] <slangasek> soren: heh
[20:44] <slangasek> soren: well, don't expect launchpad to accomodate fun of that nature either... :)
[20:44] <soren> slangasek: That's exactly what I was trying to find out.
[20:44] <Daviey> SpamapS: Does it have a journal?  hfsPLUS does AIUI, and can only be mounted read-only, that might be it.
[20:44] <SpamapS> http://paste.ubuntu.com/700076/
[20:44] <SpamapS> yeah I only want it readonly
[20:45] <SpamapS> just so I can get at any old docs I have on the os x drive
[20:45] <soren> slangasek: I really just wanted to get some stuff built on amd64 to bypass the insane build queue on i386, but then I realised I might be able to use it to fix  e.g. bug 183495
[20:45] <Daviey> SpamapS: It would be interesting to see if you see the same behaviour with the journal dropped.
[20:45] <SpamapS> this could also be corruption/hardware related
[20:45] <SpamapS> can't say I can remember the last GPF I saw in anything
[20:45] <slangasek> soren: it *might* happen to work right now, but a) I doubt it because launchpad has *very* strict sanity-checking at accept time, and b) you certainly aren't going to get any guarantees that it'll continue working
[20:46] <soren> slangasek: AFAIR, dpkg-genchanges is run by sbuild so I'm stuck anyway.
[20:46] <slangasek> yeah, could be
[20:46] <soren> Err..
[20:47] <soren> Well by dpkg-buildpackage.
[20:47] <soren> Something I don't control at least.
[20:47] <soren> Every 6 months or so I have a new "great" idea of how to fix that one. It never works out :)
[20:50] <Daviey> soren: build it arch any, build-dep on qemu-system-sparc, produce the binary within that :)
[20:50] <cjwatson> SpamapS: actually, what's weird is that that should be using grub-mount
[20:51] <Daviey> s/any/all
[20:51] <SpamapS> At this point my fonts are all doinked and nothing works right, time to reboot..
[20:51] <soren> Daviey: I think I actually tried that.
[20:52] <soren> Daviey: I think I got stuck because I needed access to ports.
[20:52] <cjwatson> SpamapS: ... oh, I guess you already had that fs mounted so os-prober used the existing mount
[20:52] <soren> Daviey: ...which I couldn't depend on either.
[20:52] <SpamapS> cjwatson: right
[20:52] <Daviey> soren: hah
[20:52]  * SpamapS reboots.. bbiab
[20:52] <soren> Daviey: The best guess right now is some sort of ia32-libs-ish thing.
[20:52] <soren> Daviey: So build it on sparc, and have another package pull that deb.
[20:52] <cjwatson> maybe we should give grub-mount priority over even existing mounts
[20:53] <soren> Daviey: and shove its contents into an arch: all package.
[20:53] <Daviey> soren: Surely that has the same issue, of the sparc built package being in ports?
[20:53] <soren> Daviey: But I always lose my will to live before I finish that.
[20:54] <soren> Daviey: ia32-libs is sticted together at source package build time.
[20:54] <soren> stitched.
[20:54] <Daviey> ah
[20:54] <soren> Daviey: Not at binary package build time.
[20:54] <soren> Daviey: That's why the source package is half a gig :)
[20:56] <Daviey> soren: I understood Debian were considering blocking bin uploads, will be interesting to see how they resolve that.
[20:56] <soren> Daviey: Good question.
[20:57] <infinity> siretart: Not living in patch hell might be pleasant.  You have a diff?
[20:57] <cjwatson> Daviey: I mentioned this example to the Debian ftpmasters at DebConf; they're aware of it and will ensure it doesn't get broken by throwaway-binary uploads
[20:58] <infinity> Sweetshark: ACK on the being around for an upload thing.
[20:58] <cjwatson> I think by having a mechanism for certain arch-all packages to be forced onto certain architectures
[20:59] <Sweetshark> infinity: https://launchpad.net/ubuntu/+source/libreoffice/1:3.4.3-3ubuntu2 too late ;)
[21:00] <Sweetshark> infinity: but still: thank you very much!
[21:00] <Daviey> cjwatson: a Please-build-this-any-on-this-arch: commodore64 , _changes option?
[21:01] <infinity> Sweetshark: So I saw. :)
[21:02] <cjwatson> Daviey: something like that
[21:02] <cjwatson> I'm not sure if it'd be Packages-arch-specific or .changes or manual-db-hacking (given that there are like three of them) or what
[21:03] <Daviey> Interesting
[21:10] <infinity> cjwatson: P-a-s seems like a reasonable way to go.
[21:14] <siretart> infinity: you mean sth like http://git.libav.org/?p=libav.git;a=shortlog;h=refs/heads/release/0.7 or rather http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=shortlog?
[21:16] <SpamapS> ahh lovely console
[21:16]  * SpamapS waits for dpkg --configure -a to finish :P
[21:23] <SpamapS> wow that was pretty painful..
[21:23] <infinity> siretart: Or something like a libav_0.7.2-0ubuntu1 package? :)
[21:23] <SpamapS> I feel like we should have a check at boot time, if your system has unconfigured packages, it should offer to run dpkg --configure -a for you.
[21:24] <ScottK> Because boot speed hasn't regressed enough already?
[21:24] <Daviey> cjwatson: By Jove, cobbler-enlist works from the ISO.
[21:24] <cjwatson> Awesome.
[21:24] <cjwatson> A last-minute update that went right!
[21:24] <infinity> Don't jinx it.
[21:25] <Daviey> exit non-zero also allows you to try again \o/
[21:25] <Daviey> infinity: I'll juju it
[21:25]  * cjwatson touches his desk for luck
[21:25] <siretart> infinity: well, it would be a pretty minimal libav_0.7.2-1ubuntu1 (compared to libav_0.7.2-1)
[21:27] <infinity> jamespage: What creates the nova group?
[21:27] <SpamapS> ScottK: one more grain of sand in the hourglass. :)
[21:27] <infinity> jamespage: (hint: "adduser --ingroup foo" doesn't create groups)
[21:28] <slangasek> SpamapS: and do all interaction via plymouth? :)
[21:28] <infinity> siretart: I was sort of driving at "I'd like no packaging changes, just the upstream version bump to drop the 63 cherrypicks".
[21:28] <SpamapS> We could actually make it pretty fast.. have dpkg put an upstart job in /etc/init that does the recovery, and remove it when its done.
[21:28] <infinity> siretart: Hence -0ubuntu1 seeming more appropriate than -1ubuntu1 (since it's not based on -1, which has multiarch)
[21:28] <infinity> siretart: But whatever. :)
[21:29] <SpamapS> slangasek: well now you're talking crazy. :)
[21:29] <slangasek> yes, yes I am
[21:29] <ScottK> slangasek: Didn't you hear.  That's just for a pretty boot and everyone should just remove it anyway.
[21:30] <slangasek> ScottK: that's why I replaced it with a job that just runs fsck -pyf /dev/*
[21:30] <SpamapS> slangasek: thats masterclass right there
[21:31] <infinity> jamespage: Ahh, nevermind, you already had the group before, just fixing up some old users, I guess.
[21:31] <siretart> infinity: right
[21:31]  * infinity wants more context in his diffs.
[21:31] <slangasek> reeses context diffs
[21:31] <slangasek> is it friday?  I think it's friday
[21:31] <infinity> I dunno, does that mean I get more diffs in my context?
[21:32] <slangasek> yes
[21:32] <cjwatson> slangasek: s/fsck -pyf/shred/
[21:32] <slangasek> :)
[21:34] <infinity> siretart: (I'd even entertain the idea of such an upload say... Nowish)
[21:35] <infinity> siretart: From the security headache standpoint, that seems much nicer than 0.7.1+63cherrypicks. ;)
[21:39] <bdmurray> is there someone familiar with perl who can look at 678060?  this person has reported dozens of perl crashes
[21:45] <slangasek> bdmurray: the backtrace is pretty nondescript. I think it probably needs to be debugged in situ
[21:47] <slangasek> it's also probably not a perl bug at all, but would take a lot of work to confirm this
[21:51] <infinity> bdmurray: A reproduction script would be nice.
[21:51] <slangasek> maco: would you be interested in helping with bug #837042?  I'm concerned that this Kubuntu-specific ubiquity bug is going to wind up remaining unfixed when there are still so many general ubiquity bugs still being worked on
[21:51] <slangasek> infinity: the submitter has filed bugs reporting large numbers of random perl scripts crashing
[21:52] <infinity> slangasek: So, he's reporting that he has bad RAM?
[21:52] <cjwatson> slangasek,maco: hah, I'd just started looking at that :)
[21:52] <slangasek> cjwatson: oh, carry on ;)
[21:52] <slangasek> infinity: maybe?
[21:53] <cjwatson> just setting up a test environment
[21:53] <maco> slangasek, cjwatson: i've got a bit of a11y almost-there-ness to dig into on ubiquity
[21:53] <slangasek> infinity: or maybe a bad CPU implementation...
[21:53] <maco> it reads pretty much all the stuff it needs to!  ....and then some
[21:54] <maco> "Replace $OS with Ubuntu. Replace Windows with Ubuntu. Checkbox not checked"  the second sentence needs to go away :-/
[21:54] <slangasek> heh
[21:55] <bdmurray> not the first one?
[21:55] <slangasek> infinity: what's particularly odd is how all of the crashes he reports are segfaults in memory-management-related functions... across multiple programs
[21:55] <infinity> I prefer losing both sentences.  Translation is so much easier when the UI is just checkboxes and radio buttons with no explanation.
[21:56] <slangasek> well, no, I guess the perl crashers are more varied than that
[21:57] <infinity> slangasek: Does he have any perl crashes that couldn't be readily explained by a bit-flip in bad RAM?
[21:57] <infinity> slangasek: Cause I'm having a hard time believing Perl hate him, and only him, when most of us rely on it working 24/7.
[21:57] <cjwatson> I'd definitely rather maco were looking at a11y bugs, since I've already tried to investigate those and got absolutely nowhere
[21:58] <slangasek> bdmurray: I would suggest picking one of the bugs in question, setting it incomplete and asking him for hardware details, with the comment that things are crashing for him that don't crash for anybody else and it looks like a broken system; and if no explanation is forthcoming, mass-close any bugs he's filed that haven't been confirmed by others
[21:58] <slangasek> infinity: the one bdmurray pointed to has a crash at 0x04000008... that ain't no bit flip
[21:59] <bdmurray> slangasek: I was thinking of incompleting all of them in case I forget or he never replies.
[21:59] <maco> bdmurray:  it doesnt say "dollar sign oh ess" :P but it could end up saying "Replace Mac OS with Ubuntu. Replace Windows with Ubuntu." when you havent got windows
[21:59] <slangasek> bdmurray: should we be collecting /proc/cpuinfo in all reports? it might have been helpful here
[21:59] <slangasek> bdmurray: incomplete> sure, sounds good
[22:00] <infinity> slangasek: Hrm?  Any attempts to read to/from the wrong regions can easily be because the pointer got garbled when it mistakenly took a vacation in RAM.
[22:00] <infinity> The solution to this is clearly more registers.
[22:00] <infinity> A lot more.
[22:01] <cjwatson> perl mm crashes can often be broken extensions
[22:02] <slangasek> infinity: what single-bit error accounts for trying to read from an address of 0x04000008?
[22:02] <slangasek> I think cjwatson's explanation the more likely
[22:02] <cjwatson> even if they don't show up in a backtrace, given the spooky-action-at-a-distance nature of a lot of memory corruption
[22:02]  * slangasek nods
[22:03] <cjwatson> I must admit that I find it unproductive to investigate perl crashes - it takes so long and it's so rare that it's actually a real problem
[22:03] <slangasek> exactly
[22:03] <cjwatson> if we want to do something about them we should sic a real perl core hacker on them
[22:04] <cjwatson> (who will tell us we should be on 5.14)
[22:04] <tjaalton> forgive my question, but has authconfig (from fedora) ever been evaluated for handling the configuration of network logins in the installer. I know it doesn't fit as-is, the pam config backend should just be disabled, the config backend should use debconf etc, but otherwise..
[22:05] <cjwatson> no, I don't believe so
[22:05] <tjaalton> uh, too long a line
[22:05] <slangasek> I think "point out nobody else's perl is broken, and incomplete the bugs" would be a more appropriate course of action :)
[22:05] <cjwatson> it's not clear to me that the installer is a good place to configure network logins at all
[22:05] <slangasek> tjaalton: sure, I evaluated authconfig; that's why I wrote pam-auth-update :)
[22:05] <tjaalton> slangasek: hehe, but it only does a part of it
[22:05] <slangasek> yes
[22:06] <slangasek> someone else gets to write the other parts
[22:06] <slangasek> :)
[22:06] <tjaalton> yes
[22:06] <slangasek> but, in general authconfig fails Debian Policy, which is why I started from the other end
[22:07] <tjaalton> cjwatson: how so? every time ubuntu is reviewed here they complain why you can't configure it from the installer, but go through various loops instead
[22:07] <cjwatson> my view is that the installer should get the OS on there and get out of the way
[22:08] <cjwatson> I must admit it's news to me that installer reviews are complaining about the lack of network login; that's not one I'd heard before (though perhaps I'm amnesiac)
[22:08] <cjwatson> bit-flip> a machine I use once developed a bit-flip in /bin/cat; it was amazing how much kept working
[22:09] <cjwatson> network logins are about on the edge of what I can see being reasonable in the installer; I could probably argue it either way
[22:09] <slangasek> bug #856290 is a fun bitflip bug
[22:09] <cjwatson> but, like slangasek, I find it unlikely that authconfig would be a good place to start
[22:09] <cjwatson> except for requirements gathering maybe
[22:09] <infinity> cjwatson: Given that our installer creates a user, network logins sort of seem to fit with that.
[22:09] <slangasek> cjwatson: right; with pam-auth-update I partly aimed to reduce this to a package selection question
[22:09] <tjaalton> cjwatson: usually people who need them use preseeding etc, but it would help demoing a new release
[22:10] <cjwatson> infinity: that would be the other side of the argument, yes
[22:10] <tjaalton> ok, so what I had in mind would be a way to configure sssd the way fedora does
[22:10] <tjaalton> it has a python api, which authconfig supports
[22:10] <cjwatson> I would expect you'd want a couple more steps in user-setup
[22:10] <infinity> cjwatson: So, stop creating user 1000, and we're good. ;)
[22:10] <tjaalton> of course it doesn't have to be authconfig to poke it..
[22:10] <Daviey> I'm not sure those that care about network logins are the same people that care to use ubiquity.
[22:11] <cjwatson> a python api is not very useful here
[22:11] <cjwatson> Daviey: d-i
[22:11] <tjaalton> still
[22:11] <slangasek> tjaalton: but if what you want is to configure sssd, just... make sssd configurable
[22:11] <tjaalton> slangasek: well, got a point there
[22:11] <slangasek> authconfig doesn't help with that, you just need to debconfiscate it
[22:11] <stgraber> tjaalton: btw, I plan to have a ubiquity plugin in Edubuntu 12.04 doing just that ;)
[22:11] <tjaalton> right
[22:11] <tjaalton> stgraber: oh?
[22:11] <Daviey> This does sound like a reasonable target for Orchestra foo.
[22:11] <SpamapS> agreed
[22:12] <stgraber> tjaalton: with "easy" integration for AD, openldap and edirectory (the most common in education)
[22:12] <cjwatson> user-setup goes before package selection, so you could have it have network login options in expert mode
[22:12] <cjwatson> (priority=medium) which would make it preseedable and accessible by kickstart too
[22:12] <infinity> slangasek: Hah.  "fesign".  I like it.
[22:12] <slangasek> personally, I'm not thrilled with sssd's model of "route all pam and nss calls here and add another layer", but ah well
[22:12] <infinity> slangasek: I wish all "dying storage" bugs were that obvious.
[22:12] <slangasek> infinity: :)
[22:12] <stgraber> tjaalton: so they can just enter some AD credentials and have it working next time they reboot (won't deal with tricky things like network shares though and will need them to have the POSIX extensions in AD as I don't want to use winbind)
[22:13] <tjaalton> slangasek: the point is having one connection to the servers, and not all clients doing their own stuff
[22:13] <tjaalton> slangasek: also the same what osx does, i'm told
[22:13] <stgraber> anyway, got to run :)
[22:13] <tjaalton> but you probably knew that
[22:13] <slangasek> tjaalton: there were other implementations of this already... sssd wants to be one connection to *all* servers :)
[22:14] <tjaalton> slangasek: oh you mean likewise etc?
[22:14] <slangasek> there's an ldap-only proxy thing
[22:14] <tjaalton> stgraber: yeah winbind is baad
[22:14] <Daviey> likewise-open has with tradition been pretty well supported by us and upstream.
[22:14] <tjaalton> it has it's limitations though
[22:14] <slangasek> and credentials-caching stuff for kerberos
[22:15] <Daviey> tjaalton: are those documented?
[22:15] <slangasek> but if people are happy with sssd, so be it :)
[22:15] <tjaalton> Daviey: yes, supported only in the enterprise version
[22:15] <tjaalton> slangasek: well, pam_krb5/pam_ccreds et al are not that robust
[22:15] <tjaalton> sorry
[22:15] <tjaalton> pam_krb5 is
[22:16] <tjaalton> but if you need offline creds, pam_ccreds never worked for me
[22:16] <tjaalton> and the same for nss data
[22:17] <tjaalton> ..which basically needed you to dump the whole directory locally
[22:25] <SpamapS> ccreds worked for me "back in the day" ...
[22:25] <SpamapS> been a long long time since I mucked with it..
[22:25] <tjaalton> it's the directory side that's harder to get working offline
[22:25] <tjaalton> reliably anyway
[22:25] <SpamapS> heh.. thats kind of a weird notion anyway
[22:26] <SpamapS> letting your whole directory flow out of your organization onto laptops seems a bit daft
[22:26] <SpamapS> A small subset of it to be cached by the apps that use it.. for email/names/etc. works fine.
[22:27] <tjaalton> yeah you don't need whole of it, but that's what the silly modules did. maybe the ldap-proxy would work better
[22:27] <infinity> SpamapS: You don't need to export full directories to systems to make them work.
[22:27] <tjaalton> nss-updatedb, that's the name
[22:28] <infinity> SpamapS: ud-ldap (I know, not a solution anyone outside of Debian/Freedesktop/Canonical likes) is smart about making sure hosts only get the users and groups they need, etc.
[22:35] <infinity> Ugh.  I really hate how /+filebug from an apport crash report still requires me to type descriptions.  "It broke, apport told me so."  99% of the time, that's about all any user will know.
[22:37] <sbeattie> which is what oh so many of the bug reports filed that have for a description.
[22:37] <sbeattie> s/that/that way/
[22:40] <infinity> sbeattie: Yeah.  It also prompts me half the time to just close the window in annoyance, though.  I can only imagine that users, when faced with "you must enter a description" don't do well.
[22:56] <SpamapS> is it just me or is there something screwy with terminator making the fonts blurry?
[23:01] <SpamapS> seems to be only on my DVI connection. Hrm.
[23:01] <SpamapS> ah
[23:01] <SpamapS> unplug, replug.. instant happy
[23:01] <SpamapS> weird
[23:13] <slangasek> your cable must have been in analog mode
[23:22] <SpamapS> anything used in postinst that is not part of the base system needs to be Pre-Depends right?
[23:22] <slangasek> noooooooooo
[23:22] <SpamapS> ok good
[23:22] <slangasek> PRE depends for PRE inst
[23:22] <SpamapS> right right ok
[23:22] <slangasek> :-)
[23:22] <slangasek> postinst == depends
[23:28] <yofel> hey, does someone know how to tell the archive builders not to run optipng on the icon files of a package?
[23:29] <yofel> it breaks the kile symbol table (kde latex editor)
[23:32] <yofel> looking at pkgbinarymangler, is adding 'export NO_PNG_PKG_MANGLE=1' in debian/rules all I need to do?
[23:33] <slangasek> yofel: yes
[23:33] <yofel> ok, thanks