[04:49] <jcw4> Is anyone available to review my trivial PR to the names package? https://github.com/juju/names/pull/28
[05:05] <jcw4> Also, http://reviews.vapour.ws/r/158 which will depend on the names package PR too
[13:04] <jcw4> thanks mgz
[13:05] <mgz> jcw4: no probs
[13:07] <jcw4> anastasiamac: congrats on your first blocker bug fix yesterday :)
[13:10] <mgz> jcw4: it's not quite done yet sadly :)
[13:10] <mgz> anastasiamac: poke poke :)
[13:10] <anastasiamac> it was not me fixing it tho :-) I was just a PA that typed it
[13:10] <jcw4> anastasiamac: lol
[13:10] <jcw4> mgz: it's still not working?
[13:11] <jcw4> mgz: was that your ordering bugfix?
[13:12] <mgz> jcw4: no, that's amusingly an unrelated regression that was masked by the fact that other bug was already causing the test job to fail
[13:12] <jcw4> mgz: I see.
[13:13] <mgz> once both land the ppc64el job might be happy again
[13:13] <jcw4> anastasiamac: my first big PR was step by step laid out for my by thumper - I was pretty much a PA too.
[13:13] <jcw4> mgz: hopefully
[13:17] <jcw4> TheMue: I responded to your comments on https://github.com/juju/names/pull/28
[13:33] <jcw4> mgz: wrt. to the un-exercised error case you mentioned in the review... the only error that would get returned is if the mgo iterator returns an error on closing in a defer block (state/state.go:1620)
[13:33] <jcw4> mgz: I'm not quite sure how to cause that error
[13:34] <jcw4> mgz: suggestions? or should I make a fake ActionReceiver and force a bogus error return there just to exercise that line?
[13:52] <mgz> jcw4: you can fake, but if it's that edgy it's likely not worth bothering with
[13:56] <jcw4> okay; thanks mgz - shall I drop that issue?
[13:59] <jcw4> mgz: dropped - as soon as I get my names PR landed I'll update this one with the dependencies.tsv change.  Should I take "looks great overall" as an LGTM or wait for an official one? :)
[14:07] <mgz> jcw4: I may bug someone else as well for the shipit
[14:13] <jcw4> mgz: ta
[14:19] <mgz> axw, anastasiamac: https://code.google.com/p/go/issues/detail?id=8654
[14:23] <anastasiamac> mgz: yep
[15:30] <huwshimi> 346022
[15:30] <huwshimi> 250720
[15:30] <huwshimi> 962491
[15:30] <huwshimi> 279768
[15:30] <huwshimi> 376365
[15:30] <huwshimi> Erm
[15:30] <perrito666> huwshimi: ok
[15:53] <mgz> axw: bug 1379380 - can you go/gccgo compile and compare goyaml.Marshal(map[string]string{{"pew": "pew\npew\n"}}) - something very odd is happening...
[15:53] <mup> Bug #1379380: Test failure on gccgo in RelationGetSuite <juju-core:Triaged> <https://launchpad.net/bugs/1379380>
[15:53] <jcw4> mgz: axw fwiw, I was seeing the same error with go 1.3.3 recently
[15:57] <axw> looking
[15:57] <axw> anastasia had this issue before, but I couldn't repro
[15:58] <mgz> with gccgo? maybe it's some other thing, like wrong goyaml version
[15:58] <axw> yes, with gccgo
[15:59] <axw> testing again now anyway
[16:00] <axw> gccgo 4.9.1 vs. gc 1.3 makes no diff to me
[16:00] <mgz> worth asking anastasiamac what goyaml she hath
[16:00] <mgz> jcw4: if you can repo, what goyaml?
[16:00] <axw> yes, I was going to ask to do godeps, but then got sidetracked
[16:01] <jcw4> mgz:  I'd have to reboot my mac into ubuntu since it was on an experimental dual boot instance
[16:01] <jcw4> mgz: but I'm pretty sure it was a stock godeps -u dependencies.tsv version of goyaml
[16:01] <mgz> jcw4: 's not urgent
[16:38] <jcw4> mgz, axw  my goyaml was at a different revision - confirming the goyaml suspicion