[00:31] <hazmat> umm.. https://bugs.launchpad.net/juju-core/+bug/1256053/comments/3
[00:31] <hazmat> i think we need to mark this critical https://bugs.launchpad.net/juju-core/+bug/1215579
[00:31] <_mup_> Bug #1215579: Address changes should be propagated to relations <addressability> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1215579>
[00:32] <hazmat> i'm working up a script to resolve it, but even transporting the script to all the units is a bit tedious without resorting to ansible and a juju inventory
[00:48] <hazmat> posted a workaround to both, nevermind re critical..
[00:56] <davecheney> hazmat: createing a worker running on ecah machine agent that listens to netlink should be straight forward
[00:56] <davecheney> what hook would it fire ?
[00:57] <hazmat> davecheney, the user's issue isn't actually the one that bug
[00:57] <hazmat> davecheney, the netlink this is pure optimization
[00:57] <hazmat> davecheney, the actual issue is that juju doesn't update the relations per bug http://pad.lv/1215579
[00:58] <hazmat> davecheney, ie. you can have unit related to another service whose ip addrss changes. juju will pick up the address change. but the private-address of that unit in its relations (which juju set) will never be updated.
[00:58] <hazmat> s/netlink this/netlink thing
[00:59] <hazmat> davecheney, fwiw.. here's my workaround for folks today.. https://gist.github.com/kapilt/a61efcb4eaef9e685397
[01:00] <wallyworld_> hazmat: i'll get tanzanite to start working on that bug after the githib migration; likely early next week
[01:00] <hazmat> wallyworld_, awesome, thanks
[01:00] <wallyworld_> maybe even this week if we have bandwidth
[01:00] <wallyworld_> hazmat: stuff like that, just ensure i know about it and we'll prioritise it
[01:01] <hazmat> wallyworld_, will do.
[01:01]  * hazmat calls it a night
[01:03] <axw> morning all
[01:04] <wallyworld_> axw: morning
[01:05] <wallyworld_> axw: i've got agreement to set up a test instance running mongo 2.7.1 to see if that hep with the mongo instability
[01:05] <wallyworld_> well, mongo > 2.4.x
[01:05] <wallyworld_> 2.7.1 is the latest
[01:05] <axw> wallyworld_: cool
[01:05] <wallyworld_> it's compiling now on the instance, will create a jenkins job
[01:07] <wallyworld_> axw: cause one of the failures with replicaset tests i looked at yesterday - the mongo process just died for no reason and hence broke the test. there's several mongo bugs which might be culpable which are fixed in 2.6 or later which are not being back ported
[01:07] <wallyworld_> so if this goes well, we'll look to get mongo 2.6/7 into juju-mongodb
[01:08] <axw> wallyworld_: did it actually die (core?) or did it just drop the connection?
[01:08] <axw> wallyworld_: meant to ask on the hangout, but forgot
[01:08] <wallyworld_> axw: the log showed the mongo process itself died
[01:08] <axw> ok
[01:08] <wallyworld_> and the test tried to reset and ping and failed cause the process was gone
[01:09]  * wallyworld_ taps fingers waiting to mongo to finish compiling
[01:38] <davecheney> thumper: http://paste.ubuntu.com/7525844/
[01:38] <davecheney> what am I not seeing ?
[01:39] <thumper> davecheney: whitespace maybe?
[01:40] <thumper> davecheney: menn0 and I suggest doing a full print prior to the assert
[01:40] <thumper> just to check
[01:41] <menn0> 	err := st.users.Find(bson.D{
[01:41] <menn0> 		{"_id", bson.RegEx{
[01:41] <menn0> 			Pattern: "^" + regexp.QuoteMeta(name) + "$",
[01:41] <menn0> 			Options: "i", // case-insensitive
[01:41] <menn0> 		}}}).One(udoc)
[01:41] <menn0> 	if err == mgo.ErrNotFound {
[01:41] <menn0> 		err = errors.NotFoundf("user %q", name)
[01:41] <menn0> 	}
[01:41] <menn0> 	return err
[01:41] <menn0> }
[01:41] <menn0> sorry, ignore that
[01:41] <davecheney> thumper: full print ?
[01:42] <menn0> davecheney: fmt.Printf("%q", tw.Log)
[01:43] <davecheney> kk
[01:48] <davecheney> hmm, that just makes things more confusing
[01:48]  * davecheney goes to look at js.LogMatches
[01:52] <davecheney> grr
[01:52] <davecheney> this is a bug with the matcher
[01:52] <davecheney> http://paste.ubuntu.com/7525911/
[01:53] <davecheney> when times didn't match, the matcher returns false but keeps the reason to itself
[02:26] <davecheney> has anyone tried to write a gocheck checker that checks the output of another checker
[02:29] <davecheney> oh and the checker type is not exported
[02:29]  * davecheney throws a table
[02:44] <axw> davecheney: gocheck.Not does that
[02:47] <davecheney> axw: can I use that to write a test of a checker ?
[02:48] <axw> davecheney: sorry maybe I misunderstood. I don't know how you'd do that
[02:48] <davecheney> axw: s'ok, i'm working on something
[04:13] <jcw4> if state/state.go has an un-exported logger, can I use that in state/action.go, or should I declare a new logger with a different name to avoid a name collision?
[04:15] <jcw4> thumper: since it's midday likely for you, and you just emailed about errors... ^^^ :)
[04:16] <jam1> jcw4: you can use logger in any file in the same package
[04:16] <axw> jcw4: all source files in the same package can/should use the same logger, as a general rule
[04:16] <jam1> so just use "logger.Debugf" in action.cog
[04:16] <jcw4> jam1, axw great.  Thanks
[04:17] <jimmiebtlr> Is it expected that the output of add-machine is to Stderr?  ex. "created machine 1"
[04:26] <wallyworld_> axw: with the replicaset stuff - we cab back it out if it doesn't help, or, if 2.7.1 works better we can change it also, or william likes the idea of mocking out the replicaset behaviour and adding separate CI tests so we'll be looking into that as well
[04:26] <axw> wallyworld_: sounds good
[04:43] <jcw4> jimmiebtlr: I assume so... sorry. I don't know
[04:47] <jcw4> I can't seem to get -gocheck.f="ActionSuite"
[04:47] <jcw4> to work
[04:47] <jcw4> is there a trick to it, or does it just not work?
[04:49] <jcw4> jam1: ^^  :)
[04:49] <jam1> jcw4: you're sure it is spelled "ActionSuite" and not "actionSuite" or some other spelling?
[04:50] <jcw4> jam1: interesting... yep, just verified
[04:50] <jam1> go test -gocheck.v -gocheck.f=apiclient does what I would expect
[04:51] <jcw4> is it somehow related to not having the testing package initialize in that suite?
[04:51] <jam1> jcw4: are you trying to run the tests recursively? or just in one dir?
[04:51] <jcw4> go test -gocheck.f="ActionSuite" ./state/...
[04:51] <jam1> jcw4: if you don't have a testing.T function in a package, then no tests get run by "go test"
[04:51] <jam1> jcw4: well, I'm sure that syntax won't work, because you are passing the "…" at the end
[04:51] <menn0> jcw4: which directory are you running "go test" from?
[04:52] <jcw4> jam1: I see
[04:52] <jam1> and go test is a bit picky about argument order
[04:52] <jcw4> menn0: juju-core
[04:52] <jcw4> what is the preferred argument order jam1
[04:52] <jam1> jcw4: at the least, you need to spell it "go test ./state/… -gocheck.f=ActionSuite"
[04:52] <jcw4> jam1: Ah!  I see
[04:52] <jam1> the issue is that there are some arguments that are processed by "go test"
[04:52] <menn0> try changing to the package directory where ActionSuite is defined
[04:52] <jcw4> menn0: +1
[04:52] <jam1> and there are other arguments that are processed by the binary that it builds and runs for you
[04:53] <jam1> "…" is telling *go test* to run everything
[04:53] <jam1> "-gocheck.f" is being passed to the binary that gets built to tell it what to run
[04:53] <axw> I believe the -gocheck args don't get passed down if you run use "..."
[04:53] <jam1> since "go test" itself doesn't understand what "-gocheck" means, it stops processing arguments and hands the rest to the binary being run
[04:53] <axw> davecheney: right? ^
[04:53] <jam1> axw: it does, you just have to spell it right
[04:54] <jcw4> axw, jam1, menn0 fantastic help.  Thanks
[04:54] <jam1> axw: I originally thought it was all broken because "-gocheck.v" looks like it doesn't work, but actually it does, but without "-v" "go test" in recursive mode suppresess the output
[04:54] <jam1> so you have to do:
[04:54] <jam1> go test -v ./… -gocheck.v -gocheck.f=XXX
[04:54] <jam1> axw: ^^
[04:55] <jam1> axw: and you can't quite do that in juju-core because the 3rd party packages under utils don't use gocheck, and thus fail if you try to pass them those flags
[04:55] <axw> hmm ok
[04:55] <axw> gocheck.v isn't doing anything when I use ...
[04:55] <jam1> what sucks, is that having the test binary passed positional arguments
[04:55] <jam1> doesn't fail
[04:55] <jam1> but it does fail if you pass named options
[04:55] <jam1> (ah consistency....)
[04:55] <jcw4> axw, jam1, menn0 yep it worked (when I didn't use ..., and reordered gocheck opts to the end)
[04:57] <axw> jam1: ah right, missed the need for -v
[04:57] <davecheney> jcw4: axw correct
[04:57] <davecheney> those arguments should go at the end of the command line
[04:58] <jam1> axw: yeah, so did I for a *long* time.
[04:58] <davecheney> there is no reason gocheck couldn't adjust gocheck.v based on the test.v value which is better handled by the go tool
[05:08] <davecheney> does anyone have experience with writing gocheck checkers ?
[05:08] <davecheney> this is doing my head in
[05:11] <jam1> davecheney: I've done some
[05:12] <davecheney> jam1: can you explain how the Check siganture works ?
[05:12] <davecheney> Check(params []interface{}, names []string) (result bool, error string)
[05:12] <davecheney> names appears unused
[05:12] <davecheney> error is a string
[05:12] <jam1> if you are writing a checker, you should generally not put anything into error
[05:12] <davecheney> result appears to indicate succes or failure
[05:12] <davecheney> jam1: why not ?
[05:12] <jam1> because it indicates there is actually something you cannot test
[05:13] <jam1> davecheney: if you return an error it gets reported immediately, and breaks things like Not()
[05:13] <jam1> because Not(error) is still error
[05:13] <davecheney> ok
[05:13] <jam1> while Not(resultFalse) is still true
[05:13] <davecheney> this all started because
[05:13] <jam1> s/still/
[05:14] <jam1> davecheney: so IIRC, names can be used as an output variable, but you don't have to do anything with it as input
[05:14] <davecheney> http://paste.ubuntu.com/7525844/
[05:14] <davecheney> but names is passed as a value
[05:14] <davecheney> there is no way I could append to names inside the function
[05:14] <davecheney> and have that visible to the caller
[05:16] <jam1> davecheney: you may not be able to append, but I think you can change in place
[05:16] <davecheney> true
[05:16] <davecheney> ok
[05:17] <jam1> I believe that is how I made slightly nicer error messages by replacing params in place (so when you get an array of 100 things, you can report the 1 that is actually wrong, and hide the rest)
[05:17] <davecheney> ok
[05:18] <davecheney> that helps me understand what is going on
[05:18]  * jam1 really dislikes the in/out parameters, but that seems to be how gocheck works
[05:18] <davecheney> go check is ok as an assertion framework, but writing checkers is ass backwards
[05:18] <jam1> I was trying to figure out how to give nicer errors, but I can't just return something into "error" because that is a forceful failure
[05:19] <jam1> davecheney: fwiw, I think the actual failure from your paste is that the LogLevel is wrong, but it isn't being shown
[05:19] <davecheney> checked that
[05:20] <davecheney> [{"INFO" "audit" "audit_test.go" ')' "2014-05-27 11:52:08.804353055 +1000 EST" "user-agnus: donut eaten, 7 donut(s) remain"}]
[05:20] <davecheney> expected
[05:20] <davecheney> obtained
[05:20] <davecheney> ["INFO user-agnus: donut eaten, 7 donut(s) remain"]
[05:20] <jam1> ah, ffs, the match is a regex
[05:20] <jam1> and (s) doesn't match \(s\)
[05:20] <davecheney> if you excuse me
[05:20] <davecheney> i have to go outside and shout
[05:22] <davecheney> well, on the positive side
[05:22] <davecheney> i've got a branch which improves the coverage of the LogMatches to 100%
[05:22]  * jam1 wonders if we should have a fallback "regex did not match, but exact match did" error message.
[05:22] <jam1> :)
[05:36] <fwereade> axw, hey, re https://launchpad.net/bugs/1215579
[05:36] <_mup_> Bug #1215579: Address changes should be propagated to relations <addressability> <reliability> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1215579>
[05:36] <axw> fwereade: yo
[05:36] <fwereade> axw, please let me know what you're planning to do there
[05:36] <axw> fwereade: just trying to figure it out right now...
[05:36] <axw> fwereade: much bigger than I realised :)
[05:36] <fwereade> axw, indeed, it's in a positive thicket of subtleties
[05:37] <axw> fwereade: I was thinking a new worker, relationuniter, which watches for address changes on a machine and then updates the private-address setting for all relation units on that machine
[05:37] <fwereade> axw, the main issues are: (1) we have to have a hook for it, otherwise units can't respond to their *own* changes of address
[05:37] <fwereade> axw, -100
[05:38] <fwereade> axw, a worker that keeps an eye on address changes is one thing
[05:38] <fwereade> axw, fucking around with relations outside the purview of the uniter will totally fuck us
[05:38] <axw> ok
[05:39] <fwereade> axw, one issue is that they use the much-maligned state.Settings, which is only safe for writes from a single client
[05:39] <fwereade> axw, and that clientis the uniter
[05:39] <axw> fwereade: yeah, I modified to do be safe in that regard
[05:40] <axw> with a loop that checks for concurrent changes... but I hadn't considered units changing the address themselves
[05:40] <fwereade> axw, but even if that were fixed, the units (1) have to know what their addresses are and (2) have to be able to reject private addresses they don't like
[05:41] <fwereade> axw, and this only becomes more critical as we build up the networking model
[05:41] <fwereade> axw, (re (2): proxy charms)
[05:42] <axw> ok. I think I lack enough knowledge in this area that I'm going to be dangerous. I'm going to unassign myself for now
[05:42] <fwereade> axw, well, it demands care and forethought, but I wasn't trying to actively scare you off...
[05:42] <axw> I will keep looking at it, I just don't want anyone to get their hopes up :)
[05:42] <fwereade> axw, remind me about what you did to settings?
[05:43] <fwereade> niemeyer, morning, welcome to malta, sorry I haven't said hi before now
[05:43] <niemeyer> fwereade: Heya, thanks!
[05:44] <axw> fwereade: nothing in the tree yet. I made a RelationUnit.UpdateSettings method; extracted the operation building from Settings.Write (into WriteOps), and had UpdateSettings do that with a assertUnchanged in a loop
[05:44] <jimmiebtlr> should lbox propose should create a code review on rietveld?
[05:45] <axw> jimmiebtlr: yes, that's its purpose
[05:45] <jimmiebtlr> ok, I got the error "User does not have sufficient permissions to edit the bug task milestone." and no prompt for credentials for it
[05:46] <fwereade> axw, ah, excellent -- there are other problems with settings, too, and if we can find an excuse to address them we should do so (because at last, with the db not exposed, we can do so sanely)
[05:46] <axw> jimmiebtlr: try without -bug
[05:46] <jimmiebtlr> ok
[05:47] <fwereade> axw, are you free for a hangout in a few minutes?
[05:47] <axw> fwereade: sure, let me just make a cup of tea
[05:51] <jimmiebtlr> axw:  That did it, thanks
[05:53] <axw> jimmiebtlr: no worries. if you go to the bug, you can associate the branch manually (top right, "Link to a related branch")
[05:53] <axw> fwereade: ready when you are, shall I start one?
[05:54] <fwereade> axw, please
[05:55] <davecheney> jimmiebtlr: how come your merge proposals don't have code review links ?
[05:57] <jimmiebtlr> When I do propose with -bug set, it gives permissions error and never seems to make it to the rietveld creation
[05:58] <jimmiebtlr> I think I have to first do it without setting bug, then go into launchpad and set it through the gui.
[05:58] <jimmiebtlr> Sorry about the number of emails, trying to figure the tools out
[06:17] <jcw4> fwereade: https://codereview.appspot.com/92630043/ -- updated to address your feedback
[06:17] <jcw4> fwereade: should I lbox propose again, or wait til you've reviewed the code?
[06:20] <jcw4> fwereade: I suppose I have to lbox propose again to pick up the newly edited changes...
[06:20] <fwereade> jcw4, lbox propose again please
[06:21] <jcw4> fwereade: incoming....
[06:27]  * jcw4 is EOD... cya later
[06:42] <jam1> fwereade: I've put together a patch to change Login to accept and return EnvironTags, and to have those values saved in the cache and passed in on demand.
[06:42] <jam1> It does not do it with a v2 of the Login api
[06:42] <jam1> because I haven't gotten to the client side of that stuff yet, and because my other stuff hasn't landed anyway.
[06:42] <jam1> You're welcome to say "I only want this in a v2" and it goes into WIP until I can do it.
[06:43] <jam1> but I figure the code as it stands is reasonable to review.
[06:44] <fwereade> jam1, cheers
[06:49] <jam1> fwereade: https://codereview.appspot.com/101760046
[06:51] <fwereade> jcw4, btw, if you have draft comments waiting when you lbox propose again, it will publish them alongside the PTAL message
[06:56] <jam1> fwereade: so the post is up, an email sent to the CI guys, and I'm off for about 2 hours to go be entertained by what my son is doing in school. bbiab
[06:56] <fwereade> jam1, take care, have fun
[08:14] <voidspace> morning all
[08:15] <fwereade> voidspace, heyhey
[08:33] <jam1> fwereade: thanks for the review
[08:34] <jam1> fwereade: one other thing I wanted to run by you, while working on this, I discovered that only JujuConnSuite and cmd-restore use NewAPIConn, and I'd like to kill it with fire
[08:34] <jam1> it is the one that returns a Conn that has both a State and an Environ
[08:34] <jam1> but nobody actually needs that, and JujuConnSuite does bad things with it.
[08:35] <jam1> (JujuConnSuite.APIInfo() is implemented in terms of APIConn.Environ.StateInfo(), for examples of bad behavior)
[08:46] <fwereade> jam1, awesome! has long been an ambition of mine, glad we're at the point we can do it
[08:46] <fwereade> jam1, +100
[08:47] <jam1> great, I thought you felt that way, and it got in the way of something I wanted to do :)
[09:03] <fwereade> jam1, https://codereview.appspot.com/100460045/ LGTM
[09:03] <jam1> fwereade: thanks for getting to it, I know its a bit big
[09:04] <fwereade> jam1, np; need to pop out for a while myself; would you take a look at casey's https://codereview.appspot.com/100400043/ if you get a moment please? I feel like I've lost perspective on it
[09:04] <jam1> k
[09:33] <axw> fwereade: sorry, won't be able to chat about relation address things again today. Tomorrow hopefully, if that suits you
[09:34]  * axw bbl
[09:34] <voidspace> so bzr blame says the code I'm interesting in was committed by Andrew in revision 2636
[09:34] <voidspace> but launchpad (juju-core) says that revision 2636 was by nate and doesn't contain this code
[09:35] <voidspace> will bzr blame give the revision from the "original branch" rather than the revision it was merged onto trunk?
[09:35] <mgz> voidspace: are you sure it's not 2636.something.something?
[09:35] <voidspace> mgz: it's 2636.4.2
[09:36] <voidspace> mgz: what does the 4.2 indicate?
[09:37] <voidspace> mgz: "bzr help blame" says "revision, author and date"
[09:37] <mgz> okay, so then what you want is `bzr log -c mainline:2636.4.2`
[09:37] <voidspace> mgz: ah, cool
[09:37] <voidspace> mgz: thanks
[09:37] <voidspace> that tells me what I need
[09:37] <mgz> the dotted revnos are changes off the mainline, (Andrew started from Nate's revision)
[09:37] <voidspace> mgz: ah
[09:39] <voidspace> now I need to see if I can find the original MP on launchpad, and any tickets closed as a result
[09:39] <voidspace> but the commit message from "bzr log" has a link to the CL, which is handy
[09:39] <mgz> voidspace: should be linked from the... right
[09:40] <voidspace> the CL has a link to the MP
[09:40] <voidspace> gets me a step closer :-)
[09:42] <voidspace> fwereade: I tested the "immutable syslog port" with local provider and it works fine
[09:43] <voidspace> fwereade: running a test against a canonistack HA deployment before I merge, just for sanity
[09:48] <voidspace> wallyworld_: ping, you still around?
[10:03] <bloodearnest> heya all, anyone got any more details on LP #1307434 ? We're hitting the same issue using mgo in a different project
[10:03] <_mup_> Bug #1307434: talking to mongo can fail with "TCP i/o timeout" <cloud-installer> <performance> <juju-core:Triaged> <https://launchpad.net/bugs/1307434>
[10:08] <wallyworld_> voidspace: i'm here, but eating dinner, can ping you soon
[10:11] <rogpeppe> jam: ping
[10:11] <jam1> rogpeppe: pong
[10:11] <voidspace> wallyworld_: cool, thanks :-)
[10:12] <rogpeppe> jam1: i was just looking at this https://codereview.appspot.com/101760046/ and a slightly different approach occurred to me, which i thought i might run by you
[10:14] <rogpeppe> jam: because i've been thinking about multi-tenant state servers
[10:15] <rogpeppe> jam1: specifically, i was wondering about, rather than specifying the environment in login, we could specify it in the URL for the API
[10:15] <jam1> so we could, but we don't currently connect to a URL in as many letters. The information we store is a host:port combination, which we turn into a URL
[10:15] <jam1> so yes, with a but
[10:16] <rogpeppe> jam1: that means that *all* the URLs for an environment (including charm putting, logs, etc) can be accessed with respect to an environment
[10:16] <rogpeppe> jam1: yeah, you'd need to know the environment uuid when you call api.Open
[10:17] <rogpeppe> jam1: but you probably want that anyway (because nothing much calls Login explicitly)
[10:17] <jam1> which I am migrating towards, but all existing .jenv files, etc don't know the UUID
[10:17] <jam1> so I think at the least we still need to get that data into the files
[10:18] <rogpeppe> jam1: you're migrating towards calling Login explicitly?
[10:19] <jam1> no, towards passing EnvironTag/UUID into api.Open via the api.Info struct
[10:19] <rogpeppe> jam1: that sounds great
[10:19] <rogpeppe> jam1: i guess the question is just what happens under the hood in api.Open
[10:20] <jam1> *today* it is easier to do it compatibly via Login, if only because I've already written that code :)
[10:20] <jam1> but also, changing all the URLs we use is going to involve a whole different layer (the HTTP mux)
[10:21] <rogpeppe> jam1: yeah, it will (but it's work we do want to do some time anyway)
[10:21] <jam1> but I also think what I've done doesn't preclude us from doing that in the future.
[10:21] <rogpeppe> jam1: i guess it doesn't matter if we pass the UUID in Login too
[10:21] <rogpeppe> jam1: when the UUID is in the url, it will just be a tiny bit of extra validation
[10:23] <rogpeppe> jam1: i guess if we're explicit that the UUID in Login is *only* for validation, not for selection, then we'll be ok for backward compatibility too
[10:25] <rogpeppe> jam1: BTW, do we now generate the UUID and store it in the .jenv file at bootstrap time?
[10:25] <jam1> not yet
[10:27] <wallyworld_> voidspace: back now. late dinner tonight after soccer. what can i do you for?
[10:30] <mgz> wallyworld_: hi!
[10:30] <wallyworld_> heya
[10:30] <voidspace> wallyworld_: hey
[10:30] <voidspace> wallyworld_: so I'd like to re-enable mongo replica sets for local provider
[10:30] <wallyworld_> great :-)
[10:31] <voidspace> wallyworld_: apparently there was a problem with them previously, which I'm led to believe you reported
[10:31] <wallyworld_> i can test since it broke for me
[10:31] <voidspace> wallyworld_: I'm struggling to find the issue though
[10:31] <wallyworld_> but
[10:31] <voidspace> we obviously need to work out why it was broken for you and fix it
[10:31] <wallyworld_> i upgraded my kernel today and that broke cgroups and hence local :-(
[10:31] <voidspace> hah
[10:31] <wallyworld_> i'll need to downgrade
[10:32] <voidspace> ouch
[10:32] <wallyworld_> it broke for me because mongo just didn't start
[10:32] <wallyworld_> can't recall the exact error
[10:32] <wallyworld_> but the upstart job failed to start mongo with --repl or whatever the ption was
[10:33] <wallyworld_> but i can just test it again to see if it works
[10:33] <wallyworld_> i think one other person also had the issue
[10:33] <wallyworld_> not sure who now
[10:34] <voidspace> wallyworld_: ok, thanks
[10:35] <wallyworld_> voidspace: i can do that tomorrow after i downgrade my kernel, is that ok?
[10:35] <voidspace> wallyworld_: I'll create a branch with HA always on (just delete the code that switches it off) and you can try it
[10:35] <voidspace> wallyworld_: tomorrow is fine, thanks
[10:35] <wallyworld_> i have some other stuff i need to try and get done tonight
[10:35] <voidspace> cool
[10:35] <wallyworld_> i'll let you know how i go
[10:38] <voidspace> wallyworld_: I'll push a branch and email you a link
[10:39] <voidspace> wallyworld_: tomorrow is fine
[10:39] <wallyworld_> ok
[10:39] <wallyworld_> ta
[10:49] <dimitern> jam1, fwereade, standup?
[10:50] <jam1> dimitern: sorry about that, brt
[10:51] <wwitzel3> hello
[10:51] <wwitzel3> need a reboot, brb
[10:52] <fwereade> dimitern, with you in a mo
[10:52] <fwereade> dimitern, don't wait
[10:54] <wallyworld_> mgz: how's the github stuff? did you get to talk to rick or you don't need to now?
[10:55] <mgz> wallyworld_: I didn't need anything from him yesterday, will probably bug both him and curtis today about the remaining small things
[10:55] <wallyworld_> ok
[10:56] <wallyworld_> mgz: if you talk to curtis make sure he is ok with the timeframe or else we'll need to delay
[10:56] <mgz> yeah
[11:00] <wallyworld_> mgz: you on track to get the contributing doc finished up today (with everything else you have to do)?
[11:00] <mgz> yup
[11:00] <wallyworld_> great :-)
[11:00] <mgz> thanks for the comments from you and andrew
[11:00] <wallyworld_> np, hope they helped
[11:01] <wallyworld_> i'd like to email it out soon so will do so when you finalise it
[11:05] <perrito666> morning
[11:09] <wwitzel3> perrito666: morning
[11:09] <voidspace> perrito666: morning
[11:09] <voidspace> wwitzel3: morning
[11:47] <dimitern> fwereade, jam1, vladk - the goamz branch I'd love a review on https://codereview.appspot.com/100780048
[12:08] <voidspace> right, lunch time
[12:08]  * voidspace lurches
[12:09] <perrito666> voidspace: uh, thats true, medicine time, bbl
[12:24] <fwereade> jam1, replied to bug instead of you, sorry
[12:27] <dimitern> niemeyer, hey
[12:27] <niemeyer> dimitern: Heya
[12:27] <dimitern> niemeyer, I have another small goamz branch, if you can take a look https://codereview.appspot.com/100780048
[12:28] <niemeyer> fwereade: When are you coming?
[12:28] <niemeyer> dimitern: Cool
[12:28] <fwereade> niemeyer, heh, haven't really figured it out yet -- I was thinking mid-afternoon on wed, thu, or fri would be pretty convenient, though, because I can get a lift most of the way there
[12:29] <fwereade> niemeyer, do you have something particular in mind that I should be at?
[12:29] <fwereade> niemeyer, because, you know, there's nothing stopping me at any other time
[12:29] <fwereade> niemeyer, (well, I have a washing machine being delivered in a couple of hours, so today ain't great, but still)
[12:30] <niemeyer> fwereade: Nope, nothing specific.. might just be nice to take the chance that 100+ co-workers are around to interact a bit
[12:31] <fwereade> niemeyer, yeah, I just don't want to show up and end up hanging around being useless ;)
[12:32] <fwereade> niemeyer, I'd been thinking at least that I could come down and see some people in the evening one (more?) of those days
[12:32] <perrito666> niemeyer: well you are trying to make a geek choose between a new gadget and 100+ people... that is unfair
[12:32] <fwereade> niemeyer, how are your plans looking?
[12:32] <niemeyer> fwereade: I would take the chance to be here most of the time, to be honest, even if you're just working on your usual tasks during meetings
[12:33] <niemeyer> fwereade: There's open space to hack, and just being around to talk to people over breaks is worth it
[12:33] <niemeyer> fwereade: That's how I would feel if people would so close to me, either way.. :)
[12:33] <niemeyer> s/would so/were so/
[12:34] <fwereade> niemeyer, that's very true, I guess I'd kinda assumed that hacking space might not be so available
[12:38] <hazmat> mgz, re gh please don't transfer history how gui did it (squashing branch commits into mainline history)
[12:39] <mgz> hazmat: yeah, we'll keep all the commits, even though git doesn't handle them quite as neatly
[12:40] <hazmat> mgz, well more to the point.. goal would be not polluting main branch history with every branch's individual commit as linear line.
[12:41] <hazmat> which is what gui ended up doing
[12:41] <mgz> hazmat: ...that sounds like the opposite of what I understood your first comment as
[12:42] <hazmat> mgz, squashing was a bad word choice, s/polluting would have been better
[12:43] <hazmat> mgz, ie. doing a git log on trunk should see merge commit messages, not every branches individual commit messages.l
[12:43] <mgz> hazmat: it may be something to raise on the mailing list then, the current planned import does no squashing
[12:46] <hazmat> mgz, hmm.. actually i think i might be off track here.. git log --oneline --graph shows what i would expect, just the default git log shows minor commits on feature branches by default
[12:46] <hazmat> yeah.. git log --oneline --first-parent is the equivalent of bzr log
[12:46] <hazmat> er. bzr log --line
[12:47] <mgz> yeah, it's an issue with the git tooling
[12:47] <mgz> git itself does the dag okay
[12:56] <jam> dimitern: https://codereview.appspot.com/100780048/ reviewed
[12:57] <jam> mgz: just that most git tools think first parent isn't relevant and sort by sha1 for ordering rather than the actual recorded merge parent ordering.
[13:09] <dimitern> jam, thanks!
[13:36] <dimitern> niemeyer, I've updated the branch after fwereade and jam reviewed it, I just need your review :) https://codereview.appspot.com/100780048/
[13:37] <niemeyer> dimitern: Okay, I cannot promise to be timely there
[13:37] <dimitern> niemeyer, ok, when you can, thanks
[13:38] <niemeyer> dimitern: Or just go ahead and merge it.. I trust John and William
[13:41] <dimitern> niemeyer, thanks!
[13:42] <dimitern> niemeyer, it's just for testing, no public-facing logic has changed
[13:43] <niemeyer> dimitern: Super, thank you
[13:45] <jam> dimitern: I think you can simplify the "known" changes if you go back to a bool map.
[13:45] <jam> since you can just do && idMap[id]
[13:45] <jam> sort of stuff
[13:45] <alexisb> welcome gsamfira !
[13:46] <gsamfira> hey alexisb :)
[13:46] <dimitern> jam, oh, sorry I forgot about this
[13:47] <dimitern> jam, but I'll fix it next time i need to make changes, it's not a big deal
[13:54] <jam1> cmars: I reviewed https://codereview.appspot.com/100400043/
[13:58] <wwitzel3> perrito666: where'd you go? :)
[13:58] <cmars> thanks jam1. I've also become concerned over compatibility issues with clients -- including older juju clients. Having second thoughts about making ecdsa the default.
[13:58] <jam> cmars: for juju clients, we only really need to be compat with 1.18
[13:59] <cmars> jam1, i'm considering leaving the support for switching to ecdsa in this proposal, issuing separate certs for the state server & mongo, but leaving the default RSA
[13:59] <jam> cmars: I really like the idea of splitting out the certs, as sharing the certs has always bothered me
[14:00] <jcw4> fwereade: "Checking the logs would be ideal" ... how does one check the logs in a test?
[14:01] <jam> jcw4: you can look for test that use LogMatches
[14:01] <jcw4> jam: tx!
[14:05] <jcastro> http://askubuntu.com/questions/472849/destroy-a-juju-service-and-also-its-associated-machine
[14:05] <jcastro> would it be a good idea to have a --destroy-the-machine-too flag for destroy-service?
[14:06] <fwereade> jcastro, it surely would, even as default behaviour, but I can't remember whether we have it scheduled for this cycle
[14:06] <jcastro> yeah I remember talking about it
[14:06] <fwereade> jam, do you recall what heading we had it under?
[14:06] <jcastro> should I file a bug?
[14:06] <fwereade> jam, I have a feeling it might be one of the tanzanite ones
[14:06] <fwereade> jcastro, if you can't find one, yeah, go for it
[14:08] <jcastro> https://bugs.launchpad.net/juju-core/+bug/1299034
[14:08] <_mup_> Bug #1299034: garbage collect/remove destroyed service machines by default <destroy-service> <improvement> <juju-core:Triaged> <https://launchpad.net/bugs/1299034>
[14:23] <perrito666> natefinch: wwitzel3 voidspace heh, sorry that seemed easier to explain on code that over the phone :)
[14:25] <perrito666> and in that process I found out the solution, :)
[14:25] <natefinch> awesome
[14:25] <perrito666> happens, I usually explain things to my dog to do this
[14:26] <perrito666> but he rarely answers
[15:04] <natefinch> fwereade: you around for the ensure availability talk?
[15:06] <voidspace> gah, "syslog immutable" branch test failures
[15:06] <voidspace> one spurious, one at least looks genuine
[15:06] <voidspace> re-running locally
[15:06] <voidspace> just one
[15:06] <voidspace> I really thought I'd run all tests
[15:06] <voidspace> *sigh*
[15:08] <fwereade> natefinch, tasdomas: sorry, drama, guys came t deliver washing machine, decided to try to do it from the road without a permit, much excitement
[15:09] <fwereade> natefinch, tasdomas: joining
[15:28] <victor13> hola jodedores
[15:34] <perrito666> now that was a bit rude
[15:34] <perrito666> and poorly translated
[15:45] <natefinch> perrito666: what is jodedores?
[15:45] <natefinch> google translate is failing
[15:45] <perrito666> a rather literal translation of f****ers
[15:45] <natefinch> haha
[16:23] <voidspace> juju seems to have got itself into a tizzy and I can't use the local provider
[16:23] <voidspace> "ERROR cannot use 37017 as state port, already in use"
[16:23] <voidspace> netstat doesn't show anything using that port though
[16:23] <voidspace> rebooting to fix...
[16:27] <voidspace> yay that seems to have fixed it
[16:28] <natefinch> voidspace: yeah, that happens to me once in a while
[16:28] <voidspace> heh
[16:41] <voidspace> natefinch: making syslog-port immutable has landed (I had to fix a failing test first)
[16:41] <voidspace> natefinch: and I've created a branch with replica set enable for local provider, for wallyworld_ to try out
[16:41] <voidspace> natefinch: so next is looking at replica sets for tests
[16:42] <voidspace> natefinch: you said there was *one place* to make the change, can you easily find out where that is or should I go spelunking?
[16:46] <voidspace> natefinch: MgoInstance run method presumably
[16:47] <voidspace> which is what starts mongo for the MgoSuite
[16:50] <voidspace> hmmm... just adding "--replSet juju" is not looking *too* promising
[16:50] <voidspace> tests appear to have hung
[16:51] <voidspace> we'll see if they timeout in ten minutes (did we ever change that timeout?)
[16:51] <voidspace> Panic: no reachable servers
[16:51] <voidspace> *sigh*
[16:52] <voidspace> two minute timeout
[16:52] <voidspace> for two failures
[16:52] <voidspace> so maybe one minute
[16:52] <voidspace> 23 passed though
[17:59] <jcw4> fwereade: https://codereview.appspot.com/92630043/
[18:00] <jcw4> mgz: I should be pinging you on these too right? ^^
[18:21] <sinzui> natefinch, do you have a minute to review https://codereview.appspot.com/98630044
[18:23] <sinzui> ^ perrito666
[18:50] <sebas5384> hey! :)
[18:51] <sebas5384> there's any plans for hardware constraints work for juju-local (lxc) ?
[18:51] <sebas5384> since cgroups help you with that already
[18:52] <natefinch> I'm not sure what you mean about hardware constraints on local.  Isn't it, by definition, always running on your local hardware?
[18:52] <natefinch> sinzui: I can review now
[18:53] <natefinch> heh, perrito666 beat me
[18:53] <sebas5384> natefinch: linux containers can be constrained, like cpu, mem, etc..
[18:53] <sebas5384> https://bugs.launchpad.net/juju-core/+bug/1242783
[18:53] <_mup_> Bug #1242783: containers should use constraints to configure cgroups/kvm values <constraints> <local-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1242783>
[18:53] <perrito666> natefinch: I am fast :p
[18:54] <natefinch> sebas5384: ahh, hmm, interesting... that never occurred to me
[18:54] <sebas5384> natefinch: that feature would be awesome!
[18:54] <sebas5384> :)
[18:55] <natefinch> sebas5384: juju is open source - write it ;)
[18:55] <sebas5384> since now we can deploy an ubuntu charm, or mysql, etc...
[18:55] <sebas5384> heheh http://sorisomail.com/img/127989758237.jpg
[18:56] <perrito666> natefinch: wanted to contribute something today before my cold kills me
[18:56] <sebas5384> natefinch: there's some guide to newbies to contribute?
[18:56] <sebas5384> i would like to at least see if I can contribute :P
[19:00] <natefinch> sebas5384: http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/CONTRIBUTING
[19:00] <natefinch> not really a newbie guide, just a guide.  We should probably work up something a little easier to swallow
[19:01] <perrito666> there are more specific docs in the /doc folder
[19:02] <sebas5384> natefinch: yeah that would be nice, thanks, i will read it :)
[19:20] <alexisb> natefinch, ping
[19:24] <natefinch> alexisb: hey hey
[19:30] <alexisb> do you remember who on the core team was assigned to shadow hazmat in the TOSCA effort?
[19:30] <alexisb> was it you?
[19:30] <alexisb> natefinch, ^^^
[19:30] <natefinch> alexisb: I remember, it was me :)
[19:31] <alexisb> ok I am going invite you to tomorrow morning call evne though I think it is a bad time for you
[19:32] <natefinch> alexisb: ok
[19:38] <jcw4> sebas5384: feel free to ping bodie_ or I with questions too.. we recently started contributing so we may have some fresh memories of any issues
[19:38] <natefinch> jcw4: thanks, that's a huge help... for people who have been doing this for a long time, we may have forgotten a lot of the setup steps we now take for granted
[19:39] <natefinch> alexisb: I guess I'll go read up on TOSCA then ;)
[19:39] <jcw4> the *right* thing to do would be to capture each question we get and make an FAQ
[19:41] <natefinch> jcw4: make FAQ.txt and slap it in the /doc directory, or even in the root directory for that matter.
[19:41] <jcw4> natefinch: will do
[19:42] <natefinch> jcw4: put it in the root directory, then make the first FAQ "where is the dev documentation?" and point to CONTRIBUTING and /doc  :)
[19:42] <jcw4> natefinch: lol!
[19:42] <jcw4> natefinch: +1
[19:42] <jcw4> okay sebas5384 ... I'm ready for the questions.. :)
[19:43] <sebas5384> nice!!! jcw4 thank you!
[19:43] <jcw4> sebas5384: :)
[19:43] <sebas5384> jcw4: I started a recognition field to work in the bug
[19:43] <sebas5384> http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/provider/local/environ.go#L314
[19:43] <sebas5384> so i found this already
[19:46] <perrito666> rogpeppe: are you around by any chance?
[19:46] <jcw4> sebas5384: looks like constraints for lcx containers are lower priority now though (well medium instead of high)
[19:46] <sebas5384> yeah jcw4 but i'm planning to use it
[19:47] <sebas5384> because i'm going with lxc containers way :)
[19:47] <jcw4> sebas5384: cool, I'm interested to see how that goes
[19:47] <sebas5384> yeah! and will be my first contribute :)
[19:48] <sebas5384> jcw4: whats your environment for developing?
[19:48] <jcw4> trusty
[19:48] <jcw4> vim
[19:48] <sebas5384> bzr hehe
[19:48] <sebas5384> never used
[19:49] <jcw4> sebas5384: apparrently if you wait a week you'll be able to use git
[19:49] <jcw4> sebas5384: when I started I was gung-ho to move to github (still favour that)
[19:49] <sebas5384> they are going to move to git?
[19:49] <jcw4> sebas5384: but I've gotten to like some things about bzr and especially lbox
[19:49] <jcw4> sebas5384: I believe so
[19:50] <sebas5384> jcw4: sweet!
[19:50] <natefinch> yep... moving to github thursday evening, I believe
[19:50] <sebas5384> yeah i imagine, every tool have's some features that the other one doesn't
[19:50] <sebas5384> yeah!! \o/
[19:50] <sebas5384> thats nice
[19:50] <jcw4> https://lists.ubuntu.com/archives/juju-dev/2014-May/002459.html
[19:50] <sebas5384> juju-gui is over there already
[19:51] <jcw4> sebas5384: natefinch next FAQ : mailing lists...
[19:51] <jcw4> Although that's in CONTRIBUTING already I think
[19:52] <jcw4> nope...
[19:52] <sebas5384> didn't see about that
[19:52]  * jcw4 rubs his hands and chuckles... 
[19:53] <sebas5384> jcw4: i have to build a fresh install of trusty in a vbox
[19:54] <sebas5384> using mac here :(
[19:54] <jcw4> I was able to do some things on a mac directly, but yeah ubuntu is certainly the main dev env
[19:56] <jcw4> sebas5384: if you don't mind paying a little bit, digital ocean has decent prices on vm's, and I was doing quite well on an AWS $100/month vm
[19:57] <jcw4> sebas5384: but I ended up paving over a laptop of mine with Trusty
[20:05] <hazmat> natefinch, ping if you have questions re tosca.. i'm diving back in myself..
[20:07] <natefinch> hazmat: thanks.  I looked at the website for like a minute last time, so... basically just need to read more in-depth
[20:09] <natefinch> sebas5384: the tests are kind of the major problem with developing on a mac.  most will run, but I'm sure a bunch will fail.  And definitely the local provider won't work on OSX
[20:11] <perrito666> sebas5384: well, excepting for the compile time, which can be a bit dense, working on a VM works quite well in mac
[20:12] <hazmat> natefinch, you want this https://www.oasis-open.org/committees/download.php/52954/TOSCA-Simple-Profile-YAML-v1.0-wd02-Rev-05.docx
[20:12] <hazmat> natefinch, just go to the docs section from the home page.. https://www.oasis-open.org/committees/documents.php?wg_abbrev=tosca
[20:13]  * perrito666 did the smallest change and broke a lot... such is my luck
[20:13] <sebas5384> perrito666: yeah! i will bootup a vbox with vagrant
[20:13] <sinzui> natefinch, is the landing bot ill?
[20:13] <sebas5384> i'm doing that right now
[20:15] <natefinch> sinzui: uh, no idea
[20:16] <natefinch>  hazmat thanks
[20:16] <hazmat> natefinch, how's your python?
[20:18] <hazmat> natefinch, most of the code for this (and all of ostack bits) is in python.. there are two repos of interest
[20:19] <natefinch> hazmat: my python is ok.  I'm a little rusty, and never wrote a ton of it, but it's generally pretty easy to read as long as they're not trying to be too crazy
[20:19] <hazmat> my take on the spec is https://github.com/kapilt/juju-tosca  its doing some auto gen of types/classes.  some of the other tosca guys have been working on this https://github.com/spzala/heat-translator
[20:25] <jcw4> natefinch: FAQ: https://codereview.appspot.com/98650043
[20:25] <natefinch> I love that the name of the thing is "OASIS Tosca YAML Simple Profile 1.0"
[20:25] <natefinch> it sounds so.... Standards-y
[20:26] <jcw4> especially the word Simple in a six word title
[20:26] <natefinch> Right?  Especially because Tosca is an acronym already
[20:26] <natefinch> OASIS Topology and Orchestration Specification for Cloud Applications YAML Simple Profile 1.0
[20:27] <jcw4> haha, and OASIS too presumably?
[20:27] <jcw4> and YAML
[20:28] <natefinch> Organization for the Advancement of Structured Information Standards
[20:28] <alexisb> alrighty all I am off for the afternoon doing community work, be back online later this evening to check in
[20:28] <natefinch> alexisb: have fun
[20:34]  * jcw4 leaves for a couple hours
[20:53] <bodie_> jcw4, you around?
[20:54] <bodie_> if you're not too busy, I could use a second brain for a minute
[20:56] <natefinch> does that work? 'Cause I need a second brain like... always
[20:57] <perrito666> natefinch: sure, amazon ech
[20:57] <perrito666> you just add more brains
[20:57] <bodie_> it's kind of like networked storage
[20:58] <bodie_> you need good protocols and error handling
[20:58] <bodie_> you can usually assume things might not make their way from sender to receiver in one piece
[20:58] <bodie_> etc
[20:58] <natefinch> heh
[21:01] <sebas5384> hehe
[21:01] <sebas5384> BOA - brain oriented architecture
[21:01] <sebas5384> and like always, as a service ... xD
[21:05] <perrito666> the usage of addr:port as a str instead of stored as two separated entities has made my life difficult many times these days
[21:07] <waigani> fwereade: --define ?
[21:08] <perrito666> sweet, fwereade now accepts flags?
[21:08] <waigani> lol
[21:08] <waigani> I wonder what the output would be
[21:12] <bodie_> fwereade --help
[21:12] <bodie_> lol
[21:19] <menn0> I think he also takes --review and --architect-something
[21:20] <bodie_> heh
[21:27] <wallyworld_> sinzui: hi, did you have time for a quick catchup?
[21:27] <sinzui> I do
[21:27] <wallyworld_> i'll start a hangout
[21:28] <wallyworld_> https://plus.google.com/hangouts/_/gwsrc7uen7yzc2m4y5nxqxyhnea?hl=en
[21:30] <thumper> morning folks
[21:39] <thumper> sinzui: morning
[21:41] <sinzui> hi thumper. my fix for the win installer is playing now. I hope to see a pass for all juju http://juju-ci.vapour.ws:8080/
[21:41] <thumper> sinzui: so we are good?
[21:41] <thumper> sinzui: I also sent a reply to the list
[21:42] <thumper> sinzui: and then noticed that you had already committed a fix for the win installer
[21:42] <sinzui> thumper, probably. Everything That needed to know about the version appears to. I just need to see a pass for everything
[21:42] <thumper> sinzui: I think we should have a note in the version.go file to say "if you change this, please remember the windows installer file"
[21:42] <sinzui> thumper, or a test.
[21:42] <thumper> a test would be good
[21:43] <sinzui> I learned from natefinch that updating one always mean updating the other :). my first two releases  failed bcaue of that
[21:49] <mfoord> signing off (not been here for a while but forget to say goodnight)
[21:49] <mfoord> so goodnight...
[21:53] <fwereade> waigani, thumper, hey, I'm here for a bit
[21:53] <waigani> fwereade: hello
[21:53] <fwereade> waigani, thumper, have I been telling you to do stupid things?
[21:53] <waigani> fwereade: I was wondering what you thought of $ juju switch --define
[21:54] <thumper> fwereade: I have 7 minutes before my call with cmars
[21:54] <thumper> fwereade: can we hangout?
[21:54] <fwereade> waigani, ah-- hmm, I'm not sure anyone's *defining* anything
[21:54] <fwereade> thumper, sure
[21:54] <waigani> fwereade: okay, worth a shot
[21:54] <thumper> --define?
[21:55] <waigani> thumper: fwereade does not like --env-info
[21:55] <thumper> what's --env-info?
[21:55] <waigani> the flag to dump all the info on the environ
[21:55] <waigani> $ juju switch --env-info
[21:56] <waigani> then it gives you user, endpoints etc
[21:56] <waigani> its all in my branch
[21:56] <waigani> ANYWAY
[21:56] <waigani> just looking for a better name
[21:58] <sinzui> thumper, juju doesn't support -beta1 Every deploy tests fails
[21:58] <sinzui> http://juju-ci.vapour.ws:8080/job/aws-deploy/1244/console
[21:58] <sinzui> ^ one example
[21:58] <thumper> what?
[21:59]  * thumper looks
[21:59]  * thumper wonders why tests didn't catch this
[22:00] <thumper> sinzui: shall we roll back the version stuff? and I'll take more of a look at it when I have some time
[22:00] <sinzui> thumper, might be best if you don't see an obvious fix
[22:01] <thumper> sinzui: I don't have an obvious fix
[22:01] <thumper> I say rollback
[22:01] <sinzui> thumper, hold
[22:02] <sinzui> thumper, in that log, the actual failure is 1.18 attempting to destroy the an env
[22:03] <sinzui> thumper, never mind. that succeed, as did the proper clean up 1.20-beta1 cannot bootstrap itself from stream
[22:03] <sinzui> thumper, lets roll back
[22:03] <sinzui> This will be a test that my changes properly support the old version
[22:06] <thumper> cmars: around?
[22:07] <cmars> thumper, hey
[22:07] <cmars> thumper, i'm in the hangout
[22:08] <thumper> coming
[22:08] <thumper> cmars: I can hear you
[22:08] <thumper> volume up?\
[23:28] <waigani> davecheney, thumper: menn0 and I did our stand-up. So the next call can just focus on tags discussion if you like.
[23:28] <davecheney> waigani: cool
[23:28]  * davecheney has many comments
[23:49] <waigani> menn0: can you send me that email please?
[23:52] <menn0> waigani: done
[23:52] <waigani> menn0: thank you :)