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