[07:14] <rogpeppe1> mornin' all
[09:29] <rogpeppe> frankban: hiya
[09:29] <rogpeppe> frankban: https://github.com/juju/charmstore/pull/66
[09:37] <frankban> rogpeppe: morning, on it
[09:37] <rogpeppe> frankban: ta
[09:40] <frankban> rogpeppe: LGTM
[09:40] <rogpeppe> frankban: ta!
[10:24] <rogpeppe> frankban: next up: https://github.com/juju/charmstore/pull/67
[10:52] <rogpeppe> frankban, dimitern, TheMue, jrwren: a little fix: https://github.com/juju/charm/pull/38
[10:54] <TheMue> rogpeppe: one moment, meeting
[10:56] <rogpeppe> TheMue: np
[10:57] <TheMue> rogpeppe: quickly done, has been nicely small
[10:59] <rogpeppe> TheMue: ta!
[11:08] <frankban> rogpeppe: done
[11:08] <rogpeppe> frankban: thank you
[11:09] <rogpeppe> frankban: there's no CI set up on the charm package, is there?
[11:10] <frankban> rogpeppe: AFAIK there isn't
[11:14]  * frankban lunches
[11:40] <rogpeppe> frankban, TheMue, dimitern, jrwren, fwereade: update juju-core to use charm.v3: https://github.com/juju/juju/pull/489
[11:43] <dimitern> rogpeppe, reviewed
[11:43] <rogpeppe> dimitern: thanks!
[11:43] <TheMue> ah, I can step out, just started with review
[11:44] <TheMue> first shrugged about the number of files :)
[11:53] <rogpeppe> TheMue: it's almost all just import path changes
[11:58] <TheMue> rogpeppe: yeah, I’ve seen, additionally only those parts where the API changed
[11:58] <rogpeppe> TheMue: yup
[12:12] <frankban> rogpeppe, jrwren: could you please review https://github.com/juju/charmstore/pull/68 ? thanks
[12:12] <rogpeppe> frankban: looking
[12:12] <frankban> ty
[12:20] <rogpeppe> frankban: reviewed
[12:20] <rogpeppe> lc
[12:20] <frankban> rogpeppe: thanks
[12:21] <rogpeppe> frankban, jrwren: would appreciate a review of https://github.com/juju/juju/pull/489 please
[12:21] <rogpeppe> frankban: (the charm.v2 branch finally landed!)
[12:21] <frankban> rogpeppe: cool, and this is v3
[12:21] <rogpeppe> frankban: yup
[12:21] <frankban> rogpeppe: do we want core to use unstable v3?
[12:21] <rogpeppe> frankban: once core starts using it, it will no longer be unstable
[12:22] <frankban> rogpeppe: ok
[12:24] <jrwren> rogpeppe: done. I had looked earlier, but given its core, I didn't think I should +1.
[12:25] <rogpeppe> jrwren: please add your +1 - i'll wait for frankban's review too
[12:25] <jrwren> rogpeppe: done.
[12:25] <frankban> rogpeppe: done
[12:25] <rogpeppe> jrwren, frankban: thanks
[12:26] <rogpeppe> oh shit
[12:26] <rogpeppe> darn, forgot to update dependencies.tsv
[12:26] <rogpeppe> it won't land
[12:27] <frankban> rogpeppe: heh
[12:27]  * rogpeppe wishes there was some way of cancelling a jenkins job that's already started
[12:27] <rogpeppe> ha, no need, it's failed already
[12:28] <frankban> jrwren: I tried to not fully duplicate the manifest logic on the test side: that's probably the reason why you are confused
[12:28] <jrwren> frankban: Sounds good. I commented because I wanted to make sure it wasn't accidental.
[12:29] <frankban> jrwren: cool
[12:32]  * rogpeppe wants a merge tool that is a bit cleverer about go imports
[12:48] <jrwren> I didn't notice until now that running tests spins up its own mongod to run. Cool.
[13:43]  * rogpeppe goes for lunch
[14:17] <hatch> frankban can you remind me how I go about qa'ing your precise branch? 
[14:18] <hatch> I can't remember the best practice for pulling it down
[14:18] <frankban> hatch: thanks for looking at it
[14:18] <frankban> hatch: do you have a charm GUI shared repo?
[14:18] <frankban> GUI charm even
[14:18] <hatch> frankban I don't
[14:19] <hatch> can I check out just HEAD somehow?
[14:19] <frankban> hatch: so, time to create one ;-)
[14:19] <frankban> hatch: bzr init-repo juju-gui-charm
[14:19] <hatch> lol *sigh* I haven't had to set my vm up for bzr stuff again in a while
[14:19] <frankban> hatch: cd juju-gui-charm
[14:20] <hatch> ok got that far :)
[14:20] <frankban> hatch: bzr branch lp:~juju-gui/charms/trusty/juju-gui/trunk trunk
[14:21] <hatch> that's gona take a while :D
[14:21] <hatch> see u in 10 years :P
[14:21] <frankban> hatch: bzr checkout --lightweight trunk sandbox
[14:22] <hatch> I do that after it's done downloading the entire repo, correct?
[14:22] <frankban> hatch: bzr branch lp:~frankban/charms/trusty/juju-gui/fix-legacy-server
[14:22] <frankban> yes
[14:22] <frankban> hatch: cd sandbox
[14:22] <frankban> hatch: bzr switch ../fix-legacy-server
[14:22] <hatch> kadams54 looks like your branch has a test failure
[14:22] <frankban> make
[14:33] <jcsackett> kadams54: you need a second review, right?
[14:33] <kadams54_> jcsackett: yeah, and to figure out why one test is failing.
[14:34] <jcsackett> kadams54_: shall i wait till you've got that fixed?
[14:34] <kadams54_> jcsackett: I think it's safe to QA.
[14:34] <jcsackett> kadams54_: ok, i'll start reviewing now then.
[14:35] <kadams54_> jcsackett: thanks
[14:41] <hatch> jcsackett which view actually renders the charm details tabview when you click on the url?
[14:42] <jcsackett> hatch: i don't understand your question. you mean the charm url in the inspector?
[14:42] <hatch> when you click the charm url in the inspector
[14:42] <hatch> it opens a view
[14:42] <hatch> which view is that
[14:42] <jcsackett> hatch: it uses showViewelet to open the charmDetails viewlet.
[14:42] <jcsackett> which, in turn, uses browsercharmview...which in turn uses browserentitydetails, ircc.
[14:43] <jcsackett> turtles, all the way down.
[14:45] <luca__> when Juju is bootstrapped does the user have to define a name for it?
[14:46] <hatch> luca__ it is in the environments.yaml
[14:46] <hatch> we use that name in the GUI
[14:46] <luca__> hatch: I see, thanks.
[14:46] <luca__> hatch: and the user can have any name they want
[14:47] <luca__> hatch: ?
[14:47] <hatch> yep
[14:47] <hatch> it's used as the key to the environment config
[14:47] <hatch> so for example I have a `juju bootstrap ec2-precise` 
[14:47] <hatch> which is an ec2 env using precise as the default series 
[14:47] <hatch> there is also an ec2-trusty 
[14:47] <hatch> etc
[14:48] <hatch> jcsackett so why didn't you just prevent any click event on the anchor tags in the headers from bubbling from the tabview?
[14:49] <jcsackett> hatch: b/c we want it to dispatch to set the hash.
[14:50] <jcsackett> with the new dispatch model there's no reason those should be special cased from the other version of charm details.
[14:51] <hatch> right, but a hash should just be able to be added to the end of the url all easy like
[14:51] <hatch> jujugui call in 10
[14:52] <jcsackett> hatch: that's not how it appears to work in charm details land off the charmbrowser.
[14:52] <hatch> I was under the impression that the issue was that pjax was picking up the click and re dispatching?
[14:53] <jcsackett> hatch: talk after the call?
[14:53] <hatch> when it really should just be able to update the hash in the url, 
[14:53] <hatch> yeah sure
[14:53] <hatch> since we can't load the inspector in a real env I'm not sure how we can qa most of this anyways :)
[14:56] <jcsackett> we can't load the inspector in a real env?
[14:56]  * jcsackett thinks he missed something.
[14:56] <jcsackett> and anyway, this was a bug with fakebackend too.
[14:56] <hatch> nope it opens to a white sidebar and the charm details pane open - also blank
[14:57] <jcsackett> when did that start happening?
[14:57] <jcsackett> (you can still qa this against fakebackend--a real env wasn't necessary to create the bug)
[14:57] <hatch> you were fixing it, and stopped because we were trying to get something else done....or something along those lines
[14:57] <hatch> :)
[14:57]  * jcsackett blinks.
[14:57] <jcsackett> i haven't seen this happen in a real env, and don't recall what you're talking about.
[14:58] <jcsackett> i recall a bug about this awhile ago, but i recall fixing that.
[14:58] <hatch> if you visit a /inspector url in a real env you'll see it
[14:59] <hatch> you fixed something in there by adding a retry 
[14:59] <hatch> but this was something else i remeber you saying
[14:59] <jcsackett> do we have a bug/card? b/c the only thing i recall related to this was quite old.
[14:59] <hatch> yeah I can find it
[15:00] <jcsackett> kadams54_: is your bug only about the deploy summary? the changelog is still showing individual everything.
[15:00] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1349565
[15:00] <kadams54_> jcsackett: Correct. Deploy summary is condensed, changelog shows everything.
[15:01] <jcsackett> kadams54_: cool.
[15:01] <kadams54_> That's what hatch and I decided after talking through the bug.
[15:14] <luca__> hatch: have you finished the new scale up journey
[15:14] <luca__> hatch: ?
[15:15] <hatch> luca__ in the inspector?
[15:15] <hatch> or in the machine view?
[15:15] <luca__> hatch: in the inspector
[15:16] <hatch> yes that's done with the exception of Huw's branch in review which adds the "1 unit (3 uncommitted)"
[15:16] <hatch> stuff
[15:16] <hatch> that should be landing during his day as there are a couple issues with it atm
[15:18] <hatch> frankban how do I check what branches I have/ what branch I'm on?
[15:19] <frankban> hatch: bzr info
[15:20] <hatch> thanks
[15:20] <hatch> :)
[15:21] <frankban> hatch: also bzr branches can help
[15:24] <hatch> frankban so what does the bzr switch do? Is it like a merge?
[15:24] <rogpeppe> hatch: bzr switch is a cobzr extension (unless the native bzr has it now)
[15:25] <rogpeppe> hatch: it's just like git checkout
[15:25] <hatch> oh ok - native bzr must have it because I didn't install cobzr
[15:26] <frankban> hatch: it switches to another branch, so that you can always work on sandbox
[15:27] <hatch> frankban ok so make has been completed so now I can just deploy this as a normal charm?
[15:27] <frankban> hatch: now you can follow the instructions on my MP
[15:27] <frankban> hatch: in particular, make deploy lets you deploy what's on sandbox without having to setup a local juju repo
[15:28] <hatch> great 
[15:28] <frankban> hatch: and from now on, you can "bzr branch" GUI charm branches from inside the shared repo, and it will be cheap and fast
[15:29] <hatch> note to self- DO NOT DELETE FOLDER
[15:29] <hatch> :)
[15:30] <frankban> hatch: for instance, if you want to work on a new GUI charm branch, you: 1) cd to sandbox 2) ensure there are no uncommitted changes 3) bzr switch ../trunk 4) bzr pull and 5) bzr switch -b my-feature-branch
[15:30] <hatch> sounds a lot like how bzr should work by default :)
[15:31] <frankban> hatch: it supports lightweight checkouts by default actually, no need for cobzr or stuff like that
[15:32] <frankban> hatch: all my bzr repos are set up like that. lightweight checkouts are not as fast as git named branches, but they are good enough
[15:33] <frankban> guihelp: any of you do use zsh? I'd like to give it a try
[15:34] <kadams54_> I do, though I'm not really a power user
[15:34] <hatch> frankban rick does, I did but it kept borking with my tmux stuff
[15:34] <hatch> now that I'm back working in Ubuntu full time I will likely give it a go again
[15:34] <frankban> hatch: hmm, I also use tmux
[15:35] <frankban> hatch: it seems autocomplete, hostory search and such work much better
[15:35] <hatch> frankban I think the issue was that there are just so many layers running when you have zsh and tmux that they clashed for me because I kept customizing them
[15:35] <frankban> kadams54_: ^^^
[15:36] <frankban> I am taking a look at https://github.com/robbyrussell/oh-my-zsh
[15:36] <kadams54_> Yeah, that's what I use
[15:36] <kadams54_> https://github.com/kadams54/dotfiles - feel free to poke around in my zshrc
[15:37] <frankban> kadams54_: great thanks
[15:38] <hatch> I find the hardest thing to do is colouring
[15:39] <hatch> terminal + zsh + tmux = colour hell
[15:40] <kadams54_> I agree: colouring = hell. Coloring, on the other hand, is as easy as pie.
[15:41] <kadams54_> ;-)
[15:41] <jrwren> I don't use zsh, how does it affect colour?
[15:41] <hatch> lol
[15:42] <hatch> jrwren because you can set themes in it
[15:42] <hatch> so you have three things setting colours so when something is wrong it's hard to track down what is setting the colour
[15:42] <jrwren> What is there to theme other than a prompt?
[15:42] <hatch> typical linux boy
[15:42] <hatch> :P
[15:43] <jrwren> Its true, as I sit at my OSX terminal :)
[15:43] <hatch> hahaha
[15:43] <hatch> lemme guess it's iterm2 isn't it?
[15:43] <jrwren> yes.
[15:43] <jrwren> You win a prize!
[15:43] <hatch> man I wish Ubuntu had an iterm2 clone
[15:43] <kadams54_> frankban: https://github.com/scrogson/dotfiles is a friend of mine who does a lot more with tmux and zsh.
[15:44] <jrwren> hatch: quake key is built in!
[15:44] <hatch> jrwren not quite the same :)
[15:45] <hatch> atm I'm really struggling with the font rendering in Ubuntu, trying to find something to make it prettier 
[15:49] <hatch> jujugui does anyone know how to hide the comments in a PR on GH?
[15:49] <rogpeppe> hatch: rebase :-)
[15:50] <hatch> lol
[15:51] <kadams54_> OK, driving back home. Be back online in about two hours.
[16:15] <hatch> frankban "unable to get bundle deployment statuses" notification and the juju-gui charm has no icon
[16:15] <hatch> are these to be expected on the legacy server?
[16:15] <frankban> hatch: yes
[16:15] <hatch> cool
[16:16] <hatch> +1'd shippppit
[16:20] <hatch> jcsackett qa issue with your branch 
[16:20] <hatch> repro instructions in the pr
[16:27] <frankban> hatch: thanks!
[16:28] <jcsackett> hatch: huh.
[16:28] <jcsackett> hatch: well, that's annoying.
[16:28] <hatch> :) sorry
[16:28] <jcsackett> i'll figure it out post-lunch.
[16:28] <jcsackett> all good, better to catch it now than after landing. :p
[16:33] <frankban> hatch: I am starting the process for a new charm release
[16:33] <hatch> thanks a lot! 
[16:34] <hatch> these charm releases are kind of a pita :)
[17:02] <rick_h__> guten tag
[17:02] <rick_h__> frankban: zsh <3
[17:07] <rick_h__> frankban: I'll try to get you some sample stuff sometime.https://github.com/mitechie/zshrc
[17:07] <rick_h__> frankban: ^ is a lighting talk I gave long ago on some reasons to <3 zsh
[17:07] <frankban> rick_h__: nice thanks!
[17:08] <rick_h__> frankban: but when I get back can get my zshrc out if you need anything
[17:11] <frankban> rick_h__: cool
[17:13] <hatch> rick_h__ AHOY!
[17:19] <rick_h__> hatch: howdy!
[17:19] <rick_h__> train wifi is stinky on this return trip
[17:19] <hatch> choo choo
[17:19] <rick_h__> and now the train is stopped...hmmm
[17:19] <rick_h__> hatch: how goes?
[17:19] <rick_h__> sent an email to the list, basically a big high-five
[17:20] <hatch> it's going, saw your mountain picture, still jealous NBD!
[17:20] <hatch> :)
[17:21] <rick_h__> MV almost done :P 
[17:21] <hatch> slowly but surely 
[17:21] <hatch> doing a lot of reviews and qa's so something must be getting done :)
[17:26] <rick_h__> damn net keeps dropping
[17:27] <rick_h__> anyway, reminder I'm afk for a bit. Uros can answer stuff tomorrow but not much to say for now. 
[17:28] <hatch> yep np, you go enjoy your vacation
[18:08]  * rogpeppe is done for the day
[18:08] <rogpeppe> g'night all
[18:18]  * kadams54 is back
[19:25] <jcsackett> hatch: i just realized i didin't commit and push my qa-fix. so i've done that, if you want to look at the PR again. :p
[19:25] <hatch> haha sure ok
[19:25] <jrwren> https://github.com/CanonicalLtd/charmstore-charm/pull/2
[19:25] <jrwren> err..
[19:27] <hatch> jcsackett big fix lol
[19:27] <jcsackett> hatch: right?
[19:28] <jcsackett> just huge. :p
[19:29] <hatch> haha
[19:30] <hatch> jcsackett so I see you set rendered to false in the charm details....that means that we are using the same instance of charm details all the time?
[19:31] <hatch> after a class has been 'destroyed' typically you don't revive it again
[19:32] <jcsackett> hatch: yeah, instead we keep creating new browsercharmdetail views.
[19:33] <jcsackett> hatch: i believe this is true predating this branch; i think it's something to do with how we're creating viewlets, mixed with how inspector has evolved.
[19:33] <jcsackett> 1 more for the "we need to clean up slots/viewlets" pile.
[19:33] <hatch> ohh so the issue is that the pointer to the charmView to check if it should create new or update is still pointing to the destroyed version
[19:33] <jcsackett> hatch: where? happy to fix that now.
[19:34] <hatch> jcsackett I added a comment to the line I THINK is the right place
[19:35] <hatch> basically you are having to set rendered to false when something is destroyed when really we should just be checking if it was destroyed 
[19:36] <jcsackett> hatch: i find it non-intuitive that a "destroyed" object still exists so i can check it.
[19:36] <jcsackett> :p
[19:37] <hatch> jcsackett haha blame javascript
[19:38] <jcsackett> oh, i do. i do.
[19:38] <jcsackett> :p
[19:38] <hatch> in python when you destroy a class instance does it destroy all references to it as well?
[19:38] <jcsackett> for so *many* things.
[19:38] <hatch> I guess python has NATIVE classes though
[19:38]  * jcsackett nods
[19:38] <hatch> jcsackett we could always switch to Dart :) 
[19:39] <jcsackett> i don't know enough about Dart to immediately nix that, but i'm going to guess it's not worth the rewrite. :p
[19:41] <hatch> haha no, no it's not
[19:41] <hatch> but if we were starting new I would seriously consider it
[19:41] <hatch> the GUI is now sufficiently complicated I can no longer keep its execution flow in my head
[19:41] <hatch> *sadface*
[19:42] <jcsackett> hatch: i hear that.
[19:44] <hatch> time to go pick up a copy of visio and graph it all :P
[19:46] <hatch> jcsackett +1'd with trivials, lemme know if the test request makes sense
[19:46] <jcsackett> hatch: i may have to keep the 'rendered' in destroy hack; doing it with checking 'destroyed' is leading to the pane opening with no content on the second click.
[19:46] <jcsackett> i think the slot system doesn't clean up after itself right this way--we're forcing it do things it's not really built for.
[19:47] <hatch> son-of-a
[19:48] <hatch> ok then, I think my test request still holds
[19:48] <jcsackett> hatch: do you mean add a test showing that it handles the destructor thing? because this path doesn't involve the destruction cycle.
[19:48] <jcsackett> this, for example, might be clicking one tab and then another.
[19:49] <jcsackett> if you mean "update the test to include seeing what destroy does" +1, if you mean something else, i don't follow. :)
[19:50] <hatch> yeah sorry - I meant test the destructor cycle, because we had to add that into there to make sure it did what it was supposed to do
[19:51] <jcsackett> hatch: and i can now confirm that showViewlet is reviving the "destroyed" viewlet, so rendered needs to be set to false. i'll add an XXX to explain that the viewlet stuff isn't destroying things properly.
[19:51] <hatch> excellent thanks
[19:51] <hatch> ubuntu looks about 1M x better on a non-retina screen :)
[19:51] <hatch> I wonder who I poke to see about getting that fixed
[19:52] <hatch> the font rendering that is
[20:31] <hatch> jujugui do we have any UI for removing units from machines? 
[20:31] <kadams54> I don't think so
[20:34] <hatch> kadams54 so the only way atm to remove a unit is via the services inspector?
[20:34] <kadams54> Yes
[20:35] <hatch> hmm then the lazy remove unit method is incorrect
[20:35] <hatch> *sigh*
[20:35] <hatch> in fact, I don't see how it was ever right hah
[20:37] <hatch> actually kadams54  looks like you wrote it....do you remember when you wrote the remove unit method in the ECS? 
[20:37] <kadams54> Sure
[20:38] <hatch> ok one sec 
[20:39] <hatch> kadams54 https://github.com/juju/juju-gui/blob/develop/app/utils/environment-change-set.js#L691 so right here you assign args[0] to service then use it as a service.....but args[0] was always an array of units to remove...
[20:39] <hatch> or am I missing something
[20:41] <hatch> I'll create a follow-up card to fix this but atm there is no way this could work to remove ghost units....at least I don't see how it could
[20:42] <hatch> weird it does work
[20:42] <hatch> lol
[20:43] <kadams54> I see what you mean, but I'm not sure why it wouldn't work
[20:43] <kadams54> It seems like it would, just maybe not with the API it should have
[20:45] <hatch> well because args[0] is an array
[20:45] <hatch> and you're checking if command.args[0] [20:45] <hatch> so it can only ever remove a single unit if a single unit was added
[20:46] <hatch> it'll work for a real unit, but not for ghosted stuff
[20:46] <hatch> does that sound right?
[20:47] <kadams54> No?
[20:47] <kadams54> Seems to me like it'll work for a single unit but not multiple. Ghosted or not doesn't matter.
[20:48] <kadams54> Ah, OK, I see… that comparison only happens when checking for ghosted.
[20:48] <hatch> well the real units it would just pass to the changeset and execute the args via the backend
[20:48] <hatch> yeah
[20:48] <hatch> :)
[20:48] <kadams54> But if you only pass a single ghosted, that should still work
[20:49] <hatch> yeah ok I'll file a bug/card so we don't forget about this and release it
[20:49] <hatch> heh
[20:51] <hatch> kadams54 https://bugs.launchpad.net/juju-gui/+bug/1355440
[20:51] <hatch> does that make sense? :) 
[20:52] <hatch> card created in project 1 - if it doesn't please update it 
[21:20] <jcsackett> jujugui: i need another review on https://github.com/juju/juju-gui/pull/487 
[21:33] <hatch> don't everyone jump at once ;)
[21:48] <hatch> jcsackett do you know when matt is back?
[21:54] <hatch> jujugui does anyone else get a drop error when trying to drag and drop in chrome on ubuntu?
[21:54] <hatch> happens about 50% of the time for me
[21:55] <hatch> I have to drag and drop fast for it to not it seems
[23:01] <huwshimi> Morning
[23:02] <hatch> morning huwshimi 
[23:04] <huwshimi> hatch: How's things?
[23:04] <hatch> truckin along, spent a lot of time today doing qa heh
[23:04] <hatch> I looked at your branch and was getting a failure in a totally different spot than you mentioned
[23:04] <hatch> so I figured I better wait to see what you said
[23:05] <huwshimi> oh dear
[23:05] <huwshimi> hatch: What error did you get?
[23:05] <hatch> same one that's listed in the CI failure
[23:08] <huwshimi> hatch: Yeah, that's the same thing, I just pointed to where the tests are actually failing
[23:08] <hatch> oh....damn
[23:11] <hatch> huwshimi ok so I can look into this when I get back in a couple hours, have to go run some errands and whatnot
[23:12] <huwshimi> hatch: sure, no problems. Much appreciated.
[23:12] <hatch> bbl cya
[23:14] <jcsackett> hatch: https://bugs.launchpad.net/juju-gui/+bug/1323924