[00:24] <jbicha> bluesabre: tarballs would be better since there are binaries (the .png's)
[00:35] <bluesabre> jbicha, thanks
[00:36] <jbicha> bluesabre: or you can push to a bzr branch if you prefer
[00:42] <bluesabre> thanks jbicha!  I've done just that
[04:19] <knome> on the same note of "xubuntu uploaders away", we also need our docs uploaded, bug 1227275
[04:20] <knome> if somebody is willing to sponsor, it's appreciated
[05:04] <ScottK> doko_: I certainly didn't drop anything on purpose.
[05:04] <ScottK> cjwatson: I'll ask.
[05:17] <shadeslayer> cjwatson: Riddell already fixed it yesterday I think
[09:18] <doko_> cjwatson, python3-defaults still not migrated. python-csb is listed as failing, however failing forever, see debian report 711376
[09:25] <cjwatson> doko_: forced, http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/373
[09:26] <cjwatson> it's still not happy about codespeak-lib either
[09:35] <cjwatson> doko_: trying to work this out as I think it's a proposed-migration bug - will take a few minutes
[09:40] <cjwatson> doko_: I think I've fixed it for the next run ...
[09:46] <doko_> thanks \o/
[10:10] <cjwatson> doko_: accepted: python3-defaults
[10:42] <doko> cjwatson, https://launchpad.net/ubuntu/+source/ruby-multi-xml/0.5.4-0ubuntu2/+build/5032194  should I try to cancel?  seems to build on amd64, but apparently not on i386
[10:46] <cjwatson> doko: Yes, I think so
[10:46] <cjwatson> It's not stuck in buildd-manager or anything
[10:47] <doko> now in state Cancelling
[10:47] <cjwatson> 2013-09-19 10:47:37+0000 [QueryProtocol,client] Processing finished ABORTED build PACKAGEBUILD-5032194 (i386 build of ruby-multi-xml 0.5.4-0ubuntu2 in ubuntu saucy PROPOSED) from builder komainu
[10:48] <cjwatson> so the cancel worked
[10:48] <cjwatson> I don't know how the ftbfs pages will show that :)
[11:33] <knome> so, are the freezes landing today as in the schedule or is there some kind of delay?
[11:34]  * smartboyhw thinks there is some kind of delay, as mentioned in a mail
[11:36] <knome> no confirmation to the mail sent by kate yet
[11:36] <smartboyhw> I think the Beta2Freeze will probably go next Monday.. (Not sure about UIFreeze and DocFreeze)
[11:37] <cjwatson> smartboyhw: I wasn't aware that such a change had been agreed.  Are you referring to an agreement or are you guessing?
[11:37] <cjwatson> knome: Hardly surprising, Adam's at the Plumbers conference.  I'll see about getting a mail out
[11:38] <knome> cjwatson, cheers. (btw, i personally wouldn't mind at all postponing all the freezes until monday.)
[11:39] <smartboyhw> cjwatson, sorry, I confused it with the Alpha freezes (the new structure is still not getting in my head).
[11:39] <smartboyhw> kudos.
[11:41] <Laney> I thought there was agreement about Monday freezes, but less clarity about what to freeze
[11:43] <cjwatson> Laney: OK, do you have a reference for that?
[11:44] <Laney> cjwatson: Just going from what people said in the thread
[11:44] <Laney> there was no vote or anything like that
[11:44] <cjwatson> I only see Kate saying that, and there's no reasoning given?
[11:44] <cjwatson> Unless I'm looking at the wrong thread
[11:44] <Laney> The one that I started
[11:44] <Laney> forgot what I called it
[11:45] <cjwatson> Any idea when or what list?
[11:45] <Laney> oh yeah it was about blocks but it got into freeze dates a bit
[11:45] <Laney> on ubuntu-release
[11:45] <Laney> Message-ID: <20130904154121.GB11027@iota>
[11:45]  * Laney refreshes memory
[11:45] <cjwatson> Ah, right
[11:46] <cjwatson> Reading
[11:46] <Laney> Kylin wanted a longer one but didn't say how long exactly
[11:46] <cjwatson> Right, I had totally missed this thread, sorry
[11:47] <Laney> np
[11:47] <cjwatson> I don't think any of this discussion affects UI freeze, though
[11:47]  * smartboyhw would rather prefer 3-day freeze for Beta 1 and 7-day freeze for Final Beta, but he's got no deciding rights
[11:47] <Laney> no not that, but the beta freeze
[11:47] <cjwatson> or doc string freeze
[11:48] <cjwatson> smartboyhw: I'm finding the arguments in the thread for switching to Monday for beta freeze (inc. final beta) pretty persuasive
[11:49] <ogra> wasnt that already decided ?
[11:49] <cjwatson> ogra: Kind of, apparently I missed it
[11:49]  * ogra thought he saw a discussion about exactly that in here ... and there was agreement for monday 
[11:50] <ogra> was a while ago already ... a few weeks
[11:50] <Laney> I guess it's at the "do it and see if anyone screams" stage
[11:50] <ogra> heh
[11:50] <Laney> seems sensible to me
[11:50] <cjwatson> I'll edit the schedule/process now
[11:51] <Laney> but as for /what/ to freeze on Monday, I'm less clear
[11:51] <Laney> Maybe it's moot-ish if Ubuntu is participating
[11:51] <cjwatson> Indeed
[11:51] <cjwatson> I think we're fine to freeze core packages for final beta freeze
[11:53] <Laney> is ubuntu-touch doing it?
[11:53] <knome> anybody know people who could sponsor some uploads then? :)
[11:54] <smartboyhw> knome, that's #ubuntu-devel :P
[11:57] <mdeslaur> infinity: so, my systemd upload is stuck in -proposed because of arm64...the queue says 12 days, is that accurate?
[11:57] <cjwatson> mdeslaur: No it's not
[11:57] <Laney> no it's not
[11:57] <cjwatson> Nothing is blocked due to arm64
[11:57] <Laney> you're waiting on the upstart test
[11:58] <cjwatson> See the "(but arm64 isn't keeping up, so nevermind)" comment there
[11:58] <mdeslaur> cjwatson: ah, right...how do I know I'm waiting for the test?
[11:58] <cjwatson> "autopkgtest for upstart 1.10-0ubuntu1: RUNNING (Jenkins: public, private)"
[11:58] <mdeslaur> ah, right
[11:58] <cjwatson> I'm not too sure what's going on there - it's been running since Monday
[11:59] <mdeslaur> ok, sorry, seems I lack coffee this morning
[11:59] <cjwatson> jibel: ^- do you know what's up with the upstart autopkgtest?
[11:59] <cjwatson> It appears to have passed on amd64 but has hung shutting down?
[11:59] <cjwatson> And i386 failed
[12:00] <cjwatson> jodh: Do you know if the upstart autopkgtest failure on i386 is transient?  http://10.98.0.1:8080/view/Saucy/view/AutoPkgTest/job/saucy-adt-upstart/ARCH=i386,label=adt/71/console if you have VPN access
[12:00] <cjwatson> jodh: http://paste.ubuntu.com/6127979/
[12:02] <jibel> cjwatson, I've already seen this when adt crashes after the end of the test, when the alarm has already been reset. In that case it runs forever if there are some stalled processes. I'll kill it.
[12:03] <jibel> it happens sometimes with tests that use dbus-launch
[12:06] <cjwatson> Any opinions on freeze time on Monday, or shall I basically make it start of European day?
[12:07] <sil2100> cjwatson: hello! We pushed 2 new touch-related packages to the archive just now, they're in the NEW queue - Didier is aware of those, they had been, so to say, preNEWed by him - could you move them forward? Those are clickmanager-plugin and click-update-manager
[12:08] <cjwatson> Laney: Also, we're doing a migration block for final beta, not an upload block, right?
[12:08] <cjwatson> sil2100: OK, I had a bit of an interrupt storm, I'll try to get to it
[12:08] <Laney> cjwatson: I thought so
[12:08] <cjwatson> Laney: Yeah, BetaProcess is gratuitously out of date
[12:09] <sil2100> cjwatson: super big thanks :)
[12:09] <Laney> ah yea
[12:09] <Laney> h
[12:09] <Laney> I should have reviewed Kate's new page :-/
[12:09] <cjwatson> It was out of date on this before the rework too
[12:09] <cjwatson> would be nice if we had a canonical script to generate the block
[12:10] <ScottK> cjwatson: With no unblock of migration after the beta is out, I would hope.
[12:10] <cjwatson> ScottK: I think that's what we did last cycle, isn't it?
[12:10] <ScottK> Yes.
[12:10] <Laney> I have a script that parses seeded-in-ubuntu's data
[12:11] <ScottK> cjwatson: It's one of those things we end up doing every cycle, but it seems like it's never part of the "standard" way things are going so we end up relitigating it twice a year.
[12:11] <Laney> broke it a bit while playing with the new suggestion
[12:12] <cjwatson> ScottK: it's in the process now; hopefully that will stick a bit better
[12:12] <skaet> Laney,  since you were working the opt-in beta with me,  would still appreciate your input as to what really makes sense and what should be dropped.    :-)
[12:13] <skaet> cjwatson,  agreed, it was out of date.
[12:13] <Laney> yeah, will try to look soon
[12:13] <Laney> thanks for working on it
[12:14] <ScottK> cjwatson: Thanks.
[12:15] <skaet> ScottK,  since Kubuntu's usually one of the "opt-in"s,  yours and Riddell's input on https://wiki.ubuntu.com/BetaProcess, would be good for that column.
[12:16]  * ScottK really wasn't involved this time.
[12:16] <cjwatson> I've left ReleaseCandidateProcess alone for now, since I forget whether we're using a hard freeze for final
[12:16] <cjwatson> So start of EU day on Monday is fine by people?
[12:16]  * skaet nods, but figures ScottK's got historical perspective, and may have opinions.
[12:17] <Laney> Didn't we use a block-all source last time for RC/final?
[12:17] <Laney> start of day seems fine
[12:17] <cjwatson> Possibly.  I forget
[12:17] <skaet> cjwatson,  sees like that's the consensus, but probably worth a discussion at vUDS, based on how it goes this time.
[12:18] <cjwatson> what, for start of EU day?
[12:18] <cjwatson> I think that's a bit minor for UDS time :)
[12:18] <skaet> :-)
[12:18] <Laney> I will clean this script up and get it into u-a-t
[12:18] <skaet> start of EU day is fine.   I was ref'ing the prior comment
[12:18] <cjwatson> oh, right, I think there is prior consensus on that, I just don't remember it right now
[12:18] <Laney> not the biggest expert in apt_pkg though
[12:19] <cjwatson> (to go back to ScottK's comment about relitigating; I think we've agreed it before but I just got hit with about three parallel things to do)
[12:23] <skaet> does anyone know if mvo is still the right person to do the GnomeAppInstallDesktopDatabaseUpdate?    He didn't respond to my email last time,  and we probably want to make sure its done before final beta.
[12:25] <cjwatson> No, he's not
[12:25] <cjwatson> I'll see if I can figure out how to do it, modulo said interrupt storm
[12:25] <skaet> cjwatson,  understood.  thanks.
[12:25] <cjwatson> http://paste.ubuntu.com/6128057/  any comments?
[12:26] <cjwatson> some of the things suggested for the mail in BetaProcess no longer really make sense given the -proposed workflow, so I made some up on the fly :)
[12:28]  * skaet looking
[12:30] <skaet> cjwatson,  agreed, hence overdue for that scrub.   One thought,  possibly add a link to: https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule  so folks can see the upcoming events?
[12:30] <cjwatson> also http://paste.ubuntu.com/6128074/
[12:30] <cjwatson> ok
[12:30] <cjwatson> added
[12:30] <cjwatson> See https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule for the rest
[12:30] <cjwatson> of the schedule in the run-up to Ubuntu 13.10.
[12:31] <skaet> one to the doc and translation folks looks fine.
[12:31] <cjwatson> thanks, sent that one
[12:32] <cjwatson> I have to go and help with childcare for a bit now, so I'll look over any other comments and send the main announcement when I get back (<1hr)
[12:32] <doko> nice, icon and noweb can be demoted
[12:45] <jibel> cjwatson, jodh FTR upstart test was blocked by bug 1227610
[12:52] <skaet> dam,  following up from our earlier discussion on the translations.   I'm not seeing seb128 or jasonwarner online.    Is there anyone else you can recommend to help with "Notify DavidPlanella (ubuntu-translation-coordinators) to coordinate a fresh set of language packs which will be exported, uploaded, and built in time for beta."
[12:52] <skaet> dpm, ^ ??
[12:53] <dpm> I generally coordinated with pitti, who did the actual uploads, but neither him nor I have much time to work in translations, as we've moved to other roles
[12:56] <skaet> dam,  pitta's here at the conference with me,  so I'll see if I can track him down and see if he's willing to help this time.    Looks like this is a gap then, that we'll need to figure out a solution for longer term.
[12:58]  * skaet detests the auto correct on this system…. must figure out how to turn it off.  :-P  sorry dpm.
[12:58] <dpm> no worries, I got what you meant :)
[13:02] <cjwatson> skaet: I believe seb128 is on holiday
[13:03] <RAOF> Are we going to get glamor-egl through NEW?
[13:03] <cjwatson> jibel,jodh: OK.  I think that only explains amd64, though, not the i386 failure I asked jodh about
[13:04] <cjwatson> sent the freeze announcement
[13:27] <cjwatson> RAOF: yup
[13:31]  * Laney imagines a pitti bread
[13:37] <RAOF> cjwatson: Woot! Thanks.
[13:46] <skaet> cjwatson, am heading downstairs to linux conf now, will only be online sporadically.   Will see if I can find pitti re: translations.
[13:46] <cjwatson> translations were done fairly recently
[13:47] <cjwatson> he may not need to bother
[13:48] <skaet> ok,  we need to update that step in the checklist with a new contact.
[13:55] <cjwatson> RAOF: looks like libglamor-dev could reasonably be M-A: same, FWIW
[13:59] <RAOF> cjwatson: I'll fix that in git.
[14:07] <cjwatson> RAOF: ta
[14:58] <jbicha> hi, could gnome-documents/armhf be removed? it depends on libgdata to be built with goa support but that was disabled on armhf to try to reduce what dependencies need to be installed on the Ubuntu Phone images
[15:06] <infinity> cjwatson: I was considering an archive freeze, not a migration block, but perhaps this needs more discussion, as no one seems to quite agree. :P
[15:06] <cjwatson> infinity: Ah, consensus here appeared to be a migration block
[15:07] <cjwatson> That's my personal preference too I think
[15:08] <infinity> cjwatson: I do think there needs to be a point where we take control and actually reject uploads.  That's hard to do with a migration block.
[15:08] <infinity> cjwatson: OTOH, the autolander makes archive freezes suck because of opaque copies. :/
[15:08] <infinity> cjwatson: Which are basically my for/against on the matter.
[15:09] <cjwatson> infinity: For final freeze, I agree; for alphas/betas, I don't think it's necessary
[16:03] <pitti> hey all
[16:04] <pitti> as per skaet's request: automatic langpack uploads disabled, will upload fresh -base packs on Monday for final beta (I requested an LP export, shold arrive by Mon)
[16:44] <slangasek> infinity: I'm +1 for the britney block approach
[16:44] <slangasek> fwiw
[16:44] <Laney> for beta and/or final?
[16:45] <slangasek> for beta
[16:45] <slangasek> for final, we need to deal with quiescing -proposed somehow
[16:46] <slangasek> either with a freeze controlling what goes in, or by communicating a plan to kick stuff back out of -proposed that fails to migrate
[16:46] <infinity> Well, we carry some things over at times, but we need a way to prevent stupid uploads at the upload phase, not later.
[16:47] <infinity> Rejects are better than rollbacks.
[16:49] <slangasek> infinity: well, accepting into -proposed also gives us the option of diverting to t* at opening anything that we don't accept into saucy release; it's the same amount of review for the release team either way, but one option saves the uploader a second upload
[16:50] <infinity> slangasek: Diverting to T is what I meant by "carrying over", but I don't want to accept something that I would never accept into S in the first place, because if they need to fix what's in release we need to punt the proposed one.
[16:50] <infinity> (Plus people blatantly ignoring FF, etc...)
[16:51] <slangasek> I think the case where they need to fix what's in release and have nonrelease crap in -proposed is a minority case, and we shouldn't optimize our process around that
[16:52] <infinity> I think you underestimate the number of things we've traditionally had to reject in the last few weeks of release. :)
[16:53] <infinity> Anyhow, I'm fine with beta being just a britney block and seeing how that goes, and I suspect we're all agreed at this point that final freeze should be an archive freeze.
[16:53] <infinity> If that split turns out to be a Bad Idea, we can revisit for 14.04.
[16:53] <infinity> (Or choose to be more conservative because it's an LTS, or whatever)
[17:14] <stgraber> slangasek: pushed the fix for bug 1181789 to lp:~ubuntu-core-dev/ubuntu/raring/upstart/raring/
[17:23] <xnox> cool. thanks.
[17:33] <slangasek> stgraber: thanks!
[17:33] <slangasek> infinity: it's not underestimating things that need rejected, only estimating that the number of things that need to be rejected in a timely fashion to make room for *release-worthy* upgrades to take their place is quite small
[17:34] <slangasek> but regardless, yes, I'm fine with an archive freeze for FF
[21:09] <lool> sorry, trying to track when the archive publisher run will be done and when the next britney run occurs; would someone be so kind to tell me when both of these start + finish in cron format, I'll make note of it here to stop wondering  :-)
[21:09] <lool> nevermind, cjwatson just helpfully jumped in to explain in another chan
[21:10] <cjwatson> well, I didn't answer as for cron
[21:10] <infinity> The publisher has been running fine, but lillypilly seems less happy.
[21:10] <cjwatson> the cron job is 03-58/5 (lp:lp-production-crontabs pepo-lp_publish) but it doesn't actually run every five
[21:11] <cjwatson> that's "attempt to run every five if not already running"
[21:11] <infinity> Either way, it's run several times since the last britney run.
[21:11] <cjwatson> the publisher will flip the state of the upload to Published in the UI when it starts, but it isn't visible until the end, so that time span is pretty reliably the duration of the publisher
[21:11] <cjwatson> i.e. about 20 mins for a run including the devel release pocket
[21:12] <infinity> cjwatson: The britney run that's been running for an hour; could this be an issue? :P
[21:12] <infinity> 1002      6950  0.0  0.0  12336  1504 ?        S    20:09   0:00 /bin/bash ./britney merge stats
[21:14] <cjwatson> Yeah, it indeed could
[21:14] <cjwatson> An hour, seriously?  FFS
[21:15] <infinity> ScottK / Riddell: If I dropped the ancient ti-omap4 kernel, pvr-omap4, and the *-omap-revert X server/drivers from the archive, thus effectively killing the ability to have a kubuntu-omap4 image, would you care?
[21:15]  * cjwatson nukes it from orbit
[21:15] <infinity> ScottK / Riddell: That whole stack is somewhere between unsupportable and lolz, I'd much rather we just drop it entirely.
[21:22] <lool> noting cron details
[21:24] <Riddell> infinity: I'd care but I'd be convincable
[21:24] <Riddell> infinity: but server has omap4 too?
[21:28] <infinity> Riddell: omap4 for server can be done with the -generic kernel, since it doesn't need a decent graphics driver.
[21:28] <infinity> Riddell: That's potentially doable for kubuntu too, if you guys don't care about having any acceleration.
[21:29] <infinity> (Entirely impossible for Ubuntu Desktop, since we rely on working GL/EGL)
[21:29] <infinity> Riddell: Basically, supporting the quantal kernel and a reverted X server forever is just not a tenable solution.
[21:31] <infinity> Nooooo!
[21:31] <infinity> cjwatson: gcc-4.8 failed on kijo...
[21:31] <infinity> cjwatson: Oh, lolz.  150m timeout.
[21:31]  * infinity headdesks.
[21:31] <cjwatson> sigh
[21:31] <cjwatson> any prospect of that new kernel?
[21:32] <infinity> Pestering dannf every day. :P
[22:01] <cjwatson> bdmurray: thanks for partman-basicfilesystems; note that it's part of a set with partman-efi
[22:01] <cjwatson> (and a forthcoming grub2)
[22:06] <bdmurray> cjwatson: okay, getting there
[22:07] <cjwatson> infinity: I guess we could bump the timeout just for arm64 and try again.  Dunno if it's worth it ...
[22:08] <infinity> cjwatson: Or just on kijo01, since it's defined in .sbuildrc (which is puppeted, but IS could override it).
[22:08] <cjwatson> yeah
[22:08] <cjwatson> I suppose it might as well be doing something
[22:08] <infinity> cjwatson: I'm not sure it's worth the effort if we think we're getting a fixed kernel soon.