| davecheney | niemeyer: testing/mgo_test.go wasn't being run | 01:48 |
|---|---|---|
| davecheney | i'll roll that fix into my next proposal | 01:48 |
| niemeyer | davecheney: Oops.. thanks! | 02:14 |
| davecheney | niemeyer: https://code.launchpad.net/~niemeyer/goetveld/trunk/+merge/126136 | 02:19 |
| davecheney | ^ not propsed with lbox, sorry | 02:20 |
| davecheney | urgh, change list is empty as well ... | 02:22 |
| davecheney | ahh, because i did it ass backawards | 02:24 |
| davecheney | niemeyer: https://code.launchpad.net/~dave-cheney/goetveld/001-add-darwin-termios-support/+merge/126137 | 02:25 |
| niemeyer | davecheney: LGTM | 03:16 |
| niemeyer | davecheney: I've just changed the project so it's trunk is owned by the gophers team | 03:16 |
| niemeyer | s/it's/its/ | 03:16 |
| niemeyer | davecheney: Please feel free to repropose against the new trunk and submit it straihgt | 03:16 |
| niemeyer | straight | 03:16 |
| * niemeyer => bed | 03:24 | |
| fwereade | ha! my first Refresh-related bug with a long-lived-entity | 07:52 |
| rogpeppe | fwereade: morning! | 07:52 |
| rogpeppe | fwereade: it was bound to happen | 07:52 |
| fwereade | rogpeppe, what would you think about putting Refresh in at the start of Watch on Unit and Service? | 07:52 |
| fwereade | rogpeppe, that way the initial event actually is the current state, rather than potentially being whatever aged rubbish you started to watch? | 07:53 |
| rogpeppe | fwereade: what are the events that those watchers produce? | 07:53 |
| fwereade | rogpeppe, something-changed | 07:54 |
| fwereade | rogpeppe, send fresh units back | 07:54 |
| rogpeppe | fwereade: so won't the initial event be a fresh unit? | 07:54 |
| rogpeppe | fwereade: and hence have all the currently correct settings? | 07:54 |
| fwereade | rogpeppe, AFAICT it'll correspond to *some* transaction more recent than the revno of the old document | 07:54 |
| fwereade | rogpeppe, hey wait that makes no sense | 07:55 |
| rogpeppe | fwereade: hmm, that seems wrong | 07:55 |
| fwereade | rogpeppe, ok, time seemed to be flowing in reverse, and a Refresh fixed it, but clearlymore thought is required | 07:55 |
| rogpeppe | fwereade: the initial event should be the most recent revno | 07:55 |
| fwereade | rogpeppe, ah, no, the initial event is just the unit yu originally watched | 07:56 |
| rogpeppe | fwereade: that seems wrong to me | 07:56 |
| fwereade | rogpeppe, yeah, agreed | 07:56 |
| rogpeppe | fwereade: then there's no point in having the initial event | 07:56 |
| fwereade | rogpeppe, well, yeah; we could either Refresh it or reconstruct a new one and send that back | 07:57 |
| rogpeppe | fwereade: i'd incline towards the latter | 07:57 |
| rogpeppe | fwereade: we don't do any implict Refresh anywhere else | 07:57 |
| rogpeppe | TheMue: yo! | 07:58 |
| fwereade | rogpeppe, ok, sgtm | 07:58 |
| rogpeppe | fwereade: and every other event on the channel is a fresh object | 07:58 |
| fwereade | TheMue, heyhey | 07:58 |
| fwereade | rogpeppe, yeah, feels neat | 07:58 |
| TheMue | morniing rogpeppe and fwereade | 07:58 |
| fwereade | rogpeppe, TheMue: should be trivial: https://codereview.appspot.com/6571047 | 08:32 |
| rogpeppe | fwereade: LGTM | 08:35 |
| fwereade | rogpeppe, cheers; trivial enough to submit directly, do you think? | 08:36 |
| rogpeppe | fwereade: i *think* so, but it is a significant change in one sense. | 08:37 |
| rogpeppe | fwereade: even though the code is trivial | 08:37 |
| fwereade | rogpeppe, in the sense that it causes the uniter to work properly, it is significant ;p | 08:38 |
| fwereade | rogpeppe, and I think it is unambiguously (1) correct, because watches should send current state and then deltas; and (2) safer, because we don't ever send the originating entity over to some unknown client over a channel | 08:39 |
| rogpeppe | fwereade: it's that last thing that i think is the killer argument | 08:39 |
| fwereade | rogpeppe, indeed, it is only secondary in my mind because it wasn't the thing that bit me | 08:39 |
| rogpeppe | fwereade: i'd say go for it | 08:40 |
| * fwereade cheers | 08:40 | |
| Aram | moin. | 09:41 |
| davecheney | hello and goodbye | 09:42 |
| davecheney | time to make the dinner | 09:42 |
| davecheney | then i'll see ya'll for the hangout | 09:42 |
| fwereade | ok launchpad.net/juju-core/worker/uniter117.284s | 09:46 |
| fwereade | ok launchpad.net/juju-core/worker/uniter/charm7.835s | 09:46 |
| fwereade | ok launchpad.net/juju-core/worker/uniter/hook0.007s | 09:46 |
| fwereade | ok launchpad.net/juju-core/worker/uniter/relation8.826s | 09:46 |
| davecheney | fwereade: did you see my comment to the list about i/o usage | 09:46 |
| davecheney | that might explain your excessive test times | 09:46 |
| fwereade | davecheney, I did, makes a lot of sense | 09:46 |
| fwereade | davecheney, thanks | 09:46 |
| davecheney | fwereade: maybe aram can help | 09:46 |
| davecheney | i had a look today, but I wasn't much chop for anything | 09:46 |
| davecheney | invoking mgo the way the tests do, doesn't make it create that big _tmp | 09:47 |
| davecheney | flie | 09:47 |
| davecheney | but then again, I never connected a client to the manually invoked one | 09:47 |
| Aram | 20MB | 09:47 |
| Aram | make it smaller | 09:47 |
| Aram | 1MB | 09:47 |
| davecheney | on my machine _tmp was 256mb | 09:47 |
| Aram | hmm? | 09:47 |
| Aram | perhaps testing/mgo had leaked? | 09:47 |
| Aram | or was this only from one test? | 09:48 |
| Aram | aaah | 09:48 |
| Aram | I know | 09:48 |
| Aram | niemeyer made the capped collection 20MB | 09:48 |
| Aram | 200 | 09:48 |
| davecheney | aram what is _tmp ? | 09:48 |
| Aram | and it needs contiguous space for that | 09:48 |
| davecheney | (see email) | 09:48 |
| fwereade | Aram, aaaahhh, and it's only made little in *some* tests | 09:48 |
| Aram | ok, let me read the email | 09:48 |
| fwereade | Aram, right? | 09:48 |
| davecheney | fwereade: only made little in cloudinit -> deploy to ec2 | 09:49 |
| davecheney | oh, that explains why my had started version didn't use any disk space | 09:50 |
| davecheney | it won't do that until someone connects to it and does ensure index ... | 09:50 |
| fwereade | davecheney, StartMgoServer specifies everything that addMongoToBoot does, doesn't it? | 09:53 |
| Aram | fwereade: make the capped collection 1MB and see if tests take less. | 09:54 |
| Aram | in open.go | 09:54 |
| Aram | wtf is wrong with launchpad today, so slow. | 09:55 |
| Aram | actually, my internet is slow. | 09:56 |
| * Aram reboots router | 09:56 | |
| TheMue | lunchtime, see you in the hangout | 10:15 |
| TheMue | hmm, my build complains about an undefined bson.SetZero. i already update mgo. or is it a different problem? | 10:59 |
| Aram | bzr pull | 10:59 |
| Aram | go get -u is not enough | 10:59 |
| TheMue | Aram: thx, will try | 11:00 |
| TheMue | Aram: it pulled nothing, but i'm still using 1.0.2. may this be the problem? | 11:01 |
| Aram | no | 11:01 |
| Aram | you pulled mgo, right? | 11:01 |
| TheMue | yes | 11:02 |
| Aram | what does bzr log --line -r -1 say? | 11:02 |
| davecheney | so, how about that meeting ... | 11:03 |
| TheMue | funny, 172 with the added SetZero | 11:04 |
| davecheney | TheMue: maybe a fast path is to | 11:04 |
| davecheney | rm -rf .../v2/mgo | 11:04 |
| davecheney | go get ... | 11:04 |
| davecheney | the cd v2/mgo | 11:04 |
| davecheney | bzr pull | 11:05 |
| davecheney | that is what I did | 11:05 |
| davecheney | i'm pretty sure it will work | 11:05 |
| TheMue | will try that too | 11:05 |
| davecheney | please double check you don't have another mgo snuck away somewhere else | 11:05 |
| Aram | davecheney: but it's always funny to find new bzr misfeatures and broken behaviors to complain about them. | 11:05 |
| * davecheney smiles at Aram | 11:06 | |
| davecheney | its like bzr has set the revision to a revision in a branch | 11:06 |
| fwereade | hm, should we be meeting now? | 11:07 |
| davecheney | indeed | 11:08 |
| davecheney | we should | 11:08 |
| Aram | we should have a meeting about the lack of the meeting. | 11:12 |
| davecheney | Aram: please propose an agenda first | 11:13 |
| Aram | a user story. | 11:13 |
| Aram | which we have to send to a program manager. | 11:13 |
| TheMue | shall i sent out the invite? | 11:13 |
| * davecheney is texting mrarmm | 11:14 | |
| fwereade | TheMue, please do | 11:15 |
| TheMue | done | 11:16 |
| mramm | sorry I was late to the meeting | 11:17 |
| davecheney | s'ok | 11:17 |
| davecheney | lets get going | 11:17 |
| mramm | I'm in the meeting, called by frank | 11:20 |
| davecheney | err, nobody else is | 11:20 |
| Aram | we are | 11:21 |
| Aram | :) | 11:21 |
| Aram | davecheney: https://plus.google.com/hangouts/_/74ad471b07ee1c4e3215133bbf54c62e79ff5c7b?authuser=1&hl=en | 11:21 |
| davecheney | ta | 11:21 |
| Aram | rogpeppe: ^ ^ | 11:23 |
| rogpeppe | oops, didn't see it | 11:24 |
| rogpeppe | will be there in a moment | 11:24 |
| mramm | 16:06 niemeyer: Woah | 11:29 |
| mramm | 16:06 niemeyer: services: | 11:29 |
| mramm | 16:06 niemeyer: builddb: | 11:29 |
| mramm | 16:06 niemeyer: charm: builddb | 11:29 |
| mramm | 16:06 niemeyer: exposed: false | 11:29 |
| mramm | 16:06 niemeyer: units: | 11:29 |
| mramm | 16:06 niemeyer: builddb/0: | 11:29 |
| mramm | 16:06 niemeyer: agent-version: 0.0.0 | 11:29 |
| mramm | 16:06 niemeyer: machine: 1 | 11:29 |
| mramm | 16:06 niemeyer: public-address: ec2-204-236-223-223.compute-1.amazonaws.com | 11:29 |
| mramm | 16:06 niemeyer: status: started | 11:29 |
| fwereade | davecheney, sorry, did you paste it somewhere I missed? | 11:33 |
| davecheney | sorry, email | 11:33 |
| davecheney | irc is on another machine, sorry | 11:33 |
| fwereade | davecheney, np, ty | 11:35 |
| fwereade | lunch bbl | 11:59 |
| niemeyer | Morning juju masters! | 12:48 |
| davecheney | niemeyer: hello | 13:06 |
| niemeyer | davecheney: Heya! | 13:06 |
| davecheney | sleep it would seem, eludes me | 13:06 |
| TheMue | niemeyer: hi | 13:10 |
| niemeyer | davecheney: Wow, yeah, you've been here for a while :) | 13:14 |
| niemeyer | TheMue: Yo | 13:14 |
| fwereade | niemeyer, heyhey | 13:30 |
| niemeyer | fwereade: Heya | 13:30 |
| niemeyer | fwereade: Just reviewing the relation units stuff | 13:30 |
| niemeyer | fwereade: Superb so far | 13:30 |
| fwereade | niemeyer, for some reason I made the make-uniter-work branch depend on that one | 13:31 |
| fwereade | niemeyer, jolly good, hopefully I won't need to reparent the followup ;) | 13:31 |
| fwereade | niemeyer, I submitted one trivial this morning btw that was necessary | 13:31 |
| niemeyer | fwereade: No, certainly not.. I think there were a few opportunities to have split the branches, as you noted yourself in the description, but it's alright.. happy to have it in whatever form. | 13:32 |
| fwereade | niemeyer, cheers | 13:33 |
| niemeyer | fwereade: Super, thanks re. trivial | 13:33 |
| fwereade | niemeyer, now I come to think of it, the timeout bumps in the followup are surely only necessary because I wasn't using a tmpfs | 13:34 |
| fwereade | niemeyer, I will adjust them down as seems fit | 13:34 |
| niemeyer | fwereade: Hmm | 13:35 |
| niemeyer | fwereade: The timeouts on the sad cases may be high | 13:35 |
| fwereade | niemeyer, I was thinking "conservatively", at first, anyway -- just to what they were originally | 13:35 |
| niemeyer | fwereade: Those prevent spurious breaks when the machine happens to get some load or when tests are running on a slow machine | 13:35 |
| niemeyer | fwereade: I haven't seen the branch | 13:36 |
| niemeyer | fwereade: What were they? | 13:36 |
| fwereade | niemeyer, 5s to 10s is the notable one, in a couple of places | 13:36 |
| fwereade | niemeyer, and I really don't think it deserves that long | 13:36 |
| niemeyer | fwereade: wow | 13:36 |
| niemeyer | fwereade: Yeah, that's a lot | 13:36 |
| niemeyer | fwereade: How come we're getting such long timeouts? Are we missing a resync? | 13:37 |
| fwereade | niemeyer, that was pessimistic, in practive it only missed the 5s mark by a few milliseconds even under load | 13:37 |
| fwereade | niemeyer, but I was in no mood to mess around ;) | 13:37 |
| fwereade | niemeyer, almost certainly it is because the mongo tests stress the hell out of my machine unless I have a tmpfs | 13:37 |
| niemeyer | fwereade: Hmm | 13:37 |
| niemeyer | fwereade: I wonder why | 13:38 |
| niemeyer | Well, I do have an SSD | 13:38 |
| fwereade | niemeyer, I think Aram and davecheney have a better developed understanding of it -- the stuff I've been working on has not generally been affected enough to get really worked up about when you're running a few tests at a time | 13:38 |
| fwereade | niemeyer, that said, it feels *much* nicer now than it ever did before, not sure is this is psychosomatic | 13:39 |
| fwereade | niemeyer, is anyone working on jujud btw? | 13:39 |
| niemeyer | fwereade: not that I know of | 13:39 |
| niemeyer | fwereade: I was about to ask what else has broken tests atm | 13:40 |
| fwereade | niemeyer, that seems to be the one remaining eyesore in the test output | 13:40 |
| niemeyer | fwereade: Anything obvious there? | 13:40 |
| fwereade | niemeyer, barely looked tbh | 13:40 |
| fwereade | niemeyer, focus has been elsewhere | 13:40 |
| fwereade | niemeyer, schema error in bootstrap_test is the first | 13:41 |
| fwereade | niemeyer, the remaining failures can probably be mostly attributed to collateral damage | 13:41 |
| niemeyer | fwereade: That rings a bell somehow | 13:42 |
| niemeyer | fwereade: Review sent | 13:57 |
| fwereade | niemeyer, cheers | 13:57 |
| niemeyer | Aram: ping | 14:00 |
| Aram | pong | 14:00 |
| niemeyer | Aram: Heya | 14:01 |
| niemeyer | Aram: How're things going there? | 14:01 |
| fwereade | niemeyer, the resyncing is to pick up Alive changes, without which Unit.Status will report "down" regardless of content | 14:02 |
| Aram | niemeyer: yesterday I've taken a swap day and today I'm working on the missing watchers and lifecycle in watchers. but a little bit later, ATM I'm running some rrands. | 14:02 |
| Aram | errand | 14:02 |
| Aram | s | 14:02 |
| niemeyer | fwereade: Sorry, I'm still slow today.. can you cover it a bit more piecemeal? | 14:03 |
| niemeyer | Aram: Okay, let's please talk once you're back | 14:03 |
| fwereade | niemeyer, ah, sorry, ok: I'm actually on crack, that's a different piece of code | 14:04 |
| fwereade | niemeyer, no reason for the resyncing you correctly complain about | 14:04 |
| niemeyer | fwereade: Is it just a matter of refreshing the unit itself? | 14:04 |
| fwereade | niemeyer, yeah, that is the sane and easy way | 14:04 |
| niemeyer | fwereade: Super.. I'm really just trying to understand these new patterns and see where/whether they fall short | 14:05 |
| fwereade | niemeyer, that was almost certainly an unremoved attempt at working around the weirdness in the entity watchers | 14:05 |
| rogpeppe | niemeyer, fwereade: just checking, do you think the provisioner is currently working in trunk? | 14:11 |
| fwereade | rogpeppe, STM to be, just deployed a unit | 14:11 |
| fwereade | rogpeppe, not from trunk, but I haven't touched the provisioner | 14:12 |
| rogpeppe | fwereade: hmm, my live tests aren't working | 14:12 |
| niemeyer | rogpeppe: It was yesterday | 14:12 |
| rogpeppe | niemeyer: the live test? | 14:12 |
| niemeyer | rogpeppe: The provisioner | 14:12 |
| rogpeppe | niemeyer: the provisioner test suite runs fine for me locally - just not live | 14:14 |
| niemeyer | rogpeppe: I've used the provisioner live yesterday | 14:14 |
| niemeyer | rogpeppe: Multiple times | 14:15 |
| rogpeppe | niemeyer: i've probably broken the live tests somehow then | 14:15 |
| niemeyer | rogpeppe: Or they are just not working after the state migration | 14:15 |
| rogpeppe | niemeyer: entirely possible. but it's not relying on watchers, so i *thought* it should work ok | 14:16 |
| rogpeppe | niemeyer: did juju status report you the correct agent version for the bootstrap machine? | 14:19 |
| niemeyer | rogpeppe: Yep | 14:20 |
| niemeyer | rogpeppe: I have a paste somewhere, hold on | 14:21 |
| niemeyer | rogpeppe: Sorry, can't find it | 14:23 |
| niemeyer | rogpeppe: I can easily fire a new env, though | 14:23 |
| rogpeppe | niemeyer: i think i saw it actually | 14:23 |
| rogpeppe | niemeyer: i'm trying again, but not in the test this time | 14:23 |
| niemeyer | fwereade: I think we'd benefit from adding back service.CharmURL, btw | 14:27 |
| niemeyer | fwereade: We can probably just revert it from somewhere in history | 14:27 |
| fwereade | niemeyer, I can only think of one place it's be a real boon... quite often we want the charm itself as well | 14:28 |
| niemeyer | fwereade: In hindsight, it was the SetCharmURL bit that was ill-conceived.. CharmURL is fine | 14:28 |
| fwereade | niemeyer, but yeah no actual objections | 14:28 |
| niemeyer | fwereade: Yeah, but often we grab the charm and throw it away.. we might grab the charm only if | 14:28 |
| fwereade | niemeyer, fair enough | 14:29 |
| niemeyer | fwereade: Not an issue by any means.. just sharing brain state :) | 14:29 |
| fwereade | niemeyer, ok, re MachineUnitsWatcher: what is the mechanism by which it guarantees it does not send events with the same unit both Added and Removed? | 14:36 |
| niemeyer | fwereade: I think there isn't any right now.. | 14:37 |
| niemeyer | fwereade: I've pondered about the same thing in the context of the MachinesWatcher | 14:38 |
| fwereade | niemeyer, I guess that was true both before and after the loop change | 14:38 |
| niemeyer | fwereade: Right | 14:38 |
| niemeyer | fwereade: I've actually made a comment regarding this in the CL | 14:38 |
| niemeyer | fwereade: Dave suggested it wasn't an issue, but I'm not yet sure | 14:38 |
| niemeyer | fwereade: I'm tempted to drop them too | 14:39 |
| fwereade | niemeyer, it feels to me like it is | 14:39 |
| niemeyer | fwereade: If nothing else, we must handle the situation where it doesn't show up correctly | 14:39 |
| niemeyer | fwereade: Because it is just a perspective of timing | 14:39 |
| niemeyer | fwereade: If we made the same query moments afterwards, we'd see nothing | 14:39 |
| fwereade | niemeyer, yeah, indeed | 14:40 |
| fwereade | niemeyer, I guess it's best to use that style though, and fix the watchers so that mergeChanges always does the Right Thing | 14:40 |
| niemeyer | fwereade: +1 | 14:41 |
| fwereade | niemeyer, the advantage of the double-loop style in RUW is that I think it *did* allow me to make useful guarantees of that nature | 14:41 |
| fwereade | niemeyer, anyway, shouldn't be too tricky :) | 14:41 |
| niemeyer | fwereade: I've been doing a few changes, btw: renaming mergeChanges to merge; getInitialEvent to initial, and pass the change itself onto initial; plus the w.out change I've mentioned | 14:41 |
| niemeyer | fwereade: Hmm | 14:42 |
| fwereade | niemeyer, those all sgtm | 14:42 |
| niemeyer | fwereade: I don't think so | 14:42 |
| niemeyer | fwereade: I mean, I don't think there were any guarantees before either | 14:42 |
| niemeyer | fwereade: Because events were aggregated regardless | 14:42 |
| fwereade | niemeyer, I *think* that because the loops in which I send and the loops in which I get scope changes are different, it all Just Works | 14:43 |
| fwereade | niemeyer, I don;t pick up a new scope event until I've sent the change derived from the first one | 14:43 |
| niemeyer | fwereade: I don't see why it makes a difference.. the code that may be executed or not is exactly the same, with the new convention or with the old one | 14:43 |
| fwereade | niemeyer, that change may have had any number of settings changes merged in but those are safe | 14:43 |
| niemeyer | fwereade: The second loop is exactly a copy with the first one with the send disabled | 14:43 |
| fwereade | niemeyer, not in RUW | 14:43 |
| niemeyer | fwereade: Which is exactly what we do in the new convention, but with less code | 14:44 |
| niemeyer | fwereade: Oh? | 14:44 |
| niemeyer | fwereade: /me looks again | 14:44 |
| fwereade | niemeyer, although it is just one more var to track really | 14:44 |
| niemeyer | fwereade: I see.. I think it's actually preferable to teach merge about how to handle the situation | 14:47 |
| niemeyer | fwereade: Otherwise it's unnecessarily buffering changes arbitrarily | 14:47 |
| fwereade | niemeyer, yeah, sounds sane | 14:47 |
| rogpeppe | niemeyer: ah, i think i *may* have discovered the reason why live tests are failing | 14:48 |
| niemeyer | rogpeppe: Sweet! | 14:48 |
| rogpeppe | niemeyer: just a hunch as yet | 14:48 |
| rogpeppe | niemeyer: but... | 14:49 |
| rogpeppe | niemeyer: what's the name of the public bucket containing the mongo binaries? | 14:49 |
| niemeyer | rogpeppe: juju-dist.. why does it matter? | 14:49 |
| rogpeppe | niemeyer: is it hard-coded? | 14:50 |
| niemeyer | rogpeppe: yes | 14:50 |
| rogpeppe | drat | 14:50 |
| niemeyer | rogpeppe: As of today | 14:50 |
| niemeyer | rogpeppe: It shouldn't be, but this avoids yet another refactoring without all tests green | 14:50 |
| rogpeppe | niemeyer: that's fine. hrmph. | 14:50 |
| niemeyer | fwereade: Follow up reviewed too | 14:52 |
| TheMue | niemeyer: test of removals in firewaller always showed an effect. the fw dislikes the service removal when it is stopped. stopping the service watcher returns an error then. | 14:52 |
| fwereade | niemeyer, ta | 14:52 |
| niemeyer | TheMue: More details please? | 14:53 |
| niemeyer | TheMue: If the firewaller is stopped, how can it dislike anything? | 14:54 |
| fwereade | niemeyer, ok, so *that* was the bit with a weird StartSync that I think is justified | 14:54 |
| niemeyer | fwereade: Yeah, I imagined it when reading | 14:54 |
| fwereade | niemeyer, Unit.Status does an alive check on the UA | 14:54 |
| niemeyer | fwereade: I'm just curious about how it unrolls into it | 14:54 |
| niemeyer | fwereade: Aha, ok.. is that all? | 14:54 |
| fwereade | niemeyer, Status returns "down" when the pinger is not there | 14:55 |
| fwereade | niemeyer, yeah, that's it | 14:55 |
| niemeyer | fwereade: So a suggestion: let's move the sync down to right before Status, and call Sync rather than StartSync | 14:55 |
| fwereade | niemeyer, ah, yeah, sounds sensible | 14:55 |
| fwereade | niemeyer, cheers | 14:55 |
| niemeyer | fwereade: Thanks! | 14:56 |
| niemeyer | TheMue? | 14:56 |
| TheMue | niemeyer: sorry, my wife called me ;) | 15:02 |
| TheMue | niemeyer: fw.Stop() is expected to return no error | 15:02 |
| TheMue | niemeyer: but if a service is removed it returns a service not found | 15:02 |
| TheMue | niemeyer: because during the stop all internal go routines are stopped, and there the service watchers | 15:03 |
| TheMue | niemeyer: and this stopping does state.Service(name) for the non-existing service | 15:03 |
| niemeyer | TheMue: This is a bug that should be fixed | 15:03 |
| TheMue | niemeyer: indeed | 15:04 |
| TheMue | niemeyer: so you had the right feeling about testing it | 15:04 |
| niemeyer | TheMue: Would you mind to review all fw call sites that grab objects, and consider the appropriate action when the respective entity isn't found? | 15:05 |
| niemeyer | TheMue: Happy to have that done in tiny branches that follow each other so that we have a good way to coordinate as we go | 15:06 |
| TheMue | niemeyer: could you please rephase "fw call sites"? thx. | 15:06 |
| niemeyer | TheMue: call site == a point in the code that calls something | 15:06 |
| TheMue | niemeyer: ah, yes. ok, will do. | 15:07 |
| niemeyer | TheMue: Once you have that first issue fixed, please push for review so we can talk a bit about it with more concrete logic | 15:07 |
| TheMue | niemeyer: ok | 15:08 |
| rogpeppe | niemeyer: hmm, live tests fail even though bootstrapping and deploying live work ok. looks like the provisioner never sees the new machine. | 15:26 |
| niemeyer | rogpeppe: How can the provisioner never see the new machine if it is the one firing off new machines | 15:27 |
| rogpeppe | niemeyer: it's not the one that creates the new Machine though | 15:28 |
| niemeyer | rogpeppe: Exactly.. and if it didn't see that machine, it wouldn't fire an instance fo rit | 15:28 |
| niemeyer | rogpeppe: Also, tests pass | 15:29 |
| rogpeppe | niemeyer: the live deploy tests are currently disabled | 15:29 |
| niemeyer | rogpeppe: Provisioner tests pass | 15:29 |
| rogpeppe | niemeyer: sure. i'm just saying what i see. | 15:30 |
| niemeyer | rogpeppe: Of course, and I'm just explaining that "provisioner never sees the new machine" can't be true on its own | 15:30 |
| niemeyer | rogpeppe: The builddb charm works | 15:30 |
| niemeyer | rogpeppe: Firing new machine | 15:30 |
| niemeyer | rogpeppe: With machiner, uniter, etc | 15:30 |
| rogpeppe | niemeyer: absolutely. i see that working too. | 15:30 |
| niemeyer | rogpeppe: That doesn't happen with a provisioner that never sees a new machine | 15:30 |
| rogpeppe | niemeyer: but my live test that used to work no longer works. so *something* is up. | 15:31 |
| rogpeppe | niemeyer: it might be the fact that the second machine is added before the provisioner comes up | 15:31 |
| niemeyer | rogpeppe: I'm sure.. | 15:31 |
| niemeyer | rogpeppe: Again, tests pass.. | 15:32 |
| niemeyer | rogpeppe: You seem to argue that the provisioner is completely broken.. I doubt it's as simple as that | 15:32 |
| rogpeppe | niemeyer: i'm not arguing that at all | 15:32 |
| rogpeppe | niemeyer: i'm saying that live tests fail that used to pass, that's all | 15:32 |
| rogpeppe | niemeyer: and i don't see the provisioner see the new machine, which seems to be a symptom | 15:33 |
| niemeyer | rogpeppe: Sorry, okay.. I don't know how to help then | 15:33 |
| rogpeppe | niemeyer: i'm not asking for help, just giving a status update | 15:33 |
| niemeyer | rogpeppe: That live tests are broken, ok :) | 15:33 |
| rogpeppe | niemeyer: yeah, it's weird | 15:34 |
| niemeyer | fwereade, rogpeppe: Regarding https://codereview.appspot.com/6571047, I really want to stop sending entities down the pipe at all | 15:35 |
| niemeyer | Everything is a lot simpler and more correct if we just sent the entity identification | 15:36 |
| rogpeppe | niemeyer: just send a change notification? | 15:36 |
| niemeyer | rogpeppe: Yeah, with the id/name | 15:36 |
| rogpeppe | niemeyer: i tend to agree. | 15:36 |
| niemeyer | The machines watcher was significantly simpler and more obvious to handle correctly on the other side with it | 15:36 |
| niemeyer | That said, I've been resisting suggesting this for now, just so we can get it all working as it used to | 15:37 |
| niemeyer | After we're comfortable again, I think we should change | 15:37 |
| fwereade | niemeyer, no strong feelings myself | 15:37 |
| niemeyer | This also avoids the spurious reads we have nowadays within the watcher itself | 15:38 |
| niemeyer | when the entity changes repeatedly without being consumed | 15:38 |
| niemeyer | and it also simplifies the Dead-handling logic.. | 15:38 |
| niemeyer | Anyway, lunch time here | 15:38 |
| niemeyer | rogpeppe: If you're still struggling by the time I'm back, let's try to pair on it | 15:39 |
| rogpeppe | niemeyer: i think i might be getting somewhere now. just expressing the problem was helpful. | 15:39 |
| rogpeppe | niemeyer: aaargh! | 15:39 |
| rogpeppe | niemeyer: found it | 15:39 |
| rogpeppe | so frickin simple | 15:41 |
| platypusfriend | Greets | 16:02 |
| platypusfriend | I'd like to suggest that, on the https://juju.ubuntu.com/ page, under the "Try it for yourself" heading, the instructions to install Juju from the PPA don't work out of the box with Ubuntu 12.04.1 | 16:03 |
| platypusfriend | gregkrsak@brewmaster:~$ add-apt-repository ppa:juju/pkgs | 16:04 |
| platypusfriend | The program 'add-apt-repository' is currently not installed. You can install it by typing: sudo apt-get install python-software-properties | 16:04 |
| platypusfriend | (thanks!) | 16:04 |
| niemeyer | platypusfriend: kthxbye | 16:18 |
| niemeyer | rogpeppe: What was it? | 16:19 |
| rogpeppe | niemeyer: well, one problem was that i was assuming that the machine received from the machine watcher had no information content, so was reading agent tools from the original. | 16:19 |
| rogpeppe | niemeyer: but... that doesn't appear to have fixed the problem. we will see. | 16:20 |
| rogpeppe | niemeyer: am currently running a live test again | 16:20 |
| rogpeppe | niemeyer: hmm, looks like the machine watcher might not be sending an initial event. | 16:24 |
| niemeyer | rogpeppe: Indeed, I don't think it is | 16:25 |
| rogpeppe | niemeyer: i thought we tested for that | 16:25 |
| niemeyer | rogpeppe: I can fix that.. what else is using it? | 16:27 |
| niemeyer | Hmm | 16:28 |
| * rogpeppe checks | 16:28 | |
| niemeyer | Apparently only used in tests | 16:28 |
| niemeyer | In two places only, one of them being the live tests | 16:28 |
| rogpeppe | niemeyer: that sounds about right | 16:28 |
| niemeyer | rogpeppe: I'm on it.. will take the chance to simplify the watcher according to the latest conventions | 16:29 |
| rogpeppe | niemeyer: sounds good | 16:29 |
| niemeyer | rogpeppe: Hah, curious | 16:30 |
| niemeyer | rogpeppe: If we send just the id, the initial event becomes a bit silly | 16:30 |
| rogpeppe | niemeyer: i'm not sure | 16:31 |
| rogpeppe | niemeyer: it's actually still useful, even though it carries no info content | 16:31 |
| rogpeppe | niemeyer: because it for a very simple pattern inside various watcher clients | 16:32 |
| rogpeppe | s/it/it makes/ | 16:32 |
| niemeyer | rogpeppe: Cool, I'm not suggesting we change the convention right now either way, since we're in the middle of a huge transition | 16:32 |
| rogpeppe | niemeyer: +1 | 16:32 |
| niemeyer | rogpeppe: Let's just observe the changed sites and see how they look once we do this | 16:32 |
| rogpeppe | niemeyer: sounds good | 16:32 |
| rogpeppe | niemeyer: my observation was that in quite a few places, the initial event is not acted upon any differently from a changed event, so it makes sense to handle them both in the same branch of the select statement. | 16:33 |
| niemeyer | rogpeppe: If that's generally the case for the entity watchers, +1 | 16:34 |
| rogpeppe | niemeyer: so it's nice to guarantee that we get at least one event | 16:34 |
| niemeyer | rogpeppe: It perhaps also conveys useful information, although I'm not entirely sure: | 16:34 |
| niemeyer | rogpeppe: When we get the watch fired, we know we're subscribed | 16:34 |
| rogpeppe | niemeyer: interesting. i wonder if that's ever actually useful to know. | 16:35 |
| niemeyer | rogpeppe: Ah, no, sorry, it doesn't matter | 16:35 |
| niemeyer | rogpeppe: We provide the machine revno when watching, so there are no holes | 16:35 |
| rogpeppe | niemeyer: ah, so in that case the initial event *does* carry useful info | 16:36 |
| niemeyer | rogpeppe: ? | 16:36 |
| rogpeppe | niemeyer: oh, sorry, other way around | 16:36 |
| niemeyer | Yeah | 16:36 |
| rogpeppe | niemeyer: i thought you were suggesting the events would contain the revno as well as the id | 16:36 |
| rogpeppe | niemeyer: which may be a good idea, i suppose | 16:36 |
| niemeyer | rogpeppe: Nope.. not suggesting that yet, at least | 16:37 |
| rogpeppe | niemeyer: it kinda makes sense - you give a revno to watch from, then you're handed revnos as it changes. | 16:37 |
| niemeyer | rogpeppe: I'm slightly concerned that we might see code ignoring the initial watch thinking "Oh, but when the initial event arrives, the machine/unit/service hasn't yet changed" | 16:38 |
| niemeyer | rogpeppe: Which is not necessarily true.. let's watch out for that | 16:38 |
| rogpeppe | niemeyer: yeah | 16:38 |
| niemeyer | rogpeppe: The concept of revno is internal pretty much everywhere | 16:38 |
| niemeyer | rogpeppe: I'm not keen on exposing it, if possible | 16:38 |
| rogpeppe | niemeyer: fair enough. | 16:39 |
| rogpeppe | niemeyer: though doesn't the uniter make use of revnos? | 16:39 |
| niemeyer | rogpeppe: That where the "pretty much" comes from. The only exception is the settings version, because we have to persist them to disk. | 16:39 |
| rogpeppe | niemeyer: here's an idea for how an updated watcher API might work: | 16:43 |
| rogpeppe | http://paste.ubuntu.com/1226959/ | 16:43 |
| rogpeppe | niemeyer: i.e. each entity watcher embeds the entity that it's watching | 16:43 |
| rogpeppe | niemeyer: oops, with one crucial addition: http://paste.ubuntu.com/1226963/ | 16:44 |
| niemeyer | rogpeppe: I don't understand what this is solving | 16:45 |
| rogpeppe | niemeyer: it's solving, for me at any rate, the fact that i want to watch the same kind of thing on two different kinds of entity | 16:45 |
| rogpeppe | niemeyer: perhaps that's not a problem anywhere else though, i guess | 16:46 |
| rogpeppe | niemeyer: it seems kinda logical to tie the watcher together with the thing it's watching. | 16:46 |
| niemeyer | rogpeppe: What is the MachineUnitsWatcher going to be tied with? | 16:47 |
| rogpeppe | niemeyer: is MachineUnitsWatcher an entity watcher? | 16:47 |
| rogpeppe | niemeyer: i'm only thinking of this for things where currently we just send an instance of the object down the channel | 16:48 |
| niemeyer | rogpeppe: Sorry, seems like a big red-herring | 16:48 |
| rogpeppe | niemeyer: ok fair enough | 16:48 |
| rogpeppe | niemeyer: i wondered if UnitWatcher and MachineWatcher could actually be implemented by the same type, and that led me to think in this direction | 16:48 |
| rogpeppe | niemeyer: looking at TestWatchMachine, it looks as if it *does* test for an initial event | 16:51 |
| niemeyer | rogpeppe: Please leave that with me.. I'll send a branch in a moment | 16:52 |
| rogpeppe | niemeyer: ok | 16:52 |
| rogpeppe | niemeyer: i'm off now. might be able to have a look back in a bit, otherwise see ya tomorrow! | 17:08 |
| niemeyer | rogpeppe: have a good time there | 17:13 |
| niemeyer | rogpeppe: Do live tests work, btw? | 17:19 |
| rogpeppe | niemeyer: no, i'm waiting for your machine watcher CL | 17:25 |
| niemeyer | rogpeppe: Well.. this will just add an extra event | 17:25 |
| rogpeppe | niemeyer: i *think* that's what's stopping them passing | 17:25 |
| rogpeppe | niemeyer: that will be good enough | 17:25 |
| rogpeppe | niemeyer: currently it blocks waiting for that event and never gets it | 17:26 |
| niemeyer | rogpeppe: It's a spurious event.. should be trivial to just not wait for it | 17:26 |
| niemeyer | Either way, too late.. the watcher is ready and you're off.. I'll have a look at it later | 17:27 |
| rogpeppe | niemeyer: i've actually got another hour or so now | 17:27 |
| niemeyer | rogpeppe: Oh, okay, let me push the watcher then | 17:27 |
| niemeyer | rogpeppe: I don't think it's the initial event here, btw | 17:31 |
| niemeyer | rogpeppe: Have you changed the test so it calls Refresh? | 17:31 |
| rogpeppe | niemeyer: ok. i changed the test so it used the Machine that it receives on the channel | 17:32 |
| niemeyer | rogpeppe: That won't work.. the channel contains an id now.. | 17:32 |
| niemeyer | rogpeppe: Just Refresh the machine | 17:32 |
| rogpeppe | niemeyer: ok, i'll change as needed when i merge | 17:32 |
| niemeyer | rogpeppe: Ok, I won't touch it | 17:32 |
| rogpeppe | niemeyer: sounds good | 17:33 |
| niemeyer | rogpeppe: You'll see why the original tests were working, btw | 17:33 |
| rogpeppe | niemeyer: cool | 17:33 |
| niemeyer | Committing & proposing | 17:33 |
| rogpeppe | niemeyer: i'm interested - they looked plausible! | 17:33 |
| niemeyer | rogpeppe: Agreed. Two bugs coalesced for it to work. | 17:34 |
| niemeyer | rogpeppe: https://codereview.appspot.com/6564049 | 17:37 |
| rogpeppe | *click* | 17:37 |
| rogpeppe | niemeyer: so the test was ok, then, and the problem was that the txn-revno was out of date, so it sent an event anyway? | 17:44 |
| rogpeppe | niemeyer: i'm not sure i see the other bug you refer to though | 17:44 |
| niemeyer | rogpeppe: Right | 17:44 |
| niemeyer | rogpeppe: Well, the other bug is the fact it didn't send | 17:45 |
| niemeyer | rogpeppe: The two bugs, together, make the test pass | 17:45 |
| rogpeppe | niemeyer: the watcher didn't send? | 17:46 |
| niemeyer | rogpeppe: The initial event.. :-) | 17:46 |
| rogpeppe | niemeyer: ah of course! | 17:46 |
| rogpeppe | niemeyer: it all becomes blindingly obvious | 17:46 |
| rogpeppe | niemeyer: it would be nice if we could have a test that would have failed with the previous bugs. | 17:47 |
| niemeyer | rogpeppe: The current test fails if we fix the revno issue | 17:48 |
| niemeyer | rogpeppe: But it's not easy to test the fact the revno was wrong, precisely because it causes an initial event to be sent, which is the behavior we want | 17:49 |
| rogpeppe | niemeyer: i wondered about getting a machine from a different source than AddMachine | 17:49 |
| niemeyer | rogpeppe: The bug is in AddMachine | 17:49 |
| niemeyer | was | 17:49 |
| rogpeppe | niemeyer: given that there are several Machine constructors that can be bad in different ways | 17:49 |
| rogpeppe | niemeyer: indeed. | 17:49 |
| niemeyer | rogpeppe: Nope.. they are all ok, because they grab the db value | 17:50 |
| rogpeppe | niemeyer: if the original hadn't used AddMachine, we'd have found the bug | 17:50 |
| niemeyer | rogpeppe: AddMachine is special because it uses the memory value | 17:50 |
| rogpeppe | niemeyer: yeah, i'm just saying. maybe there should be a test that AddMachine returns exactly the same values as Machine. but that's hard to do externally. | 17:51 |
| niemeyer | rogpeppe: We could abuse DeepEquals for that.. it's generally a bad idea, but we can have a single trivial spot doing that for the entities, at least so we consciously know when we break that rule. | 17:54 |
| rogpeppe | niemeyer: i wondered about that | 17:58 |
| niemeyer | rogpeppe: I'll add a test | 17:58 |
| rogpeppe | niemeyer: one thought: is it really worth sending the machine id down the channel. we're never going to actually use it AFAICS. why not chan struct{} ? | 18:05 |
| niemeyer | rogpeppe: Happy to take it off while we don't care | 18:09 |
| Aram | niemeyer: what is it that you wanted to talk about? | 18:19 |
| rogpeppe | niemeyer: it would make me happy. then MachineWatcher and UnitWatcher can implement the same interface. | 18:20 |
| niemeyer | Aram: Isn't it quite late for you already? If you're taking the day off, we can talk tomorrow.. | 18:20 |
| niemeyer | rogpeppe: Cool, I'll drop it before merging | 18:21 |
| Aram | niemeyer: it's late but it's fine, if we talk today I can work on it tomorrow in the morning, when you'll not be here. | 18:21 |
| rogpeppe | niemeyer: in fact, both Machine.Watch and Unit.Watch could return the same interface type. then Machine and Unit are directly compatible for watching. | 18:22 |
| rogpeppe | niemeyer: the MachineWatcher type could be unexported. | 18:23 |
| niemeyer | Aram: I don't actually have much to talk about, I think.. I was going to bring up the auth + SSL stuff, but we don't even have the machine units watcher done yet, so that's probably the first thing to work on | 18:23 |
| niemeyer | Aram: I think you've seen as well discussion about the latest conventions | 18:23 |
| Aram | niemeyer: aah, yes. so we continue to do full document watchers or just ids? | 18:24 |
| niemeyer | Aram: Regarding w.out, nil, dropping the two loops, etc | 18:24 |
| Aram | I've seen that | 18:24 |
| Aram | very nice way of dropping the extra loop | 18:24 |
| niemeyer | Aram: Just ids, and with liveness | 18:24 |
| niemeyer | Aram: Similar to how the current MachinesWatcher is working | 18:24 |
| Aram | ok | 18:25 |
| niemeyer | Aram: Dead+Alive rather than added/removed | 18:25 |
| Aram | yeah | 18:25 |
| niemeyer | rogpeppe: Yeah, we can do a lot, but let's hold off a bit.. this is already going quite far | 18:25 |
| rogpeppe | niemeyer: cool. agreed. | 18:26 |
| niemeyer | I'm actually going to split this equivalence stuff in its own branch | 18:26 |
| rogpeppe | niemeyer: that sounds good too | 18:27 |
| niemeyer | I had to do changes for the charm equivalence which is unrelated to the original goal | 18:27 |
| niemeyer | Come on LP | 18:33 |
| niemeyer | rogpeppe: It's in | 18:38 |
| rogpeppe | niemeyer: i saw. thanks! | 18:38 |
| niemeyer | rogpeppe: np, will push the follow up for review onw | 18:39 |
| niemeyer | https://codereview.appspot.com/6566050 | 18:52 |
| niemeyer | rogpeppe: ^ | 18:56 |
| * rogpeppe looks | 18:56 | |
| rogpeppe | niemeyer: LGTM | 18:58 |
| niemeyer | rogpeppe: Thanks! | 18:59 |
| rogpeppe | niemeyer: ok, i've updated the live tests for the new interface. now running them live - we'll see what happens. | 19:15 |
| niemeyer | rogpeppe: Fingers crossed! | 19:15 |
| rogpeppe | niemeyer: i've got a bus to catch in 15 minutes so if this doesn't work, it'll have to be tomorrow | 19:15 |
| * rogpeppe wants a connection with faster upload speed | 19:16 | |
| niemeyer | rogpeppe: +1 | 19:16 |
| Aram | yeah, in Romania I have 100Mbps upload for $9/month. | 19:17 |
| Aram | here in Austria I pay 50€ for only 10Mbps. | 19:17 |
| Aram | that's 71 times more expensive upload. | 19:18 |
| rogpeppe | Aram: here i have no option for faster upload. it's crappy copper and they've no plans to upgrade. | 19:19 |
| Aram | yeah, in Romania I was lucky to have fiber. | 19:19 |
| rogpeppe | still, it only took 3:10 to upload the tools that time | 19:20 |
| Aram | at some point they forgot to set speed limits for me and I have 1Gbps download/upload for months :-). | 19:20 |
| rogpeppe | i should do what dave does and run the live tests on ec2 itself | 19:21 |
| rogpeppe | gotta go, or will miss bus | 19:22 |
| rogpeppe | tests still waiting mongod | 19:23 |
| rogpeppe | niemeyer, Aram: have fun | 19:23 |
| Aram | cheers. | 19:23 |
| niemeyer | I wonder what "tests still waiting mongod" means.. It's pretty much instantaneous for me nowadays | 19:31 |
| === robbiew1 is now known as robbiew | ||
| hazmat | out of curiosity how big are the tools? | 20:01 |
| niemeyer | hazmat: Each binary is about 5M stripped | 20:05 |
| hazmat | niemeyer, and what's the size with symbol? | 20:06 |
| niemeyer | hazmat: 7MB or so | 20:06 |
| hazmat | niemeyer, cool, thanks | 20:06 |
| niemeyer | hazmat: np | 20:06 |
| niemeyer | Stepping out for a while.. back soon | 21:23 |
| fwereade | niemeyer, discussion in https://codereview.appspot.com/6567044/ ; trivial in https://codereview.appspot.com/6570050 ; it would be awesome if you could take a look at the first, in particular, if you're around at any stage | 22:56 |
| niemeyer | fwereade: I'm here | 22:57 |
| niemeyer | fwereade: Looking | 22:57 |
| niemeyer | fwereade: Hmm | 22:57 |
| niemeyer | fwereade: I've already replied to the first a while ago | 22:57 |
| fwereade | niemeyer, ah, sorry, missed that | 22:58 |
| niemeyer | fwereade: np | 22:58 |
| niemeyer | fwereade: LGTM on second | 22:59 |
| fwereade | niemeyer, hmm, ok, I see; LGTM re out = nil | 22:59 |
| niemeyer | fwereade: Super | 22:59 |
| fwereade | niemeyer, LGTM stands with the change then? | 23:00 |
| niemeyer | fwereade: I'll have some food while another round of live tests run | 23:00 |
| niemeyer | fwereade: Yep! | 23:00 |
| fwereade | niemeyer, sweet, the tests will look much nicer once the uniter's in | 23:00 |
| niemeyer | fwereade: Btw, I'd like to bring the id on machine watcher bakc | 23:00 |
| fwereade | niemeyer, sorry, context | 23:01 |
| niemeyer | fwereade: I think it was a mistake to remove it.. the first time I've tried to fix some code, it was using the return :) | 23:01 |
| niemeyer | fwereade: Ah, sorry | 23:01 |
| niemeyer | fwereade: We've dropped the result this afternoon, so it returns struct{} | 23:01 |
| niemeyer | fwereade: It was a candidate change, but it was a mistake.. first code I went to fix in the live tests, it was using the id of the result meaningfully | 23:01 |
| niemeyer | fwereade: I'll send a branch so we can bring it back.. I don't want to hack the tests more at this point | 23:02 |
| fwereade | niemeyer, cool, I should sleep soon but I'll be around for a few mins at least | 23:02 |
| fwereade | niemeyer, I'll just treat those failures as deliberate/expected | 23:04 |
| niemeyer | fwereade: Which failures? | 23:05 |
| fwereade | niemeyer | 23:05 |
| fwereade | cmd/jujud/provisioning_test.go:69: undefined: state | 23:05 |
| fwereade | # launchpad.net/juju-core/environs/jujutest | 23:05 |
| fwereade | environs/jujutest/livetests.go:262: m.AgentTools undefined (type struct {} has no field or method AgentTools) | 23:05 |
| fwereade | # launchpad.net/juju-core/environs/jujutest | 23:05 |
| fwereade | environs/jujutest/livetests.go:262: m.AgentTools undefined (type struct {} has no field or method AgentTools) | 23:05 |
| fwereade | niemeyer, I was assuming that jujud was broken deliberately to prevent ugly panics dirtying up the test log | 23:06 |
| niemeyer | fwereade: Yeah, this is broken and is expected.. I'm working to fix all of this | 23:06 |
| fwereade | niemeyer, cool | 23:06 |
| fwereade | niemeyer, I shall not allow them to trouble me | 23:06 |
| niemeyer | fwereade: https://codereview.appspot.com/6571053 | 23:06 |
| niemeyer | fwereade: Hehe :) | 23:06 |
| fwereade | niemeyer, LGTM | 23:07 |
| niemeyer | fwereade: Cheers | 23:08 |
| niemeyer | fwereade: I have quite a few nice trivials on the pipeline, but I'll try to catch up with Dave after dinner | 23:09 |
| niemeyer | fwereade: Thanks, and have a nice sleep there | 23:09 |
| fwereade | niemeyer, cool, perhaps gently encourage him to fix config-get, because I think that will give us more charms to play with right away | 23:09 |
| niemeyer | fwereade: I think he's on it, but I'll talk to him | 23:10 |
| fwereade | niemeyer, tyvm | 23:10 |
| niemeyer | fwereade: np | 23:10 |
| niemeyer | Dinner time.. biab | 23:10 |
| fwereade | niemeyer, enjoy | 23:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!