[00:01] oh ok [00:22] gary_poster: just ran it through on ec2 and it completed successfully with ie and firefox both failing the unit tests first then retrying [00:22] so...yay! [00:22] now....canonistack.... [00:25] hatch, heh, weird, but kinda good. [00:26] I just forwarded you the response from sauce labs [00:26] basically saying that it can't be caching [00:27] but now....haircut :) [00:27] have a good night [00:27] you too hatch, thx === rick_h_22 is now known as rick_h_droid [11:27] rogpeppe, hi, are you landing your lp:~rogpeppe/juju-core/259-charm-relation-name branch soon? it's conflicting with trunk in state/state.go, and I'm not confident enough to fix it myself [11:32] teknico: yeah, i was planning to land it any time now. would you like me to hold off for a bit? [11:34] rogpeppe, uh? not at all, why would I? please go ahead :-) [11:34] teknico: oh, cool; sorry i misunderstood. [11:35] rogpeppe, my command of the English language is definitely not up to these kinds of nuances :-) [11:36] teknico: your english is great! i wasn't quite clear what you wanted though. [11:45] rogpeppe, since the AddRelationResults struct is now going to contain just Endpoints []state.Endpoint , I wonder whether I even need to define it [11:46] teknico: the result of an api call must always be a struct [11:47] rogpeppe, oh, ok then [11:47] teknico: i think i was thinking it would probably be better as Endpoints map[string]state.Endpoint [11:48] rogpeppe, oh right, sorry, I neglected that part [11:48] thanks for reminding me [11:51] rogpeppe, uhm, actually yesterday you suggested returning map[serviceName]charm.Relation, I wonder which one's best [11:51] teknico: sorry, that's what i mean [11:51] teknico: you can't return state.Endpoint [11:51] right === benji___ is now known as benji [11:57] teknico: that branch has now landed [11:58] rogpeppe, awesome, thanks again for all your work! [11:58] teknico: np [12:48] rick_h_, hi. I haven't been looking too carefully at the latest css changes, but please don't break the degree of responsiveness we had before. Things look more or less ok right now, but I get nervous when I read "The new header is not yet responsive." from huwshimi. Note that I do currently see a regression on the behavior when I resize the window: the right and bottom scrollbars are in place when calculations a [12:48] re made, add then removed when the new size is set. This leaves gray bars at the right and bottom when it happens. The way we solved that in the past was to shrink the interface to the smallest acceptable size before calculating dimensions, and then expanding it back out. [12:48] guihelp: last week did we agree to not require "one 'var' per variable" or to forbid it? [12:48] gary_poster: definitely, I make sure to qa these before they ok'ing them. I'm also nervous as he's trying to start big picture where I'd prefer if he worked from our browser code up [12:48] except in the case where it is multiline [12:49] bac we agreed to have multiple single line variables per "var" [12:49] bac: for simple assignments I think we made it optional, for complex (multiline) assignments its required [12:49] but one "var" per multiline variable [12:50] yeah, would be fine with what bcsaller said, though I don't remember that specifically. [12:50] gary_poster: yes, hatch caught the width issue and noted it in the MP but ok'd it. I'll create a bug and assign it to Huw. I asked him last night to create bugs where appropriate from the comments made in the last MP [12:50] in cases of ambiguity defer to bcsaller is my rule [12:50] ha [12:51] cool thanks rick_h_ . It is pertinent to both width and height. sounds good. === teknico is now known as teknico_away [13:03] gary_poster: am I making a "Stable" release or a "Developer" release? My guess is "Stable" but... development doesn't seem all that stable right at the moment. :) [13:09] benji why not? [13:10] it's just that we are undergoing very active development, which I suppose is reflected in the 0.x nature of the verison numbers. I just wanted to be sure I was doing the right thing. [13:13] stable and dev both benji, but let's have a quick guichat to make sure I am on the same page with you [13:13] k [13:18] * frankban lunches [13:19] hatch: bcsaller looking to include a markdown converter, any opinions on a library? Currently looking at PageDown https://code.google.com/p/pagedown/wiki/PageDown [13:20] rick_h_: you mean different from the gallery one we already provide in a handlebars helper? [13:20] * gary_poster was just trying to connect those dots [13:21] bcsaller: /me goes peeking in the tree for something that might already be ther [13:21] app/views/utils.js markdown helper [13:21] bcsaller: never mind :) [14:01] gary_poster: any ideas what to do when canonistack fails? [14:02] hatch, weep? consider tackling other tasks? stare out the window? rotate in chair? [14:03] lol [14:04] hatch :-P for your branch just keep getting that prepped for review. I have a plan for at least killing the canonistack failures faster [14:04] I sketched it last night [14:04] the only problem is a dependency [14:04] gotcha ok I'll get this up right away [14:04] cool [14:14] gary_poster, hi, sorry, I'm late [14:14] teknico, oh hai :-) [14:15] teknico, one sec [14:15] sure [14:23] ugh I hate it when I commit and forget to run make lint before lbox :) [14:23] we should change lbox so that it runs lint before check :D [14:26] proposed [14:29] jujugui call in 2 [14:29] noooooooooooooooooooooo [14:29] * benji reboots [14:46] hatch: the modellist bubble event did work as you described. thanks. [14:46] excellent [14:55] It's a hard life. http://ubuntuone.com/gallery/56atUQ5IHr3CkOXeT605zL/IMG_20130328_084932.JPG [14:58] rogpeppe: re apiinfo in the uniter agent.conf, do we have a bug for that, or do you want me to file one? [14:58] Makyo: hehe [15:06] frankban: yeah, if you could file one, that would be great. but perhaps phrase it slightly differently: "we want our charm to know the address of the API. we're currently doing it like this. this solution (in uniter agent.conf) might be better" [15:12] rogpeppe: filed bug 1161443 [15:12] <_mup_> Bug #1161443: Make the API address easily accessible by charms

< https://launchpad.net/bugs/1161443 > [15:13] frankban: thanks! (and i added a comment giving my preferred solution - i'm still not sure if fwereade will go for it though) [15:13] rogpeppe: thanks, an env var would be great [15:21] hey frankban, where is the charm log in juju- core [15:21] I found charm [15:21] /var/lib/juju/agents/unit-juju-gui-0/charm [15:21] gary_poster: /var/log/juju/ [15:22] ah [15:22] cool [15:22] thanks [15:22] gary_poster: welcome [15:29] rick_h_, benji, the scrollbars are a worse regression than I thought [15:29] scrollbars? [15:29] rick_h_, benji, yes, I think we may need to revrt before we release [15:29] oh, the "regression" part was what is meant to me [15:29] s/to/fo/ [15:29] yes :-) [15:29] s/fo/for/ [15:29] * benji goes back to typing school. [15:30] k, I'll not release until that is fixed [15:31] benji, rick_h_ no matter how big my browser is, whhen I go to https://ec2-54-235-226-84.compute-1.amazonaws.com/ (which is trunk) I see scroll bars until I adjust [15:31] trying on uistage as well [15:31] btw frankban qa for charm is great. ,arking... [15:31] marking... [15:32] gary_poster: :-) [15:32] https://ec2-54-235-226-84.compute-1.amazonaws.com/ has scrollbars for me in Chrome, none in Firefox [15:33] benji what about http://uistage.jujucharms.com:8080/ [15:33] * benji looks [15:33] FF OK [15:34] Chrome OK too [15:35] benji me too. :-/ ok call off the dogs. I guess we can make a release. weird that it is specific to go env [15:35] quite weird [15:41] anyone have any objection to me upgrading us to Node 0.10.1 now that the regression is fixed? [15:42] bcsaller: gary_poster changes have been re-proposed [15:51] bcsaller: created a slacktask for your comments [15:51] I* [15:51] hatch: thanks [15:52] my dogs can hear my neighbours car door close from 2 houses down but somehow they can sit right infront of my sub while my music is on [15:52] the force is strong with these ones [15:52] gary_poster: http://jujugui.wordpress.com/2013/03/28/deploying-the-gui-in-a-juju-core-environment/ [15:52] hatch: upgrading sounds fine to me, with due caution of course [15:53] http://starwars.com/This-Is-Madness/ [15:53] ugh I can't believe Ahsoka Tano won over Captain Rex [15:53] benji: yep of course :) [16:00] frankban, cool [16:00] frankban, how does the gui charm know if its py or go? [16:01] hazmat: it checks whether or not ../agent.conf exists [16:17] gary_poster: this bit of the release process doesn't seem right: "Check that read and execute permissions for all are present on all files [16:17] and directories, especially in the ``node_modules/`` directory. [16:17] " [16:17] the not-right part is that not all the files do have the a+x bit set [16:18] should it be more like "all files are a+r and the files in node_modules are a+rx"? [16:18] (I am writing a "find" command that will verify this for us in one step that I will add to the release instructions.) [16:26] hatch: no objections to Node 10.1 [16:26] hatch I gave you a LGTM so will only re-review if you request. would you like me to look at it again? [16:27] frankban, cool :-) [16:27] :-) [16:28] gary_poster: no I think the emails were delayed [16:28] it's been merged for a while now :) [16:28] cool hatch :-) [16:28] benji maybe so. OTOH we can clean up that tarball now [16:28] do we need node_modules now? [16:28] I forget [16:28] but don't think so [16:28] I have no idea. Shall I investigte? [16:29] or shall I make a release and a card to investigate? [16:29] benji :-) +1 [16:30] I'll assume that the instruction that they should be executable is erronious and I will remove it. If I am wrong, QA will tell me. [16:30] ok benji [16:34] bcsaller: I'm pretty sure that we can utilize the new YUI Promises stuff to avoid our multiple rendering stuff [16:35] all these double backticks irritate me; probably the single biggest failign of reST [16:41] jcsackett: are you around? [16:42] hatch: for some definition thereof, sure. :-) [16:42] haha - just wondering if you had a sec for a guichat so I can explain the questions [16:42] hatch: sure. guichat? [16:42] e.g. hangout? [16:42] yup [16:43] i'm in [16:43] in what? is there a saved one i don't know about? [16:43] pmd [16:47] rogpeppe, hi. is the "put all the info in the watcher that we need" branch already in review or near review, out of more than merely idle curiosity? :-) [16:47] gary_poster: no, i've been on other fixes, i'm afraid [16:48] ah ok understood [16:48] gary_poster: if benji wants to take the reins, that would be fine [16:48] gary_poster: currently i'm delving into a couple of odd looking bugs in the AllWatcher [16:49] rogpeppe, ok it sounds like we ought to take the expose stuff then. thank you [16:49] expsoing the attrs we need, I mean [16:49] gary_poster: that would be great if you could, thanks. [16:49] np, thank you [16:49] gary_poster: i think i'm better doing what i am currently [16:50] rogpeppe, that was what I heard as well :-) [16:50] Nexus 10 just showed up in a box, wrapped in bubble wrap, inside another box, inside a bag, inside another bag. V. thorough. [16:51] :-) [16:51] glad it appeared [16:52] Good timing, too. Should start getting dog ready for vet. Won't be long. [16:54] Makyo: that's how my paperwork showed up from head office too [16:54] wrapped in about 3 recursive layers [16:55] :D [16:55] maybe it's a policy [16:55] lol [16:55] Hah, yeah :) [16:55] No US wall charger, but oh well, just USB. [16:58] now all we have to do is figure out how to run 120volts through a USB cable and we will have a universal power system [16:58] :) [16:59] Still want my wireless charger. [16:59] Anyway, dog to vet. Back in a few. [16:59] cya [16:59] bye [17:00] :lbox: command not found [17:00] wth [17:00] heh [17:18] gary_poster: yep it needs to be changed in the charm too - but that's another branch [17:18] :) [17:18] cool hatch [17:21] gary_poster: you might be relieved to hear that the first bug wasn't actually a bug in the allWatcher itself, but in the testing infrastructure around it. [17:21] :-) cool rogpeppe [17:21] rogpeppe, have a look sometime? https://codereview.appspot.com/8094045 [17:21] gary_poster: i'm still not sure how to fix it though :-) [17:21] rogpeppe, lol, I have confidence [17:22] teknico: looking (makes light relief!) [17:23] gary_poster: the problem is that we create the allWatcher immediately the mongo State is created, but then the test stuff sets the admin password, and that then denies access to the currently-running allWatcher... [17:23] heh [17:24] gary_poster: it was one of those "what the frick is happening?" bugs [17:24] yeah, I can imagine [17:27] I see these errors in Firefox: [17:27] Timestamp: 03/28/2013 12:24:13 PM [17:27] Error: not well-formed [17:27] Source File: http://jujucharms.com/search/json?search_text=series%3Aprecise%20owner%3Acharmers [17:27] Line: 1, Column: 1 [17:27] Source Code: [17:27] { [17:27] it doesn't seem to affect the apps performance, but it is still disquieting [17:29] benji: hmm, the json from there passes json linting [17:31] benji: maybe the response isn't sending a content-type back and FF wants to try html on it or something? [17:32] rick_h_ the events stuff was moved to an attr on purpose to avoid cross instance issues [17:32] as prototype properties are shared cross instance [17:33] hatch: but cant' it just go into the same section ATTRS lives in? [17:33] { _events: [], ATTRS } [17:33] isn't that all isntance related stuff there from Base? [17:33] oh you want it to be a static? [17:34] honestly I've never put it there [17:34] hatch: well, I just don't want to create events and such tied up to something that doesn't need it like this [17:34] hmm [17:34] a Base drive ATTR is a lot heavier than a private property [17:34] well... [17:34] 'feels wrong' [17:34] if we don't define the property then we can use 'this._events' [17:34] then it will be scoped to the instance [17:35] right, that's what I mean [17:35] although then we have to be VERY sure that we are never calling this._events when the context is different [17:35] _events is meant for two things, creating events and destructor cleanup [17:35] how else should it be accessed? [17:36] teknico: reviewed [17:36] assume we have a callback executed under some other context and we go this._events... [17:36] then it will point to the wrong context and those events won't be detached [17:36] whereas this.get('_events') will fail [17:36] we should just get to adding an extesion for Base that adds methods addEvent, cleanEvents [17:36] lol [17:36] agreed [17:37] well, that type of scope issue is always present in any JS work being done [17:37] yeah but usually it doesn't come with the penalty of zombie event listeners [17:37] :) [17:37] for the record I totally agree with you [17:38] ok, is there a way to generate a unique id for an instance of Base? [17:38] I'm just erring on the side of caution [17:38] make events a global watcher and add all events to it. Then destructor references it on cleanup [17:38] at then we can track/check for left over events in tests/etc [17:38] rogpeppe, thanks, looking [17:38] hmm [17:38] now that's an interesting approach [17:39] well for this branch it's referencing both _events and .get(_events) and I don't think a ATTR is the right place for this stuff [17:39] I'd vote investigating sticking it next to ATTRS and make sure it's instance scoped, if it's not then worst case just this._events = [] in the initializer [17:40] this is a really simple bit of code and scope shouldn't be an issue [17:42] sure ok ok [17:42] rick_h_, hatch: does handlebars provide any helpers to easily handle pluralizing? e.g. if extra is 1 "result" if extra is > 1 "results"? [17:42] not that I know of [17:42] jcsackett: I find sometimes just changing the text is good. "View X more" [17:42] no plurals needed :) [17:43] rick_h_: if you're good with that; you pointed out the wireframe's actually say "see x more results" [17:43] let UX catch us before we waste time on it [17:43] yea, so "See X more" then :) [17:43] but if it's pulled out from the method into a template we can easily change it to a functino call to do plurals if needed [17:43] hatch, bcsaller, I added docs about our Jenkins setup on the wiki page. https://wiki.canonical.com/JujuGUICI#preview Good enough? [17:44] checking [17:44] rick_h_: you alright with it remaining "see less" then? "see fewer" feels awkward. [17:44] really? less seems to not fit my tongue but I can't figure out why. [17:45] jcsackett: but yea, if it's just my strangeness leave it for sure [17:45] fewer is count [17:45] where's deryck when you need some english [17:45] have no idea what you are talking about :-) [17:45] rick_h_: see gary's point. fewer is when you have a number. [17:45] gary_poster: in the search results you see XX by default with a link to "show more" and then when you show more the link is "show less" [17:46] we could do "see X fewer", but that seems uneccesary for the intent. [17:46] jcsackett: maybe that's what's strange is that it's XX more (numbery) but not on the way back [17:46] jcsackett: yea, so just ignore me [17:46] we are accustomed to "less" in vbrowser because it is viaual [17:46] visual [17:46] less information [17:46] fewer pieces of data [17:46] rick_h_: ignoring away. :-) [17:47] lol, "fewer pieces of data" though. It's not "less pieces of information" is it? [17:47] gary_poster: If the wiki is the place we save the Jenkins script we should put a note at the top of that script saying to save any changes back to the wiki. Other than that looks good :) [17:47] * rick_h_ goes back to english school...been too long [17:48] bcsaller, was doing that in description on jenkins. will also put it at top of script. Not sure if wiki is best place but it is OK and easy :-) [17:48] jcsackett: let me go play with a jsbin for a minute on the _event stuff. [17:48] thank you for review [17:48] rogpeppe, re: AddRelation(endpoint0, endpoint1 string) -> (endpoints .. string), I guess I'll have to change DestroyRelation too [17:48] rick_h_: argue with jeff. i don't care, honestly, but i don't want to go back and forth between you two. :-P [17:48] jcsackett: rgr [17:49] gary_poster: looks good - thanks for doing that! bcsaller heh that script is a lot longer than our original lol!!! [17:49] teknico: good call, yes please, thanks [17:50] teknico: you could probably do it in the same CL if you wanted. [17:50] cool thanks hatch [17:50] rogpeppe, that's what I'm doing, yes [17:51] gary_poster: so, my current take on the SetAdminPassword issue is that if you call SetAdminPassword, you poison all existing watchers. i *think* that's a reasonable stance, but YMMV. [17:53] rogpeppe, I think paranoia is reasonable for juju's use cases. however the watcher seems like the wrong place to be paranoid [17:53] gary_poster: i don't see a reasonable alternative unfortunately. [17:53] if you are going to take that stance--and I think it is a reasonable one--then it would make more sense to dump users off and require reauthentication. [17:54] gary_poster: they're all using the same mongo client, and that's been shut out [17:54] gary_poster: i think that's what will happen in practice actually [17:54] rogpeppe, but only when you try to use a watcher? [17:55] rogpeppe, I also think that ideally the error message would clearly indicate what's going on and why, but that's arguably nice to have in comparison [17:56] gary_poster: hmm, i've just realised my solution won't work. SetMongoPassword really does poison all other clients. [17:56] heh [17:56] gary_poster: and in this case we've got two clients [17:56] juju itself being the other? [17:57] gary_poster: the one started by the dummy environ, which starts at Bootstrap time, and is what the API server is running on. and one in the juju.Conn which the clients are using. [17:58] where dummy environ == roughly "juju itself" in the context of the tests IIUC [17:58] gary_poster: on the first connection, the client connection sets the password (so that we can avoid sending it up plaintext in the cloudinit data) [17:58] gary_poster: yeah [17:59] gary_poster: and this *is* an issue for the real live environment, i now realise [17:59] hatch: so if we change _events to being set in the intializer so it's per instance does that change your LGTM for jcsackett? If so I'll cave and let the ATTR go just feels dirty, but maybe less error prone potential. [17:59] rogpeppe, replied to your review, thanks. I added a few questions myself, please have another look [17:59] teknico: will do (although i have to go *very* shortly, and won't be back until Tues, i'm afraid) [17:59] nope that's fine [17:59] jcsackett: ok? ^^ [18:00] rogpeppe, I'm out Wed-Fri next week btw [18:00] gary_poster: ok, good to know [18:00] you're right that it's more performant I was just concerned with the potential issues associated with it [18:00] hatch: understand. Yea, we need a better long term solution. [18:01] rogpeppe, it's actually just *one* question :-) [18:01] rick_h_ when we do build this solution it should be done to be contributed back to yui [18:01] hatch: +1 [18:03] teknico: replied [18:04] rogpeppe, thanks, have a great weekend! [18:04] teknico: and you! [18:04] I'm working tomorrow (but I'll be off on Monday) :-) [18:06] gary_poster: actually i've realised it's *not* an issue live (the bootstrap process creates a new user) and that points me to the right solution... [18:06] gary_poster: thanks for being a fine sounding board for my thoughts [18:06] ah, make a new user? echo chamber, perhaps ;-) but glad I helped [18:08] gary_poster: think of yourself as a stuffed bear :-) http://talkaboutquality.wordpress.com/2010/08/30/tell-it-to-your-teddy-bear/ [18:08] lol [18:10] am off now. happy weekends all. [18:10] hatch we don't need npm as a build dependency because node now includes it right? [18:10] bye rogpeppe ! [18:11] gary_poster: correct - and verified locally [18:11] cool thanks [18:11] LGTM [18:11] which I am kind of sketched out about because they are two different applications with obviously conflicting apis [18:13] hmm looks like I need to create a wordpress account [18:13] I gota spread my beliefs to the world! [18:14] gary_poster: do we know what happens if trunk commits happen prior to it completing a test? does it queue them up? [18:14] or run the latest [18:17] hatch, queu [18:17] e [18:18] ok good :) [18:18] benji how goes release? [18:19] could I get one more review on this 4ln diff :) https://codereview.appspot.com/8105043/ [18:20] ppllllleaaaasseee [18:28] gary_poster: anything in particular you would like me to tackle ? [18:29] hatch, yes. congratulations on finishing CI. We will improve it later as a separate task. Meanwhile, we have a new "Story A" [18:29] I've created cards for the tasks, but I need to talk you through it. [18:29] sure - now? [18:30] I have a call with bac. bac, can we postpone our call by 30 min or so? [18:30] or would now be better? [18:30] nope take your time [18:30] gary_poster: either [18:30] I'll take a 30min lunch [18:30] hatch ok cool talk to you then [18:30] bac, joining [18:33] gary_poster: back from lunch; I figured out the little problem I had (relating to version.js) and am in the middle of QA now [18:41] cool benji thx [18:46] our two-factor auth setup is aweful; my phone and the server keep getting out of sync and have to be reset [18:47] Hm, Ubuntu's pretty on the tablet, though a little flaky. gary_poster - if I read the email right, I should put android on this, right? [18:47] wait! this is staging, two factor auth doesn't work here.... [18:47] Makyo, no [18:48] Makyo, Ubuntu touch. Though you will probably want to flash it to get it to newest [18:48] daily [18:48] Makyo will also forward you a few emails for contact and debugging info [18:48] gary_poster, thanks. Can't open the browser on the current version :) [18:48] Makyo, heh [18:50] Makyo, to flash new version, you start in ubuntu (not bootloader, despite instructions that confused me) and do step 4 of https://wiki.ubuntu.com/Touch/Install [18:50] You'll need step 1 before that [18:50] but step 2 and 3 are unnecessary now [18:50] steps [18:54] hatch, I think the most recent Jenkins failure indicates that you broke the charm :-) [18:55] yay CI! :-) [18:59] rick_h_: sorry, was finally taking a lunch break. so, just in initializer create. this._events? [19:00] jcsackett: correct [19:00] hatch, http://pastebin.ubuntu.com/5656043/ [19:00] that's from charm machine from Jenkins [19:00] I'm going to make a fresh build locally and see if I can dupe [19:01] awwwww mann [19:01] oh wait [19:01] no that's a grunt error [19:01] hatch, dunno, that's from benji, and it is doc only :-/ [19:01] so maybe a new spurious failure? [19:02] hmm [19:02] or I screwed up the docs THAT bad [19:02] :-) [19:04] how do you deploy the charm locally? I have always spun up ec2 instances :) [19:04] hatch, dunno, rerunning make was fine. :-/ maybe crazy virtualization issue? [19:04] never seen that one before [19:06] maybe if we get an install error we should dump the machine and juju logs [19:07] maybe so [19:07] ran make clean-all && make build [19:07] everything fine. [19:07] hmm that's odd [19:07] Going to re-run test on jenkins [19:07] seems spurious [19:07] :-( [19:08] hatch guichat? [19:08] sure === matsubara_ is now known as matsubara [19:55]