[01:24] wallyworld_: you around? [01:24] yep [01:25] good [01:25] * thumper is proposing the lxc-container branch *again* [01:25] where else would i be [01:25] wallyworld_: I dunno, fucking around? [01:25] enjoying a hot shower? [01:25] well, the weather is nice outside [01:25] * thumper snorts [01:25] not funny [01:25] well, it is shit here [01:26] wallyworld_: how's the bathroom? [01:26] not quite done. tradesman is a total fuckwit. we'll be reporting him to the Building Services Authority, but need to get him to finish as much as we can first [01:27] hope you took pictures [01:27] yep [01:27] wow [01:27] been watching some home renovation programs on sky, damn scary what some builders do [01:28] hoping to get some that don't suck for our work [01:28] I can only think of one profession that doesn't con customers more than builders [01:28] * thumper waits for lbox to continue generating the diff [01:28] yeah. and i got the worst tiler in queensland according to people who i have talked to since [01:28] that does, I mean [01:28] bigjools: software developers? [01:28] thumper: got it in one [01:28] politician [01:28] I don't consider politics to be a profession [01:28] ok, perhaps politicians [01:28] haha [01:29] serial troughers maybe [01:29] wallyworld_: https://codereview.appspot.com/10370044 another round? [01:29] alright [01:29] ta [01:30] dog is being a nutter today [01:30] is outside [01:30] so much for this being a family channel :) [01:31] yeah, I felt guilty as soon as I swore :) [01:31] you guys are a bad influence [01:32] I thought I was bad until I met Ian [01:32] heh [01:32] I was much worse when I first went to the UK [01:32] had to tone things down a lot [01:32] and not use swearing as punctuation, or as adjectives too often [01:33] I expect the politically correct HR drones had some policy on it ... [01:33] everyone got asked to go on some "sensitivity" training at one of the banks I was at [01:34] as a contractor I told them to get fucked [01:34] thumper: i had a branch that william has +1'ed to remove that Instance.Metadata() method. if you +1 it also, i can land it and you could tweak your branch before landing https://codereview.appspot.com/10384049/ [01:34] kk [01:35] bigjools: haha [01:35] thumper: there's no crisis that can't be solved by sending in the diversity coordinators, apparently [01:36] pfft [01:36] was that a fart? [01:36] no [01:37] like *snort* [01:37] things you miss by typing stuff [01:37] miss all that non-word verbal communication [01:38] aye, it's hard to talk without waving your arms around [01:46] wallyworld_: so right now, we are doing nothing with this metadata? [01:47] thumper: i have a branch which has been reviewed which i need to fix some things on. the branch writes the metadata to state. [01:47] wallyworld_: what happens if I return nil, or a real struct where all the values are nil? [01:47] just return nil [01:48] it will create an empty record in the db [01:48] with just the InstanceId and Nonce [01:48] and mem, cpu cores etc will be blank [02:13] sigh [02:13] seems like Go doesn;t coerce ints to floats [02:13] haha [02:13] no [02:14] it doesn't even promote ints [02:14] into bigger ints as needed [02:14] O_o [02:14] needs explicit cast [02:14] wallyworld_: https://codereview.appspot.com/10409049 for the broker [02:15] davecheney: you could cast your "on call reviewer" eye over too maybe? [02:15] davecheney: are you still doing on-call reviewing in your current role? [02:25] wallyworld_: ta [02:25] np [02:47] wallyworld_: what is the point of the PublicAddress, PrivateAddress, and InstanceId functions on environs.EnvironProvider? [02:47] they don't seem to make any sense [02:48] why does a provider have an ip address or instance id? [02:49] thumper: i think each machine has a provider instance. i agree it doesn't make sense [02:49] huh? [02:49] that is nuts [02:50] sounds broken [02:50] i'm not across the design decisions there, before my time [02:50] * thumper nods [02:50] but i agree with you [02:50] I'll be up late tonight to talk with fwereade__ anyway [02:50] I'll add it to my WTF question list [02:50] if i'm around i'll listen in [02:51] i think william wants to refactor all this stuff [02:51] there's a few interfaces with inappropriate methods [02:56] thumper: am I on call today ? [02:56] as to the other question, NFI [02:57] davecheney: according to the juju google calendar [02:57] * thumper does school run [02:57] my bad [03:10] wallyworld_: does the provider interface require a separation between public and private storage? Or can it all be private? [03:13] bigjools: it could all be private. may require a tweak to some auxiliary code [03:13] wallyworld_: is there any use for public at all then? [03:13] yes, to store the tools [03:14] snd simplestreams metadata [03:14] does juju upload simplestreams stuff? [03:14] no [03:14] thought that was seaprate [03:14] ok [03:14] it is expected to be created to match the cloud [03:14] there's a tool which can be used to make a starting metadata file [03:14] the tooling needs to be refined [03:15] so if one person uploads tools to a public place and then removes them, does someone else get to auto-upload tools? [03:15] and how is authenticity guaranteed [03:15] it's not [03:15] \o/ [03:15] design flaw [03:15] the idea right now is that only authorised people get to write to the public bucket [03:16] so those people need to be trusted [03:16] so there's just one public storage [03:16] one per cloud [03:16] there's one for ec2, canonistack, hp cloud etc [03:17] the tools tarballs are currently replicated across each [03:17] so what's the procedure for the first upload to a public place? [03:18] the juju release manager uploads to the ec2 pubic bucket, then uses sync-tools cmd to help replicate to other public buckets [03:18] ah ok [03:18] the new upcoming simplstreams stuff makes it a bit better [03:18] and the tarballs will be signed also [03:18] so for our new provider, someone would upload the tools before any deployments would take place [03:19] yes [03:19] for certified public cloud partners, the tools are uploaded/maintained as part of the release process [03:19] presumably *someone* must be thinking about some sort of GPG signature downloadable over https from a trusted site? [03:19] yes [03:20] for private clouds, we will provide tooling to make setup easy [03:20] ok so I'll work on a change I need to make public storage available then [03:20] was wondering whether it was really neede [03:20] d [03:21] bigjools: is this for a CPC partner? [03:24] bigjools: if so, then the metadata for tools and images will be hosted on a canonical url, and that metadata will point to the cloud's pulic bucket to actually get the tools from [03:24] wallyworld_: right [03:24] and juju at some point will gpg verify the md5 of the tools. [03:25] yes [03:25] please tell me that is going to happen [03:25] real soon now [03:25] working on it [03:25] splendid [03:25] * bigjools thinks about booking flights to Europe [03:25] a few things are happening in that space, might be a release or two away [03:27] bigjools: you in IOM? [03:27] bigjools: you get to fly? [03:27] thumper: supposed to be there [03:27] still not sure about going [04:40] bigjools: in the maas provider, i'm going to add a NOP when it comes to returning hardware characteristics about a started instance (mem, cores etc). i'd like to raise a bug for it. ec2 and openstack will have this supported. will it take much to do for mass? [04:42] wallyworld_: are you going to land the instance metadata work? [04:42] * thumper off to take kids ice skating [04:42] back after dinner [04:42] * thumper away === thumper is now known as thumper-afk [04:49] wallyworld_: easy, all that stuff is already supported for the python provider [04:50] so why not fix it :) [04:56] bigjools: i'll just land the current branch for now and raise a bug. thumper is queued up behind this branch [04:56] yeah no worries [04:57] it was on our hitlist when doing the new provider [05:15] bigjools: bug 1193998 [05:15] <_mup_> Bug #1193998: mass provider doesn't return hardware characteristics of started instances [05:16] ta. if we get to it, we get to it [06:04] fwereade__: ping [06:37] wallyworld_: sorry I missed our 1:1. I rebooted my machine, and then wasn't paying attention. I'm making a coffee real quick and then I'll be around if you are available. [06:41] jam: hi, no problem. i saw you log off. can we reschedule to tomorrow. a *new* tiler has just arrived and i have a little bit of stuff to sort out [06:41] * wallyworld_ still has no finished bathroom :-( [06:42] wallyworld_: wow. That bathroom is causing you so much grief. Time to just put in an Outhouse and be done with it. :) [06:42] wallyworld_: we can reschedule for tomorrow, no problem [06:43] can someone give a quick look at https://codereview.appspot.com/10465043/ it is a pretty small patchd [07:02] mornin' all [07:02] fwereade__: ping === rogpeppe1 is now known as rogpeppe [07:03] jam: question - i got a mp approved, and did a few small bits of followup after the lgtm, but now the bot is saying i have unapproved revisions :-( [07:03] that never used to happen [07:03] wallyworld_: you have to push, and let Launchpad see the new revs, and then Approve [07:03] I re-approved it for you [07:03] wallyworld_: you might also need to reload the MP [07:03] ok, thanks. i thought i had pushed but maybe not [07:04] as it stores the 'current' revision when it is loaded, and sets the approved revision to the one it saw [07:04] wallyworld_: you did push [07:04] you didn't wait for the MP to refresh before you marked it Approved [07:04] ah ok. in too much of a hurry [07:04] so the MP was at eg rev 10, you pushed rev 11, and marked rev 10 as approved, but not rev 11 [07:13] wallyworld_: any chance of a review of https://codereview.appspot.com/10447047/ or https://codereview.appspot.com/10259049/ ? would be much appreciated. [07:14] rogpeppe: i'm running late for soccer. i'll be back in about 3 hrs. sorry [07:14] wallyworld_: np [07:14] wallyworld_: thought i was probably too late, just pushing my luck :-) [07:15] wallyworld_: Hi… jam's explanation on MP is enough (I think) for me to work on the missing URL() method… but I'd rather work on it in a different branch and get this one (https://codereview.appspot.com/10237046/) reviewed now… could you please have another look when you'll be back fro soccer? [07:17] rogpeppe, heyhey [07:17] fwereade__: yo! [07:17] fwereade__: wondering if you fancy a chat about moving the api connect stuff forward [07:18] rogpeppe, yeah, sounds sensible, would you start a hangout please? [07:18] fwereade__: doing [07:19] fwereade__: https://plus.google.com/hangouts/_/b51c68bb41b0ebd90ac5ae51531a89f50e298495?authuser=0&hl=en-GB [07:19] rogpeppe, fwereade__: Mind if I listen in? I probably won't add much, but I'd like to follow the conversation. [08:00] danilos: be there in just a second [08:01] jam: ack === thumper-afk is now known as thumper [08:34] fwereade__: hey [08:34] thumper, heyhey [08:35] fwereade__: got some time? I've got lots of questions [08:35] thumper, how's it going? [08:35] thumper, sure, just a sec [08:36] thumper, ready [08:36] * thumper starts a hangout [09:09] fwereade__: have you got provider-specific constraints on the plan? [09:13] bigjools, sorry, 5 mins [09:52] fwereade__: we lost you [09:53] heh, I can still hear you [09:53] bigjools, rvba, I was just asking if it was just maas-name and maas-tags, or if we missed something else [09:53] bigjools, rvba, if you've ok piggybacking name on tags I'm ok with adding tags [09:54] fwereade__: that's all: maas-name (can probably be supported as tags) and maas-tags. [10:14] fwereade__: does my MP from last week look OK now? https://codereview.appspot.com/10407045/ [10:16] jtv, huh, looks like you're right about the validation on SetConfig. grar. [10:18] jtv, I don't think it should really be the SetEnvironmentCommand's responsibility; I could accept it being *state*'s responsibility not to mess it up, but state can't do that very easily due to some decisions we made a while back [10:18] bah [10:18] fwereade__: true, the place where the responsibility really belongs is missing, isn't it? [10:19] I was also wondering why the ec2 and openstack providers continue to write to environ.name when it's being read without locking. [10:20] jtv, search me... I would honestly not hold up any of our providers as shining beacons of best practice [10:20] Functionality is easier to retrofit than concurrency correctness. [10:20] jtv, would you be ok adding the validation in SetConfig regardless of what ec2/openstack do? [10:21] already did — didn't the diff update? [10:21] jtv, can't see the changes myself [10:22] jtv, it doesn't happen automatically on push, you need to `lbox propose` again [10:22] Argh [10:23] Our lives would become so much easier if we could just use one kind of reviews... [10:23] It's especially annoying if it means switching back to another branch while you're already working on another. [10:23] jtv, heh, yeah, I can understand that [10:24] wallyworld_: I just realized I forgot to lbox propose again (with the fixes) so you probably did not see the diff being updated, I've done it now (https://codereview.appspot.com/10237046/). [10:24] (Also, it'd be nice if lbox could actually bother to check for fatal errors... someone once wrote that whoever doesn't do that in Go ought to be fired :) [10:24] jtv, I would be loath to give up the line-specific comments, but it seems to be fading in importance a little given the trunk-gating [10:25] * fwereade__ refrains from comment [10:25] What's trunk-gating? [10:25] It sounds lumber-related. [10:25] jtv, we now have tarmac to land approved branches [10:25] Ah that [10:25] Do the two interact? [10:26] jtv, not very much, no -- `lbox submit -tarmac` might be nice, though [10:26] jtv, we've had a few branches get in without being `go fmt`ed [10:26] It'd also need to submit a commit message, rather than just a description... [10:27] jtv, yeah, that's not such a huge change, really [10:27] jtv, but nobody's actually working on changing it at the moment [10:28] I also find the line-based comments rather hard to work with as a reviewee... I'd be perfectly happy to go with the normal Canonical procedure completely. [10:29] Well, it looks like I've re-proposed. Let's see if the branches will marry. [11:24] fwereade__: the tarmac rules should be "go fmt ./... && go build ./... && go test ./..." so we shouldn't have anything land without formatting. Are you talking about the lbox rules? [11:25] jam1, hmm, I've had lbox complain about go fmt issues on propose twice now === jam1 is now known as jam [11:25] jam1, does it definitely merge the code it runs, and not just merge the source branch from which it got the code? [11:26] jam,^ [11:26] double underscore versus 1... [11:26] fwereade__: It should run the test suite, and then commit/not commit, It doesn't restage the commit a second time after the test suite passed. (AFAICT) [11:27] running go fmt as part of tarmac seems a little risky, as that has changed between go versions so is inconsistent [11:27] mgz: it just means we're 100% consistent in what lands on trunk :) [11:28] mgz, jam, ahh -- remind me, which go does tarmac use? [11:28] but does it actually commit post fmt? [11:28] mgz: it does the fmt pre merge check [11:28] so it should land it post fmt [11:28] I guess we trust fmt not the break stuff... [11:28] mgz: I just checked the last 20 revs, and none of them had complaints for *my* go fmt. [11:30] it's 1.0 from distro on the bot right? [11:31] fwereade__: so I know lbox check uses 'gofmt' rather than 'go fmt' I don't know if there is a difference there. But I just checked the last 100 commits to trunk, and 100% of them have 0 output running 'go fmt ./...' [11:31] to verify, I manually mutated a file while it was running, and it complaine.d [11:31] fwereade__: so if you see lbox complain, let me know [11:32] but I can't reproduce (and I'm guessing it might be because of your own local changes) [11:32] fwereade__: could it be a go 1.1 vs 1.0.3 formatting issue? [11:33] mgz: https://plus.google.com/hangouts/_/8868e66b07fa02bdc903be4601200d470dae9ee3 [11:33] ya [11:33] jam, yeah, I was wondering about that [11:33] jam, I'm on 1.1 [11:36] fwereade__: so go 1.0.3 is happy with all of the last 100 commits. [11:36] fwereade__: so it must be you :) === jam1 is now known as jam [11:36] jam, ha, ok, I'll look closer next time I see it and try to figure it out [11:37] jam, 1.1 vs 1.0.3 seems likely though [11:38] any chance of a review of https://codereview.appspot.com/10447047/, please? it's considerably more deleted code than added code. [11:43] jam: there are definitely gofmt 1.1 vs 1.0.3 differences [11:43] jam: there's no difference between gofmt and go fmt (they use the same tool) [11:45] rogpeppe1: they take different args, at least. [11:45] jam: go fmt calls gofmt [11:46] * rogpeppe1 quickly goes to check he's not talking out of his arse [11:46] yes, that's true [11:46] jam: it's even in the docs: " [11:46] Fmt runs the command 'gofmt -l -w' on the packages named [11:47] by the import paths. [11:47] " === rogpeppe1 is now known as rogpeppe [11:47] jam: i have the go1.0.3 version of gofmt in my PATH, so that's what i always use to format code [11:51] rogpeppe: you've got a review [11:51] TheMue: thanks! [11:59] rvba: hi, sorry i missed your earlier message. i was at soccer. i look at the codereview link but the 2nd patchset is not there. i looked at the diff in lp and it looks ok. i just have a more minor comment - use %q instead of '%s' to quote a string value in a printf call [12:16] mgz: any chance you'll be able to land https://codereview.appspot.com/10439043/ today? i have a branch that depends on it. [12:18] fwereade__: you asked for some more tests about the Machiner watcher code (to test the API .Next() behavioR) [12:19] fwereade__: from what I can see, there is 0 client code that follows any watcher that was set up in the API [12:19] jam, ah, yes -- I guess there's some subtlety that I'm missing? [12:19] there is a function "state/api/watcher.go" that has "newEntityWatcher" which is not an exposed function, and nothing calls it. [12:20] fwereade__: so the code adds an ability to start a watcher on the server [12:20] but AFAICT there is no functionality for actually following that watcher on the client. [12:20] jam, I was hoping that the unit tests for the machiner would grow the infrastructure necessary to make a naked Next call with the returned watcher id and check that it does something [12:20] jam, the client side is a different problem, I think [12:20] wallyworld_: I think the new mp is there: https://codereview.appspot.com/10478045/ [12:21] fwereade__: so there should be a APIServer.resources[id] object [12:21] jam, I'm only thinking of the unit-ish-testing of the server side [12:21] fwereade__: is that reasonable? [12:21] rogpeppe: as jam says, trying to do that now, but working out how to get reasonable test coverage is frustrating me [12:21] fwereade__: also, *I* am a little confused about what Next() is vs what Changes() is . [12:21] * rogpeppe goes for lunch [12:21] wallyworld_: I did not realize re-proposing a branch creates yes a new MP. [12:21] jam, hmm, isn't the resources stuff done via an interface anyway? [12:21] rvba: no problem, looking now [12:21] jam, so we can completely control that, I think [12:22] jam, Next() means please-read-from-Changes()-and-return-what-you-got [12:22] jam, but in fact I don't even care about that here, now I think about it [12:23] jam, the Resourcerer or whatever interface will presumably be expected to have a watcher registered [12:23] rvba: done. thanks for adding the notfound code [12:23] jam, the mock can check the registered resource is sane, and pick an id to give back to the machiner, and the test can then check that id came back [12:24] jam, sane? I may be forgetting something about the resources, I don't know it well [12:24] wallyworld_: thanks for spotting that problem :) [12:24] no wuckers [12:25] jam, fwiw, there is some rambling in the -wip https://codereview.appspot.com/10495043 that I was working on over the weekend [12:25] fwereade__: right now the API for Resources is that they have a "Stop()" method. [12:25] however, he could probably cast it to the actual Watcher [12:25] because we humans know its actual type [12:25] jam, +1 [12:26] jam, in fact, independent of its relevance this second, I would appreciate your thoughts on that CL [12:27] jam, it's a bit dashed off because I have other stuff to do but I hope to land something related eventually [12:30] fwereade__: I will try to look at the code you mention. [12:30] fwereade__: in the mean time, you mention Next [12:30] jtv, LGTM, just one tweak [12:30] but all I specifically see is "Changes" [12:30] Thanks fwereade__ [12:30] jam, yeah, I had my layers confused [12:30] the thing stored in the resources is a state.EntityWatcher [12:32] jam, and there was/will be some sort of Next method somewhere that takes a resource Id and returns the next thing to come out of its changes channel (or an error if it's stopped) [12:32] jam, it appears that does not exist at present [12:32] jam, but it's not actually needed for testing this [12:33] jam, because we can write unitier tests anyway without bringing it into the mix [12:33] jam, sorry, I didn't think that one all the way through [12:34] fwereade__: right, we were a bit confused because we couldn't find (a) anything client-side that could actually follow a watcher and (b) something called Next() :) [12:35] fwereade__: apparently (a) has been designed and is called Next() [12:35] jam, that said, to write a client watcher, we will need to make Next calls -- and there is code in history that does that [12:35] but hasn't been implemented [12:35] jam, I think it was removed with the change [12:35] fwereade__: there is nothing in trunk today that I could find. [12:36] fwereade__: well, there is for the AllWatcher [12:36] jam, it would have gone in one of dimitern's commits the week before he left [12:36] but not for the EntityWatchers that we have. [12:36] jam, if you find that code it will serve as a useful model [12:37] jam, but it had a couple of issues -- I think the entitywatcher variant was ok, but the lifecyclewatcher would drop events [12:38] jam, there are a couple of possible approaches to that [12:38] fwereade__: drop all events so nobody notices? [12:38] :) [12:38] jam, the description in CL above really is relevant there :) [12:38] jam, sorted [12:38] jam, let's go shopping [12:39] jam, basically we can either implement client-side coalescence when a second change comes in before we've delivered the first [12:39] jam, (lots of work, duplicated from elsewhere, although it cold probably be factored into cleanliness) [12:40] jam, or we can flip-flop client-side watchers from send to receive mode [12:40] jam, so we get the result of Next(), then sit and wait until our client reads it from our channel, and only then make another Next call [12:41] jam, this is pretty nice, and a hell of a lot simpler [12:41] fwereade__: doesn't that leave you with stale Next() results? Is it possible to not call Next until someone actually cares and we have the coallescing done in the server? [12:41] jam, well, the Next calls do in fact cause some coalescence on the server [12:42] jam, because the watcher coalesces internally until someone reads from Changes, and that only happens when we call Next [12:42] jam, however, there is going to be an unintended consequence there with the code as it stands [12:44] jam, specifically: (1) api server syncs state (2) client calls Next, no more changes (3) state syncs again, 100 changes come in (4) the first change is delivered on Changes and returned from Next (5) the client has to handle that one, and call Next *again* before he sees the rest of that block of 100 changes [12:45] fwereade__: do you see a block of changes, or just one-by-one ? [12:45] jam, in theory you can see blocks [12:45] jam, how much you do in practice depends on the specific watcher [12:46] fwereade__: EntityWatcher.Changes() has a channel that is essentially just a boolean "something happened" [12:46] I guess LifeCycleWatcher gets an array of strings? [12:46] jam, and they are all currently implemented in a way that, given the characteristics of the underlying state/watcher implementation, tends towards single events [12:46] s/array/slice/ [12:47] jam, yeah [12:48] jam, coalescence is indeed much easier for the entity watchers [12:48] jam, but even then, it tends twoards suboptimal behaviour [12:48] jam, hmm, actually, maybe not so much there [12:48] jam, maybe single documents are ok across the board [12:49] fwereade__: well getting 100 'something has changed' calls all at once is a bit annoying. It really depends how the backlog is treated. [12:49] jam, agreed [12:50] jam, that shouldn't be a problem with the entity watcher [12:50] jam, it is a problem I recently discovered in the scope watcher, though [12:50] jam, that's that CL === fwereade__ is now known as fwereade [12:56] fwereade__: mgz added a call to Changes, does it look reasonable to you? (https://code.launchpad.net/~gz/juju-core/057-api-machiner-watch/+merge/170586 line 212, CL is in the process of updating) [12:57] jam, mgz, that looks perfect in essence but I'm suspicious of getting that event out of it; just a sec [12:58] that event? [12:58] NotNil is all I;m asking of it [12:58] I'd *like* to make that a useful assertion [12:58] mgz, according to the previous implementation you wouldn't have got one at all [12:59] and maybe have proper checks for yeah, no event at all/timeout/whatver [12:59] mgz, because that one read and returned the initial guaranteed Changes() event as part of the Watch() call [13:00] mgz, that approach makes some sense, I think, because all watchers are meant to return an initial event describing the difference between no-state and the current state [13:00] mgz, and it would be nice to help the client watcher implementation by delivering the first event straight-off [13:02] mgz, so in that case you'd be able to extract a resource that's an EntityWatcher for the machine you know about, and do a quick check that no events are produced until you write a change to the machine [13:02] fwereade: I would *really* like to see an example test along those lines to work off [13:02] mgz, just as you do, but with one extra check verifying the bit of behaviour you missed because you had no way to know about it [13:03] mgz, I just (at least partially) unfucked most of the ones in state actually [13:03] mgz, state/watcher_test.go [13:03] thanks [13:04] mgz, they're internal at the moment but I'm fine promoting them somewhere else if they're useful to you [13:06] what do you mean by internal? [13:06] mgz, NotifyWatcherC looks like it might actually be *exactly* what you need [13:07] mgz, in the state_test package [13:07] but... I could just use that, no? [13:07] mgz, hmm, I thought you didn't get _test.go code compiled in except for the package currently under test [13:08] fwereade: correct [13:08] surely I can just import state/state_test [13:08] you have to move it to a testing module [13:08] mgz: nope [13:08] ;_; [13:09] it would be 'state_test' but that won't look up in the module path [13:09] okay, so I'll land this with copy-code, then maybe move that [13:14] * fwereade grudgingly approves of mg's plan, so long as he follows up with the fix asap ;p [13:14] mgz's [13:23] ...I keep getting "panic: watcher was stopped cleanly" instead of any useful failures [13:23] mgz: just looked at your branch [13:23] mgz: one thing: [13:23] I guess the stop needs do be a defer or something [13:24] mgz: the event coming off the entity watcher channel can never be nil [13:24] mgz: it's a struct{} [13:24] rogpeppe: that was an entirely stub assert [13:24]