=== imbrando1 is now known as imbrandon
[01:39] <thumper> davecheney: what would your recommendation be around wanting a max that works with ints?
[01:42] <davecheney> thumper: what is the question ?
[01:42] <thumper> davecheney: well, math.max works on float64
[01:42] <thumper> but I'm trying to find the longest int
[01:43] <davecheney> you'll find lots of
[01:43] <davecheney> func max(a, b int) int { if a > b { return a } return b } 's
[01:43] <davecheney> in the codebase
[01:43] <davecheney> that is the current standard
[01:48] <thumper> I just realized that codereview.appspot was sending email to my gmail account (that I don't actually read)
[01:48] <thumper> and I can't configure it to send email to my normal address
[01:49]  * thumper chalks up another mark against rietveld
[01:52] <thumper> davecheney: so why did your last comment not go to the merge proposal?
[01:52] <davecheney> thumper: i have no idea
[01:52] <davecheney> to be honest, when I joined, the attitude was to ignore the MP and use Rietveld
[01:52] <davecheney> the comment should arrive on the MP evnetually, it was cc'd on the review
[01:53] <davecheney> so you should have got the comments via the route of
[01:53] <davecheney> rietveld -> mp -> gophers group -> you
[01:59] <thumper> it is faster...
[01:59] <thumper> rietveld -> mp -> me (as I proposed the merge)
[01:59] <thumper> but it doesn't arrive on the mp
[01:59] <thumper> since I wrote all that email shit with abentley, I know how it works
[02:00] <thumper> oh I know what it is
[02:00] <thumper> the email address that it is coming from is not linked to any known launchpad user
[02:00] <thumper> so it drops them on the floor
[02:01] <thumper> since my gmail account isn't linked to my LP user, LP ignores all email from it
[02:01] <davecheney> bzzt
[02:01] <thumper> obviously roger has linked his gmail to LP user
[02:01] <thumper> his default email address for the LP user is his canonical one
[02:02] <thumper> which is what the outgoing MP email is sent as
[02:02] <davecheney> maybe, he was winging for months that he wasn't getting any updates
[02:02] <thumper> that is what it is
[02:02]  * thumper knows it
[02:02] <thumper> so what I have to do is to add my google mail address to LP
[02:02] <thumper> and so does every other user
[02:03] <thumper> which sounds crackful
[02:03] <thumper> would be better if rietveld would allow me to configure my email address
[02:04] <davecheney> hmm, that might be unpossible
[02:04] <davecheney> canonical.com is a gapps domain
[02:04] <davecheney> but the email portion is disabled
[02:05] <davecheney> to send/recieve as your canonical identity you would need a google identity on canonical.com
[02:05] <thumper> davecheney: OK, my question around this latest MP is that I have four different LGTM calls, but there is still a little contention around the init command AFAICS
[02:05] <davecheney> fuckem
[02:05] <davecheney> it's called source control
[02:05] <davecheney> you can always propose another change
[02:06] <thumper> heh
[02:07]  * thumper emails juju-dev with this email revalation
[02:08] <thumper> davecheney: so you reckon submit this alias branch for merging now?
[02:10] <davecheney> thumper: +1
[02:10] <thumper> kk
[02:10] <davecheney> what is the worse people can do ?
[02:10] <davecheney> they are miles away
[02:12] <thumper> well... from past experience, the worst they can do is revert the merge, and yell publicly on the mailing list at how shit you are
[02:12]  * thumper says mostly in jest
[02:12] <davecheney> you don't need to commit code for that
[02:12] <davecheney> :P
[02:13] <thumper> fucking conflicts...
[02:13]  * thumper fixes
[02:17]  * thumper goes to find his child
=== wedgwood_away is now known as wedgwood
[03:32]  * thumper is confused
[03:35] <thumper> davecheney: ping
[03:45] <davecheney> ack
[03:45] <davecheney> thumper: ack
[03:45] <thumper> davecheney: nm, found that go build doesn't report all the errors
[03:46] <thumper> which is why  I was confused
[03:46] <thumper> go test found them
[03:46] <davecheney> ok
[03:46] <davecheney> offline for 5-10 mins
[03:46] <davecheney> rebooting + MOAR RAM!
[04:09] <davecheney> mmm, 8gb
[04:09] <davecheney> i had forgotten that I had donated some to my other machine a while back
[04:09] <davecheney> and only remembereed that when the said donated ram failed
=== wedgwood is now known as wedgwood_away
[08:05] <TheMue> Morning
=== TheRealMue is now known as TheMue
[08:21] <fwereade> TheMue, morning
[09:51] <fwereade> TheMue, can you think of any reason we have the --upload-tools flag on bootstrap/upgrade, instead of just an upload-tools command that puts stuff into the appropriate "public-bucket" (wtf? why not "tools-bucket"?) for the environment?
[09:52] <TheMue> fwereade: First, yeah, tools-bucket is more clear than public bucket. +1 on that. ;)
[09:53] <fwereade> TheMue, do you recall anything else that it's used for?
[09:53] <TheMue> fwereade: I think the basic idea has been to upload the tools "on the fly", but I don't know if it's really better than having an explicit command for it.
[09:54] <TheMue> fwereade: Can't remember the discussion which led to this decision.
[09:54] <fwereade> TheMue, I think it's way back before I even started on go
[09:55] <TheMue> fwereade: Yip, it's in there for a long time. Is our IRC archive searchable?
[09:55] <fwereade> TheMue, I think it's just cargo-culting from python tbh :(
[09:55] <fwereade> TheMue, (the public/private buckets, anyway)
[09:56] <TheMue> fwereade: Think so too. In the beginning we've ported much 1:1.
[09:56] <fwereade> TheMue, the tools stuff was done round about lisbon 1 but I wasn't closely involved... guess I should talk to niemeyer this pm, see if he has context I lack
[09:57] <TheMue> fwereade: I'm sure he can answer your question.
[09:58] <TheMue> fwereade: http://irclogs.ubuntu.com/2012/05/01/%23juju-dev.txt
[10:11] <frankban> hi fwereade: is there a bug for the default-series problem?
[10:12] <fwereade> frankban, not yet, I'm looking into it more closely just now
[10:12] <frankban> fwereade: ack thanks
[10:19] <fwereade> frankban, quick check: were you using --upload-tools? because that seems to work in quite a surprising way
[10:19] <frankban> fwereade: yes
[10:19] <fwereade> frankban, right, yeah, ISTM that upload-tools is crack, because it just forces everything to run with the tools that have been uploaded regardless
[10:20] <frankban> fwereade: so it takes the series I am running in the local machine?
[10:20] <fwereade> frankban, yeah, and it looks like it's totally infectious
[10:21] <frankban> fwereade: so, in theory, if I compile and run juju in a precise lxc it should work...
[10:21] <fwereade> frankban, I have a nasty suspicion that even without upload-tools it will force the series/arch of the bootstrap node onto everything it provisions, but I'm still verifying that
[10:23] <fwereade> frankban, hmm, yes, worth a try
[10:23] <frankban> fwereade: I will
[10:27] <fwereade> frankban, you will still be stuck with whatever you uploaded for absolutely everything you deploy, but at least you should be able to progress
[11:05] <mariusko> Hi, where should charm settings be saved?
[11:06] <fwereade> mariusko, I'd expect charm settings to be declared in the charm's config and set individually for each service running the charm
[11:06] <fwereade> mariusko, what sort of settings are you thinking of?
[11:19] <mariusko> fwereade: these are more locally cached ones
[11:20] <mariusko> actually, they are from the relation to mongodb, but they needs to be reused in config-changed hook
[11:21] <mariusko> I could not find an easy way to find it there without knowing the unit number
[11:22] <mariusko> When there is just one relation possible to mongodb, I would expect to be ablo te get those relation config options easily
[11:22] <fwereade> mariusko, there's a relation-list tool that will tell you what units are on the other side of the relation
[11:25] <mariusko> I.e. in this case I would expect to write the example "user=`relation-get -r db:42 user mysql/0`" as "user=`relation-get -r db user mysql`" if there is a one-to-many relationship from mysql
[11:26] <fwereade> mariusko, there's `relation-ids <name>` to tell you what relations exist; `relation-list <id>` to tell you what units are in each relation; and then you can `relation-get <id> <unit>`
[11:26] <fwereade> mariusko, except I've done the syntax completely wrong, sorry
[11:27] <mariusko> fwereade: ok, let me see if it can solve the problem. Is there a way to debug these commands interactively?
[11:27] <fwereade> mariusko, what version of juju are you using?
[11:27] <mariusko> They did not work in "juju debug-hooks"
[11:27] <fwereade> mariusko, ok, you're using python... and that would have been what I suggested next
[11:27] <mariusko> 0.6.0.1+bzr616-0juju2 from the ppa
[11:28] <fwereade> mariusko, do you have a transcript of what didn't work by any chance?
[11:31] <mariusko> fwereade: "juju debug-hooks testapp4/0", then "relation-ids" gives "No JUJU_AGENT_SOCKET/-s option found"
[11:32] <fwereade> mariusko, does any hook tools work at all?
[11:32] <fwereade> mariusko, eg juju-log?
[11:32] <mariusko> nope, just when run automatically
[11:36] <fwereade> mariusko, huh, that rather sounds like debug-hooks is just plain broken
[11:36]  * fwereade tries to think who might be up to date with the python and awake at this hour
[11:39] <fwereade> mariusko, you might be able to iterate *reasonably* quickly if you keep upgrading your config-changed hook from a local repo
[11:42] <mariusko> fwereade: pushed the current code: https://code.launchpad.net/~mariusko/charms/precise/node-app/lp1123939_procfile_support
[11:43] <mariusko> Caching now happens in "/etc/juju_nodejs_app_${app_name}_mongodb.env"
[11:51] <fwereade> mariusko, I'm not quite sure how well that will work when there are multiple mongodbs
[11:51] <fwereade> mariusko, it seems like every unit of node_app will just store the most-recently-changed mongodb server?
[11:51] <mariusko> I think there only could be one associated with one node app
[11:53] <fwereade> mariusko, I'd better go take a look at the mongodb charm ;)
[11:53] <mariusko> Hmm japp, "app_name" is set by the user, so it could be other charm instances with the same app_name...
[11:53] <mariusko> Maybe service name should have been included
[11:55] <mariusko> That would also break some of the existing stuff in the charm too
[12:00] <mariusko> Maybe "$JUJU_SERVICE" should have been used instead
[12:00] <fwereade> mariusko, that should definitely be unique, yeah
[12:02] <fwereade> mariusko, and it does rather look as though it is just storing the most-recently-changed info
[12:03] <fwereade> mariusko, which I think might be a problem is the most-recently-changed on ever goes offline
[12:03] <mariusko> there are a lot of issues in the charm japp
[12:04]  * TheMue is at lunch
[12:04] <mariusko> it looks more like in a demo state now
[12:05] <mariusko> Anyway, there should just run one instance on each machine anyway
[12:05] <fwereade> mariusko, yeah, I'm not too bothered by the machine-sharing issue right now
[12:06] <fwereade> mariusko, I think it would be noticeably better if it maintained an up-to-date seed list (I'm pretty sure the node.js drivers can work with replicasets, right?)
[12:06] <mariusko> but if the mongodb dies, I hope that juju fires up a new one and then run the relation hook again to set the new info?
[12:07] <fwereade> mariusko, if you've got 3 in a replicaset and the last one to change goes down, I fear that the node apps will only try to connect to that one and fail ignominiously
[12:07] <mariusko> Seems it reads it: "replset=`relation-get replset`"
[12:07] <fwereade> mariusko, that's just a string
[12:07] <fwereade> mariusko, taken straing from the config
[12:08] <fwereade> mariusko, AFAICT, anyway
[12:08] <fwereade> s/straing/straight/
[12:08] <mariusko> haven't started playing with mongo yet, so I don't know much about it
[12:09] <mariusko> It is now set to ""myset"
[12:09] <fwereade> mariusko, I'm having some trouble spelunking through the mongodb charm -- it is certainly doing sane things in the replset relation hooks
[12:09] <mariusko> I thought the relationship was many nodeapp->one mongodb->many mongodb nodes
[12:10] <fwereade> mariusko, building up host:post,host:port lists... but I haven't figured out if/how they pass them on to database clients
[12:10] <mariusko> I have a replica-set relation from mongodb
[12:11] <fwereade> mariusko, that relation looks like it's being sensible -- ie it's causing the individual mongos to keep track of their replica sets, which is good
[12:12] <fwereade> mariusko, so if you successfully connect to any one, your driver should be able to figure out the current rs state and go from there
[12:13] <fwereade> mariusko, but if a node app only has one mongo address stored, and that address stops working for any reason, I don't think it'll be able to connect
[12:19] <mariusko> fwereade: firing up one more mongo unit now to see what happens
[12:19] <mariusko> But it was like that before my hacking too :)
[12:20] <mariusko> Japp, the mongodb IP changed to the last added mongodb node
[12:22] <fwereade> mariusko, sure, sorry, I think I've derailed you quite badly :(
[12:23] <mariusko> fwereade: japp, it seems like the client should list all nodes when connecting: "MongoClient.connect("mongodb://localhost:30000,localhost:30001/integration_test_?w=0&readPreference=secondary", function(err, db) {"
[12:23] <mariusko> At least more than one
[12:24] <fwereade> mariusko, re uniqueness, incidentally, it's more-or-less ok to store that sort of cached information inside the charm dir
[12:24] <fwereade> mariusko, the important bit is that if it's stored in the charm dir, it's for the consumption of the *charm* (which can then use it to write config files in /etc or wherever, in response to hooks)
[12:24] <mariusko> If all should be listed, it is maybe easier to try to do it properly and fetch all of them
[12:25] <fwereade> mariusko, if it's for the consumption of the service in any way -- eg an actual config.js, definitely don't store it in the charm dir
[12:26] <fwereade> mariusko, +1 to that, I think
[12:27] <fwereade> mariusko, no sure how to handle connections to multiple mongodb *services* though... that might be a case where the "limit" setting on the charm would be helpful
[12:27] <fwereade> mariusko, if only limit restrictions were actually implemented :/
[12:28] <mariusko> Hehe, juju looks a bit in alpha state at this time
[12:28] <mariusko> But seems to work in simple cases for test/development purposes
[12:28] <mariusko> Hope it will change for Raring
[12:29] <fwereade> mariusko, hopefully we'll have something solid for you... but I'm not sure limit will make the cut
[12:29] <fwereade> mariusko, on the plus side, I think that it's reasonably clear that the tools to get node_app doing the right thing are in place
[12:30] <fwereade> mariusko, it takes a little while to get used to charm-writing though
[12:30] <mariusko> fwereade: tried to describe the problem here: https://bugs.launchpad.net/charms/+source/node-app/+bug/1131188
[12:30] <_mup_> Bug #1131188: Does not support multiple mongodb units <node-app (Juju Charms Collection):New> < https://launchpad.net/bugs/1131188 >
[12:30] <fwereade> mariusko, thank yu, that's extremely helpful
[12:31] <mariusko> Japp, Heroku etc. seems to have a more complete service just now, but AFAIK it does not allow hacking on it like Juju :)
[12:32] <fwereade> mariusko, I don't want to bash those at all, they do what they do just as they should, but we're not trying to do quite the same things :)
[12:37] <mariusko> Sure, those services also have their own proprietary tools so it is harder to change cloud providers. Sent a merge requst
[12:39]  * dimitern lunch
[12:43] <bac> hi jam, thanks for the review.
[12:43] <bac> i don't understand your comment in the README about --upload-tools
[12:44] <bac> even if you use --upload-tools, i think it will complain if it sees a juju-origin
[12:44] <jam> bac: for juju-core you can do 'juju bootstrap --upload-tools' which is how you get the 'current' version of tools available for things to use.
[12:44] <jam> With Python juju
[12:44] <bac> so for people coming from pyjuju with a pre-existing environments.yaml they will see that complaint
[12:44] <jam> you had to specify a source
[12:44] <jam> like ppa
[12:45] <jam> bac: sure, my point is, if someone was *using* a custom source for juju (like juju-origin: ppa) they most likely want "juju bootstrap --upload-tools".
[12:45] <bac> jam: gotcha
[12:45] <jam> I was mentioning it as "do we want to include a side reference so people can figure out where to get similar functionality"
[12:45] <jam> though I imagine people tend to have that line because it was the magic voodoo that made things work
[12:46] <jam> (because precise has an old version of juju that is incompatible with lots of python-juju clients)
[12:46] <bac> jam: with the two positive reviews am i free to make the changes requested and then submit or do i need to re-propose?
[12:47] <bac> for this one i will definitely re-propose.  just asking about the expectation for this project.
[12:47] <jam> If you have 2 LGTM, then submit (though you should respond to make it clear that you've done the requested actions, etc.)
[12:58] <fwereade> bac, generally we take the string "LGTM" to be the indicator of sufficient positivity, so I'm not quite sure dfc's counts
[12:59] <fwereade> bac, I think his "weird API" comment has some legs... not because the API is weird, IMO it's a perfectly sensible one, but I'm not sure how nicely it will play with rog's RPC magic
[13:01] <fwereade> bac, jam: I'm also a little bit reluctant to recommend --upload-tools too loudly, but I have not yet figured out whether it breaks juju *enough* worse than it already is re series/arch selection
[13:02] <fwereade> bac, jam: and I am afraid I've just been called to lunch
[13:41] <fwereade> niemeyer, heyhey
[13:42] <niemeyer> fwereade: Heya
[13:43] <fwereade> niemeyer, I liked your ubuntu finder sketch :)
[13:43] <dimitern> niemeyer: hey
[13:44] <niemeyer> fwereade: Neat :)
[13:44] <niemeyer> dimitern: Heya
[13:49] <bac> dimitern: hi, thanks for the review.  i removed the 'cobzr branch -b' part b/c i found it did not work.  does it work for you?
[13:49] <dimitern> bac: yw, actually I never used it like that, I always use bzr checkout -b branchname (that's with cobzr)
[13:50] <dimitern> that's maybe worth mentioning (if it's not there already)
[13:50] <bac> dimitern: i'll try that
=== wedgwood_away is now known as wedgwood
[14:57] <TheMue> re
[14:57] <TheMue> Argh, my system crashed. *grmpf*
[16:13] <dimitern> fwereade: ping
[16:15] <fwereade> dimitern, pong
[16:15] <dimitern> fwereade: i couldn't find anywhere Service.SetCharm is used, except for a few tests
[16:15] <fwereade> dimitern, it will be used by upgrade-charm
[16:16] <dimitern> fwereade: but a lot of the things it has to do are uniter operations
[16:16] <fwereade> dimitern, its current total lack of safety is the primary reason for the lack of upgrade-charm
[16:16] <fwereade> dimitern, sorry, restate?
[16:16] <dimitern> fwereade: e.g. downloading a charm to see what it implements, its config, etc.
[16:16] <fwereade> dimitern, the uniter should already handle those changes once they've happened
[16:17] <fwereade> dimitern, the upgrade-charm story is all about making sure those changes are sane
[16:17] <fwereade> dimitern, so that the uniter will itself respond sanely ;)
[16:17] <dimitern> fwereade: so all the things you described about changes to Service.SetCharm (well, most of them) will in fact happen in the uniter, before calling it
[16:18] <fwereade> dimitern, I don;t think so -- can I talk properly in a mo?
[16:18] <dimitern> fwereade: what, hangout?
[16:23] <mgz> dimitern: if you're not hanging out yet, can you hop on mumble quickly and tell me if my settings on this box are working okay?
[16:23] <dimitern> mgz: sure
[17:05] <fwereade> dimitern, ping
[17:05] <fwereade> dimitern, sorry
[17:05] <dimitern> fwereade: pong
[17:05] <fwereade> dimitern, quick hangout?
[17:05] <dimitern> fwereade: ok, i'll send you a link
[17:05] <fwereade> dimitern, with you in 2 mins
[18:31] <jtv> Is anyone else having trouble running "make check" in pyjuju?
[18:31] <jtv> And "make review" etc?
[18:34] <dimitern> fwereade: it seems there's no clean way to stop a watcher without a panic :(
[18:35] <dimitern> fwereade: am I to expect that? and check for a panic in the tests?
[18:37] <fwereade> dimitern, hmm, sorry good point: that's a line saying watcher.MustErr(relationsw) or something?
[18:38] <fwereade> dimitern, change that bit
[18:38] <dimitern> fwereade: yeah, that one
=== deryck is now known as deryck[lunch]
[18:38] <fwereade> dimitern, that's checking that no sneaky git stops the watcher underneath us; now that we're deliberately stopping it you should be fine with an err or nil
[18:39] <fwereade> dimitern, maybe only start the new watcher once the old one has stopped? that might actually be neatest
[18:39] <dimitern> fwereade: :)
[18:39] <fwereade> dimitern, to be clearer: if there's an err, return it; if it's nil, start a new one
[18:39] <dimitern> fwereade: hmm
[18:40] <fwereade> dimitern, that could probably use a comment though, it's a bit subtle, and don't forget to fix up the defer stop (or defer a new one)
[18:40] <dimitern> fwereade: yeah, ok
[18:40] <dimitern> fwereade: i was thinking exactly of the defer
[18:41] <dimitern> fwereade: so it'll call MustErr instead
[18:41] <fwereade> dimitern, hmm, no, I don;t think you want MustErr at all for relationsw
[18:41] <fwereade> dimitern, I think you probably want a defer that stops the current value of relationsw, rather than snapshotting it
[18:42] <dimitern> fwereade: ISTM the only place MustErr is called on relationsw is in the <-Changes() case
[18:42] <fwereade> defer func() {relationsw.Stop()}() rather than defer relationsw.Stop()
[18:42] <dimitern> fwereade: ah! got you - yeah, it'll be different
[18:43] <dimitern> fwereade: so filter.go: 223 that if should be gone
[18:43] <dimitern> oops 213
[18:44] <dimitern> no
[18:44] <dimitern> sorry, finally 221 :)
[18:44] <dimitern> on the relationsw
[18:46] <fwereade> dimitern, yeah, around 222: if err == nil { relationsw = service.WatchRelations() } else { return err }
[18:47] <fwereade> dimitern, something like that
[18:47] <dimitern> fwereade: won't that screw up the defer above?
[18:48] <dimitern> fwereade: ah, no - because we'll be out already!
[18:48] <fwereade> dimitern, depends if relationsw is naked or only evaluated inside the deferred func
[18:48] <fwereade> dimitern, if it's `defer relationsw.Stop()` then it's *that* specific relationsw that will be stopped; if it's inside a func it'll take the value of relationsw at the time it's finally executed
[18:50] <dimitern> fwereade: no, I mean I though I saw a inf loop there, but then I realized <-Changes() and the restarting won't happen again while in the defer
[18:50] <fwereade> dimitern, yeah, exactly, once we're in the defer we can't go back :)
[18:51] <dimitern> fwereade: neat :)
[18:51] <dimitern> fwereade: and I can get the err from relationsw.Err(), right?
[18:55] <dimitern> fwereade: right, so to test the watcher was restarted, I should stick a change just before the upgrade is fired
[18:55] <dimitern> fwereade: or you don't think this needs testing?
[18:59] <dimitern> fwereade: sorry it seems you dropped off
[19:09] <jtv> Could anyone give me a review for these Makefile changes?  https://code.launchpad.net/~jtv/juju/makefile-fixups/+merge/149907
=== deryck[lunch] is now known as deryck
[21:01] <bac> .
[21:01] <bac> fwereade: when you have a moment could you do a second pass on my branch?  if you think it is ok do i need to wait for dfc to re-review too?
[21:02] <bac> fwereade:  https://codereview.appspot.com/7401043/
[21:04] <fwereade> bac, sure, just a mo
[21:07] <fwereade> bac, LGTM, couple of trivial typos
[21:07] <fwereade> bac, I think you're fine re dfc, you did address his point
[21:12] <bac> fwereade: thanks
[21:26] <_thumper_> mramm: ok, at home now, hangout?
[21:26] <_thumper_> mramm: needs to be personal one though
[21:26] <_thumper_> as the laptop is upgrading :)
[21:26] <mramm> ok
[21:26] <mramm> shoot me an invite?
[21:27] <_thumper_> I'll try...
[21:28] <BradCrittenden> fwereade: i have made the final changes.  i cannot submit the branch b/c i'm not in ~gophers.  can you merge it for me?
[21:28] <_thumper_> mramm: the ipad app won't let me add you :(
[21:28] <_thumper_> don't know why
[21:28] <mramm> ok
[21:28] <mramm> let me try inviting you
[21:28] <_thumper_> ok
[21:29]  * _thumper_ tries to recall which image is the personal one
[21:29] <mramm> invite sent
[21:29] <_thumper_> which did you use?
[21:29] <_thumper_> I don't see it
[21:29] <mramm> though perhaps to your canonical acount
[21:29] <_thumper_> perhaps invite the other me :)
[21:30] <mramm> looking for your personal...
=== BradCrittenden is now known as bac
[21:30] <gary_poster> Hey mramm, could you please add ~juju-gui to ~gophers so we can propose?
[21:31] <gary_poster> mramm alternatvely I can give you individual people, as you wish
[21:39] <mramm> _thumper_: trying again, seems that I lost google hangout
[21:39] <_thumper_> ack
[21:40] <_thumper_> mramm: you disappeared again
[21:40] <mramm> hmm
[21:40] <mramm> google hangout is not my friend today
[21:43] <mramm> trying again with another browser
[21:45] <mramm> yea, nothing working, trying a reboot
[21:45] <mramm> be back in 2 min
=== _thumper_ is now known as thumper
[21:51] <thumper> I home mramm isn
[21:51] <thumper> isn't having shell issues too
[21:51] <thumper> s/home/hope
[21:52] <thumper> I have a horrible feeling that this day is going to be a write-off
[21:52] <thumper> I hope not...
[22:01] <hatch> arrrrgggggggg
[22:02]  * hatch smashes things in hope that it solves his problem
[22:02] <thumper> hi mramm
[22:02] <thumper> mramm: long two minutes :)
[22:02] <mramm> yea
[22:02] <mramm> computer hung on reboot
[22:02] <mramm> :(
[22:03] <thumper> :(
[22:03] <thumper> but you got a shell ok?
[22:05] <mramm> eventually
[22:06] <mramm> not sure why but it just took forever to get there
[22:06] <mramm> but then all is good
[22:07] <thumper> mramm: are you going to try a hangout again?
[22:12] <mramm> thumper: I'm in a hangout with dave at the moment
[22:15] <thumper> mramm: ok
[23:17] <mramm> thumper: you still around?
[23:24] <davecheney> thumper: when you get done with mramm, can we have a chat ?