[00:08] ok well past EOD [00:08] cya in the am [00:52] friggen CI failures [00:53] valuechange sucks for CI [00:53] well IE passed but now FF is failing on two different tests [00:53] well ok not two totally different [00:54] but different none the less [00:54] some which shouldn't have even been changed... [00:54] like the textarea autosize plugin?? [00:54] wth [00:55] timing sensitive based since it's based on valuechange [00:55] remember when we were tinkering with the 50ms poll time? [00:56] remember when I jsut deleted the tests from VC history like they never existed.... [00:56] oh I wish [00:56] lol [00:58] bzr branch trunk friggen-damn-ci-failures [01:02] umm what [01:02] TypeError: can't convert undefined to object [01:13] bcsaller: still around? [01:13] hatch: yes [01:13] so in inspector.js you had created a wrapper for handlers.push called watch [01:13] yeah....firefox didn't like that... [01:13] lol wth [01:15] hatch: is watch a reserved word in 'future js'? [01:16] negative [01:16] I'll try and create a repro [01:16] I guess that is the type of thing CI should catch, but why would we expect that to fail [01:16] see if it's something else in our code [01:16] or FF just being wako [01:17] that was just an alias IIRC, I guess just call the push directly when its used [01:17] yup that's what I did [01:18] yeah it was just an alias [01:18] probably to save chars [01:19] bcsaller: http://jsbin.com/ipehec/1/edit [01:20] updating FF to see if it fixes it [01:21] nope 23 does the same [01:23] handlers.push is fine [01:23] not sure that even works in chrome [01:23] console.log(handlers) [01:24] hatch: ^ [01:24] whatabout it? [01:25] its empty in the jsbin [01:25] right [01:25] console.dir(handlers) [01:25] shows you the prototype [01:26] you can't alias any protoype methods on an array in FF [01:26] http://jsbin.com/ipehec/2/edit [01:28] not working in chrome for me either, I think it was failing silently [01:28] odly enough it works just fine with objects [01:28] http://jsbin.com/ipehec/4/edit [01:29] interesting [01:29] ignore the comments [01:29] i just forgot to remove them [01:30] the sad part is I didn't really need the alias [01:30] haha right [01:30] that's some interesting stuffs [01:30] handlers.push it is [01:31] yup [01:31] I've already got it fixed and proposing [01:32] wana give it a review once it's done so I can get it in tonight? :) [01:33] probably be a few minutes before lbox is done [01:36] bcsaller: https://codereview.appspot.com/12640043 [01:37] hatch: LGTM, thanks [01:38] great thanks [03:14] CI back to normal....awww yeahh [03:14] hah [04:08] huwshimi: you around? [05:23] hatch: Yeah, I was, sorry I missed your message. Guessing you're gone now? [08:37] hey frankban. :-) good news: we do not need to support pyjuju for bundles. [08:40] gary_poster: good news indeed :-) [08:41] teknico, :-) . Also, mramm expects that we can stop supporting pyjuju at 13.10 [08:41] but that's not official yet [08:42] mourning its untimely demise already ;-) [08:42] :-) [08:46] gary_poster: great! so, IIUC, we don't need to add a pyAPIenv to the deployer, correct? === schwuk_away is now known as schwuk [13:28] abentley: could you please have a look here: https://code.launchpad.net/~adeuring/charmworld/1204899-report-json-value-error/+merge/179181 ? [13:30] adeuring: sure. [13:31] adeuring: Are you planning to update the staging revno so that you can QA your previous branch? [13:32] abentley: can you helpme to set up the juju environment? [13:33] adeuring: Okay, how can I help? [13:34] abentley: for a start: what do I need to put into environments.yaml? [13:34] adeuring: You should have a mail from me called "Accessing staging". That has the environments.yaml that you need. [13:34] abentley: ah, thanks, need to look again... [13:37] jujugui looking for 2 more reviews/qa's on this branch https://codereview.appspot.com/12627043/ [13:37] hatch: looking [13:38] thanks! [13:38] it'll need a deep qa [13:38] in fact I'll merge trunk into it again [13:39] proposing with the newest trunk merged in now [13:40] adeuring: Is it possible for start_date or end_date to be bogus? If so, what happens? [13:41] abentley: that should be set by our code. The worst I can imagine is that the end date is in the past.. [13:41] adeuring: What if the start date is after all the subsequent dates? [13:42] abentley: without looking too close, I'd say that we get an empty report. but let me check... [13:42] benji: updated [13:42] k [13:44] abentley: yes, we get an empty report. Basically, it boils down to a call of range(-3) or similar to generate the "buckets" [13:46] adeuring: However, IIUC, the start_date and end_date is typically not supplied, so we should get a range of 2011/05/1 to now. [13:46] abentley: right, and that looks reasonable [13:47] adeuring: I thought it might come from user-supplied data, in which case we'd need another bug report. === schwuk is now known as schwuk_away [13:49] hatch: the code changes look fine, doing QA now [13:51] adeuring: r=me. [13:51] abentley: thanks === schwuk_away is now known as schwuk [13:56] jujugui review time. qa instructions are included. https://codereview.appspot.com/12621043 [13:57] hatch: I'll peek. [13:57] thanks [13:57] I'd really like to get it landed asap [13:58] so we can start working with the new yui finally [13:58] ugh, I get nervous when shrinkwrap updates things [13:59] rick_h: you can thank module authors for not locking down their dependencies for that :/ [14:01] jujugui, we can stop supporting pyjuju as soon as we stop testing it in CI :-) [14:01] for reals? [14:01] wow! [14:01] gary_poster: let's fix CI! ;-) [14:02] oh c'mon I just got it working again last night [14:02] lol [14:02] heh [14:02] hatch, for IE 10 drag target bug, sinzui suggested making the "drag a charm here" thing in the middle disappear when you start a drag [14:02] I like that [14:02] gary_poster: yeah - I was also going to look into why it's not a drop target [14:02] also, are you ok with the odd drag proxy? [14:03] it may not be supported in IE10 like in chrome [14:03] bcsaller: ServiceUpdate is in juju-core trunk [14:08] hatch, yes [14:09] frankban, did you see me (try to) tell you that you don't need to support pyjuju in deployer at all? [14:09] gary_poster: yes, a good news [14:09] cool frankban [14:09] hatch: the confirm button in the service inspector (after editing a config setting) isn't working? known issue? [14:10] hatch: also saw the expose button one, but you said that was expected. [14:10] rick_h: yeah I think it was introduced by huws branch [14:10] I made a comment in his review but he must have left it [14:10] hatch: hmm, yea neither cancel/confirm work [14:10] https://codereview.appspot.com/12506044/#msg8 [14:11] hatch: ok, but sounds like we don't have a card/anyone on it then? Should I add a card to inspector? [14:12] rick_h: I'll create a ticket and a card [14:12] hatch: cool thanks [14:13] qaing your branch now [14:13] hatch: thanks [14:18] rick_h: I see the options requests are still slow :) [14:21] abentley: I'm getting the error "exceptions.ValueError: Missing config 'username', 'password', 'project-name' required for userpass auth [14:21] hatch: yes, bug is still out on that [14:22] adeuring: It sounds like you might not have sourced the openstack config-- the novarc in the credentials I gave you. [14:24] abentley: maybe. When did you send it? [14:25] hatch: sorry, unity crash caused me to delay my QA a bit; still looking [14:25] * hatch thinks benji needs new hardwares [14:25] :) [14:26] says the man that needs new hardwares... [14:26] adeuring: I believe I gave you the openstack credentials on a USB stick at the Oakland sprint, but I can mail them to you now. [14:26] rick_h: hey mine doesn't crash :D [14:26] it's just slow lol [14:26] abentley: OK, THANKS [14:28] unfortunately I think my issues (computer-wise at least) are all software-induced [14:28] adeuring: Please associate GPG keys with your canonical acccount. [14:31] gary_poster: IIRC, we try to avoid installing packages from pypi in the charm, correct? [14:32] frankban, y [14:32] gary_poster: ok thanks [14:35] yui 3.11 being merged in to trunk [14:35] jujugui ^ [14:35] abentley: ? There is a key associated with my LP account. What do you mean? [14:35] is that Canadian for "hold onto your butts"? [14:35] lol [14:37] gary_poster: on the IE DD task now [14:37] hatch, cool thx [14:38] gary_poster: also curtis's branch is hanging out in maintenance review - could you ask him next time you see him what's up with it? [14:38] hatch: where's "above the click handlers" that you wanted a comment? [14:39] adeuring: Not your lp account. Your canonical email account, abel.deuring@canonical.com. It needs to be listed on your GPG key so that programs can pick that key automatically when sending mail to that account. Right now, only your gmx.net and satzbau-gmbh.de accounts are listed. [14:39] rick_h: well I'm assuming the a's had another click handler on them else where would they link to? [14:39] hatch: well, it's in the Y.Views and such. [14:39] ohh right pjax garbage [14:39] abentley: ah, right, I'll do it [14:39] hatch: and this is only overriding this in the context of the widgets in the autocomplete results [14:40] hatch: huh? pjax garbage? no, it's Views listening to events from widgets [14:40] hatch, benji said he approved it if he added a test for the nagios external master script. Neither he nor anyone in webops knows how to write that test. [14:41] oh haha ok, what should we do with the card? :) [14:41] * benji looks at it. [14:41] rick_h: so there is a view which is navigating on clicking those a's? [14:41] hatch: the charm-token widget is used EVERYWHERE so some places watch for that click to open the charm details/etc [14:42] hatch: in this view, clicking on the charm triggers teh autocomplete selection event and we don't want to do anything else with it [14:43] hatch: the tokens render with a and a link in there. We just have to kill that for autocomplete to work. [14:43] ok I gota pop this open again [14:43] one sec [14:43] gary_poster/hatch: they either misunderstood my request or have suffered a collective brain aneurysm. The test is not of the script but of the endpoint the script gets as a liveness test. I.e., it would asssure that the URL the script hits stays there and continues to contain the text that the script expects. [14:44] benji, cool thanks, sinzui says he can do that! [14:44] rick_h: ohh now I see, it has a path in the href [14:44] hatch: right [14:44] hatch: so we're killing that, that's all [14:44] could that be removed in favour of the charmid ? [14:45] (not in this branch) [14:45] jujugui emergency vet trip in a few, but will bring laptop. Still aiming to land the go-sandbox-deltas branch today [14:45] uh oh! Hope puppy is ok [14:45] hatch: then we get into special casing, adding css for acting like a hover/clickable, etc [14:45] Makyo: good luck === BradCrittenden is now known as bac [14:45] Conjunctivitis, nothing too bad, but sure is gross :P [14:45] heh [14:45] hatch: I don't think killing link clicks in a specific case is bad. [14:46] no but it's impossible to find out where it's being blocked if you want it to [14:46] that's what my comment was about [14:46] but we don't want to. How in the world would an autocomplete option have an you want to follow? [14:47] I'm missing how this causes any grief for later on trying to figure out "why is my click blocked"? [14:47] benji, gunoy deployed your changes. Do they looks good? [14:48] sinzui: cool! looking [14:48] Cache-Control: max-age=0, public, must-revalidate [14:48] perfect [14:48] gary_poster: ^ [14:49] we probably wouldn't want to follow an a in an autocomplete (at least in this case) [14:49] hatch: I've updated the comment to call out the part to help [14:49] but prevented events in the middle of a script aren't clear when you're stepping through the code trying to find out wth is going on [14:49] hatch: but I want to keep the same css, :hover, dom structure as other charm tokens and would prefer to not tweak the template on it. [14:50] hatch: understand. [14:50] so that's why I was commenting about putting a note on the real listener [14:50] s [14:50] but those don't exist [14:50] heh [14:50] and been there done that [14:50] hatch: trust me, it took me a bit yesterday to figure out why things kept navigating :) [14:51] ugh anchors!! [14:51] semantic this!! [14:51] hah [14:51] I still think the search is broken [14:52] stop calling it search [14:52] then it'll stop being broken [14:52] :P [14:52] it's not search [14:52] then don't have a description that says 'Search for charms' [14:52] :P [14:52] and when you complete your search it works just like you expect [14:52] 'Autocomplete charm name here' [14:53] benji, The release was delayed because the stable branch diverged when the developer branch was merged. r69 was replaced with an identical but different revision and bzr choked. [14:53] sorry you aren't going to convince me this time :) [14:53] sinzui: yes, yes... I understand some of those words [14:53] hatch: that's ok. It's good to be completely wrong somtimes and carry that with a badge of honor on your chest :) [14:53] rick_h: http://yuilibrary.com/yui/docs/autocomplete/ look at the example image even! [14:54] this is even used on Yahoo's own homepage! [14:54] hatch: and they do evvvvverything right :P [14:54] We need to think about the process to ensure we merge into stable, not replace stable. Your weren't involved in the mixup BTW. It just happened and it block your request [14:54] * hatch can't wait for the first public bug that the search is broken [14:58] rick_h: ok I'm a little confused by your response about the empty left column [14:58] hatch: k [14:58] I type ceph into the input [14:58] hit enter [14:58] it clears out the left column [14:58] hatch: you've done a search now [14:58] for the term "ceph" [14:58] it's showing you the search results [14:59] oh man even I'm confused about this interaction, so it's a dual purpose input? [14:59] it autocompletes from the start of a string and acts as a search box? [14:59] no, it's a search input. [14:59] it's always been a search box [15:00] you've just autocompleted a search term for the user [15:00] this is why autocomplete != search [15:00] but you haven't because if I click that it opens the charm not fills in the input [15:00] if I use google autocomplete on their search box "hatch is" it gives me suggestions, and then when I select one it does that search for me [15:01] hatch: second, need more details then. It should fill in the input, do a search, and show you the details [15:01] hatch: it's search autocomplete [15:01] ohhh NOW i see [15:01] there is a bug in here somewhere [15:02] ok, I'm willing to admit there might be :/ [15:02] it was causing the sidebar to be emptied and then just showed the charm [15:02] like....empty as in nothing in it [15:02] yea, that shouldn't happen [15:02] ok now how did I get it to do that [15:02] man that was confusing for both of us there lol [15:03] you thought I was an idiot, I thought you had gone crazy [15:03] haha [15:03] "doctor it hurts when I do this." "stop doing that" [15:03] and you both were right! ;-) [15:03] lol!!! [15:05] rick_h: ok I don't know what's up here but probably 20% of the time it has an empty sidebar ..... ugh worst bugs ever [15:06] hatch: ok, working on other parts of your review now. I'll peek at it in a sec [15:06] hatch: watch the network tab in the debugger and see if the search call is going out/has response [15:07] yeah now I can't get it to do it at all [15:07] abentley: new problem:; "File "/usr/lib/python2.7/dist-packages/juju/providers/common/connect.py", line 43, in run [15:07] client = yield self._internal_connect(share) [15:07] Error: [('PEM routines', 'PEM_read_bio', 'no start line')]" [15:08] at least when it's working it makes sense :P [15:09] adeuring: My guess is the paths to the included PEM files are wrong. You should extract the contents of orangesquad.zip to a single directory and source the script from there. [15:09] adeuring: No, wait... [15:09] adeuring: Yes, look into the PEM file paths. [15:10] abentley: yeah, thanks!" [15:14] abentley: did not help; the files which the env vars point to exists... [15:17] adeuring: Do the sha1 sums match? http://pastebin.ubuntu.com/5962937/ [15:18] abentley: yes [15:19] jujugui call in 10 kanban now [15:19] adeuring: That's very weird. I don't know what to suggest. I don't know how it could claim those files have no start line. [15:19] I've only seen that when the path was wrong. [15:24] * Makyo returns. [15:26] abentley: sooo... could you update staging for me? [15:26] adeuring: Sure. What revno? [15:27] abentley: 339 please [15:27] hatch: updates to the other issues uploading now. If you can dupe please let me know and I'll try to fix. I'm working on trying to dupe it now. [15:27] rick_h: ok after call [15:27] hatch: rgr [15:28] adeuring: config changed. Should be updated in a minute. [15:28] jujugui guichat in 2 [15:28] tahnks [15:43] rick_h: \o/ [15:43] hatch: yea, autocomplete/click a category, then go and autocomplete a charm not in that category [15:44] hatch: and you end up with empty results because the search for that charm name + category (from earlier) has no results [15:44] hatch: are jujugui and guichat the same thing? [15:44] abentley, yes, but jujugui pings in irc. [15:44] abentley: yes, just that the second one doesn't ping the channel so easier for others not using it [15:45] but when you use both in the same message it is moot [15:45] lol [15:45] abentley: there are jujugui and guihelp which ping the whole channel (if you set it up in your configs) and we changed to using guichat to reference the guichat boardroom so we woudln't ding everyone with it's old name (jujugui) [15:46] And now you have three pings \o/ [15:46] will someone please smack him? [15:46] rick_h: CHOO CHOOO [15:46] Ffffff [15:46] rofl [15:49] rick_h: lgtm'd [15:50] hatch: thanks [15:50] I'm really glad you were able to dupe the bug haha [15:50] yea, better to catch it now while my head is in the code [15:50] that was a pretty obscure one too [15:54] rick_h: this was me trying to repro that error http://nodejsreactions.tumblr.com/post/57620383823/var-result-fs-readfile-data-json-function [15:55] lmao, that's awesome [15:56] man, I can leave that running all day [15:56] haha yeah I laughed [15:56] hatch: ok, bug fix upload fyi [15:58] heh such a easy fix [16:03] gary_poster, ping for docs/vids meeting? [16:09] he forgot about us :'( [16:20] gary_poster, we ducked out, ping if it's moved. [16:22] man native drag and drop is needlessly complex [16:31] jujugui, Makyo, hatch, sorry. Was suddenly called into meeting with Mark. I'm exhausted so that's ok that we will not be calling. :-P Lots more to talk about...our schedule will be changing more. :-) CLI work is huge. Will give more details soon. [16:32] no problem :) [16:33] right now I'm trying to decide if I hate virtualbox or windows 8 [16:33] one is buggy [16:33] haha [16:36] heh [16:37] [object Object] THANKS IE! [16:39] go IE go! [16:39] isn't IE12 out yet to make dev work not suck? [16:40] with all the praise IE11 is getting you know it's gona suck somehow [16:40] it's the same hype they had with IE10 [16:42] I actually got IE to drop on that empty canvas element [16:42] but only by causing a type error [16:42] lol [16:46] teknico, ping? [16:49] thanks for the review bcsaller [16:49] np [16:49] why does the media wiki icon always take way longer to load? :) [16:49] gary_poster: landing updated autocomplete now. Would love to get UX to look at if it's passible enough to un-feature flag it while we tweak the ui a little bit more. [16:50] since people love it so much, let em have it :) [16:50] rick_h, cool, let me know when it is on comingsoon and I'll call 'em over. will that be good, or do you want me to merge? [16:50] gary_poster: yea, I'll let you know [16:50] cool [16:51] go my little lboxes go! [16:51] rick_h, if you could prep me with answers to "why does this not look like UX?" [16:51] that would probably help the conversation along ;-) [16:52] gary_poster: sure thing, basically 'it's not in a google doc and rick couldn't find the place the mockup was at' [16:52] heh [16:52] gary_poster: that + 'rick hasn't figured out how to do a seperator cleanly [16:52] should sum it up [16:52] ok [16:52] rick_h, heh :-) cool [16:56] *sigh* [17:02] We can switch to this: http://tinysubversions.com/gaunt/ [17:05] lol [17:07] Makyo: that should work beautifully as a template engine for whitespace: http://compsoc.dur.ac.uk/whitespace/ [17:10] frankban, Hah: https://twitter.com/tinysubversions/status/365478093630095360 [17:12] heh [17:12] lol! [17:18] bcsaller: is the drap/drop import script supposed to support IE10? [17:19] hatch: uhh sure, I guess. I don't remember if that was verified as that feature was never officially published [17:20] hatch: I'm going to be changing the import stuff to be deployer format files in the next day or so if all goes well [17:20] but that was my only plan there, at that point though I think it will be a 'real' feature [17:21] ok because IE10 doesn't support custom strings in getData() [17:21] and that's causing other stuff to fall over [17:21] var dataType = evt._event.dataTransfer.getData('dataType'); [17:21] so that needs to be 'Text' [17:21] but then I think that'll break the actual functionality in modern browsers? [17:25] ya know what though...it might not matter [17:25] getting D&D to work with multiple drop targets in IE breaks it in chrome [17:31] ooo I got it dropping now in chrome and ie [17:31] now ff? [17:31] you wish! [17:32] hey I didn't say the drop worked....just that it's actually 'dropping' lol [17:32] but you are correct [17:32] it doesn't work in FF at all [17:32] oh wait [17:32] it never did work in FF here [17:33] * hatch switched to other FF [17:33] yusss [17:33] errors in all 3 browsers [17:35] hah, you broke them all now? [17:36] yup! [17:44] DD WORKS IN ALL 3 DD WORKS IN ALL 3!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! [17:44] it took 3 hours and probably broke every test we have but its working! [17:45] lies! [17:45] well I'm going to take this time to review bc's branch [17:45] bcsaller [17:46] autocomplete fail [17:47] bcsaller: .... slice = [].slice does that actually work? ;) [18:01] hatch: with call it gets context [18:01] or apply [18:01] bac: Do you have a minute to hang out? I'd like to make sure we're not treading on each others' feet. [18:09] hi abentley, yes i was just about to ask you the same [18:10] bac: guichat open. [18:10] bcsaller: I was referencing the FF issues of yesterday [18:10] :) [18:10] abentley: i just saw you then you disappeared! [18:15] rick_h: https://plus.google.com/u/0/109440437666972345229/posts/SN6PnrYV3d6 [18:29] man I'm so pumped DD works in all 3 browsers now [18:29] guihelp anyone a master of :nth css fun? [18:30] rick_h: http://fromanegg.com/post/57464448123/css-selectors-the-next-level ;) [18:30] k, hatch volunteers to help [18:30] yay hatch [18:32] I really want a :last-with-class :/ [18:32] hatch: got a sec for guichat? [18:32] rick_h: nth-last-of-type [18:32] sure [18:32] guichat is busy [18:33] hatch: k, invite otw [19:07] * hatch lunching [19:16] bac: Could you please review https://code.launchpad.net/~abentley/charmworld/separate-text-queries/+merge/179261 ? [19:16] abentley: sure [19:18] abentley: r=me [19:19] bac: Should land in 5 minutes. [19:35] bac: Delayed due to testing of https://codereview.appspot.com/12634045 === schwuk is now known as schwuk_away [20:02] abentley: I'm struggling to understand why UpdateCharmJob.run() has this line of code payload['_id'] = payload['branch_spec'] [20:02] I would have expected the _id to be consistent with (if not actually use) construct_charm_id() [20:03] benji: construct_charm_id would cause the charm id to include the revision. That's the plan, but we're not there yet. [20:04] hmm [20:05] abentley: so... construct_charm_id doesn't actually construct an ID for a charm? [20:06] benji: It will. I landed it first because other branches needed it. [20:06] I'll add a comment to that effect. [20:30] * hatch shakes fist [20:30] damnnn you multi dispatch [21:00] 6 out of 1104 tests failing....not bad....not bad at all [21:02] bcsaller: are you still hanging around? [21:02] hatch: yeah [21:02] have a few minutes to look at my dd ie work? [21:02] hatch: sure [21:03]