[00:00] :) [00:04] ah crap [00:05] uh oh [00:05] huwshimi_: please go to your develop branch and do a sync from upstream develop [00:05] and QA the changes per your expected [00:06] I accidently pushed the cleanup to juju develop and so it's in there now [00:06] I'm running tests to make sure they're ok atm [00:06] but I cherry-picked things and want to make sure the fixes are still good for the css/etc [00:07] tests pass [00:08] hatch: still around? [00:10] rick_h_: I think it's all good [00:10] huwshimi_: k, the diff in the commits look good [00:10] so going to call this closed [00:10] sorry for the mess up [00:10] my fault for trying to take a shortcut [00:10] since my network bandwidth is a trickle atm [00:11] huwshimi_: remind me next time we have a AU call to go through some techniques for helping with this [00:11] rick_h_: OK great, thanks! [00:12] huwshimi_ I am [00:12] rick_h_: ^ [00:12] hatch: can you verify that develop QA's ok for you in safari for the bugs mentioned? [00:12] sure [00:13] 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] hatch: well he had 3 nice commits so I just updated develop, cherry picked the 3 revs, fixed on conflict [00:14] right, I am asking in more general terms [00:14] because we now get the 'real' commit and a merge commit [00:14] 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] haha oops [00:14] yea :/ [00:17] rick_h_ huwshimi_ qa looks good here [00:18] hatch: cool thanks for the check [00:18] huwshimi_: thanks for the updates. If you get a chance to check if it helps the FF issue I'd appreciate it [00:18] at least a yay/nay for fix so we can close the bug [00:19] rick_h_ have you looked at the git merge --squash flag to see if we can use it and not rebase? [00:20] and also use --ff [00:20] to make it not create a merge commit [00:20] 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] hatch: I want to, have not yet [00:20] 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] ok np just wanted to see if it was on your radar [00:21] the rebase seems to be causing peeps issues [00:21] yea, definitely [00:21] 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] the GUI actually runs very well with safari [00:21] huwshimi_: k [00:21] really fast and smooth [03:34] huwshimi_ so do we now support Safari? [03:35] at least as far as the sandbox is concerned? [03:42] hatch: Nope, need to get the export working as well. [03:42] ahh ok cool, so is that css card on the board done now too? [03:43] hatch: Yeah, I guess that one is done now. It's already landed :) [03:45] cool, it'll be nice to support yet another browser [03:45] well....nice for others...lol [03:51] hatch: Yeah, the testing matrix gets harder though [03:52] yup yup [04:06] adding support in CI should be pretty easy though === rogpeppe1 is now known as rogpeppe [11:09] frankban: morning [11:09] morning rick_h_ [11:09] frankban: got time to chat this morning? [11:10] rick_h_: sure [11:11] frankban: https://plus.google.com/hangouts/_/76cpj3qusk9dek11oh8t82jcfo?authuser=1&hl=en [12:05] rick_h_: how's the jetlag? looks like you were up early again. [12:43] bac: yea, but this was intentional. Wanted to chat before I took the boy to day care [12:43] bac: but yea, I'm still an early guy though 6am is best yet :) [12:50] bac: when you get a sec wonder if we can chat. [12:50] rick_h_: sure. send me an invite [12:51] bac: k, give me a couple min thanks [12:52] bac: https://plus.google.com/hangouts/_/76cpi3hmf68o8olj07cmo27r64?authuser=1&hl=en === frankban_ is now known as frankban [14:50] so....systemd eh? [14:50] yep, we'll see how that goes [14:52] ugh [14:53] I'm not super educated on it, but it sure seems to me that upstart was the winnder technically [14:53] winner [15:31] * benji watches a 900K zip of the GUI charm being built in the browser. [15:31] wooooo! [15:35] benji right on! I'm a little jealous that you're working on that [15:35] :D [15:35] :) [15:35] it's been fun; a little slower than I had hoped, but fun [15:36] 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] hmm that does sound like an odd one [15:37] in other good news, you can now drop a zip onto the inspector too [15:42] oop someone got pulled over [15:44] has anyone ever 'played' Core Wars before? [15:52] jujugui call in 8 [15:54] 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] apparently my ghost is hanging around heh [15:55] hatch___: hmm, well we have series info in the charm url? [15:56] hatch___: ah, but this is a local one I imagine? [15:56] hatch: I played around with core wars a little a long time ago === luca__ is now known as luca === hatch___ is now known as hatch [15:59] jujugui call in 1 [16:05] rick_h_ ahh right I can split the series out of the url, thanks I'll do that [16:21] 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] 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] frankban: it looks like he means to 'return self.config' but isn't [16:22] rick_h_ it looks like we handle the undefined default case in the databainding [16:22] bac: looking [16:22] databinding [16:22] hatch: I don't remember enough about it to make a cogent response :) [16:22] so maybe we can do it [16:22] banji oh haha gotcha [16:22] hatch: right, but as a read. We don't have a way to write that or am I mistaken? [16:22] banji: when benji plays a banjo [16:23] heh [16:26] rick_h_ sorry just looking now [16:27] rick_h_ if the field is an input and it's '' then it returns it as null [16:27] this is of course not possible with a checkbox [16:28] hatch: interesting. maybe we're in better shape than we think then. [16:28] 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] so we need to do something to test that null gets to an unset into the api call to core [16:29] frankban: ok, but the _fetch_charm_store doesn't return anything. [16:29] right, you can see the code in utils:_getElementsValuesMapping() [16:29] sorry views/utils.js:_getElementsValuesMapping() [16:29] bac: it does not seems the caller really needs it to return something [16:29] hatch: cool, can you file a bug along those lines with the info you've got there? [16:29] and we can look into it [16:30] frankban: i'd be more confident monkeying around with it if the method were tested... :( [16:30] what's the title of the bug? [16:30] :) [16:30] unfortunately launchpad doesn't really have a 'task' bug type :) [16:30] hatch: juju gui doens't use juju unset for config updates [16:30] bac: agreed [16:30] sounds good [16:30] hatch: and put the notes in there and we can see what the actual diff needs to be to make it work. [16:31] well we'll need some type of UI element for the checkboxes regardless [16:31] but that might be ok... [16:31] hatch: well, can a checkbox be undefined? I think that's a big nuts [16:31] I mean it's a boolean [16:31] /big/bit [16:31] if you define a config option as a boolean but don't give a default is it then undefined? [16:32] I think it should be a lint error tbh [16:32] marcoceppi ^ [16:34] 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] 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 [16:38] hatch: thanks [16:43] 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] hatch: you rang? [16:43] :) [16:43] lol, the charm model already has code to do this I thought [16:43] but benji is regex master [16:43] haha [16:44] rick_h_ I can look [16:45] 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] marcoceppi see bug #1279414 as well plz [16:46] 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 [16:46] marcoceppi: cool, that makes sense then [16:46] I explicitly stated that booleans must remain with a default of a boolean, or lint will throw an error [16:46] ok so then we are in a pretty good spot [16:46] marcoceppi: we've got a bug to verify and update to support the idea of unset. [16:46] marcoceppi: so we'd ask that the policy not change until we can get it all setup. Next week probably [16:46] marcoceppi can a field be 'null' or are 'null' and unset the same? [16:47] rick_h_: that's fine [16:47] hatch: unset is just juju reverting to the default value [16:47] so a default of null (python None) is a valid default for a configuration option [16:47] and so is an empty string? [16:48] hatch: no, empty string is not None [16:48] I mean, it's a valid value [16:48] hatch: correct [16:48] default: "" is no problem, because you can juju set cfg="" [16:48] rick_h_ ^ so this means we need a separate UI element for 'reset' :/ [16:48] but you can't ever run juju set cfg=None [16:49] ahh our issue is that the UI does not let you set anything other than an empty string [16:49] 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] so right now we consider an empty string to be null [16:50] 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] rick_h_ right but from what I'm seeing here is that we are doing it incorrectly [16:50] 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] hatch: right [16:51] so we need a reset button :( [16:51] 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] marcoceppi right, that's just easier said than trying to find some UI to do that :D [16:51] haha ;) [16:52] hatch: hangout on the way [16:52] 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] marcoceppi: right, cool [16:52] rick link? my phone answered it [16:52] hatch: https://plus.google.com/hangouts/_/76cpjdqgqe3robu1q9isu6kr2o?hl=en [16:52] there's just no way to put it back to None [16:52] marcoceppi: gotcha [17:08] hazmat: you around? Could you review https://codereview.appspot.com/52600045 (juju-deployer) when you get a chance? [17:09] bac: he's on vaca this week still I believe so might not hear back until next week [17:10] rick_h_: ok. well if i don't hear back by EoD i'll move my card out of the way, somewhere [17:10] bac: k, maybe get a review from frankban if he's able to at least get a sanity check [17:10] bac: and then it's just a landing issue? [17:10] sure [17:10] frankban: ^^ [17:11] frankban: i was also going to ask for a review of juju-gui charm https://codereview.appspot.com/61510051. trivial change. [17:11] frankban: but if you're eod i'll get someone else to look at it [17:11] bac: sure, I'll look at it, EOD in 50 [17:12] thanks frankban. note there are two: charm and deployer [17:12] * bac lunches [17:20] benji hey so were you going to get me that regex? ;) [17:22] 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] yep [17:23] thanks :) [17:24] hatch: > 'cs:precise/my-charm-name-12'.match(/[^:]*(?=\/)/)[0] [17:24] 'precise' [17:24] nice :) now I wish I knew why that worked [17:24] :) [17:25] not anything before the : [17:25] if JS had look-behind assertions it would have been a little simpler [17:25] hatch: here's the explanation [17:25] [^:]* - find anything not a : and eat it up [17:25] ah, benji with the notes [17:26] rick_h_: I was just setting up your explanation [17:26] lol [17:27] [^:] means anything not a colon ([abc] means any of a b or c, the carat after the opening bracket means "not") [17:27] * means zero or more, of course [17:28] 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] 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] hatch: make sense? [17:30] it does thank! [17:30] s [17:30] I just don't write enough regex to get decent at it :) [17:31] 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] here's some lunch time APL for all you fine folks out there: http://www.youtube.com/watch?v=a9xAKttWgP4 [17:33] haha oh boy APL [17:42] bac: https://codereview.appspot.com/61510051/ done [17:49] guihelp: I need two reviews for https://github.com/juju/juju-gui/pull/123 . anyone available? thanks! [17:50] I'll take it [17:50] take one [17:52] frankban: looking [17:52] hatch, rick_h_: thank you [18:29] bac: both reviews done. EOD have a nice evening [18:30] have a good night frankban [18:31] rick_h_ looks like selenium failed the safari tests [18:31] hatch: ah cool [18:31] and it's a full on blizzard here :/ [18:31] hatch: :P [18:32] I WAS going to go work elsewhere today [18:32] not worth it now [18:32] lol [18:32] did you guys see the backup subordinate charm? Looks pretty cool [18:33] heard of it but not checked it out yet [18:33] 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] hmm "attemped to assign to read only property" [18:35] is the failure that caused it to go boom [18:36] rick_h_ what's the full error message? [18:37] er [18:37] line it's on [18:37] sorry brain fade [18:37] hatch: bah, closed it. It's a pain to time the video at the right spot to get it [18:37] is it around the XHR stuff? [18:37] sec [18:37] sorry :) [18:38] * rick_h_ is going to feel like he needs to get an air if we support safari [18:39] "must cull removed services from the existing list" [18:39] assets/muodles.js line 8 [18:39] "attempted to assign to readonly property" [18:39] from test_environment_view.js 1430 [18:39] hatch: ^ [18:39] looking [18:40] what the heck... [18:40] let me try and run the test suite in safari [18:40] give me a couple mins [18:41] 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] rick_h_ I can reproduce, just trying to figure out the safari inspector to see how a custom var is readonly [18:44] the safari inspector is actually pretty cool [18:45] hatch: yea, should be close to chrome as it's webkitt based [18:45] all pretty colours and such lol [18:45] no it's entirely different odly enough [18:45] oh, it used to be close [18:45] oh well, shows how long it's been since I played on a mac [18:46] resolutoin on an air kind of stinks :/ [18:46] 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] I think that's why they haven't updated it [18:47] the xps 13 has 1920 and hours of battery life [18:47] because the MBP13" is really just a big air [18:47] I've never come anywhere close to Dell's advertised battery life [18:47] was just looking at reviews [18:47] so they were review results but yea [18:47] not "rick hard at work" results [18:47] haha yeah, this MBP battery life is garbage [18:48] they do the tests 'playing video' which this thing lasts almost 11H on a charge [18:48] open IRC? 5h [18:48] lol [18:48] I think it's the wifi [18:48] anyways - I see the problem [18:49] it's that we are trying to assign a value to a property which is undefined [18:49] cool, well no rush. Just was curious [18:49] lol, go us [18:49] so 'undefined' is read-only in strict mode [18:50] rick_h_ I'll add the details to the card and then get to fixing it after this local charm stuff [18:51] hatch: cool. Yea it's lower priority but seems we're almost there so would be cool to have [18:53] rick_h_ updated with details [18:53] looks like it's the only test failure though [18:53] hatch: thanks [18:53] so yay [18:53] well it only ran some 48% of the tests before stopping [18:53] hatch: did the rest run for you? [18:54] rick_h_ yes it completed the run and it was the only failure [18:54] hatch: oh, very cool then [18:54] took about 50s [18:54] like I was saying, we're darn close [18:54] yay [18:54] which is the fastest of any browser [18:54] impressive [18:54] hmm, 13" air looks nice except for resolution. [18:55] yeah that's what drove me into the Pro line....then the 13" pro was overpriced imho, so... yeah [18:55] save the money and defer the OSX work to huw brad or I :) [18:56] heh, I don't like not being able to test/qa/support [18:56] makes me feel icky [18:56] 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] something to load/qa once in a while and requires fitting in the backpack with everything else [18:57] ok, running off. early mornings still here. Have fun all. Thanks for looking into that hatch [18:58] have a good one [19:00] 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] bac can you use the gui on maas? [19:01] like deploy services and the like? [19:01] hatch: unsure [19:01] hmm who would know... [19:01] i've never played with maas [19:01] 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] hazmat are you around? [19:01] hazmat is supposedly out until monday [19:02] ohh ok, umm [19:02] hatch: i'm inclined to just leave it out until proven we need it [19:02] is it harder to add in later? [19:03] I just asked in #juju-dev [19:07] bac looks like marcoceppi does/has so it's probably a good idea to include it [19:07] bac: hatch we're using it in orangebox, so it'd be good to include [19:07] hatch: it is just a matter of adding 'tags' to ALLOWED_CONSTRAINTS [19:08] alrighty, i'll throw it in. [19:08] marcoceppi am I supposed to know what orangebox is? I just think Halflife :) [19:09] hatch, marcoceppi: on second thought i will not include tag support now and here is why: [19:09] oh halflife [19:10] 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] ahh ok [19:15] bac: what's the constraint? [19:15] tags=a,b,c [19:15] 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] rick_h_: like i said, it'll be easy once we stop being dumb [19:16] bac: ok, then yea. Let's file a bug on the maas constraint and make that a follow up [19:17] if we've got fixes for the more common uses then let's get that out. [19:17] rick_h_: alternatively i can add it to the constraint parsing bug. can be done easily at the same time [19:17] bac: sounds good [19:17] support for the other tags is landing now [19:17] 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] added to card [19:40] pfft [19:50] functional js is da bomb [19:50] holy does it make testing easy...tedious but easy :) [20:19] jujugui: how do I get version 1.18.0 (or greater) of juju? (so I can deploy local charms) [20:19] benji 1.17.3 [20:19] has it [20:19] what version are you using? [20:20] 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] 1.16.5 [20:20] benji no the 1.17.x series is the dev releases [20:20] so that says that because that's going to be the first stable release with it [20:20] ok so you need to add the dev ppa of juju [20:20] 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] so that you can upgrade [20:20] lol node also does the even odd thing [20:21] you can also build from source which is really easy, but adding the ppa is easier :) [20:21] you can also switch back and forth using apt easy [20:21] hatch: do you have a pointer to the ppa? or a pointer to the pointer? [20:21] benji let me shell into my server and find out [20:21] one sec [20:22] ok maybe it's odd [20:22] off [20:22] it'll be a couple minutes now [20:22] lol [20:22] sorry [20:23] no rush, thanks [20:26] hmm now that it's on I can't ssh into it :/ bleh [20:28] :( [20:28] I'll try my Google fu. [20:28] it got stuck on the grub loader [20:30] ppa:juju/devel [20:33] benji try http://ppa.launchpad.net/juju/devel/ubuntu [20:33] yeah [20:33] :) [20:33] sorry something happened took me a bit to get it straightened out [20:34] not sure why it was so messed [20:47] http://askubuntu.com/questions/253926/error-invalid-options-specification-options-staging-type [20:47] anyone know what's up with this? [21:03] 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] bac: rgr [21:04] jcastro: looking, staging is a config flag [21:04] jcastro: wonder if something is up in the type of the default value on that or something [21:05] hmm, actually staging is removed now. [21:06] jcastro: that question is a year old. i'd guess it is invalid now. [21:07] oh heh! I thought it was just yesterday. Missed the year [21:07] a year and a day [21:07] jcastro: so yea, that's old, and the config issues there don't apply any more. [21:08] jujugui: i'm done today. see (some of you) on monday. [21:08] bac: have a good weekend! [21:08] cya bac [21:10] Need a pre-push hook. [21:11] Makyo: yea [21:12] 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] rick_h_, oh, in browser-tabview? [21:12] Makyo: frankban's branch has a fix for it but didn't get landed [21:12] Makyo: yes [21:12] rick_h_, alright, thanks. [21:13] Makyo: yea, sorry about that. [21:27] Makyo you should be able to set up an alias for yourself :) [21:27] hatch, yeah. Though it sounds like there are hooks for that in newer versions. Or I could use pre-commit [21:28]