[09:41] <iulian> queuebot is alive!
[09:44] <cjwatson> excellent
[09:45] <wgrant> How does queuebot work?
[09:45] <wgrant> There's no convenient interface.
[09:45] <wgrant> Unless it runs queue frequently.
[09:46] <cjwatson> there's a horrible cron job on cocoplum that runs queue frequently and publishes it to http://people.canonical.com/~ubuntu-archive/queue/
[09:46] <wgrant> aHA.
[09:46] <cjwatson> I would be more than happy to replace it with API access if it existed ;-)
[09:46] <cjwatson> (nowadays, it caches the downloaded files from the queue to avoid hammering LP too much)
[09:47] <wgrant> Yeah... the API is slow, but not as slow as queue.
[09:47] <cjwatson> publish-queue runs once every two minutes; for some reason queuebot then checks once a minute
[09:47] <cjwatson> queuebot itself is in lp:ubuntu-archive-tools as ubuntu-release-bot
[09:47] <wgrant> The API almost exposes enough.
[09:47] <wgrant> But not quite.
[09:47] <cjwatson> everything except the password
[09:48] <wgrant> Can't get the source name out of a PackageUpload.
[09:48] <cjwatson> if that's ever fixed, let me know and I'd be happy to rewrite queuebot to use it
[12:05] <Daviey> Hi friendly release team!  I wondered on the possibility of bug 631103 getting a FFe.  The regression potential seems kinda low, the patch was proposed well before FF; but seems he was let down by the sponsoring system.  Screencasts users seem to depend on this feature, which is a regression from Lucid.
[12:05] <ubot4> Launchpad bug 631103 in ffmpeg (Debian) (and 1 other project) "[patch] maverick ffmpeg "Unknown input format: 'x11grab'" (affects: 6) (heat: 32)" [Unknown,Unknown] https://launchpad.net/bugs/631103
[13:06] <doko> cjwatson, pitti: May I accept these 'build1' no change uploads?
[13:08] <cjwatson> doko: yes, go ahead
[14:29] <iulian> Daviey: Stefan has just approved it.
[14:30] <Daviey> great!
=== bjf[afk] is now known as bjf
[16:51] <doko> cjwatson: looking at component-mismatches:
[16:51] <doko> libcrypt-des-ede3-perl: libcrypt-des-ede3-perl
[16:51] <doko>    [Reverse-Build-Depends: libcrypt-cbc-perl]
[16:52] <doko> libcrypt-des-perl: libcrypt-des-perl
[16:52] <doko>    [Reverse-Build-Depends: libcrypt-cbc-perl]
[16:52] <cjwatson> stuff in that section requires an MIR
[16:52] <doko> libcrypt-rijndael-perl: libcrypt-rijndael-perl
[16:52] <doko>    [Reverse-Build-Depends: libcrypt-cbc-perl]
[16:52] <cjwatson> if there's been an MIR, then they can be promoted
[16:52] <doko> well, asac and I think this is a circular b-d which can be demoted
[16:53] <cjwatson> uh
[16:53] <cjwatson> no, germinate wouldn't see if it were purely circular.
[16:54] <cjwatson> libcrypt-blowfish-perl build-depends on libcrypt-cbc-perl
[16:54] <doko> libcrypt-cbc-perl b-d on libcrypt-blowfish-perl
[16:54] <cjwatson> that's not why
[16:54] <cjwatson> libcrypt-blowfish-perl is in the supported-development-common seed
[16:54] <doko> the  libcrypt-blowfish-perl  b-d on libcrypt-cbc-perl
[16:55] <doko> ahh, ok
[16:55] <cjwatson> without a particularly good reason apparently, so if you think it can be removed, feel free
[16:55] <cjwatson> :q
[16:55] <cjwatson> oops
[16:55]  * cjwatson checks bzr blame quickly
[16:55] <cjwatson> been there since revision 1, no explanation
[16:56] <cjwatson> go ahead and unseed it if you like
[16:56] <doko> ok
[16:56] <doko> cjwatson: do the current Binary only promotions to main look ok to do?
[16:57] <cjwatson> anyway, it may be useful to know that it's impossible for promotions to be purely due to circularity; that script doesn't care what's currently in main, but rather it looks at the seeds and decides what should be in main, and then compares
[16:57] <doko> ok
[16:57] <cjwatson> kubuntu-mobile may not be workable yet
[16:58] <cjwatson> the others should be fine
[16:58] <cjwatson> assuming that they aren't listed as reverse dependencies of something in the top section
[17:00] <doko> well, linphone-dev is, but the source already is in main
[17:27] <sistpoty|work> [continue from -meeting]: ah, there: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-April/000701.html
[17:29] <cjwatson> I suspect Mozilla should be updated since asac is doing Linaro now; the others look OK from my memory
[17:29] <cjwatson> of course that's "up until FinalFreeze"
[17:29] <cjwatson> so it's probably kind of moot now
[17:29] <sistpoty|work> oh, heh, right
[17:30] <cjwatson> of course this is quite a long final freeze this time round
[17:30] <cjwatson> so I expect we'll have a lot of exception requests to deal with ...
[17:30] <sistpoty|work> and we used to have a later date for final freeze in universe than in main for lucid
[17:31] <cjwatson> oh yes, well, I think in practice that's still the case isn't it?
[17:31] <cjwatson> we're just unable to freeze the archive separately
[17:31] <sistpoty|work> I think so, yes
[17:33] <sistpoty|work> (otoh, I can't really tell, as I can't shove packages through the queue)
[17:36] <skaet> sistpoty|work, will you be handling the issueing of the delegation note,  or should it come from robbiew at this point?
[17:37] <robbiew> I'm sure sistpoty|work can handle it
[17:38] <chrisccoulson> on the subject of freezes and mozilla, cjwatson, what is the chances of me getting a new package in to universe at this stage? (well, resurrecting an old one to be more precise)
[17:38] <chrisccoulson> bug 531867
[17:38] <ubot4> Launchpad bug 531867 in iceowl (Debian) (and 1 other project) "[FFe] [needs-packaging] Lightning 1.0 Beta for Thunderbird 3 (affects: 95) (dups: 5) (heat: 357)" [Unknown,Unknown] https://launchpad.net/bugs/531867
[17:38] <skaet> robbiew, agree.   just making sure I understand where it should be coming from.
[17:39] <cjwatson> chrisccoulson: it'll depend on whether somebody has time to review it; it won't be the most urgent thing on anyone's list, I think
[17:41] <sistpoty|work> skaet, robbiew: can do... maybe we should also define a date for final freeze for universe? how about 4th october?
[17:42] <robbiew> sistpoty|work: have we done that in the past...I can't remember
[17:42] <sistpoty|work> robbiew: yes
[17:43] <robbiew> I think the 4th is a good date then
[17:43] <sistpoty|work> robbiew: https://lists.ubuntu.com/archives/ubuntu-release/2010-April/000044.html
[17:43] <robbiew> week from release
[17:51] <ScottK> sistpoty|work: I think it can be later than that.
[17:51] <sistpoty|work> ScottK: what do you suggest?
[17:51] <ScottK> sistpoty|work and robbiew: I'd check with slangasek to be sure, but I think that we can go up to ~36 hours before release.
[17:51] <ScottK> Err.
[17:51] <ScottK> Let me step back.
[17:52] <ScottK> That should be the deadline for no more uploads at all.
[17:52] <cjwatson> grr, wubi regression
[17:52] <ScottK> I think final freeze two days before that is sufficient.
[17:52] <cjwatson> that would be my fault then :-/
[17:53] <sistpoty|work> ScottK: that would be october 6 or 7?
[17:55] <robbiew> let's do the 6th then
[17:55] <ScottK> robbiew: Noon UTC on the 6th?
[17:55] <robbiew> sounds good to me
[17:56] <robbiew> ScottK: can you shoot an email to u-d-a announcing that?
[17:56] <ScottK> Final, final upload deadline for unseeded uploads is Noon UTC on the 9th.
[17:56] <ScottK> Yes.
[17:57] <ScottK> robbiew: I'd like to hear fro slangasek first to make sure he thinks that's sane.
[17:57] <skaet> robbiew,  I'll go make the the necessary changes to the release checklists to reflect this for future.
[17:58] <robbiew> ScottK: sure...sounds reasonable
[17:58] <robbiew> as I'm not sure how much us releasing on a Sunday vs Thursday would affect things
[17:58] <ScottK> For unseeded packages I think it doesn't.  It's just tie for mirror sync.
[17:58] <ScottK> tie/time
[17:59] <ScottK> skaet: We are still in a bit of a learning process on when unseeded packages need to freeze.  It used to be that security uploads were managed outside soyuz and it took three days to do that, so that was the driver for cutting off uploads.  Now it's just time for mirror sync and I think 24 hours is sufficient for that.
[18:00] <ScottK> So I suggested setting the final package upload deadline at 36 hours prior to the start of release day to give us 12 hours to fix any last minute OMGWTFBBQ type problems.
[18:00]  * ScottK pokes at slangasek some more.
[18:01] <skaet> ScottK, sounds good.   Will add that, unless slangasek has new input.
[18:01] <astraljava> Q: Our project lead seems to be unavailable for release delegate meet about to happen on #u-devel, is it possible for me to fill in temporarily?
[18:02] <ScottK> astraljava: What project?
[18:02] <astraljava> ScottK: Ubuntu Studio.
[18:02] <ScottK> Sure
[18:02] <ScottK> sistpoty|work: ^^^
[18:02] <astraljava> ScottK: Thanks :)
[18:02] <slangasek> ScottK, skaet: sounds sane to me
[18:03] <ScottK> skaet and robbiew^^^
[18:03] <slangasek> ScottK: fwiw, I think part of the reason for freezing with some lead time is to give us some slack in the event of buildd problems in that window
[18:03] <sistpoty|work> astraljava: ScottL just pinged me on -devel
[18:03] <robbiew> ScottK: ack
[18:03] <astraljava> sistpoty|work: Ok good, scratch that. :)
[18:03] <sistpoty|work> :)
[18:04] <slangasek> 36-hour cutoff gives us a full day to find and fix any buildd issues that would otherwise cause the just-uploaded source package to not have matching binaries in the release
[18:06] <skaet> slangasek, ScottK:  fair enough.   thanks.
[18:06] <ScottK> Point of clarification: Does this apply just to unseeded Universe/Multiverse packages or to any package that doesn't appear on an ISO?
[18:06] <ScottK> There are Main packages that also aren't on an ISO?
[18:06] <sistpoty|work> we used to keep main separate for lucid
[18:06] <ScottK> slangasek: ^^^ thoughts?
[18:06] <ScottK> Right, but I'm not sure we need to.
[18:07] <ScottK> It's the fact that packages are on an ISO that drives the earlier deadline not that they are in Main.
[18:07] <cjwatson> this is true, though I wonder whether it's worth the extra effort of deciding
[18:08] <ScottK> I consider it as something to think about as we evolve towards the archive reorg plan.
[18:08] <ScottK> Any time we say "Main" or "Universe" we ought to be thinking about if we really should be or not.
[18:08] <slangasek> ScottK: I think that's the release manager's call... I always went with "unseeded universe/multiverse" intentionally, rationale being that any package in main, on an ISO or not, has a greater risk of breaking the build for something that *is* on an ISO, and all has to be buildable at release-time so that it gets security support
[18:09] <ScottK> slangasek: OK.  That makes sense.
[18:10] <ScottK> skaet: ^^^
[18:10] <robbiew> I like this approach
[18:11] <robbiew> going with "unseeded universe/multiverse"
[18:11] <skaet> I'll defer to those with experience ;)
[18:11] <skaet> sounds reasonable to me as well though.
[18:12] <robbiew> ok, so as "Acting Release Manager" I would like to go with "unseeded universe/multiverse", because I'm always scared about breaking the ISO :)
[18:13] <skaet> lol
[18:13] <robbiew> ...but I'm not scared to do re-spins the day of release :P
[18:14]  * skaet rolls her eyes, and looks forward to london.
[18:17] <ScottK> OK.  Drafting it up.
[18:23] <doko> cjwatson, ScottK: may I have permission for an OOo upload this weekend (and accept it), build is done on i386, but I'd like for the armel test build to finish before I upload
[18:23]  * ScottK defers to cjwatson.
[18:25] <cjwatson> we're far enough out that OOo isn't much of a problem, but it would still be better if upload/accept were by different people
[18:25] <cjwatson> speaking of which, I'd appreciate somebody reviewing my initramfs-tools upload :-)  that fixes at least part of what's wrong with Wubi right now
[18:26] <doko> ok, I'll try to ping somebody
[18:26] <cjwatson> I'll be around at some point over the weekend I'm sure
[18:27] <doko> is the php5/netcat component mismatch a bug in the tool?
[18:28] <cjwatson> why would it be?  php5 Build-Depends: netcat
[18:29] <doko> and netcat-openbsd is in main, providing netcat
[18:29] <cjwatson> ah, well, real packages usually win
[18:30] <cjwatson> easiest fix would be to have php5 Build-Depends: netcat-openbsd | netcat, indicating a preferred alternative
[18:31] <doko> we patch it anyway, so I'll change that
[18:34] <doko> $ queue diff initramfs-tools|less
[18:34] <doko> Initialising connection to queue new
[18:34] <doko> Running: "diff initramfs-tools"
[18:34] <doko> Unknown Action: diff
[18:34] <doko> Aborting current transaction
[18:34] <cjwatson> lp:ubuntu-archive-tools ./queuediff -s maverick initramfs-tool
[18:34] <cjwatson> +s
[18:34] <ScottK> robbiew: Sent.  So it should be in the moderation queue.
[18:40] <doko> o python3-stdlib-extensions: python3-gdbm python3-gdbm-dbg python3-tk python3-tk-dbg
[18:40] <doko>    [Reverse-Depends: Rescued from python3-stdlib-extensions, idle3, python3-gdbm-dbg]
[18:40] <doko> cjwatson: ^^^ ok to promote with source? python3 versions
[18:41] <cjwatson> doko: I think those are fine since they're just python3 versions of stuff already in main for python2
[18:41] <doko> ok
[18:44] <doko> cjwatson:  initramfs-tools, the change ignores errors, so it shouldn't have sid effects
[18:45] <cjwatson> sid effects?
[18:45] <cjwatson> oh, side-effects, right
[18:46] <cjwatson> yeah, -f was just in case some initramfs hook had already put /etc/mtab in there
[18:47] <doko> oops, sid effects =)
[19:31] <sistpoty> ok, I mailed everyone from the list of delegates where I don't have an ok yet :)
[20:29] <skaet> sistpoty, Thanks.  :)
[20:29] <sistpoty> yw
=== bjf is now known as bjf[afk]
=== mdeslaur_ is now known as mdeslaur
[22:15] <slangasek> ScottK: could I bother you to review that binutils upload for me?  Needed to let u-boot-linaro build with ~ in the upstream version number...
[22:15]  * slangasek takes a couple others for review
[22:15] <ScottK> Looking.
[22:24] <doko> plus vorbis-tools ...
[22:26] <ScottK> slangasek: Accepted.
[22:26] <slangasek> ScottK: ta
[22:26] <ScottK> doko: Yours too.
[22:26] <ScottK> You're welcome.
[22:29] <sistpoty> robbiew, skaet: btw, why aren't you a member of ubuntu-release?
[22:29] <robbiew> well...I'm only acting :)...don't want folks getting any ideas
[22:29] <robbiew> heh
[22:29] <sistpoty> pfft :P
[22:29] <robbiew> as for skaet...makes sense for her, but she needs to be an official Ubuntu member 1st ;)
[22:30] <robbiew> i'm sure she'll get there VERY soon :P
[22:30] <sistpoty> heh, ok... just would like to get reality reflected in launchpad *g*
[22:30] <skaet> heh
[22:51] <robbiew> sistpoty: feel free to add me (if you have the rights)...I won't mind ;)
[22:52] <sistpoty> robbiew: I fear you'll have to ask cjwatson for that (he's admin) ;)
[22:53] <robbiew> sistpoty: heh...I'm thinking I can get him to approve me :P
[22:54] <sistpoty> heh
[22:56] <cjwatson> "Colin, hate to tell you this, but you're fired.  Unless ..."
[22:56] <sistpoty> haha
[22:58] <robbiew> lol
[22:58] <sistpoty> so nice, that I'm from the community and can include *that* quote when sending the announcement about delegates: "robbiew: ...but I'm not scared to do re-spins the day of release :P"
[22:58] <cjwatson> so, I don't mind adding you for the duration you're acting; anyone mind?
[22:58] <robbiew> puhleeese...the last thing I'd do is threaten to fire cjwatson if he didn't give me MORE work/responsibility
[22:58] <cjwatson> hope you're scared to do respins the day of THIS release
[22:58] <cjwatson> given that nobody will be around ;-)
[22:59] <sistpoty> haha
[22:59] <robbiew> heh...well, technically all we have to do is switch the website on sunday
[22:59] <robbiew> we can have it ready before then ;)
[22:59] <slangasek> ready and published? :)
[22:59] <cjwatson> mm, except for the way that's way more than just a single command ;-)
[22:59] <cjwatson> I suppose we could have it ready to run sync-mirrors
[22:59] <cjwatson> that might not be a hideously bad idea
[23:00] <robbiew> yeah...that's what I meant
[23:00] <cjwatson> we'd be committed at that point though
[23:00] <robbiew> have the ISOs done by Saturday
[23:00] <robbiew> hell..we could "release" Sunday at 00:00 UTC :)
[23:01] <robbiew> or 00:10:10 UTC for the fun of it
[23:01] <slangasek> nothing like trusting your release publishing to an at job
[23:01] <robbiew> who went with this stupid 10.10.10 sunday thing anyway
[23:01] <robbiew> lol
[23:17] <cjwatson> robbiew: added
[23:19] <robbiew> damn it...now I don't have an excuse to ignore doko's FFes
[23:19] <robbiew> :P
[23:20] <sistpoty> robbiew: that's your task list now: https://bugs.launchpad.net/~ubuntu-release/+subscribedbugs :P
[23:21]  * robbiew creates skaet's ubuntu membership page now
[23:21] <robbiew> (j/k)
[23:21] <sistpoty> haha
[23:22] <doko> sistpoty: how can you add to this list?
[23:22] <sistpoty> doko: subscribe ubuntu-release
[23:23] <sistpoty> doko: or did you mean ubuntu-release members?
[23:25] <sistpoty> (if the latter, I can't)
[23:47] <ogasawara> per bug 641618, can I get an archive admin to approve the linux package ^^
[23:47] <ubot4> Launchpad bug 641618 in linux (Ubuntu Maverick) (and 1 other project) "Maverick Kernel Freeze Exception (affects: 1) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/641618
[23:48] <doko> new kernel? hey, there wasn't even a new compiler upload ...