[06:57] jdstrand: yep, kees ack'ed it, too; it's in now === smb` is now known as smb [10:08] skaet, i wonder if 'open the work-items database for the new release' should be on the release checklist somewhere, it can be done as soon as a driver actually makes the release in launchpad i believe [10:08] (its done now in theory btw) [10:13] apw, am working through the checklist now. If its not there, I'll add it. [10:14] skaet, fun bedtime reading i am sure ... congrats btw on surviving the release :) [10:14] * cjwatson is going round sorting out the seeds [10:14] mvo: oh, I noticed a comment from you that the dist-upgrader-all directory was only in -proposed, not -updates - want me to fix that? [10:15] * skaet is glad to see cjwatson, and has some questions.... [10:15] congratulations on the release, seems to have gone smoothly :) [10:15] cjwatson, smoother than the stories robbiew has been telling me for the last couple of months at any rate ;) [10:15] cjwatson: a fix for this would be much appreciated, ideally so that on copy from -proposed to -update the dist-upgrader-all dir is copied as well [10:17] Bug #231371 [10:17] Launchpad bug 231371 in soyuz "support dist-upgrader pocket copy " [High,Triaged] https://launchpad.net/bugs/231371 [10:17] cjwatson, which tasks from the checklist have you handled already? [10:20] mvo: unfortunately it has to be manual, but I updated https://wiki.ubuntu.com/ArchiveAdministration#Special%20case:%20update-manager%20updates [10:20] s/updated/wrote/ actually [10:20] mvo: or rather, it has to be manual unless Soyuz is enhanced ... anyway, you'll see it in -updates in an hour or so [10:21] cjwatson: great, thanks cjwatson! [10:21] skaet: none yet, I was just starting on creating the new seeds [10:22] skaet: can you access https://launchpad.net/ubuntu/maverick/+driver ? might as well do step 1 :-) [10:26] * cjwatson runs 'for x in *.maverick; do bzr branch $x ${x%.maverick}.natty; done' and starts pushing those up [10:28] * skaet has changed driver for maverick to ubuntu-core-dev. [10:42] hello [10:42] cjwatson, jml indicates that a Natty distroseries has been created with status FUTURE. Should we move it to FROZEN? [10:43] FUTURE? wow. [10:43] shiny new lp feature? [10:43] hang on a sec, need to finish seeds first. [10:43] cjwatson: shiny new lack of buck [10:43] bug [10:44] I have no idea how I misspelled that [10:45] I fixed its displayname [10:45] jml: Did you need DB hacking to do that? [10:45] I can't see it in the UI. [10:45] wgrant: no. there's an option to change the status [10:45] wgrant: perhaps it's a restricted view? [10:47] natty seeds created, germinate output running (we don't need to wait for that) [10:47] seed mirrors created too, so that's steps 2 and 3 [10:47] checked maverick release pocket queue, it's empty (step 4) [10:47] Ah, there. [10:48] I assume we still ought to disable the publisher during distroseries initialisation? [10:48] Uh, yes. [10:48] Or boom. [10:48] :( [10:48] wgrant: is there a bug filed for that? [10:49] Hm, it's possibly OK if we do a careful run afterwards like the instructions say. But it's not tested TTBMK. [10:49] publisher disabled [10:49] jml: yes, please move natty to FROZEN [10:49] The publisher, i-d-s and transactions have an interesting relationship :/ [10:49] :) [10:50] is it correct for both lucid and maverick to be CURRENT? [10:50] IIRC before we've had the LTS be SUPPORTED. [10:50] cjwatson: need a losa to do that, I think. [10:50] Needs a LOSA, and yes Lucid should be supported. [10:50] skaet: ok, you wanna chase a LOSA to change lucid -> SUPPORTED and natty -> FROZEN? [10:51] I've created an ubuntu-11.04 milestone. will go round and create the other milestones since I might as well [10:51] cjwatson, jml's volunteered. [10:52] cjwatson, re: other milestones, sounds good. [11:09] all milestones created [11:09] https://launchpad.net/ubuntu/natty/+milestones [11:09] \o/ [11:09] https://launchpad.net/ubuntu/+series indicates that the statuses are fixed [11:10] oh, of course, germinate output won't work until the publisher has run, silly me [11:11] more-extra symlinks created (step 9) [11:12] wgrant,jml: in https://wiki.ubuntu.com/NewReleaseCycleProcess step 10 and 12, do both of those need to be LPCONFIG=ftpmaster-publish now? I know that step 12 does, but not sure about i-f-p [11:12] step 8 is verified, btw. [11:13] cjwatson: i-f-p shouldn't care. [11:13] cjwatson: It's all DB work. [11:13] does it need an LPCONFIG environment variable at all, then? [11:13] It needs to run as a specific DB user. [11:13] Hm. [11:13] But that may be in the script. [11:13] * wgrant checks. [11:14] Someone needs to check the configs (the key is archivepublisher/dbuser) [11:14] They're probably the same. [11:14] any guess on filename? [11:14] Not sure where the production configs live on prod, sorry. [11:14] * cjwatson guesses at production-configs/ :-) [11:15] Ah. [11:15] ftpmaster/launchpad-lazr.conf in there, then. [11:15] no dbuser there [11:15] Inheritance yay. [11:15] nor in ftpmaster-publish/ [11:15] So they're the same. [11:16] does meta/extends define the inheritance? [11:16] Yes. [11:16] ah, in fact ftpmaster-publish/launchpad-lazr.conf is really simple [11:16] Just changing dirs? [11:17] all it does is set error_reports/oops_prefix to FTPMASTERPUBLISH and error_reports/error_dir to /srv/launchpad.net/production-logs/lp_publish - otherwise it just extends ftpmaster [11:17] Doesn't matter, then. [11:17] and some log file fiddling in the non-lazr stuff [11:17] ok [11:17] * cjwatson fixes the publisher steps in the process, where it does matter [11:17] it's going to be a few hours before we'll be ready to run the branch-distro script [11:18] (step 11) [11:18] jml: ok, but you guys consider yourselves notified? [11:18] cjwatson: indeed we do. [11:18] preparing to run i-f-p [11:19] The subsequent careful publisher could be amusing. [11:19] But we'll see. [11:19] will use '-a amd64,armel,i386,powerpc' (per the note in the process page, which comes from StevenK) [11:19] amusing? [11:21] skaet, hmm, https://wiki.ubuntu.com/MaverickMeerkat/ReleaseManifest talks about the ARM releases living on releases.u.c (i'm not sure we want to move them, but the manifest page should be in sync) [11:21] * ogra just noticed that now :( [11:21] ogra, no worries. let me look [11:22] cjwatson: Amusing in that it might fail, due to some stuff that was done a couple of weeks ago. But it should be OK. [11:22] ogra: I explicitly checked with davidm and he said cdimage not releases [11:22] cjwatson, perfect [11:22] The -a might be unnecessary now, but won't hurt. [11:22] ogra: where does that page talk about ARM living on releases.u.c? [11:22] (i personally dont like them on r.u.c because the download page gets confusingly full) [11:22] i-f-p running [11:23] 2010-10-11 10:23:02 ERROR Parent series has pending builds. [11:23] Crap. [11:23] ugh, i should have more coffee ... [11:23] Indeed. [11:23] cjwatson, Maybe just historical, but they did live on r.u.c for karmic/lucid. [11:23] Three pending armel builds. [11:23] cjwatson, skaet sorry for the noise ... a discussion in another channel got me confused [11:23] cjwatson, thankds for clarifying. [11:23] Investigating. [11:23] https://edge.launchpad.net/ubuntu/maverick/+builds?build_text=&build_state=pending&arch_tag=all [11:24] indeed its exactly the opposite of what i said. all is fine [11:24] cjwatson: Their DB state is corrupt. [11:24] cjwatson: There are pending, but not queued. [11:25] We'll need DB surgery to set them to some other state (probably Superseded). [11:25] I'll go find a LOSA [11:26] persia: indeed. moving them was an explicit decision, I'm told [11:27] Ah, OK. If it's intentional, it's good :) [11:29] wgrant: mthaddon asked if he could have some SQL [11:29] cjwatson: They should have some already, I would have thought. [11:29] But otherwise: [11:33] http://paste.ubuntu.com/510797/ [11:34] * cjwatson isn't seeing anything relevant on the internal LPHowTo page [11:34] but then, not a LOSA [11:35] oh wait, there it is, it's on https://wiki.canonical.com/InformationInfrastructure/IS/BuilddFixing [11:36] Yeah, I can't exactly browse the internal wiki yet. [11:36] ish [11:36] well, quite [11:36] but for mthaddon's benefit [11:36] Does that also specify deleting BuildQueues and BuildPackageJobs? [11:36] yes [11:36] and Job [11:36] I don't think they exist in this case. [11:36] Right, forgot that one. [11:37] right - the context here is forcibly removing a build that kills buildds [11:37] Yeah. [11:48] rerunning i-f-p, thanks mthaddon [11:49] np [11:49] 2010-10-11 10:48:54 ERROR Parent series queues are not empty. [11:49] gar [11:49] does this really require non-RELEASE queues to be empty? [11:50] It shouldn't. [11:50] shouldn't, looking at the code [11:50] I glanced over the code last night. [11:50] And it looked sane. [11:50] oh, wait, NEW is non-empty [11:50] hah, this is a bug [11:50] Oh? [11:51] Ah. [11:51] partner. [11:51] Indeed. [11:51] partner is non-inherited, but i-f-p refuses if it has queue entries [11:51] I guess I can just process these and then wait ... [11:52] * cjwatson files a bug in the meantime [11:52] Or maybe convince someone to cowboy the extra arg into i-f-p. [11:52] it's probably faster to process NEW ... [11:52] Unfortunately true. [11:52] And then wait for the publisher. [11:52] Oh. [11:52] But they're sources, so no publisher required. [11:53] If you're quick. [11:53] fwiw, I reckon it'd be a good idea to have some common tag for bugs associated with doing the NewReleaseCycleProcess [11:53] bug 658256, if you want to give it one [11:53] Launchpad bug 658256 in soyuz "initialise-from-parent refuses if there are NEW queue entries for partner (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/658256 [11:54] wgrant: not entirely sure I want to play that kind of game :) [11:54] cjwatson: thanks [11:54] cjwatson: Well, i-f-p will work fine if you run it between accepting those sources and the builds finishing. [11:54] hm, I guess it will [11:55] wgrant: did you say there was a bug for need to disable the publisher during distroseries initialisation? [11:55] in that case, I should do a coffee resupply *first*. [11:55] jml: I don't think there is. In the context of the whole process (with the extra careful runs later on) it will probably work fine, but it needs testing. [11:55] we'd have to disable the cron job for the manual careful runs anyway [11:56] so the fact that the careful runs is needed is a bug, if you want to look at it that way [11:56] (i.e. should be possible to initialise new series without fiddling with publisher setup) [11:56] s/runs is/runs are/ what happened there ... [11:58] We want to make dirty pockets forcable for other reasons anyway, which would eliminate the need for the careful runs. [11:58] indeed. [12:05] partner packages accepted, i-f-p running. third time's the charm [12:07] wgrant,jml: bug 55211 is essentially this, BTW. [12:08] Launchpad bug 55211 in soyuz "shouldn't require careful publisher run when cloning new released distrorelease (heat: 4)" [Medium,Triaged] https://launchpad.net/bugs/55211 [12:09] cjwatson: ta. I'll mark https://bugs.edge.launchpad.net/soyuz/+bug/658269 as a dupe of that then. [12:09] Launchpad bug 658269 in soyuz "Initializing new series requires fiddling with publisher setup (affects: 1) (heat: 6)" [Undecided,New] [12:11] btw, when you guys get bored with natty, don't forget antimony is down to 5Gb on /srv [12:12] Can we remove jaunty from releases/ yet? [12:13] It doesn't die for nearly three weeks, does it? [12:13] Damn. [12:14] Ah, no, 12 days. [12:14] antimony can be sorted by a mass purge of daily builds, I imagine [12:15] elmo: also you could do an archive pass on /srv/cdimage.ubuntu.com/old-images/, if skaet didn't already ask for it [12:15] 63G there [12:15] cjwatson: ok - I'll RT that - who should be notified when that's done, you + skaet? [12:15] please [12:16] initial publish-distro run in progress for natty [12:16] cjwatson: i-f-p still happy? [12:16] Hah. [12:16] yep, i-f-p completed [12:16] oddly quiet by comparison with the VERY NOISY rest of LP scripts [12:17] (i.e. no output on successful completion) [12:17] jml: hm, though I notice that I said in 55211 that this wouldn't be a problem for normal non-released distroseries [12:17] evidently I was confused [12:18] Well, i-f-p is brand new. [12:18] or else it doesn't actually require the careful run and we've just been overparanoid for years ... [12:18] And less special than the publisher. [12:18] wgrant: *blink* [12:18] Hm? [12:19] i-f-p dates back to 2006 [12:19] It was largely rewritten a month or two ago. [12:19] ah, well, even so, it was always quiet [12:19] Ah. [12:19] not that I'm complaining [12:19] The careful publisher is necessary to get -proposed, -updates, -security, -backports indices. [12:21] * cjwatson notes that in the bug [12:24] (If not careful, it'll only publish indices for dirty pockets. And we don't copy non-RELEASE, so they'll be empty and clean.) [12:26] Has it made it into the domination phase yet? [12:27] I guess that should be quick. [12:34] it's done [12:34] Yay. [12:35] about four minutes from init to get into domination phase. when you asked it was in a-f. [12:35] just doing other checks before publishing partner [12:37] Hm, longer than I would have hoped. [12:37] can send you the log if you want [12:37] Nah. [12:37] If it worked, should be fine. [12:37] actually, I think I misrea. [12:38] +d [12:38] There should have been nothing empty, so the publishing phase (A) should have been a no-op. [12:38] 21 seconds to get to start of domination phase; domination took a bit under four minutes [12:38] Right. [12:38] That's about what I would have expected. [12:39] Domination should take < 20s, but that's a known issue. [12:39] packages were correctly not copied to partner; deleting that NRCP step [12:39] Excellent. [12:49] publishing partner [12:50] package sets were automatically copied over - thanks StevenK (IIRC), deleting that NRCP step [12:50] wgrant: a known issue you say? does it have a bug? [12:51] I like this business of processes getting shorter [12:51] jml: Bug 654372 [12:51] Launchpad bug 654372 in soyuz "Source domination is inefficient (affects: 1) (heat: 19)" [High,Triaged] https://launchpad.net/bugs/654372 [12:51] cjwatson: :) [12:51] Fix is easy, but I want to see if I can clean it up first. [12:51] Since temp tables make me sad. [12:52] wgrant: I agree with everything you just said. [12:52] publisher re-enabled [12:52] waiting for the first automatic run now [12:53] A couple of minutes past the hour, still? [12:54] :03 [12:57] lamont: can has new buildd chroots? [12:57] (for natty) [12:57] lamont: oh, you'll need to wait for the first publisher run to happen, I guess [12:57] Is there a reason we don't just copy the maverick ones across? [12:58] cjwatson: I have maverick release tarballs that claim to be natty [12:58] wgrant: they have sources.list entries, don't they? [12:58] lamont: that works [12:58] cjwatson: launchpad overwrites sources.list [12:58] cjwatson: They've been overridden since PPAs were introduced. [12:58] copying is fine then [12:59] * cjwatson updates the process [12:59] * lamont tosses tarballs nattywards [12:59] * lamont looks forward to his 5 day weekend [13:00] skaet: current status: steps 1-15 and 17 done (reload the process page if you haven't recently, since I deleted a couple of steps) [13:00] cjwatson: once the flood gates are open for a bit (like say next monday), I'll roll newer, shinier, less stale tarballs [13:01] natty done, tossing final-bits maverick tarballs in as well [13:01] cjwatson, ack, will reload. [13:01] doko: if you'd like to go ahead and upload new toolchain bits, they should at least not bounce now [13:02] NRCP does say to wait until the first normal run finishes. But that shouldn't matter for internal stuff. [13:03] cjwatson, have done first pass of the page updates UbuntuDevelopment, ReleaseSchedule, ArchiveAdmin. [13:03] also sent note off to rosetta [13:03] wgrant: it does, but for the upload queue I don't believe it matters [13:03] NRCP doesn't express parallelisable things very well [13:04] cjwatson: Ah, for the queue, no. [13:04] But even builds should work as soon as the chroots and careful publisher are done. [13:04] cjwatson, 18,28 in new page done. [13:04] 'k [13:05] queuebot should be looking at natty now [13:05] cjwatson: as long as you're tweaking, you could add a similar bullet to upload fresh tarballs for the just-released suite as well (makes ppa/whatnot builds slightly faster via smaller dist-upgrades) [13:05] * skaet breaking for lunch and to run an errand. [13:06] lamont: done [13:06] Erm. [13:07] lack of previous version is because rmadison isn't up to date yet [13:07] Ah, of course. [13:07] that'll sort itself out in a few hours [13:07] and the "New" bit there just means new in the queue [13:07] (as opposed to "Updated" which is "there was already a package in the queue, but now there's a newer version as well") [13:08] Right. [13:09] Package set memberships seem to have been correctly copied as well. This is good. [13:12] yep [13:42] updated archive reports to point to natty (step 19) [13:48] Er. [13:48] a.u.c has directories. [13:48] But no indices. [13:48] Ah, there now. [13:50] the official excuse is of course "just in case you need a package to check if the queues are working" [13:55] cjwatson: You might want to add a note that i-d-s -a probably won't be necessary in future, since it skips disabled archs. [13:58] oh, I'll just delete that bit in the process then, thanks [13:59] (YM i-f-p) [13:59] Er, yes, the method is iDS, but the script is still i-f-p. [14:00] merge-o-matic updated (step 20) [14:01] cjwatson: gcc-defaults and binutils waiting for approval [14:01] any ordering constraints? [14:04] wgrant: are you sure it skips them? I don't see that in InitialiseDistroSeries._copy_architectures [14:04] cjwatson: That bit wasn't CP'd, it seems. [14:04] It's definitely in db-devel. [14:05] So it will be there next time. [14:05] Bug #649717 [14:05] ok, I was looking in devel, didn't know it was behind db-devel [14:05] Launchpad bug 649717 in soyuz "InitialiseDistroSeries should not copy disabled DASes (affects: 1) (heat: 6)" [Undecided,Fix committed] https://launchpad.net/bugs/649717 [14:06] Confusingly, production and db-devel have DistroArchSeries.enabled, but devel doesn't. [14:06] Since it was a late patch at the end of last cycle. [14:07] ok, process edited [14:08] doko: sorry, not sure you saw that was directed at you - does it matter if gcc-defaults and binutils build in paralle? [14:08] parallel [14:09] I'm not sure how it wasn't CPd, though. It was in production-stable before my thing to not publish disabled indices was CPd :( [14:12] cjwatson: no [14:13] cjwatson: sorry, distracted with the ac100 ... [14:27] ok, accepted, thanks [15:34] doko: anything else after binutils, gcc-defaults, and the eglibc copy? [15:35] cjwatson: you'll get gcc-4.4, gcj-4.4 and gnat-4.4 in a few minutes. for 4.5, I'll have to merge tomorrow's linaro release first. [15:35] it should be ok to continue with the toolchainish bits [15:35] ok. I didn't understand your last sentence though? [15:36] debhelper, perl, cdbs, dpkg, etc [15:36] autoconf/automake [15:37] oh, right [15:44] doko: does gcc-4.4 need to wait for armel to finish with binutils? [15:45] cjwatson: no [15:45] ok, accepted [15:45] cjwatson: preparing base-files. should issue mention 11.04, or something else? [15:46] I already uploaded base-files [15:46] ("Ubuntu natty (development branch)" is the standard form) [15:46] ahh, ok [15:47] if you want to review/accept it from the queue, that would be good [15:47] not that the different-reviewer protocol really matters at this point, the freeze is just for ordering purposes [15:47] * cjwatson starts on dpkg [16:22] * skaet back from picking up her Toshiba AC100 :D, and wondering what still needs doing? [16:23] cjwatson, which tasks are left? [16:24] release natty :) [16:24] lol [16:24] quickly, before we add any bugs [16:24] Riddell, in about 6 months ..... [16:26] and there's a few bugs there today (or so maverick's release notes indicate ;) ) [16:28] skaet: we're in the middle of step 21, which is mostly on doko [16:29] cjwatson, anything I can do to help with the reports? [16:31] which reports? [16:35] jml: any progress on the branch creation? [16:35] cjwatson: slow progress. [16:36] cjwatson: in 45 mins I'll be in a position to ask for a cherry pick, once the cherry pick is done, I'll be in a position to create the branches. [16:37] will anything break if I push stuff to lp:ubuntu/natty/SOURCEPACKAGE in the meantime, for things I'm working on? [16:39] cjwatson: I don't know. Give me a moment in which to educate myself enough to guess. [16:42] cjwatson: probably not. [16:50] hm, I bet the short name (ubuntu/natty/SOURCEPACKAGE) as opposed to the long name (~ubuntu-branches/ubuntu/natty/SOURCEPACKAGE/natty) doesn't exist yet, though? [17:03] cjwatson, ..."modify various reports (britny, anastacia, jessica) to point to new distroseries [17:04] oh that's done [17:04] (and reload the process page, since I updated the names ...) [17:05] there's a lot of stuff that's basically really quick s/maverick/natty/g in a bunch of places; those ones require cocoplum access [17:09] done step 26 (the cdimage stuff) - a lot of the later steps are parallelisable [17:10] merges.ubuntu.com seems to be working broadly as expected - I think [17:10] hmm, I can't seem to access cocoplum, should I have access? [17:10] or do I need to wait to qualify for some group for that? [17:10] no, but we should get you that RSN [17:11] I've done 28 already earlier. [17:12] RT sent to get you archive access [17:14] thanks... editing through the ArchiveAdministration page helped explain some of the things I had questions about. ;) [17:15] right, that doubles as the page every new archive admin gets to read as part of training [17:15] ... and traditionally, also edit to fix any inadequacies :) [17:23] heh, when I have access, will do the (now standard) read, review and clarify the ambiguities ;) [17:30] ubiquity intro message restored for next upload (step 30) [17:31] \o/ [17:31] I'll start working through the bugs that needed to be release noted then, and get them targeted to Natty. Should I am to milestone them for Alpha 1, so we don't loose focus? [17:32] or just release target them, and let teams set milestones? [17:37] cjwatson, all is good with the scripts to start generating natty_probs.html and natty_outdate.html? [17:42] * skaet needs to change locations. Back on line after dinner. [17:45] skaet: yep, those scripts are running [17:45] http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html [17:46] skaet: release-noted bugs> I think some discretion is probably called for depending on the nature of the bugs ... [17:46] for nasty ones, alpha-1 seems a good idea [17:48] cjwatson, fair 'nuf. I was planning on reading each anyhow, so will be selective with the alpha-1 milestoning. [17:49] release-targeting is definitely right either way