User1: User2 kde-workspace got missed.  (or maybe infinity)
User2: blast
User2: fixing
User1: Thanks.
User2: sorry, must've been highway hypnosis while reading http://people.canonical.com/~ubuntu-archive/pending-sru.html
User1: Easy enough.  There are a lot of them.
User3: rah, API removals work
 * cjwatson commits a new remove-package client
User3: so that should be usable by non-Canonical archive admins now
 * ScottK smiles.
User3: 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
User3: (if you're removing on behalf of somebody else, you can name them in the comment)
User1: Nice.
User3: fixing up the reports and ancillary stuff now
User3: please update lp:ubuntu-archive-tools if you're doing anything remotely related to removals
User3: I'll be removing the old facilities on cocoplum soon
User3: (this is way faster too, actually)
User3: ArchiveAdministration updated
User4: User3 Faster is nice.
User3: mostly because it doesn't do stupid locking
User3: and probably also the execute_zcml_for_scripts crap
User3: 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.
User3: Startup time is better.
User3: 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.
User1: User3 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.
User3: Yes, I was meaning to do something about it as soon as I figured out who the replacements should be.
User3: User10 your sru-report changes are live
User3: (as of the next run)
 * cjwatson decommissions the last traces of the old ssh cocoplum sync-backend hac
User3: k
User3: nothing in ubuntu-archive-tools depends on ssh access any more
User3: (which is not to say there aren't still Canonical-only tools, there just aren't annoying tentacles between the two worlds any more)
User1: User3 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.
User3: You can't yet, no
User3: My somewhat terrifying http://paste.ubuntu.com/1015825/ would permit that but needs to be redesigned
User3: Actually maybe it wouldn't yet
User3: I don't have an override-one-binary thing hooked up yet
User1: 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.
User3: User1 I've done the override for you - go ahead and accept it
User1: Thanks.
 * 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
User5: infinity, haha, so you flipped the behavior with the lve builder fix, now all subarches but ac100 build
User3: I'd appreciate thoughts on https://bugs.launchpad.net/launchpad/+bug/1006871
User6: Launchpad bug 1006871 in launchpad "Copying packages to -updates always goes through unapproved queue, even when copying user is privileged" [Undecided,New]
User7: User3 I see you added the squashfs et al features to live-installer udeb.. what is left to do?
User7: (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)
User4: User5 I'll look at that when I'm less drunk. :P
User8: the evening just did start ...
User5: infinity, no hurry really, i can live with ac100 missing A1
User4: User8 We got an early start.
User9: User4 well done =)
User9: User8 make sure infinity doesn't do this: http://xkcd.com/364/
User3: User7 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 ...
User3: ... 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-*
User3: User7 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
User3: hmm, you have to choose between bootstrap-base and live-installer, I think, which will be seedily awkward
User3: perhaps a temporary cdimage hack to sed the seeds
User3: it shouldn't be *that* hard, but finding all the stuff you need to change up-front is nearly equivalent to doing the work :-)
User7: User3 that i plenty to get me started, appreciated
User3: cool - look at how the other live images are done for general structure, obviously
User7: right
User3: User2 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
User3: User2 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?
User6: 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
User3: I only noticed after manually setting to Fix Committed *why* I'd had to do that
User3: you'd have to ask Canonical sysadmins; try #canonical-sysadmin to start with
User7: scott-work: is cd image your primary mirror network?
User7: http://ubuntustudio.org/downloads no precise?
User7: (and brokem images?)
User3: sleepy.  woke up at 1:30am, back to sleep at 5am, up again around 8:30am.
User3: so kind of drifting in and out of sanity
User2: User3 bug tasks fixed, thanks
User2: User3 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?
User3: User2 How well do you think testing for the other three bugs will have covered at least regression-testing here?
User10: User3 I updated my ubuntu-archive-tools branch / merge proposal and tested it on lillypilly
User3: User10 in response to pitti's comments?
User3: User10 I already fixed it
User10: User3 yes
User3: sorry, I should have mentioned on the MP
User10: oh, okay
User3: I took a rather more sledgehammer approach in case there were other things using len()
User2: User3 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
User2: sorry, no
User2: the code triggers the second time you run the hook and it fails
User2: but the impact of a regression is either marking a failing hook as a permanent failure when it shouldn't, or vice-versa
User3: Is it not possible to fiddle the system time to test this fairly quickly?
User2: or to timestamp in the past, sure :)
User2: I can do a quick test then
User3: I think it'd be worth *somebody* trying, even if not Loic
User11: I know the bug report is rather long and confusing but from what I can see libgcrypt11 should be copied to -updates in precise
User11: 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)
User12: doing a survey of the blueprints, and some scrubbing is clearly needed.
User7: User12 the feature reaper ?
User12: Daviey,  gap analysis anyway.
User1: User3 Removals definitely work with mere mortal archive-admin privileges: https://launchpad.net/ubuntu/+source/plasma-widget-daisy/+publishinghistory - Thanks again.
User2: User3 fwiw I've set the rpcbind priority now
User13: cjwatson, hi
User3: User1 yay
User3: User2 cool, thanks
User3: User13 I'm in the pub, can't do anything complicated right now :)
User1: User12 Is pitti still the right person for the size limit work item?
User12: ScottK,  I think its been decided already,  will ask tomorrow in the meeting.   seb128 should know.   Will adjust after I hear back.
User13: cjwatson, OK, will contact you tomorrow.
User3: User13 if it's for SRU handling, there are other SRU/archive-admin types around
User3: User1 FWIW process-removals.py can mirror Debian removals in bulk or individually (-s pkg)
User1: Good to know.
User3: does require some care
User1: No doubt.
User3: I tend to think hard about things with Ubuntu modifications
User1: That one hasn't actually been removed yet, but it was a good opportunity for a test.
User3: Ah
User1: I figured I'm the case of the least privilege for which a removal ought to succeed, so it was worth verifying.
User3: I made some progress on queue today (was too sleepy to work on what I was actually supposed to be doing).
ubuntu-release
Ubuntu IRC