[00:03] thumper: you around? [00:07] anyone know much about neutron? having issues with a juju deployed openstack [00:14] bradm, mgz knows most about neutron but he's probably asleep [00:15] wallyworld: I seem to be on the wrong side of the world to be dealing with neutron, everyone who seems to know it is asleep [00:16] yeah :-( [00:25] wallyworld: hi [00:25] gday [00:25] got time for a chat? [00:26] yup [00:26] ish [00:27] it will be quick, just a heads up from the standup last night [00:28] https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.sbtpoheo4q7i7atbvk9gtnb3cc?authuser=1 [01:12] 2014-02-26 01:11:42 ERROR juju runner.go:220 worker: exited "environ-provisioner": failed to process updated machines: error executing "lxc-ls": wait: no child processes [01:12] 2014-02-26 01:11:43 ERROR juju.container.lxc lxc.go:166 failed getting all instances: error executing "lxc-ls": wait: no child processes [01:12] ^ local provider peeps [01:12] any ideas ? [01:14] can't say I've seen that. busted packages again? :( [01:17] is lxc-ls bailing before the wait occurs ? [01:19] ah, I read it as an error coming back from lxc-ls [01:19] ubuntu@winton-02:~$ lxc-ls [01:19] ubuntu@winton-02:~$ echo $? [01:19] 0 [01:19] not sure. [01:19] weird [01:19] try lxc-ls -1 [01:19] (one, not ell) [01:20] and again as root [01:20] ubuntu@winton-02:~$ sudo lxc-ls [01:20] dave foo ken ryu [01:20] interesting [01:20] ubuntu@winton-02:~$ ps auxww | grep jujud [01:20] root 24736 3.0 7.5 8262756 621576 ? Ssl Feb22 174:19 /home/ubuntu/.juju/local/tools/machine-0/jujud machine --data-dir /home/ubuntu/.juju/local --machine-id 0 --debug [01:20] but the machine agent is running as root [01:21] does "sudo lxc-ls -1" do anything different? [01:21] doubtful.. [01:23] davecheney: the golxc code is just doing exec.Command("lxc-ls", "-1").CombinedOutput() [01:23] so... *shrug* [01:23] ubuntu@winton-02:~$ sudo lxc-ls -1 [01:23] dave [01:23] foo [01:23] ken [01:23] ryu [01:23] same, but different [01:23] screw it [01:24] yeah -1 just means one per line, didn't think it'd matter [01:24] gonna destroy and start again [01:31] waigani: ping - standup [01:50] + /home/ubuntu/bin/juju destroy-environment -y local [01:50] + /home/ubuntu/bin/juju bootstrap [01:50] ERROR cannot use 37017 as state port, already in use [01:50] sigh [01:51] bloody hell [01:51] what ? [01:51] there is nothing listening on that port .... [01:52] ERROR cannot use 37017 as state port, already in use [01:52] ubuntu@winton-02:~$ ss | grep 37017 [01:52] ubuntu@winton-02:~$ [01:54] davecheney: i don't think that's a good way to check [01:54] you want ss -nl i think? [01:59] oh [01:59] serves me right for using hipster tools [01:59] i'll go back netstat -anp next time [01:59] ubuntu@winton-02:~$ sudo !! [01:59] sudo netstat -anp | grep 37 [01:59] tcp 0 0 0.0.0.0:37017 0.0.0.0:* LISTEN 24711/mongod [02:00] intersting [02:00] i wonder why it didn't die === edu-afk is now known as edamato === mwhudson is now known as zz_mwhudson === zz_mwhudson is now known as mwhudson [02:29] axw, wallyworld, waigani: we'll just use this one... https://plus.google.com/hangouts/_/calendar/dGltLnBlbmhleUBjYW5vbmljYWwuY29t.kieq2g96khnegtjsretb0l4clo [02:31] thumper: says not allowed to join [02:31] pfft [02:31] same [02:31] * thumper sighs [02:31] this was the one from the package review [02:32] you are now invited === edamato is now known as edu-afk [03:03] thumper: poke, are you still online? [03:03] jam: yes, am with the team talking timings :) [03:06] thumper: I'm available for video chat for a bit if you want [03:20] jam: available now [03:31] thumper: starting up G+ hangout now [03:31] kk [03:31] thumper: https://plus.google.com/hangouts/_/7ecpikfgr7oi6hsg74ds6jdcl0 === mwhudson is now known as zz_mwhudson [04:45] thumper: seriously lol-ing at your twitter conversation this morning [06:23] oh wtf [06:25] * axw stops wtf'ing [06:25] the bot marked the wrong MP as merged [07:01] axw: where? [07:02] I can't say that I've seen that before [07:02] the bot doesn't actually do it [07:02] Launchpad detects when the tip revision has been merged into trunk [07:02] so it is generally accurate [07:02] jam: https://code.launchpad.net/~axwalk/juju-core/lp1281071-rsyslog-tls/+merge/207889 [07:02] what I did was I created another branch, merged that one in but removed all the stuff I didn't care about [07:03] so LP saw the merged revisions [07:03] axw: the above branch is "andrew.wilkins@canonical.com-20140225140210-4206fc8pbnfkpb46" which is rev 2349.2.5 in trunk [07:03] so that MP was *merged*, just from something else [07:05] yeah, makes sense - I just haven't done that before and was a bit surprised [07:05] be careful when clicking near tabs :) [07:06] :) [07:06] yeah, makes sense - I just haven't done that before and was a bit surprised [07:06] jam: yes, the rev is there, I just took out most of what's in that MP [09:25] fwereade, wrtp, i'd appreciate a review and some direction on https://codereview.appspot.com/66540044 [09:29] dimitern: looking [09:51] dimitern: reviewed [09:52] wrtp, ta! [09:56] dimitern, your review here: https://codereview.appspot.com/67870043/ do you mean I need to implement the new status code in FullStatus only - and not in Status? [09:58] mattyw, FullStatus only - Status uses FS internally, when needed (1.16 compat mode) [09:59] fwereade, wrtp, so, it seems we'll need to define the next agent conf version - should it be 1.17 or 1.18? I'm thinking of adding Version, DataDir, LogDir, possibly Jobs as fields === wrtp is now known as rogpeppe [10:00] dimitern: i don't think it makes sense to define formats for dev versions [10:00] dimitern, ok thanks [10:00] dimitern: so i'd suggest 1.18 [10:02] rogpeppe, ok, and in that version we'll use a single file + version, no format separately [10:02] dimitern: yeah [10:02] rogpeppe, can you think of any other fields we might need to define except the ones above? [10:03] dimitern: what is "Version" there? the agent configuration version? [10:05] rogpeppe, ok Format then [10:05] dimitern: what does it hold? [10:07] rogpeppe, the agent conf format version [10:10] dimitern: i'm not sure we want to expose that outside of the agent package [10:10] dimitern: and i don't think it should be a regular field [10:10] dimitern: i suggest that we store the version on a line of its own before any of the other conf data [10:10] rogpeppe, expand? [10:11] dimitern: then we can read the version and use it to decide how to parse the rest of the config data [10:11] dimitern: which gives us freedom to change file formats in the future if we want (for example to move away from YAML) [10:12] * rogpeppe has just got his laptop back through the post [10:12] and they've cleaned it all up - it doesn't look like my scruffy laptop any more :-) [10:13] let's see if it works... [10:13] ha, they replaced the keyboard! [10:17] rogpeppe: I'm glad you got it back in time, congrats [10:18] rogpeppe, \o/ [10:18] rogpeppe, ok, that sgtm [10:20] jam: yay! back on the thinkpad! === rogpeppe1 is now known as rogpeppe === rogpeppe1 is now known as rogpeppe [10:46] rogpeppe: fwereade, dimitern: standup? [10:50] fwereade: poke ? [10:51] jam, sorry, couple of mins [10:58] mgz: poke ? [10:59] jam: ta [11:08] fwereade: one more quick standup ping? [11:48] fwereade: https://codereview.appspot.com/68650044 [11:51] rogpeppe: https://bugs.launchpad.net/juju-core/+bug/1254577 is still marked Critical and not Fix Committed. I thought you landed code related to that? [11:52] jam: marked as "fix committed" [11:52] rogpeppe: do you know if that got released in 1.17.3 [11:52] ? [11:53] jam: i certainly hope so. let me check. [11:55] jam: well, the fix was merged 3 weeks ago, so i should certainly hope so [11:57] does anyone have the link to the current CI runs? I seem to have an old IP address that is no longer valid [11:57] sinzui: ^^ [12:13] jam: FYI I have an old IP too, not sure what happened. Sinzui is likely still asleep, but when he responds, I'll email out the new IP. [12:21] frankban, dimitern: does charm get handle symlinks at all? [12:22] fwereade, because it uses a zip reader internally, i guess it should [12:22] frankban, dimitern: it looks like it's just sending the target path and I'm not convinced that's useful [12:23] fwereade: I guess it depends on how they are handled by zip.ReadCloser [12:24] frankban, fwereade, but a test with a zip + symlinks is definitely useful [12:24] frankban, dimitern: ok, what do you think we should be doing? sending the actual content of the target? [12:25] fwereade: makes sense [12:25] fwereade, frankban, that sounds reasonable [12:25] fwereade, dimitern: trying with a symlink [12:25] dimitern, frankban: ok, cheers, I'll see what I can do [12:28] dimitern, frankban: also, would it be *really* annoying if I changed the filelist stuff to return directories as well? I freely admit this is more rooted in convenience than any solid design principles [12:29] dimitern, frankban: hmm, I think we may need special handling for the revision file too [12:29] fwereade: not annoying for me [12:30] frankban, cool, basically I'd like to just return the result of the imminently-available Bundle.Manifest method [12:30] fwereade: re: revision file, is it special? [12:31] frankban, its presence is not guaranteed in the zip file, but it is always returned by Manifest because we do always write one out [12:31] fwereade: oh, so you'll instantiate a bundle and it will have a Manifest returning the file list? [12:31] frankban, it'll *almost* certainly always be there, but it's that "almost" that's the issue ;) [12:31] frankban, yeah, I think so -- is a ReadBundle unreasonable at that point? [12:32] fwereade: OIC, if it's not there there is no problem from our perspective, AFAICT we are not interested in the revision file for that API. but I agree, if it's in the list, we must also return its contents [12:34] fwereade: in my previous impl (before requirements changes) I used ReadBundle to and ExpandTo to extract the files, so, it makes sense. I wonder if at that point a bundle.GetFile would be reasonable too. [12:36] * fwereade starts wondering about a Content(path) method [12:37] frankban, yeah, I'm just having trouble integrating the symlink-resolution stuff in my current model [12:41] frankban, how do we currently behave if you ask for a path to a dir? [12:41] frankban, ah 403 cool [12:41] fwereade: forbidden [12:41] yeah [12:41] frankban, ok, I think that works for me [12:42] frankban, dimitern: can we do a really quick hangout? [12:43] fwereade: sure [12:43] fwereade, frankban, sure [12:43] dimitern, frankban: https://plus.google.com/hangouts/_/7ecpjumv8629dqrig0jdegier8?hl=en [13:19] fwereade: you've got a review: https://codereview.appspot.com/69110043/ [13:21] jam, natefinch http://162.213.35.54:8080/ and it appears ill (and we stood it up 2 days ago too) [13:21] oh, no route to host [13:21] sinzui: k, so that I can't get to it is probably because it isn't there :) [13:22] heh === psivaa is now known as psivaa-lunch [14:12] dimitern: i've responded to your review [14:13] dimitern: i'd appreciate the rest, if you have some time [14:14] rogpeppe, thanks, i'll look into it a bit later [14:14] dimitern: ta [14:14] natefinch, fwereade: your reviews appreciated too === psivaa-lunch is now known as psivaa [14:51] rogpeppe: Hey, just a ping to let you know your branch got merged, and the tests that were failing due to the panic formatting changes in recent Go versions have also been fixed [14:52] niemeyer: great, thanks. i was planning to get around to merging it, but my laptop died which was a distraction [14:52] niemeyer: i'll update the juju-core deps file [14:52] rogpeppe: Thanks [14:59] rogpeppe, what are these cryptic 0v 1p in member definitions [14:59] dimitern: see the definition of mkMembers and mkStatuses [15:00] rogpeppe, right, thanks [15:00] mramm, fwereade: Are we having that call today? [15:01] I'm in the hangout [15:01] if you want to have it [15:01] but I don't have any items for today's agenda [15:02] so I am also fine with skipping today [15:03] mramm: I'm joining [15:21] rogpeppe: resuming the review now [15:21] natefinch: thanks! [15:33] lunch [15:46] natefinch, rogpeppe , is someone adding support to install juju-mongodb when it is available? [15:46] sinzui: i think that's the plan, but i don't know its current status [15:47] rogpeppe, thank you [15:50] rogpeppe, reviewed [15:50] dimitern: ta! [15:50] sinzui: it is planned but I don't think anyone is assigned. I did the other part, but someone else should probably do this part, since I am way behind on HA stuff. [15:51] natefinch, fab. I think I will work to release juju 1.17.4 as it is for people working on trusty and other archs [16:03] rogpeppe, fwereade, so with the introduction of agent conf format 1.18 we should drop 1.12 format support, right? [16:03] rogpeppe, would you explain the windows 022 thing a bit more? [16:03] fwereade: i think so [16:03] dimitern: i think so [16:03] ok :) [16:03] dimitern, hmm, I have a nasty feeling that 1.12 might try to upgrade arbitrarily far [16:04] fwereade: so, i'm not convinced that we'll get sane-looking perms from windows-generated zip files [16:04] fwereade, so? [16:04] fwereade, it will fail [16:04] fwereade: from previous experience with unix-like perms on windows [16:04] fwereade: natefinch may know more of the expected behaviour [16:04] dimitern, so I'm not sure that we can guarantee that 1.18 won't start up with a 1.12 conf [16:05] dimitern, it may just be a matter of shouting about it in the release notes though [16:06] rogpeppe, natefinch: in particular I don't quite get what `&=022` would do, maybe because I'm not sure where you mean me to apply it [16:06] fwereade, well, we can't guarantee compatibility 16 releases back anyway, so it should just fail in some sensible way [16:07] fwereade: it would clear group and other write permissions from all files and directories [16:08] fwereade: sorry, it should have been &^022 [16:09] fwereade: another possibility is to use ((p&7) | (p&7)<<3 | (p&7)<<6)) & ^022 [16:10] fwereade: i.e. ignore group and other modes, don't allow any group/user write perms, and use r and x bits from user perms for group and other [16:10] fwereade: but that means it's not possible to make a non-group or other -readable file [16:26] fwereade, rogpeppe: catching up.... perms on windows are way different. Not 100% sure on how Go translates permission bits to windows [16:26] natefinch: yeah. [16:26] natefinch: what do you think windows-created zip files will report for permissions? [16:27] natefinch: perhaps you could create a zip file under windows, with a variety of permissions, and we could find out [16:28] rogpeppe: yeah, that';s what I was thinking. I don't know what linux defaults to when it sees a windows file that doesn't have permissions like that set. I'll try it out, easy enough [16:28] fwereade: one thought is that if we're unpacking the charm under unix, it's pretty unlikely that the charm was zipped under windows [16:28] natefinch: i did some of the go zip perms code, ages ago, but i can't remember much about it and it's probably changed since i did it [16:28] natefinch: i think the trauma of reading the zip spec must've blanked my memory :-] [16:29] rogpeppe: hahah [16:34] natefinch, rogpeppe: sorry, multitasking fail [16:36] rogpeppe: by default it's 0664 [16:36] natefinch: which default? [16:36] -rw-rw-r-- for those of us less binarily inclined [16:36] rogpeppe: if I just create a zip without specifying permissions [16:36] natefinch: is that Go's behaviour or windows' ? [16:37] rogpeppe: windows, sorry [16:37] natefinch: have you tried unpacking that using Go, to make sure [16:37] rogpeppe: not yet, I'll do that [16:38] rogpeppe: unpacking on linux, I presume? [16:39] natefinch: it shouldn't make any difference [16:39] natefinch: you don't actually need to create the file [16:39] rogpeppe, natefinch: fwiw we *do* make sure that hooks are executable when we unpack *anyway* and I suspect this hits most of the cases -- 644/744 should be enough for anyone, right? [16:39] natefinch: just see what perms are reported [16:39] rogpeppe, natefinch: indeed assuming that *is* what's reported [16:40] fwereade: i'd go for 755 rather than 744 [16:40] fwereade: but yeah, i don't think there's a huge issue here [16:40] fwereade: it's worth going into it with our eyes open though [16:40] fwereade: (i have definitely hit problems in this area in a previous lifetime) [16:41] rogpeppe, natefinch: I'm not *really* expecting we'll get a lot of people writing charms on windows anyway tbh [16:42] rogpeppe, natefinch: drag a charm archive into a browser on windows? plausible [16:42] rogpeppe, natefinch: zip up a subtly wrong dir and drag it into a browser on linux? also plausible [16:43] rogpeppe, natefinch: "develop" a charm sight unseen on windows, and deploy it to a real ubuntu cloud straight off? seems less likely [16:43] fwereade: it's possible but i think that the resulting issues probably won't be *too* bad [16:43] fwereade: exactly [16:45] fwereade: one other thing occurs to me: the perms you'll get when creating a file with os.OpenFile may well be different from the perms you get when doing a chmod [16:45] fwereade: because of umask [16:46] fwereade: to be consistent, perhaps we should AND all the perms with the current umask before doing anything [16:48] &^umask, right? [16:50] rogpeppe, fwereade: btw the unzipped files w/ go are created with 0664, too. [16:51] fwereade: yeah [16:51] natefinch: that's not a great default, but umask should sort it out [16:54] natefinch, ok, that seems probably good enough to me? [16:54] rogpeppe, added v brief notes on https://codereview.appspot.com/68650044/ -- I'll be looking at it some more [16:55] rogpeppe, but it is explicitly *not* nlgtmed, so please do not take my need to convince myself further as a roadblock [16:59] fwereade: i'd be interested to know what kind of thing you're thinking about when you suggest a "simpler and dumber model" [17:02] fwereade: i agree that the current mocking setup is somewhat experimental, but i *think* it beats trying to get the real State to jump through all those hoops [17:03] rogpeppe, yeah, definitely agreed [17:06] fwereade: the IsNotFound cases are the only place in the code we don't have 100% coverage. that's mainly because i haven't yet thought of a decent way to "wait for nothing to happen" [17:07] fwereade: i'd also be interested to know where you found it difficult to follow the code, so i can add an appropriate comment or two [17:23] rogpeppe, I'll hopefully have some better comments later today [17:24] fwereade: i've just approved the MP BTW, but i'll take on board any further comments and integrate them into the next branch [17:24] rogpeppe, I do find myself wondering whether we actually kinda want to unpack charms with the permissions in the zip file, umask be damned [17:24] rogpeppe, thanks [17:24] fwereade: i'm not sure [17:24] fwereade: an easy way to do that is to set umask to 0 [17:25] fwereade: umask is kinda dumb anyway [17:25] fwereade: i preferred the plan 9 way of doing things, where the default perms were taken from the parent dir [17:25] rogpeppe, heh, but then we do want to keep using the default umask for hook execution I think [17:25] * fwereade rather agrees tere [17:26] fwereade: i don't know. what do you think the expectation of umask is for charm authors? [17:27] rogpeppe, there were bugs about it in the past [17:27] rogpeppe, iirc the expectation is "execute hooks with the system umask" [17:28] fwereade: the other thing that i didn't remark on in the review, is what happens if you have a directory with non-writable permissions, but it contains some files? [17:28] fwereade: i *think* that in general it's a moot point because zip files don't usually mention directories explicitly [17:28] fwereade: but it can be an issue [17:32] rogpeppe, yeah, my thinking was mainly that unwritable things are unlikely to come up in practice, and when they do we have ErrConflict [17:32] rogpeppe, because I certainly don't know what the point of having such things would be [17:32] fwereade: alternatively, make sure that all directories are at least 700 [17:33] fwereade: me neither, but it's difficult to pre-guess [17:33] rogpeppe, and thus am unqualified to impose expectations [17:35] hiya. Is ssh forwarding broken? http://paste.ubuntu.com/7000920/ [17:35] that's on 1.17.3-saucy-amd64 [17:37] ev: hmm, it would be interesting to find out what actual command line is being executed there [17:37] rogpeppe: hm? Isn't that in the pastebin? [17:37] is that just bug 1281577 [17:37] <_mup_> Bug #1281577: juju 1.17.2 doesn't pass command line options to ssh

[17:37] ah, that's the badger [17:37] thanks guys [17:37] ev: no, sorry, i mean the ssh comment [17:38] mgz: thanks [17:38] ev: sinzui is doing 11.17.4 today which has the fix [17:38] -1 [17:41] whoop! [17:42] rogpeppe, fwereade: btw, it looks like zip files don't actually include the directory information, just implicitly through paths on files (at least the ones I created on windows 7). [17:43] natefinch, would you mail me one please? [17:43] natefinch: that's what i meant by "zip files don't usually mention directories explicitly" [17:43] natefinch: i think it's possible for them to do so though [17:44] natefinch: i *think* it's possible to have empty dirs in a zip file [17:45] rogpeppe: windows won't let you do it : [Window Title] [17:45] Compressed (zipped) Folders [17:45] [Content] [17:45] Windows was unable to add one or more empty directories to the Compressed (zipped) Folder. [17:45] [OK] [17:45] natefinch: ha ha [17:45] natefinch: no one likes those poor empty directories [17:45] rogpeppe: I'd just been testing that [17:45] natefinch: apart from bzr, which is being phased out [17:45] rogpeppe: yeah, it's kinda sad, because they can have value. [17:46] natefinch: they're really important sometimes [17:46] rogpeppe: if for nothing else than "here's where you should put X stuff" [17:47] natefinch: certainly tools *exist* on windows that let you add empty dirs to zips... [17:47] whether they're what people use is another matter [17:47] mgz: yeah, probably 7zip etc would allow it. Certainly we should support it if it's possible. [17:47] 7zip does, just tested [17:50] mgz: good to know. [17:54] rogpeppe: we should probably talk HA next steps before your EOD, or jam will have my head for not putting up some tasks on kanban [17:55] natefinch: i'm just working on that, but let's have a chat about it [17:55] natefinch: in fact, give me 10 mins to finish my thoughts here [17:55] rogpeppe: sure thing' [18:06] mgz, ev : I hope to do a 1.17.4 release tomorrow. nova/canonistack lost the ci machine abotu 12 hours. We had to stand up another one as our first priority [18:07] sinzui: eck... we need a less overcommitted region probably :0 [18:08] mgz, It happened last week too. We will move to another region or cloud [18:12] sinzui: *nods* I've just sent instructions to my team on using juju from trunk for this [18:12] natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1 [18:12] HP has hilariously set really low limits on not only security groups, but security group rules [18:12] so wooo tunnels [18:13] I don't suppose I could convince someone to update the simplestreams stuff to use the new US/West HP Cloud region? [18:13] we've uploaded the right thing to a public bucket on one of our HPCloud accounts for now [18:14] ev, Juju-CI just built UNRELASED debs for trusty, saucy, and precise. This is the release candidate we are testing: http://162.213.35.54:8080/job/publish-revision/ [18:14] if ev, this is the actual release tarball we will use on success: http://162.213.35.54:8080/job/build-revision/ [18:15] ( https://region-a.geo-1.objects.hpcloudsvc.com/v1/11289530460295/images and https://region-a.geo-1.objects.hpcloudsvc.com/v1/11289530460295/tools ) [18:15] sinzui: *nods* thanks! === psivaa is now known as psivaa-afk [19:20] * rogpeppe is done for the day [19:20] g'night all [19:21] fwereade: there are now some kanban cards for HA, BTW [19:51] o/ === zz_mwhudson is now known as mwhudson === smoser` is now known as smoser === dstroppa_ is now known as dstroppa === hatch_ is now known as hatch [21:59] waigani: https://bugs.launchpad.net/juju-core/+bug/1281394 [21:59] <_mup_> Bug #1281394: uniter failed to run non-existant config-changed hook

[22:10] wallyworld: just for you: http://pastebin.ubuntu.com/7002116/ [22:10] looking [22:11] is this trunk? [22:11] aye [22:11] pulled trunk, started a local provider [22:11] hmmm. worked for me before :-( [22:11] and CI [22:12] ok, i'll have to look [22:12] and also deployed ubuntu charm [22:12] that is all [22:12] well, it is up and running [22:12] but the worker is bouncing [22:12] sigh, yeah will look [22:12] but i'm in a good mood - got support for IDE based debugging :-) [22:13] niiiiiice [22:13] no more fmt.Printf() to see wtf is going on [22:21] haha [22:21] nice [22:21] Tim just shot me [22:22] nerf [22:34] thumper: what juju version were you upgrading local provider env from? [22:34] I wasn't upgrading [22:34] I was just starting it [22:35] hmmm. ok [22:38] thumper: since you're ocr :-) could you +1 this one roger looked at - i've responded to changes but he didn't get to +1 yesterday. there's also https://codereview.appspot.com/68990043/ :-D [22:38] i'm ocr? [22:38] it says so on the calendar :-) [22:38] * thumper sighs [22:38] suppose I am then... [22:38] yes, I'll look soonish [22:39] yep :-) [22:39] no hurry [22:39] i have 4 branches stacked up i need to land [22:39] so just keen to clear the queue sometime today or whenever [22:40] yeah yeah [22:41] * thumper puts wallyworld on the TODO soonish stack [22:45] no hurry === thumper is now known as thumper-gym