[00:16] mgz_: thanks for your help [00:16] this is working a treat [00:16] davecheney: ace [00:16] a few small issues and i'll be able to land this branch [00:16] thumper: a pint of grog for mgz_ ! [00:21] awesome [00:43] hmm.... [00:43] I'm seeing state/leadership package sometimes timeout after 20 minutes [00:43] * thumper smells race [00:43] but my --race doesn't work [00:59] it's totally possible to have logical races without memory races [01:03] sure [01:57] thumper: why discard that PR about server->controller? is that rename not happening anymore? [01:57] axw: it is, but I'm going to retarget it against the new 'controller-rename' feature branch [01:57] as I feel that I'm going to break CI [01:57] thumper: okey dokey [01:57] especially as I change some of the command stuff [01:58] and remove the feature falg [01:58] so I thought I retarget it all [01:58] hopefully a very short lived feature branch [01:58] as conflicts against master are going to be a biatch [01:59] thumper: did you see my latest email about multi-env vs. azure? [02:00] I think so [02:00] * thumper goes to look again [02:01] thumper: did not get a reply. just curious about how we're supposed to do create/destroy when an env has resources shared between machines [02:01] setup/teardown, a la bootstrap/destroy [02:01] like what? [02:01] thumper: in the case of azure: a resource group, subnet, network security group, storage account [02:02] thumper: each env will have its own everything, except for a single virtual network that all envs are connected to [02:02] ok... [02:03] well, shouldn't we just hook into the create environment, and destroy environment endpoints? [02:03] when we destroy a controller, we take down all the hosted environments first [02:03] axw: waigani has been refactoring all our destruction code so it is nicer and more async [02:03] thumper: yeah, but atm EnvironProvider just has "PrepareForCreateEnvironment" - I'm using htis but it doesn't feel quite right [02:03] thumper: sounds good [02:04] you should use the create environment, not the prepare [02:05] thumper: there is no "create environment" in EnvironProvider, at least not on master. maybe in a feature branch? [02:05] where are you looking? [02:05] hmm... [02:05] thumper: https://github.com/juju/juju/blob/master/environs/interface.go [02:05] * thumper thinks... [02:05] * thumper looks [02:07] axw: actually, there is currently no function we call at all in the provider when creating a new environment [02:07] before there was never anything to execute [02:09] hmm... [02:09] thumper: so I think we need a CreateEnvironment as well as a PrepareForCreateEnvironment [02:09] I think you may be right [02:09] * thumper greps for the Prepare... [02:09] thumper: PrepareForCreateEnvironment is called (twice), and it is usable [02:09] hmmm [02:10] yeah, checking for valid Config [02:10] thumper: i.e. I've got multi-env working in azure [02:11] axw: it feels better to have a separate CreateEnvironment call [02:11] that we call just once [02:11] thumper: +1 [02:12] thumper: also, it's not obvious why Prepare is called twice (once before assigning UUID, once after) - would be good to have better docs on that [02:12] I believe it is the two step call we do [02:12] which we are looking to fix [02:12] the first is to ask for a config skeleton [02:13] and then the validation when the user passes it back [02:13] but to be honest, I'm not entirely clear [02:13] we are wanting to make the juju cli do the same as jem [02:13] and have all providers supply the configschema [02:13] oh... [02:13] can you make the new azure provider supply the configschema? [02:14] not sure if the old one did [02:14] thumper: it didn't. I'll add it to the list. [02:37] axw: here is that branch retargeted to the controller-rename branch http://reviews.vapour.ws/r/3053/ [02:54] axw: small one if you have a moment https://github.com/juju/charmrepo/pull/36 === natefinch-afk is now known as natefinch [03:44] thumper: http://reviews.vapour.ws/r/3054/ [03:44] thumper: adds "no tail" support to state.LogTailer [03:44] * thumper looks [03:48] menn0: why do we need to call tailer.Stop when we said "don't tail" ? [03:50] thumper: you don't ... [03:51] thumper: it's just in case the tailer isn't working during tests [03:51] thumper: like when I wrote the test but NoTail wasn't implemented yet [03:51] thumper: happy to reemove it if you think it's confusing [03:51] perhaps just a comment would be enough [03:52] * thumper sighs [03:52] state/leadership is failing for me again... [04:01] thumper: i've responded to the review [04:06] wallyworld: reviewed [04:06] ty === Ursinha-afk_ is now known as Ursinha === Ursinha is now known as Guest82331 === psivaa_ is now known as psivaa === Guest82331 is now known as Ursinha === Ursinha is now known as ursula1234 === ursula1234 is now known as Ursinha [04:22] waigani: http://reviews.vapour.ws/r/3056/ [04:22] waigani: it is the earlier branch retargetted and many of the missed systems renamed too [04:30] Bug #1454466 changed: Deployment times out waiting for relation convergence - nvp-transport-node in installing state

[04:30]

[04:33] Bug #1454466 opened: Deployment times out waiting for relation convergence - nvp-transport-node in installing state

[04:33]

[04:36] Bug #1454466 changed: Deployment times out waiting for relation convergence - nvp-transport-node in installing state

[04:36]

[04:39] thumper: shipit with a question about "controller environment" [04:59] thumper: menn0 axw http://reviews.vapour.ws/r/3057/ [05:01] davecheney: shipit [05:02] axw: that was awfully fast! [05:02] boom [05:02] menn0: awfully easy review :) [05:02] -2700 lines -> ship it! [05:02] heh [05:02] I think axw has a bot that just automatically replies with ship it [05:02] ;) [05:03] in seriousness, I wish we had one for back/forwardports [05:04] or a way to just not post to RB [05:05] axw: sorry, one more https://github.com/juju/charmrepo/pull/37 [05:08] wallyworld: you should probably use yaml.v1, it's in dependencies.tsv [05:09] axw: ah, yeah, thanks === bodie__ is now known as bodie_ [08:11] ericsnow: ping? [09:00] axw, I think you're probably right re manifold-in-different-package, but I'm really reluctant for some reason [09:01] axw, possibly because so many others are not yet sufficiently separate from their worker packages as to cleanly accommodate that? [10:02] dimitern, dooferlad: standup? [11:10] fwereade_: sorry, I was away from IRC. I'm of two minds. On the one hand, it's obviously inherently tied to the worker, but on the other, it has a separate role to play (policy over starting the worker, and connecting the worker to other things). I think having it in a separate package just keeps the responsibilities clearer [11:31] axw, yeah, I think you're right. subpackage is probably not *really* the right place, but close enough for now [12:16] perrito666: thanks [12:18] voidspace: yw [12:18] * perrito666 overslept, rainy day, fresh drapes, impossible not to [12:21] cherylj: hi, could you please take a look at http://reviews.vapour.ws/r/3063/ when you have time? [13:26] fwereade_: I realized late that alexisb moved our meeting time (relative to my tz at least). I need to take the dog out, but will try to be back for the meeting === niedbalski_ is now known as niedbalski [13:45] jam, we dropped but I am here if you want to chat post dog walk [13:45] Hello, I am trying to build the packages from source, how can i download the dependency packages individually instead using the makefile ? [13:47] alexisb: hiya. I don't have anything specific. You dropped the meeting for today? [13:47] jam, fwereade_ and I met for a moment and then dropped [13:50] alexisb: you realize you really have nothing to say to eachother without me ? :) [13:51] jam, so very true ;) [13:58] frankban: did you have any write up on using the new bundle support that can go out into the release notes for 1.26-alpha1? [14:11] rogpeppe, do you recall why EnvironObserver has a mutex, and replaces its environ, instead of doing a SetConfig? environs are meant to be goroutine-safe... [14:12] rogpeppe, (I know it's from, what, 20 months ago :)) [14:19] cherylj: no I don't but I can get it prepared [14:19] frankban: that would be great. Just enough to tell people it's there and how they can use it. [14:21] cherylj: cool, Makyo ^^^ would you like to prepare something about bundle deployment in core? [14:22] cherylj: will you have time to look at the branch today? [14:25] fwereade_: i'll have a look [14:25] rogpeppe, cheers [14:28] fwereade_: even if an Environ itself is goroutine-safe, a worker still doesn't want it changing underneath itself with no warning [14:32] frankban: yes, I can. I see you have two ship it reviews already. Did you still want me to take a look? [14:33] cherylj: yes please, I need a review from a core developer [14:33] frankban: ah, ok. Will look at it this morning [14:34] cherylj: ty! [14:41] rogpeppe, sorry, why not? [14:42] rogpeppe, isn't that the point of it being goroutine-safe, that someone updating the config should be no cause for concern? [14:42] bother [14:47] rogpeppe, sorry, bad timing before [14:48] fwereade_: np [14:48] rogpeppe, what's the problem with the environ config being updated under a worker? I rather thought that was the point of the boroutine-safety? [14:49] fwereade_: if i'm writing a worker, i might be doing something on the basis of one attribute, but another attribute might change underfoot so it's inconsistent [14:49] fwereade_: i think it's better if the config is treated as immutable [14:50] Bug #1513084 opened: 1.20 cannot upgrade to 1.26-alpha1: run.socket: no such file or directory <1.20>

[14:50] rogpeppe, that sounds like a problem with the Config method alone then? [14:51] rogpeppe, (also: if a worker's depending on env config values from the env, not from state, isn't it already confused?) [14:53] fwereade_: if that's an issue, why are we creating the env at all? [14:53] rogpeppe, to call methods that do something to the substrate [14:53] fwereade_: ok, so those methods will depend on env config values in the env, right? [14:54] rogpeppe, yes, but that's the env's problem, not the client's [14:54] fwereade_: so should the worker rely on two sources of truth for the config values from the state - the env and another watcher? [14:56] fwereade_: currently a worker needs only to use the EnvironObserver, which gives it the config values from state (and an environment that can use them) [14:56] Bug #1513096 opened: invalid agent version in environment configuration: "1.26-alpha1"

[14:57] rogpeppe, what's the overlap between worker-relevant values and env-relevant values? [14:57] fwereade_: i don't know. but i wouldn't want to rely on there being none ever [14:58] fwereade_: having a single place to watch seems like a reasonable thing to me [14:58] rogpeppe, in practice, what the EnvironObserver is used for is to create an environ, hand it over to instancepoller, and never update it [14:58] rogpeppe, the instancepoller doesn't remotely care about what wwe're doing in the background, it just wants its instancegetter to work [14:59] fwereade_: i'm slightly surpised the provisioner worker doesn't use it [14:59] rogpeppe, what would the point be? if it doesn't update the environ we still have to thread env-watching through every worker [15:00] rogpeppe, if it simplified its clients, then it'd be great, but as it is there's no reason to switch implementations to use that afaics [15:03] fwereade_: presumably the provision *does* update its Environ when the environ config changes? [15:03] fwereade_: ah yes, it does [15:05] rogpeppe, yeah -- and that one is also sl. different in that it has an interest in actual juju-model config as opposed to just the substrate config [15:05] rogpeppe, but I'm pretty sure that if it's paying attention to the substrate config it's DIW somewhere [15:06] fwereade_: "dead in water" "doing it wrong" ? [15:06] rogpeppe, the latter was my intent :) [15:06] fwereade_: it feels a bit racy to me [15:08] rogpeppe, only if the environ itself is, surely? [15:08] fwereade_: not really. [15:08] fwereade_: i don't like state changing underfoot [15:09] fwereade_: i mean, it's *probably* ok [15:10] rogpeppe, I feel like the biggest worry is that few environs have ever been actually used from multiple goroutines, so their safety is not battle-tested [15:11] fwereade_: there should be at least one cross-environment test that's designed to trigger the race detector in such cases [15:13] rogpeppe, sure, but the number of ways to subtly break safety tends to overwhelm any but exhaustive/invasive testing, and I don't think we really have anything sophisticated enough [15:13] fwereade_: ah, i was being confused by the configObserver - it's only there for testing [15:13] fwereade_: if a provider doesn't simply use a mutex, it's probably doing it wrong [15:14] fwereade_: and that simple mutex logic can be easily tested with the race detector [15:14] rogpeppe, there's another way to approach it that I quite liked, but forget the details of [15:14] fwereade_: i tend to just make a test like: go setConfig(); go getConfig(); go setConfig(); go getConfig() [15:15] fwereade_: which will trigger a failure in the race detector if the appropriate mutexes aren't used [15:15] rogpeppe, right, but that's just 2 methods and still rather luck-dependent [15:16] fwereade_: true that it's only 2 methods (it should probably be all of 'em), but i don't think it's that luck dependent [15:16] rogpeppe, I accept it'll probably fail most of the time, but I doubt it'll be 100% :) [15:16] fwereade_: why wouldn't it be? [15:18] rogpeppe, it might happen to run them all serially by sheer coincidence, and never happen to flag the issue -- is it smarter than that? I thought it erred in fvaour of false negatives [15:18] fwereade_: even if it runs them all serially, the race detector will flag it [15:19] * fwereade_ scrubs that bad data out of his brain then [15:19] fwereade_: of course you can get false negatives if the code never actually accesses the memory in question [15:19] rogpeppe, cool [15:19] fwereade_: it's a pretty good tool [15:19] rogpeppe, yeah, but that's not the case here [15:19] fwereade_: i'm a big fan of race-detector-oriented tests [15:20] rogpeppe, indeed, I have a deep and abiding love for the race detector [15:20] Bug #1511822 changed: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed

[15:20] Bug #1513096 changed: invalid agent version in environment configuration: "1.26-alpha1"

[15:20] rogpeppe, ok, so, some go-spam-every-method tests would be good in general [15:26] fwereade_: so presumably your motivation for the initial question was wondering why the instance poller aggregator isn't seeing env config changes? [15:27] rogpeppe, not so much, actually, I came across that later -- I was more thinking of running a separate EnvironObserver that *could* be shared by the various workers that use environs [15:28] fwereade_: well, the current one can be in fact [15:29] fwereade_: you could do the SetConfig locally in each worker as desired [15:29] rogpeppe, don't think so? there's only one Environ in the observer [15:29] fwereade_: each worker would have its own Environ [15:30] rogpeppe, that's what I'm trying to get away from [15:30] fwereade_: for reasons of efficiency? [15:31] rogpeppe, more that the env-watching is unnecessary extra complexity in a bunch of different workers [15:31] rogpeppe, and yeah, there's some efficiency improvement as well [15:32] rogpeppe, and it opens the door to us being able to actually manager rate limits sanely, instead of having a herd of N environs stampeding to talk to the same endpoint from a single agent [15:32] fwereade_: the difficulty is that it's all bound up with environ config and that smears a bunch of semi-related attributes together [15:34] fwereade_: i'm toying with the thought that workers shouldn't ever look at the environ config directly at all [15:34] rogpeppe, I do agree that env config is a mess; but AFAICS the potential for harm comes from people using the environ config -- ha, yeah [15:34] rogpeppe, can you think of any legitimate uses for .Config() for a client? :) [15:34] fwereade_: but instead have the parameters passed in and derived from the config [15:34] rogpeppe, yeah, absolutely [15:35] fwereade_: then you'd probably need to restart the worker when config relevant to it changed [15:35] rogpeppe, we just want to pass in something that knows how to ask for instances, and which isn't all whiny and needy about being updated by the same client who wants instances [15:35] rogpeppe, still not really understanding why not to SetConfig and be done with it? [15:36] rogpeppe, in the observer, I mean [15:36] fwereade_: SetConfig and use chan struct{} ? [15:36] rogpeppe, no, I don't want the clients to have to care about environ config at all [15:37] fwereade_: that's ok iff there's no overlap between the attrs used by the worker vs those used by the provider [15:38] fwereade_: i wonder what it would take to split 'em [15:38] rogpeppe, well, at least in the instancepoller case, it doesn't care about env config at all [15:38] fwereade_: i'm more thinking of the provider case actually [15:38] rogpeppe, in the provisioner case all I can think of is, uh, instance-reaping mode, whatever it's called [15:38] sorry [15:38] provisioner [15:38] fwereade_: yeah [15:39] rogpeppe, which the provisioner shouldn't really know is to do with the env config anyway, it shoudl just be watching/asking for reaping mode [15:43] fwereade_: one way to be more sure that the workers aren't doing anything untoward might be to make the Environ with Config and SetConfig methods that return an error or panic [15:52] rogpeppe, mm, yeah, I will poke around in that direction and see what happens [15:53] fwereade_: that wouldn't be compatible with logic doing type inspection of the Environ, but i would hope that nothing is doing that anyway (and i've always considered it seriously misguided in the places we *are* doing it) [15:53] s/hope that nothing/hope that nothing in the workers/ [15:55] rogpeppe, yeah [16:04] gc.ErrorMatches is horrible and bad, and anyone who uses it should feel bad. [16:05] natefinch, gtg out, would still be interested to hear more on this -- I'd say that *overbroad* ErrorMatches~s are the usual problem? [16:06] fwereade_: the only time the *text* of an error message matters, is if it is shown to a user... which 99% of the time it is not [16:06] fwereade_: we use it as a shorthand for "I expect this specific error to be returned" [16:07] fwereade_: which is not what is actually being tested [17:11] natefinch: i disagree. i think it's really helpful to see what our errors look like [17:13] natefinch: the alternative is often just asserting that the error is non-nil, which isn't very helpful (i have discovered lots of places where we generated a really stupid or malformed error which we never knew about because of that) [17:15] rogpeppe: the problem is that asserting the error message asserts a ton of information you don't actually care about. Like how certain types serialize into strings, like how many levels of abstraction there are between you and the origin of the error [17:16] natefinch: yes, i agree. that can be problematic too. but i think the upside of seeing what your error messages actually look like outweighs that. [17:16] natefinch: i often finish an ErrorMatches string with .* [17:17] natefinch: i've found the error string thing really helpful recently - i found one error that was mentioning the same URL 3 times in the same error message. [17:18] natefinch: crafting decent error messages is important for the user experience [17:18] natefinch: and the tests are usually the only place *we* will ever see them [17:19] natefinch: if it hadn't been for ErrorMatches, we wouldn't have made the recent fix to the charm error messages ("charm or bundle not found" vs "entity not found") caught when ian was reviewing our juju-core changes in response to a charm dep update [17:21] rogpeppe: sure, there are times when we show errors to users, and in those cases, error text matters.. but we use ErrorMatches *everywhere* in places we know the user will never see the message (logs don't really count). [17:22] natefinch: logs definitely count [17:22] rogpeppe: not down to the letter [17:22] natefinch: so what would you do? just check that the error isn't nil? [17:23] rogpeppe: no, check what you actually care about, that we detected a specific type of error and failed in an expected way. Use a custom error type or something. [17:23] natefinch: another issue i found recently was where an API test wasn't actually testing what it thought it was - the error was for an entirely different reason. [17:24] natefinch: i don't think we should need a custom error type or value for every kind of error we want to test for [17:24] rogpeppe: the thing that brought this up for me was that a test started failing on master because I added a level of indirection, so the error message had an extra section of "while you were doing foo:" [17:24] natefinch: yes, that's definitely the down side [17:24] natefinch: it does make for more churm [17:24] natefinch: but i still think it's worth it [17:25] natefinch: (and i have thought about this quite a bit when making similar changes) [17:25] rogpeppe: and the problem is that no one is actually thinking about what the error message says or means. For example, to fix that test, I just copied what the new text is from the error and pasted it into the regex. That's not really making our code or tests better. [17:26] rogpeppe: imagine if we decided to change how tags print out, so now they print out as "tag: foo/0" ... we'd have thousands of broken tests. [17:26] natefinch: when you did that, i hope you asked yourself the question "does this error accurately and reasonably represent the error that's being tested for?" [17:27] natefinch: yes we would [17:27] natefinch: but if we changed the representation of tag.String we'd have lots of other issues too [17:29] rogpeppe: but there would be 1000 failing tests that are failing because they're testing something they don't actually care about. certainly there are places that care what tag's String() function outputs... but that's not the only tests that would fial. [17:29] natefinch: yes, it's a tradeoff [17:30] natefinch: but i don't see a better alternative [17:30] rogpeppe: checking for specific error types (a la os.IsNotExist and errors.IsNotFound) [17:31] ericsnow: so every different error message should have its own error type? [17:31] rogpeppe: no, but they shouldn't all be effectively bare strings either [17:31] rogpeppe: arguably one for each equivalence class of error [17:32] ericsnow: how do you decide that? [17:32] rogpeppe: through bikeshedding [17:32] ericsnow: and adding hundreds of different error types is a serious maintenance burden [17:33] rogpeppe: unlike hard-coding checks for error strings ;) [17:33] ericsnow: at least that's only in the tests and easily changed [17:33] ericsnow: the problem with having error types is that they're a burden on every developer and need to be maintained as part of the API [17:34] ericsnow: but often a given error might only have meaning within the context of a given implementation [17:34] rogpeppe: I'd argue that the errors you get *are* part of the API [17:34] ericsnow: i agree totally [17:34] ericsnow: and i think that any API should think very hard about the set of error types it exposes [17:34] rogpeppe: definitely [17:35] ericsnow: which doesn't mesh well with tests that want to test internal functionality [17:36] rogpeppe: agreed, though often having to test internal functionality is a code smell [17:37] rogpeppe: regardless, as you said there are tradeoffs [17:37] ericsnow: if you're aiming for high coverage, you have to do that in practice [17:37] ericsnow: (and i think aiming for high test coverage is worthwhile) [17:37] rogpeppe: I'll leave it to katco to expound the higher plane that is dependency injection :) [17:38] rogpeppe: and I couldn't agree more about the importance of high test coverage [17:38] quick, look over there! [17:38] * rogpeppe looks at the pretty birdy [17:38] I'm with roger on internal tests. I think they greatly increase the confidence you can have in your tests. They make writing tests immensely faster, and they prevent you from mangling your exported API just to support testing. [17:39] does anyone remember what the environmental var is for tabular status? [17:41] katco: maybe JUJU_CLI_VERSION=2 ? [17:42] katco: (haven't tried it, just scanned the code) [17:42] that works [17:42] rogpeppe: ty [17:42] katco: np === ericsnow is now known as ericsnow_afk [18:08] Bug #1513165 opened: Containers registered with MAAS use wrong name [18:17] Bug #1513165 changed: Containers registered with MAAS use wrong name [18:19] katco: got a sec? bug 1512399 [18:19] Bug #1512399: ERROR environment destruction failed: destroying storage: listing volumes: Get https://x.x.x.x:8776/v2//volumes/detail: local error: record overflow

[18:20] why does the autogenerated cinder stuff have "https://cinder.example.com" in it at all? can't it just have the path? [18:20] Bug #1513165 opened: Containers registered with MAAS use wrong name [18:20] issue is the calling code overrides the host, but not the scheme [18:21] so, it breaks if the endpoint is not https [18:23] Bug #1513165 changed: Containers registered with MAAS use wrong name [18:26] Bug #1513165 opened: Containers registered with MAAS use wrong name [18:32] katco: "Pull request successfully merged and closed. You’re all set—the natefinch:assign-worker branch can be safely deleted." [18:41] mgz_, cherylj has been looking at lp 1512399 [18:41] alexisb: it's easy to fix, it's just katco's autogenration code needs changing to take an endpoint rather than do this weird overriding [18:42] wanted to check with her before hacking it [18:42] mgz_, ack [18:42] I will stay out of it, thanks [18:42] alexisb: no worries [18:46] mgz_: natefinch: sorry was eating lunch [18:46] natefinch: grats... feel like we should throw a party or something :p [18:46] katco: right? :) [18:46] mgz_: i believe axw has already modified the auto-generated code, so further modification is probably ok [18:47] ...that's more like not okay then, unless he pull requested back to your repo? [18:47] oh, or you mean he modified the generated file? [18:48] mgz_: yes i think so [18:48] yeah, seems like that... mehp, that make updating more annoying [18:50] looks trivial [18:50] mgz_: fwiw he asked first. we were both busy and i think the cinder project made some modifications that broke auto-generation w/o looking into it [18:50] beautiful, this is what mongorestore says when file not found: don't know what to do with file [18:50] mgz_: but yes, because of the layering approach, it should be very trivial :) [18:50] katco: anyway, the code just needs to build urls in a sane way [18:51] mgz_: should just have to modify protocol here: https://github.com/go-goose/goose/blob/v1/cinder/client.go#L25-L33 [18:51] an endpoint is not just a host, it's a scheme+host+path that you then append a path to [18:51] mgz_: still, just need to modify that 1 function [18:52] mgz_: and that's not even auto-generated code. that's goose [18:52] katco: just + req.URL.Scheme = endpoint.Scheme in SetEndpointFn works for the bug as reported, but that code is still wrong [18:52] mgz_: modify the path in the same place [18:52] the auto gen code should append paths to the endpoint [18:53] and having hardcodes fake urls is ugly. [19:07] katco, ericsnow_afk, wwitzel3: the tech debt bug to fix the tests: perrito666: nice error message [19:07] lol wrong copy [19:07] http://reviews.vapour.ws/r/3068/ [19:13] wwitzel3: why does the package_test.go file need a +build go1.3? [19:13] the card said it did? [19:14] I foobar'd my go install trying to install 1.2 so I could test the build flags [19:15] so I'm playing with that right now, when I threw it at the bot through, it still didn't work, so I missed some [19:15] natefinch: feel free to give it a try if you have 1.2 [19:15] wwitzel3: install go from source, it's easy and easy to switch versions [19:16] (switching versions is just git checkout go1.2 and then make.bash) [19:17] * natefinch just switched from 1.4 to 1.2 in like 10 seconds) [19:21] wwitzel3: every file that imports github.com/lxc/lxd is going to have to be +build go1.3 ... and every file that imports anything those files [19:24] natefinch: so if the file that imports lxd is go1.3, all the files in the lxd package still have to have it? [19:24]