=== _thumper_ is now known as thumper
thumperfollowed closely by wat?00:59
axwrogpeppe: pong... presumably you're asleep though00:59
axwthumper: office space?01:00
thumperaxw: yeah, there are now four of us in Dunedin01:00
thumperconsidering options around having an office01:01
axwah, cool01:01
thumperaxw: I'm looking at the bug wallyworld_ mentioned in the email01:01
wallyworld_thumper: meeting?01:01
thumperaxw: it was the creation of ~/.juju/ssh01:01
axwoh? :(01:01
axwsorry about that01:02
thumperaxw: np, working on it01:07
axwbrb, restarting01:09
* axw loves his new SSD01:11
wallyworld_axw: don't forget to add trim support, unless you are running trusty :-)02:08
axwwallyworld_: yup thanks :)02:09
axwnot running trusty yet02:09
wallyworld_i knew you'd know to do it :-)02:09
wallyworld_i want to upgrade to trusty, just a bit scared02:09
axwme too02:09
wallyworld_maybe best to wait a few weeks02:09
axwI was going to wait a few months ;)02:11
wallyworld_i've found the first beta to be ok in the past02:20
axwyeah maybe I'll get in on the beta02:31
thumperI found that very amusing02:37
thumperbootstrapped local02:37
thumperdid juju status02:37
thumperit says "agent-state: down"02:37
thumperI'm like, bollocks02:37
thumperotherwise status wouldn't work02:37
thumperaxw: can I get you to review the changes to the ~/.juju/ssh work?02:38
axwthumper: yes02:38
thumperaxw: cheers, just proposing now02:39
thumperaxw: https://codereview.appspot.com/5295004302:44
axwI wish we didn't have to run with sudo :(02:46
thumperme too02:55
thumpermaybe soon02:56
axwthumper: reviewed03:09
thumperaxw: can we talk about this?03:22
axwthumper: sure03:22
axwthumper: thanks, looks better now (to me anyway)04:53
thumperaxw: np04:53
axwwallyworld_: did you add the MachineConfig API, or was that jam?04:59
axwfor manual provisioning04:59
wallyworld_i can't recall doing it04:59
wallyworld_what does bzr annotate say?05:00
axwwallyworld_: says you did it actually :)05:00
wallyworld_which file?05:00
axwwallyworld_: just wondering if there's a particular reason why Series was passed in, when that can be gotten from the state.Machine05:01
axwwallyworld_: and if I'm allowed to break compatibility with 1.17.305:01
wallyworld_can't recall exactly - may be because the old state based api had it as a param05:02
wallyworld_and the new api replicated that behaviour05:02
wallyworld_i'd have to look over the code again to remember. maybe add as a topic for discussion inthe meeting tonight05:03
axwit would've been like that because it was all in the same function, I think05:03
wallyworld_if i can get my current wip shit sorted, i'll look over the code05:03
axwok, ta05:04
wallyworld_axw: the old 1.6 api seemed to require series to be passed in05:06
axwwallyworld_: which 1.16 API is that?05:06
wallyworld_environs/manual/provisioner.go recordMachineInState1dot1605:06
wallyworld_and then the same series is passed to MachineConfig05:07
axwwallyworld_: I'm talking about the bit *after* recording the machine in state05:07
wallyworld_but i guess the series is known05:08
wallyworld_i see what you are talking about now05:08
axwI'll put in an item for the meeting to make sure I can break it05:08
wallyworld_so it makes sense to drop it05:08
wallyworld_i think it will be ok because 1.17 is dev05:08
axwarch is known in that case too, but I'm not sure I can remove that one. MachineConfig could conceivably be used in other contexts, and Arch isn't required like Series is05:09
axwyeah I figured it's okay to break05:09
axwalthough, MachineConfig requires arch, so... maybe it's okay for it to assume it's set on the machine and just error out if not05:11
axwI'll do that05:11
jamespagedavecheney, +1 on not shipping a fork btw07:11
jamespagedavecheney, just reading your email07:11
* fwereade needs to be out for a bit, be back by the meeting08:12
jam1mgz: rogpeppe: I'm going to have to miss the weekly meeting today, it is my son's first day of Karate, so I have to be there to get him all sorted out.08:28
rogpeppejam1: ok08:35
=== jam1 is now known as jam
rogpeppeaxw: i was just pinging you in case you might be up for a review of https://codereview.appspot.com/52850043/08:45
axwrogpeppe: sure, will take a look now08:45
rogpeppeaxw: thanks08:46
axwrogpeppe: lgtm09:00
rogpeppeaxw: thanks09:00
rogpeppeaxw: maybe you're right about logging join/leave at info level09:03
rogpeppeaxw: it would be easy to do, and "09:04
rogpeppedeploy service -n 100009:04
rogpeppe" won't spam09:04
rogpeppeaxw: 'cos it only makes one connection09:04
axweach machine agent will connect later won't it?09:04
rogpeppeaxw: ah, but i guess all the machines will make a conn, yeah09:05
axwthat's my only reservation09:05
rogpeppeaxw: 2000 lines isn't much though09:05
axwyeah I guess so. I've found that sort of thing useful in the past, debugging when clients unexpectedly exit09:05
axwtho I think we're at debug by default09:06
axwfwereade: I would appreciate a look at this later, if you have time: https://codereview.appspot.com/53040043/09:58
axwit's for hazmat09:58
rogpeppeaxw, fwereade, dimitern, mgz, wallyworld_: team meeting?10:07
dimiternrogpeppe, we're all there10:07
wallyworld_were're here10:07
fwereaderogpeppe, we're having it ;p10:07
dimiternrogpeppe, https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.sbtpoheo4q7i7atbvk9gtnb3cc10:07
rogpeppehmm, i must have clicked on the wrong link. i'm in https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.8sj9smn017584lljvp63djdnn8?authuser=110:08
axwrogpeppe: https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.sbtpoheo4q7i7atbvk9gtnb3cc?authuser=110:08
axwrogpeppe: this is the CL mentioned before: https://codereview.appspot.com/53040043/10:51
rogpeppeaxw: thanks, will look10:51
axwI will bbl if you need to ask me anything about it10:51
wallyworld_fwereade: i think i've addressed the outstanding issues with the juju status work - the revision update functionality and the status command presentation of data. if you get a chance to take a look, great. if not, i'll chase a review tomorrow10:53
rogpeppeaxw: so the idea behind this is that it means that you can provision machines that you can't ssh to, right?10:55
mgzdimitern: have proposed a pretty trivial initial goose branch10:55
* fwereade makes no promises to wallyworld_ but thanks him for the reminder10:56
=== sparkieg` is now known as sparkiegeek`
dimiternmgz, looking11:09
=== sparkiegeek` is now known as sparkiegeek
axwrogpeppe: yes, that is the idea11:32
dimiternmgz, reviewed11:35
dimiternmgz, i'm still looking at the networks spec doc and into the lxc/kvm brokers btw11:37
rogpeppeaxw: reviewed12:02
dimiternnoodles775, you around?12:05
noodles775dimitern: yep, for a bit.12:05
dimiternnoodles775, re bug 1259925 you reproduced - can you do it reliably?12:05
_mup_Bug #1259925: juju destroy-environment does not delete the local charm cache <destroy-environment> <local-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1259925>12:05
dimiternnoodles775, and if so, can you please leave a comment so I can try it myself and investigate?12:06
noodles775dimitern: I've not tried since then - should I retry with 1.17.0 or trunk? (I actually tried trunk this morning but couldn't get juju status to return sensible info http://paste.ubuntu.com/6761458/)12:09
dimiternnoodles775, trunk would be preferable; have you made sure you rebuilt cmd/juju and cmd/jujud and then did bootstrap --upload-tools ? I was seeing similar status output yesterday before doing that12:10
dimiternnoodles775, also, if you can reproduce it again, can you make a mongo dump please? I'll help to see what's in the db12:11
noodles775dimitern: no - I didn't do --upload-tools, I'll try that. Thanks.12:12
dimiternaxw, have you tested your branch against 1.16 api server?12:14
cgzthanks for the goose review dimitern12:24
sparkiegeekam I right in saying that there's no API for querying the state of a relation (e.g. hooks have fired and state comes from failures or not)?12:43
axwdimitern: no, I haven't. I can do that tomorrow.13:15
axwthanks rogpeppe13:16
dimiternaxw, I posted some review comments as well13:16
axwcool, thanks dimitern13:16
dimiternaxw, cheers13:16
rogpeppesparkiegeek: you can find out the current status of a unit, which will show you if a relation has failed. what information are you after?13:17
sparkiegeekrogpeppe: I want positive confirmation of success13:18
rogpeppesparkiegeek: confirmation that a relation has been successfully made?13:18
sparkiegeekrogpeppe: exactly13:18
sparkiegeekrogpeppe: where "success" = no hooks have failed :/13:19
sparkiegeekrogpeppe: and more importantly, that they *have* been run13:19
rogpeppesparkiegeek: ah, yes. you can get the former, but i'm not sure there's any current way to verify that the relation-joined hook has successfully run13:19
rogpeppefwereade: ^ am i right there?13:20
axwdimitern: "I'd like to see a test about using ProvisioningScript against 1.16 API server" -- do you just mean an interactive test, or do we have some way of doing that in unit tests?13:20
dimiternaxw, we have similar tests for other api calls - grep for 1dot16 methods and their associate tests13:20
fwereaderogpeppe, sparkiegeek: that is correct -- we have work scheduled to flag when a unit's finished doing work, but you can't tell today13:21
sparkiegeekfwereade: is there a bug number or blueprint you can point me at?13:21
rogpeppefwereade: i'm not sure that that will provide quite the functionality required13:23
rogpeppefwereade: a unit might have successfully joined the relation but still have work to do13:23
fwereadesparkiegeek, I can't find one immediately, I'm writing one, will close it dupe if I can track it down13:24
rogpeppefwereade: (from relation changed events, for example)13:24
sparkiegeekfwereade: great! Thanks a lot13:24
fwereaderogpeppe, "finished doing work" ie completed all hooks, nothing scheduled for the future13:24
axwdimitern: ah yep I understand now. I will add a test to environs/manual that tests the compat13:24
axwdimitern: thanks13:24
dimiternaxw, ta!13:24
rogpeppe sparkiegeek: i'm wondering if what you really want here is a way for a charm to provide a positive indication that it's in a certain state13:24
rogpeppefwereade, sparkiegeek: i'm thinking this might be another use case for output variables13:25
rogpeppefwereade: the problem is that with juju run particularly, that state might never occur13:25
rogpeppefwereade: a relation's attributes could be constantly changing, so the charm might never reach that steady state13:26
rogpeppefwereade: but i suspect that sparkiegeek doesn't care about steady state as much as "this relation has been successfully joined"13:27
sparkiegeekrogpeppe: that would work for me too, assuming the states cover the scenario of being deployed vs. being deployed and successfully related to $X13:27
sparkiegeekrogpeppe: correct13:27
rogpeppesparkiegeek: the idea is that a charm could set an output variable to communicate something to the outside world. so the relation-joined hook could set foorelation-ready=true, for example (the variable name would be arbitrary)13:28
fwereaderogpeppe, sparkiegeek: hmm, per-relation busy/idle flags?13:29
rogpeppefwereade: again, i don't think that quite hits the mark13:29
rogpeppefwereade: we don't care about busy vs idle but "are you in this state?"13:30
fwereaderogpeppe, ok, please be very precise about what state we're hoping to expose and why, I may have missed something13:30
fwereaderogpeppe, define a "successfully joined" relation13:31
rogpeppefwereade: my impression is that output variables would not be very hard to implement. can you think of something that makes them so?13:31
rogpeppefwereade: i don't think we can hope to make a canonical definition of that13:31
fwereaderogpeppe, well I assumed it was a proxy for "what sparkiegeek really wants"13:32
rogpeppefwereade: hence i think that an output variable that lets the charm *say* "this thing has successfully happened", whether it's a relation successfully joined (by that charm's definition of success), or a web service being started, or whatever13:32
fwereaderogpeppe, "all scheduled hooks have been runfor this relation, and none of them failed" STM to match the desires stated above13:32
rogpeppefwereade: but that might never happen, in legitimate scenario13:33
rogpeppes/in/in a/13:33
fwereaderogpeppe, well, I don'tsee how you can say the relation has been "successfully joined" until that's completed13:33
fwereaderogpeppe, it might always fall over next hook13:34
rogpeppefwereade: sure. that's why i would define "success" at the juju level at all13:34
rogpeppefwereade: i *think* that output variables provide sufficient tools for a charm to communicate "success" by whatever definition it chooses13:35
fwereaderogpeppe, I'm reluctant to abandon the idea that it should be mediated by juju somehow13:36
rogpeppefwereade: how do you mean? you think there might be some general definition of "success" in this context?13:36
fwereaderogpeppe, I think the one I'm proposing has some utility, yes13:38
rogpeppefwereade: ISTM that it's too low level and may be fragile if people come to rely on it extensively13:39
rogpeppefwereade: it's also going to be hard to implement, i suspect - how can you actually tell when a client has no more hooks to execute?13:40
fwereaderogpeppe, "has this unit successfully responded to all known changes [in this relation ]without errors?" doesn't seem so hard to me13:40
rogpeppefwereade: what does "respond" mean in that context? changes with respect to what base state?13:41
fwereaderogpeppe, "responded to" = "run all relevant hooks", right?13:42
TheMuenate_finch: your yesterdays tweet about 90% of programming is so damned right. i currently trying to find an elegant way to get the log dir which is different for containers like lxc or kvm. and the information is wonderfully private. *sigh*13:42
rogpeppefwereade: so every time you run a hook, you store that in the state?13:43
rogpeppefwereade: ISTM that output variables would be considerably easier to implement, have less runtime costs, and give access to a very useful range of new capabilities.13:44
fwereaderogpeppe, no13:46
fwereaderogpeppe, the GUI team *is* asking for that, and I think I'm ok activating that for specific units, but I don;t want a constant spew from all of them13:46
rogpeppefwereade: so you think output variables are a bad idea in general?13:48
fwereaderogpeppe, no, I just don't think they solve the "wait for a unit to be ready" use case we already know we have13:48
nate_finchTheMue: yeah, I was trying to get the mongo port from the machine config into the machine agent.  Should be easy, but it's not13:49
fwereaderogpeppe, but that the report-busy-idle stuff *does* solve the are-we-ready-yet problem13:49
fwereaderogpeppe, if we do it via output variables we fuck the gui13:49
rogpeppefwereade: there's no way in general to wait for a unit to be ready. a relation between A and B might have been successfully made, but it's quite possible that for a unit in A to be ready, B must have a made a relationship with C13:49
fwereaderogpeppe, yes, you have to wait for the whole system to get to idle before you can be confident the whole thing will remain stable until perturbed13:50
rogpeppefwereade: even then, you can't do it13:50
rogpeppefwereade: units can asynchronously do stuff now, right?13:50
fwereaderogpeppe, I consider juju-run to be a perturbation13:51
rogpeppefwereade: the system may very well never become idle13:51
fwereaderogpeppe, I think that's a symptom of a problem with the system that's been constructed then13:51
rogpeppefwereade: not necessarily13:51
rogpeppefwereade: it might be perfectly reasonable for a charm to provide some update on a relation every few seconds13:52
rogpeppefwereade: i don't think we should focus too much on "idleness"13:52
rogpeppefwereade: i think we should be much more interested in "history"13:53
fwereaderogpeppe, I am having some trouble imagining a use case there13:53
TheMuenate_finch: sounds familiar ;)13:53
fwereaderogpeppe, you use the relation settings to set up the channel over which the fast-changing info flows, surely13:53
rogpeppefwereade: for example: a service that's a gateway to another service with a bunch of servers that are changing. it has a relation attribute that contains that set of servers.13:54
rogpeppefwereade: it depends how fast-changing it is.13:54
rogpeppefwereade: if something's changing on the order of once every 10 seconds, i think it may be reasonable to use relation attributes13:55
rogpeppefwereade: and the point is: we've provided the capability, so people will do it *anyway*13:55
rogpeppefwereade: and it would be good to make our tools cope well when it happens13:55
fwereaderogpeppe, I think that it's perfectly reasonablefor us to report such a system as unstable then13:56
fwereaderogpeppe, that's coping perfectly with a system that's unstable13:56
rogpeppefwereade: unstable is fine - we can still do useful work with an unstable system13:57
Beretfwereade, how would that screw over the GUI?13:57
rogpeppefwereade: as an example of another possible approach, we could provide a "hook history", that lets us know which hooks have been executed in a given unit.13:57
rogpeppefwereade: when a hook is run twice, we overwrite that hook's previous entry in the history13:58
fwereadeBeret, if we let people use a completely unstructured channel to report working/not-working, the gui won't be able to show a useful distinction13:58
Beretah, I was assuming the output variable would have to be structured13:58
fwereadeBeret, busy/idle *can* be interpreted by the GUI and drawn as pale-green/solid-green or similar13:58
rogpeppefwereade: each entry in the history could have its own time stamp.13:59
sparkiegeekor some egg timers/beachballs ;)13:59
fwereadeBeret, the "output variables" idea is that they be minimally structured -- it's the flipside of charm config, which is really a service's "input variables"13:59
rogpeppefwereade: the other thing is that a unit may look idle from a juju point of view, but be very busy internally14:00
rogpeppefwereade: we could easily impose some conventions on output variables14:00
rogpeppefwereade: to let charms show their status to the GUI in a standard way, for example14:01
fwereaderogpeppe, the same sort of thing that worked so well with haproxy and private-address, for example?14:01
rogpeppefwereade: remind me14:02
fwereaderogpeppe, haproxy has "host", everything else in the world uses "private-address"14:02
fwereaderogpeppe, relying on convention is I think inadequate14:03
rogpeppefwereade: if you don't use the conventions, the GUI won't see you. seems reasonable to me.14:03
fwereaderogpeppe, and if you accidentally use them, the gui acts werd14:03
rogpeppefwereade: you could even have the uniter set output variables actually14:04
rogpeppefwereade: (the history idea above could work that way)14:04
rogpeppefwereade: convention can work well14:04
rogpeppefwereade: i prefer a general mechanism with some conventions to building more and bigger Stuff14:05
dimiternmgz, fwereade, meeting?15:00
dimiternwe can use this https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig15:01
cgzdimitern: I didn't add a hangout or anything... let's use that15:01
jamespagefwereade, any thoughts on that suggestion I made re juju letting charms know if units are alive?15:09
=== nate_finch is now known as natefinch
fwereadejamespage, well, I am still not sure it'll really solve the problem16:18
fwereadejamespage, I know the "idle" hook I mentioned is not a thing, but I'm still interested to know if it helps you16:18
* fwereade maybe missed a followup elsewhere..?16:19
natefinchrogpeppe: WIP - https://codereview.appspot.com/53220043/   ignore the replicaset.go changes.. just some extraneous changes that got on the wrong branch.16:36
jamespagefwereade, sorry - idle hook?16:50
jamespagemust has missed that bit16:50
rogpeppenatefinch: reviewed17:01
natefinchrogpeppe: thanks17:06
natefinchrogpeppe: about restarting mongo every time the machine agent bounces... I had been assuming we'd only call this method when we knew the upstart script was either out of date or missing (i.e. on upgrade from previous versions, or when starting a new state server).  I think either we'll know when we need to call this, or if we aren't sure, we'll have to call it every time just in case.17:21
rogpeppenatefinch: the idea was that we'd call it if when starting up and we find we have a ManageState job17:22
rogpeppenatefinch: that's kind of the point17:22
rogpeppenatefinch: in that case we need to start the mongo server if it's not already started17:23
natefinchrogpeppe: right, it occurred to me after I said that, that the "Ensure" part of the name means that logic should be encapsulated17:25
rogpeppenatefinch: yes please :-)17:25
mattywrogpeppe, what happened to that charm lib you were writting in go?17:29
rogpeppemattyw: launchpad.net/juju-utils/gocharm17:30
rogpeppemattyw: um, maybe i got the path wrong there17:30
rogpeppemattyw: launchpad.net/juju-utils/cmd/gocharm17:30
=== bjf[afk] is now known as bjf
mattywrogpeppe, in here? lp:juju-utils17:30
rogpeppemattyw: yeah17:31
rogpeppemattyw: for docs, see http://godoc.org/launchpad.net/juju-utils/cmd/gocharm17:31
rogpeppemattyw: and http://godoc.org/launchpad.net/juju-utils/hook17:31
rogpeppemattyw: the latter is the actual charm hook interface that you write code against17:32
rogpeppemattyw: the former just compiles the code and generates hook stubs17:32
mattywrogpeppe, looks awesome, will try to have a play with it over the next few days17:33
rogpeppemattyw: please do. i'd love any feedback at all.17:33
natefinchoh local environment... why do you have to throw a wrench in everything?18:20
jcastrohey sinzui19:08
sinzuihi jcastro19:09
jcastroyou still get this right? https://bugs.launchpad.net/golxc/+bug/123854119:09
jcastroit's making life annoying, I was wondering maybe we can bug a core dev together today?19:09
* natefinch ducks19:09
_mup_Bug #1238541: Local provider isn't usable after an old environment has been destroyed <intermittent-failure> <local-provider> <golxc:New> <https://launchpad.net/bugs/1238541>19:09
jcastronatefinch, look at how easy it is! :)19:10
jcastronatefinch, I can also just prod the list if you'd like19:11
sinzuijcastro, I will get someone to investigate it. I thought bug 1269363 may have indirectly addressed the issue19:12
_mup_Bug #1269363: local environment broken with root perms <local-provider> <ssh> <juju-core:Fix Committed by thumper> <https://launchpad.net/bugs/1269363>19:12
natefinchjcastro: yjrtr19:12
natefinchjcastro: there's a branch with a fix already submitted.  I can probably just approve the branch19:13
jcastrothat would be swell, we're doing a bunch of bootstraps/teardowns as part of the audit and cleaning up the containers by hand gets old after a while, heh19:14
sinzuibugger, I cannot manage the bugs in golxc19:14
sinzuioh, it is not a part of juju-project. Either a mistake of the project really isn't about juju19:15
natefinchsinzui: I approved the fix and marked the bug as fix committed19:17
sinzuithank you natefinch19:18
jcastronatefinch, I owe you a beer, thanks!19:36
thumpermorning folks20:05
thumpersometimes it feels like I never stop working20:06
thumperthat is what 11pm meetings do for you :-(20:06
natefinchthumper: haha... I know the feeling... 5am meeting for me :)20:06
* thumper nods20:06
thumpernatefinch: got a minute to chat?20:07
natefinchthumper: sure20:07
thumpernatefinch: I want to bounce an idea off someone20:07
natefinchthumper: I can be your rubber duck20:07
thumpernatefinch: looking for more of a teddy bear https://plus.google.com/hangouts/_/7ecpi3me7dl01vto2l2n3368ns?hl=en20:07
natefinchthumper: not sure if that's better or worse ;)20:07
hazmatfor juju datadir normally is just /var/lib/juju?20:22
* hazmat is trying to interpret some api params20:22
natefinchhazmat: yeah20:23
natefinchhazmat: I'm going to assume that hmm means everything is going perfectly. ;)20:54
hazmatnatefinch, magically delicious as always20:56
hatchlooks like `juju destroy-environment local` removes some files which causes `sudo juju destroy-environment local` to fail looking for those files putting it into a "corrupt" state21:39
hatchhas anyone noticed this before?21:39
sinzuihatch, thumper fixed a similar issue to that yesterday21:41
hatchsinzui oh awesome21:42
thumpershould fix that...21:42
hatchmy test machine isn't the most pristine environment so I always like to confirm with others before I file bugs haha21:44
wallyworld_thumper: there's some stuff i'm keen to land which has been partially reviewed. how many beers/red wine would it take to get you to look and hopefully +1?21:53
thumperwallyworld_: how long are they? the longer they are, the more wine it takes21:56
wallyworld_not tooooo long21:57
wallyworld_https://codereview.appspot.com/48880043/ https://codereview.appspot.com/49510043/ https://codereview.appspot.com/49500043/21:57
wallyworld_not too short either21:58
* wallyworld_ goes to order a case of the finest French red21:58
thumperwallyworld_: https://codereview.appspot.com/49510043/ can you respond to williams comments?22:38
wallyworld_thumper: looking22:46
wallyworld_thumper: yeah, i implemented that but didn't respond because i talked to him verbally and thought he'd do the last review22:47
wallyworld_will comment22:47
thumperwallyworld_: ta22:50
thumperwallyworld_: I'll take a look again after the gym22:51
wallyworld_thumper: ok, appreciate it thanks22:51
sinzuithumper, wallyworld_ , Nate marked this branch approved to merge a few hours ago, but I don't think he realised that it is managed by ~juju, not gobot. Are either of you comfortable doing the merge and push? https://code.launchpad.net/~patrick-hetu/golxc/fix-1238541/+merge/20084522:52
wallyworld_sure can do22:52
wallyworld_will do now22:52
wallyworld_sinzui: that should be done22:58
sinzuithankyou wallyworld_ . Lp agrees22:59
wallyworld_sinzui: how is the streams.c.c stuff going?22:59
sinzuiI learned that Ben was testing the deployment today. I hope for tomorrow to be done22:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!