[00:13] <cjwatson> StevenK: Help?  Upgrading dogfood results in http://paste.ubuntu.com/1018822/
[00:13] <cjwatson> 'column "private" of relation "bug" does not exist'
[00:15] <cjwatson> Hmm.  Which is odd, given that there's no such COMMENT in devel
[00:15] <cjwatson> Urgh, OK, ton of conflicts, never mind
[00:17] <wgrant> cjwatson: Ah yeah, it was used for some emergency pre-cowboy QA. reverting it all should work
[00:19] <cjwatson> Does anyone care about keeping a copy, or just 'bzr revert'?
[00:20] <wgrant> bzr revert
[00:26] <cjwatson> OK, it's running again now, thanks
[01:13] <wgrant> cjwatson: Are you sure we have a new enough dpkg?
[01:13] <wgrant> cjwatson: This code is run on appservers too.
[01:14] <cjwatson> 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] <cjwatson> Which is annoying but no worse than today.
[01:15] <cjwatson> It should know that armel matches any-arm, which is an improvement.
[01:15] <wgrant> 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] <cjwatson> The arguments are strictly controlled here, and there doesn't exist a better interface.
[01:16] <cjwatson> And dpkg-architecture is not particularly complex.
[01:17] <cjwatson> Either trying to parse /usr/share/dpkg/*table or extending the previous broken parser is IMO a worse idea.
[01:18] <cjwatson> If there were a python-dpkg I'd use it :-)
[01:22] <cjwatson> 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] <wgrant> Yeah, it seems OK.
[01:23] <cjwatson> 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] <wgrant> Shouldn't you be away until Wednesday? :)
[01:23] <wgrant> No, I think it's OK, but I am wary of dpkg nowadays.
[01:23] <cjwatson> Well, I mean technically I'm back home on Tuesday.  Probably won't be doing much that evening.
[01:24] <wgrant> dpkg-architecture seems to have avoided the horribleification that abounds in most of the rest of dpkg nowadays.
[01:25] <cjwatson> It might be worth patching in a bit more armhf understanding here, but I don't think it's desperately urgent.
[01:25] <wgrant> Right.
[01:25] <cjwatson> Only two packages in quantal are using any-arm* at all.
[01:26] <wgrant> 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] <cjwatson> (picolisp, scsh-0.6)
[01:26] <cjwatson> Hmm.  Can you think of a sane alternative, if that's particularly painful?
[01:27] <wgrant> No.
[01:27] <wgrant> It's just a change from what we've done in the past.
[01:28] <cjwatson> Also, does http://paste.ubuntu.com/1018886/ look like a vaguely reasonable queue binary override API, based on our earlier conversation?
[01:29] <cjwatson> If that's usable then I think I have an approximately usable replacement for queue.
[01:30] <wgrant> cjwatson: That looks pretty good. Doesn't handle overrides differing between archs, but hopefully you don't care about that...
[01:31] <cjwatson> Not really.  OTOH if we actually want that then we can override individual queue items.
[01:31] <cjwatson> (This is on PackageUpload.)
[01:32] <wgrant> Yeah, but delayed copies etc.
[01:32] <wgrant> All the builds in a single upload.
[01:32] <cjwatson> I'm not sure I've ever tried overriding a delayed copy :-)
[01:32] <cjwatson> Maybe I should given the chaos with kernel copies.
[01:33] <cjwatson> Yeah, for those I don't think we need arch-specific handling anyway.
[01:33] <cjwatson> If we do in future I could add an architecture key.
[01:33] <wgrant> Yep
[01:34] <cjwatson> 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] <cjwatson> I'll see about getting that in for review on Wednesday, then.
[01:37] <wgrant> Excellent.