=== wedgwood is now known as wedgwood_away [06:14] jtv1: poke about https://code.launchpad.net/~jtv/juju-core/no-go-env/+merge/142280 need help landing it? [06:15] wallyworld_: I saw you landed your patches (which is great), but noticed you had some troubles with the first one. Is there a process issue or just a misunderstanding? [06:15] not sure - tarmac said there was a conflict but i could reproduce locally [06:16] couldn't [06:16] couldn't ? [06:16] i recreated the branch and repushed and it was ok after that [06:18] wallyworld_: so if I try to merge your first commit, I get a conflict in client/client.go. After your "merge trunk" commit things work successfully. [06:18] I wonder if the bot/launchpad somehow didn't get your latest update. [06:19] Maybe you forgot to push after doing the merge? [06:19] but that doesn't match what is on the MP [06:19] could be, that would seem the mostly likely cause. perhaps i am used to lbox submit doing the final push [06:19] it doesn't show any new commits after you marked it approved [06:20] i can't remember exactly what i did [06:20] but then the MP seems to not show any new commits, I'm guessing the recreating the branch broke the MP [06:20] as there is no diff, etc. [06:20] a bit of ifddling and it came good [06:20] i don't think there's anything wrong with tarmac, it must have been my issue [06:21] i always got to lbox submit and realise after i get an error that goose doesn't work that way anymore [06:22] and then i forget to copy the descriptin to the commit message [06:22] i'll get the muscle memeory right one of these days [06:22] gotta go pick up my som, back in a bit [06:22] wallyworld_: so goose was trying to merge your first commit (ian.booth@canonical.com-20130211050134-up8560e45212lnc6) according to tarmac logs [06:22] wallyworld_: see you later. [06:23] sorry that i have to go 1/2 way through, i'm late :-( [06:23] np [06:24] davecheney: I'm looking to land a patch which removes 'jujuc' and moves the functionality into 'jujud' https://code.launchpad.net/~jameinel/juju-core/only-jujud/+merge/148181 [06:24] I want to make sure it doesn't break upload tools, et al. [06:25] I think I've covered the bits (and the test suite passes), but you seem to be the one with the most tool-uploading experience. [06:25] Is there anything you want me to test manually before I submit the change? [06:57] jam: back [06:58] i think maybe i just didn't have the latest local rev pushed, that would explain the behaviour i think [06:58] wallyworld_: yeah, tarmac was definitely trying to merge an older revision [06:58] so either it wasn't pushed to LP, or tarmac wasn't seeing it for some reason. [06:59] i'd guess the former [06:59] but in my mind i had pushed it [06:59] PBKAC [07:13] fwereade: morning! [07:13] TheMue: hiya [07:13] rogpeppe, TheMue, heyhey [07:14] rogpeppe, TheMue: there is a start up at https://codereview.appspot.com/7324049/ [07:14] rogpeppe, TheMue: I'm more concerned about implementation sanity than with exactly what I'm implementing [07:15] rogpeppe, TheMue: because... well, you know why. I can change them easily, but if I wait for perfect agreement on everything I'll wait forever [07:16] fwereade: looking [07:18] rogpeppe, fwereade: Good morning. [07:19] fwereade: *click* [07:33] fwereade: You've got a review. [07:34] TheMue, tyvm [07:40] fwereade: reviewed [07:43] rogpeppe, cheers [07:44] TheMue, the answer to your question is "yes" [07:46] rogpeppe, is there some way to express `Constraints{CpuCores:&123}`? [07:46] fwereade: only with an extra line [07:46] rogpeppe, so, not in a top-level var for the tests? [07:46] fwereade: i was just looking at tim's "gap" document. where do we stand on centralised logging support (something i believe pyjuju has)? [07:47] fwereade: huh? [07:47] rogpeppe, I guess I could do a little `pInt(int) *int` func or something [07:47] fwereade: Constraints{CpuCores: &t.cpuCores} ? [07:47] rogpeppe, how do I express nil in the tests then? [07:47] fwereade: ah! [07:48] fwereade: yeah, i think intp(123) would be better than using interface{} [07:48] rogpeppe, ok, cool [07:48] fwereade: Thx. ;) [07:49] fwereade: although... [07:49] rogpeppe, re logging I think there's a bug open [07:50] rogpeppe, and, yeah, we need it [07:50] Btw, anyone able to change the topic to the actual state/milestone goals? [07:50] fwereade: if you moved the parsing code into state, it might work to specify a string instead. [07:51] rogpeppe, that code does feel very cli-specific though [07:51] fwereade: i'm not sure. i suspect we might use it as a universal serialisation format for constraints [07:52] rogpeppe, hmm, I was expecting just to store documents in state [07:52] fwereade: i'm thinking of the API [07:53] fwereade: (also some other tools might want to parse constraint strings too) [07:54] fwereade: i think people using the GUI should be able to type constraint strings in the same format that we've got on the command line. [07:55] fwereade: and i'd prefer it if the GUI people didn't have to duplicate our parsing code [07:55] rogpeppe, hm, I'd expect the constraints gui to be a little more graphical/restrictive than that [07:56] fwereade: hmm, maybe [07:56] fwereade: anyway, i still think that code would fit very nicely alongside the String code. [07:56] rogpeppe, and it's not very consistent with setting env/service config [07:57] fwereade: because those are yaml? [07:57] rogpeppe, not in the API they're not [07:58] rogpeppe, also SetgentTools etc [07:58] fwereade: oh really? we have to translate env and config settings to and from js? [07:58] rogpeppe, the whole API is written with the assumption that we want to use objects rather than identifiers everywhere [07:58] fwereade: the tools parsing is next to the tools stringer [07:58] rogpeppe, I never really liked it [07:59] fwereade: i'm not sure how that's relevant here [08:02] rogpeppe, don't we have to translate *everything* to and from js for the gui? [08:03] fwereade: i guess so. it might make some things awkward though. people can express things in the config yaml that can't make it through a json round trip. [08:04] rogpeppe, remind me, what's allowed that we'll lose? [08:04] fwereade: (at least, i *think* they might be able to) [08:05] rogpeppe, my fervent hope is that the schemas are tight enough that they can't [08:05] rogpeppe, but a hope is ll it is :/ [08:06] * rogpeppe goes to look at the config settings code [08:13] jam, wallyworld_: do I need another goose update? openstack's localLiveSuite.TestPorts is failing [08:15] jam, wallyworld_: nope, still failing: http://paste.ubuntu.com/1648509/ [08:15] fwereade: hmm, we parse all config options into string, and silently throw away anything that doesn't fit. [08:16] fwereade: that will probably work ok with json. [08:16] * fwereade raises a single eyebrow with titanic self-control [08:16] rogpeppe, that is surprising to me... both environment and service config? [08:17] fwereade: just looking at service config there [08:17] fwereade: i'll have a look at env parsing again [08:18] * fwereade wonders why we have types then [08:20] fwereade: env parsing is up to the provider. as long as providers stick to json-compatible values we'll be ok [08:21] fwereade: I get "TestPorts(Work in Progress)" meaning it is skipped [08:22] fwereade: using rev 891 of juju-core [08:22] in environs/openstack/live_tests.go it has 2 functions, both of which comment out the Port tests. [08:23] fwereade: now, IIRC mgz accidentally landed a possibly port-related patch yesterday, but found he made a mistake when doing so, so rolled back the commit about 5 min later. It doesn't make a lot of sense that you would have seen it inside that window, but it is possible. [08:23] fwereade: can you do "bzr log" in your juju-core branch and check? [08:23] It should end with an Ian Booth commit [08:24] fwereade: ok, sorry about that, it looks like 890 was mgz's patch that exposes the global ports tests (and expects them to pass), but then 891 landed by wallyworld_ removes that change [08:24] jam, yeah, but there's only one mgz commit before that [08:25] jam, and I see no skipped ports test in 891 [08:25] fwereade: yeah, something weird here, let me see if I have something wrong [08:25] jam, thanks [08:25] fwereade: *after* we've parsed service config options into string, we validate them with charm.Config.Validate. [08:26] fwereade: but tbh i think it's a bit crackful that that validation is done by the command line command, not in the state. [08:26] fwereade: I had 'bzr revert -r -2' a while back to check if something was a regression. So it looks like 890 does, indeed, enable those tests. I'll run them again to see if they pass here. [08:26] rogpeppe, yeah, there's a hack in config-get saying essentially "remove this when Service.Config is no longer crack" [08:26] fwereade: it fails here. [08:26] Blame mgz :) I'll see what I can sort out [08:27] It looks like an accumulator is getting the same entry 2 times and not stripping the double [08:27] jam, cheers :) [08:27] fwereade: this one? [08:27] // TODO Remove this once state is fixed to report default values. [08:27] rogpeppe, yeah [08:27] fwereade: i think that state *does* report default values [08:28] fwereade: but only because we make sure to put them in in the first place [08:28] fwereade: as I'm checking this for you, can you test if environs/ec2: go test -live works for you? [08:28] rogpeppe, we should definitely NOT do that [08:28] It times out for me after 10 minutes, and 2 modules that take > 5min [08:28] fwereade: ah, because they might change on upgrade? [08:28] rogpeppe, yeah [08:29] jam: go test -live needs to be run with a longer timeout [08:29] jam: it usually takes about 15 minutes for me [08:29] rogpeppe: how does one do that? [08:29] (and can -live do it automagically?) [08:29] rogpeppe, did you fix the bootstrap tests crazy teardown bit? [08:29] jam: this is the script i call "livetest": [08:29] go test -amazon -test.timeout 2h -gocheck.vv $* >[2=1] | timestamp [08:30] fwereade: not yet [08:30] rogpeppe: is timestamp your own tool? [08:30] jam: yeah, sorry, ignore that bit [08:30] jam: (though i do find it dead useful) [08:30] rogpeppe: there is a 'timestamp' provided by the "Internetwork Routing Protocol Attack Suite", but that didn't seem fitting [08:30] I imagine it logs what time each line came in [08:30] jam: yeah [08:31] which I've seen elsewhere, but not packaged. [08:31] rogpeppe, trivial: https://codereview.appspot.com/7312099 [08:32] jam: go get code.google.com/p/rog-go/cmd/timestamp [08:32] :-) [08:32] fwereade: looking [08:33] fwereade: it looks like it is a local-ism. Probably Martin was testing against the -live server and it was working, and didn't run the tests again with only the local server. [08:33] The local double lets you expose the same port twice [08:33] but then reports that the port is *open* twice. [08:34] so we'll need to patch goose for that it looks like. [08:34] fwereade: I'll put up a patch quickly. [08:34] jam, lovely, thanks [08:34] (I haven't fully confirmed that, but it seems likely) [08:35] jam, I'd expect -live to run them locally as well for verification's sake [08:35] fwereade: it does [08:35] I just tried it [08:35] and it fails [08:35] * fwereade grumbles [08:36] so I'm not sure how this got through [08:36] mgz should be up soon to ask [08:37] fwereade: hmm, does this look right to you? i can't remember what unit names we intended to disallow: ^[a-z][a-z0-9]*(-[a-z0-9]*[a-z][a-z0-9]*)*/[0-9]+$ [08:38] rogpeppe, I think that's right, yeah [08:38] rogpeppe, service names ending with `-%d` are not allowed [08:39] fwereade: ah yes, i see now. foggy memories of that regexp resurface :0) [08:45] fwereade: reviewed [08:46] rogpeppe, I don't think it complains about a string with a / in, it just strips off the "unit-", doesn't it? [08:46] jam: ha. would help if i actually pushed it [08:46] rogpeppe, subsequent complaints about unknown units are, I think, sane [08:48] rogpeppe, but maybe "invalid unit specifier" should just be "invalid entity name" as above [08:48] fwereade: if you pass in "unit-foo-bar", you'll see `"foo/bar" is not a valid unit name` but if you pass in "unit-foo", you'll see `invalid unit specifier "foo"` [08:49] fwereade: they're both invalid unit names [08:49] rogpeppe, ahh, yeah [08:49] fwereade: so i think they should probably draw the same error [08:53] rogpeppe, reproposed [08:54] rogpeppe, I think it's useful to be clear about the unit name being the problem rather than the entity name [08:54] rogpeppe, maybe that's pointless though [08:54] fwereade: hmm [08:54] fwereade: i think it might be pointless actually [08:55] fwereade: i suspect all "invalid name" errors from that function should look the same [08:55] fwereade: and should all mention the actual entity name that was typed in [08:56] fwereade: sorry for pushing back on this pissy trivial issue :) [08:57] rogpeppe, np, I'd prefer to get it right :) [08:57] fwereade: but i suppose it is something that users will actually see [08:58] rogpeppe, when whatever they're using to log in doesn't handle the user name right? or more cases? [08:59] fwereade: hmm. maybe not actually. the user will never type an entity na,e. [09:00] rogpeppe, I am now wondering whether we should be checking validity of machine and user ids as well though [09:01] rogpeppe, what are the username restrictions (if any?) [09:01] fwereade: i think that's ok because we don't mangle the id going into those functions [09:01] rogpeppe, I think machine-henry is still an invalid entity name [09:03] fwereade: it is. interestingly State.Machine doesn't check for a valid machine id either. [09:03] rogpeppe, ha, that'd be my fault [09:03] fwereade: how about having a regexp for valid entity names? [09:03] * fwereade has to fix id types but thinks it's less important than constraints :( [09:04] rogpeppe, -1, I think, it's not going to be pretty [09:04] fwereade: it won't. although it could be built up of existing components [09:04] rogpeppe, the service/unit ones are bad enough as it is :) [09:04] fwereade: i'd reuse those [09:05] fwereade: `^(unit-`+unitNameValid+`)|(machine-[0-9]+)| etc` [09:05] fwereade: but given the user never types an entity name, i think we're going overboard [09:06] rogpeppe, yeah, I'm about to propose with trivial machine id checking as well, and hope we'll never need to touch it gain :) [09:07] fwereade: let's just leave it where you started, except perhaps pass the invalid name into State.Unit even if it has no slash in it [09:07] fwereade: that way you'll always get a consistent error. [09:08] rogpeppe, I think invalid is different to not found, and I've already written it :) [09:08] fwereade: State.Unit returns an error on invalid names already [09:09] rogpeppe, I still think there's something to be said for consistency at the level of this func alone [09:09] rogpeppe, and I don't think it's a heavy cost to pay :) [09:09] rogpeppe, reproposed [09:10] fwereade: LGTM [09:11] rogpeppe, cheers [09:20] rogpeppe, http://paste.ubuntu.com/1648829/ (doesn't seem consistent, might have seen it once when other stuff was broken but not last time I ran these tests) [09:23] fwereade: are you using trunk? [09:23] rogpeppe, that was a paranoid re-run of all tests against the fix-auth-entity [09:23] fwereade: i don't see a similar assert at line 557 and tests pass for me [09:24] rogpeppe, branched from trunk very recently [09:24] rogpeppe, weird [09:24] rogpeppe, wish I hadn't deleted the branch after verifying I couldn't repro [09:24] fwereade: the ErrShutdown assert is on line 616 in trunk [09:25] rogpeppe, assume I'm on crack then, I'll complain if it happens again [09:26] fwereade: except it *is* testing for ErrShutdown. it may well be a race. i'll have a closer look at the logic. [09:26] fwereade: (if it is a race, it's a benign one - it doesn't really matter which of those errors is returned in practice) [09:26] rogpeppe, agreed, I just don't like test failures :) [09:27] fwereade: me neither. i end up asserting one of two possible errors. [09:27] s/end/might end/ [09:27] rogpeppe, fine by me if it's not simple to make it consistent [09:31] jam: I'm off today but yes, some help landing it would be very much appreciated! [09:36] rogpeppe: how do you tell if a map is empty? [09:36] can you use len(mymap) ? [09:37] jam: yup [09:37] jam: (works on nil maps too) [09:39] rogpeppe: is there an easy way to check if maps are equal? Or do you have to iterate both and look them up in the other one? [09:42] jam: in a test, i'd use DeepEqual [09:42] jam: otherwise, yes [09:42] rogpeppe: in tests that is fine, but in real code? [09:43] jam: it depends really. DeepEqual is slow and often not what you want (depends on the type of the map values) [09:43] rogpeppe: I know of DeepEquals from gocheck, where do you get DeepEqual from? (stdlib?, somewhere else?) [09:44] jam: reflect [09:44] jam: reflect.DeepEqual(x, y) [09:44] rogpeppe: thx, this is a map[string]string [09:44] jam: the other thing about DeepEqual is it's not type safe [09:44] I just want to see if they are passing something I already have [09:44] jam: i'd just write the comparison code. [09:45] jam: it's only 6 lines or so [10:04] Hi, does it exist some system for notification/autentication between charms? [10:04] Other than (mis)-use relations [10:05] mariusko: that's what relations are for [10:05] I would like to trigger redeploy from a git server charm to e.g. node-app on git push received [10:06] I thought of either setting the branch name again on node-app in that case to trigger it, or add a parameter to store the SHA1 to deploy [10:08] But how would the app-charm get access to the git repo? Is there a magic authentication through ssh or something? [10:11] Or access it through NFS? [10:31] TheMue, ping [10:32] mariusko, do you have a config setting for your git repo? feels like a job for an external tool: set the service config, and let the charm's config-changed hook handle it [10:33] fwereade: pong [10:33] TheMue, it crosses my mind that we probably don't want the storage backend implementation hidden away inside environs/local [10:33] TheMue, how are you planning to deploy it? [10:33] fwereade: If there's good multiple usage I can surely move it. [10:34] TheMue, I'm probably missing something, but I don't see when it'll be used inside environs [10:34] fwereade: The backend only indirectly. I only put it there as we so far had no other need for it. [10:35] TheMue, what's the planfor actually running it? [10:35] fwereade: It can be a standalone binary of maybe also a configurable part of the machine agent. But here I'm not yet secure enough, I haven't yet looked. [10:36] fwereade: The component is flexible enough. [10:36] TheMue, yeah, I'm wondering whether a worker might be the way forward [10:37] TheMue, not something that needs to be done right away though, I guess [10:37] fwereade: I will keep it in mind, but yes, that would be a good "environment" for the backend to live in. [10:37] TheMue, although I imagine you're aiming for a bootstrap ASAP? [10:38] fwereade: Exactly. [10:38] TheMue, cool, I imagine it will fall out naturally soon enough then [10:38] fwereade: Think so too. [10:39] TheMue, can I ask you to take a little look at davecheney's stater work, and let me know whether any of that will potentially fit in well with what you need in the local provider? [10:39] fwereade: Do you know how to change topic w/o op? [10:39] TheMue, I'm afraid I don't [10:39] TheMue, maybe ask niemeyer when he comes on? [10:40] * niemeyer is around [10:40] fwereade: Good idea, and yes, I will take a look at the stater. [10:40] morning folks [10:40] niemeyer: Good morning. [10:40] niemeyer: Nice video about maps btw. [10:40] Hmm.. actually, how do I allow the topic to be changed by everyone again? [10:41] * niemeyer looks at the help [10:41] TheMue: Cheers! [10:41] niemeyer, heyhey, sorry I missed you :) [10:42] TheMue, it's stalled in review at the moment because dave is looking at other things, but I don;t think we can afford to exclude it from consideration -- if you can come up with a plan that fits both local and HA use cases I will send you virtual flowers [10:43] * fwereade needs to take an extended lunch today, off in a few mins, and will see everyone in a couple of hours [10:43] fwereade: Oh, Valentine's. *rofl* === ChanServ changed the topic of #juju-dev to: I am a new topic. [10:45] TheMue: /msg chanserv topic #juju-dev [10:47] niemeyer: Great, thank you. === ChanServ changed the topic of #juju-dev to: finish ALL THE THINGS [10:48] if someone can come up with a better topic, go for it :) [10:48] * fwereade => off [11:25] jam: mgz: dimitern: can we delay the meeting for 30 minutes or so? i've had a call from my wife and i unexpectedly have to go and pick her up from a work meeting [11:25] wallyworld_: works for me, [11:25] wallyworld_: if anyone else was here it would be delayed :), but yeah, wfm [11:26] ok, thanks :-) will leave now and hopefully be back in 1/2 hour or so [11:29] lunchtime [11:34] fwereade: I think I will have to try to hack a bit to see when I get time. Maybe add a connection between gitolite and node-app charm where either you specify a ssh key to fetch the updated code or that node-app adds a ssh key to the server [11:49] dimitern: the rest of us are all here [11:49] dimitern: i'm back [11:49] jam: just a sec [12:01] * rogpeppe goes for lunch [12:13] back, but i'll probably step out for a breath of fresh air later [12:28] fwereade, others?: https://codereview.appspot.com/7303091 - refactoring of hook module [12:50] just rebooting, back in a mo [13:31] dimitern, ping [13:32] fwereade: pong [13:32] fwereade: that's the CL we were talking about yesterday [13:32] dimitern, I think hook.Info shouldn't be in charm/hook -- that bit is very specific to the uniter [13:33] fwereade: ah, ok, I can move that bit back into worker/uniter/hook ? [13:33] hi i just set up my environment and have r892 of juju-core. i'm seeing test failures for state/api. trying to figure out if it is my environment or if that test is really broken in trunk. [13:33] dimitern, yeah -- I know it'll make both packages feel a little anaemic, but I think it's the right division [13:34] fwereade: sure, np [13:34] fwereade: how about the ScanCharm ? [13:34] bac, would you paste them? I know there was churn there in the last couple of days [13:34] fwereade: sure [13:34] dimitern, my first reaction was eww! to the Errors type, but I haven't looked closely enough to figure out whether that's a sensible response ;p [13:35] fwereade: it's a bit iffy at first, but I think it makes sense for what it does [13:36] dimitern, I think you should be ok trusting the contents of the Meta though -- it does validate on load [13:36] fwereade: http://paste.ubuntu.com/1650787/ [13:37] fwereade: including duplicate relations scanning? [13:39] bac, both of those are known and don't indicate anything seriously wrong that won't be fixed today [13:39] fwereade: great, thanks for looking [13:39] * fwereade looks meaningfully at rogpeppe and mgz, neither of whom appear to be around right now [13:39] dimitern, I think so, yeah === TheRealMue is now known as TheMue [13:40] dimitern, lines 99-102 in meta.go [13:40] bac, btw, much love for the bzr revision and go version at the bottom of the paste :) [13:40] :) [13:41] fwereade: ok then, I'll remove this check - can you comment that? [13:41] dimitern, yeah, will do, just going through it now [13:43] fwereade, dimitern, jam, anyone else: a small CL that adds error codes to the rpc package: https://codereview.appspot.com/7311097 [13:46] rogpeppe: looking [13:46] dimitern: ta! [13:49] dimitern, I think it's all doing a bit much, I'm afraid [13:49] dimitern, I totally understand the temptation to use filepath.Walk [13:50] dimitern, but I think it'll work out clearer if you just build up a list of possible hook names given the available relation names [13:50] fwereade: why using Walk is bad? [13:51] dimitern, because we don't care about anything except the actual hooks that juju might try to run [13:51] fwereade: hmm.. [13:52] dimitern, I think that all we need is to build a list of all the global hooks, plus 4 relation hooks for every relation [13:52] fwereade: do you think it's better, once we have discovered all relations, just do a loop over and find whether they're there [13:52] dimitern, we don't even care if they're not there [13:53] dimitern, the only thing we should worry bout is if they're there but aren;t executable [13:53] fwereade: so the executable check has to happen in ScanCharm? [13:54] dimitern, g+? might be quicker than typing [13:54] fwereade: sure, I'll start a hangout [13:54] dimitern, cheers [13:54] fwereade: https://plus.google.com/hangouts/_/a19365e0ad7fd87450ce5dcdb4539de6e2fa6ca8?authuser=0&hl=en [13:55] rogpeppe, http://paste.ubuntu.com/1650787/ -- bac has been seeing EOFs too [13:55] fwereade: thanks. i'm looking at that right now, though i haven't been able to reproduce it [14:13] * dimitern >> lunch [14:25] rogpeppe: thanks for looking. i've got a fresh install and am using bigjool's mongo PPA. [14:29] rogpeppe, you have an LGTM on the error codes, but I'd like to see the NotFound stuff implemented for Machine soon -- I'm not 100% clear on how that'll look in practice === wedgwood_away is now known as wedgwood [14:33] rogpeppe, also, re the int suggestion for CpuPower, would you expand a bit on what you're thinking -- something like 1000 CpuPower == 1 ECU? [14:47] fwereade: sorry, was in a hangout [14:47] fwereade: thanks. that's the next step [14:47] rogpeppe, np, I expected so [14:47] fwereade: yeah, for CpuPower, something like that. probably 100 could be sufficient. [14:48] fwereade: we can display it as a float if we want. [14:48] fwereade: although probably easier not to [14:48] rogpeppe, yeah, that's the plan -- I'd kinda like to keep a bit more accuracy in there than I expect us to need :) [14:49] fwereade: i hope you don't mind my instinctive discomfort with floats. [14:49] bac: can you reproduce the test failure consistently? [14:49] rogpeppe: yes as can teknico [14:49] bac: cool - i'll push a branch for you to test in a moment [14:49] rogpeppe, no, I share it really, I just thought it might be clearer as a float [14:50] rogpeppe: thanks [14:52] rogpeppe, the best float bug I ever heard about was in some game with decent-sized worlds made up of smaller rooms... when the rooms (which were playtested originally in the centre of the universe) were placed far enough away from (0, 0, 0), the loss of resolution meant that the geometry was represented funkily enough to allow people to clip through walls/floors/etc [14:53] fwereade: i bet they were using float32s [14:53] rogpeppe, probably -- and take the details with a pinch of salt [14:53] fwereade: cool bug! [14:53] rogpeppe, but still, floats are bad :) [14:53] rogpeppe, indeed [14:53] * rogpeppe likes floats... in the right place. [14:53] rogpeppe, probably not so cool to debug ;) [14:53] fwereade: or probably to fix... [14:54] rogpeppe, as long as nobody kids themselves they're numbers they're fine [14:54] rogpeppe, ha, yeah [14:57] bac: lp:~rogpeppe/juju-core/216-rpc-consistent-close-error [14:57] rogpeppe: will try now [14:57] teknico: ^^ [14:57] bac: thanks [14:58] bac, rogpeppe, I'll try it too shortly [15:09] fwereade, TheMue: it finally dies... [15:13] hi all; I'm getting an error (well, lots of similar errors) when running "go get -v launchpad.net/juju-core/..." --> "import "crypto/rand": import path doesn't contain a hostname" [15:17] rogpeppe, teknico: i now see a different failure, which i have seen before: http://paste.ubuntu.com/1651636/ [15:18] bac: that's blue team's domain :-) [15:19] jam: ^^ [15:21] sorry, on a call, haven't tried yet [15:24] bac: have you tried go get -u launchpad.net/goose ? [15:24] benji: instead of that, try go get -v launchpad.net/juju-core/cmd/juju [15:25] rogpeppe: i did update goose but not goamz [15:26] bac: so have you got it working now? [15:26] rogpeppe: go install launchpad.net/juju-core/log: mkdir /usr/lib/go/pkg/linux_386/launchpad.net: permission denied [15:26] benji: what's your GOPATH? [15:26] I had a GOROOT set when I got the aformentioned error, now with no GOROOT I get the above [15:26] benji: :) [15:26] benji: you need a GOPATH [15:27] % echo $GOPATH [15:27] /home/benji/workspace/go [15:45] rogpeppe, as for bac, the "api_test.go:524: suite.TestStop" is gone, but the "live_test.go:0: localLiveSuite.TestPorts" is still there [15:45] is "blue team's domain" a reliable enough escape hatch? ;-P [15:46] teknico: yeah, i see the error too [15:46] rogpeppe: i believe mgz should have fixed that [15:46] dimitern: cool [15:46] rogpeppe: we're talking about disabling the ports test today [15:46] teknico, we were expecting mgz to show up and fix it, and that has not happened -- I think I'll just propose a trivial that skips it again [15:48] fwereade, thanks, bac, ^^ [15:48] why was the test failing again? [15:48] ah, did we not report in here? [15:50] it just wants a goose branch landed to make the test service return a sanish error in response to the juju-core tests checking duplicate rule behaviour and probably not being very well isolated [15:50] mgz, dimitern: i've also seen this failure in openstack: http://paste.ubuntu.com/1651926/ [15:51]