[00:36] <phillw> infinity: yeah, a glass of wine / beer & a chillax with sleep will do everyone good :)
[01:05] <xnox> phillw: I dislike encouragements of alcohol consumption.
[01:07] <phillw> so do I.. but  I dislike encouragements of respinning the world ~ 24 hours before a release... we can't win them all :P
[01:09] <xnox> phillw: not the world, just a couple of images.
[04:08] <ScottK> So I accept two and then I upload two ...
[05:11] <SpamapS> ScottK: the neverending SRUqueuee.... it goes on and on and on
[05:11] <ScottK> You could help that by accepting my postfix SRUs ...
[05:12] <ScottK> :-)
[05:12]  * micahg is reminded he promised to sponsor another SRU
[05:14] <SpamapS> ScottK: I will do an aggressive SRU run if I can find time next week. Otherwise, the queue will likely get nice and long until post UDS
[05:14] <ScottK> Here I am trying to show your server users how responsive the system is to issues ...
[05:17]  * micahg is trying to keep backports chugging along
[05:24] <lamont> 2
[05:24] <lamont> meh
[06:20] <obounaim> Good morning
[08:34] <infinity> cjwatson: So, we don't really have anything to upload just yet, but are we ready for me to inject chroots?
[09:44] <cjwatson> infinity: Yeah, please do - I think doko has some bits
[09:44] <infinity> cjwatson: Doing.
[09:49] <infinity> cjwatson: Alright, should be done.  I should throw a base-files at it to test it.
[09:51] <infinity> cjwatson: Oh, lolz, also your efi bits got dumped in raring/unapproved by IFP.
[09:51] <infinity> cjwatson: I guess that makes sense, since we've already seen that with copies.
[09:54] <cjwatson> infinity: Yeah, actually by the first publisher run
[09:54] <cjwatson> infinity: We almost explodificated the world by not following NewReleaseCycleProcess and stopping the publisher before setting raring to FROZEN
[09:55] <infinity> cjwatson: Yeah, I caught that in scrollback.  Sorry about that, didn't think about the consequences.
[09:55] <cjwatson> (Also, that stuff landing in unapproved is another symptom of the "UEFI copies within same archive shouldn't require re-approval" bug.)
[09:55] <cjwatson> (Which I should probably file and fix.)
[09:56] <infinity> cjwatson: Right, that's what I assumed.
[10:19]  * cjwatson files bug 1068558 for that
[10:19] <ubot2> Launchpad bug 1068558 in launchpad "UEFI copies within same archive shouldn't require re-approval" [Undecided,New] https://launchpad.net/bugs/1068558
[10:23] <babyface_> a lot of chinese user are complaining for this issue, can anybody take care of it? https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/1043031
[10:23] <ubot2> Launchpad bug 1043031 in language-selector "fontconfig-voodoo is not included in language-selector-common" [Undecided,Confirmed]
[10:28]  * cjwatson requests translations opening (NRCP step 16)
[10:28] <cjwatson> babyface_: fontconfig-voodoo was intentionally removed because (I'm told) fontconfig itself should automatically take care of it
[10:29] <cjwatson> As I said in that bug
[10:29] <cjwatson> babyface_: If it's not doing the right thing, ask the desktop team
[10:29] <cjwatson> It's not a matter for the release team
[10:29] <babyface_> cjwatson, ack. thanks.
[10:30] <cjwatson> And, you know, I asked on that bug for more information nearly a month ago and then there was radio silence until an hour ago ...
[10:30] <cjwatson> (Not that I'm even on the desktop team)
[10:33] <babyface_> cjwatson, sorry for that. I will verify it, and talk to desktop team if needed. thanks.
[10:43] <cjwatson> updated britney for raring (NRCP #17)
[10:44] <cjwatson> updated merge-o-matic for raring (NRCP #18)
[10:45] <cjwatson> hmm, MoM seems to have stopped again, better investigate that ...
[10:47] <cjwatson> I wonder how the Debian jikespg maintainer managed to upload something with a different .orig.tar.gz!
[10:48] <cjwatson> oh well, MoM hopefully unstuck
[10:51] <doko> can I copy my gcc-4.7 stuff?
[10:52] <cjwatson> err, apparently I may have been economical with the truth when I said the publisher was back on.  It is now ...
[10:52] <cjwatson> doko: go ahead
[11:07] <cjwatson> (feel free to accept your own; raring is only frozen to ensure that only the toolchain goes in, not because we need to control anything
[11:07] <cjwatson> )
[13:23] <rtg> now that the release carnage is somewhat abated, can I get an AA to NEW linux-lts-quantal and linux-meta-lts-quantal in the Precise queue ?
[14:33] <infinity> rtg: I'll get there shortly.
[14:33] <infinity> rtg: After I eat my lunch. ;)
[14:34] <rtg> infinity, thanks. no rush, just wanted to make sure they didn't get forgotten.
[14:49] <TheLordOfTime> was 2d unity removed from Q?
[14:52] <ScottK> TheLordOfTime: #ubuntu-desktop
[14:52] <tumbleweed> (and, yes)
[15:22] <bdmurray> Being the "new guy" on the SRU team - when does the team take charge of the quantal proposed queue?
[15:22] <ScottK> At release.
[15:24] <ScottK> At least that's when I quit caring when I wasn't on both teams ....
[15:33] <infinity> bdmurray: What ScottK said, with a logical tautology of "stuff in -proposed is an SRU when it's an SRU" which is, yes, after release.
[16:09] <cjwatson> So, britney is actually not looking hopelessly terrible
[16:09] <cjwatson> I have it able to run over a hypothetical natty-proposed -> natty, and it takes maybe five minutes or so in all and produces output that looks pretty plausible
[16:11] <cjwatson> Now, I still need to write something that takes its output and turns it into an Archive.copyPackages call (or maybe actually a load of individual Archive.copyPackage calls, since we probably want to be quite careful about versions)
[16:11] <cjwatson> I'll think about that parenthesis a bit
[16:11] <cjwatson> Also my changes to the Debian code are currently fairly brutal and disorganised
[16:12] <cjwatson> But this is looking promising for having it able to work by sometime next week
[16:12] <infinity> We want to be careful about versions, we also want to be careful about getting it in one transaction, or we just lollerskated away half the reason to use britney.
[16:12] <cjwatson> Well
[16:12] <cjwatson> The perfect shouldn't be the enemy of the good here
[16:12] <cjwatson> Archive.copyPackages doesn't give any kind of transactional assurance
[16:12] <infinity> True, but getting half in before a publisher run, and half after will create half an hour of messy.
[16:12] <cjwatson> It just creates lots of jobs
[16:13] <cjwatson> Right, but no worse in general that it would've been without britney
[16:13] <infinity> True, true.
[16:13] <infinity> Maybe it needs an XXX: FIXME on it, then. :P
[16:13] <cjwatson> It would certainly be nice to be able to copy everything in a giant transaction
[16:14] <cjwatson> But I suspect that attempting to do that right now would make LP explode
[16:14] <cjwatson> Perhaps instead of processing the heidi output (a full dump of what the target suite ought to look like) I should process the update_output text
[16:14] <cjwatson> That would tend to result in a series of incrementally sane changes
[16:15] <infinity> Well, even a publisher "transaction"... Though, after carefully removing everything that hack lock contentions with the publisher, intentionally adding one seems bad.
[16:15] <cjwatson> Not perfect in cases of loops, but it would optimise
[16:15] <infinity> s/hack/had/
[16:16] <cjwatson> I think this approach would be a pretty good first cut, and we can talk with LP folks about how we might come up with safer interfaces
[16:17]  * infinity nods.
[16:17] <cjwatson> The number of copies involved will tend to be limited by buildd performance, so we shouldn't be DoSing the PCJ queue in the same way that auto-sync does (or did, before I made manual copies take precedence)
[16:17] <infinity> I agree that half an hour of potential installability oopses probably isn't world ending.
[16:18] <cjwatson> Well, the way I'd put it is reducing the probability of such events from very high to rather low.
[16:18] <cjwatson> As opposed to zero.
[16:18] <infinity> Though, the contention that it's "not worse than before" may not be entirely true, cause if we have a snag all moving at once, those would have previously snagged one at a time based on build-deps.  Maybe.
[16:18]  * infinity shrugs.
[16:18] <infinity> We'll see.
[16:18] <cjwatson> There may be individual situations that get worse; my contention is that it will be on average significantly better, even without transactionality :)
[16:19] <infinity> Yes, on average, it should be an improvement.  We're in raging agreement.
[16:19] <cjwatson> Excellent.
[16:35] <bdmurray> if I do the sru verification of bug 1068389 is that sufficient to get it out soon or should it see more testing?
[16:35] <ubot2> Launchpad bug 1068389 in ubuntu-release-upgrader "P->Q - do-release-upgrade crashed with UnicodeEncodeError: 'ascii' codec can't encode character u'\xbb' in position 1: ordinal not in range(128) in DistUpgrade/DistUpgradeViewText.py", line 143, in showInPager" [Critical,In progress] https://launchpad.net/bugs/1068389
[16:44] <cjwatson> Hmm, perhaps I want an equivalent of Archive.copyPackage that uses the MASS_SYNC copy policy
[16:44] <cjwatson> Because I want version control, but I also want to avoid lots of mail spam
[16:45] <cjwatson> OTOH ... maybe what I want is "send mail as if this had been a direct upload to the release pocket"
[16:45] <cjwatson> maybe this needs to be a new copy policy
[16:45] <infinity> bdmurray: Given the nature of the bug, if it's tested to be an improvement, go ahead and release it, IMO.
[16:46] <cjwatson> oh, notify() has its own auto-sync handling, I think
[16:46] <infinity> cjwatson: "Send a mail as if this had been a direct upload..." is what we do currently on pocket copies, isn't it?
[16:46] <cjwatson> Bet it doesn't work for copies
[16:46] <cjwatson> infinity: Except for the ways in which it differs
[16:46] <infinity> cjwatson: Heh.
[16:47] <cjwatson> I'll need to check in more detail, but I believe that: (a) it sometimes has different recipients; (b) it will notify about auto-syncs
[16:47] <cjwatson> I might be wrong about (b)
[16:50] <cjwatson> Actually, it might work if I pretend that all the copies are sponsored for katie
[16:50] <cjwatson> This isn't a hacky system at all
[16:51] <infinity> Wait, we still special-case katie?
[16:51] <cjwatson> Oh yes
[16:51] <infinity> There aren't enough palms for my face.
[16:51] <cjwatson> auto-syncs are all sponsored for katie
[16:51] <cjwatson> It's what makes them not send giant amounts of mail
[16:52] <infinity> Well, yeah, I knew there was a hack in play, I just didn't realise it was still that.
[16:52] <cjwatson> It inhibits upload notifications and translation import error notifications; I think those are its only purposes
[17:17] <cjwatson> Hm, I'll need different output from britney anyway to get hold of the exact versions
[20:40] <bdmurray> slangasek: I'd like to add ubuntu-release-upgrader to -updates early
[20:40] <bdmurray> slangasek: see bug 1068389
[20:40] <ubot2> Launchpad bug 1068389 in ubuntu-release-upgrader "P->Q - do-release-upgrade crashed with UnicodeEncodeError: 'ascii' codec can't encode character u'\xbb' in position 1: ordinal not in range(128) in DistUpgrade/DistUpgradeViewText.py", line 143, in showInPager" [High,In progress] https://launchpad.net/bugs/1068389
[20:43] <slangasek> bdmurray: while it doesn't seem terribly urgent to me (affected users can always either restart the upgrader and not ask for details, or wait for the fix before upgrading), I also don't think we'll get much further feedback on it by letting it cook in -proposed, so ack
[20:43] <bdmurray> slangasek: it does leave your sources.list at quantal instead of precise
[20:44] <slangasek> ah
[20:44] <slangasek> bdmurray: urgency explained - so double ack :)
[20:45] <slangasek> bdmurray: maybe that program should be wrapped in a generic exception handler to roll things back on crash?
[20:45] <slangasek> (roll back && reraise)
[20:45] <slangasek> unrelated to the current SRU obviously
[20:53] <bdmurray> do you know how long it'll take for the dist-upgrader in -updates to show up?
[20:54] <slangasek> assuming that's done automatically by the publisher, should be ~30 minutes
[22:12] <stgraber> ^ marked quantal as released, archived all the quantal and 12.04.1 milestones, added raring daily and kept precise daily
[22:12] <stgraber> so the tracker should be ready for the first raring daily builds
[22:15]  * stgraber adds a work item to make it easier to access archived series
[22:29] <slangasek> raring is quickly achieving semantic satiation for me
[22:29] <slangasek> I think future release codenames should be chosen to guard against this
[22:30] <ScottK> I think future code names should be announced before final freeze so we can make the tools aware.
[22:31] <slangasek> that too
[22:34] <infinity> I think when we run out of alphabet, our next naming scheme should be "reusing the codenames of other distributions", just to confuse people.
[22:35] <infinity> And then see how long it takes for someone to make a crack about woody beefy miracles.
[22:35] <stgraber> that or continue with utf-8 and see how many tools and other websites we can get to crash
[22:36] <infinity> I don't know any animals or adjectives that start with ☭
[22:37] <infinity> In Communist Russia, release codenames blog about you?
[22:37] <slangasek> ☭-cell-anemic ☭head shark
[22:37] <slangasek> obvs
[22:42] <xnox> infinity: slangasek: wait... is that not a little head and beak of a bird possibly dove?!
[22:42] <ScottK> There's a reason we switched to version numbering from version names in backports revisions ...
[22:42] <ScottK> As long as the calendar moves forward we've got several decades to figure out the next plan.
[22:42] <slangasek> xnox: yes, isn't that the Latvian official bird?
[22:42] <skaet> thanks stgraber
[22:42] <xnox> slangasek: yes, it is. They taught us that in school. Strangely all the history text books were published in 1992.
[22:42]  * skaet has moved hopefully all the quantal ref's to raring in https://wiki.ubuntu.com/ArchiveAdministration
[22:42] <infinity> Not sure that was necessary.  They were examples that used to date all the way back to... Forever ago.
[22:57] <skaet> infinity, its a step in the process (was a link to raring-changes that needed updating, rest cosmetic, I agree).
[23:46] <ScottK> ^^^ is already an accepted SRU in quantal, so just to make sure it's not forgotten ...