[02:29] <NCommander> sk
[02:30] <NCommander> wn 23
[02:30] <NCommander> argh
[08:41] <ogra_> cjwatson, does that look right ? http://paste.ubuntu.com/1058761/
[08:43] <ogra_> (or should the arm arches just be added to the bottom line of the file ?)
[08:44] <cjwatson> ogra_: No, better not, as that would affect all flavours.  That patch looks fine to me, except please sort the architecture names in the second chunk
[08:44] <ogra_> alphabetically ?
[08:44] <cjwatson> Yes
[08:44] <ogra_> k
[08:45] <cjwatson> (Well, I suppose we could override it in all flavours, but ARM is probably still sufficiently special that it's better not to I think)
[08:45] <ogra_> yeah, and flavours might not like the additional build time for their manual builds
[09:09] <jibel> quantal server and alternate failed to install automatically due to a warning. I filed bug 1017398
[09:09] <ubot2> Launchpad bug 1017398 in debian-installer "Quantal Server and alternate installation failed with error "Failed to retrieve InRelease"" [Undecided,New] https://launchpad.net/bugs/1017398
[09:12] <cjwatson> Thanks
[09:13] <cjwatson> Will fix once I have updated images handy
[10:13] <Daviey> hah, i was just about to look into that myself.. Super!
[10:23] <cjwatson> Yeah, sorry for delay, had a phone call, but on it
[10:28] <cjwatson> jdstrand: So, I'm tantalisingly close to having Archive.copyPackage work for you guys - not quite there as I missed a piece in what got deployed this morning (so don't try to use the shiny new unembargo=True flag yet as it won't work), but nearly
[10:28] <cjwatson> jdstrand: However, as it stands, the copies will land in the queue and require an archive admin to accept them, which I don't think will be acceptable
[10:29] <cjwatson> jdstrand: Do you think it would be sufficient for this to fix bug 648611 and grant ubuntu-security queue admin on the security pocket (which realistically is basically the current policy, just implemented extremely oddly), which would require you to manually accept the copies; or do I need to fix bug 1006871 somehow as well?
[10:29] <ubot2> Launchpad bug 648611 in launchpad "ubuntu-sru either have too much or too little permission as queue admins" [High,Triaged] https://launchpad.net/bugs/648611
[10:29] <ubot2> Launchpad bug 1006871 in launchpad "Copying packages to -updates always goes through unapproved queue, even when copying user is privileged" [Low,Triaged] https://launchpad.net/bugs/1006871
[10:32] <cjwatson> jdstrand: I'd like to kill off unembargo-package.py and the hack that lets you use Archive.syncSource ASAP, but obviously not at the cost of getting in the way of security updates
[12:02] <jdstrand> cjwatson: not looking super-closely at the bugs-- if 648611 allows us to use to maintain our autonomy, I think that is fine. I've already added some output to our script for approving things and that is acceptable (if a mild nuisance)
[12:02] <jdstrand> s/to use//
[12:03] <jdstrand> that could have been a clearer sentence. aiui, fixing 648611 should be enough
[12:11] <cjwatson> jdstrand: OK, thanks.  FWIW I do already have a branch up for review that adds sufficient API that the worst case would be that the script would have to poll for a minute or two until it can accept the copy for you
[12:12] <jdstrand> cjwatson: so, I have a libreoffice and oo.o update that I plan to push today. would you like me to try to use copyPackage on it?
[12:13] <jdstrand> cjwatson: (not for testing the unapproved bits, but the other parts)
[12:14] <cjwatson> jdstrand: No, you can't yet
[12:14] <jdstrand> ok
[12:14] <cjwatson> "not quite there as I missed a piece in what got deployed this morning", as above
[12:15] <cjwatson> The fix for that has been reviewed but needs to go through test suite, landing, QA, deployment
[12:15] <jdstrand> oh, I quickly read that 648611 was said piece
[12:20] <cjwatson> No, that one's separate
[12:21] <cjwatson> The bit that was broken was that my initial attempt had a bug which caused mail notifications to crash after the restricted files were unrestricted, because they were trying to get at uncommitted librarian files
[12:21] <cjwatson> So I'm moving the privacy update after mail notifications instead, since anything else is unspeakably cumbersome
[12:22] <cjwatson> If you try to use copyPackage(unembargo=True) right now it'll just crash when trying to run the copy job
[12:23] <jdstrand> I see
[12:23] <cjwatson> That'll hopefully be fixed by tomorrow, depending on buildbot runtime and such
[12:23] <jdstrand> cjwatson: thanks for all your work on this btw :)
[12:23] <cjwatson> np, I will get considerable LP LoC credit out of it ;-)
[12:23] <jdstrand> :)
[12:24] <cjwatson> Not to mention the ability to actually understand the copy code once it's about half the size
[12:24] <cjwatson> I'd be well up for you doing a test run once a fixed version is deployed; I guess that would at least be enough to remove unembargo-package.py, since you're only using that as a fallback right now
[12:26] <cjwatson> And we can keep Archive.syncSource around until you have more self-service queue admin
[12:26] <jdstrand> cjwatson: I'll be off Tu-Th, but feel free to ask mdeslaur to coordinate that with a member of my team
[12:26] <cjwatson> OK, cool
[14:34] <dobey> so, have we dropped the alpha freezes, or does the soft freeze happen at the end of today?
[14:38] <skaet> dobey,  switch over to using -proposed will happen later today
[14:38] <cjwatson> Where's the Launchpad branch for that?
[14:38] <dobey> ok
[14:38] <cjwatson> Or the ubuntu-archive-tools branch/commit
[14:38] <skaet> cjwatson,  thought we'd follow the same pattern as A1
[14:39] <skaet> issue?
[14:39] <cjwatson> Absent code to direct (a) auto-syncs and (b) uploads to -proposed, it'll be ineffective
[14:39] <cjwatson> This is in a relevant blueprint somewhere ...
[14:40] <cjwatson> The pattern for A1 was for people to upload to -proposed basically on the honour system, which sort of works some of the time but is not desperately effective and is certainly cumbersome
[14:40] <skaet> not as effective as we'd like,  but at least doesn't block some of the larger builds from progressing.
[14:40] <cjwatson> So as long as that's understood, fine
[14:40] <cjwatson> I thought you meant something stronger
[14:40] <skaet> no,  very much understand our infrastructure is not in place yet for that.
[14:40] <cjwatson> OK
[14:47] <cjwatson> Hah, I was just getting ready to QA that
[14:48] <cjwatson> less work for meeeee
[15:02] <Daviey> stgraber: In the ISO tracker, "Quantal Alpha 2" and "Quantal Daily" should both be in the Testing state, right?
[15:02] <Daviey> (I just created the A2 milestone)
[15:23] <stgraber> Daviey: yep. Whenever cron is disabled on nusakan and you start building new images, I usually mark the daily milestone as archived or released so people don't try and look for dailies when we aren't building them
[15:25] <Daviey> stgraber: ok, thanks.
[15:54] <ScottK> seb128: ^^^ How's that for service?
[15:57] <bjf> cjwatson, infinity, bug 1004556. who handles getting a package from -proposed to -updates?
[15:57] <ubot2> Launchpad bug 1004556 in linux-armadaxp "linux-armadaxp: 3.2.0-1603.6 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1004556
[15:59] <cjwatson> Periodic sweeps of pending-sru by archive admins
[16:00] <cjwatson> The fact that the previous upload didn't have a tracking bug broke our processes so you didn't get it done
[16:00] <cjwatson> Please include tracking bugs in future
[16:00] <bjf> cjwatson, ack
[16:00] <cjwatson> (In the changelog, that is)
[16:00] <bjf> cjwatson, ack
[16:02] <cjwatson> Looking now
[16:08] <seb128> ScottK, that's excellent, thanks a lot ;-)
[16:09] <cjwatson> bjf: Done
[16:09] <bjf> cjwatson, many thanks
[16:12] <Daviey> cjwatson: As bug 1017398 is fixed, re-spinning alternate and server make sense?
[16:12] <ubot2> Launchpad bug 1017398 in debootstrap "Quantal Server and alternate automated installation failed with error "Failed to retrieve InRelease"" [Undecided,Fix released] https://launchpad.net/bugs/1017398
[16:12] <cjwatson> Oh, sure
[16:13] <cjwatson> Running now
[16:13] <Daviey> oh, thanks.
[16:14] <Daviey> (I wasn't asking you to do it, just checking if it should now be done.. but thanks muchly for doing it)
[16:17] <cjwatson> I forgot you had nusakan access
[16:18] <Daviey> cjwatson: kindly forget for the rest of the week. :)
[16:20] <cjwatson> Ha
[16:20] <cjwatson> No chance mate :)
[16:21]  * xnox is reminded of the MIB red light tool
[16:27] <skaet> ev,  cjwatson - does it make sense to put out WUBI images this milestone?   looks like the same problem we had in A1 is still there. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1009564
[16:27] <ubot2> Ubuntu bug 1009564 in wubi "Quantal Ubuntu Wubi failed to install" [Critical,Confirmed]
[16:27] <skaet> Daviey, ^
[16:28] <Laney> ..
[16:28] <cjwatson> I have no opinion on the matter
[16:28] <Laney> err, no
[16:28] <cjwatson> One way to form an opinion might be to try to find out whether only jibel is affected or whether it's widespread
[16:28] <cjwatson> That bug only has one person marked as affected
[16:29] <ev> skaet: seems like more of a question for the kernel team. I'd rather not kick the can down the road, but I'm not sure how much is involved in fixing it.
[16:29] <skaet> balloons,  ^ do you know if anyone else has tested WUBI, and its not been makred.
[16:29] <ev> but I agree with cjwatson that we should first see how much of an issue it is.
[16:29] <balloons> not for alpha 2 to my knowlede
[16:30] <Daviey> I think it's reasonable to ship it for the Alpha series, with a Potentially known issue on the Release notes, requesting further confirmation. No?
[16:30] <balloons> although people weren't successful @ alpha 1
[16:30] <balloons> remember :-)
[16:30] <skaet> Daviey,   we didn't ship it for Alpha 1,  so getting more data right now seems prudent.
[16:30] <Daviey> If we withhold something that we think could have issues, then we won't get the exposure to confirm it.
[16:31] <skaet> balloons,  yeah its the alpha 1 data (or since then) we're trying to figure out about WUBI.   Was there any testing in last week's set?
[16:31] <balloons> to wubi, none to my knowledge
[16:31] <skaet> Daviey,  its more that if its still broke, and there isn't a fix likely, so we want to waste folks time....
[16:31] <balloons> typically have to go ask for that :-)
[16:32] <cjwatson> skaet: seems like we ought to verify the assumption in that first clause by getting somebody else to double-check
[16:32] <skaet> balloons,  can you see if we find someone to help double check if the issue is still there?
[16:32] <skaet> cjwatson,  yes
[16:33] <balloons> yes, I'll ask to have it looked @ again
[16:33] <skaet> thanks balloons
[16:38] <ogasawara> skaet: v3.5-rc4 was released yesterday and we've already rebased our Quantal kernel.  I'd like to squeeze in an upload in time for A2.  When would be the latest we could upload?  The reason I ask is there is also a bugfix for arm I'm told is getting addressed and should be fixed by tomorrow.  Would an upload tomorrow morning be too late?
[16:42] <skaet> ogasawara,  we'll switch over to using -proposed at 2100,  upload today would be better if possible, since the image testing will start tomorrow AM.   I suspect its going to be a case of upload when its ready, and we'll decide if we respin or not for it,  when its there.
[16:53] <skaet> ogasawara,  is there a bug number for the arm fix?
[16:59] <jibel> skaet, wubi r270 with disk image 20120625 is ok. Same system that was failing on A1.
[17:00] <jibel> I'll update and close the bug report
[17:04] <Daviey> ogasawara: can you comment if it's an ABI change?
[17:05] <ogasawara> skaet: ack, I'll check with ppisati for a bug# and let you know
[17:05] <ogasawara> Daviey: it will be an ABI bump
[17:08] <Daviey> If the kernel goes via -proposed.. cjwatson, we'll need a d-i no-change rebuild, right?
[17:27] <cjwatson> Daviey: Yes, though it doesn't strictly have to be in the same block migrated to release as the old ABI will stick around in NBS until d-i is done
[17:47] <xnox> if anything e2fsprogs update raises, please do not hesitate to get in touch with me
[19:04] <xnox> I would like some pieces of text to be included in the Apha 2 announce in relation to many updates in the filesystems stack
[19:04] <xnox> Where / How do I submit these for inclusion?
[19:06] <skaet> xnox,  please put them in the QuantalQuetzal/TechnicalOverview/Alpha2 wiki page
[19:07] <xnox> skaet: ok, thanks
[19:07] <xnox> skaet: it's not symlinked from the release schedule, will fix that as well.... unless it's done as an milestone release step on thursday?
[19:09] <skaet> xnox,  link didn't go in to schedule until after its released,  but with the recent changes (ie. we are using TechnicalOverview/Alpha2 rather than just TechnicalOverview),  we can do it now.   Its a good idea.
[19:09] <xnox> skaet: ok.
[19:21] <xnox> skaet: Please spell check / technical language check https://wiki.ubuntu.com/QuantalQuetzal/TechnicalOverview/Alpha2#Filesystem_Stack
[19:21] <skaet> xnox,  will do when I tak my next pass over it.   Thanks!  :)
[19:22] <xnox> skaet: you should subscribe to the page, to get spammed =))))
[19:23] <skaet> xnox,  usually do,  just hadn't remembered yet.  Thanks for the reminder, done.
[19:23] <skaet> :)
[19:25] <xnox> skaet: ok, I'm done now for the day. Good luck rick-rolling & spinning the cd bundle =)
[19:35] <bdrung> ScottK: desktop-file-utils is accepted in precise-proposed, but audacity not?
[19:36] <ScottK> bdrung: Yes.  Do they have to go together?
[19:39] <seb128> they don't, but having that specific issue resolved requires both sides
[19:39] <bdrung> ScottK: it make sense to combine them
[19:39] <seb128> it will not break anything having only desktop-file-utils though
[19:39] <seb128> d-f-u specify which handle to pick if there are several options
[19:39] <bdrung> seb128: but can it be tested without the patch for audacity?
[19:39] <seb128> the audacity part adds audacity as an option
[19:40] <ScottK> I had time to review one this morning and d-f-u was easy.
[19:40] <seb128> bdrung, by hacking locally the audacity .desktop yes ;-)
[19:40] <seb128> ScottK, that was still useful, the libreoffice bug has already been verification-done ;-)
[19:41] <seb128> the audacity one can be confirmed later, the update has to stay a week in proposed anyway
[19:41] <ScottK> Yeah.
[19:41] <ScottK> Actually the audacity one is pretty easy too.  Accepting.
[20:13] <ScottK> slangasek: speaking as a VERY new member of ubuntu-sru, I agree with your assessment about delegations.
[20:16] <slangasek> ScottK: ack
[21:37] <micahg> skaet: about the release announcement, shouldn't the stuff about making stuff uninstallable go before the other stuff in the list?  It seems to read that milestone bug fixes even if they make something uninstallable can go to the release pocket
[21:37]  * micahg forgot if he mentioned this last time
[21:41] <cjwatson> I assume that I should not run auto-syncs for a while
[21:41] <skaet> cjwatson
[21:41] <skaet> cjwatson,  yes that was going to be my request in the channel.
[21:42] <skaet> micahg,   I'll post the rules on the pad, and put it in the order you indicate there.
[21:42] <cjwatson> Easy enough to do
[21:43] <cjwatson> Or not to do
[21:43] <skaet> exactly.  :)
[21:43] <skaet> thanks cjwatson.