[00:12] OK, I think that's all the BUILDERFAILed builds I can see retried. [00:18] wgrant: You mentioned making sure AccessArtifact is hot before applying db-git. Do you think that's still necessary given the staging timings, and if so how do we go about it? [00:18] cjwatson: Yes, it's still necessary. A SELECT COUNT(*) FROM accessartifact; a few times should do it. [00:18] wildcherry IO is sloooooooooow. [00:19] OK, I'll put that in the RT. [00:22] wgrant: https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus#Unusual_Rollout_Requirements look right? [00:23] cjwatson: I'd say "immediately before", but one of us will be handholding anyway I imagine. [00:24] tweaked [00:25] Thanks, looks good. [00:27] That's https://rt.admin.canonical.com/Ticket/Display.html?id=78737 now. [00:28] Hopefully wildcherry will rest in peace soon. [00:28] Quite. [01:54] Hi everyone [01:55] I was checking this page yesterday regarding the Launchpad API : https://help.launchpad.net/API/launchpadlib [01:55] and I saw a link to the reference documentation: https://launchpad.net/+apidoc/ [01:55] however it looks like the current version of the API is planned to be deprecated in 2 months [01:56] if I want to develop a little Python tool to retrieve and process info from Launchpad, should I still go with launchpadlib? [02:18] ePierre: launchpadlib is the way to go, but unless your application is being distributed to end-user systems it should probably be using the 'devel' API version. [02:19] '1.0' will be around for longer than the page states (and even 'beta' still works, as we've had no reason to break it so far), but new applications that can be easily updated should use 'devel' by default. [02:32] wgrant, ok thanks! [02:33] For now it's just gonna be for personal use (I just would like to tinker a bit with Python and Launchpad to retrieve info more easily than using the web interface) [02:34] ePierre: Definitely use devel, in that case. === mup_ is now known as mup [12:39] wgrant: https://code.launchpad.net/~cjwatson/launchpad/git-basic-model/+merge/248976 should be ready for re-review now. [12:43] Ah, you beat me. [12:44] Just finished with the second pass, just about there. [12:44] Oh zope.publisher why do you despise me [12:44] cjwatson: https://code.launchpad.net/~wgrant/launchpad/xbia-refactor/+merge/249295 and https://code.launchpad.net/~wgrant/launchpad/xbia/+merge/249296 could do with a review if you have time today. [12:44] What's it doing to you? [12:44] wgrant: will do [12:45] Unhelpful response to unexpected exceptions in XML-RPC methods. (Hacking in traceback.print_exc) [12:45] Ah. [12:45] Er traceback.print_exception [12:45] Otherwise you just get "fatal: remote error: Unexpected Zope exception: TypeError: object.__new__() takes no parameters" and have to drink heavily. [12:45] [12:46] Nothing useful in the appserver log? [12:46] No, but there is if one hacks zope.publisher :) [12:46] Heh [12:46] # Create an appropriate Fault object. Unfortunately, we throw away [12:46] # most of the debugging information. More useful error reporting is [12:46] # left as an exercise for the reader. [12:46] ,,, [13:00] wgrant: Does it matter (e.g. for determinism of build creation) that the return value of determine_architectures_to_build is no longer sorted? [13:06] wgrant: And do we have agreement with Debian ftpmaster (or buildd admins?) on the specification? [13:06] cjwatson: createForSource sorts the output, I think, but let me check. [13:07] cjwatson: It's roughly compatible with the Debian proposal, at least in the ways we're likely to use it. [13:07] (though the Debian proposal hasn't been touched in about a year) [13:07] Steve needs this now, or gross hacks will abound. [13:08] We figure it'll only be a handful of packages, so even if they adopt a conflicting proposal it's pretty trivial to migrate. [13:08] The output isn't sorted AFAICS. [13:09] createForSource sorts by processor.id [13:09] Only for arch_indep_das [13:10] needed_architectures is unsorted [13:10] are you looking at the new code? [13:10] Oh, or did I break it in the refactor branch, and fix it in the final... [13:11] Ah, you would appear to have done [13:11] Yeah, sorry, you're right. [13:11] OK, I guess we can land in one step. Let me just reassure myself about the rest of the second branch. [13:14] Shouldn't there be some kind of assertion in determine_architectures_to_build that if we need an arch-indep build then we actually get one? [13:15] Or will that fail later? [13:16] It may legitimately fail. [13:16] If I have an "Architecture: powerpc all", it will only build on powerpc. If I don't have powerpc, it shouldn't create any builds. [13:18] So that'll just return the empty dict. OK. [13:18] Right. [13:32] r=me with a couple of comments [13:34] Thanks. [13:39] dpkg-architecture is really slow. [14:05] The build start time estimate tests are the worst thing in the world. [14:08] Re GitRepositorySet.set*Default, I was thinking of having those be internal methods which were called by methods that require edit permission on the target; I'm just not far enough up the stack to implement that yet. But you're right that it shouldn't require edit permission on the repository, and I should make the intended use more clear. [14:08] s/Set// [14:09] In that case the automatic clobbering behaviour probably makes less sense. [14:09] Moving them off Edit indeed sounds sensible. [17:12] wgrant: I've addressed your second batch of git-basic-model comments. Thanks.