[14:44] anybody around.. [14:44] i'd liike some vetting of my approach for deploy-to [14:44] in core [15:41] hazmat, heyhey [15:42] hazmat, didn't know you were planning to grab that, but I'm delighted if you are :) [15:47] fwereade_, twas assigned to me friday, and i did say i'd take it up.. so yeah.. diving in. [15:47] fwereade_, do you have a minute for a g+? [15:47] * hazmat preps a diff [15:47] hazmat, sure [15:47] fwereade_, here's a diff of the approach.. http://paste.ubuntu.com/5686584/ [15:49] fwereade_, https://plus.google.com/hangouts/_/1a13f8d6e06fde8d8ce9f9f4a1219b62f75ee409?authuser=0&hl=en [22:06] oh ffs [22:06] trunk tests failing for me [22:07] gah, in two places... [23:34] hi davecheney [23:34] davecheney: how are you doing? [23:34] davecheney: as usual, I have questions :) [23:41] thumper: and you believe I have answers ? [23:41] davecheney: for some at least :) [23:41] this is becoming increasingly untrue [23:41] davecheney: firstly... [23:41] davecheney: can I get you to pull trunk, [23:41] science says that you cannot be just an observer in a system, you are also a participant [23:41] davecheney: and cd into the bzr package and run the tests [23:41] thumper: sure [23:41] two secs [23:41] davecheney: I'm guessing it will fail [23:42] yeah, i saw that proposal [23:42] well, read the title [23:43] ... testing [23:43] if it fails, then go `bzr merge lp:~thumper/juju-core/fix-bzr-test` and rerun the test [23:44] getting regex match [23:45] this whole multiple series thing is getting me down [23:45] either we all use one series [23:45] or we need build bots on every series [23:45] davecheney: so you're tests pass/ [23:45] ? [23:45] they do not pass [23:45] match == fail [23:45] ah.. [23:46] bzr_test.go:69: c.Assert(string(output), Matches, "(?s).*revision-id: "+revid+"\n.*message:\n.*my log message\n.*added:\n.*myfile .*") [23:46] ... value string = "" + [23:46] ok, can you merge my branch and rerun [23:46] I'm happy to merge a test failure like this with one approval :) [23:46] s/test failure/test failure fix/ [23:48] thumper: tests pass [23:48] LGTM, please submit [23:48] https://codereview.appspot.com/8500043/ [23:48] wanna mark that [23:48] and I'll submit [23:49] done [23:49] submitting [23:50] davecheney: worker/uniter/context.go around line 142 [23:50] davecheney: it seems to me that we are closing the outWriter pipe before waiting for the process to finish [23:50] davecheney: this looks suspicious to me [23:51] davecheney: am I missing something, or does it look weird to you too? [23:51] my first assumption is that I'm missing something [23:51] thumper: that is the subject of literally months of arguing [23:51] ah... wat? [23:51] beforewarned that digging in there involves interfacing deeply with roger and willam [23:52] thumper: are you fixing a test failure bug ? [23:52] what was the arguing? [23:52] that one comes up over and over again [23:52] thumper: about the correct way to fix it [23:52] davecheney: no, I was looking around the serialisation of hook execution on a machine [23:53] so reading the uniter code [23:53] * davecheney finds the bug [23:53] (s) [23:53] I'm wonering why if this was after a long time of arguing, why there is no comment there [23:55] because most of our arguments end in a stalemate [23:56] * thumper cracks open a can of worms [23:56] davecheney: do you know the area of code where multiple hooks can be executed at one time? [23:56] it seems to be related to subordinates [23:58] and this causes deadlocks on the apt cache etc ? [23:58] isn't this william's 'serialized hook execution'