[00:00] m_3: are you doing update alternatives ? [00:00] davecheney: side note, we should push that to ~juju btw, not ~davecheney/juju-core/packaging [00:00] yup [00:01] m_3: have you talked to mgz ? [00:01] I think it's assigned to martin, not sure... [00:01] he is also doing that [00:01] ok, make sure you don't overlap and waste your own time [00:01] yep, thanks... I'm getting him the juju-0.6 version to look at [00:02] we discussed this morning [00:03] davecheney: on charm-testing, did you get a chance to get a basic version of watch working? [00:03] davecheney: or still need that done? [00:03] m_3: still todo [00:03] ack [00:04] sorry, making slow going gettting my changes comitted [00:04] short version, although we can't prove it, charm testing looks good to me [00:04] we haven't managed to break anything significant [00:04] davecheney: no prob... just wanted to sync up with you before spending any time on it [00:04] but right now the providers and backends are so unstable it is impossible to tell how well the charm's are tested [00:05] apparently we do retry ec2 operatoins [00:05] not that it helps [00:05] the f'r still returns garbage [00:05] davecheney: dude, that's not a 2.0-specific issue ;) [00:05] yeah, lots of flakiness lately against the apis (hard to quantify tho) [00:06] certs not being valid for brief periods of time, then passing in a retry [00:19] davecheney: got some time? [00:21] fwereade: you work weird hours dude [00:21] fwereade: if you are really around, I have a few specific questions [00:21] thumper, heh, laura's had an earache and I'm not likely to sleep for a bit [00:21] fwereade: regarding mongo transactions and unit allocation [00:21] :( [00:21] thumper, ok, cool [00:21] is she still awake? [00:22] thumper, she's sleeping now, but if crying starts I may suddenly disappear and not come back predictably or at all [00:22] thumper: sorry, on my way out the door [00:22] davecheney: np [00:22] thumper, happy to chat for now anyway :) [00:22] fwereade: that's fine === jtv1 is now known as jtv [03:49] * wallyworld_ -> doctor, bbiab [05:04] m_3: https://canonical.leankit.com/Boards/View/103148069/104151613 [05:04] ^ this is hte card for 'make a juju watch sort of thing' [08:00] morning all === TheRealMue is now known as TheMue [08:08] davecheney: ping [11:18] mgz: poke [11:27] reping mgz please? other machine is... having fun [11:27] w7z: you' were quit with a timeout [11:27] mgz: poke [11:27] so there is no mgz to poke anymore [11:27] counter-poke [11:27] w7z: prod [11:28] Just wanted to chat, but you're on mumble, so you can probably just undeafen yourself [11:29] w7z: no love for the undeafening? [11:31] I'm getting there... [11:42] fwereade: ping [11:42] dimitern, pong [11:43] fwereade: am i right to assume, that if neither --repository is given nor JUJU_REPOSITORY is set, then the cmd should use the charm store? [11:43] dimitern, it's independent, I think [11:44] dimitern, the repoPath argument is only used if we know it's a local charm in the first place [11:44] dimitern, ie it starts with local: [11:44] fwereade: so we never use the CS? how about if the effective the repo is empty - should it be a separate error? [11:45] fwereade: ah, I see your point - it's only used for local: charms [11:45] dimitern, I don't think we should worry about the repo path at all at the command level [11:45] dimitern, pass it through and if there's an error, then there's an error [11:46] fwereade: my question was - should I distinguish between --repository= and --repository=invalid_path [11:46] dimitern, maybe, if it's specified, we should validate that it's a dir? otherwise double-check what we do the relevant Infer* methods [11:46] fwereade: I'm already using ReadDir to verify it's a dir [11:47] fwereade: it it's empty and we need it there will be an error reported [11:47] dimitern, emphasis was meant to be on the "if it's specified"... but then maybe it makes sense to assume . to be the repo in the absence of any specific value set [11:47] dimitern, an empty dir is, I think, a valid repo [11:48] dimitern, it just doesn't have any series or charms in it [11:48] fwereade: ok, so if it's a valid dir it's ok, otherwise it's an error [11:48] dimitern, the interesting thing is that it won't ever be empty in fact [11:48] dimitern, by empty I mean "" [11:48] dimitern, because we use ctx.AbsPath to figure out where it really is [11:49] fwereade: it can be empty when you pass --repository= and unset J_REPO [11:49] dimitern, still won;t be empty once it's gone through ctx.AbsPath [11:49] fwereade: that's even worse - it'll mean it's the cwd [11:49] dimitern, what's wrong with that? [11:49] dimitern, if I'm developing charms, having the repo as the pwd seems very convenient [11:49] fwereade: istm this is kinda unexpected [11:50] fwereade: unless documented in the help at least [11:50] dimitern, if I'm not developing charms I shouldn't be using a local repo ;p [11:51] dimitern, what's the worst that can happen? "no charm found in local repo at /path/to/pwd"? [11:51] fwereade: so I'll have to check it on run, rather than on init (where I can't use AbsPath) [11:51] lunchtime [11:51] dimitern, I'm becoming convinced that it shouldn't be checked by the command at all [11:52] mgz: dimitern: jam: [11:52] ian@wallyworld:~/.hpopenstack$ juju debuglog [11:52] juju-hpcloudx-machine-0:2013/03/26 11:51:27 DEBUG JUJU:jujud:machine state/watcher: loading new events from changelog collection... [11:52] juju-hpcloudx-machine-0:2013/03/26 11:51:27 DEBUG JUJU:jujud:machine state/watcher: loading new events from changelog collection... [11:52] juju-hpcloudx-machine-0:2013/03/26 11:51:32 DEBUG JUJU:jujud:machine state/watcher: loading new events from changelog collection... [11:52] fwereade: so then: remove the tests for --repository as well? [11:52] dimitern, just run it through ctx.AbsPath and sling it into InferRepository [11:52] dimitern, I didn't say anything about tests [11:53] dimitern, just that it doesn't need special handling in the command [11:53] fwereade: if we're not checking it why should we test it? [11:53] dimitern, because it affects the behaviour of the command? [11:53] fwereade: just a sec, need to test this [11:54] rogpeppe, am I able to ask you some questions about the juju api? [11:54] wallyworld, whoa! [11:54] wallyworld, awesome! [11:54] wallyworld, tyvm [11:55] fwereade: yeah, me happy :-) [11:55] fwereade: if i'm not checking --repo explicitly, passing either an invalid or empty one there will cause "service "blah" not found" to be returned [11:55] fwereade: that is tailing the consolidated log file which contains accumulated logs from all nodes [11:55] wallyworld, I completely failed to understand what you pasted for a mo :) [11:56] wallyworld, just one detail, please call it "debug-log" [11:56] fwereade: we are on a standup and i was communicating with the team :-) [11:56] fwereade: already mentioned :-) [11:56] wallyworld, cool :) [11:56] dimitern, I'm not following; what does the repo have to do with the service? [11:57] mattyw: sure, ask away [11:58] fwereade: i'm not doing it explicitly, just the check for service fires when there is no repo given [11:58] dimitern, ah, are you talking about the error tests for repo values? [11:58] fwereade: yes [11:58] dimitern, I think you need to create a service so you can get far enough in those tests [11:59] fwereade: ofc, silly me :) sorry, still waking up [11:59] rogpeppe, well I;m basically about to start poking around, to begin with all I really want is to read the current status of all the units. I'm looking at the juju-core/state/apiserver and api packages. There looks to be a client.go, is this essentially an example of something to read from the api? [12:00] mattyw: what are you writing your client code in? [12:00] rogpeppe, go [12:00] mattyw: ok, so you don't need the API in fact, for the time being. [12:00] mattyw: what's your use case? [12:01] fwereade: ok, then we have this unhelpful error: "no repository found at \"/tmp/gocheck-583324308/12/blah\"" [12:01] fwereade: (with juju upgrade-charm riak --repo=blah) [12:01] dimitern, ok, so an empty dir is not a valid repo [12:01] dimitern, what's unhelpful about that? [12:02] dimitern, it seems to describe exactly the problem [12:02] fwereade: well, for starters there's no blah dir there at all [12:02] dimitern, so, yeah: no dir, no repo [12:03] fwereade: ok then, I'll leave it to this and make a fuzzy regexp error matching\ [12:03] dimitern, william@diz:~/code/go/src/launchpad.net/juju-core$ rm not-here [12:03] rm: cannot remove `not-here': No such file or directory [12:03] dimitern, sgtnm [12:03] fwereade: thanks [12:06] * fwereade => lunch [12:26] fwereade: ping me when you're back please [12:26] jam: made that change and the tests still pass [12:29] I don't see anything accessing Config from the suite, only from env [12:29] mgz: http://bazaar.launchpad.net/~juju/juju-core/trunk/view/head:/environs/jujutest/livetests.go#L50 [12:30] looks the same in your branch: http://bazaar.launchpad.net/~gz/juju-core/tests_os_ssh_isolation_1144704/view/head:/environs/jujutest/livetests.go#L50 [12:31] hm, declaring A A is ineffective then [12:32] mgz: If I just do "TestConfig TestConfig" on line 28 of livetests.go [12:32] then "go test" fails with "type *LiveTests has no field or method Config" [12:33] does anyone around know about the particular requirements of the "Need something that functions like jitsu watch" ticket? [12:33] okay, ...the problem is (cd environs&&go test ./...) doesn't actually run any of the tests I care about... [12:34] rogpeppe: m_3 or hazmat are your best choices here I think, although AFAIR it was about having a regexp filter over status output [12:35] so, how do I actually run all tests under environs/ then? [12:35] dimitern: yeah, although having just taken only 10 minutes to knock up something that uses the client AllWatcher (http://paste.ubuntu.com/5649215/) i think we can do better than that [12:35] dimitern: with probably less code [12:36] rogpeppe: i don't quite get what that code is doing [12:36] dimitern: it's watching for any changes in the environment [12:36] dimitern: through the GUI API interface [12:37] rogpeppe: i think filtering is key here - it's the way to block a script until something happens in status [12:37] dimitern: sure. all you need for filtering is to put some code inside that for loop [12:37] mgz: that should run all the ec2 tests and all the openstack tests [12:37] With the problem that if something doesn't compile, it gives you a minimal error message [12:38] jam: it appears that it doesn't even build them [12:38] because it just passed... [12:38] rogpeppe: sgtm [12:38] dimitern: but i'm not sure exactly what they mean by "machine state" or "service state" [12:38] I get "FAIL launchpad.net/juju-core/environs/dummy [build failed]" [12:39] rogpeppe: whether service X was deployed and now running perhaps? [12:39] dimitern: i can guess, but i'd like to know for sure before i code something wrong [12:39] mgz: are you sure 'bzr dif' agrees you made the change? [12:40] http://pastebin.ubuntu.com/5649271/ [12:40] mgz: see my earlier comments [12:40] rogpeppe: maybe it's a good question to ask on the list then [12:40] you cannot pass -gocheck.v [12:40] with ./... [12:40] gah... [12:40] 'go test ./...' does what you want [12:41] and *maybe* go test ./... -gocheck.v [12:41] go test -gocheck.v only runs the tests in the CWD [12:41] by earlier comments [12:42] I mean things from months ago when I ran into that myself [12:42] which is why goose has a "test.py" helper [12:42] yeah, I hit it previously, but apparently can't internalise all the go test weirdnesses [12:43] mgz: it doesn't help that it does run some tests, and they all appear to pass [12:43] and doesn't complain while it goes about ignoring your passed parameter [12:48] dimitern, pong [12:49] fwereade: I made the changes, wanna take a look before I submit? https://codereview.appspot.com/7927043/ === vds` is now known as vds [12:51] dimitern, sure, thanks [12:51] rogpeppe, so jitsu watch has an overly large range of functionality.. but in practice.. its primarily used to assert that a unit is started and relations are not in error === vds is now known as indentify === indentify is now known as vds [12:52] hazmat: could you describe briefly the actual functionality required? does it need info about machines? what about services? [12:53] hazmat: if i'm right, then it's a very small piece of work :-) [12:53] I've juju bootstrapped and juju deployed a charm with py juju on ec2, juju status tells me everything works fine, with exactly the same settings juju-core status tells me: error: Get :301 response missing Location header [12:54] fwereade, jam: have pushed up and proposed a change I think is good to land [12:54] I've seen something similar here: https://bugs.launchpad.net/juju-core/+bug/1083017 [12:54] <_mup_> Bug #1083017: Cannot bootstrap with public-tools in non us-east-1 region

< https://launchpad.net/bugs/1083017 > [12:55] want to try some other changes, but will probably use a different branch [12:55] rogpeppe, i think yes to both (although the later primarily as an aggregate of the units being in good order). the problem is its implementation is extremely generic. so its hard to categorize effectively without auditing uses.. it supports additional things that i'm a little more concerned with like setting predicate expressions on relation data [12:56] * hazmat pokes around a charm checkout [12:56] hazmat: yeah, we won't be doing that yet [12:56] hazmat: (if ever, i dunno) [12:56] vds, is that the only output ? re juju-core status? [12:56] hazmat, yep [12:57] fwereade: time for a short hangout? [12:57] TheMue, I would love to but would you ping me again in 10 mins please? [12:58] fwereade: ok [12:58] TheMue, tyvm [12:58] fwereade: yw, i have to ty [13:01] dimitern, LGTM [13:01] fwereade: great, tyvm [13:02] fwereade: and of the two cards left for upgrade-charm, which one is more important: handling (new peer) relations with SetCharm or validating endpoints compat? [13:05] dimitern, peer relations [13:05] hazmat: yes, it would be very useful to know what's actually needed in practice. [13:05] fwereade: ok, I'll pick that up next [13:05] dimitern, the endpoints compat fixes a race but quite an obscure one [13:05] dimitern, I'm ok to kick that back to post-13.04 [13:06] fwereade: great to hear :) [13:11] rogpeppe, afaics there are only two users of jitsu watch.. juju-gui charm, and the internal implementation of jitsu test. [13:11] rogpeppe, there are quite a few users of jitsu get-service-info [13:11] hazmat: what does get-service-info provide that juju status doesn't ? [13:12] hazmat: and how does jitsu test use jitsu watch? [13:12] rogpeppe, fwiw the grep jitsu audit against precise charms. http://paste.ubuntu.com/5649345/ and quantal http://paste.ubuntu.com/5649346/ [13:13] rogpeppe, nothing of note.. its already built on status parsing [13:14] hazmat: cool [13:15] mgz: so what about making TestConfig.Config() a method, so that we copy it at that point [13:15] rather than having it as an exposed map? [13:16] it ideally would not be exposed at all [13:16] but the tests all suck [13:16] I have an alternative I prefer, but that's why I mentioned a different branch [13:16] because that's more rewritey === wedgwood_away is now known as wedgwood === wedgwood is now known as Guest28578 === Makyo|out is now known as Makyo [14:02] Hi, it seems like the Ubuntu package repo in EC2 is broken, at least in ireland region [14:02] "Failed to fetch bzip2:/var/lib/apt/lists/partial/eu-west-1.ec2.archive.ubuntu.com_ubuntu_dists_precise-updates_main_source_Sources Hash Sum mismatch" [14:03] Breaks most of the charms... [14:12] mariusko: ack, thx [14:13] robbiew: opened a bug report to track it: https://bugs.launchpad.net/ubuntu-on-ec2/+bug/1160358 [14:13] <_mup_> Bug #1160358: Hash Sum mismatch for Precise main and universe EC2 images < https://launchpad.net/bugs/1160358 > [14:15] * dimitern lunch [15:13] robbiew: works fine in EC2 default US [15:14] rogpeppe, the api is great :) [15:14] mattyw: thanks! [15:14] mattyw: those are welcome words :-) [15:16] mariusko: ok, thanks [15:16] mattyw: did you know you can see nicely formatted docs here? http://godoc.org/launchpad.net/juju-core/state/api [15:16] I've alerted the appropriate folks within our IS and cloud engineering teams [15:17] rogpeppe, I'm actually serving it up on my pc using godoc -http=":6060" as I find it displays slightly neater [15:17] mattyw: even better :-) [15:17] rogpeppe, but I had seen the godoc.org one, one of the things I like about go [15:18] mattyw: although it's quite nice that the types on the godoc.org link to their definitions [15:18] rogpeppe, that's true, I'm happy to cheat and Ctrl+f for those though [15:19] mattyw: ha ha [15:31] fwereade, hazmat: fancy a brief chat about the interface to the juju-watch tool? [15:32] rogpeppe, sure, if hazmat's not sleeping [15:32] fwereade: well, we could do an initial pass [15:32] * TheMue is AFK as said yesterday, will continue later [15:32] fwereade: changes feel good so far [15:33] TheMue, excellent [15:33] fwereade, hazmat: https://plus.google.com/hangouts/_/e8d67225b0b8f66799886c65264cd98a37bf4053?authuser=0&hl=en-GB [15:51] m_3: ping [15:51] rogpeppe: pong [15:52] m_3: just pondering the design of a jitsu watch-like tool [15:52] rogpeppe: cool [15:52] m_3: and wondering how important it is to retain compatibility with that tool's command-line interface [15:52] m_3: and how much functionality is required [15:52] rogpeppe: not important at all afaik... we can pretty easily adapt the tooling that's using it [15:53] m_3: ok, that's cool. [15:53] rogpeppe: required functionality imo: [15:53] rogpeppe: block until terminal state is reached [15:54] m_3: here's my preliminary sketch BTW: http://paste.ubuntu.com/5649690/ [15:54] rogpeppe: make the current state available [15:54] m_3: ah, so when the terminal state is reached, it'll print the entire status? [15:54] rogpeppe: timeout can be done from outside of the tool [15:54] m_3: ok, though it's trivial to do inside it. [15:55] terminal states were {started, install-error, start-error} iirc [15:56] rogpeppe: no need for the entire status if we're watching a particular service... just that service's status [15:56] m_3: hmm, interesting, so just waiting for one particular state is not quite good enough. [15:56] rogpeppe: correct [15:56] m_3: do you need to watch for more than one thing at a time? [15:57] rogpeppe: in the context of testing, you wanna wait through non-terminal states (like 'pending') [15:57] m_3: yeah, i see that [15:57] rogpeppe: but know when your test is complete... pass or fail [15:58] rogpeppe: not sure if there's _really_ a need to watch more than one service... at least at first [15:58] rogpeppe: it'd be nice to watch for relation status as well [15:58] again... waiting through non-terminal... until a terminal is reachedd [15:58] m_3: what do you mean by relation status? [15:59] rogpeppe: I gotta run to chair an ubuntu-server irc meeting [15:59] m_3: ok, thanks for the input - very helpful! [15:59] rogpeppe: watch for relation state to be in a failed state or not [15:59] rogpeppe: I can talk more about it after that meeting... [15:59] m_3: that might be useful, thanks [16:00] rogpeppe: thanks for getting watchers in!!! [16:00] m_3: np! [16:11] rogpeppe: are megawatcher_internal_test.go and state_test.go in a different package somehow? [16:11] dimitern: yes [16:11] rogpeppe: I mean, they are but why? [16:12] dimitern: because megawatcher_internal_test tests lots of internal stuff [16:12] dimitern: the other tests test using only the external interfaces [16:12] dimitern: i broke with tradition for the allwatcher :-) [16:12] rogpeppe: I need to move AddConfigCharm out of there, so I can use it in state tests [16:13] dimitern: you can use it in state tests [16:13] rogpeppe: though conn_test yes [16:13] rogpeppe: but istm something so generic should be in state_test instead [16:13] dimitern: you can use it directly too, if you want. [16:14] dimitern: well, it can't be in state_test because some of the internal tests use it [16:14] dimitern: unless we want to dupe the code [16:14] rogpeppe: i need to add a similar helper - AddMetaCharm for overriding metadata.yaml, but putting this in megawatcher_internal_test seems wrong [16:15] dimitern: it's arguable that perhaps it should be in export_test.go [16:15] rogpeppe: ok, I'll just put it there then, with AddConfigCharm [16:15] dimitern: megawatcher_test is just a place of convenience [16:16] dimitern: won't AddMetaCharm be almost identical to AddConfigCharm? [16:16] rogpeppe: yes [16:16] dimitern: perhaps there's a more general function struggling to emerge here [16:16] rogpeppe: yeah, good point [16:17] rogpeppe: how should i call it? AddCustomCharm? passing filename + content? [16:18] dimitern: something like: AddTestingCharm(c *C, name string, mutate func(ch *charm.Dir)) ? [16:19] dimitern: if mutate is nil, it does nothing; otherwise it can be used to change the cloned charm as desired [16:19] rogpeppe: I don't really want to change 100 files with tests just for that 1 func [16:19] rogpeppe: i can do it in a follow up though [16:20] rogpeppe: for now I'll add AddCustomCharm and make conn_test's Add(Meta|Config)Charm call it internally [16:20] dimitern: that sounds good to me [16:20] dimitern: as does the move to export_test.go [16:30] I get this error trying to go get juju-core https://pastebin.canonical.com/87778/ [16:33] vds: try go get -u launchpad.net/goose [16:33] vds: then try again: go install launchpad.net/juju-core/... [16:34] rogpeppe, done already few minutes ago, I can try again [16:34] vds: hmm, that won't help then [16:36] vds: what revision of goose are you on? [16:37] rogpeppe, 60 [16:37] vds: ah, current rev is 82 [16:37] vds: i think you might be switched to a different branch or something [16:38] rogpeppe, it says trunk, I remove it and go get it again [16:38] vds: good plan [16:40] vds: rev 60 seems about the same time we introduced tarmac + goose-bot for trunk management, so it's best to scratch it and get it afresh [16:42] rogpeppe: i'm getting ErrExcessiveContention with upgradecharm stuff because of the annotations, albeit intermittently [16:42] dimitern: interesting. can you paste a log? [16:43] rogpeppe: http://paste.ubuntu.com/5649803/ [16:44] dimitern, what's the connection to the annotations? [16:45] fwereade: hmm.. maybe it's not actually [16:45] fwereade: but it worked earlier today [16:46] dimitern, fwereade: yeah, that was my question too [16:46] it's not intermittent - got it twice so far - 100% reproducability [16:46] it worked before i merged current trunk just now, and it was working when I was submitting the upgrade charm cmd [16:47] * fwereade checks [16:47] dimitern: i'm not seeing the issue at all [16:48] dimitern: do you see it when you run the test in isolation? [16:48] rogpeppe: I was about to propose the new peer relations stuff and merged trunk before [16:48] rogpeppe: it was working before the merge [16:48] dimitern: could you paste me the branch you're working on and i'll test it in that [16:48] dimitern, STM that trunk works [16:48] fwereade: +1 [16:48] let me push it [16:49] dimitern, are you 100% sure you're only adding *new* peer relations? ;p [16:49] dimitern: i've run it > 87 times now without problem [16:49] i am [16:50] in isolation it also fails [16:50] dimitern, yeah, on reflection that question made little sense, sorry [16:50] * rogpeppe wishes we added more context to errors as a matter of course [16:51] lp:~dimitern/juju-core/017-upgrade-charm-add-new-peer-relations [16:52] when I run the state tests they all pass [16:52] including the new one i added to check new peer rels are added on upgrade [16:52] but upgrade cmd fails [16:52] s/cmd fails/cmd tests fail/ [16:53] i cannot see what the problem might be [16:55] dimitern: i can confirm that i see the error [16:56] dimitern, I'm not sure about the logic in peerRelationsDifference [16:56] fwereade: please explain? [16:57] dimitern, looks to me like "for every existing relation, if it's also a new one, add it" [16:57] dimitern, where it should be "for every new relation, if it doesn't already exist, add it" [16:58] fwereade: ah! makes sens [16:58] fwereade: :) yeah, I'll change it [17:00] something is very wrong with my machine -> rebooting [17:05] fwereade: very weird.. how come such case wasn't caught by the state tests? [17:06] fwereade: probably because the test is a bit flawed - I need to start with some peer relations already and then try to add new ones [17:06] dimitern, I imagine your test coverage was a touch lacking somewhere, but I haven't actually read them yet [17:08] fwereade: now it works! :) tyvm [17:09] dimitern, awesome [17:16] gn all, see you soon [17:26] rogpeppe: if it's not too late for a review :) take a look at this please: https://codereview.appspot.com/8034043/ [17:27] dimitern: have you added a state test that fails when the last issue wasn't fixed? [17:28] rogpeppe: I improved the state test, but it's not easy to test this there [17:29] rogpeppe: but upgrade-charm cmd tests pass now [17:29] dimitern: why is it hard to test? [17:30] dimitern: i think it's important to add a test near the functionality that was wrong [17:32] rogpeppe: I think i did just that in the test\ [17:33] dimitern: so you've reverted the changes to the non-test state files and checked that the state tests now fail? [17:34] rogpeppe: no I didn't revert them [17:35] dimitern: it's worth trying, just to make sure [17:35] rogpeppe: but the i guess the test could be improved a bit [17:35] rogpeppe: I'll try yeah [17:35] dimitern: if tests still pass then the tests do need improving :-) [17:36] rogpeppe: i'll give it a go tomorrow then [17:36] dimitern: cool, thanks [17:39] rogpeppe: thanks you for reviewing this [17:39] dimitern: i haven't reviewed it yet, i'm afraid [17:39] rogpeppe: well, the comments so far were helpful :) [17:40] rogpeppe: i'd appreciate if you mention them [17:40] dimitern: on the review? [17:41] rogpeppe: yeah, i'll be easier for me to remember the suggestions in the morning [17:42] dimitern: done [17:42] rogpeppe: cheers [17:56] time for me to go. g'night all. === hatch_ is now known as hatch [19:56] morning [20:05] thumper: evening ;) [20:33] yep, evening, and latest CL is in again, so good night [21:29] fwereade: if you are around, I have more questions [21:30] thumper: no chance right now :) just coming from his place, he's off already [21:30] dimitern: ok, ta [21:31] thumper: btw what's your local time now? [21:31] 10:31am [21:31] ah, ok [22:19] thumper: sorry i missed you yesterday, i'm all yours today [22:19] davecheney: cool [22:19] I have some questions now if you are available [22:19] mostly about how we use mongo, and state stuff [22:22]