[01:26] <ScottK> slangasek: kde-workspace got missed.  (or maybe infinity)
[01:26] <slangasek> blast
[01:26] <slangasek> fixing
[01:26] <ScottK> Thanks.
[01:27] <slangasek> sorry, must've been highway hypnosis while reading http://people.canonical.com/~ubuntu-archive/pending-sru.html
[01:27] <ScottK> Easy enough.  There are a lot of them.
[02:15] <cjwatson> rah, API removals work
[02:16]  * cjwatson commits a new remove-package client
[02:16] <cjwatson> so that should be usable by non-Canonical archive admins now
[02:21]  * ScottK smiles.
[02:29] <cjwatson> shows up in exactly the same way in +publishinghistory as old removals; no longer possible to override the remover name, but that's probably a good thing
[02:29] <cjwatson> (if you're removing on behalf of somebody else, you can name them in the comment)
[02:30] <ScottK> Nice.
[02:31] <cjwatson> fixing up the reports and ancillary stuff now
[02:37] <cjwatson> please update lp:ubuntu-archive-tools if you're doing anything remotely related to removals
[02:37] <cjwatson> I'll be removing the old facilities on cocoplum soon
[02:37] <cjwatson> (this is way faster too, actually)
[02:39] <cjwatson> ArchiveAdministration updated
[02:45] <infinity> cjwatson: Faster is nice.
[02:46] <cjwatson> mostly because it doesn't do stupid locking
[02:46] <cjwatson> and probably also the execute_zcml_for_scripts crap
[02:50] <cjwatson> Maybe depends how you define faster.  It's slower if you run it on lots of packages at once, at the moment.  Probably some optimisation potential.
[02:50] <cjwatson> Startup time is better.
[02:51] <cjwatson> Minor semantic change: it's no longer possible to remove source without removing binaries built by that source too (I believe that check is safe against binaries being taken over by other packages).  This is probably good.
[03:16] <ScottK> cjwatson: I noticed in the diff for your last ArchiveAdministration page update that neither of the people listed as reviewers for Partner packages work for Canonical anymore.
[03:17] <cjwatson> Yes, I was meaning to do something about it as soon as I figured out who the replacements should be.
[03:17] <cjwatson> bdmurray: your sru-report changes are live
[03:18] <cjwatson> (as of the next run)
[03:21]  * cjwatson decommissions the last traces of the old ssh cocoplum sync-backend hac
[03:21] <cjwatson> k
[03:21] <cjwatson> nothing in ubuntu-archive-tools depends on ssh access any more
[03:22] <cjwatson> (which is not to say there aren't still Canonical-only tools, there just aren't annoying tentacles between the two worlds any more)
[03:23] <ScottK> cjwatson: If you have a bit of spare context, would you please accept qt4-x11 from binary New for me?  I've reviewed it and I think it's fine, but libqt4-dev-bin needs an override to Main and I don't think I can do that without overriding all the Universe binaries to Main too.
[03:23] <cjwatson> You can't yet, no
[03:24] <cjwatson> My somewhat terrifying http://paste.ubuntu.com/1015825/ would permit that but needs to be redesigned
[03:25] <cjwatson> Actually maybe it wouldn't yet
[03:25] <cjwatson> I don't have an override-one-binary thing hooked up yet
[03:26] <ScottK> No rush.  It doesn't actually come up that often and if I'm in a real rush, I just override everything and let component mismatches sort it later.  Not ideal, but it works.
[03:27] <cjwatson> ScottK: I've done the override for you - go ahead and accept it
[03:27] <ScottK> Thanks.
[03:34]  * cjwatson confirms by example (libextlib-ruby) that the way the API form of requestDeletion auto-removes binaries on source removal is safe against binaries being taken over by other sources
[09:27] <ogra_> infinity, haha, so you flipped the behavior with the lve builder fix, now all subarches but ac100 build
[12:41] <cjwatson> I'd appreciate thoughts on https://bugs.launchpad.net/launchpad/+bug/1006871
[12:41] <ubot2> Launchpad bug 1006871 in launchpad "Copying packages to -updates always goes through unapproved queue, even when copying user is privileged" [Undecided,New]
[13:07] <Daviey> cjwatson: I see you added the squashfs et al features to live-installer udeb.. what is left to do?
[13:09] <Daviey> (i'd quite like A1 to be squashfs based.. and don't mind doing the work, but guidance on what is to be done would be appreciated)
[13:14] <infinity> ogra_: I'll look at that when I'm less drunk. :P
[13:15] <doko> the evening just did start ...
[13:15] <ogra_> infinity, no hurry really, i can live with ac100 missing A1
[13:16] <infinity> doko: We got an early start.
[13:38] <xnox> infinity: well done =)
[13:39] <xnox> doko: make sure infinity doesn't do this: http://xkcd.com/364/
[14:15] <cjwatson> Daviey: I'm really tired and I'm not sure I'm coherent; but a rough estimate is that you need to (a) change livecd-rootfs/live-build/auto/config to pare back the ubuntu-server squashfs to just the base system (+ maybe standard) rather than assuming that it's OK to install grub as well, since d-i probably isn't smart enough to deal with removing packages in the case of needing an alternative; (b) make whatever adjustments ...
[14:15] <cjwatson> ... to the seed structure and cdimage/bin/list-seeds and so on are needed to get the right sets of packages in the right places; (c) tell cdimage to use CDIMAGE_LIVE=1 for server builds; (d) almost certainly a load of other stuff like fiddling with tools/boot/quantal/boot-*
[14:16] <cjwatson> Daviey: I suspect the simplest answer is actually to build a test image with DEBUG=1 set in the environment (so that cdimage doesn't publish it), copy it off nusakan directly, and iterate until it works
[14:17] <cjwatson> hmm, you have to choose between bootstrap-base and live-installer, I think, which will be seedily awkward
[14:17] <cjwatson> perhaps a temporary cdimage hack to sed the seeds
[14:18] <cjwatson> it shouldn't be *that* hard, but finding all the stuff you need to change up-front is nearly equivalent to doing the work :-)
[14:24] <Daviey> cjwatson: that i plenty to get me started, appreciated
[14:25] <cjwatson> cool - look at how the other live images are done for general structure, obviously
[14:26] <Daviey> right
[14:53] <cjwatson> slangasek: accepted rpcbind, but I may have to remember to override it to standard in -proposed, depending on what LP does with it; hopefully I'll remember around the right time
[14:55] <cjwatson> slangasek: actually, rpcbind is a separate source package from nfs-utils - would you mind fixing up the bug tasks on bug 863741 to something that makes sense and will cause things to be properly Fix Released on -> -updates?
[14:55] <ubot2> Launchpad bug 863741 in nfs-utils "apt doesn't want to replace portmap with rpcbind on upgrade" [Medium,Fix committed] https://launchpad.net/bugs/863741
[14:55] <cjwatson> I only noticed after manually setting to Fix Committed *why* I'd had to do that
[15:03] <scott-work> not sure this is the right place, but i am being asked by leann (kernel team) to provide download information for ubuntu studio. can anyone offer suggestions on where i might gather such information?
[15:03] <scott-work> i imagine that i cannot accurately track torrent downloads, however i presume that cd image downloads would be acquirable
[15:04] <cjwatson> you'd have to ask Canonical sysadmins; try #canonical-sysadmin to start with
[15:04] <Daviey> scott-work: is cd image your primary mirror network?
[15:05] <Daviey> http://ubuntustudio.org/downloads no precise?
[15:05] <Daviey> (and brokem images?)
[15:06] <scott-work> cjwatson: thank you for the information. how are you today?
[15:07] <cjwatson> sleepy.  woke up at 1:30am, back to sleep at 5am, up again around 8:30am.
[15:07] <scott-work> Daviey: yes, the cd image is our primary mirror network, to my knowledge it is our only mirror
[15:07] <cjwatson> so kind of drifting in and out of sanity
[15:07] <scott-work> Daviey: that website is suffering incredible bitrot and is in process to be replaced, although i did update the home page to reflect precise's release and link
[15:07] <scott-work> cjwatson: hehe, some maintain that state without a lack of adequate sleep
[15:09] <slangasek> cjwatson: bug tasks fixed, thanks
[15:11] <slangasek> cjwatson: could I ask you to have a look at the update-notifier in -proposed?  The bug that's verification-needed seems unlikely to get it for at least another week, but the other bugs are all fairly high-priority; would you like me to back out that change, or do you think it can be promoted as-is?
[15:14] <cjwatson> slangasek: How well do you think testing for the other three bugs will have covered at least regression-testing here?
[15:15] <bdmurray> cjwatson: I updated my ubuntu-archive-tools branch / merge proposal and tested it on lillypilly
[15:15] <cjwatson> bdmurray: in response to pitti's comments?
[15:15] <cjwatson> bdmurray: I already fixed it
[15:15] <bdmurray> cjwatson: yes
[15:16] <cjwatson> sorry, I should have mentioned on the MP
[15:16] <bdmurray> oh, okay
[15:17] <cjwatson> I took a rather more sledgehammer approach in case there were other things using len()
[15:18] <slangasek> cjwatson: it would be incomplete regression coverage, since the code in question only triggers when someone has a hook failing for three days consecutively... however, any possible regression is low-impact as a result
[15:18] <slangasek> sorry, no
[15:18] <slangasek> the code triggers the second time you run the hook and it fails
[15:18] <slangasek> but the impact of a regression is either marking a failing hook as a permanent failure when it shouldn't, or vice-versa
[15:19] <cjwatson> Is it not possible to fiddle the system time to test this fairly quickly?
[15:21] <slangasek> or to timestamp in the past, sure :)
[15:21] <slangasek> I can do a quick test then
[15:21] <cjwatson> I think it'd be worth *somebody* trying, even if not Loic
[15:53] <stgraber> I know the bug report is rather long and confusing but from what I can see libgcrypt11 should be copied to -updates in precise
[15:54] <stgraber> it's been in the queue for 13 days and has been verified for precise (though not shown in the report as the bug affects multiple releases)
[17:44] <skaet> doing a survey of the blueprints, and some scrubbing is clearly needed.
[17:46] <Daviey> skaet: the feature reaper ?
[17:46] <skaet> Daviey,  gap analysis anyway.
[19:08] <ScottK> cjwatson: Removals definitely work with mere mortal archive-admin privileges: https://launchpad.net/ubuntu/+source/plasma-widget-daisy/+publishinghistory - Thanks again.
[19:09] <slangasek> cjwatson: fwiw I've set the rpcbind priority now
[19:12] <tkamppeter> cjwatson, hi
[19:44] <cjwatson> ScottK: yay
[19:44] <cjwatson> slangasek: cool, thanks
[19:44] <cjwatson> tkamppeter: I'm in the pub, can't do anything complicated right now :)
[19:50] <ScottK> skaet: Is pitti still the right person for the size limit work item?
[19:51] <skaet> ScottK,  I think its been decided already,  will ask tomorrow in the meeting.   seb128 should know.   Will adjust after I hear back.
[19:58] <tkamppeter> cjwatson, OK, will contact you tomorrow.
[20:02] <cjwatson> tkamppeter: if it's for SRU handling, there are other SRU/archive-admin types around
[20:03] <cjwatson> ScottK: FWIW process-removals.py can mirror Debian removals in bulk or individually (-s pkg)
[20:03] <ScottK> Good to know.
[20:03] <cjwatson> does require some care
[20:03] <ScottK> No doubt.
[20:04] <cjwatson> I tend to think hard about things with Ubuntu modifications
[20:04] <ScottK> That one hasn't actually been removed yet, but it was a good opportunity for a test.
[20:04] <cjwatson> Ah
[20:05] <ScottK> I figured I'm the case of the least privilege for which a removal ought to succeed, so it was worth verifying.
[20:07] <cjwatson> I made some progress on queue today (was too sleepy to work on what I was actually supposed to be doing).