[00:13] StevenK: Help? Upgrading dogfood results in http://paste.ubuntu.com/1018822/ [00:13] 'column "private" of relation "bug" does not exist' [00:15] Hmm. Which is odd, given that there's no such COMMENT in devel [00:15] Urgh, OK, ton of conflicts, never mind [00:17] cjwatson: Ah yeah, it was used for some emergency pre-cowboy QA. reverting it all should work [00:19] Does anyone care about keeping a copy, or just 'bzr revert'? [00:20] bzr revert [00:26] OK, it's running again now, thanks [01:13] cjwatson: Are you sure we have a new enough dpkg? [01:13] cjwatson: This code is run on appservers too. [01:14] I was just wondering that. I think, though, that the only problem with the version on appservers is that it doesn't know that armhf matches any-arm. [01:15] Which is annoying but no worse than today. [01:15] It should know that armel matches any-arm, which is an improvement. [01:15] Also, shelling out randomly to bits of dpkg doesn't strike me as a truly marvellous idea, but perhaps my doubts in its security are unfounded today. [01:16] The arguments are strictly controlled here, and there doesn't exist a better interface. [01:16] And dpkg-architecture is not particularly complex. [01:17] Either trying to parse /usr/share/dpkg/*table or extending the previous broken parser is IMO a worse idea. [01:18] If there were a python-dpkg I'd use it :-) [01:22] I've just checked dpkg-architecture's behaviour if given a pathological argument to -i (containing ;, `, newline). It reads the argument unmolested and doesn't do anything silly with it. [01:22] Yeah, it seems OK. [01:23] So I do think this is safe. But if you think there's a real security concern then of course feel free to revert. I'm going to be away from ~8 hours from now until late Tuesday. [01:23] Shouldn't you be away until Wednesday? :) [01:23] No, I think it's OK, but I am wary of dpkg nowadays. [01:23] Well, I mean technically I'm back home on Tuesday. Probably won't be doing much that evening. [01:24] dpkg-architecture seems to have avoided the horribleification that abounds in most of the rest of dpkg nowadays. [01:25] It might be worth patching in a bit more armhf understanding here, but I don't think it's desperately urgent. [01:25] Right. [01:25] Only two packages in quantal are using any-arm* at all. [01:26] But we now need to be sure to upgrade the appservers with any new dpkg stuff that we previously only had to push out to Soyuz. [01:26] (picolisp, scsh-0.6) [01:26] Hmm. Can you think of a sane alternative, if that's particularly painful? [01:27] No. [01:27] It's just a change from what we've done in the past. [01:28] Also, does http://paste.ubuntu.com/1018886/ look like a vaguely reasonable queue binary override API, based on our earlier conversation? [01:29] If that's usable then I think I have an approximately usable replacement for queue. [01:30] cjwatson: That looks pretty good. Doesn't handle overrides differing between archs, but hopefully you don't care about that... [01:31] Not really. OTOH if we actually want that then we can override individual queue items. [01:31] (This is on PackageUpload.) [01:32] Yeah, but delayed copies etc. [01:32] All the builds in a single upload. [01:32] I'm not sure I've ever tried overriding a delayed copy :-) [01:32] Maybe I should given the chaos with kernel copies. [01:33] Yeah, for those I don't think we need arch-specific handling anyway. [01:33] If we do in future I could add an architecture key. [01:33] Yep [01:34] queue-api LoC +486 and scripts/ftpmaster-tools/queue + lib/lp/soyuz/scripts/queue.py = 862, never mind whatever tentacles that has elsewhere ... [01:34] I'll see about getting that in for review on Wednesday, then. [01:37] Excellent.