[00:22] EMPTY REVIEW QUEUE [00:23] * niemeyer steps out to celebrate [04:04] afternoon [04:05] anyone in the chan ? [04:16] davecheney: hi [04:20] howdy [04:21] can I ask, what happens if you run juju status on a freshly bootstrapped environ ? [04:21] looking at the code, the result should be yamls {} [04:23] juju status returns a yaml with one machine (bootstrap machine) [04:26] ahh yes, of course [04:27] * davecheney goes back to mocking [04:31] davecheney: http://bazaar.launchpad.net/~juju/juju/trunk/view/head:/juju/control/tests/sample_cluster.yaml [04:31] andrewsmedina: ta [04:46] davecheney: sleep time [04:46] davecheney: see you tomorrow [04:47] andrewsmedina: np, thanks for your help [04:52] davecheney: :D [06:41] davecheney: hiya [06:44] morning [06:45] rog, davecheney, heyhey [06:45] fwereade_: yo! [06:54] rog, does this look in any way familiar to you? [06:54] ../state/state.go:8: inconsistent definition for type goyaml._Ctype_struct___9 during import\n\tstruct { start *goyaml._Ctype_yaml_tag_directive_t; end *goyaml._Ctype_yaml_tag_directive_t; top *goyaml._Ctype_yaml_tag_directive_t }\n\tstruct { start *goyaml._Ctype_yaml_simple_key_t; end *goyaml._Ctype_yaml_simple_key_t; top *goyaml._Ctype_yaml_simple_key_t }\n [06:54] rog, goyaml builds just fine normally, but falls over like that in TestPutTools [06:55] fwereade_: it's a cgo error, but i don't think i've seen it before [06:55] fwereade_: have you tried go build launchpad.net/juju-core/... ? [06:56] fwereade_: because it looks to me like TestPutTools is failing because it can't build the commands. [06:56] rog, yes indeed, that is the weirdness [06:56] rog, it only fails when I clear out pkg [06:57] fwereade_: hmm, i wonder if it's something to do with GOPATH. [06:57] fwereade_: what happens if you do GOPATH="" go build launchpad.net/juju-core/cmd/... ? [06:58] hmm, it just should fail with "pkg not found" i guess [06:58] rog, in PutTools (or whatever that calls) I presume? [06:58] rog, I'll see :) [06:58] fwereade_: yeah. [06:59] fwereade_: so you cleaned out pkg by doing rm -r $GOPATH/pkg ? [06:59] rog, yeah [06:59] fwereade_: i'll see if i can reproduce. were you testing all packages, or just one? [06:59] rog, all packages [07:02] fwereade_: if you clean out pkg, then do "go install launchpad.net/juju-core/...", *then* start the tests, does it then succeed? [07:02] rog: fwereade_ have eithre of you installed gustavo's patch to the go tool ? [07:02] davecheney: nope. [07:03] davecheney, nope [07:03] davecheney: i don't have a huge $GOPATH/src dir, so it's not so important for me [07:03] cool, i have been playing with it, and had some weirdness [07:03] rog, I expect so, I will check [07:04] rog, empty GOPATH just won't build as expected [07:06] fwereade_: hmm, i've got a test that's hanging again :-( [07:06] rog, installed packages work just fine [07:06] rog, bah :( [07:06] rog, which one? [07:06] fwereade_: unrelated [07:06] fwereade_: weird [07:06] fwereade_: i'm not sure - it only prints the test name when the test has timed out! [07:06] the machine: section in juju status isn't actually state.Machines is it [07:07] it environ.Instances [07:07] fwereade_: i'm gonna kill it and see what's happening [07:08] the machines: section is reporting details about the environ.AllInstances [07:08] fwereade_: it's the juju package that's hanging [07:09] rog, huh, weird... won't -gocheck.vv tell you though? [07:09] rog, not so helpful if it's unreliable [07:09] davecheney, sorry, I'm not quite following you [07:09] davecheney, I'm pretty sure status should be telling us about machines, not instances [07:09] the two keys that are reported 'machines' in juju status [07:09] fwereade_: yeah, but i'd already run it without gocheck.vv, and i suspect it's a sporadic failure [07:10] fwereade_: I think they are what we call environ.Instances [07:10] because the first field in the yaml is dns-name [07:10] a property which is only availble on the environ.Instance [07:10] fwereade_: it's actually hanging trying to dial zookeeper [07:10] davecheney, I'm suspicious of that assertion, but juju/control/status.py is a rats' nest so I'll have to check ;) [07:11] fwereade_: pm = yield self.provider.get_machine(instance_id) [07:11] fwereade_: i think that dial should have a timeout actually. it's wrong that zk tries to redial indefinitely. [07:11] i think we have a cleaner separation of machine, the virtual, and instance, the conrete in the go impl [07:11] rog: zk never times out [07:11] it sucks [07:11] davecheney, STM it's only doing that with the machines it already knows about from state [07:12] davecheney: +1 [07:12] davecheney, look 17 lines before that [07:12] fwereade_: as you say, it is an uncomforable union of both concepts [07:13] davecheney, I dunno, I think status info from both is relevant [07:13] davecheney, I think it's ok to smoosh them together there [07:13] fwereade_: thanks for the clarification [07:13] I was hoping to have more to show [07:13] fwereade_: apart from that one test hangup, all the tests worked ok for me after removing pkg. [07:13] davecheney, instances are really an internal detail, but their properties apply to the machines the user cares about [07:13] but all I have tonight is a harness [07:14] davecheney, status is not going to be all that small I'm afraid [07:14] davecheney, probably smaller than the python, but still [07:14] fwereade_: indeed, which is why I put some time into setting up a table driven harness [07:14] davecheney, +1 [07:14] imma signing off in a few minuts [07:14] they are closing the coworking space [07:15] davecheney, enjoy your evening :) [07:15] but I look forward to your comments [07:15] davecheney: have fun [07:15] davecheney: when do you leave for lisbon? [07:16] rog: sunday [07:16] but I don't get there til monday 14:25 [07:16] davecheney: i saw that [07:16] I have NFI how to get from the airport to the hotel [07:16] davecheney: there's some info on the sprint wiki page [07:16] need to get some euros as well [07:17] rog: I could have go there a day erlier for an extra 800 euro, and a detour via CDG [07:17] davecheney: well, i might catch you tomorrow morning then... [07:17] davecheney: marvellous [07:17] davecheney: well, i'm glad you're making it regardless! [07:17] for small values of yay [07:18] anyway, i'll catch you around [07:18] davecheney: i usually order currency from travelex to be picked up at the airport. that way you get the convenience of just picking it up, but a much better rate. [07:19] fwereade_: does malta use euros? [07:19] rog, yeah [07:19] fwereade_: well aren't you lucky then?! [07:19] rog, luckyish :) [07:20] :-) [07:20] rog, my bank is still shit at getting me more money when I need it overseas [07:20] fwereade_: not good [07:20] rog, I usually have to bite down the swears and hit up mygradually dwindling UK funds [07:21] right-o [07:21] have a good day gentlemen [07:21] davecheney: and you. enjoy the evening! [07:21] have a good night davecheney :) [07:21] fwereade_: is that because they don't like you using your card overseas? [07:22] rog, I have a credit card that *works* but is such an aggressively shitty deal that I don't really use it [07:22] rog, they're essentially charging me to borrow the money from myself [07:22] fwereade_: just get cash in advance... [07:23] rog, and I have no way of telling what my "balance" is on it [07:23] rog, I have another one which works only in totally arbitrary circumstances [07:23] fwereade_: another possibility is to get a "foreign currency" card, which you can charge up as required. [07:23] rog, twas sold to me as "this will let you get cash from HSBC machines in the UK without us charging you" [07:23] fwereade_: you get the best rate that way. [07:24] fwereade_: ha [07:24] rog, in practice it *sometimes* works everywhere *except* HSBC machines in the UK, where it never works [07:24] fwereade_: i have a possible idea for why your build might be failing [07:24] rog, I keep meaning to go and shout at them for a host of reasons but I have better things to do with my time ;) [07:24] rog, oh yes? [07:25] fwereade_: i think it must be something in your environment. i'm trying to remember what the gcc heuristics are for finding include files. [07:26] rog, ahhh, yes, that does make perfect sense [07:26] fwereade_: i'm wondering if it's right that bundleTools runs in a clean environment with just GOPATH, GOBIN and PATH set [07:26] rog, I suspect it might be better to just use whatever env the developer is using in the first place [07:26] fwereade_: what happens if you unset everything in your environment except those vars? [07:27] fwereade_: that's what i'm thinking [07:27] fwereade_: ... and then run go install launchpad.net/juju-core/cmd/... [07:28] fwereade_: i'd be interested to find out what var it was, but i think you're right - the fix is to mutate the env, not come up with a new one [07:28] fwereade_: (assuming i've got the right diagnosis, of course!) [07:31] rog, I'm peering at my env and can't see what could be the issue :/ [07:31] fwereade_: i suspect it might be $HOME [07:32] fwereade_: try HOME="" go install launchpad.net/juju-core/cmd/... [07:32] rog, sorry, just a mo [07:39] rog, empty HOME works fine :( [07:42] fwereade_: try applying lp:~rogpeppe/juju-core/go-build-env and see if it works then [07:42] fwereade_: (your go test, that is) [07:42] fwereade_: (the thing that was failing before) [07:43] rog, will do in a sec, thanks [07:45] rog, I have a side issue to ponder: in https://codereview.appspot.com/6402048/ niemeyer suggests a RelationHandler type [07:45] rog, and I'm not actually sure whether *that* has a benefit over putting the methods directly onto Relation [07:45] fwereade_: yeah, i saw that. i haven't thought it over yet though. [07:46] fwereade_: yeah, what fields are in RelationHandler other than the Relation itself? [07:47] fwereade_: oh, hold on, it's got a particular set of relation end points in it [07:47] rog, that's the only way we have to identify/get a Relation in the first place isn't it? [07:47] rog, the endpoint list is equivalent to the relation's name [07:48] * rog does a godoc to remind himself of the API [07:48] fwereade_: yeah that does sound right [07:49] rog, there is *something* up there [07:49] rog, possibly we ought to be doing it with endpoint identifiers rather than actual RelationEndpoints [07:49] rog, and doing the translation internally [07:50] fwereade_: why's that? [07:50] rog, but I'm not sure that entirely fits expected usage [07:50] rog, mainly because that will be a lot more convenient for add-relation and remove-relation [07:51] rog, which is the only time I'm aware of when we do stuff with relations *other than* via something that already exists within state [07:51] rog, which can identify them how it likes internally [07:51] rog, same as the name/key distinction [07:51] rog, btw, go-build-env works great [07:52] fwereade_: ah good. so *something* in your environment is the culprit! [07:53] fwereade_: i'm not sure i get it. RelationEndpoint is part of the public API; why not use it? [07:53] fwereade_: or are you suggesting removing it from the public API? [07:55] rog, I'm not quite sure :) [07:55] rog, possibly it is theright approach, and we just need a State.Endpoint(name string) method [07:56] rog, except, hmm, that's actually State.Endpoints... [07:56] fwereade_: what would it return? [07:56] rog, meh, it'll become clearer as I do more with it [07:57] rog, look, you need a state to construct a meaningful RelationEndpoint, right? [07:57] fwereade_: BTW i'm all for the idea of reducing the number of types in state [07:57] fwereade_: do you? [07:58] rog, yeah, it's all information that comes from the charm [07:58] fwereade_: well, i suppose you hav... yeah [07:59] fwereade_: a relation endpoint is always associated with exactly one unit, right? [07:59] rog, no, with a service [08:00] rog, the user expresses endpoints as service_name[:relation_name] [08:01] rog, and we need to do magic to figure out what endpoints are actually referred to by those strings [08:01] fwereade_: and for a scope=local relation, there's still only one endpoint for the service? [08:02] rog, and possibly barf if they're ambiguous and ask the user to specify the [:relation] bit [08:02] rog, yeah, the endpoints are purely about the connections between services [08:02] fwereade_: so the RelationEndpoint type is about isolating that magic, so that you're dealing with unambiguous things? [08:03] rog, the details of which units actually talk to one another is handled completely separately, although the choice of how to do so is ofc governed by the endpoint's scope [08:03] rog, or rather the narrowest scope present in the endpoints of the relation as a whole [08:03] fwereade_: so you do some magic to produce an endpoint, then use that in the API? [08:03] rog, I don't do anything, we don't yet have add-relation ;p [08:03] fwereade_: will do, then :-) [08:04] rog, but, yeah, that's what we'll have to do [08:04] rog, I'm saying we should have AddRelation(epnames ...string) [08:04] rog, ...probably, anyway [08:04] rog, I'm not 100% sure [08:05] fwereade_: where epnames are potentially ambiguous? [08:05] rog, quite possibly we should actually have State.RelationEndpoints(epnames ...string) ([]RelationEndpoint, error) [08:05] fwereade_: that's Service.AddRelation, presumably? [08:05] rog, yes [08:06] rog, no, State.AddRelation [08:06] fwereade_: ah. [08:08] fwereade_: i'm not sure if that magic needs to be in state [08:08] fwereade_: it seems to me like it's something that can be built using the primitive already available. [08:08] primitives [08:09] rog, yeah, reasonable perspective [08:10] fwereade_: it seems to me like that's the meat of the logic of add-relation [08:10] fwereade_: and it could sit happily in the juju package [08:10] rog, ok, I think I'm convinced, thanks :) [08:10] fwereade_: then the state API is still very general [08:11] fwereade_: cool [08:11] rog, (also the meat of remove-relation) [08:11] fwereade_: but... i'm not sure we've answered the original question [08:11] rog, (although I suspect we should have a slightly different algorithm there) [08:11] fwereade_: should RelationHandler just be Relation? [08:12] fwereade_: ah, no, it can't be [08:12] rog, I'm leaning towards "yes" [08:12] rog, really? bother [08:12] fwereade_: because it's more than a relation - it encapsulates a set of units cooperating in a relation [08:13] rog, all that is implicit in the *Unit params to the methods, innit? [08:13] fwereade_: so for locally scoped relations, you'll have a RelationHandler for each machine running the service [08:14] rog, no you won't [08:14] fwereade_: no? [08:14] rog, you just do rh.Join(localUnit); rh.Watch(localUnit), surely? [08:14] rog, ok, the name of Watch is sl. misleading [08:15] rog, WatchAsThoughYouWere(localUnit) ;) [08:15] rog, the rh itself is the "same" object regardless of what UA is running it [08:15] fwereade_: but if all machines have also doing rh.Join, won't we see changes from all machines? [08:16] rog, well, in a global relation, yes; in a locally scoped relation, no [08:16] oh i think i see [08:16] rog, it figures out what scope to watch from the unit we pass in [08:16] rog, ie it finds all the units in the same scope as the one suggested [08:16] fwereade_: you're relying on the fact that every time we get a relation, it's freshly made [08:16] rog, expand please [08:18] fwereade_: are you saying that the Join method doesn't actually affect the state at all? [08:18] hmm, i think i'm confused [08:19] rog, no, I'm not, but I can't connect that with what you're asking [08:19] rog, that would not surprise me, I *think* I now get relations, but it has been a somewhat arduous path [08:19] fwereade_: i'll try and recap; tell me where i go wrong. [08:20] rog, cool [08:22] fwereade_: someone does add-relation svc1:relation1 svc2:relation2; we look up the endpoints for both of those, and call State.AddRelation with those. [08:22] rog, yes [08:23] fwereade_: the unit agent on each machine sees the new relation and calls Join on it. [08:24] rog, yes [08:24] fwereade_: the unit agent runs the relation1-relation-joined hook. [08:24] rog, no [08:25] ah, no i see [08:25] rog, a *different* unit agent runs that hook when it detects that the first UA called Join [08:25] of course [08:25] fwereade_: ok, the unit agent see *anouther* machine that has called Join on the new relation. [08:25] rog, yep [08:25] fwereade_: so it runs the relation1-relation-joined hook. [08:26] rog, (ofc it only sees *that* because it's watching the relation from its own perspective, by having called Watch(itsOwnUnit) [08:26] rog, yes [08:26] fwereade_: but how does this work with locally scoped relations? [08:27] rog, the state.unitScopePath is at the heart of it [08:27] rog, are you familiar with the contents of the /relations/relation-XXX node? [08:27] fwereade_: remind me :-) [08:28] rog, if it's a globally scoped relation, it has a settings subnode, and a subnode for each role in the relation [08:28] rog, if it's container-scoped, it contains a subnode for each container that holds some unit participating in the relation, and each of those container nodes contains the role and settings nodes [08:29] rog, when watching, or joining, on behalf of a given unit, we figure out what the role-and-settings-parent node is for that unit, based on the relation's scope and (maybe) the unit's container [08:29] rog, and then we just watch/write to the contents of that tree [08:30] rog, (note: the top-level relation node of a container-scoped relation does *not* have role or settings nodes) [08:30] rog, make sense? [08:31] rog, (similarly, the Settings(*Unit) method does the same thing) [08:32] fwereade_: ah, so the Join method does the magic based on the unit [08:32] rog, yes; really, *every* Relation(Handler)? operation depends on a specific unit to get the appropriate perspective [08:32] fwereade_: BTW unitScopePath doesn't actually seem to be used anywhere [08:33] rog, update your tree :) [08:33] fwereade_: ah ha! [08:33] rog, and then for examples of actually constructing a useful one, take a look at the relation-unit branch itself [08:34] rog, in Unit.AgentJoin [08:36] rog, it's very small but I'm rather pleased with it [08:36] rog, the python seems to do path-hackery all over the place :) [08:36] fwereade_: ok, so i *think* i understand now, and it seems reasonable then that the methods should be directly on the Relation. [08:36] rog, cool [08:37] rog, I think I'll talk about it with niemeyer too, but it's good to know I'm not *obviously* all underpants-on-head about it ;) [08:38] fwereade_: how would Relation.Join(unit) differ from Unit.AgentJoin(relation) BTW? [08:39] rog, it's only responsible for the Pinger [08:39] rog, AgentJoin does both the pinger *and* the watching *and* gives access to the settings node [08:40] rog, I *suspect* we'll still end up with something similar in effect to the RelationUnit but I can't see far enough into the future to be sure [08:41] rog, the precise types we need to sling around will become clearer as I work on the queuing and tie it into cmd/jujuc/server.ClientContext [08:42] fwereade_: if RelationHandler is actually Relation, then it seems like we've managed to lose a type, which sounds like a good thing. [08:42] fwereade_: well, lose a public type anyway [08:42] rog, yeah, I think so [08:43] fwereade_: i'm definitely +1 on that [08:43] rog, cool :) [08:43] fwereade_: i think Join, Settings and Watch on Relation is an easier thing to understand [08:43] fwereade_: i hadn't quite grasped what a RelationUnit actually *was* :-) [08:44] rog, and we don't have ServiceRelation any more, I never really understood what that was either ;) [08:44] fwereade_: cool :-) [08:45] * rog likes it when an API comes together [09:05] fwereade_: https://codereview.appspot.com/6421045 [09:06] rog, LGTM [09:07] * fwereade_ tuts in niemeyer's general direction [09:07] (config gofmt ;)) [09:08] * fwereade_ suddenly grasps the full horror of how the tests will look if he tries: [09:08] var hookQueueTests = []struct { [09:08] adds []state.RelationUnitsChange [09:08] gets []relationer.HookInfo [09:08] }{ [09:09] ...given that: [09:09] / RelationUnitsChange holds settings information for newly-added and -changed [09:09] / units, and the names of those newly departed from the relation. [09:09] type RelationUnitsChange struct { [09:09] Changed map[string]UnitSettings [09:09] Departed []string [09:09] } [09:09] / UnitSettings holds information about a service unit's settings within a [09:09] / relation. [09:09] type UnitSettings struct { [09:09] Version int [09:09] Settings map[string]interface{} [09:09] } [09:09] ...and: [09:09] / RelationUnitsChange holds settings information for newly-added and -changed [09:09] / units, and the names of those newly departed from the relation. [09:09] type RelationUnitsChange struct { [09:10] Changed map[string]UnitSettings [09:10] Departed []string [09:10] } [09:10] / UnitSettings holds information about a service unit's settings within a [09:10] / relation. [09:10] type UnitSettings struct { [09:10] Version int [09:10] Settings map[string]interface{} [09:10] } [09:10] * fwereade_ ponders grumpily [09:34] morning [10:23] rog: Btw, your log-tracking-testing will soon fly into the trunk. Just doing the final steps. [10:24] TheMue: cool. i saw gustavo's remarks, and breathed a sigh of relief that he thought it was ok :-) [10:24] TheMue: morning, BTW! [10:25] rog: morning and yes, it's indeed a nice idea. didn't thought so in the beginning, but seeing it in real life feels good. [10:26] TheMue: it went through a couple of more complex iterations before it arrived at the paste i gave you. i'm quite happy how it turned out actually. [10:28] fwereade_: erm, you pasted the same thing twice [10:28] fwereade_: did you mean to post the HookInfo type definition? [10:28] rog, oh, blast, yeah [10:28] type HookInfo struct { [10:28] Name string [10:28] RemoteUnit string [10:28] Members map[string]map[string]interface{} [10:28] } [10:28] rog, but not to worry, it's readable now [10:29] rog, there are rather a lot of cases to deal with, though ;) [10:39] fwereade_: what are the names in RelationUnitsChange.Departed, BTW? unit names? [10:39] And once again heavy rain. Hey, weather god, it's enough! [10:42] TheMue: you'll be too hot next week! [10:42] rog: Yes, I've seen, and I promised my family to bring some good weather with me like from Oakland. [10:43] fwereade_: also, it seems odd that RelationUnitsChange gives no way of telling *which* unit changed. is that because we don't need to know? [10:43] rog: Tomorrow the school holidays begin, so it *has* to change. ;) [10:50] ec2 ssd instances! [10:50] http://aws.typepad.com/aws/2012/07/new-high-io-ec2-instance-type-hi14xlarge.html [10:52] TheMue: we haven't really had a summer here. it's been continual rain. and when i got back, found that there'd been some serious rain while we were away: http://www.youtube.com/watch?v=huCnxI8qDb0 http://www.youtube.com/watch?v=lpJVTCLHKUE [10:53] hazmat: sounds expensive :-) [10:54] rog, depends on if you need it.. netflix reduced their costs by half for the same throughput on a benchmark.. http://techblog.netflix.com/2012/07/benchmarking-high-performance-io-with.html [10:55] hazmat: interesting [10:55] rog: Hard storms, yes. We had some of those in July too. May/June have been some wonderful warm days where I worked on the veranda. [10:58] Hmm, Gavin Harrison really motivates me to realize an old dream: learn to play drums. [10:58] He's the drummer of Porcupine Tree. [11:01] fwereade_: i don't think you'd need an intention log per relation [11:01] fwereade_: i *think* that one log would suffice [11:03] TheMue: one forecast i saw had it at 37 degrees in lisbon on one day [11:09] rog: ouch [11:09] TheMue: but mostly around 30, which is bearablew [11:09] s/w// [11:16] rog: Yes, just took a look too. 30 is fine [11:24] rog, sorry, lunch :) [11:24] fwereade_: np! [11:25] rog, RelationUnitsChange has Changed map[unitname]info, Departed []unitname [11:26] rog, you're expected to know which relation changed because you started watching a particular relation [11:26] fwereade_: ah, i think the documentation should mention that the key of Changed is the unit name :-) [11:26] rog, sensible, cheers [11:27] fwereade_: i glanced at it my brain said "attribute name" [11:27] rog, I thought it kinda went without explicitly saying when I wrote it but it could certainly be clearer [11:27] fwereade_: some of are stupider than you might think :-) [11:28] rog, I'm interested to hear about your further thoughts on intention logs though [11:29] rog, (sorry I had to dash yesterday) [11:29] fwereade_: np [11:30] fwereade_: i'm thinking that when we get an error executing an intention, we can write "broken" to the intention log. [11:30] fwereade_: that doesn't stop the updates coming through the queue for that relation, of course. [11:30] fwereade_: but i'm reconsidering if having the queue in a separate goroutine is the right approach after all [11:33] rog, sorry, I'm not coming up with any responses [11:34] fwereade_: that's fine, it's all vapour anyway :-) [11:34] fwereade_: just my vague thoughts on the matter. you're much closer to the problem. [11:35] rog, I am definitely having difficulty visualising an intention log with the unit lifecycle state and all the relation lifecycle states and brokens and dones and collapses and resolve-handling :) [11:35] rog, collapses and resolves, in-memory, for a single relation, is occupying most of my brain ATM :) [11:37] rog, I think I have something that will work and be easy enough to extend to handle process bounces, but we'll see [11:44] fwereade_: this kind of API, perhaps? http://paste.ubuntu.com/1099903/ [11:46] rog, ATM I have http://paste.ubuntu.com/1099905/ [11:48] fwereade_: i'm not sure just RelationUnitsChange is enough, as it doesn't hold the name of the relation that changed. [11:48] fwereade_: of course, it could get that [11:49] rog, I'm assuming one of these per relation [11:49] rog, and that the client should know what relation they're dealing with [11:50] fwereade_: that sounds good actually [11:50] rog, it's about all I can fit in my head ATM :) [11:50] :-) [12:28] niemeyer: yo! [12:29] Morning! [12:30] niemeyer: Heya [13:10] niemeyer: what if there's already a setting for GOBIN in the environment? are later entries guaranteed to override earlier ones? [13:12] niemeyer, heyhey! [13:13]