[12:04] <bac> benji: could you do a 2nd on https://codereview.appspot.com/13660050 when you have time?
[12:05] <benji> bac: sure
[12:42] <bac> itunes has a page for your app purchases with a big 'Report a problem' button.  when you press it, the button disappears but nothing else happens.  cunning.
[12:43] <benji> bac: that's because at that point there is no need for the button any more, you have reported yourself to be a problem.
[12:44] <bac> it is only 99 cents but i want the developer punished
[14:05] <benji> BradCrittenden: I just saw this comment in the charm model code.  Do you know what this means for the bundle model?
[14:05] <benji>   // XXX jcsackett Aug 12 2013 Charm model is only being kept while we observe
[14:05] <benji>   // the effects of the changeover to Browsercharm. This can be deleted once we
[14:05] <benji>   // ascertain there is no fallout.
[14:07] <BradCrittenden> benji: i saw it too.  it should have no affect on bundles
[14:08] <jcsackett> benji, bac: i think rick_h_ completed that changeover, so maybe that comment can go away?
[14:09] <benji> jcsackett: you may be right: I just checked for BrowserCharm and it doesn't appear in the code base (other than a substring of BrowserCharmView, which should probably be renamed)
[14:10] <bac> benji: but the comment mentioned a transition TO browsercharm
[14:10] <rick_h_> benji: bac jcsackett is correct. Missed that in my changeover 
[14:10] <benji> bac: I think BrowserCharm became Charm and the old Charm model went away (or they were merged or something similar)
[14:11] <rick_h_> it's not camel cased so missed it in my grep for BorwserCharm
[14:11] <rick_h_> with better spelling...
[14:12] <bac> so the model that begins like the following is the keeper:
[14:12] <bac> models.Charm = Y.Base.create('browser-charm', Y.Model, [], {
[14:12] <bac> rick_h_: ^^
[14:13] <rick_h_> bac: right, that's the one true model used for everything 
[14:13] <bac> rick_h_: cool.  i may do a quick follow on branch to kill the other as it is way confusing
[14:14] <rick_h_> bac: rgr, comment should go away for sure
[14:15] <bac> if i can get lbox to not blow up.  /me crosses fingers
[14:15] <bac> rick_h_: does android allow per number call blocking?
[14:17] <jcsackett> bac, rick_h_: There is still the old charm model in that file too, and it can die. (var Charm = Y.Base.create ...)
[14:18] <bac> jcsackett: yep.  thanks for confirming.
[14:19] <jcsackett> and it looks like the old CharmList is there too; you want to keep the instantiation that starts with models.CharmList, rather than var CharmList 
[14:20] <rick_h_> jcsackett: huh? We still use charmlist?
[14:21] <rick_h_> bac: so I don't know. I know google voice does (which I use) but not checked on the device itself
[14:21] <rick_h_> bah, this 3g lag is crazy
[14:21] <jcsackett> rick_h_: yes. BrowserCharmList became CharmList when BrowserCharm became Charm.
[14:21] <rick_h_> jcsackett: right, and BrowserCharmList is still there?
[14:21] <jcsackett> rick_h_: doesn't look like it.
[14:22] <jcsackett> there are just two declarations for CharmList
[14:22] <jcsackett> but only one is attached to the namespace.
[14:22] <jcsackett> it's a source of confusion in reading the code, i think, but not an issue per se.
[14:23] <rick_h_> jcsackett: ah gotcha. ignore me then. 
[14:23] <jcsackett> ah, the damage a typo does. my XXX comment helped not at all when you were killing all of this. :-P
[14:23] <rick_h_> well, my fault for rushing to do it before I left and just reading off grep
[14:24] <abentley> bac, benji: We believe the new lander is working properly.  Please let me know if you have any issues.  It's at http://162.213.35.27:8080/ btw.
[14:25] <benji> abentley: do we just mark MPs as approved and it lands them?
[14:25] <abentley> benji: Yes, and then it updates staging.
[14:25] <benji> abentley: cool!  And I guess (hope) it runs the tests before landing/updating
[14:25] <Makyo> Sigh.  NB: make clean is your friend.  Always has been, always will be.
[14:26] <abentley> benji: Right.
[14:27] <benji> Makyo: the guy that wrote one of the best books on make says that make clean shouldn't ever be a thing and the real make clean is "rm -rf" and re-check-out the project. :)  I tend to agree with him.
[14:28] <Makyo> benji, Hah!  That was going to be my next step out of frustration :)
[14:28] <Makyo> I just rebuilt my env last week, though.
[14:29] <Makyo> Though I'm sure that works with lightweight checkouts without having to redo everything.
[14:31] <hatch_> lightweight checkouts are da bomb!
[14:32] <hatch_> I don't know how they work but aww yeahhh
[14:33] <Makyo> Hahah
[14:33] <hatch_> lol
[14:35] <Makyo> Spent the end of yesterday and beginning of this morning debugging a 404 on a test file that only showed up in test-debug/prod, but not test-server. Oh well~
[14:35] <Makyo> jujugui review/QA please https://codereview.appspot.com/13705045/
[14:35] <hatch> I'll take one
[14:36] <hatch> what was the issue?
[14:36] <Makyo> make clean fixed it.  It was requesting an asset from an old location, I guess.
[14:54] <hatch> could I get a very quick review on the hacking docs update https://codereview.appspot.com/13828044/
[14:54] <hatch> jujugui ^
[14:54] <Makyo> On it
[14:54] <hatch> thanks
[14:56] <benji> hatch: I don't think sudo on the lbox install is neccesary (and probably not a good idea)
[14:56] <hatch> benji: it was under sudo before so I just left it as such
[14:57] <hatch> can it even be installed without sudo?
[14:57] <benji> hmm, in that case I would default to leaving it too, but I'm suspicious
[14:57] <hatch> someone with 12.04 can check :)
[14:57] <benji> hatch: mine is installed without sudo
[14:58] <hatch> oh alright then, I can remove it
[15:00] <Makyo> As long as your $GOPATH is where your user can write it.
[15:01] <hatch> mm goo point
[15:01] <hatch> maybe I'll just leave it
[15:01] <hatch> :)
[15:02] <hatch> does anyone know of a charm that's very basic? now that I have juju core set up to test it would be nice to use charms which install fast :)
[15:03] <hatch> bac: ci failure in firefox
[15:04] <Makyo> hatch, does $GOPATH default to something?  Can you `go get` and `go install` without it?  That used to not be the case, but perhaps that's changed?  Blanket use of sudo aside, it'd be nice to make sure we're right in our docs :)
[15:06] <hatch> usr/lib i think
[15:06] <hatch> but darn now I can't remember
[15:07] <Makyo> hatch, I've got a fresh Ubuntu server vm, want me to check?
[15:07] <hatch> if you have the time
[15:07] <hatch> no rush
[15:08] <Makyo> hatch, Sure, give me a few.
[15:10] <bac> hatch: looking
[15:10] <bac> jcsackett, rick_h_: could one of you look at this deletion branch https://codereview.appspot.com/13255052
[15:17] <Makyo> hatch, no default $GOPATH. I'd suggest something like adding "Set your GOPATH environment variable to something like $HOME/bin/go" and then you can remove the sudos.
[15:17] <Makyo> hatch, Will also have to modify $PATH, will get that info to you in a sec.
[15:18] <hatch> ok, I accidentally hit submit instead of propose :/ but I'll still update :)
[15:18] <Makyo> hatch, That's fine.
[15:19] <hatch> oh and re zookeeper, I'm not sure, I ended up running it anyways
[15:19] <hatch> so I'm not sure if it's not required or not
[15:19] <hatch> might be for 12.04 but not 13.04
[15:19] <Makyo> hatch, export $PATH=$PATH:$GOPATH/bin:$HOME/bin/go/bin
[15:19] <Makyo> WAIT
[15:20] <Makyo> That's what I get for typing from memory.
[15:20] <Makyo> export $PATH=$PATH:$GOROOT/bin:$GOPATH/bin
[15:21] <Makyo> (Which is for bash, ofc. May want to type that out in words, like "Add $GOROOT/bin and $GOPATH/bin to your PATH environment variable")
[15:21] <hatch> Makyo: if you don't mind, could you gist that for me? my irc client is turning it into an emoticon mess
[15:26] <Makyo> hahah, sure :)
[15:29] <luca__> gary_poster: when are you starting work on project: I scream, you scream, we all scream for ice cream?
[15:30] <Makyo> hatch, https://gist.github.com/makyo/6686500
[15:30] <gary_poster> lol, one sec, on call about it luca__ 
[15:30] <hatch> lol
[15:30] <hatch> Makyo: thanks
[15:30] <hatch> :)
[15:30] <luca__> gary_poster: ah, are you talking to emma and mark?
[15:30] <gary_poster> y
[15:30] <hatch> hmm /me has not met this emma yet
[15:30] <hatch> I think it's time for another London trip
[15:31] <Makyo> Pff.
[15:31] <hatch> yeah you're right, lets do Ireland or something
[15:32] <Makyo> I do need to take James to London.  Helps that there's the office there to work at.  Maybe we'll figure something out next year.
[15:32] <hatch> Friend of mine just had a corporate meeting in Banff
[15:32] <Makyo> Hahaha, I'm not opposed to that, either!
[15:33] <hatch> nope!
[15:33] <bac> hatch: i have a real error in my test.  done() called before the end.  odd that chrome was happy with it.
[15:33] <hatch> bac: darn - I was really hoping it was a glitch
[15:33] <bac> hatch: i prefer the explainable
[15:33] <bac> even if the explanation is that i goofed.
[15:34] <hatch> yeah good point :)
[15:38] <hatch> Makyo: you know you don't 'need' an office to work at ;) All you really need is wifi and a power outlet (mostly because your laptop won't last 30mins on a charge :P )
[15:39] <Makyo> hatch, I'm slowly getting my dev env set up on the MBA!  The only problem I've run into with that is that it goes to sleep thirty seconds after plugging in/unplugging for some reason, regardless of activity.
[15:40] <Makyo> hatch, Though I just imagine that working in the office would be more conducive to actually working than working in, say, a hotel lobby.
[15:40] <Makyo> Though those heights, man...
[15:41] <hatch> well I'd probably bank on a building falling over before a mountain falling over
[15:41] <hatch> so probably a safe bet
[15:42] <hatch> Makyo: search for Caffeine - it's a must have app for osx
[15:42] <hatch> http://lightheadsw.com/
[15:43] <Makyo> hatch, I'll look into it.  This seems more like a bug than anything - it'll go to sleep in the middle of typing - but that may be handy otherwise.
[15:44] <hatch> ohh - yeah that's definitely not normal
[15:44] <Makyo> Though there was a recent software update, will see if that fixes it.
[15:44] <hatch> are you able to run an ubuntu vm on it?
[15:45] <Makyo> Yeah, I have an ubuntu server VM for running the dev env/bzr/lbox.  Files are shared over NFS so I can work on the MBA itself.
[15:46] <hatch> cool cool
[15:46] <hatch> that's what I'm doing right now as well
[15:46] <hatch> although every time I switch to the 13.04 desktop I like it more and more
[15:46] <hatch> although the thing that I hate the most os the header bars for the windows
[15:47] <hatch> they don't match the rest of the OS at-all
[15:47] <hatch> pretty pretty pretty - O M G WHAT HAPPENED
[15:47] <hatch> that's what happens to me
[15:47] <hatch> lol
[15:49] <Makyo> Hah.  They match well enough for me, so maybe you've just got a weird theme going on.
[15:50] <Makyo> jujugui call in 10 kanban now
[15:51] <Makyo> hatch, re: your comments on my branch, I'll check on the errors, though I wasn't getting them.  The rest is for the next card.
[15:52] <hatch> hmm i was on a fresh pull
[15:52] <hatch> I can try again
[15:52] <Makyo> hatch, I don't doubt it, I'll keep investigating.
[15:54] <hatch> Makyo: oh yeah on my laptop I don't think I run a single stock UI element haha
[15:54] <Makyo> hatch, Well, no wonder it looks all wonky :)
[15:54] <hatch> oh no I'm talking the stock UI
[15:55] <hatch> the black embossed headers don't match the rest of the UI
[15:55] <gary_poster> luca__, hey.  I should give a quick summary to you of call I just had with Mark Baker and Emma
[15:55] <Makyo> hatch, Huh?  They do for me..
[15:56] <gary_poster> luca__, you coming to daily call, or are you around in 15 or 20?
[15:56] <hatch> Makyo: really? the rest of the UI is flat/square and they are rounded and embossed
[15:56] <gary_poster> alejandraobregon will want to know too, but it is fairly simple so can tell you, you can tell her, and I can also write email about it later today
[15:56] <Makyo> hatch, rest of the UI is rounded and embossed for me, too.
[15:57] <hatch> oh weird
[15:57] <Makyo> hatch, buttons are embossed squircles, dash has rounded corners, folders are glossy, etc.
[15:58] <hatch> yeah not here - maybe I installed something and don't remember
[15:58] <hatch> which is entirely possible
[15:58] <gary_poster> jujugui call in 2
[16:01] <gary_poster> benji you around?
[16:01] <benji> gary_poster: no
[16:01] <gary_poster> benji, :-P
[16:12] <benji> quote of the day right there: "fukushima brand sushi"
[16:12] <hatch> yeah and it wasn't from me!.... yussss
[16:13]  * hatch passes torch to Makyo
[16:13] <Makyo> Hahahaha
[16:14] <hatch> I think I still need a roomie for SFO, not sure if anyone else is still looking
[16:14] <Makyo> I don't think I have one yet.
[16:15] <hatch> sup roomie!
[16:15] <Makyo> Yo.
[16:25] <hatch> http://www.engadget.com/2013/09/24/zboard-San-Francisco-Special-gets-crowdfunded/ next step the hover board from Back To The Future?
[16:32] <abentley> I do not know whether to be proud or ashamed: http://bazaar.launchpad.net/~abentley/charms/precise/packages/trunk/view/head:/README
[16:33] <hatch> oo new imacs....maybe this means new mbp's are finally coming
[16:34] <hatch> abentley: are they REALLY mutually exclusive? ;)
[16:48] <hatch> bcsaller: can I send a remove-service delta from the console?
[16:55] <bcsaller> hatch: you could if you took app.env.ws.onmessage({delta}) I think
[16:55] <bcsaller> hatch: or calling the method on the fakebackend
[16:57] <hatch> alright - I just now need to figure out what the format of the request is
[16:58] <bcsaller> hatch: the tests will show that
[16:58] <bcsaller> the go sandbox tests would show the message format
[17:05] <gary_poster> abentley, heh, wow, yeah, maybe both, but sounds cool :-)
[17:06] <hatch> bcsaller: so I haven't had any luck using onmessage but I figured that calling app.env.destroy_service('liferay') should trigger a delta in sandbox...no?
[17:06] <gary_poster> hey hatch, I have a viewlet test that is leaving something dirty.  wondering if you have seen before, because I am ready to get this done and have some lunch. :-)  you available? 
[17:07] <hatch> yeah I'm not getting anywhere while I wait for my core instance to boot up
[17:07] <gary_poster> hatch cool 
[17:07] <gary_poster> https://plus.google.com/hangouts/_/5a21fc24877892fe2bd5ba462ce6f47f9c2bce2e
[17:07] <bcsaller> hatch: yes, that is exactly as if you'd destroyed the service from the inspector though
[17:07] <hatch> ohh so that's intentional
[17:07] <hatch> ok got it
[17:25] <hatch> jujugui does anyone know a 'juju' way to access exposed services from inside a 'local' deployment inside a vm without an ssh tunnel?
[17:25] <hatch> something like exposing the local service to the hosts ip?
[17:26] <gary_poster> hatch, it Just Works for me
[17:26] <hatch> mine gives me 10.0.X.X ip's
[17:26] <hatch> which are only accessable from the host vm
[17:26] <gary_poster> hatch, oh you mean to the parent
[17:26] <hatch> yeah
[17:26] <hatch> from within the vm, no problem
[17:26] <hatch> I have too many levels of recursion :D
[17:27] <hatch> I can tunnel, it's not an issue but just wondering if there is a juju way to do it
[17:27] <hatch> it feels like there should be
[17:27] <gary_poster> hatch, I always use vms that share networks with surrounding.  I forget the setting name, but that alleviates issues like that IME
[17:27] <gary_poster> not a juju issue I don't think
[17:27] <bcsaller> that should also work though, there isn't a local firewall so expose isn't even needed. you can't go directly to that ip on the right port?
[17:28] <hatch> well I need to create an ssh tunnel from the juju-gui 'machine' to its host
[17:28] <hatch> like...
[17:29] <hatch> ssh -N -p 22 -c 3des devbox@localip -L 1234/10.0.X.X/443
[17:29] <hatch> then when I go from my desktop machine to access the 'localip' of the devbox it works as expected
[17:29] <bcsaller> nah, the lxc network should be bridged by default, it used you be, `route -n |grep lxcbr0`
[17:30] <hatch> 10.0.3.0        0.0.0.0         255.255.255.0   U     0      0        0 lxcbr0
[17:30] <hazmat> hatch, you can do that (ssh forward) or do iptables port forward if you want something more transparent
[17:31] <hatch> hazmat: should exposing a service on juju local automatically port forward?
[17:31] <hatch> it feels to me like it should 'just work'
[17:31] <hazmat> hatch, no, juju does not touch iptables
[17:31] <hazmat> hatch, local provider .. hint was meant for local usage, where its not nesc.
[17:32] <hazmat> hatch, the use of lxc containers (via juju add-machine lxc:0) on non local providers is pretty new, and only works out of the box for baremetal
[17:32] <hatch> ohh ok
[17:32] <Makyo> hatch, when you get a chance, I can't dupe the errors, though I did see them during development.  Can you tell me the process that led to them?
[17:33] <hatch> I'm wondering if this is going to cuase confusion to others who might be using a remote box and trying lxc versions
[17:33] <hatch> ^ hazmat
[17:33] <hatch> Makyo: will repro and get back to you
[17:33] <Makyo> hatch, thx
[17:33] <gary_poster> hatch are you doing add-machines or just environements.yaml type:local?
[17:34] <hatch> juju boostrap -e local
[17:34] <hatch> so the latter
[17:34] <gary_poster> right
[17:35] <hatch> Makyo: http://HOSTIP:8888/:flags:/upgradeCharm ; DD liferay ; deploy ; errors errors and more
[17:35] <Makyo> hatch, oh, that's right, hold on.
[17:35] <benji> jujugui: I have a review up at https://codereview.appspot.com/13860044
[17:36] <Makyo> hatch, forgot to take note, had forgotten.  I see that every time with liferay, but only liferay.
[17:36] <hatch> ohh.....lol crazy that I chose it in my QA then haha
[17:36] <hatch> typically I don't choose it for some reason
[17:37] <Makyo> Same!
[17:37] <Makyo> Will look into it.
[17:37] <hatch> gary_poster: hazmat so once add-machine works on lxc this issue will no longer be?
[17:37] <gary_poster> hatch, no, on my side just was confused by why hazmat raised add-machine
[17:38] <gary_poster> separate issue AFAIK
[17:38] <hatch> ohh - ok then yeah I'm confused too :D
[17:39] <hatch> I'll ssh tunnel it for now - no big deal, but maybe could be worth a note in the lxc docs or a blog post or something
[17:45] <hatch> darn just ran into this bug https://bugs.launchpad.net/juju-core/+bug/1210054
[17:45] <_mup_> Bug #1210054: juju terminate-machine with local provider doesn't destroy machine <juju-core:Triaged> <juju-core (Ubuntu):Triaged> <juju-core (Ubuntu Saucy):Triaged> <https://launchpad.net/bugs/1210054>
[18:14] <hatch> rebooted the host and now the ssh tunnel doesn't work :/
[18:14] <hatch> clearly today is not my day hah
[18:16] <hatch> the machines instance-state is 'missing' is that supposed to be like that on lxc?
[18:18] <gary_poster> hrh, no
[18:18] <gary_poster> heh
[18:18] <gary_poster> jujugui, looking for one review/qa of https://codereview.appspot.com/13841044 .  Meanwhile, getting some lunch
[18:18] <gary_poster> then will do reviews myself, if any are around :-)
[18:19] <hatch> gary_poster: I can do it
[18:19] <hatch> maybe I'll then ask in juju about this oddity
[18:40] <hatch> """The local provider has been enabled. There is currently one serious restriction with it right now, IP addresses are not available on the machines shown in status. This means that you’ll see “instance-state: missing” for the machines in “juju status”."""
[18:46] <hatch> gary_poster: reviews done - funny how the only real QA issue was the 'cool' feature you added ;)
[18:52] <benji> jujugui: I'm looking for a review of https://codereview.appspot.com/13860044
[18:52] <bac> benji: ok
[18:52] <benji> thanks
[19:07] <bac> benji: your RV is full of chunk mismatch.  i'm not sure how that is fixed.
[19:07] <benji> bac: hmm; were you able to review it or should I look into fixing the MP?
[19:08] <bac> benji: i did not review it
[19:09] <benji> bac: k, I'll see about fixing it
[19:14] <benji> bac: I've fixed it.  Also, note that the only real non-mechanical (but still relatively trivial) changes are in app/widgets/token.js
[19:14] <bac> why do power supplies not have unique tips based on output?  just fried my usb 3  hub.
[19:14] <bac> ok
[19:18] <hatch> bac: because you would need about 1M different ends :)
[19:19] <hatch> and that might be on the low side :P
[19:21] <bac> hatch: that raises a whole different issue...
[19:21] <hatch> haha oh so true so true
[19:21] <bac> dear EE grads, you can have 5V or 12V, that should be sufficient for all designs
[19:22] <hatch> don't you mean
[19:22] <hatch> OEE grads
[19:22] <hatch> Over electrical engineer :P
[19:23] <hatch> honestly I have a very limited knowledge about it, but my guess is if you have to step down from 12v to say 6v you would essentially just be converting it to heat
[19:23] <hatch> which isn't very efficient
[19:28] <bac> use 12V or 5V components, avoid the step down
[19:28] <hatch> right but if you don't need the current it's going to go to waste somewhere
[19:28] <bac> like my fried hub?  that's waste!  :)
[19:28] <hatch> lol
[19:28] <hatch> good call
[19:36] <bac> Makyo: fwiw, 'make clean; lbox submit' still fails in that same way.
[19:37] <Makyo> bac, Gah :/
[19:37] <bac> but only 4/5 times.
[19:38] <hatch> lol 80% failure rate is not good
[19:39] <hatch> :/ ok after updating Juju nothing I can do will give me access to this exposed juju-gui instance
[19:43] <hatch> bac: mind telling me the setup you used again to get your tunnel working
[19:43] <hatch> I'm sure I'm using the identical code but the tunnel does not work :/
[19:44] <bac> hatch: do you have 'ssh tunnel manager' for os x?  pretty handy.
[19:44] <bac> ssh -N -p 22 -c 3des bac@saucy64.local -L 8888/10.0.3.162/80
[19:44] <hatch> and you run that from osx?
[19:44] <bac> yes
[19:44] <hatch> what version of juju are you using?
[19:45] <hatch> yeah nothing....it's not even hitting the tunnel :/
[19:46] <bac> that seems beside the point but i sometimes run the packaged juju (1.14.1-saucy-amd64) and sometimes i run my $GOPATH/bin/juju hand-built version
[19:46] <bac> hatch: and your trying https://localhost:8888 ?
[19:47] <bac> ick, i said 'your'
[19:47] <hatch> well it's not localhost, it's another machine
[19:47] <hatch> so I'm visiting that machine
[19:47] <bac> but the tunnel is your machine
[19:47] <gary_poster> hatch, hey.  thank you very much for review and qa. I can't dupe your qa bad, or maybe we have different expectations.  also one code comment made me want to talk with you.  you available in https://plus.google.com/hangouts/_/23d50444baecceeabfa7ec461380e05ea8123912 ?
[19:47] <bac> the entry to the tunnel is localhost, i.e. the machine safari is on
[19:48] <bac> that's what the -L means
[19:48] <hatch> oh jeebus
[19:48] <hatch> what a stupid mistake
[19:48] <hatch>  /face-desk
[20:04] <bac> benji: i did the review and sent it but haven't even pulled your branch yet.  i'm still struggling to get one landed first.
[20:04] <bac> so, i'm saying i didn't do qa or even run the tests.
[20:06] <benji> bac: it's ok, everything works fine
[20:06] <benji> ;P
[20:06]  * benji goes to an appointment.
[20:10] <hatch> bcsaller: can you join gary and us in the chat above?
[20:12] <Makyo> hatch, when you get a chance, re-pull/test for liferay fix
[20:13] <hatch> thanks will do
[20:27] <hatch> every time I use the GUI on a real env I am impressed :)
[20:27] <hatch> the simulator is cool...but the real thing is so much better
[20:28] <hatch> ^ taken out of context that statement....rules
[20:30] <hatch> jujugui didn't we have an option in the charm to enable unminified code NOT on the simulator?
[20:31] <gary_poster> hatch, yes, frankban added it, though it is probably only on ~juju-gui charm atm.  lookin
[20:32] <gary_poster> wow the new charm tokens from 0.10 are way better to use
[20:34] <gary_poster> hatch, yes, look on https://jujucharms.com/~juju-gui/precise/juju-gui-106#bws-configuration for juju-gui-debug option
[20:34] <hatch> ahh ok and it looks like I'm running version 76
[20:34] <hatch> wow that's behind haha
[20:35] <hatch> (we should probably fix that ;) )
[20:35] <gary_poster> hatch, no you are using official release
[20:35] <gary_poster> ~juju-gui-charmers
[20:35] <gary_poster> that's what you get by default
[20:35] <hatch> ohh
[20:35] <gary_poster> moving charm from ~juju-gui to ~juju-gui-charmers is equivalent to making a release
[20:36] <gary_poster> ~juju-gui is trunk
[20:36] <hatch> so it looks like you can't upgrade the GUI from within the GUI?
[20:36] <hatch> known issue?
[20:37] <gary_poster> that's what Makyo is working on, if you've noticed :-)
[20:37] <hatch> oh...right...duh
[20:37]  * hatch fail
[20:37] <gary_poster> :-)
[20:44] <hatch> gary_poster: don't agree with my personal preference of if (!value) { return; } ? ;)
[20:48] <hatch> it doesn't look like I can set the debug option in the GUI
[20:50] <hatch> although seeing the GUI move when I alter it from the console is pretty cool :D
[20:58] <bac> benji: can we chat first thing tomorrow about next steps?
[21:04] <gary_poster> hatch, yeah, I lean towards preferring to return at the end of the function. Maybe silly.  <shrug>  Not being able to set the debug option in GUI is odd.  I wonder if that's a bug with our bool handling. :-/
[21:05] <hatch> quite possibly
[21:15] <gary_poster> landing huwshimi's branch.  running for now.  bye all
[21:21] <hatch> cya
[21:22] <hatch> Makyo: there was a branch recently which closed the little 'make relation' menu on the canvas, can you point me to where that code is?
[21:22] <hatch> basically it's being left in the canvas when a service is being removed from the console
[21:23] <hatch> so I want to make sure that it gets hooked in with the inspector closing code
[21:27] <hatch> found it
[21:41] <Makyo> Oops, sorry, was dogwalking.
[21:49] <hatch> no problem
[21:58] <hatch> hmmmmm
[21:58] <hatch> so we 'remove' these service models but don't destroy them
[21:58] <hatch> quite innnnteresting
[22:03] <bac> now gary_poster has killed jenkins
[22:06] <hatch> haha, looks like it might be a canonistack issue
[22:15] <arosales> any recommendations on the work-flow to add a unit to a service in the GUI (looks like the inspector is the way to do it in).
[22:16] <arosales> nevermind that is the inspector
[23:02] <huwshimi> Morning
[23:54] <hatch> it's not really clear where to find that information being that the Service is the primary
[23:54] <hatch> all of these are great bugs to open btw so that we can take them to UX and say 'seeeeeeee' others say so too :D
[23:56] <arosales> ya I thought I would confirm and then file bugs and let you guys triage accordingly
[23:58] <hatch> awesome
[23:58] <hatch> btw I'm slowly working on that charm
[23:58] <arosales> hatch, thanks for following up though