[00:05] <cjwatson> bdmurray: I hope my comments in bug 1039484 and the rationale for why I don't think this should be done in python-apt make sense
[00:05] <cjwatson> bdmurray: You mention "two places" in the MP - what's the other?
[00:21] <mfisch> robert_ancell: I responded to your question on gnome-icon-theme-symbolic
[00:25] <robert_ancell> mfisch, my point is neither the gnome-icon theme git log (http://git.gnome.org/browse/gnome-icon-theme/log/) or tarball show any of these changes for gnome-icon-theme
[00:31] <bryceh> infinity, jockey and nvidia-common fixed and re-uploaded
[00:33] <bryceh> infinity, I renumbered nvidia-common to 0.2.44.1 which I suspect is more correct since it's an SRU of a native package; the previous upload was 0.2.46... I'm assuming it's not too late to redo the number but if so I can redo it as .46.
[00:33] <rickspencer3> hi bryceh
[00:33]  * rickspencer3 waves back
[00:43] <mfisch> robert_ancell: sorry, I had it backwards, updating the bug
[00:44] <mfisch> robert_ancell: looks like this is only a version change
[01:11] <infinity> bryceh: That should be fine, lemme give them a once-over right now.
[01:12] <bdmurray> cjwatson: yes, it makes sense that merge proposal was a bit stale.  I believe it was also crashing in logging.debug() although it isn't happening with my test now
[01:14] <cjwatson> It'll depend on the other arguments.  In general, in Python 2, attempting to do unicode_value % utf8_byte_string_value will fail.
[01:15] <cjwatson> (Which logging.debug may do under the covers.)
[01:15] <infinity> bryceh: The fix for #976779 ... Shouldn't the package ship the /var/lib/nvidia-common directory?
[01:15] <infinity> bryceh: Or does hybrid-detect write the directory as well as the file?
[01:16] <bryceh> lemme doublecheck
[01:17] <infinity> bryceh: Yeah, looks like it just does an fopen() on the filename, so that's going to fail without the directory being present.
[01:17] <infinity> bryceh: Probably needs fixing in quantal too, if this was a straight backport.
[01:19] <bryceh> in setup.py is:                ("/var/lib/nvidia-common/", glob.glob("share/last_gfx_boot")),
[01:19] <bryceh> infinity, let me check the deb but I think it establishes the dir at package install time
[01:19] <infinity> bryceh: Ahh, I didn't notice that setup.py was creating the path.  That'd do it.
[01:20] <bryceh> -rw-r--r-- root/root         5 2012-09-20 07:04 ./var/lib/nvidia-common/last_gfx_boot
[01:20] <bryceh> yep, it's in the .deb
[01:21] <infinity> Shiny.
[01:21] <infinity> Accepting both, then.
[01:21] <bryceh> thanks :-)
[01:22] <infinity> bryceh: Thanks for fixing all the nit-picking. ;)
[03:39] <mfisch> robert_ancell: someone registered the wrong upstream project for sonic, I'm going to fix it
[03:41] <robert_ancell> mfisch, yeah, there's a suprising number of those - I don't know if that was people or a script that linked them
[03:43] <mfisch> it caused me some confusion, but it's fixed now
[03:55] <mfisch> robert_ancell: what's the fix for this?  dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
[03:55] <mfisch> robert_ancell: there's a control field I think I can use, can't remember what it is
[03:56] <robert_ancell> mfisch, it's just the maintainer field
[03:56] <robert_ancell> we just set them to Ubuntu Desktop if they're maintained by the desktop team
[03:58] <mfisch> the last upload was NMU as well
[03:58] <mfisch> so it somehow worked
[03:58] <mfisch> I did talk to the maintainer BTW
[03:59] <jetsaredim> is there an easy way to unpack the source of a given package to see how it's built?
[04:00] <jetsaredim> without having to setup a whole development environment?
[04:00] <mfisch> jetsaredim: apt-get source <package>
[04:01] <jetsaredim> where does it get deposited?
[04:01] <mfisch> in your current directory
[04:01] <mfisch> and you don't need to use sudo
[04:01] <infinity> mfisch: That warning is implying that you should run "update-maintainer(1)"
[04:04] <mfisch> infinity: so that just un-made Bill Cox the maintainer
[04:04] <infinity> mfisch: Bill Cox being the Debian maintainer?
[04:05] <mfisch> I assume so
[04:05] <mfisch> he's the upstream maintainer
[04:05] <infinity> Yes, well.  That's correct.
[04:05] <infinity> Ubuntu-modified packages are maintained by ubuntu-devel.
[04:05] <mfisch> I'm still curious how the last upload worked, but I'll make this change
[04:06] <mfisch> thanks infinity
[04:06] <infinity> And the original maintainer is set as Original-Maintainer in the control info.
[04:06] <infinity> The last upload may have worked if you didn't have DEBEMAIL set when you built it.
[04:06] <mfisch> must have been (it wasn't me who did it)
[04:06] <infinity> Which makes the hard error turn into a warning, for reasons the devscripts maintainer has never convinced me make sense.
[04:07] <mfisch> that script set "XSBC-Original-Maintainer", I assume that's right
[04:07] <infinity> Either way, it's Ubuntu policy to change maintainer when we change packages, so the Debian maintainers don't get hassled about things we change/break in Ubuntu.
[04:07] <infinity> mfisch: It does it right, yes.
[04:07] <jetsaredim> its been a while since I wrote/reviewed Makefiles but where would the configure script be called?
[04:07] <mfisch> thanks, I was worried that changing it was a rude thing to do maybe ;)
[04:07] <mfisch> jetsaredim: usually in ./configure?
[04:07] <infinity> mfisch: No, not changing it tends to be the rude thing.  This policy was at the request of Debian. :)
[04:08] <infinity> (Or, rather, many many Debian developers)
[04:08] <jetsaredim> mfisch: no i mean where is that called from
[04:08] <jetsaredim> like where are the options defined for calling configure
[04:08] <infinity> jetsaredim: If you're talking about packaging, in debian/rules
[04:09] <mfisch> ah, well it's done durin...
[04:09] <mfisch> what he said
[04:09] <infinity> jetsaredim: If you're building by hand, nothing calls configure, you do.
[04:11] <jetsaredim> infinity: i'm trying to figure out what is causing an issue I'm seeing with a given package
[04:11] <jetsaredim> tcdecode which is part of transcode is complaining about not being able to handle mpeg2
[04:11] <jetsaredim> (in quantal)
[04:12] <jetsaredim> was just trying to see if the configure option had been set to include the --enable-libmpeg2
[04:12] <jetsaredim> which is seems to have - so now i'm a bit baffled
[04:12] <mfisch> jetsaredim: sounds like you'll want to setup a build environment and see how it was built
[04:14] <jetsaredim> mfisch: i'm a little over my depth at this point
[04:14] <mfisch> jetsaredim: how did you figure out if that flag was enabled?
[04:14] <jetsaredim> its listed in the rules file
[04:14] <pitti> doko_: more like 0:8 :(
[04:14] <jetsaredim> confflags += --enable-libmpeg2
[04:15] <pitti> Good morning
[04:15] <jetsaredim> mfisch: ldd seems to think that none of the transcode utils are linked to libmpeg2
[04:16] <mfisch> pitti: thanks for the talk this morning
[04:16] <mfisch> jetsaredim: I'm not familiar with that package unfortunately and it's my bedtime, did you file a bug and attach what you figured out?
[04:16] <jetsaredim> mfisch: only thing I can think of is that the configure needs both --enable-libmpeg2 AND --enable-libmpeg2convert
[04:17] <mfisch> jetsaredim: that should be easy for you to test
[04:17] <jetsaredim> mfisch: i'm in the process of re-opening an old bug for the same issue
[04:17] <mfisch> jetsaredim: do you know how to build it and install build-deps?
[04:18] <mfisch> jetsaredim: actually I can build it for you for quantal real quick
[04:18] <jetsaredim> i was hoping to not turn this system into a build box
[04:18] <jetsaredim> if you don't mind that would be awesome
[04:18] <mfisch> jetsaredim: whats the package again?
[04:18] <jetsaredim> transcode
[04:19] <mfisch> i386 or amd64?
[04:19] <jetsaredim> i think just adding a line to debian/rules to add the --enable-libmpeg2convert might do it
[04:19] <jetsaredim> i'm amd64
[04:19] <mfisch>  transcode 3:1.1.7-2build1 is what I'm seeing
[04:20] <jetsaredim> yep - that's the current 12.10 version
[04:20] <mfisch> okay, pulling build-deps
[04:21] <jetsaredim> i suppose if i'm going to play around with this stuff i should probably learn more about packaging
[04:21] <jetsaredim> been a while since i messed with any debs
[04:21] <pitti> doko_, infinity: OK, after 8 or 9 tries I give up, and make tests non-fatal on armel/hf
[04:29] <mfisch> jetsaredim: you want a binary or package?
[04:30] <mfisch> let me upload the package
[04:30] <jetsaredim> mfisch: package works
[04:39] <mfisch> jetsaredim: glad that option worked for you
[04:39] <jetsaredim> yea - now i can make my perfectly legal backups of my dvds
[04:39] <jetsaredim> :D
[05:15] <ScottK> doko_: Would you please retry ktorrent on armhf in the rebuild.  I think it will work now.
[06:24] <pitti> infinity: meh, now glib2.0 failed on armhf during compilation; shall I disable that part as well? :-)
[06:24]  * pitti just sticks fingers in ears, sings "lalala" and hits "retry"
[07:04] <dholbach> good morning
[07:04] <pitti> hey dholbach, guten Morgen
[07:04] <dholbach> hey pitti
[07:11] <earthling_> What do you guys think of the Amazon Ubuntu Search feature?  Should it be included in 12.10?
[07:11] <pitti> I think it should be in the dash search, but not in the launcher as an icon
[07:11] <pitti> sabdfl: good morning, how are you?
[07:12] <pitti> sabdfl: amazon icon in the launcher certainly stirred some "discussion"?
[07:12] <earthling_> pitti, that is reasonable
[07:12]  * pitti mubmles "billboard"
[07:12] <RAOF> My amazon icon disappeared as soon as I clicked on it.
[07:12] <RAOF> Which was odd.
[07:12] <penreturns>  yup its call unity lens shopping
[07:12] <RAOF> I wonder if the U1music icon will do the same.
[07:12] <earthling_> I'm actually still using 10.04 , works well enough for me
[07:13] <pitti> RAOF: amazon icon does the same here, u1 ms WFM
[07:13] <earthling_> I am interested in all the new changes
[07:13] <RAOF> Hm. Nope. Apparently the U1music icon doesn't do anything, though.
[07:13] <pitti> RAOF: for me it opens firefox with the u1 music page
[07:13] <pitti> (shop)
[07:14] <RAOF> Doesn't seem to want to do that here.
[07:14] <pitti> I tried it in a guest session
[07:14] <earthling_> penreturns, is there a way to turn it off?
[07:15] <penreturns> yup u can remove the package
[07:15] <pitti> my user doesn't have any of the default launchers except nautilus
[07:15] <penreturns> sudo apt-get remove unity-lens-shopping
[07:15] <RAOF> penreturns, earthling_: Or twiddle the setting in Privacy
[07:16] <RAOF> (That'll exist once didrocks' package lands after B2)
[07:17] <earthling_> I've never seen so much press about a development issue
[07:17] <earthling_> other than Unity, heh
[07:17] <RAOF> Or... what was the other one?
[07:18] <RAOF> Oh, Banshee-amazon-referral.
[07:18] <RAOF> There seems to be roughly one per release :)
[07:25] <earthling_> Shuttleworth's discussion on the Amazon Dash issue   http://www.markshuttleworth.com/archives/1182
[07:54] <sabdfl> pitti, sure, not unexpectedly
[07:55] <sabdfl> we need to do a good job of giving people privacy options, and security
[07:55] <sabdfl> but i think 12.10 will have all that
[07:55] <pitti> right, I specifically asked about the launcher icon
[07:55] <sabdfl> then the tin foil hat crowd can go somewhere else, where they will be disappointed by their new overlords i'm sure :)
[07:55] <sabdfl> pitti, oh, is there an issue with the icon?
[07:56] <pitti> sabdfl: I think the dash search is fine (modulo privacy options blabla, but we have that), I just don't particularly like the icon in the launcher which looks like an "Amazon" billboard
[07:57] <pitti> the u1 music store is still closely related to Ubuntu, but I have a feeling that adding the amazon icon there breaks a dam
[07:58] <pitti> but anyway, I guess that was discussed over and over, so perhaps I STFU to not open up old wounds again
[08:07] <sladen> pitti: I believe we ship  http://start.ubuntu.com  containing a Google logo
[08:08] <pitti> sladen: that doesn't clutter up the default desktop, though; not only do we already have too many starters by default, they now also contain non-ubuntu ads
[08:09] <jussi> Is the amazon thing in the default (super only) dash?
[08:09] <pitti> sladen: I hope we at least get some good dimes from amazon for that :)
[08:10] <Laney> there's a webapp icon in the launcher too
[08:13] <sladen> jussi: the Amazon lens, is "just" the Amazon lens---however all lens get combined sourced to the default <Super> action
[08:14] <sladen> jussi: eg. a bit like Google searching everything by default; or you can select just images, just usenet, just patents
[08:14] <jussi> aye.
[08:15] <sladen> jussi: and it seems to be this aspect that people maybe concerned about.  However, pitti's point is seemingly(?) about the icon being there in-your-face
[08:15] <sladen> pitti: ^^can you clarify?
[08:15] <pitti> sladen: yes, that and that we already abuse the launcher too much and put too many default icons there
[08:15] <jussi> you might calm the flames a bit if you introduce a bunch of others, not just amazon, and do what browsers do - a first run service selection for your dash
[08:16] <jussi> ie. when I install chrome, it asks me which search engine I want
[08:17] <seb128> pitti, oh, fighting this battle again? ;-)
[08:17] <pitti> seb128: I didn't really see the previous ones; I just raised my eyebrow when I saw the new icon yesterday
[08:17] <Laney> I clicked it once to see what would happen and then it disappeared on its own and never came back :P
[08:17] <pitti> seb128: the "overfull launcher", yes, that comes up all over again and nobody seems to care
[08:18] <Laney> pitti: design argued that the concertina effect is there for just this purpose, so it's not a problem
[08:18] <sladen> the one positive suggestion, is that below the installer MP3 tick box we have another default-ticked "enable handy online stuff [you probably want this too]"
[08:18] <sladen> (the one positive suggestion that I've heard)
[08:19] <Laney> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1054167 that's this
[08:19] <jussi> sladen: yeah, I like that suggestion
[08:29] <Laney> doko_: https://launchpad.net/~laney/+archive/webkit2/+packages
[08:40] <cjwatson> sladen: while it might work out to be a nice approach, it's punting a UIFE off onto foundations and it's a fair number of moving parts to get settled down in time for final freeze ...
[08:40] <cjwatson> so, well, if that turns out to be the answer I just hope it occurs to somebody that we need actual notice of this kind of thing and some time
[08:41] <cjwatson> this is exactly why this should have landed before FF, to allow time for consequential changes elsewhere *grump*
[08:42] <ev> mpt: what are your thoughts on including a projection line on the graph? Something akin to this http://baykeeper.org/data_viz/official-sea-level-rise-projection
[08:45] <mpt> ev, look at the Quantal graph. Imagine a projection line on that. It would be slowly accelerating upwards, hitting about 0.15 on release day.
[08:46] <ev> call me pessimistic, but that's what I expect will happen
[08:46] <mpt> heh
[08:46] <mpt> ev, we know that's not going to happen because we humans know stuff about the release process that a projection line does not.
[08:46] <ev> :) fair enough
[09:03] <cjwatson> ev: Do you have any idea why https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fsoftware-properties-gtk%3AKeyError%3A%3Cmodule%3E%3A__init__%3Ashow_drivers is showing up in 0.92.6?  That line of code was changed in 0.92.4
[09:03] <cjwatson> (and should have fixed that bug)
[09:04] <cjwatson> I could understand that versions might be out of sync if it were a daemon process or something, but I wouldn't have expected software-properties to be long-running
[09:04] <ev> cjwatson: it's still a pretty low count, so it could be the "they upgraded while the program was still running" problem
[09:04] <ev> we filter those out for crashes sent to Launchpad, but we're still working through the solution for daisy:
[09:05] <cjwatson> mm, right
[09:05] <ev> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1039220
[09:05] <cjwatson> possible I suppose
[09:05] <ev> and https://code.launchpad.net/~brian-murray/apport/no-unreportable/+merge/126082
[09:06] <mpt> ev, do you know when the next rollout will be?
[09:07] <cjwatson> ev: that bug appears to be waiting for you to follow up :-)
[09:07] <ev> mpt: of what feature? :)
[09:07] <mpt> ev, the graph mainly
[09:07] <cjwatson> (or maybe I'm misreading)
[09:07] <ev> cjwatson: I followed up in the merge proposal, but I'll note that in the bug
[09:07] <ev> mpt: I'll file and RT and ask for a rollout today
[09:07] <ev> an RT*
[09:07] <cjwatson> ok
[09:09] <mpt> ev, btw did you realize the legend has disappeared?
[09:09] <ev> mpt: I made it do so, per your mockup
[09:09] <ev> I need to implement moving it to the bottom
[09:20] <ev> mpt: since we will soon be able to show graph and table data for just packages in -proposed, I'm questioning the need for being able to filter to arbitrary versions of specific packages
[09:20] <ev> well, questioning it a bit more
[09:21] <ev> and of course we already split out release by release data
[09:21] <ev> I guess it helps because we haven't quite solved updates
[09:22] <ev> err never mind, you'd see what's important in the normal view there
[09:26] <earthling_> Off switch being made for the shopping lens   http://www.omgubuntu.co.uk/2012/09/is-an-off-switch-for-the-shopping-lens-in-the-works
[09:40] <pitti> jdstrand, infinity: how are we supposed to get lpia builds for hardy updates these days? our only buildd seems disabled
[09:48] <pitti> can I temporarily recruit an i386 or amd64 builder to build https://launchpad.net/ubuntu/+source/postgresql-8.3/8.3.21-0ubuntu8.04/+build/3857919 ?
[09:48] <cjwatson> Yeah, I think that should work - feel free to try
[09:51] <pitti> ok, trying on aatxe
[10:01] <pitti> cjwatson: nice, that seems to work; it's past the tests in the debhelper stage
[10:02] <cjwatson> oddly reassigning a PPA builder didn't seem to work
[10:02] <cjwatson> (I asked on #launchpad-ops)
[10:02]  * pitti reassigns aatxe back to i386 duty
[10:03] <cjwatson> did you have to set it to manual and back or anything like that, or did you just change the processor type?
[10:04] <pitti> cjwatson: I did set it to manual first, but more out of a habit
[10:04] <pitti> to set it back I just changed the arch (it was idle then)
[10:04] <pitti> cjwatson: you can tell a PPA builder to build ubuntu packages?
[10:05] <cjwatson> No, to ppa/lpia
[10:05] <cjwatson> I'll try manual/auto
[10:07] <pitti> cjwatson: ah; we do have a working lpia PPA builder, though
[10:07] <cjwatson> we do?  gold is disabled
[10:07] <pitti> cjwatson: so, it worked without manual in one direction
[10:07] <cjwatson> gumiho is the one I'm trying to reassign
[10:08] <pitti> aah, I see; that's the one I was seeing
[10:08] <cjwatson> it says lpia but is persistently idle
[10:08] <cjwatson> I guess I don't care that much; I'll reassign it back in a bit if it doesn't do anything
[10:08] <pitti> aatxe picked up the waiting job within seconds
[10:08] <cjwatson> yeah, I saw
[10:08] <pitti> so, no idea what's wrong here :(
[10:09]  * cjwatson is looking forward to b2 being out so that he can stress-test the new queue-accept-should-never-time-out thing
[10:10] <pitti> is there a target time when we unfreeze today?
[10:10] <cjwatson> not that I know of
[10:10] <pitti> i. e. the point of no return^H^H^H^Hspin
[10:12] <pitti> that reminds me, christmas wish #23: a queue tool option to accept a "quantal" upload into "quantal-proposed" instead, so that stuff can already build and get autopkgtest-ed
[10:12] <cjwatson> once we have britney operational we'll just redirect everything from devel to devel-proposed
[10:12] <pitti> but that'll soon fix itself anyway when all uploads get built in -proposed
[10:13] <pitti> right :)
[10:13] <pitti> https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/ tests -proposed now
[10:13]  * cjwatson wonders how hard changing the suite in the queue would actually be
[10:14] <cjwatson> It *might* just be a matter of making PackageUpload.pocket (and PU.distroseries?) writable
[10:14] <cjwatson> tests would be an absolute git to write though
[10:15] <pitti> probably not worth the effort; it just came to my mind again
[10:36] <Laney> doko_: do you plan to do any build log analysis / bug filing from the rebuild test?
[12:10] <MohamedAlaa98> Hello, please help me, I want to update a package to new version for quantal, can I do this or that is incompatible with feature freeze?
[12:25] <tumbleweed> MohamedAlaa98: there needs to be a good reason for it, and it should be thoroughly tested, etc.
[12:27] <MohamedAlaa98> thumbleweed: please explain it for me, what do you mean by "a good reason"?
[12:28] <MohamedAlaa98> tumbleweed: *
[12:28] <tumbleweed> MohamedAlaa98: it needs to be worth the risk
[12:29] <l3on> Hi.. do you think it's still possibile add youtube-dl 2012-09-27 in quantal?
[12:30] <tumbleweed> l3on: any particular reason?
[12:30] <MohamedAlaa98> tumbleweed: okay thanks :D
[12:30] <l3on> tumbleweed, first reason I found: there's a bug downloading playlist .. something in youtube has changed in last months
[12:31] <tumbleweed> l3on: sounds good. file an ffe
[12:31] <l3on> tumbleweed, great!.
[12:32] <jdstrand> pitti, cjwatson: so afaik, you need to do what you did. I don't have the perms to do it, so I don't know the exact steps
[12:34] <cjwatson> jdstrand: yeah, it's all right, sorted now
[12:34] <jdstrand> didrocks: hi! do you know if there is a bug already for 'ctrl+lt+t' not opening a terminal. if not, what package should that be filed against?
[12:34] <jdstrand> didrocks: google is not helping me... :\
[12:35] <didrocks> jdstrand: yeah, it's because of duplicated keys on compiz and g-s-d
[12:35] <didrocks> jdstrand: there is a fix coming with next compiz
[12:35] <didrocks> jdstrand: but you can workaround it for now
[12:35] <didrocks> open gnome-control-center -> keyboards -> keybindings
[12:35] <didrocks> section Launcher
[12:35] <didrocks> IIRC, "Launch a terminal" is the one which is bound to the actual compiz code, ensure it's set to ctrl + alt + t
[12:35] <didrocks> "Launch a Terminal" should be unset
[12:36] <didrocks> jdstrand: once the next compiz will be here, be aware that "Launch a terminal" will disappear and you will have to set "Launch a Terminal" then to ctrl + alt + t (as you would have unset it)
[12:36] <jdstrand> didrocks: thanks! after the compiz update, will I have to set that back?
[12:36] <jdstrand> oh, heh
[12:36] <jdstrand> cool
[12:37] <jdstrand> didrocks: thanks again, this was mildly annoying :)
[12:37] <didrocks> jdstrand: sorry for the trouble :)
[12:37] <jdstrand> didrocks: not a big deal, I just wanted to make sure it was filed/fixed
[12:38] <Kano> hi cjwatson
[12:38] <didrocks> jdstrand: it's a typical case where 2 > 1 isn't a real advantage :)
[12:39] <jdstrand> :)
[12:40] <Kano> cjwatson: when grub-pc is installed + grub-efi-amd64-bin then grub is installed only for efi but with config for mbr
[12:40] <Kano> cjohnston: thats wrong, tested with debian exp -7
[12:42] <Kano> cjohnston: you definitely have to modify grub-install
[12:45] <Kano> err cjwatson always ;), the efivars check is not optimal alone, when you use a different bootloader like gummiboot or direct uefi boot but you want to use grub for selection of other legacy systems like win
[12:48] <l3on> tumbleweed, these are changes in youtube-dl.. what you think about it? is it better apply only patch rather than bump a new version of package ?
[12:51] <l3on> tumbleweed, sorry - these are the changes -> http://paste.ubuntu.com/1230335/ ^
[12:53] <doko> Laney, the analysis for main and package sets was done. asked amoog for filing the universe bug reports. however the universe rebuild will take time until after the weekend
[12:54] <doko> didrocks, seb128: ping about the gnome/gtk header include fixes ...
[12:54] <seb128> doko, what about those?
[12:54] <doko> see backlog
[12:54] <doko> didrocks, seb128: is there an easy work around for #warning "Including <librsvg/rsvg-cairo.h> directly is deprecated." ?
[12:54] <seb128> don't include it directly?
[12:55] <doko> there are a lot of these in universe
[12:55] <doko> seb128, please fix
[12:55] <seb128> what? universe buggy apps?
[12:55] <seb128> sorry I've enough work on the default installation issue and that's higher priority than universe random packages
[12:55] <doko> darktable, gstreamermm, subtitleeditor are those in package sets
[12:56] <seb128> well, whoever is owning one of those set can look at them I guess
[12:56] <geser> darktable is already fixed (waiting in queue)
[12:57] <geser> I'm trying to through the rebuild results and fix them when I see them
[12:57] <seb128> geser, thanks
[12:57] <doko> honestly such changes should told once new gtk/gnome changes get uploaded
[12:57] <doko> be told
[12:58] <seb128> it's hard to know what has an impact or not, they did similar change to lot of libs over time, I don't want to spam lists with every change GNOME does to its libs
[12:59] <doko> yeah, so better leave it to other to detect and fix
[13:00] <seb128> it's not like you were emailing the list about every single toolchain change either...
[13:00] <seb128> see the stl abi issue that didrocks has to track down earlier in the cycle
[13:05] <Kano> cjwatson: next bug: get rid of -w for efibootmgr, it just overwrote my hd uuid, that means my win install does not boot (mbr), my hd is mbr with efi as primary partition. -w kills win
[13:08] <doko> seb128, bullshit. the known toolchain changes were announced, with hints how to fix. the abi issue was not known
[13:08] <seb128> doko, the include issue was not known either
[13:08] <doko> you call yourself a tech "lead", so please be proactive
[13:08] <seb128> doko, I didn't call myself that
[13:09] <doko> seb128, I doubt it, it did pop up for precise as well, and afairc it was reverted
[13:09] <seb128> doko, that was in glib
[13:09] <seb128> no librsvg
[13:09] <seb128> which has another scale and was handled properly
[13:09] <doko> right, see subtitleeditor
[13:09] <doko> and gstreamermm
[13:09] <seb128> right, you come with like 5 rdepends
[13:09] <seb128> can't we just fix them and move on?
[13:10] <seb128> it doesn't seem worth the discussion
[13:11] <doko> no, I can't fix hundreds
[13:12] <seb128> is it really hundreds?
[13:12] <seb128> we should probably revert the librsvg change if that's the case
[13:13] <doko> start with glib if you really do care
[13:13] <seb128> $ grep-available -s Package -F Build-Depends librsvg2-dev /var/lib/apt/lists/*quantal*Sources | sort | wc -l
[13:13] <seb128> 67
[13:14] <seb128> I don't see how it can be "hundreds"
[13:14] <seb128> when there is less than 100 sources using librsvg
[13:14] <seb128> what about glib?
[13:15] <doko> there are hundreds of build failures. if you address those which you introduce with new upstream versions yourself, ... it would help a lot
[13:15] <doko> again see subtitleeditor and gestreamermm
[13:15] <seb128> I've no time for universe sorry
[13:16] <seb128> I can file bugs asking those to be removed from quantal if that helps
[13:17] <doko> being productive today?
[13:17] <seb128> I was until you started that IRC discussion
[13:17] <seb128> I'm sorry but it's just not realistic to expect me or whoever upload glib and gtk to be responsive for ever years old unmaintained universe source
[13:18] <seb128> I'm happy to get those dropped from the archive if nobody has time,motiviation to fix them though
[13:18] <seb128> that's the best I can offer you today
[13:19] <seb128> that said, going back to what I was working on
[13:39] <smoser> slangasek, wonder if you have a thoughts
[13:40] <smoser> if an interface is brought up in the kernel (ipconfig)
[13:40] <smoser> then when network-device-added comes through, it is 'ifup' will fail, and not call the upstart hooks for ifup
[13:41] <smoser> so static-networking wont fire. even though it already is set.
[13:42] <smoser> open-iscsi has some "helper" stuff to get this fired for the device that its iscsi root is on. but i'm wondering if there should be a more general solution.
[13:46] <geser> seb128, doko: a fixed gstreamermm and subtitleeditor are waiting in the queue
[13:46] <seb128> geser, thanks a lot
[13:47] <stgraber> smoser: that sounds like bug 1010439
[13:47] <stgraber> smoser: any such interface really ought to be marked as "inet manual" though, that way ifupdown should do the right thing
[13:47] <smoser> stgraber, yes, yes it does.
[13:48] <seb128> dpm, hey
[13:48] <seb128> dpm, do you know why https://translations.launchpad.net/ubuntu/quantal/+source/unity-lens-shopping/ is empty ?
[13:48] <smoser> stgraber, the issue with 'inet manual' is that it wont apply to static-networking
[13:48] <smoser> when imo, it should
[13:49] <smoser> (ie, if that nic is up from the kernel, and its the only one in /etc/network/interfaces as 'auto', then static-networking should fire)
[13:49] <dpm> seb128, hm, it seems there hasn't been any .pot file imported, I was wondering about this the other day, but at that point there wasn't a source package uploaded yet. Maybe the uploaded package didn't create a .pot file? https://translations.launchpad.net/ubuntu/quantal/+source/unity-lens-shopping/+imports
[13:50] <seb128> dpm, the build log https://launchpadlibrarian.net/116724481/buildlog_ubuntu-quantal-i386.unity-lens-shopping_6.0.0-0ubuntu1_BUILDING.txt.gz has
[13:50] <seb128> "Running xgettext --add-comments --directory=. --default-domain=unity-lens-shopping --flag=g_strdup_printf:1:c-format --flag=g_string_printf:2:c-format --flag=g_string_append_printf:2:c-format --flag=g_error_new:3:c-format --flag=g_set_error:4:c-format --flag=g_markup_printf_escaped:1:c-format --flag=g_log:3:c-format --flag=g_print:1:c-format --flag=g_printerr:1:c-format --flag=g_printf:1:c-format --flag=g_fprintf:2:c-format --flag=g_sprintf:2:
[13:50] <seb128> c-format --flag=g_snprintf:3:c-format --flag=g_scanner_error:2:c-format --flag=g_scanner_warn:2:c-format --output=unity-lens-shopping.pot --files-from=./POTFILES.in.temp --keyword=_ --keyword=N_ --keyword=C_:1c,2 --keyword=NC_:1c,2 --keyword=Q_ --keyword=g_dgettext:2 --keyword=g_dngettext:2,3 --keyword=g_dpgettext:2 --keyword=g_dpgettext2=2c,3 --from-code=UTF-8
[13:50] <seb128> Removing generated header (.h) files...done.
[13:50] <seb128> Wrote unity-lens-shopping.pot"
[13:50] <seb128> ups
[13:50] <seb128> sorry, didn't realize the xgettext line was a long one
[13:50] <dpm> seb128, I see it was in universe and then went to main. Could that have affected it?
[13:51] <seb128> dpm, it could I guess
[13:51]  * dpm builds package locally to see what translations look like
[13:51] <stgraber> smoser: hmm, my understanding is that if you configure network from the initramfs and have the interface marked as "inet manual", then when network-device-added is received, the ifup <interface> will succeed and statis-network-up will be emitted (assuming it's the only interface)
[13:51] <seb128> didrocks, ^ do you plan an upload soon for unity-lens-shopping?
[13:51] <didrocks> seb128: there is one start of next week
[13:52] <didrocks> I can make a dummy upload if needed
[13:52] <didrocks> to have it rebuilt
[13:52] <seb128> didrocks, see other channel
[13:52] <stgraber> smoser: anyway, an alternative would be for the initramfs script to do: "mkdir -p /run/network/ && touch /run/network/ifup.$INTERFACE"
[13:53] <seb128> didrocks, ignore that ... do you want me to do the dummy upload?
[13:53] <stgraber> smoser: oh, and you'd also likely want "echo $INTERFACE=$INTERFACE > /run/network/ifstate" so that ifupdown doesn't try to bring it up again
[13:53] <didrocks> seb128: fine with me :)
[13:53] <seb128> didrocks, ok, doing it
[13:54] <stgraber> but that sounds like a hack to me, having the interface configured as inet manual should do the trick...
[13:54] <didrocks> seb128: the packaging branch in lp:ubuntu/unity-lens-shopping :)
[13:54] <seb128> didrocks, thanks
[13:54] <didrocks> thanks to you :
[13:54] <didrocks> :)
[13:54] <dpm> seb128, hm, I can't seem to be able to build the local package, I'll leave it to you guys and the new upload
[13:54] <smoser> stgraber, i'll see if manual works.
[13:55] <smoser> you think it will get bounced?
[13:55] <seb128> dpm, sure
[13:56] <smoser> stgraber, i think you're right. manual should work.
[13:56] <stgraber> smoser: with manual, the interface shouldn't be touched but the if-up scripts should be run, which is what I think we want
[13:56] <seb128> dpm, thanks
[13:56] <stgraber> IIRC that's what I implemented in casper for netboot installs and what we have in LTSP, so if that doesn't work, we need to figure out why and fix it :)
[13:56] <smoser> stgraber, shoot. the one other thing is that i want resolvconfhooks to fire.
[13:56] <smoser> they will, right?
[13:56] <stgraber> yep
[13:57] <stgraber> they are if-up hooks, so they should still be called
[13:58] <smoser> stgraber, http://bazaar.launchpad.net/~cloud-initramfs-tools/cloud-initramfs-tools/trunk/view/head:/dyn-netconf/scripts/init-bottom/cloud-initramfs-dyn-netconf
[13:58] <smoser> that is what i'm working on.
[13:58] <smoser> i'll just write manual instead of auto on line 68 then.
[13:58] <smoser> and hopefully magic will occur
[13:59] <smoser> (basically, this writes a /etc/network/interfaces style file in /run/network/dynamic-interfaces. the filesystem that i'm using will have /etc/network/interfaces as a symlink to ../../run/network/dynamic-interfaces)
[14:00] <stgraber> do you actually need networking later on in the initramfs?
[14:00] <smoser> later on?
[14:00] <stgraber> otherwise you could flush all IPs from the devices and let ifupdown do the work
[14:00] <smoser> well, for this, its iscsi-root
[14:00] <smoser> so yes
[14:00] <stgraber> right :)
[14:00] <smoser> but i think in general leave it
[14:01]  * ogra_ wonder why we still dont have a generic networking function in the initramfs functions we could just source
[14:01] <ogra_> *wonders
[14:02] <ogra_> casper uses it, nfs, ltsp and iscsi ... and there are likely more
[14:02] <stgraber> iscsi-root will need "inet manual", if not booting from iscsi you can probably do an "ip addr flush" at the end of your script and stick with "inet static"
[14:03] <stgraber> ogra_: yeah, extending the networking function a bit would be nice, though so far I haven't seen two identical use cases for it ;)
[14:03] <stgraber> ogra_: for example, LTSP doesn't use ipconfig, it uses udhcp with a separate hook that overrides ipconfig :)
[14:03] <ogra_> stgraber, well, all of then do the same thing somehow
[14:04] <ogra_> (make you end up with properly configured network)
[14:04] <ogra_> its just a matter of making the function generic enough so i can be used in all contexts
[14:05]  * ogra_ thinks that would probably make a good UDS topic, though it might clash with event nased initranfs which will require rewriting these bits anyway
[14:05] <ogra_> *based
[14:12] <Laney> doko: Actually my question about filing bugs was related to that
[14:13] <Laney> if you have the facility to detect patterns like those #errors from including the wrong headers directly and can, say, tag the bug reports as such
[14:13] <Laney> then it might be a good thing to do and get some fixed as part of dholbach's bug fixing initiatives
[14:16] <dholbach> yeehaw
[14:25] <doko> Laney, svammel could certainly extended for that
[14:26] <tumbleweed> if geser hasn't fixed them all first
[14:27] <geser> I only fixed 10 so far
[14:28] <tumbleweed> don't stop now
[14:28] <debfx> doko: what's the result of the qt build with -gstabs? did it change anything?
[14:30] <slangasek> smoser, stgraber: seems hard to generalize from this; I can see cases when you might do ipconfig but subsequently want to reconfigure the interface with ifupdown post-initramfs
[14:30] <smoser> slangasek, i think in that case you should bring the interface down in initramfs.
[14:30] <smoser> (or perhaps even on network-device-added)
[14:30] <slangasek> hmm, perhaps
[14:32] <stgraber> yeah, my recommendation would really be to flush all addresses after ipconfig has run if you're using static config and don't need networking for your rootfs
[14:35] <doko> debfx, Laney tried. I think it didn't help
[14:35] <Laney> doko: actually it did
[14:36] <Laney> in PPA, but not locally for some reason
[14:36] <Laney> https://launchpad.net/~laney/+archive/webkit2/+packages
[14:44] <Laney> s/2// has the almost final build I'm testing ATM
[14:48] <micahg> cjwatson: are deb-src lines sufficient for the test on Bug #1053896 ?
[14:48] <cjwatson> micahg: I'd like to test with deb lines as well
[14:49] <cjwatson> micahg: I'll do it in a chroot now
[14:49] <cjwatson> easy enough
[14:49] <micahg> ok
[14:49] <cjwatson> sbuild chroots> best thing ever for this kind of thing
[14:49] <micahg> yep
[14:49]  * micahg just noticed the warning on apt-get update this morning due to the deb-src lines
[14:49] <cjwatson> I seriously used to copy chroots around.
[15:16] <cjwatson> micahg: v-done now
[15:16] <Kano> cjwatson: did you see my query
[15:19] <brendand> can anyone recommend a good strategy for managing debian/changelog so that conflicts aren't so frequent?
[15:20] <Laney> brendand: Tell your VCS to merge them using dpkg-mergechangelogs
[15:21] <brendand> Laney, aha. i notice some projects like unity don't keep changelog with the source - what's that about?
[15:22] <Laney> Keeping packaging and development separate is quite usual, is that what you're talking about?
[15:22] <brendand> Laney, yeah
[15:23] <brendand> Laney, how is it usually gone about?
[15:24] <xnox> brendand: separate branch... one just upstream the other one just debian/ folder added.
[15:26] <brendand> Laney, xnox - i was also curious about policy around trivial changes. what if i have just added some tests for code written a long time ago. should i always have a changelog entry for that, or is there some rule of thumb?
[15:27] <xnox> brendand: two changelogs: one upstream the other one debian/changelog.
[15:27] <xnox> for native packages both collapse into debian/changelog
[15:27] <Laney> also a NEWS file listing important changes is common
[15:27] <Laney> whereas ChangeLog contains all of them
[15:27] <Laney> I often copy from NEWS into the debian changelog
[15:28] <cjwatson> brendand: You certainly don't need to list everything in debian/changelog
[15:28]  * ogra_ also likes if upstreams have TODO 
[15:28] <cjwatson> brendand: It's at the packager's discretion what to list
[15:28] <ogra_> so you know about known issues
[15:29] <cjwatson> brendand: Personally, I generally list (a) upstream changes that have some kind of major user-visible impact or compatibility issues or whatever (b) anything that's known to fix distro bugs
[15:29] <cjwatson> But there are varying opinions
[15:32] <Laney> what's a pink background on the error tracker?
[15:34] <cjwatson> Laney: "regression" - i.e. supposed to be fixed but shows up in >= the fixed version.  (in practice this is often because the program hasn't been restarted since the upgrade.)
[15:41] <cjwatson> Daviey,smoser: bug 901600 - once that's fix released, quantal cloud images should be able to apply overrides in /etc/default/grub.d/*.cfg.  Do you want to try to do that for 12.10?
[15:41] <cjwatson> I've milestoned that for 12.04.2 as well
[15:42] <smoser> YES!
[15:42] <smoser> utlemming, ^
[15:42] <cjwatson> Thought you might
[15:43] <utlemming> very nice
[15:49] <barry> zul: still looking at bug 1056820 or should i take a look at it?
[15:49] <zul> barry: no still looking
[15:50] <barry> zul: okay, i'll work on something else.  cheers.
[15:55] <infinity> pitti: Not sure if anyone answered, but when I notice a build in the lpia queue, I just flip an i386 buildd to lpia, let it pick up the build, then flip it back.
[15:58] <didrocks> scott-work: hey, FYI, bug #1054746 changed its intent. Jono's blog post reflect the latest design change (I've update the bug 10 hours ago to reflect it as well, when I was telling jono about the change)
[15:59] <cjwatson> infinity: Yep, that's what he did
[15:59] <ScottK> didrocks: Wrong Scott
[15:59] <didrocks> ScottK: misleading :)
[16:00] <ScottK> didrocks: Could you update it with the new screen shot too.
[16:01] <didrocks> ScottK: oh sure, I've given it to the translation team, but I can reupload it (again and again ;)) on the bug, one sec.
[16:01] <mpt> ev, https://wiki.ubuntu.com/ErrorTracker#errors.ubuntu.com
[16:02] <ScottK> That FFe is not, AFAICT, approved.  Once it gets the correct final, final screen shot in the bug, I'll approve it.
[16:02] <didrocks> ScottK: updated, we talked about it this morning with Laney, I thought it was enough
[16:03] <didrocks> (changed the description to point to latest screenshot)
[16:03] <ScottK> It was clear that one was going to get approved at some point.  It just need the approval in the bug.
[16:03] <ev> mpt: excellent, thanks!
[16:03]  * mpt wtfs at the switch
[16:03] <utlemming> cjwatson: do you know what would cause a grub2 error of "couldn't find a suitable memory target"?
[16:04] <utlemming> cjwatson: is that an error while loading the kernel or grub itself? I can't find much on that particular error.
[16:04] <cjwatson> You mean "couldn't find suitable memory target"?
[16:04] <cjwatson> ./grub-core/lib/relocator.c:1420:      return grub_error (GRUB_ERR_BAD_OS, "couldn't find suitable memory target");
[16:04] <utlemming> yup, that would be the one
[16:04] <utlemming> we're seeing this on a Windows Server 2012 install
[16:05] <cjwatson> That appears to be an internal GRUB error indicating that it has failed to allocate memory to load the kernel into
[16:05] <cjwatson> Probably best to bring it upstream if you're seeing this on 2.00
[16:06] <utlemming> cjwatson: what information do we need to bring that upstream? This is being seen on 12.10 B-2.
[16:07] <cjwatson> utlemming: not sure, output from 'set debug=all' might help but hard to be certain
[16:08] <cjwatson> this is a bit of a weak spot of mine
[16:08] <cjwatson> you could ask on #grub
[16:08] <ScottK> didrocks: Marked it approved, but I'm out of time to set all the tasks to triaged and set the milestone to 12.10.  Would you please do that or find someone who will.  I need to run off and get some $work done.
[16:08] <utlemming> sure....going the...thank you kindly for the direction :)
[16:10] <didrocks> ScottK: no worry, I'll do that :)
[16:11] <ScottK> Thanks.
[16:11] <didrocks> ScottK: maybe not this evening (launchpad is timing out a lot), but I'll do it
[16:11] <didrocks> ScottK: thanks :)
[16:11] <ScottK> OK.
[16:32] <ev> if I'm moving a file from one binary package to another, both produced by the same source package, do I need to do breaks and replaces? I'm pretty sure I don't, but best to ask these things :)
[16:32] <cjwatson> Yes, you do
[16:32] <ev> oh, good thing I asked
[16:32] <ev> cheers cjwatson
[16:32] <cjwatson> np
[16:33] <cjwatson> dpkg at runtime doesn't distinguish between binaries from the same source package and ones that aren't
[16:44] <ev> cjwatson: if you have a moment - does this look reasonable? http://paste.ubuntu.com/1230715/
[16:45] <cjwatson> ev: you only needs Breaks/Replaces from the new location to the old, not vice versa
[16:46] <cjwatson> ev: and as a matter of style I usually use (<< first-version-with-new-location) rather than (<= last-version-with-old-location), just in case people have +ppa1 versions or whatever
[16:48] <ev> cjwatson: so http://paste.ubuntu.com/1230725/
[16:49] <cjwatson> ev: s/0ubuntu3/0ubuntu4/ there.  Otherwise LGTM
[16:49] <ev> whoops!
[16:49] <ev> sorry, blasted through that
[16:49] <ev> thank you muchly
[16:49] <cjwatson> easy to go cross-eyed with versions
[16:50] <ev> :)
[17:16] <dpb___> pitti: Hi, ahasenack and I hit an unusual problem.  When upgrading lucid -> precise, postgres 8.4 doesn't work after the upgrade.  Only after a (another) service restart, or a system boot.  This makes any package upgrade after that does anything with a postgres database fail.  Known issue?  Is there a way to workaround?
[17:16] <ahasenack> dpb___: nice nick ;)
[17:16] <ahasenack> dpb___: paste the error in pastebin
[17:17] <dpb___> ahasenack: ya, good plan
[17:18] <dpb___> pitti: http://pastebin.ubuntu.com/1230779/
[18:31] <tjaalton> if you're seeing bug 966744, check the ppa and ping me here if it works/still breaks on quantal
[18:33] <stgraber> tjaalton: cool. Installed here, will see if that helps next time I logout
[18:33] <tjaalton> stgraber: thanks
[20:30] <jdstrand> barry: hi! is there an easy way to run a specific test for python? eg, let's assume I ran 'fakeroot debian/rules patch ; ./configure && make'
[20:31] <jdstrand> barry: so I am now prepared to run 'make TESTOPTS="-j 50" testall', but instead of testall, I just want to run test_urllib2. how do I do that?
[20:31] <barry> jdstrand: just run ./python Lib/tests/test_urllib2.py should do it
[20:32] <jdstrand> oh, well, sheesh
[20:32] <barry> :)
[20:33] <jdstrand> barry: yeah, that works great. thanks! :)
[20:33] <barry> jdstrand: np!
[21:24] <barry> slangasek, doko: re: bug 1056820.  to fix the ftbfs, i did two things: merge from sid version 5.1.2, then remove some build-deps we added previously (python-chardet, python-libxml2, and python-utidylib).  those three cause the test suite to fail, and note that we had *already* disabled those for py3, so now our py2 build env matches.  upgrading to 5.1.2 allows us to drop two patches (including the CVE) which have been applied upstream
[21:24] <barry> as of 5.1.2.  now the question is, how do we feel about doing that upgrade, and do we need an FFe?  it's a point release (we have 5.1 in quantal now) with what look like only bug fixes from the NEWS file.  of course, rdeps could be working around those problems.
[21:30] <slangasek> barry: hmm,
[21:31] <slangasek> barry: hmm, let's see if I understand correctly - does this mean we're going from having testing of one version of the bindings, to having testing of no versions of the bindings?
[21:31] <slangasek> barry: as for the FFe question: provided that you're satisfied that the point release is bugfix-only, there shouldn't be any need for an FFe
[21:32] <barry> slangasek: no.  we test both versions of the bindings, and still do.  it's just that chardet and friends totally f*cks up the tests.  it just that we realized this with py3 months ago and now realize it w/py2
[21:33] <barry> slangasek: upstream confirmed that for py3, chardet is generally not useful for feedparser any more.  my assumption is that this has led them to basically obsoleting it for py2 as well
[21:33] <slangasek> ah, k
[21:35] <barry> slangasek: yeah, i think the point release is essentially bugfix-only, from my reading of the NEWS entries.  i'll go ahead and upload it
[21:35] <slangasek> sounds good!
[21:36] <zyga> pitti: there won't be any udisks in checkbox next week! :)
[21:54] <doko> xnox, please don't disable the tests in git, I'm working with jonathan nieder on a backport
[21:54] <doko> barry, in libxml2 2.9, it's the udeb which ftbfs
[21:55] <xnox> doko: feel free to reject it from the queue, if it didn't land yet. Or superseed it.
[21:56] <xnox> doko: please open a FFe though. it's two major releases jump.
[21:57] <xnox> doko: or are you cherry picking?
[21:57] <xnox> doko: what's best course of action for resolving bug 1048036 which is result of my merge as per bug 763457
[21:58] <xnox> I did ping tseliot about it early in the cycle..... but it's still open.
[21:58] <doko> xnox, backport, not new upstream
[22:00] <xnox> doko: ok. (In my mind backport is stuff that lands in backports pocket aka new upstream releases and stuff. I guess cherry-picking is a trendy term of the decade)
[22:01] <ScottK> doko: Would you please retry kbruch on armhf in the test rebuild.  A local build worked.
[22:02] <barry> doko: i'm going to unlink libxml2 from bug 1056820.  i don't need to upgrade that to fix the ftbfs for feedparser
[22:02] <ScottK> doko: Looks like ktorrent on armhf is still waiting for a retry too.
[22:08] <doko> ScottK, done
[22:08] <ScottK> doko: Thanks.
[22:09] <ScottK> Once the queue is flushed, all the Kubuntu ones that can be fixed (with the exception of Qt and I believe that's in progress) will be done.
[22:11] <SpamapS> smb`: any luck on the network namespace issue in quantal's kernel?
[22:11] <SpamapS> [65599.932030] unregister_netdevice: waiting for lo to become free. Usage count = 1
[22:11] <SpamapS> smb`: pretty much can't use lxc on any quantal machine
[22:34] <xnox> USN-1586-1 is funny: "arbitrary Lisp code execution"
[22:34]  * xnox goes to check if it affects emacs24
[23:49] <slangasek> robert_ancell: the glibmm2.4 in the quantal queue appears to introduce new interfaces, but does not bump the shlibs dependency, which means partial upgrades are broken for anything that depends on the new interfaces
[23:51] <robert_ancell> slangasek, ah, ok. I should set SHVER in debian/rules to 2.32.0 right?
[23:51] <robert_ancell> 2.33.13 rather