[00:03] <davecheney> thumper: sure, wallyworld and I want to always include the tools in the deb
[00:03] <ahasenack> do the relation-list and relation-ids commands trigger a network call? Or does the unit have that information already locally?
[00:03] <davecheney> so every bootstrap is essentially upload tools
[00:03] <thumper> davecheney: well, jujud is in the deb
[00:04] <thumper> I checked
[00:04] <thumper> davecheney: I think I may do this in parts
[00:05] <davecheney> wallyworld: and I want to kill the idea of a public bucket
[00:05] <thumper> davecheney: effectively do the local provider this was, and we can test out the idea
[00:05]  * thumper nods
[00:05] <davecheney> thumper: you're the boss (literally)
[00:05] <thumper> davecheney: however it means uploading 12 meg every time you want to start a new juju environent
[00:06] <thumper> davecheney: speaking of boss-like things, how about we schedule a regular weekly meeting?
[00:09] <davecheney> 1, it's not 12mb
[00:09] <davecheney> its 4 at most
[00:10] <davecheney> 2, it's only when we bootstrap an envrionment
[00:10] <ahasenack> and juju upgrade-juju
[00:16] <davecheney> i don't careif upload tools is the size of the raring iso
[00:16] <davecheney> it's not a common operation
[00:31] <thumper> heh
[00:32] <thumper> well jujud is 14meg on my machine, not looked at a gzip version though
[00:32] <davecheney> thumper: upload tools says its ~ 4mb last time I looked
[00:33] <davecheney> but my point stands, i don't care how large it is
[00:33] <davecheney> it is not a common opeation
[01:04]  * thumper breaks up some of the local provider work into bits for review
[01:04]  * thumper is listening to Vilify by Device, very catchy
[02:18] <davecheney> has anyone tried to run the goamz/s3 tests recently ?
[02:25] <davecheney> thumper: aaah, http://paste.ubuntu.com/5845459/
[02:25] <davecheney> ^ this is what happens on go 1.0.2-2 (raring)
[02:26] <thumper> oh?
[02:26] <thumper> no, not tried it
[02:52] <davecheney> will fail on raring
[02:52] <davecheney> will pass on go 1.1+
[02:52] <davecheney> i've been trying to hack around the 1.0.2 http problems
[02:52] <davecheney> and I've chased it this far
[02:54] <davecheney> https://bugs.launchpad.net/goamz/+bug/1189873
[02:54] <_mup_> Bug #1189873: Tests fail on tip <goamz:New> <https://launchpad.net/bugs/1189873>
[02:55] <davecheney> ^ mis reported
[03:12] <thumper> well, that is frustrating
[03:12] <thumper> was hoping for a clever way to wrap code in a test
[03:12] <thumper> but reflect pancis
[03:12] <thumper> saying unexported function called
[03:12] <thumper> which is right
[03:13] <thumper> but I was hoping for testing ...
[03:47] <thumper> davecheney: thanks for the ParseCIDR
[03:48] <thumper> I missed that when reading the docs
[03:50] <davecheney> thumper: np, i had to read them like 3 times to find the bugger
[03:50] <davecheney> i knew it was in there because we use something similar in the go.net/ipv{4,6} packages
[03:50] <davecheney> otherewise LGTM
[03:52]  * thumper goes to make a coffee
[04:32] <Guest68473> fark
[04:36]  * thumper tries to work out why I'm failing at creating test directories
[07:35] <fwereade> jam, fwiw, "watch calls next" should be true
[07:35] <fwereade> jam, unless you can think of a reason not to do it that way?
[07:36] <fwereade> jam, well, not exactly
[07:36] <fwereade> jam, but "watch result includes first event" should certainly be true
[07:36] <fwereade> jam, and hence out should start off switched on, to correspond with that event
[08:22] <jam> fwereade: the current code doesn't work like that. So it would be redoing all the watches that we have. The current work is Watch returns a watcher, which you call next on
[08:31] <TheMue> morning
[08:32] <TheMue> upgrading to 13.04 seems to be no good idea
[08:32] <TheMue> :(
[08:42] <fwereade> jam, ok, well, that sucks and wastes bandwidth
[08:42] <fwereade> jam, please ifx
[09:11] <jam> fwereade: so NotifyWatchResult should include the change? Or we know it is a no-op so we swallow the initial event and then trigger the initial event locally?
[09:13] <rvba> Hi guys, could I please get a second review of https://codereview.appspot.com/10959043/? (original MP, approved by Jeroen, is here: https://codereview.appspot.com/10957043/).
[10:24] <jam> rvba: commented https://codereview.appspot.com/10959043/
[10:24] <rvba> jam: ta
[10:51] <jam> fwereade: api-watchers has been updated for Machine.Watch(). It still asserts that we get 1 initial change, but the server side consumes the local one, and the client side produces its own.
[11:12] <jam> rvba: https://code.launchpad.net/~jameinel/juju-core/set-agent-version/+merge/173175 is pretty trivial if you are up for a quick review
[11:35] <rvba> jam: approved
[11:35] <jam> thx
[11:38] <jam> mgz: https://code.launchpad.net/~jameinel/juju-core/set-agent-version/+merge/173175 if you are around
[11:40] <jam> TheMue: ^^
[11:55] <TheMue> jam: you've got a +1
[13:43] <jamespage> mgz, those 1.1.1 package appear to be missing runtime/cgo
[13:49] <jamespage> hmm - the build does something different in PPA
[13:59] <mgz> jamespage: hmmm
[14:08] <Guest28536> freenode ate my nick
[14:31] <jamespage> mgz, its a problem with the cross compilation
[14:32] <jamespage> runtime/cgo.a only gets built on the 'native' platform I think
[14:32] <jamespage> so only i386 gets it
[14:32] <jamespage> bah
[14:32] <mgz> hm, so the repackaging is breaking us
[14:32] <jamespage> yep
[14:32] <jamespage> I'm looking now
[14:50] <jamespage> mgz, grrr
[14:51] <mgz> jamespage: how hard would it be to build 1.1.1 with pre-debian-changes packaging, that was used for 1.0?
[14:52] <mgz> seems otherwise we're somewhat dependent on either fixing ourselves or getting the debian maintainer to fix the build process
[14:56] <jamespage> mgz, I'll look
[14:59] <jamespage> mgz, blurg - I really hate this cross compile stuff its doing
[14:59] <jamespage> mgz, I think your plan is probably a good one
[15:01] <mgz> jamespage: looks like there's working 1.1 in testing? that also predates the cross compilation stuff right?
[15:01] <mgz> does the maintainer have his work in a branch anywhere? I wonder what the history of his changes is.
[15:03] <mgz> yup he does, will have a look as well.
[15:03] <jamespage> it does - the 1.1.1 is the latest
[15:03] <jamespage> 1.1-2 is the first one with the cross compile stuff
[15:04] <jamespage> mgz, sorry - I missed this because I locally built the package on amd64 including the arch all packages
[15:04]  * jamespage sighs
[15:04] <jamespage> let me see if I can pull together a 1.1.1 without cross compile
[15:04] <jamespage> I'll also raise a bug back to debian as well
[15:12] <jamespage> mgz, hold the line - I had an idea when submitting the bug report.
[15:13] <mgz> ooo :)
[15:13] <mgz> rvba: second lgtmed on your branch
[15:18] <rvba> mgz: third even 'caused Jeroen also reviewed it :)
[15:18] <rvba> 'cause*
[15:18] <rvba> mgz: ta
[16:08] <jamespage> mgz, can I suggest that you delete the packages from the PPA for the time being
[16:08] <jamespage> they are a load of fud right now
[16:28] <mgz> sure
[16:30] <mgz> done.
[16:32] <jamespage> mgz, OK - I have some new ones building that don't cross compile
[16:32] <jamespage> and I've reported back to debian
[17:04] <jamespage> mgz, all done - https://launchpad.net/~james-page/+archive/golang-backports/+packages
[17:06] <mgz> thanks james!
[17:06] <mgz> I'll copy those across.
[17:11] <jamespage> mgz, ack - lemme know how that works out for you
[19:28] <benji> bac: I'll do the second review for you.
[19:42] <benji> that was what I was going to suggest initially until I realized the pattern was repeated