[00:00] <huwshimi_> :)
[00:04] <rick_h_> ah crap
[00:05] <huwshimi_> uh oh
[00:05] <rick_h_> huwshimi_: please go to your develop branch and do a sync from upstream develop
[00:05] <rick_h_> and QA the changes per your expected 
[00:06] <rick_h_> I accidently pushed the cleanup to juju develop and so it's in there now
[00:06] <rick_h_> I'm running tests to make sure they're ok atm
[00:06] <rick_h_> but I cherry-picked things and want to make sure the fixes are still good for the css/etc
[00:07] <rick_h_> tests pass
[00:08] <rick_h_> hatch: still around?
[00:10] <huwshimi_> rick_h_: I think it's all good
[00:10] <rick_h_> huwshimi_: k, the diff in the commits look good
[00:10] <rick_h_> so going to call this closed
[00:10] <rick_h_> sorry for the mess up
[00:10] <rick_h_> my fault for trying to take a shortcut
[00:10] <rick_h_> since my network bandwidth is a trickle atm
[00:11] <rick_h_> huwshimi_: remind me next time we have a AU call to go through some techniques for helping with this
[00:11] <huwshimi_> rick_h_: OK great, thanks!
[00:12] <hatch> huwshimi_ I am 
[00:12] <huwshimi_> rick_h_: ^
[00:12] <rick_h_> hatch: can you verify that develop QA's ok for you in safari for the bugs mentioned? 
[00:12] <hatch> sure 
[00:13] <hatch> rick_h_ I was wondering if we could use merge --squash or there is also a merge which doesn't use a merge commit for CI merging into develop
[00:14] <rick_h_> hatch: well he had 3 nice commits so I just updated develop, cherry picked the 3 revs, fixed on conflict
[00:14] <hatch> right, I am asking in more general terms
[00:14] <hatch> because we now get the 'real' commit and a merge commit
[00:14] <rick_h_> but when I pushed I tried to push to a new branch on juju `git push juju safari-bugfix-cleanup` but it went straight to develop :/
[00:14] <hatch> haha oops
[00:14] <rick_h_> yea :/
[00:17] <hatch> rick_h_ huwshimi_ qa looks good here 
[00:18] <rick_h_> hatch: cool thanks for the check
[00:18] <rick_h_> huwshimi_: thanks for the updates. If you get a chance to check if it helps the FF issue I'd appreciate it
[00:18] <rick_h_> at least a yay/nay for fix so we can close the bug
[00:19] <hatch> rick_h_ have you looked at the git merge --squash flag to see if we can use it and not rebase?
[00:20] <hatch> and also use --ff
[00:20] <hatch> to make it not create a merge commit
[00:20] <hatch> just ideas - I don't reallly know if they will do what I think they do, but it would be cool if they did
[00:20] <rick_h_> hatch: I want to, have not yet
[00:20] <rick_h_> I know there's a pattern around this that's simple that we're missing but haven't had a chance to find it yet
[00:21] <hatch> ok np just wanted to see if it was on  your radar
[00:21] <hatch> the rebase seems to be causing peeps issues
[00:21] <rick_h_> yea, definitely
[00:21] <huwshimi_> rick_h_: I thought one of my other changes had fixed that bug, but it doesn't seem to be now (might be a different version of Firefox)
[00:21] <hatch> the GUI actually runs very well with safari
[00:21] <rick_h_> huwshimi_: k
[00:21] <hatch> really fast and smooth
[03:34] <hatch> huwshimi_ so do we now support Safari? 
[03:35] <hatch> at least as far as the sandbox is concerned?
[03:42] <huwshimi_> hatch: Nope, need to get the export working as well.
[03:42] <hatch> ahh ok cool, so is that css card on the board done now too?
[03:43] <huwshimi_> hatch: Yeah, I guess that one is done now. It's already landed :)
[03:45] <hatch> cool, it'll be nice to support yet another browser
[03:45] <hatch> well....nice for others...lol
[03:51] <huwshimi_> hatch: Yeah, the testing matrix gets harder though
[03:52] <hatch> yup yup
[04:06] <rick_h_> adding support in CI should be pretty easy though
[11:09] <rick_h_> frankban: morning
[11:09] <frankban> morning rick_h_ 
[11:09] <rick_h_> frankban: got time to chat this morning?
[11:10] <frankban> rick_h_: sure
[11:11] <rick_h_> frankban: https://plus.google.com/hangouts/_/76cpj3qusk9dek11oh8t82jcfo?authuser=1&hl=en
[12:05] <bac> rick_h_: how's the jetlag?  looks like you were up early again.
[12:43] <rick_h_> bac: yea, but this was intentional. Wanted to chat before I took the boy to day care
[12:43] <rick_h_> bac: but yea, I'm still an early guy though 6am is best yet :)
[12:50] <rick_h_> bac: when you get a sec wonder if we can chat. 
[12:50] <bac> rick_h_: sure.  send me an invite
[12:51] <rick_h_> bac: k, give me a couple min thanks
[12:52] <rick_h_> bac: https://plus.google.com/hangouts/_/76cpi3hmf68o8olj07cmo27r64?authuser=1&hl=en
[14:50] <hatch> so....systemd eh?
[14:50] <rick_h_> yep, we'll see how that goes 
[14:52] <hatch> ugh
[14:53] <hatch> I'm not super educated on it, but it sure seems to me that upstart was the winnder technically
[14:53] <hatch> winner
[15:31]  * benji watches a 900K zip of the GUI charm being built in the browser.
[15:31] <rick_h_> wooooo!
[15:35] <hatch> benji right on! I'm a little jealous that you're working on that
[15:35] <hatch> :D
[15:35] <benji> :)
[15:35] <benji> it's been fun; a little slower than I had hoped, but fun
[15:36] <benji> now if I can just figure out this "RangeError: Offset is outside the bounds of the DataView" when the zip file is actually used, I'd be happy
[15:36] <hatch> hmm that does sound like an odd one
[15:37] <hatch> in other good news, you can now drop a zip onto the inspector too
[15:42] <hatch> oop someone got pulled over
[15:44] <hatch> has anyone ever 'played' Core Wars before?
[15:52] <rick_h_> jujugui call in 8
[15:54] <hatch___> does anyone know if we know what the series is once a charm has been deployed? The service model where I would expect it is absent - that could be because we don't populate it in the sandbox, but I'd like some confirmation that we have it before I spin up an env (if possible)
[15:55] <hatch___> apparently my ghost is hanging around heh
[15:55] <rick_h_> hatch___: hmm, well we have series info in the charm url? 
[15:56] <rick_h_> hatch___: ah, but this is a local one I imagine?
[15:56] <benji> hatch: I played around with core wars a little a long time ago
[15:59] <rick_h_> jujugui call in 1
[16:05] <hatch> rick_h_ ahh right I can split the series out of the url, thanks I'll do that
[16:21] <hatch> benji yeah? I was trying to figure it out last night....I don't understand why you wouldn't just set a bomb after you move forward every time then just wait for the other warrior to hit it
[16:21] <bac> hey frankban, can you look at juju-deployer/charm.py for a sec?  at the end of _fetch_store_charm is he doing something clever or is it just a bug?
[16:22] <bac> frankban: it looks like he means to 'return self.config' but isn't
[16:22] <hatch> rick_h_ it looks like we handle the undefined default case in the databainding
[16:22] <frankban> bac: looking
[16:22] <hatch> databinding
[16:22] <benji> hatch: I don't remember enough about it to make a cogent response :)
[16:22] <hatch> so maybe we can do it
[16:22] <hatch> banji oh haha gotcha
[16:22] <rick_h_> hatch: right, but as a read. We don't have a way to write that or am I mistaken?
[16:22] <bac> banji: when benji plays a banjo
[16:23] <benji> heh
[16:26] <hatch> rick_h_ sorry just looking now
[16:27] <hatch> rick_h_ if the field is an input and it's '' then it returns it as null
[16:27] <hatch> this is of course not possible with a checkbox
[16:28] <rick_h_> hatch: interesting. maybe we're in better shape than we think then. 
[16:28] <frankban> bac: it seems to me that line can be removed. it calls a property but I don't see any required side effects from that property
[16:28] <rick_h_> so we need to do something to test that null gets to an unset into the api call to core
[16:29] <bac> frankban: ok, but the _fetch_charm_store doesn't return anything.
[16:29] <hatch> right, you can see the code in utils:_getElementsValuesMapping()
[16:29] <hatch> sorry views/utils.js:_getElementsValuesMapping()
[16:29] <frankban> bac: it does not seems the caller really needs it to return something
[16:29] <rick_h_> hatch: cool, can you file a bug along those lines with the info you've got there?
[16:29] <rick_h_> and we can look into it
[16:30] <bac> frankban: i'd be more confident monkeying around with it if the method were tested...  :(
[16:30] <hatch> what's the title of the bug?
[16:30] <hatch> :)
[16:30] <hatch> unfortunately launchpad doesn't really have a 'task' bug type :)
[16:30] <rick_h_> hatch: juju gui doens't use juju unset for config updates 
[16:30] <frankban> bac: agreed
[16:30] <hatch> sounds good
[16:30] <rick_h_> hatch: and put the notes in there and we can see what the actual diff needs to be to make it work. 
[16:31] <hatch> well we'll need some type of UI element for the checkboxes regardless
[16:31] <hatch> but that might be ok...
[16:31] <rick_h_> hatch: well, can a checkbox be undefined? I think that's a big nuts
[16:31] <rick_h_> I mean it's a boolean
[16:31] <rick_h_>  /big/bit
[16:31] <hatch> if you define a config option as a boolean but don't give a default is it then undefined?
[16:32] <rick_h_> I think it should be a lint error tbh
[16:32] <hatch> marcoceppi ^ 
[16:34] <rick_h_> hatch: link to the bug when it's up and I'll send the email back to the thread so they can watch it
[16:38] <hatch> rick_h_ https://bugs.launchpad.net/juju-gui/+bug/1279414
[16:38] <_mup_> Bug #1279414: The Juju GUI doesn't use juju unset for config updates <juju-gui:New> <https://launchpad.net/bugs/1279414>
[16:38] <rick_h_> hatch: thanks
[16:43] <hatch> jujugui can someone help me out with a regex to extract the series from "cs:precise/my-charm-name-12" ? I'm using splits right now but it's kind of ugly
[16:43] <benji> hatch: you rang?
[16:43] <benji> :)
[16:43] <rick_h_> lol, the charm model already has code to do this I thought
[16:43] <rick_h_> but benji is regex master
[16:43] <hatch> haha
[16:44] <hatch> rick_h_ I can look
[16:45] <hatch> rick_h_ doesn't look like it. The charm model has a series attribute, the service one does not
[16:45]  * marcoceppi reads back
[16:46] <hatch> marcoceppi see bug #1279414 as well plz
[16:46] <marcoceppi> hatch: rick_h_ in the proposal, only int and string can be undefined
[16:46] <_mup_> Bug #1279414: The Juju GUI doesn't use juju unset for config updates <juju-gui:New> <https://launchpad.net/bugs/1279414>
[16:46] <rick_h_> marcoceppi: cool, that makes sense then
[16:46] <marcoceppi> I explicitly stated that booleans must remain with a default of a boolean, or lint will throw an error
[16:46] <hatch> ok so then we are in a pretty good spot
[16:46] <rick_h_> marcoceppi: we've got a bug to verify and update to support the idea of unset. 
[16:46] <rick_h_> marcoceppi: so we'd ask that the policy not change until we can get it all setup. Next week probably
[16:46] <hatch> marcoceppi can a field be 'null' or are 'null' and unset the same?
[16:47] <marcoceppi> rick_h_: that's fine
[16:47] <marcoceppi> hatch: unset is just juju reverting to the default value
[16:47] <marcoceppi> so a default of null (python None) is a valid default for a configuration option
[16:47] <hatch> and so is an empty string?
[16:48] <marcoceppi> hatch: no, empty string is not None
[16:48] <hatch> I mean, it's a valid value
[16:48] <marcoceppi> hatch: correct
[16:48] <marcoceppi> default: "" is no problem, because you can juju set cfg=""
[16:48] <hatch> rick_h_ ^ so this means we need a separate UI element for 'reset' :/
[16:48] <marcoceppi> but you can't ever run juju set cfg=None
[16:49] <hatch> ahh our issue is that the UI does not let you set anything other than an empty string 
[16:49] <rick_h_> hatch: well, it's what we're doing already though based on what you're saying. We need to test it and see what we're doing.
[16:49] <hatch> so right now we consider an empty string to be null
[16:50] <marcoceppi> so, that's why the policy in proof has always done strict type checking, if it's a string the default must be a string. Some charmers, *cough* james *cough* use default: null in charms to test if a config has been set, etc. Now that we have juju unset you can actually revert to a None (if it's the default value) so we're amending the rules to keep these people happy
[16:50] <hatch> rick_h_ right but from what I'm seeing here is that we are doing it incorrectly
[16:50] <rick_h_> hatch: because if we're already setting to null and no one's complained so far I kind of wonder how much is 'theoritical'
[16:50] <rick_h_> hatch: right
[16:51] <hatch> so we need a reset button :(
[16:51] <marcoceppi> Really each option should essentially have a reset to default, which would invoke either juju unset or some other fashion to put the value back to the default for that config option
[16:51] <hatch> marcoceppi right, that's just easier said than trying to find some UI to do that :D
[16:51] <marcoceppi> haha ;)
[16:52] <rick_h_> hatch: hangout on the way
[16:52] <marcoceppi> hatch: rick_h_ I can definintely keep the proof rules as it for now, but charms already exist with None defaults and it hasn't really messed up much
[16:52] <rick_h_> marcoceppi: right, cool
[16:52] <hatch> rick link? my phone answered it
[16:52] <rick_h_> hatch: https://plus.google.com/hangouts/_/76cpjdqgqe3robu1q9isu6kr2o?hl=en
[16:52] <marcoceppi> there's just no way to put it back to None
[16:52] <rick_h_> marcoceppi: gotcha
[17:08] <bac> hazmat: you around? Could you review https://codereview.appspot.com/52600045 (juju-deployer) when you get a chance?
[17:09] <rick_h_> bac: he's on vaca this week still I believe so might not hear back until next week
[17:10] <bac> rick_h_: ok.  well if i don't hear back by EoD i'll move my card out of the way, somewhere
[17:10] <rick_h_> bac: k, maybe get a review from frankban if he's able to at least get a sanity check
[17:10] <rick_h_> bac: and then it's just a landing issue?
[17:10] <bac> sure
[17:10] <bac> frankban: ^^
[17:11] <bac> frankban: i was also going to ask for a review of juju-gui charm https://codereview.appspot.com/61510051.  trivial change.
[17:11] <bac> frankban: but if you're eod i'll get someone else to look at it
[17:11] <frankban> bac: sure, I'll look at it, EOD in 50
[17:12] <bac> thanks frankban.  note there are two: charm and deployer
[17:12]  * bac lunches
[17:20] <hatch> benji hey so were you going to get me that regex? ;)
[17:22] <benji> hatch: I guess it turned out we didn't have a funciton to do that then.  Let's see... is the string always of that form?  I.e., is the "cs:" prefix always there?
[17:22] <hatch> yep
[17:23] <hatch> thanks :)
[17:24] <benji> hatch: > 'cs:precise/my-charm-name-12'.match(/[^:]*(?=\/)/)[0]
[17:24] <benji> 'precise'
[17:24] <hatch> nice :) now I wish I knew why that worked
[17:24] <hatch> :)
[17:25] <hatch> not anything before the :
[17:25] <benji> if JS had look-behind assertions it would have been a little simpler
[17:25] <benji> hatch: here's the explanation
[17:25] <rick_h_> [^:]* - find anything not a : and eat it up
[17:25] <rick_h_> ah, benji with the notes 
[17:26] <benji> rick_h_: I was just setting up your explanation
[17:26] <hatch> lol
[17:27] <benji> [^:] means anything not a colon ([abc] means any of a b or c, the carat after the opening bracket means "not")
[17:27] <benji> * means zero or more, of course
[17:28] <benji> and then (?=XXX) is a forwar assertion that the next thing is XXX (but that next thing isn't included in the match)
[17:28] <benji> for XXX we want a forward slash, but it has to be escaped otherwise we would be ending the regex, so we have \/
[17:29] <benji> hatch: make sense?
[17:30] <hatch> it does thank!
[17:30] <hatch> s
[17:30] <hatch> I just don't write enough regex to get decent at it :)
[17:31] <benji> they're a little like APL, writing them isn't that hard once you get used to it, reading them is the real challenge
[17:32] <benji> here's some lunch time APL for all you fine folks out there: http://www.youtube.com/watch?v=a9xAKttWgP4
[17:33] <hatch> haha oh boy APL
[17:42] <frankban> bac: https://codereview.appspot.com/61510051/ done
[17:49] <frankban> guihelp: I need two reviews for https://github.com/juju/juju-gui/pull/123 . anyone available? thanks!
[17:50] <hatch> I'll take it
[17:50] <hatch> take one
[17:52] <rick_h_> frankban: looking
[17:52] <frankban> hatch, rick_h_: thank you
[18:29] <frankban> bac: both reviews done. EOD have a nice evening
[18:30] <rick_h_> have a good night frankban 
[18:31] <hatch> rick_h_ looks like selenium failed the safari tests
[18:31] <rick_h_> hatch: ah cool
[18:31] <hatch> and it's a full on blizzard here :/
[18:31] <rick_h_> hatch: :P
[18:32] <hatch> I WAS going to go work elsewhere today
[18:32] <hatch> not worth it now
[18:32] <hatch> lol
[18:32] <hatch> did you guys see the backup subordinate charm? Looks pretty cool
[18:33] <rick_h_> heard of it but not checked it out yet
[18:33] <hatch> I'll have to put some more time into it, but it -looks- like you can add it to any charm and if the charm is configured, will back it's contents up
[18:35] <rick_h_> hmm "attemped to assign to read only property"
[18:35] <rick_h_> is the failure that caused it to go boom
[18:36] <hatch> rick_h_ what's the full error message?
[18:37] <hatch> er
[18:37] <hatch> line it's on
[18:37] <hatch> sorry brain fade
[18:37] <rick_h_> hatch: bah, closed it. It's a pain to time the video at the right spot to get it
[18:37] <hatch> is it around the XHR stuff?
[18:37] <rick_h_> sec
[18:37] <hatch> sorry :)
[18:38]  * rick_h_ is going to feel like he needs to get an air if we support safari
[18:39] <rick_h_> "must cull removed services from the existing list"
[18:39] <rick_h_> assets/muodles.js line 8
[18:39] <rick_h_> "attempted to assign to readonly property"
[18:39] <rick_h_> from test_environment_view.js 1430
[18:39] <rick_h_> hatch: ^
[18:39] <hatch> looking
[18:40] <hatch> what the heck...
[18:40] <hatch> let me try and run the test suite in safari
[18:40] <hatch> give me a couple mins
[18:41] <rick_h_> k, all good. I'm moving the card back todo for now. I wanted to see if they would pass but not atm
[18:44] <hatch> rick_h_ I can reproduce, just trying to figure out the safari inspector to see how a custom var is readonly
[18:44] <hatch> the safari inspector is actually pretty cool 
[18:45] <rick_h_> hatch: yea, should be close to chrome as it's webkitt based
[18:45] <hatch> all pretty colours and such lol
[18:45] <hatch> no it's entirely different odly enough
[18:45] <rick_h_> oh, it used to be close 
[18:45] <rick_h_> oh well, shows how long it's been since I played on a mac
[18:46] <rick_h_> resolutoin on an air kind of stinks :/
[18:46] <hatch> yeah, I'm guessing they might upgrade it on the next update...but then it'll take a battery life hit and be hard to choose the MBP13" 
[18:46] <hatch> I think that's why they haven't updated it
[18:47] <rick_h_> the xps 13 has 1920 and hours of battery life
[18:47] <hatch> because the MBP13" is really just a big air
[18:47] <hatch> I've never come anywhere close to Dell's advertised battery life
[18:47] <rick_h_> was just looking at reviews
[18:47] <rick_h_> so they were review results but yea
[18:47] <rick_h_> not "rick hard at work" results
[18:47] <hatch> haha yeah, this MBP battery life is garbage
[18:48] <hatch> they do the tests 'playing video' which this thing lasts almost 11H on a charge
[18:48] <hatch> open IRC? 5h
[18:48] <hatch> lol
[18:48] <hatch> I think it's the wifi
[18:48] <hatch> anyways - I see the problem
[18:49] <hatch> it's that we are trying to assign a value to a property which is undefined
[18:49] <rick_h_> cool, well no rush. Just was curious
[18:49] <rick_h_> lol, go us
[18:49] <hatch> so 'undefined' is read-only in strict mode
[18:50] <hatch> rick_h_ I'll add the details to the card and then get to fixing it after this local charm stuff
[18:51] <rick_h_> hatch: cool. Yea it's lower priority but seems we're almost there so would be cool to have 
[18:53] <hatch> rick_h_ updated with details
[18:53] <hatch> looks like it's the only test failure though
[18:53] <rick_h_> hatch: thanks
[18:53] <hatch> so yay
[18:53] <rick_h_> well it only ran some 48% of the tests before stopping
[18:53] <rick_h_> hatch: did the rest run for you?
[18:54] <hatch> rick_h_ yes it completed the run and it was the only failure
[18:54] <rick_h_> hatch: oh, very cool then
[18:54] <hatch> took about 50s
[18:54] <rick_h_> like I was saying, we're darn close
[18:54] <rick_h_> yay
[18:54] <hatch> which is the fastest of any browser
[18:54] <hatch> impressive
[18:54] <rick_h_> hmm, 13" air looks nice except for resolution. 
[18:55] <hatch> yeah that's what drove me into the Pro line....then the 13" pro was overpriced imho, so... yeah
[18:55] <hatch> save the money and defer the OSX work to huw brad or I :)
[18:56] <rick_h_> heh, I don't like not being able to test/qa/support
[18:56] <rick_h_> makes me feel icky
[18:56] <rick_h_> but yea, it'd be a second laptop. Not going to go there full time so it's almost like having a tablet around
[18:56] <rick_h_> something to load/qa once in a while and requires fitting in the backpack with everything else
[18:57] <rick_h_> ok, running off. early mornings still here. Have fun all. Thanks for looking into that hatch 
[18:58] <hatch> have a good one
[19:00] <bac> jujugui: what is our stance wrt to MaaS support?  there is one MaaS-specific juju constraint that i'm on the fence whether the GUI should support or not. thoughts?
[19:00] <hatch> bac can you use the gui on maas?
[19:01] <hatch> like deploy services and the like?
[19:01] <bac> hatch: unsure
[19:01] <hatch> hmm who would know...
[19:01] <bac> i've never played with maas
[19:01] <hatch> yeah that makes two of us
[19:01]  * bac doesn't have a garage full of hardware
[19:01]  * bac doesn't have a garage
[19:01] <hatch> hazmat are you around?
[19:01] <bac> hazmat is supposedly out until monday
[19:02] <hatch> ohh ok, umm 
[19:02] <bac> hatch: i'm inclined to just leave it out until proven we need it
[19:02] <hatch> is it harder to add in later?
[19:03] <hatch> I just asked in #juju-dev
[19:07] <hatch> bac looks like marcoceppi does/has so it's probably a good idea to include it
[19:07] <marcoceppi> bac: hatch we're using it in orangebox, so it'd be good to include
[19:07] <bac> hatch: it is just a matter of adding 'tags' to ALLOWED_CONSTRAINTS
[19:08] <bac> alrighty, i'll throw it in.
[19:08] <hatch> marcoceppi am I supposed to know what orangebox is? I just think Halflife :)
[19:09] <bac> hatch, marcoceppi: on second thought i will not include tag support now and here is why:
[19:09] <hatch> oh halflife 
[19:10] <bac> there is an outstanding issue with juju gui in that it expects constraints to be a comma-separated list whereas it should be space-separated.  the tag list is comma-separated.  so we can't support them until the GUI constraints parser is fixed.  i may take that up this afternoon.  but until then it would blow up
[19:10] <hatch> ahh ok
[19:15] <rick_h_> bac: what's the constraint?
[19:15] <bac> tags=a,b,c
[19:15] <rick_h_> yea, if it's something we can support easily then we should. I think it's used to help demo juju installing openstack
[19:16] <bac> rick_h_: like  i said, it'll be easy once we stop being dumb
[19:16] <rick_h_> bac: ok, then yea. Let's file a bug on the maas constraint and make that a follow up
[19:17] <rick_h_> if we've got fixes for the more common uses then let's get that out. 
[19:17] <bac> rick_h_: alternatively i can add it to the constraint parsing bug.  can be done easily at the same time
[19:17] <rick_h_> bac: sounds good
[19:17] <bac> support for the other tags is landing now
[19:17] <rick_h_> I just want to make sure we've got it noted before your EOD so we don't lose track with you gone 
[19:29] <bac> added to card
[19:40] <hatch> pfft
[19:50] <hatch> functional js is da bomb
[19:50] <hatch> holy does it make testing easy...tedious but easy :)
[20:19] <benji> jujugui: how do I get version 1.18.0 (or greater) of juju? (so I can deploy local charms)
[20:19] <hatch> benji 1.17.3
[20:19] <hatch> has it
[20:19] <hatch> what version are you using?
[20:20] <benji> so the error message the GUI generates is wrong?  "Your version of Juju does not support local charm uploads. Please use at least version 1.18.0."
[20:20] <benji> 1.16.5
[20:20] <hatch> benji no the 1.17.x series is the dev releases
[20:20] <hatch> so that says that because that's going to be the first stable release with it
[20:20] <hatch> ok so you need to add the dev ppa of juju
[20:20] <benji> ah (man, I hate that versioning scheme: "no, you're not as cool as the kernel, you don't get to do even/odd")
[20:20] <hatch> so that you can upgrade
[20:20] <hatch> lol node also does the even odd thing
[20:21] <hatch> you can also build from source which is really easy, but adding the ppa is easier :)
[20:21] <hatch> you can also switch back and forth using apt easy
[20:21] <benji> hatch: do you have a pointer to the ppa?  or a pointer to the pointer?
[20:21] <hatch> benji let me shell into my server and find out
[20:21] <hatch> one sec
[20:22] <hatch> ok maybe it's odd
[20:22] <hatch> off
[20:22] <hatch> it'll be a couple minutes now
[20:22] <hatch> lol
[20:22] <hatch> sorry
[20:23] <benji> no rush, thanks
[20:26] <hatch> hmm now that it's on I can't ssh into it :/ bleh
[20:28] <benji> :(
[20:28] <benji> I'll try my Google fu.
[20:28] <hatch> it got stuck on the grub loader
[20:30] <benji> ppa:juju/devel
[20:33] <hatch> benji try http://ppa.launchpad.net/juju/devel/ubuntu
[20:33] <hatch> yeah
[20:33] <hatch> :)
[20:33] <hatch> sorry something happened took me a bit to get it straightened out
[20:34] <hatch> not sure why it was so messed 
[20:47] <jcastro> http://askubuntu.com/questions/253926/error-invalid-options-specification-options-staging-type
[20:47] <jcastro> anyone know what's up with this?
[21:03] <bac> rick_h_: i've moved my juju-deployer card to 'landing' since it got a good review from frankban and hazmat will land it if he approves.
[21:04] <rick_h_> bac: rgr
[21:04] <rick_h_> jcastro: looking, staging is a config flag
[21:04] <rick_h_> jcastro: wonder if something is up in the type of the default value on that or something
[21:05] <rick_h_> hmm, actually staging is removed now. 
[21:06] <bac> jcastro: that question is a year old.  i'd guess it is invalid now.
[21:07] <rick_h_> oh heh! I thought it was just yesterday. Missed the year
[21:07] <bac> a year and a day
[21:07] <rick_h_> jcastro: so yea, that's old, and the config issues there don't apply any more. 
[21:08] <bac> jujugui: i'm done today.  see (some of you) on monday.
[21:08] <rick_h_> bac: have a good weekend!
[21:08] <hatch> cya bac
[21:10] <Makyo> Need a pre-push hook.
[21:11] <rick_h_> Makyo: yea
[21:12] <rick_h_> Makyo: there's also an issue as I introduced a lint error helping with huw's branch stuff last night so part of it is my fault :/
[21:12] <Makyo> rick_h_, oh, in browser-tabview?
[21:12] <rick_h_> Makyo: frankban's branch has a fix for it but didn't get landed
[21:12] <rick_h_> Makyo: yes
[21:12] <Makyo> rick_h_, alright, thanks.
[21:13] <rick_h_> Makyo: yea, sorry about that. 
[21:27] <hatch> Makyo you should be able to set up an alias for yourself :)
[21:27] <Makyo> hatch, yeah. Though it sounds like there are hooks for that in newer versions.  Or I could use pre-commit
[21:28] <hatch> pre-commit might be irritating if you ever commit wip's
[21:28] <Makyo> Yeah.
[21:40] <hatch> one...more....test
[21:50] <Makyo> Woo.  jujugui small position branch: https://github.com/juju/juju-gui/pull/124
[21:51] <hatch> w000
[21:57] <hatch> Makyo I can do the review in a bit if noone else gets to it first
[21:57] <hatch> just trying to get mine finished up
[21:57] <Makyo> hatch, cool, no big deal.
[22:02] <huwshimi> Morning
[22:10] <hatch> jujugui looking for a review/qa on https://github.com/juju/juju-gui/pull/125 plz and thanks
[22:10] <hatch> huwshimi morning
[22:10] <Makyo> hatch, on it.
[22:11] <hatch> thanks
[22:23] <Makyo> hatch, see the changes to browser-tabview in either frankban's or my PR to get CI to pass.
[22:24] <hatch> jujugui new critical bug regression https://bugs.launchpad.net/juju-gui/+bug/1279550
[22:24] <Makyo> Once the first lands, the others won't have diff/conflict
[22:24] <_mup_> Bug #1279550: Changing service units disables input field <juju-gui:Triaged> <https://launchpad.net/bugs/1279550>
[22:25] <hatch> Makyo ohh ok I'll add that to my version as well
[22:26] <hatch> bad bad pplz
[22:28] <huwshimi> Makyo: What did I break?
[22:28] <Makyo> huwshimi, nothing, I think?  Just a lint problem with 84 char line.
[22:28] <rick_h_> huwshimi: my fault when I did the bad merge last night
[22:28] <huwshimi> Ah
[22:35] <Makyo> hatch, will get to review in a second. Dog problems, gotta walk it off.
[22:36] <rick_h_> hatch: create an urgent card and we can take a look tomorrow. Should be something small/simple I'd imagine. 
[22:37] <rick_h_> hatch: thanks for catching
[22:37] <hatch> rick_h_ already did
[22:37] <hatch> :)
[22:37] <hatch> rick_h_ this is the third time this has regressed
[22:37] <hatch> we need more tests lol
[22:37] <hatch> Makyo sure no rush
[22:39] <rick_h_> hatch: +1
[22:39] <hatch> ok now to fix this test failure 
[22:39] <hatch> at about 20% I noticed that I had been working all afternoon on battery power
[22:39] <hatch> heh
[22:42] <hatch> Makyo ohh it's trunk that's broken not my branch
[22:42] <hatch> ok I'll wait until yours lands
[22:57] <hatch> EOD'ing for a bit, will bbiab
[23:36] <hatch> all the pictures of NC look like it does here :)
[23:38] <rick_h_> of NC?
[23:50] <hatch> north carolina
[23:51] <hatch> rick_h_ ^
[23:51] <hatch> I think we have 5" of snow today
[23:52] <hatch> they say people are just leaving their cars on the freeway... my question... why did you get on the freeway haha?