[02:11] <axw> wallyworld_: do you know why bootstrap forces --upload-tools for the local provider?
[02:12] <wallyworld_> axw: it doesn't distinguish, so if it doesn't need to for the local provider, that needs to be added in
[02:12] <wallyworld_> it was an oversight on my part i think
[02:13] <wallyworld_> axw: although local provider has always been funky with tools
[02:13] <axw> wallyworld_: what I mean is, in cmd/juju/bootstrap.go, it goes: if provider == 'local': uploadTools = true
[02:13] <axw> I just don't understand why.
[02:13] <wallyworld_> ah ok. that was deliberate then, by tim
[02:13] <axw> yeah
[02:13] <axw> don't know why? :)
[02:14] <axw> convenience?
[02:14] <wallyworld_> i think it's because the jujud needs to be put in the local provider's storage
[02:14] <wallyworld_> so it can find it
[02:14] <wallyworld_> cause local provider does not want to have to use streams.canonical.com etc
[02:14] <wallyworld_> so the local provider has been treated as an edge case
[02:15] <wallyworld_> but it is known to be a dirty great hack
[02:15] <axw> why not use streams.canonical.com like the others?
[02:15] <axw> it can be overridden with --upload-tools
[02:15] <wallyworld_> when it was written, there was no streams,canonical.com. there was an s3 bucket and you needed credentials for that
[02:16] <wallyworld_> so it was done out of necessity
[02:16] <axw> ok
[02:16] <wallyworld_> we can probs revisit that now
[02:17] <wallyworld_> s/probs/should :-)
[02:19] <axw> hm, I removed it and get errors about not finding 1.17 at s3. that could be due to some other changes I have going on tho
[02:20] <wallyworld_> i think sync tools used to look at s3
[02:20] <wallyworld_> and that's what upload-tools uses
[02:20] <wallyworld_> if are running the dev version, there are no 1.17 tools
[02:20] <wallyworld_> s/dev/from source
[02:21] <axw> no, but it should upload the local ones as a last resort
[02:21] <wallyworld_> so that's the other issue - running from source also requires a upload tools
[02:21] <wallyworld_> it should have i think yes
[02:21] <axw> I'm making providers responsible for selecting bootstrap tools
[02:21] <axw> must've broken it
[02:21] <wallyworld_> :-)
[02:40] <axw> wallyworld_: wasn't my code- the local provider explicitly sets agent-version to version.Current if it doesn't have agent-version already
[02:40] <wallyworld_> ok
[02:41] <axw> which stops the auto-upload stuff
[02:41] <wallyworld_> if there a agent-version check somewhere?
[02:41] <axw> yeah, in the current code as well. It won't try to auto-upload if the user has specified agent-version
[02:42] <axw> we could perhaps be a bit smarter, and check if agent-version is the same as what's on disk
[02:42] <wallyworld_> i wonder why that code is there
[02:42] <axw> but ... I'm not convinced the local provider needs all this special stuff
[02:42] <axw> so you don't accidentally get a version you didn't ask for, I guess
[02:42] <wallyworld_> i know there was a lot of hair pulling at the time, but am not sure of the details
[02:43] <wallyworld_> would be worth a chat with tim when he's back to get the back story on it all
[02:43] <axw> yup definitely
[07:04] <jam> sinzui: it is "tsv" as tab-separated-value so it wasn't supposed to be changed
[07:09] <fwereade> axw, heyhey
[07:09] <fwereade> I'm around if you are
[07:09] <axw> fwereade: morning
[07:09] <axw> I am
[07:10] <axw> brb, just getting a drink
[07:10] <fwereade> axw, actually I'm around in 5 mins after a quick ciggie
[07:10] <fwereade> axw, you're too quick for my morning brain ;)
[07:10] <axw> nps
[07:31] <axw> fwereade: I can't hear you if you're talking
[07:49]  * fwereade is off to get up and run a couple of errands, bbiab
[07:49] <axw> wallyworld_: would you be able to review this for me next week? https://codereview.appspot.com/14433058/
[07:49] <axw> (please) :)
[08:06] <rogpeppe1> mornin' all
[08:59] <wallyworld_> axw: sure, will do
[09:12] <axw> hey rogpeppe1, thanks for the review. let me know if you have any thoughts about my response (particularly around the ConfigureBase name)
[09:12] <rogpeppe1> axw: looking
[09:14] <rogpeppe1> axw: the underlying problem, i think, is that it ties together an random bunch of stuff, so it's difficult to think of a nicely descriptive name for it
[09:15] <axw> rogpeppe1: what's the alternative? ConfigureAuthorizedKeys and ConfigureOutput?
[09:16]  * rogpeppe1 goes to look at the manual provider case
[09:16] <axw> maybe we don't even both with that method, and have provider/common do it.
[09:17] <axw> bother*
[09:17] <axw> ah, but provisioning non-bootstrap machines needs it too
[09:17] <axw> rogpeppe1: manual provider only uses ConfigureJuju
[09:18] <rogpeppe1> axw: hmm, that's interesting in itself - where does its cloudinit output end up?
[09:18] <axw> rogpeppe1: it doesn't use cloud-init
[09:18] <axw> all output goes to stdout
[09:18] <axw> which comes back to the SSH client
[09:18] <rogpeppe1> axw: if it doesn't use cloud-init, what's it doing with ConfigureJuju?
[09:19] <axw> rogpeppe1: it translates the cloudinit.Config into a script. there's an open bug to update cloud-init to have a way of invoking manually/interactively
[09:20] <rogpeppe1> axw: oh gosh
[09:20] <rogpeppe1> axw: where does that translation happen?
[09:21] <axw> rogpeppe1: currently, environs/manual/agent.go; I have a followup CL that moves this to a new package, cloudinit/sshinit
[09:21] <axw> and makes it sufficiently generic of course
[09:22] <rogpeppe1> axw: well, in that case, it would be fine for the manual provider to use exactly the same base config, no?
[09:22] <rogpeppe1> axw: because it will ignore what it doesn't care about
[09:22] <axw> rogpeppe1: depends on whether we want to do different things in ConfigureBase (like run additional commands)
[09:23] <rogpeppe1> axw: if we do, then we probably want those commands to work in the manual provider too, i'd guess
[09:23] <axw> rogpeppe1: hmm perhaps, yes. actually, now that I think of it... there's probably no good reason to split them anymore
[09:24] <rogpeppe1> axw: this is part of the problem with the name "base" - it implies it's "base" for everything, but it's really "base for everything other than the manual provider"
[09:24] <axw> rogpeppe1: I went through a few iterations here
[09:24] <rogpeppe1> axw: sure
[09:24] <axw> I'll ponder a bit
[09:24] <rogpeppe1> axw: it kinda feels trivial, but it's also the kind of thing that can grow in complexity
[09:24] <axw> yup, fair enough
[09:24] <rogpeppe1> axw: so i'd like us to get the abstractions right here
[09:25] <axw> it's confusing enough as it is anyway :)
[09:25] <rogpeppe1> axw: yeah
[09:25] <axw> so many different interactions
[09:33] <rogpeppe1> axw: it's one of those places where the code with common pieces factored out is arguably harder to read and maintain than the original copypasta.
[09:33] <axw> rogpeppe1: I lied apparently, anyway. I didn't end up using ConfigureJuju in environs/manual. I was going to use it in the followup, but I can use the existing one after all
[09:43] <rogpeppe1> fwereade: is it possible you could have a glance through this doc for sanity checking, please? https://docs.google.com/a/canonical.com/document/d/1vZrav8Do80Lnk1uFNdVVV2jRqpEH99wcX3YWErPwWIg/edit
[09:44] <rogpeppe1> fwereade: nate has a couple of reasonable comments, but i don't want to change things away from your suggestions without your goahead
[09:50] <axw> rogpeppe1: LGTM stands with the two functions joined?
[09:51] <rogpeppe1> axw: i think so. what's actually changed in that case then?
[09:51] <axw> rogpeppe1: just the signature (it was a bit funky - took an arg that's modified and returned it), and dropped the unnecessary New function
[09:52] <axw> the file could be reverted, but I think it's a bit cleaner now
[09:52] <rogpeppe1> axw: looks like you haven't proposed the changes yet
[09:55] <axw> rogpeppe1: it was a hypothetical question, but the changes are coming.. super slow from here
[09:56] <rogpeppe1> axw: ah, that's fine. in principle it all sounds great.
[09:56] <axw> rogpeppe1: updated now
[10:00] <TheMue> interesting behavior, first eth0 closed, later whole instance terminated, but netstat still sees an established connection :(
[10:02] <rogpeppe1> axw: reviewed
[10:03] <axw> thanks rogpeppe1, good suggestions - will do them before landing
[10:03] <rogpeppe1> axw: thanks
[10:03] <axw> I mean to use US spelling, it's just automatic
[10:04] <rogpeppe1> axw: yeah - i try to use the US spelling everywhere just for consistency with the go std lib
[10:04] <axw> I defied it at IBM for a long time - but that was internal code
[10:04] <axw> yup, fair enough
[10:05] <rogpeppe1> axw: i will still use initialise and colour everywhere *except* in the source tree :-)
[10:10] <axw> alright, that's it for me. have a nice weekend all
[10:10] <rogpeppe1> axw: have a good one
[10:26] <fwereade> rogpeppe, can I trouble you for a review of https://codereview.appspot.com/26100043/ ? I am catching up to the point I can review your doc I think
[10:27] <rogpeppe> fwereade: looking
[10:27] <fwereade> rogpeppe, mgz is ocr but I can't see him
[10:27] <fwereade> rogpeppe, cheers
[10:28] <rogpeppe> fwereade: are there any pieces that i should look at in particular (i presume it's all been reviewed before when it went onto trunk) ?
[10:30] <rogpeppe> fwereade: in particular, are there any bits you made some manual changes in, rather than just running patch?
[10:34] <fwereade> rogpeppe, the hack in jujud/machine_test.go is the only bit that hasn't been reviewed individually
[10:35] <rogpeppe> fwereade: is all the code in state/cleanup.go new, or is it just moved from elsewhere?
[10:37] <rogpeppe> fwereade: ah, i see; some's new.
[10:39] <fwereade> rogpeppe, I'm pretty certain all the revs I cherrypicked were mentioned in the message so there is at least some route back to the original reviews
[10:40] <rogpeppe> fwereade: ah i see. in future it would be good if those were codereview links
[10:40] <rogpeppe> fwereade: or MP links anyway
[10:42] <rogpeppe> fwereade: reviewed
[10:47] <dimitern> rogpeppe, fwereade, wallyworld_ : standup
[11:09] <rogpeppe> dimitern: https://codereview.appspot.com/22100045/
[11:10] <dimitern> rogpeppe, cheers
[11:17] <rogpeppe> can anyone explain to me how this line of code actually works? /home/rog/src/go/src/launchpad.net/juju-core/state/environ.go:34
[11:18] <dimitern> rogpeppe, err := st.environments.Find(D{{"uuid", D{{"$ne", ""}}}}).One(&doc) ?
[11:18] <rogpeppe> dimitern: yeah
[11:18] <rogpeppe> dimitern: i suspect it only works by accident
[11:18] <dimitern> rogpeppe, what's wrong with it
[11:18] <rogpeppe> dimitern: there's no uuid field in the document
[11:19] <dimitern> rogpeppe, ha, really?
[11:19] <rogpeppe> dimitern: i think it only works because "" != nil
[11:19] <dimitern> rogpeppe, and it's always ""
[11:19] <rogpeppe> dimitern: yeah - there's a UUID field in the struct, but it's renamed to _id
[11:19] <rogpeppe> dimitern: it's always nil
[11:19] <rogpeppe> dimitern: because it doesn't exist
[11:20] <dimitern> rogpeppe, so this block returns err == nil
[11:20] <dimitern> rogpeppe, and works, i've tried
[11:21] <rogpeppe> dimitern: it'll correctly fetch the only environment document
[11:21] <dimitern> rogpeppe, what if there are more than one?
[11:21] <rogpeppe> dimitern: it would fetch the first
[11:22] <dimitern> rogpeppe, this looks like a lurking bug
[11:22] <rogpeppe> dimitern: +1
[11:22] <dimitern> rogpeppe, good catch
[11:22] <rogpeppe> dimitern: i'm not sure why there's any search condition in there at all, tbh
[11:23] <rogpeppe> dimitern: i don't know any case where we'd insert a document with an empty uuid
[11:23] <dimitern> rogpeppe, because I think when environs were added to the schema it was unclear how to refer to them
[11:23] <dimitern> rogpeppe, or that changed later with the uuid perhaps
[11:24] <fwereade> rogpeppe, what's the latest on that panic of davecheney's? Irecall you talking about it yesterday but I hadother thingsonmy mind
[11:24] <rogpeppe> dimitern: really i think we should hand the uuid to the state when opening an environment
[11:24] <rogpeppe> fwereade: the gccgo issue?
[11:24] <dimitern> rogpeppe, TheMue, that's in rev 1122
[11:24] <rogpeppe> fwereade: it's much less of a problem than we thought
[11:24] <fwereade> rogpeppe, I have no context on it, but it's targeted for 1.16
[11:24] <fwereade> rogpeppe, does it not need to be?
[11:25] <rogpeppe> fwereade: it is a gccgo bug though, and we should work around it
[11:25] <rogpeppe> fwereade: for the time being
[11:25] <rogpeppe> fwereade: the problem only happens when the gccgo runtime tries to call a function/method that returns an empty struct
[11:26] <rogpeppe> fwereade: i think there's probably only one such method (Pinger)
[11:26] <rogpeppe> fwereade: and we can trivially work around the issue by including a dummy field (e.g. _ bool)
[11:26] <rogpeppe> fwereade: in the srvPinger struct type
[11:27] <rogpeppe> fwereade: it seems like a good candidate for backporting to 1.16 (a 1 line change)
[11:27] <fwereade> rogpeppe, sorry, I'm thinking of https://bugs.launchpad.net/juju-core/+bug/1227952
[11:27] <_mup_> Bug #1227952: juju get give a "panic: index out of range" error <regression> <goyaml:Fix Committed by dave-cheney> <juju-core:In Progress by dave-cheney> <juju-core 1.16:In Progress by dave-cheney> <https://launchpad.net/bugs/1227952>
[11:28] <fwereade> rogpeppe, (is anyone building 1.16 with gccgo?)
[11:28] <rogpeppe> fwereade: ah, that was a goyaml bug which is now fixed
[11:28] <rogpeppe> fwereade: i dunno
[11:28] <rogpeppe> fwereade: the 1.16 deps would need updating
[11:29] <rogpeppe> fwereade: that's all, i think
[11:31] <rogpeppe> afk
[11:45] <rogpeppe> back
[13:16]  * rogpeppe wishes it took less than 3 minutes to run lbox propose
[13:21] <rogpeppe> mgz, natefinch, fwereade: first step towards keeping track of state servers: https://codereview.appspot.com/26880043
[13:22]  * rogpeppe goes for lunch
[13:23] <mgz> rogpeppe: looking
[14:00] <rogpeppe> mgz: did you have some queries about it?
[14:01] <rogpeppe> fwereade: i would really appreciate your feedback too, please, as i don't want to go up another blind alley
[14:01] <natefinch> rogpeppe: I'm looking, but need a little more time with it... once my two very cute distractions are with their mother, I'll be able to give it more attention
[14:01] <rogpeppe> natefinch: ok
[14:01] <natefinch> rogpeppe: which will be shortly
[14:41] <rogpeppe> can anyone think of a nicer way to test (in mongo) if the length of an array is odd than this? $where: function() { return this.stateservers.length % 2 == 1}
[14:41] <mgz> that seems reasonable
[14:42] <rogpeppe> i don't think it's a problem in this case, but it would be nice to use built-in ops if possible
[14:42] <rogpeppe> mgz: did you manage to review the above CL, BTW?
[14:42] <rogpeppe> mgz: 't'would be much appreciated if you could
[14:42] <mgz> rogpeppe: yeah, getting there... sorry
[14:42] <rogpeppe> mgz: np
[14:42] <natefinch> rogpeppe: I'm in the middle of it too. Looks fine so far.
[14:43] <rogpeppe> natefinch: thanks
[14:43] <natefinch> rogpeppe: also, %2 == 1 is pretty standard "is odd" ... seems unlikely there'd be a built-in op, but I don't know for sure
[14:43] <rogpeppe> natefinch: well, there's a built-in $mod operation
[14:43] <rogpeppe> natefinch: but i'm not sure there's a way to apply it to the length of an array
[14:50] <natefinch> rogpeppe: doesn't look like it's possible
[14:50] <rogpeppe> natefinch: yeah
[14:51] <rogpeppe> natefinch: as it turns out, i don't need to do it anyway... :-)
[14:52] <natefinch> rogpeppe: even better
[14:54] <natefinch> good god state_test.go is too big
[14:56] <mgz> rogpeppe: reviewed, just some side questions due to my shakey understanding of state management bits.
[14:56] <rogpeppe> natefinch: yeah, State is big
[14:57] <rogpeppe> mgz: ta!
[15:09] <rogpeppe> fwereade: could we have a chat about this?
[15:09] <fwereade> rogpeppe, ofc
[15:09] <rogpeppe> fwereade: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
[15:38] <rogpeppe> fwereade: i had to reboot, sorry
[15:38] <rogpeppe> fwereade: back there now
[15:50] <sinzui> rogpeppe, natefinch : do either you you have a few minutes to review this dep change: https://codereview.appspot.com/26940043
[15:50] <rogpeppe> sinzui: looking
[15:54] <rogpeppe> sinzui: looks like it should be rev 50, not 49
[15:54] <sinzui> really?
[15:55] <sinzui> rogpeppe, is tip also wrong? I can set that to 50
[15:55] <rogpeppe> sinzui: yeah, that would be better, i think (rev 50 altered the rev 49 fix slightly)
[15:56] <mgz> rogpeppe: was trunk bumped to r50?
[15:56] <rogpeppe> mgz: yeah
[15:56] <rogpeppe> mgz: i mean, no
[15:56] <rogpeppe> mgz: goyaml trunk was
[15:56] <rogpeppe> sinzui: BTW I'm a bit surprised there's no test case to go along with this
[15:57] <sinzui> rogpeppe, yep. We see it in CI though. the lander would do if it honoured godeps
[15:58] <rogpeppe> sinzui: ah, that's good
[15:58] <sinzui> rogpeppe, I am focused on a release today, but I or someone on juju-qa can get such a test by next week.
[15:59] <sinzui> such a test would have caught the spaces yesterday
[15:59] <rogpeppe> sinzui: it sounds like there already is a test, if tests now pass in CI but did fail before this fix
[15:59] <rogpeppe> sinzui: ah, but CI doesn't just run the tests, gotcha
[16:00] <rogpeppe> sinzui: yeah, i think this should probably have a test case, but i won't hold up this change for that
[16:00] <sinzui> rogpeppe, we are thinking about adding the test runner because it offers a sanity check that the integration tests have a sane start
[16:01] <rogpeppe> sinzui: yeah, i think that's probably worth doing
[16:01] <rogpeppe> sinzui: reviewed
[16:18] <rogpeppe> fwereade, natefinch, mgz: PTAL https://codereview.appspot.com/26880043
[16:37] <rogpeppe> natefinch: any chance of a LGTM ?
[16:44] <rogpeppe> hmm, i thought that instance.HardwareCharacteristics was a result, not a parameter
[16:44] <rogpeppe> but in state.AddMachineParams it seems to be being used as a kind of constraint
[16:46] <fwereade> rogpeppe, it's not aconstraint -- it's there for injected machines iirc
[16:46] <rogpeppe> fwereade: ah, ok
[16:47] <fwereade> rogpeppe, it's the result of what we got, that should hopefully match the constraints
[16:47] <rogpeppe> fwereade: i'm wondering whether i should be using addMachineOps or addMachineContainerOps when creating new state server machines
[16:47] <fwereade> rogpeppe, the former, almost certainly
[16:48] <fwereade> rogpeppe, and please don't be afraid to massage them into a better shape if necessary
[16:49] <rogpeppe> fwereade: i couldn't see how point 2) in the comment for addMachineContainerOps didn't also apply to creating state server machines
[16:51] <rogpeppe> fwereade: and since addMachine itself calls addMachineContainerOps, i thought perhaps i should too.
[16:52]  * rogpeppe still doesn't really understand the containers stuff
[16:53] <fwereade> rogpeppe, it looks like addMachineContainerOps is *actually* there to create a parent machine if it's necessary and doesn't already exist,but Imay be misskimming
[16:53] <rogpeppe> fwereade: that seems plausible
[16:53] <fwereade> rogpeppe, it's not helpfully named
[16:54] <rogpeppe> fwereade: in which case, I'd only use it when we come to do --to (or whatever it's called)
[16:54] <fwereade> rogpeppe, and would surely benefit from a smart person WTFing at it a bit and probably renaming some bits for clarity ;)
[16:54] <rogpeppe> fwereade: i'm not smart enough
[16:55] <fwereade> rogpeppe, sell not yourself short dude
[16:55] <fwereade> rogpeppe, but it's not a demand anyway ;)
[16:55] <fwereade> rogpeppe, I'm EOD, and I'm afraid I need to be off pretty sharpish -- we are out of booze that cath feels like drinking ;p
[16:56] <rogpeppe> fwereade: just one thing:
[16:56] <rogpeppe> fwereade: i'm presuming it should be started with series taken from environ config default series, right?
[16:56] <fwereade> rogpeppe, sure (and I'll try to stick my head back in later as well so leave other questions as necessary, someone else might know the answers in the meantime)
[16:57] <rogpeppe> fwereade: i suggest you alleviate the booze emergency a.s.a.p BTW :-)
[16:57] <fwereade> rogpeppe, that sounds like a good start
[16:57] <fwereade> rogpeppe, in future --to a machine that isn't default-series should probably be fine too though
[16:57] <fwereade> rogpeppe, cheers :)
[16:57] <fwereade> happy weekends all
[16:57] <rogpeppe> fwereade: have a good one
[17:04] <natefinch> TheMue: how old are your kids?
[17:05] <TheMue> natefinch: 17 and 19
[17:05]  * TheMue just fights a bit with his network :(
[17:09] <rogpeppe> natefinch: any chance of another look at the https://codereview.appspot.com/26880043; i'd like to land it tonight if possible, and i haven't got that long
[17:16] <natefinch> rogpeppe: yep, looking
[17:16] <rogpeppe> natefinch: thanks
[17:22] <natefinch> rogpeppe: btw, you can use jc.SameContents to compare to unordered lists
[17:22] <rogpeppe> natefinch: ah, i'd forgotten that
[17:23] <rogpeppe> natefinch: given that sort.Strings is easy at this point, i might just leave it as is
[17:23] <natefinch> rogpeppe: yeah yeah, that's fine.  Just a reminder for next time when it's not as easy.
[17:23] <rogpeppe> natefinch: yeah, thanks
[17:28] <sinzui> rogpeppe, This is the comparable goyaml dep fix for trunk: https://codereview.appspot.com/26960043
[17:29] <rogpeppe> sinzui: LGTM
[17:29] <sinzui> thank you
[17:33] <rogpeppe> natefinch: personally I feel that it's a mistake for callers of a function to be relying on specific error kinds returned by the function
[17:34] <rogpeppe> natefinch: unless they're explicitly documented
[17:34] <rogpeppe> natefinch: because they're really part of the implementation detail of the function
[17:34] <rogpeppe> natefinch: my errgo package (launchpad.net/errgo/errors) makes that a point of principle and always masks the underlying error kind unless you explicitly ask otherwise
[17:38] <natefinch> rogpeppe: the common and expected errors *should* be documented
[17:38] <rogpeppe> natefinch: indeed
[17:38] <rogpeppe> natefinch: and in this case there are none
[17:38] <rogpeppe> natefinch: because the document must have been created already
[17:39] <rogpeppe> natefinch: error kinds are important when a caller might legitimately decide to act differently based on the kind of error
[17:39] <rogpeppe> natefinch: in this case all the errors are as bad as each other
[17:40] <natefinch> rogpeppe: yes, definitely.  That's fair.  I thought there might be some well-known errors, but if there are not, then no big deal.
[17:41] <rogpeppe> natefinch: it's annoying that with the standard error stuff you can't add contextual information to an error without either losing the kind or needing to define your own type
[17:42] <natefinch> rogpeppe: that's why I made errorWrapper in errors... though it's not directly exposed currently
[17:42] <rogpeppe> natefinch: check out errgo - I think it works pretty well. i've been using it a reasonable amount.
[17:57] <natefinch> rogpeppe: neat, but not sure I understand the use case for having a diagnosis that is different from the actual error
[17:58] <rogpeppe> natefinch: the actual error can have lots of extra context associated
[17:58] <rogpeppe> natefinch: the diagnosis is the metadata of the error, if you like
[17:58] <natefinch> rogpeppe: why not just wrap the error in a new one that is more accurate?
[17:59] <rogpeppe> natefinch: because that's a lot of hassle - you need to define a new error type each time.
[18:00] <rogpeppe> natefinch: often it's useful to have classes of error (e.g. "not found") but still keep around some info about the original error
[18:00] <rogpeppe> natefinch: for example errgo keeps information about the source locations where the error was propagated with Wrap
[18:00] <rogpeppe> natefinch: the division seems to work pretty well in practice
[18:12] <rogpeppe> right, i'm done
[18:13] <rogpeppe> natefinch: g'night
[18:13] <rogpeppe> and happy weekends to one and all
[18:13] <natefinch> rogpeppe: night
[18:53] <sinzui> natefinch, I think gobot sent my a spurious failure. Do I change the review to approved again to retry, or to I need to also add a comment like LGTM, tests pass locally?
[18:55] <natefinch> sinzui: you can just re-approve.  looked spurious to me
[18:55] <sinzui> thank you natefinch