[02:18] <RAOF> Gah! The Unity SRU appears to _pointlessly_ replace a large batch of boost::* with std::*
[02:19] <RAOF> Mmm. if (progress == 1.0f). What could possibly go wrong!
[07:38] <stgraber> hmm, why am I getting "Raring-changes subscription notification" e-mails? Looking at mailman skaet is supposed to be the list owner so I'm not sure how I ended up on raring-changes-owner
[08:17] <cjwatson> doko: Please don't manually copy from raring-proposed to raring, no.  (I'll run britney once I'm properly awake and at a real computer.)
[08:17] <cjwatson> It'll be cronned once I trust it.
[08:18] <doko> I didn't, therefore my question
[10:48] <psivaa> cjwatson: We are hitting bug 1068178 every now and then on our daily precise encrypted-home preseeded installation tests. Would be helpful if you could have a look
[10:48] <ubot2> Launchpad bug 1068178 in ubiquity (Ubuntu) "ubuntu ubiquity: cannot stat `/target/etc/fstab' error on preseeded - encrypted-home installations on precise" [Undecided,New] https://launchpad.net/bugs/1068178
[10:50] <cjwatson> psivaa: Needs to be somebody else this week
[10:50] <cjwatson> xnox: ^- can you look at that?
[10:50]  * xnox looking
[10:51] <psivaa> cjwatson: xnox: ok thank you
[10:52] <cjwatson> though rings a faint bell - xnox, you might find that was fixed somewhere post-precise
[10:52] <xnox> cjwatson: thanks.
[11:13] <doko> xnox, do you have a list of outstanding "python (<< 3.3)" packages?
[11:14] <xnox> doko: yeah. but all of them either "pretend" to build for all, yet really want to build against default only or FTBFS
[11:14] <xnox> (as in with py2.7 & 3.2 & 3.3 and known)
[11:15] <xnox> I have one more to upload and then I'll start rebuilding with with 3.3 set to default in a ppa.
[11:15] <xnox> doko: let me push you the list.
[11:17] <doko> xnox, could you file bug reports with the python3.3 keyword in debian for the pretending ones?
[11:18] <xnox> doko: ack.
[11:18] <xnox> doko: http://people.canonical.com/~xnox/py3.2/python3.2.html
[11:18] <xnox> filter on bad only.
[11:19] <xnox> I can upload pyopencl. shiboken ftbfs with reverse-dep pyside.
[13:04] <stgraber> can someone kick the older lxc from precise-proposed? it contains missing "fi" statements for the devtmpfs handling causing a parse error
[13:04] <stgraber> hallyn uploaded a fixed version (that new queuebot listed a couple of minutes ago)
[13:12] <cjwatson> stgraber: done
[13:12] <stgraber> cjwatson: thanks
[13:59] <skaet> stgraber,   Sorry about the communication glitch.  I went in and added you, infinity, cjwatson to the moderator set for the raring-changes list yesterday.
[14:00] <cjwatson> FWIW the list of moderators in the mailman admin UI is basically just informational
[14:00] <cjwatson> The true set of moderators is just people who have the moderator password
[14:01] <infinity> Well, the list of mods or admins are the people who get nag mails.
[14:01] <infinity> But yes, the two passwords are the bit that matters.
[14:02] <Laney> not that -changes should require any moderation
[14:02] <cjwatson> No, well, in this case it did until today
[14:02] <cjwatson> But that's fixed now
[14:03] <Laney> it /did/ but it /should not/ have :-)
[14:04] <infinity> Laney: Absolutely, it shouldn't have.  But it did, regardless.
[14:09] <stgraber> yay, IPv6 is back online, restarting queuebot :)
[14:15] <ev> would someone kindly let whoopsie 0.2.6 and apport 2.6.1-0ubuntu6 through?
[14:43] <smartboyhw> skaet, just a reconfirm: When is the blueprint deadline for R cycle?
[14:44] <skaet> smartboyhw,  blueprints should be registered and accepted prior to the start of UDS if they need to be discussed there.   Otherwise, blueprints are accepted until planning freeze.
[14:45] <skaet> oops... s/planning freeze/feature definition freeze/
[14:45] <smartboyhw> thx skaet
[14:46] <skaet> yw
[14:47] <knome> skaet, btw, where can i see a list of the track leads?
[14:47] <knome> skaet, and is desktop now the track where flavors should go? (i saw some lubuntu sessions on community)
[14:49] <skaet> knome,  http://summit.ubuntu.com/uds-r/tracks <-- has the track leads
[14:49] <knome> skaet, sweet. i don't recall seeing that page before
[14:50] <skaet> and I recommend using the "community" track for the flavor work in general,  although depending on the topic, other tracks may be applicable in order to make sure the right audience knows to attend.
[14:52] <knome> skaet, ok, thanks :)
[14:52] <skaet> :)
[14:53] <knome> bbl
[15:20] <gema> xnox: ping
[15:20] <xnox> gema: yes?!
[15:21] <gema> xnox: the btrfs bp, I think you should own it
[15:21] <gema> :D
[15:21] <xnox> gema: ack.
[15:21] <gema> xnox: I created it because bjf suggested we need to do something about that
[15:21] <gema> and we do
[15:21] <xnox> gema: not sure how much time I will have for it. But sure =)
[15:21] <gema> but I think QA should be a participant, not the driver
[15:21]  * xnox nods
[15:21] <gema> xnox: if not you, someone in your team
[15:21] <gema> I don't mean to burden you with it x)
[15:22] <gema> xnox: we'll run the tests, sure, but we'll need advice and help on how to set up , etc
[15:22] <gema> that only you guys can provide
[15:22] <gema> xnox: so who is your approver?
[15:23] <xnox> gema: slangasek will need to double check for it =)
[15:23] <gema> ok, let me know
[15:23] <gema> I won't change it until you let me know
[15:23] <slangasek> gema: what blueprint is this?
[15:23] <slangasek> (full title?)
[15:23] <gema> slangasek: https://blueprints.launchpad.net/ubuntu/+spec/qa-r-btrfs-automated-testing
[15:24] <gema> slangasek: Adding automated test cases for btrfs
[15:24] <slangasek> btrfs is not a priority for us in 13.04
[15:24] <slangasek> so if that's really only about the btrfs filesystem... not gonna happen
[15:25] <gema> slangasek: ack, then I will have that BP removed and we will touch on the subject in one of our ones for adding coverage
[15:25] <xnox> ack.
[15:25] <gema> slangasek: because we likely won't have the time either, but I don't want to forget about it
[15:25] <xnox> gema: decline from uds-r, but keep it for reference and keep it as new/unapproved or something like that.
[15:25] <gema> xnox: ok, let me see if I can do that
[15:25] <xnox> gema: yeah =) keep as reference if someone else wants to do it =)
[15:26] <slangasek> declined for uds-r
[15:26] <gema> ok, thanks slangasek and xnox !
[15:28] <ScottK> doko, cjwatson, etc: I need that sip4 upload to build before I can upload python-qt4 (and I think I have that about fixed).
[15:28] <ScottK> (please accept)
[15:29] <doko> ScottK, done
[15:29] <ScottK> Thanks.
[15:57] <knome> is there a specified uds twitter hashtag?
[15:59] <cjwatson> https://uds.ubuntu.com/community/remote-participation/ just says #ubuntu
[16:00] <cjwatson> (not really an #ubuntu-release thing though ...)
[16:00] <knome> hmph. i was thinking whether one should use #uds or #uds-r
[16:01] <knome> but maybe #uds... #ubuntu seems a bit too generic, don't you think?
[16:03] <cjwatson> Not the kind of thing I care much about, and not a release management thing, as I said :-)
[16:03] <knome> hehe, sure
[16:03] <knome> just asking around O:)
[16:03] <knome> cheers
[16:04] <stgraber> can someone please reject the lxc in precise-proposed? we just noticed that the devtmpfs magic is a very bad idea. hallyn will be pushing an SRU to quantal to revert it there too
[16:05] <infinity> stgraber: Sure.
[16:07] <infinity> stgraber: How very bad an idea was it?
[16:08] <stgraber> well, devtmpfs doesn't have "instances", so let's say it'd be very bad for someone to rm /dev/* in a container...
[16:08] <stgraber> (crashing the whole host and all other containers, working around all of the apparmor magic, kind of bad)
[16:08] <infinity> stgraber: Oh, indeed.
[16:09] <infinity> stgraber: A static dev should always be fine anyway, given that you know in advance what nodes you'll need, surely?
[16:09] <stgraber> yeah, that's what we had but for some reason that was breaking grub upgrades in containers (yeah, some people are weird and have grub installed in a container even though it'll never actually be able to run...)
[16:10] <infinity> stgraber: Maybe grub just needs some container-guessing voodoo.
[16:10] <stgraber> so for now we're going with broken grub upgrades but safe /dev and will figure out another way to fix the grub upgrade
[16:11] <stgraber> yeah, I think some of the scripts already use running-in-container to check for that case, I guess we'll need some more of that
[16:11] <cjwatson> hallyn and I went over that and I'd been hoping to avoid it :-(
[16:11] <cjwatson> Bah, world sucks
[16:12] <stgraber> yeah... once we have the device namespace in the kernel we won't need those hacks, but getting that stuff implemented and accepted upstream takes a lot of time... :(
[16:28] <bdmurray> infinity: v-done for bug 1066445
[16:28] <ubot2> Launchpad bug 1066445 in apt (Debian) "apt-get crashed with SIGSEGV in pkgCacheGenerator::ListParser::NewProvides()" [Unknown,New] https://launchpad.net/bugs/1066445
[16:28] <infinity> bdmurray: Is that some sort of subtle hint? ;)
[16:28] <bdmurray> infinity: if my verification makes sense yes it is!
[16:31] <infinity> bdmurray: Yeah, good enough for me.  Released.
[19:14] <stgraber> would appreciate if lxc could be reviewed quickly in quantal-proposed considering the impact. Clean diff can be found at http://paste.ubuntu.com/1303355/
[19:14] <stgraber> (impact is that any container created with current lxc in quantal will be able to wipe the host's /dev)
[19:14] <stgraber> (oh, and that any lucid container created with it won't boot)
[19:15] <stgraber> the lxc in the queue is a revert of the change causing that (removing the patch from debian/patches) and another trivial bugfix
[19:15] <stgraber> looks like the bug paperwork hasn't been done... /me gets that fixed
[19:32]  * skaet looks at schedule for reviews, and sees if SpamapS  is around?
[19:40] <infinity> stgraber: I'll give it a poke.
[19:42] <infinity> stgraber: Both sensible fixes, accepting.
[19:42] <stgraber> infinity: thanks
[19:42] <skaet> thanks infinty
[19:42] <infinity> stgraber: (The tar fix is almost as awful, TBH)
[19:42] <infinity> stgraber: You might want to talk to the security team about a USN and letting me copy this to -security when you're done validating.
[21:10] <bdmurray> It'd be good if the ubuntu-release-upgrader in quantal-proposed could move to -updates early
[21:21] <infinity> bdmurray: Yeah, that was on my radar.  Thanks for verifying it.