[00:25]  * cjwatson wonders why there are packages in wheezy+sid and not in quantal with no DSDs
[00:51] <cjwatson> Laney,tumbleweed: I think we may have to keep the text file after all, at least in part; there are too many packages that don't have DSDs despite still being in Debian and I don't see how to blacklist them
[00:51] <cjwatson> maybe if I at least switch it out to an externally-accessible bzr branch somewhere
[00:54] <cjwatson> I fear that I cannot think of any better approach right now, short of even more LP hacking that I don't think I'll have time for
[00:58] <mdeslaur> someone might want to look into bug 990740
[00:58] <ubot2> Launchpad bug 990740 in python-defaults "upgrading from lucid to precise fails" [Undecided,Confirmed] https://launchpad.net/bugs/990740
[01:04] <slangasek> mdeslaur: key phrase there is 'Trying to "apt-get dist-upgrade"'
[01:04] <slangasek> so they're not using the release-upgrader apt
[01:06] <tumbleweed> cjwatson: hrm, if there are packages without DSDs, does that mean the autosyncer is going to miss things?
[01:06] <cjwatson> No, they're ones that have been removed from Ubuntu
[01:07] <tumbleweed> ah
[01:14] <slangasek> mdeslaur: ah, though I see comments further on claiming it still occurs with do-release-upgrade; looking further
[01:16] <slangasek> also, yay: Brian J. Murrell, the friendliest Ubuntu bug reporter
[01:19]  * cjwatson notes that nobody responded to my request for apport-collect information on that bug
[01:19] <cjwatson> ... as you just said
[01:19] <slangasek> ;)
[01:26] <slangasek> it might be that we need to fix this by making python2.7-minimal Conflicts: with the right version of python-minimal after all, instead of having a circular dep
[01:26] <slangasek> but we'll want to know why it's failing for others and not on jenkins
[01:27] <cjwatson> I was about to point Brian J. Murrell at jenkins and then noticed it was failing
[01:28] <slangasek> hmm
[01:28] <cjwatson> but I think that's a separate problem and one mvo knows about
[01:28] <slangasek> ok
[01:28] <cjwatson> induced by my attempts at python 3 porting I think
[01:28] <slangasek> dear firefox, if you insist on writing to disk every 30 seconds, the least you could do is remember to write the data that lets me use the awesome bar
[01:33]  * cjwatson gives quantal a shiny new ubuntu-keyring
[01:33] <cjwatson> at some point I may get around to all the SRUs and actually installing the keys ...
[01:33] <slangasek> :)
[01:35] <slangasek> still need to figure out why gpg won't let me sign the new cdimage key
[01:35] <slangasek> even though I've signed several other keys since then
[01:37] <cjwatson> ... you did and you mailed the signature to me
[01:37] <cjwatson> well, to cdimage@ubuntu.com
[01:37] <slangasek> orly
[01:37] <slangasek> well then
[01:37] <cjwatson> I imported it, the keyservers should have it; failing that, the new ubuntu-keyring does
[01:37] <slangasek> apparently that means something's broken in my main gpg config that's not broken in my caff config
[01:38] <cjwatson> I've lobbed it at keyserver.u.c again just in case
[01:38] <slangasek> just pulled it down from pgp.mit.edu... yeah, that's clearly me :)
[01:39] <cjwatson> you haven't signed the archive key AFAICS, not sure if you want to
[01:39] <slangasek> hmm - I intended to do that one too
[01:39] <cjwatson> if you used caff for it, I don't know if James got round to getting ftpmaster@ubuntu.com fixed to go somewhere
[01:42] <slangasek> aha, figured out the problem
[01:42] <slangasek> secret-keyring w/o no-default-keyring
[01:43] <slangasek> when the default keyring contains a signing subkey, you get an opaque "secret key parts are not available" error :P
[01:43] <slangasek> ok, archive key signed and pushed
[01:47] <cjwatson> [this is NOT encouragement for anyone who wasn't present when it was generated and/or has access to the master machines where they reside to go signing the new keys without appropriate knowledge]
[01:47] <cjwatson> cool, thanks
[03:46] <infinity> cjwatson: You know a bunch of randoms will anyway, they always do.
[03:53] <infinity> cjwatson: As for external-bzr-branch-for-blacklists, it's not like there isn't already precedence for LP pulling in a text file from bzr on a cron job (P-a-s), though I'm not sure precedence makes it a good idea. :P
=== yofel_ is now known as yofel
[12:55] <cjwatson> infinity: it's not like LP needs to know about this anyway :-)
[12:55] <cjwatson> the main consumer is auto-sync
[12:57] <Laney> It was some time ago, but I think I was interested in this for syncpackage. If the blacklist can't be universally represented in LP then it's less useful for that kind of purpose.
[12:57] <Laney> It might still be good to have it in there as much as possible though, in case people do use localpackagediffs
[12:58] <cjwatson> True, but syncpackage is already doing well enough with the text file
[12:59] <cjwatson> But yeah, you may be right on that.  Getting people to edit it consistently might be tricky, though.
[12:59] <Laney> Probably be best to just keep the text file as primary and have a script mirror it into LP.
[13:02] <cjwatson> Yeah.  Another case for the ubuntu-archive bot account.
[13:02] <Laney> Or I suppose the other option is to have the blacklist management script write to a text file when it can't commit to LP and then have the sync-blacklist.txt maintenance script we already have merge this one in too
[13:03] <Laney> either way consumers will have to still look at the text file