[02:00] Project db-devel build #691: FAILURE in 5 hr 43 min: https://lpci.wedontsleep.org/job/db-devel/691/ [07:40] Yippie, build fixed! [07:40] Project db-devel build #692: FIXED in 5 hr 40 min: https://lpci.wedontsleep.org/job/db-devel/692/ [23:08] Morning. [23:12] wgrant: olá [23:14] Barely. [23:15] we have a 150cm climbing tree for the cats [23:15] they are both wrestling at the top of it right now [23:18] :( [23:19] and now are sleep on each other [23:22] wgrant: are you planning on working today or just going 'blargh' [23:22] lifeless: Going to try to get us deployable, then blargh. [23:22] wgrant: if the former, I heard a rumour you'd made progress on rabbit [23:22] And maybe try to get rabbit sorted out. [23:22] Since that is mostly poking spm and considering packaging rabbitmq-management. [23:23] rabbitmq-management ? [23:23] A plugin which provides an HTTP API which will allow us to reset the fixture in a couple of ms. [23:23] cool [23:23] Natty has a plugin or two packaged, so it should be easy enough. [23:23] did I tell you that db resets are 0.2s [23:24] gary says they were taking 4s for him (when using the JS factory/teardown bindings written last week). [23:24] I need to investigate that this week. [23:24] Since it sounds implausible. [23:24] By a factor of 10 or so. [23:25] lifeless: Did you see the stub/bigjools Messaging API v3 land? [23:27] kindof [23:33] wgrant: what was taking 4s? [23:36] lifeless: I'm not entirely clear on that. But it was one of the normal layer teardowns, AIUI. [23:36] It only came up during the wrap-up. [23:36] so [23:36] if there is any contention on the template db [23:36] both copies will fail [23:36] I suspect there was an appserver still running or something. [23:36] and they take their own time about it [23:36] Since it's in the YUITestLayer-with-appserver monstrosity. [23:37] can I get a review of https://code.launchpad.net/~lifeless/launchpad/paralleltests/+merge/66554 ? [23:38] No, since the diff hasn't generated yet. :-P [23:38] it won't [23:38] the scanner blew up [23:39] bzr diff -rr ancestor:lp:launchpad https://code.launchpad.net/~lifeless/launchpad/paralleltests [23:39] should get you a diff [23:39] Then pastebin it? :-) [23:40] sure [23:42] I've linked a pastebin into it [23:42] I reserve the right to sob and cry and state it's too hard to review while jetlagged. [23:42] of course [23:42] this is just test plumbing [23:43] it should fix the parallel test job hanging [23:44] To my jetlagged adled brain, it looks fine. [23:44] I approve of more logging. [23:45] the logging is crude, but it helped me a lot when fiddling with it, and I expect others will need said fiddling themselves [23:45] e.g. future me [23:46] lifeless: As an aside, I'm curious how the scanner blew up on the branch? [23:47] StevenK: bug 612171 [23:47] <_mup_> Bug #612171: Error generating merge proposal diff when "source branch has pending writes"

< https://launchpad.net/bugs/612171 > [23:47] lifeless: I've approved the branch, land it, ping me when it has and I'll re-enable the Jenkins job. [23:47] I hit that [23:47] (I'm using the term scanner loosely) [23:48] I wonder if we could fix that using Julian's work to suspend the job [23:49] you could [23:49] If .checkReady() returns False, suspend the job for one run and unsuspend it on the next run. [23:49] I think its simpler to just cancel the job cleanly [23:49] and when scanning a branch, we should be updating the merge proposal(s) for it anyway [23:49] It will or will not get scanned again by itself? [23:50] right [23:50] That was a question, not a statement. :-P [23:50] 'write pending' is a state that will either rectify itself (and thus the rectification can create new merge proposal jobs), or it won't (and thus a suspended job would never succeed) [23:51] Right. Then I agree with you. [23:51] polling every run is inefficient and can fail horribly (when the things being polled but not active grows large) [23:51] We should kill the job [23:52] I suspect we have a hole in our 'create a new mp job' logic at the moment, the flip side of this error [23:52] another option would be to ignore the pending write, and read the *old* tip [23:52] anyhoo