[02:09] stgraber: ubuntu-docs should build on precise now [02:09] sorry for the delay [02:11] jbicha: ok, looking now [02:49] jbicha: uploaded [03:03] looks around for an SRU team member to accept ubuntu-docs [03:04] 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] jbicha: I'll look. [03:05] ScottK: thanks [03:08] jbicha: Needs the bug foo in https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template before it can be accepted. [03:08] Need to have some way of knowing if it passes muster. [03:11] aw, I hoped I could slide one by :| [03:15] 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] jbicha: I went ahead and accepted based on you'll fix the bug. Please don't let me down. [03:19] I'm working on it, language packs have their own separate validation process though [03:26] Sure, but we still have to have something. [03:48] OK. I think that's enough damage to the SRU queue for one night. [04:11] Whoever's doing stuff with the queue, it'd be nice to get the python2.7 SRU accepted... [04:11] Easy diff , test case, and everything. [04:39] ScottK: I admit nothing. [05:45] infinity: Thanks for nothing then. [05:53] ScottK: ;) === yofel_ is now known as yofel [13:13] hmm, who accepted lxc into -proposed? [13:13] 0.7.5-3ubuntu61 should have been copied to -updates with sysvinit before letting 0.7.5-3ubuntu62 in... [13:14] 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] 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] stgraber: It was me. If you don't want something accepted, I guess I don't know why you uploaded it. [13:17] I didn't upload it [13:17] I uploaded 0.7.5-3ubuntu61 [13:17] I see. Who uploaded that? [13:18] (62) [13:18] probably hallyn [13:18] IIRC that's correct, now that you mention it. [13:19] 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] 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] Launchpad bug 974584 in sysvinit "Semaphores cannot be created in lxc container" [High,Fix committed] https://launchpad.net/bugs/974584 [13:20] I'm testing 0.7.5-3ubuntu62 now to make sure it actually works as expected [13:31] 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] Launchpad bug 974584 in sysvinit "Semaphores cannot be created in lxc container" [High,Fix committed] https://launchpad.net/bugs/974584 [13:31] Great. Sorry for the confusion. [14:00] 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] 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] er [14:01] bdrung: ^- [14:02] 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] jdstrand: Yes, I've just uploaded a fix [14:03] sweet, that'll save me some time [14:03] cjwatson: thanks! [14:03] jdstrand: It didn't actually need poxml at all really since we don't ship any translations [14:03] even better [14:03] Which has been vaguely on my to-do list since warty and therefore will probably never happen ;-) [14:03] hehe [14:04] Sorry to steal the bug but I needed to update i-g anyway :) [14:04] cjwatson: no, that is totally fine. I only spent about 20 minutes on it last night [14:05] cjwatson: VLC has a preliminary MRE [14:09] * cjwatson has no context except what's on the web page :) [14:09] (internet-poor at the moment) [14:28] 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] bdmurray: OK. Thanks. === doko_ is now known as doko === TheDrums is now known as Guest88176 [16:29] do we normally only retain the last milestone images? [16:29] I mean to say, I can't download alpha one from quantal using http://cdimage.ubuntu.com/releases/quantal/ [16:29] only alpha 3 is listed [16:30] balloons: correct [16:31] the images still exist, but aren't on the website anymore [16:31] slangasek, interesting..it would just be a link right? [16:31] how do you mean? [16:31] the images are not on the server that provides the website [16:31] they get archived off [16:32] ahh.. [16:32] ok, so if I wanted to see if we regressed on an issue from alpha2 -> alpha 3, what do I do? [16:32] good question [16:32] so this is ringing bells with me, that there was some previous discussion about keeping the milestone images around longer [16:33] but I don't remember who I had that conversation with and what the outcome was [16:33] we should keep them public until release really [16:33] we never have because of space considerations on the webservers [16:33] yep, i understand the tech reason :) just saying [16:33] :-) yes, space is a concern [16:34] but I think the milestones are worth keeping about.. at least during the dev cycle of the current release [16:35] though iirc rick suggested in the "no more freezes" thread that we should actually keep all daily images around in that scenario ... [16:35] balloons: yes, we did not have room to do that at all [16:35] I don't know if we have room now [16:35] so there should at least be more HW in the pipe for providing such a setup [16:36] pgraner: was it you that was asking about keeping multiple milestone images around during the devel cycle? [16:36] whatever discussion we had about this didn't translate to an update on the milestone process [16:38] Well, I think we could possibly get some help for hosting if needed.. [16:38] slangasek, atm, if I wanted an alpha 2 image, does it exist anywhere? [16:38] it exists but isn't somewhere you can get to it [16:39] I can cheat and repost it temporarily to cdimage.u.c, I think [16:40] balloons: http://cdimage.ubuntu.com/releases/quantal/alpha-2/ shortly [16:40] s3 storage would be perfect for this :) [16:41] 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] slangasek, :-) ty [16:42] slangasek, Laney and I talked about leaving A2 [16:42] skaet: well, I didn't get the memo ;) [16:42] fyi, I'm back to tending to kde in component-mismatches [16:44] 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] at least we should keep $current_milestone-1 [16:46] not sure having A1 around makes sense if we are at A3 already [16:48] 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] yeah [16:49] 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] 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] balloons, indeed, but yu wont have the iterations between the milestones around anyway and A1 is traditionally pretty crappy [16:51] ("just good enough to have the installer work" usually) [16:54] ogra_, traditions have been changing... your ARM bias is showing ;) [16:54] nah, has nothing to do with arm but with achievability without losing actual development time [16:55] :-) 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] 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] obviously automagically iterating through daily images for regression testing would be amazing.. heh, we should start somewhere [16:55] there is no time to make it shiny at that point of the cycle [16:56] if you want it better, A1 should be released at A2 time [16:56] ro we should double up the amount of developers :) [16:56] *or [16:57] 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] thanks everyone!