[00:36] infinity: yeah, a glass of wine / beer & a chillax with sleep will do everyone good :) [01:05] phillw: I dislike encouragements of alcohol consumption. [01:07] 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] phillw: not the world, just a couple of images. [04:08] So I accept two and then I upload two ... [05:11] ScottK: the neverending SRUqueuee.... it goes on and on and on [05:11] You could help that by accepting my postfix SRUs ... [05:12] :-) [05:12] * micahg is reminded he promised to sponsor another SRU [05:14] 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] 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] 2 [05:24] meh [06:20] Good morning === tkamppeter_ is now known as tkamppeter === henrix_ is now known as henrix [08:34] cjwatson: So, we don't really have anything to upload just yet, but are we ready for me to inject chroots? === yofel_ is now known as yofel === mmrazik is now known as mmrazik|lunch [09:44] infinity: Yeah, please do - I think doko has some bits [09:44] cjwatson: Doing. [09:49] cjwatson: Alright, should be done. I should throw a base-files at it to test it. [09:51] cjwatson: Oh, lolz, also your efi bits got dumped in raring/unapproved by IFP. [09:51] cjwatson: I guess that makes sense, since we've already seen that with copies. [09:54] infinity: Yeah, actually by the first publisher run [09:54] infinity: We almost explodificated the world by not following NewReleaseCycleProcess and stopping the publisher before setting raring to FROZEN [09:55] cjwatson: Yeah, I caught that in scrollback. Sorry about that, didn't think about the consequences. [09:55] (Also, that stuff landing in unapproved is another symptom of the "UEFI copies within same archive shouldn't require re-approval" bug.) [09:55] (Which I should probably file and fix.) [09:56] cjwatson: Right, that's what I assumed. [10:19] * cjwatson files bug 1068558 for that [10:19] Launchpad bug 1068558 in launchpad "UEFI copies within same archive shouldn't require re-approval" [Undecided,New] https://launchpad.net/bugs/1068558 [10:23] 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] 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] babyface_: fontconfig-voodoo was intentionally removed because (I'm told) fontconfig itself should automatically take care of it [10:29] As I said in that bug [10:29] babyface_: If it's not doing the right thing, ask the desktop team [10:29] It's not a matter for the release team [10:29] cjwatson, ack. thanks. [10:30] 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] (Not that I'm even on the desktop team) [10:33] cjwatson, sorry for that. I will verify it, and talk to desktop team if needed. thanks. === mmrazik|lunch is now known as mmrazik [10:43] updated britney for raring (NRCP #17) [10:44] updated merge-o-matic for raring (NRCP #18) [10:45] hmm, MoM seems to have stopped again, better investigate that ... [10:47] I wonder how the Debian jikespg maintainer managed to upload something with a different .orig.tar.gz! [10:48] oh well, MoM hopefully unstuck === doko_ is now known as doko [10:51] can I copy my gcc-4.7 stuff? [10:52] err, apparently I may have been economical with the truth when I said the publisher was back on. It is now ... [10:52] doko: go ahead [11:07] (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] ) === henrix is now known as henrix_ === henrix_ is now known as henrix [13:23] 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 ? === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [14:33] rtg: I'll get there shortly. [14:33] rtg: After I eat my lunch. ;) [14:34] infinity, thanks. no rush, just wanted to make sure they didn't get forgotten. [14:49] was 2d unity removed from Q? [14:52] TheLordOfTime: #ubuntu-desktop [14:52] (and, yes) [15:22] Being the "new guy" on the SRU team - when does the team take charge of the quantal proposed queue? [15:22] At release. [15:24] At least that's when I quit caring when I wasn't on both teams .... [15:33] 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] So, britney is actually not looking hopelessly terrible [16:09] 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] 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] I'll think about that parenthesis a bit [16:11] Also my changes to the Debian code are currently fairly brutal and disorganised [16:12] But this is looking promising for having it able to work by sometime next week [16:12] 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] Well [16:12] The perfect shouldn't be the enemy of the good here [16:12] Archive.copyPackages doesn't give any kind of transactional assurance [16:12] True, but getting half in before a publisher run, and half after will create half an hour of messy. [16:12] It just creates lots of jobs [16:13] Right, but no worse in general that it would've been without britney [16:13] True, true. [16:13] Maybe it needs an XXX: FIXME on it, then. :P [16:13] It would certainly be nice to be able to copy everything in a giant transaction [16:14] But I suspect that attempting to do that right now would make LP explode [16:14] 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] That would tend to result in a series of incrementally sane changes [16:15] Well, even a publisher "transaction"... Though, after carefully removing everything that hack lock contentions with the publisher, intentionally adding one seems bad. [16:15] Not perfect in cases of loops, but it would optimise [16:15] s/hack/had/ [16:16] 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] 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] I agree that half an hour of potential installability oopses probably isn't world ending. [16:18] Well, the way I'd put it is reducing the probability of such events from very high to rather low. [16:18] As opposed to zero. [16:18] 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] We'll see. [16:18] There may be individual situations that get worse; my contention is that it will be on average significantly better, even without transactionality :) [16:19] Yes, on average, it should be an improvement. We're in raging agreement. [16:19] Excellent. [16:35] 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] 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] Hmm, perhaps I want an equivalent of Archive.copyPackage that uses the MASS_SYNC copy policy [16:44] Because I want version control, but I also want to avoid lots of mail spam [16:45] OTOH ... maybe what I want is "send mail as if this had been a direct upload to the release pocket" [16:45] maybe this needs to be a new copy policy [16:45] bdmurray: Given the nature of the bug, if it's tested to be an improvement, go ahead and release it, IMO. [16:46] oh, notify() has its own auto-sync handling, I think [16:46] 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] Bet it doesn't work for copies [16:46] infinity: Except for the ways in which it differs [16:46] cjwatson: Heh. [16:47] 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] I might be wrong about (b) [16:50] Actually, it might work if I pretend that all the copies are sponsored for katie [16:50] This isn't a hacky system at all [16:51] Wait, we still special-case katie? [16:51] Oh yes [16:51] There aren't enough palms for my face. [16:51] auto-syncs are all sponsored for katie [16:51] It's what makes them not send giant amounts of mail [16:52] Well, yeah, I knew there was a hack in play, I just didn't realise it was still that. [16:52] It inhibits upload notifications and translation import error notifications; I think those are its only purposes [17:17] Hm, I'll need different output from britney anyway to get hold of the exact versions === henrix is now known as henrix_ === Ursinha is now known as Ursinha-afk [20:40] slangasek: I'd like to add ubuntu-release-upgrader to -updates early [20:40] slangasek: see bug 1068389 [20:40] 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] 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] slangasek: it does leave your sources.list at quantal instead of precise [20:44] ah [20:44] bdmurray: urgency explained - so double ack :) [20:45] bdmurray: maybe that program should be wrapped in a generic exception handler to roll things back on crash? [20:45] (roll back && reraise) [20:45] unrelated to the current SRU obviously [20:53] do you know how long it'll take for the dist-upgrader in -updates to show up? [20:54] assuming that's done automatically by the publisher, should be ~30 minutes [22:12] ^ marked quantal as released, archived all the quantal and 12.04.1 milestones, added raring daily and kept precise daily [22:12] 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] raring is quickly achieving semantic satiation for me [22:29] I think future release codenames should be chosen to guard against this [22:30] I think future code names should be announced before final freeze so we can make the tools aware. [22:31] that too [22:34] 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] And then see how long it takes for someone to make a crack about woody beefy miracles. [22:35] that or continue with utf-8 and see how many tools and other websites we can get to crash [22:36] I don't know any animals or adjectives that start with ☭ [22:37] In Communist Russia, release codenames blog about you? [22:37] ☭-cell-anemic ☭head shark [22:37] obvs [22:42] infinity: slangasek: wait... is that not a little head and beak of a bird possibly dove?! [22:42] There's a reason we switched to version numbering from version names in backports revisions ... [22:42] As long as the calendar moves forward we've got several decades to figure out the next plan. [22:42] xnox: yes, isn't that the Latvian official bird? [22:42] thanks stgraber [22:42] 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] Not sure that was necessary. They were examples that used to date all the way back to... Forever ago. [22:57] infinity, its a step in the process (was a link to raring-changes that needed updating, rest cosmetic, I agree). [23:46] ^^^ is already an accepted SRU in quantal, so just to make sure it's not forgotten ...