| * cjwatson wonders why there are packages in wheezy+sid and not in quantal with no DSDs | 00:25 | |
| 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:51 |
| 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:54 |
| 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 | 00:58 |
| 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:04 |
| 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:06 |
| tumbleweed | ah | 01:07 |
| slangasek | mdeslaur: ah, though I see comments further on claiming it still occurs with do-release-upgrade; looking further | 01:14 |
| slangasek | also, yay: Brian J. Murrell, the friendliest Ubuntu bug reporter | 01:16 |
| * 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:19 |
| 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:26 |
| cjwatson | I was about to point Brian J. Murrell at jenkins and then noticed it was failing | 01:27 |
| 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:28 |
| * 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:33 |
| 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:35 |
| 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:37 |
| 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:38 |
| 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:39 |
| slangasek | aha, figured out the problem | 01:42 |
| slangasek | secret-keyring w/o no-default-keyring | 01:42 |
| 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:43 |
| 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 | 01:47 |
| infinity | cjwatson: You know a bunch of randoms will anyway, they always do. | 03:46 |
| 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 | 03:53 |
| === yofel_ is now known as yofel | ||
| cjwatson | infinity: it's not like LP needs to know about this anyway :-) | 12:55 |
| cjwatson | the main consumer is auto-sync | 12:55 |
| 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:57 |
| cjwatson | True, but syncpackage is already doing well enough with the text file | 12:58 |
| 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. | 12:59 |
| 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:02 |
| Laney | either way consumers will have to still look at the text file | 13:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!