[02:09] <jbicha> stgraber: ubuntu-docs should build on precise now
[02:09] <jbicha> sorry for the delay
[02:11] <stgraber> jbicha: ok, looking now
[02:49] <stgraber> jbicha: uploaded
[03:03] <jbicha> looks around for an SRU team member to accept ubuntu-docs
[03:04] <ScottK> bdmurray: "sru-release: comment on bugs when releasing packages to -updates and unsubscribe the SRU team from those bugs" <-- don't we want to be subscribed in case of regression comments?
[03:04] <ScottK> jbicha: I'll look.
[03:05] <jbicha> ScottK: thanks
[03:08] <ScottK> jbicha: Needs the bug foo in https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template before it can be accepted.
[03:08] <ScottK> Need to have some way of knowing if it passes muster.
[03:11] <jbicha> aw, I hoped I could slide one by :|
[03:15] <ScottK> I'd suggest the test case is verifying selected updates are present.  Just to make sure the right thing got uploaded. You could give a couple of examples.
[03:18] <ScottK> jbicha: I went ahead and accepted based on you'll fix the bug.  Please don't let me down.
[03:19] <jbicha> I'm working on it, language packs have their own separate validation process though
[03:26] <ScottK> Sure, but we still have to have something.
[03:48] <ScottK> OK.  I think that's enough damage to the SRU queue for one night.
[04:11] <ScottK> Whoever's doing stuff with the queue, it'd be nice to get the python2.7 SRU accepted...
[04:11] <ScottK> Easy diff , test case, and everything.
[04:39] <infinity> ScottK: I admit nothing.
[05:45] <ScottK> infinity: Thanks for nothing then.
[05:53] <infinity> ScottK: ;)
[13:13] <stgraber> hmm, who accepted lxc into -proposed?
[13:13] <stgraber> 0.7.5-3ubuntu61 should have been copied to -updates with sysvinit before letting 0.7.5-3ubuntu62 in...
[13:14] <stgraber> as it now reset the testing period of lxc and so when sysvinit will be copied (in 2 days), it's going to break lxc for all precise users
[13:14] <stgraber> though the fix in 0.7.5-3ubuntu62 is quite trivial, so I guess the regression testing period for that one can be shorten and both sysvinit and lxc still be released at the same time
[13:16] <ScottK> stgraber: It was me.  If you don't want something accepted, I guess I don't know why you uploaded it.
[13:17] <stgraber> I didn't upload it
[13:17] <stgraber> I uploaded 0.7.5-3ubuntu61
[13:17] <ScottK> I see.  Who uploaded that?
[13:18] <ScottK> (62)
[13:18] <stgraber> probably hallyn
[13:18] <ScottK> IIRC that's correct, now that you mention it.
[13:19] <ScottK> hallyn: I guess my comment should have been directed at you.  If there's an existing package in -proposed and you upload a new one, that should probably mean you want the existing SRU replaced.
[13:20] <stgraber> the new upload also didn't use -v so the bug list for the package on pending-sru is also wrong (doesn't list bug 974584). I'll make sure to manually track the lxc SRU and nag whoever's on duty when sysvinit reaches 7 days and both should be copied
[13:20] <ubot2> Launchpad bug 974584 in sysvinit "Semaphores cannot be created in lxc container" [High,Fix committed] https://launchpad.net/bugs/974584
[13:20] <stgraber> I'm testing 0.7.5-3ubuntu62 now to make sure it actually works as expected
[13:31] <stgraber> ScottK: I commented in bug 974584, so hopefully whoever is on SRU duty will notice and copy both. In theory that should be during bdmurray's shift so I should be around.
[13:31] <ubot2> Launchpad bug 974584 in sysvinit "Semaphores cannot be created in lxc container" [High,Fix committed] https://launchpad.net/bugs/974584
[13:31] <ScottK> Great.  Sorry for the confusion.
[14:00] <bdrung> hi. vlc is in -proposed since one week without someone reporting a regression (lp: #1025713). is it time to get it into -security/-updates?
[14:01] <cjwatson> brendand: http://people.canonical.com/~ubuntu-archive/pending-sru.html says (a) lots of bugs still verification-needed and (b) 7-day aging period not quite up
[14:01] <cjwatson> er
[14:01] <cjwatson> bdrung: ^-
[14:02] <jdstrand> cjwatson: are you actively looking at installation-guide? I have an untested preliminary patch to use xml2po from gnome-doc-utils. I'm happy to let you do it, but I can also do it
[14:02] <cjwatson> jdstrand: Yes, I've just uploaded a fix
[14:03] <jdstrand> sweet, that'll save me some time
[14:03] <jdstrand> cjwatson: thanks!
[14:03] <cjwatson> jdstrand: It didn't actually need poxml at all really since we don't ship any translations
[14:03] <jdstrand> even better
[14:03] <cjwatson> Which has been vaguely on my to-do list since warty and therefore will probably never happen ;-)
[14:03] <jdstrand> hehe
[14:04] <cjwatson> Sorry to steal the bug but I needed to update i-g anyway :)
[14:04] <jdstrand> cjwatson: no, that is totally fine. I only spent about 20 minutes on it last night
[14:05] <bdrung> cjwatson: VLC has a preliminary MRE
[14:09]  * cjwatson has no context except what's on the web page :)
[14:09] <cjwatson> (internet-poor at the moment)
[14:28] <bdmurray> ScottK: regarding sru-release that is what was discussed in the sru team call and the comment includes information regarding reporting a new bug and tagging it regression-updates a tag to which SRU team members can or are subscribed
[14:32] <ScottK> bdmurray: OK.  Thanks.
[16:29] <balloons> do we normally only retain the last milestone images?
[16:29] <balloons> I mean to say, I can't download alpha one from quantal using http://cdimage.ubuntu.com/releases/quantal/
[16:29] <balloons> only alpha 3 is listed
[16:30] <slangasek> balloons: correct
[16:31] <slangasek> the images still exist, but aren't on the website anymore
[16:31] <balloons> slangasek, interesting..it would just be a link right?
[16:31] <slangasek> how do you mean?
[16:31] <slangasek> the images are not on the server that provides the website
[16:31] <slangasek> they get archived off
[16:32] <balloons> ahh..
[16:32] <balloons> ok, so if I wanted to see if we regressed on an issue from alpha2 -> alpha 3, what do I do?
[16:32] <slangasek> good question
[16:32] <slangasek> so this is ringing bells with me, that there was some previous discussion about keeping the milestone images around longer
[16:33] <slangasek> but I don't remember who I had that conversation with and what the outcome was
[16:33] <ogra_> we should keep them public until release really
[16:33] <slangasek> we never have because of space considerations on the webservers
[16:33] <ogra_> yep, i understand the tech reason :) just saying
[16:33] <balloons> :-) yes, space is a concern
[16:34] <balloons> but I think the milestones are worth keeping about.. at least during the dev cycle of the current release
[16:35] <ogra_> though iirc rick suggested in the "no more freezes" thread that we should actually keep all daily images around in that scenario ...
[16:35] <slangasek> balloons: yes, we did not have room to do that at all
[16:35] <slangasek> I don't know if we have room now
[16:35] <ogra_> so there should at least be more HW in the pipe for providing such a setup
[16:36] <slangasek> pgraner: was it you that was asking about keeping multiple milestone images around during the devel cycle?
[16:36] <slangasek> whatever discussion we had about this didn't translate to an update on the milestone process
[16:38] <balloons> Well, I think we could possibly get some help for hosting if needed..
[16:38] <balloons> slangasek, atm, if I wanted an alpha 2 image, does it exist anywhere?
[16:38] <slangasek> it exists but isn't somewhere you can get to it
[16:39] <slangasek> I can cheat and repost it temporarily to cdimage.u.c, I think
[16:40] <slangasek> balloons: http://cdimage.ubuntu.com/releases/quantal/alpha-2/ shortly
[16:40] <Daviey> s3 storage would be perfect for this :)
[16:41] <balloons> slangasek, if we had a mirror willing to host, could we provide official gpg and md5's for the images and link out to the mirror do you think?
[16:42] <balloons> slangasek, :-) ty
[16:42] <skaet> slangasek,  Laney and I talked about leaving A2
[16:42] <slangasek> skaet: well, I didn't get the memo ;)
[16:42] <jdstrand> fyi, I'm back to tending to kde in component-mismatches
[16:44] <skaet> slangasek,   if space permits,  I'm +1 on keeping all the milestones up and accessible during the cycle.   We do need to change the checklists on the subject though ;)
[16:45] <ogra_> at least we should keep $current_milestone-1
[16:46] <ogra_> not sure having A1 around makes sense if we are at A3 already
[16:48] <skaet> ogra_   thought we were going to keep $current_milestone-1 around, but it appears glitch happened.   in terms  older ones - possibly useful to narrow down when a bug may bug may have been introduced, but am not fussed if we don't either.
[16:48] <ogra_> yeah
[16:49] <balloons> I'm not sure how the no alpha's or milestones discussion goes with this, but having those points in time to help pinpoint issues is useful. In this case, I want to check out alpha 2
[16:50] <balloons> ogra_ I'm sure can speak to it.. pinning down things like kernel regressions it's helpful to have old versions around to see when the regression started for testing :-)
[16:51] <ogra_> balloons, indeed, but yu wont have the iterations between the milestones around anyway and A1 is traditionally pretty crappy
[16:51] <ogra_> ("just good enough to have the installer work" usually)
[16:54] <skaet> ogra_,   traditions have been changing...   your ARM bias is showing   ;)
[16:54] <ogra_> nah, has nothing to do with arm but with achievability without losing actual development time
[16:55] <balloons> :-) I want all the milestones, to help ensure we given the community the tools needed to help us test; specifically when we have regressions. It is very often the case people encounter problems with a specific milestone that didn't previously exist, but without the images it's harder to verify and pin that down..
[16:55] <ogra_> it usually takes the time before A1 to actually even make the bits installable and get the installer in initial shape for a new release
[16:55] <balloons> obviously automagically iterating through daily images for regression testing would be amazing.. heh, we should start somewhere
[16:55] <ogra_> there is no time to make it shiny at that point of the cycle
[16:56] <ogra_> if you want it better, A1 should be released at A2 time
[16:56] <ogra_> ro we should double up the amount of developers :)
[16:56] <ogra_> *or
[16:57] <balloons> ogra_, lol, double devs.. that would make it take until alpha 3!
[17:07]  * skaet just updated https://wiki.ubuntu.com/MilestoneProcess checklist to make it explicit to keep prior milestone around. 
[17:07] <balloons> thanks everyone!