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