[12:01] <bac> hi frankban 
[12:01] <frankban> hi bac 
[12:01] <bac> frankban, i see your sprite branch is now on staging.
[12:01] <frankban> bac: I am seeing the behavior you described there
[12:02] <bac> frankban, oh, it seems to work for me!
[12:02] <frankban> bac: lol 
[12:02] <bac> frankban, but i now see that the up/down chevrons have a white background, not transparency, so they look funny on the grey background.  have you seen that?
[12:03] <frankban> that's crazy bac, I also see the problem you described in the review (the chevron in the menu bar is still the old one)
[12:04] <frankban> bac: it seems that the old index.html is being served by staging
[12:04] <bac> hmm
[12:04] <bac> browser cache?
[12:06] <frankban> bac: cleaned, mabybe the html cache manifest?
[12:06] <frankban> bac: could you please try to run "make appcache-force" in staging, and then restart the server?
[12:09] <bac> frankban, i did a make clean, is that sufficient?
[12:10] <bac> check it out now
[12:13] <bac> frankban, i did appcache-force/restart
[12:13] <frankban> bac: now it works, thanks, and you are right, the chevrons are not transparent
[12:13] <bac> i think clean should wipe out the appcache manifest but it does not
[12:14] <bac> frankban, glad we're all seeing the same thing now
[12:15] <frankban> bac: maybe we should run  appcache-force each time we update staging. We can clean the cache and the app data each time, but not our users.
[12:15] <bac> frankban, yes, i think it should be part of the clean target and we should just run make clean
[12:17] <frankban> bac: re the chevrons, they are transparent in the assets and in the sprite :-/
[12:21] <bac> oh
[12:22] <bac> frankban, will you also follow up with the designers regarding chevron up and down?
[12:23] <frankban> bac: you mean, the reversed directions?
[12:24] <frankban> bac: re the chevrons, locally I have the sprite with a transparent backgorund, in staging the sprite is not transparent
[12:25] <frankban> bac: white background in staging :-/ it seems we should fix how we deploy staging.
[12:28] <frankban> tveronezi: any idea on why the sprite's background in staging is not transparent?
[12:29] <tveronezi> frankban: I am trying to see what is the problem... just a sec. :)
[12:30] <frankban> tveronezi: cool thanks
[12:46] <tveronezi> frankban: I didn't get the problem. Is it something related to the header? It does not use the "sprite". It uses a regular image. I found this trick to make transparent backgrounds, but I dont see it in our code. http://css-tricks.com/snippets/css/transparent-background-images/
[12:48] <frankban> tveronezi: it is related to the chevrons_(up|down) in the charm panel. they have a white background in staging, they are transparent locally. they use the sprite. Inspecting the code, it seems that the sprite in staging is not transparent
[12:49] <frankban> tveronezi: to see those, you might want to clear your browser cache
[12:57] <tveronezi> frankban: hmmm... they look the same to me... http://ubuntuone.com/3ukBtOlhcydsB8VtlZtKha  http://ubuntuone.com/1QpOBke8x9ah5A9BkTj0CZ
[13:00] <frankban> tveronezi: I am referring to the charm description view. Open the charm panel, select a charm, you should see chevrons on each section of the description.
[13:07] <gary_poster> hey all
[13:07] <tveronezi> frankban... hmmm. I see the problem in both local and staging. I need to check the sprite generation. 
[13:07] <frankban> tveronezi: cool
[13:07] <gary_poster> teknico, hey.  how go charm tests?  You about ready with a branch?  or would it be good to have someone to pair with?
[13:10]  * gary_poster reviews
[13:10] <gary_poster> I am reviewing Makyo's bug 1077006 branch
[13:10] <_mup_> Bug #1077006: Charm panel left border should be 2px as per UX design <juju-ui:Triaged> < https://launchpad.net/bugs/1077006 >
[13:10] <benji> IRC works better when you turn on your client.
[13:11] <gary_poster> words to live by
[13:27] <hazmat> g'morning
[13:29] <bac> gary_poster, matt's branch has two reviews.  both frankban and i tagged the card before starting.
[13:32] <bac> morning hazmat.  i had to poke uistage a bit yesterday and today.  i think we need to update the cronscript to 'make appcache-force' before restarting the gui
[13:33] <hazmat> bac, k, i'll take care of it
[13:33] <bac> hazmat, i also changed the cron to run every fifteen minutes as that is what most people thought was happening.  it was actually only run every 30 minutes.
[13:34] <hazmat> bac, where is the cron now?
[13:34] <hazmat> i don't see it in crontab for ubuntu or root?
[13:35] <hazmat> just added make appcache-force to cron script
[13:35] <bac> hazmat, 'crontab -l' and 'crontab -e' is what i used
[13:35] <hazmat> ah.. ic
[13:35] <bac> as ubuntu
[13:36] <hazmat> bac are you sure re 30m?
[13:36] <bac> hazmat, previously it was 15,30
[13:37]  * hazmat discards some faulty gray matter
[13:37] <bac> oh, sorry, it was 15,45
[13:38] <gary_poster> bac cool thx.  Forgot about that.  In somewhat related issue, I am seeing problems in my local instance having to do with some images that are being rendered below where they are supposed to: http://ubuntuone.com/6wirTIHiK40RGV3ahJ3a7G
[13:38] <gary_poster> I have done make appcache-force
[13:38] <gary_poster> and cleared cache
[13:38] <gary_poster> I saw some discussion of problems in log from yesterday
[13:38] <gary_poster> but no resolution
[13:39] <gary_poster> I also see "Waiting for yui.yahooapis.com"
[13:40] <gary_poster> Looks like we are getting css and that is taking awhile
[13:41] <gary_poster> bac, frankban, tveronezi you all were talking about this yesterday I think ^^^ .  any hints?
[13:44] <gary_poster> This link is taking 15 seconds: http://yui.yahooapis.com/combo?3.7.3/build/widget-modality/assets/skins/sam/widget-modality.css&3.7.3/build/widget-stack/assets/skins/sam/widget-stack.css&3.7.3/build/panel/assets/skins/sam/panel.css&3.7.3/build/overlay/assets/skins/sam/overlay.css
[13:44] <gary_poster> heh, for a 304
[13:45] <tveronezi> gary_poster: The quick resolution was to use the debug mode in the demo server;  The css stuff will be fixed by my next branch; 'gallery-markdown' and 'gallery-ellipsis' are not available in our static yui files, so we still need to download those from yuilibs.
[13:45] <bac> gary_poster, we had that problem on staging yesterday
[13:45] <bac> use of gallery-ellipsis is not in trunk yet
[13:45] <bac> tveronezi, i still cannot get it to download
[13:46] <gary_poster> bac, ack thanks.  tveronezi thanks.  how did this get in trunk--what did we miss?
[13:46] <bac> gary_poster, if you'd like to pair i'd appreciate it
[13:46] <gary_poster> bac ok cool, fire up a hangout
[13:46] <bac> gary_poster, one issue is the combined file has 'use strict' at the top.  GlobalConfig is not defined with 'var' and that causes a failure.
[13:47] <bac> easy fix is to add 'var' in two modules.js and modules-debug.js
[13:47] <bac>  s/two//
[13:47] <gary_poster> bac oh ok cool
[13:47] <bac> our story for grabbing everything so we serve it up ourselves is not fully done i think
[13:47] <bac> making hangout
[13:48]  * bac installing plugin
[13:48]  * bac getting tea
[13:57] <tveronezi> bac: I can download those css files. http://ubuntuone.com/6vHKb78Lq8MFTQEAuWqxkf . If I add galery-ellipsis to the charm-panel.js, it adds the ellipsis to the yuilib url... http://yui.yahooapis.com/combo?gallery-2012.10.31-20-00/build/gallery-markdown/gallery-markdown-min.js&gallery-2012.10.31-20-00/build/gallery-ellipsis/gallery-ellipsis-min.js 
[14:01]  * teknico is back from lunch
[14:01] <teknico> gary_poster, nope, still struggling with it, would very much like to pair
[14:01] <teknico> gary_poster, I already got some help from frankban, but am open to pair with anyone
[14:02] <gary_poster> teknico, ack.  benji or frankban ^^^ ?
[14:03] <teknico> ("it" being setting up charm tests)
[14:03] <benji> gary_poster/teknico: I certainly can.  I have started a card already this morning, however.
[14:04] <gary_poster> benji, how far along are you on that one, then?  and/or will it be done soon? :-)
[14:05] <benji> gary_poster: probably not "soon", I was trying to figure out the roll in/out transitions for the charm panel; if we switch to ripping out the fade and making it just disappear, that would be quicker
[14:06] <gary_poster> benji, suggestion open to your veto: just make it disappear, make a low priority bug for the roll-in/roll-out, and move to helping Nicola.  wdyt?
[14:07] <benji> gary_poster: that's fine
[14:07] <gary_poster> cool thank you.  teknico ^^^ benji will join you soon
[14:07] <teknico> gary_poster, great, thanks
[14:48] <benji> wait, wait, wait... did we completely break our development story?
[14:48] <benji> do I have to run make every time I change a JS file now?
[14:49] <frankban> benji: are you using "make debug"?
[14:49] <benji> frankban: no, should I?
[14:49] <frankban> benji: it seems so.
[14:50] <benji> hmm
[14:51] <benji> I am displeased.
[14:56]  * teknico on school run, back in half an hour
[14:58] <benji> gary_poster: the charm panel fade removal is very simple, but I figured that at least you should take a glance: https://codereview.appspot.com/6854043
[14:58] <benji> it took much longer than it should because I was sabataged by the new default of minimizing JS
[14:58] <benji> (we should revisit that, it is stupid)
[14:59] <gary_poster> benji approved
[15:00] <benji> cool, landing
[15:01] <benji> re. review approval message: lol
[15:01] <benji> teknico: what's up?  how can I help?
[15:13] <tveronezi> benji: it seems the rev 239 breaks the charm search panel. 
[15:14] <benji> tveronezi: is rev 239 the branch I just laned?
[15:14] <tveronezi> Yes. I cant see the panel now.
[15:15]  * benji answers his own question: "yes"
[15:16] <benji> tveronezi: in what way does it break?
[15:16] <frankban> benji, tveronezi: confirmed, also in staging, the panel doesn't show up
[15:16] <tveronezi> benji: I click in the icon and nothing happens. If I revert one revision, it works again.
[15:16] <benji> tveronezi: which icon?
[15:17] <tveronezi> benji: charm search. http://ubuntuone.com/4nn1DSpQsT2GW7U45hHOmf
[15:18] <benji> hmm, I wonder why it worked in my branch; reverting
[15:19] <benji> I wonder what the best way to reviert is given lbox
[15:19]  * benji settles on "uncommit"
[15:19]  * benji realized that it doesn't do what he thought it would do.
[15:31] <benji> tveronezi and frankban: fix comitted; thanks for the heads-up
[15:31]  * teknico is back
[15:32] <frankban> benji: was it the opacity?
[15:32] <teknico> benji, sorry, was afk
[15:32] <benji> frankban: here is the fix: http://paste.ubuntu.com/1355684/
[15:35] <benji> teknico: so, what can I do to help?
[15:35] <teknico> benji, hangout?
[15:36] <benji> teknico: sure, yours or mine?
[15:36] <teknico> benji, emily's: https://tinyurl.com/see-emily-code
[15:36] <benji> ??
[15:36] <teknico> :-)
[15:37] <teknico> benji, frankban set that up for pairings
[15:58] <gary_poster> bac bcsaller benji frankban hazmat jovan2 Makyo mattuk1972 teknico tveronezi call in 2
[16:00] <tveronezi> gary_poster: i need to restart... I will back in a sec.
[16:00] <gary_poster> ok
[16:10] <Makyo> benji, lp:~makyo/juju-gui/remove-sub-rels - https://codereview.appspot.com/6782063/
[16:11] <benji> Makyo: thanks; I'll take a look right away
[16:25] <gary_poster> early lunch biab
[16:28] <Makyo> mattuk1972, ping
[16:28] <mattuk1972> hey
[16:28] <mattuk1972> makyo, hey
[16:29] <Makyo> mattuk1972, bug #1077006 is in staging - it's the inset left border on the charm panel.  Have a second to take a look at it and see if it meets design?
[16:29] <_mup_> Bug #1077006: Charm panel left border should be 2px as per UX design <juju-ui:Fix Released by makyo> < https://launchpad.net/bugs/1077006 >
[16:31] <mattuk1972> makyo, its almost there - its kind of odd how if it appears on a dark colour its lighter than the dark
[16:32] <mattuk1972> it cuts off a px where it ends too
[16:32] <mattuk1972> might have to rethink the colour i sent you
[16:33] <Makyo> mattuk1972, dark colour as in the header where it says 'precise', or when you click deploy and it shows the charm name?
[16:33] <Makyo> And end as in down at the bottom?
[16:33] <mattuk1972> yes to all of that
[16:33] <frankban> tveronezi: I see the old friend "Uncaught ReferenceError: GlobalConfig is not defined " when I run "make server" in your branch
[16:34] <mattuk1972> maybe ill have to rethink that
[16:34] <mattuk1972> graphic device
[16:34] <frankban> tveronezi: "make debug" works well...
[16:34] <mattuk1972> it really works on this light grey spaces but mess up on dark
[16:35] <tveronezi> frankban: whats your browser? 
[16:35] <frankban> chromium
[16:35] <frankban> tveronezi: cache cleaned, appcache forced.
[16:35] <tveronezi> precise?
[16:35] <frankban> quantal
[16:36] <tveronezi> ok... let me check that...
[16:36] <frankban> tveronezi: sure
[16:36] <Makyo> mattuk1972, Alright.  I'll look into the dark space borders.  It's currently just an internal drop-shadow on the panel border, but that can be covered up, I suppose.
[16:36] <Makyo> tveronezi, ditto here, Chrome and FF on Quantal
[16:37] <mattuk1972> makyo, can it just be a bit darker? or more opaque? or multiply the colour underneath?
[16:37] <frankban> tveronezi: I think bac solved that issue in staging addign a "var" before GlobalConfig somewhere (maybe in module.js)
[16:37] <Makyo> mattuk1972, Yeah, that's what I'll be looking into.
[16:39] <mattuk1972> makyo, are they the new simpler svg assets I'm seeing in staging? because they are rendering way nicer for me
[16:39] <Makyo> mattuk1972, Yep, plus some FF specific improvements.
[16:44] <tveronezi> Makyo, frankban: I simply cannot reproduce it here. I've tried everything: chrome, chromium and ff in precise and quantal. It works fine. Actually, it could never fail because the resulting combined file creates  declaration like... var juju_config = {...}, GlobalConfig={...}, ...   
[16:45] <tveronezi> Makyo, frankban: I dont know what is going on.
[16:45] <benji> teknico: I am done with my code review.  How can I help you on the charm?
[16:45] <tveronezi> Makyo, frankban: I will commit the var chang bac did... 
[16:47] <tveronezi> Makyo, frankban: can you pull and try it again, please?
[16:47] <Makyo> tveronezi, I'm seeing it request things from /assets/... rather than /juju-ui/assets/... which was a change we made a while back for the horizon integration.  Might be something to talk to frankban / teknico about
[16:48] <teknico> benji, I'll push on some more, and pester you again once I hit the next roadblock :-)
[16:48] <frankban> Makyo, tveronezi: yes, the 'juju-ui' prefix must be restored. I already added a note to my review.
[16:48] <tveronezi> Makyo, frankban: This is something related to the server.js. There is a comment about this change.
[16:48] <benji> teknico: ok; I'll look for something else to work on then
[16:50] <Makyo> tveronezi, ah, alright.
[16:50] <Makyo> tveronezi, This is what I'm seeing in the minified JS: var juju_config={consoleEnabled:!0,serverRouting:!1,html5:!0,container:"#main",viewContainer:"#main",transitions:!1,charm_store_url:"http://jujucharms.com/",socket_url:"ws://localhost:8081/ws"};GlobalConfig=
[16:50] <Makyo> Getting a semicolon rather than a comma.
[16:51] <tveronezi> Mayko: oh!
[16:51] <tveronezi> Mayko: I still dont get why this thing is working for me.
[16:54] <tveronezi> Mayko: Did you pull it again?
[16:54] <frankban> tveronezi: I didn't get the reason why the prefix cannot be preserved
[16:55] <frankban> tveronezi: now make server works for me
[16:55] <tveronezi> frankban: I need a diferent prefix, otherwise I cant get the "lib/server.js" line 77 to work.
[16:57] <Makyo> Pulled, but it was cached.  Works now, tveronezi 
[16:58] <frankban> tveronezi: ok, but why that cannot be 'server.get('/juju-ui/assets/stylesheets/:file' ... or something? 
[17:01] <tveronezi> frankban: because if I do this, a request to "/juju-ui/assets/stylesheets/:file" goes to the line 46 instead of the line 77.
[17:09] <jovan2> bcsaller: hi, what's the opposite of Expose? Unexpose? i.e. the action to undo an Expose.
[17:09] <bcsaller> jovan2: yes, unexpose
[17:09] <tveronezi> frankban: forget what I just said. It is working with the link you proposed. 
[17:09] <bcsaller> but it can also be though of as "exposed: true||false"
[17:10] <frankban> tveronezi: isn't it possible to make the server parse '/juju-ui/assets/stylesheets/:file' and '/juju-ui/assets/all-third.js' before '/juju-ui/'? I know that your solution is easier, but it could generate troubles when integrating juju-gui in other projects, e.g. jaas
[17:10] <frankban> tveronezi: oh, cool
[17:11] <tveronezi> frankban: so, we should start the urls with "juju-ui" right?
[17:11] <frankban> tveronezi: exactly
[17:11] <frankban> the static urls
[17:12] <tveronezi> frankban: do you see the same problem in the lines 70-71-72? It is from another branch.
[17:12] <frankban> tveronezi: do you mean " server.get('/assets/all-third.js'"?
[17:13] <tveronezi> frankban, yeap.
[17:13] <tveronezi> I will try to change those in a sec.
[17:13] <tveronezi> frankban ^
[17:13] <frankban> tveronezi: yes, that should be fixed as well, feel free to do that in your current branch or to make another card
[17:15] <frankban> tveronezi: so, to fully understand the problem: express tries to match all urls in order, if the first doesn't match, it proceeds to the second and so on. at the end, it raises a 404. Am I right? 
[17:15] <tveronezi> Makyo, frankban: thanks for this nice catch.
[17:16] <tveronezi> frankban: yeap.
[17:17] <frankban> tveronezi: cool.
[17:18] <tveronezi> bcsaller: It would be nice if you could check this solution. https://codereview.appspot.com/6853044/diff/1/lib/server.js It is part of the css stuff. frankban and Makyo are already reviewing it, but It would be nice to see if you approve what I did for this particular file, or if you have another alternative.
[17:19] <bcsaller> tveronezi: I can take a look soon
[17:19] <jovan2> bcsaller: the number of subordinates is shown on a service block in the graph view - is this number of subordinate services or units?
[17:23] <bcsaller> jovan2: I believe its the number of services that subordinate is related to, I can check
[17:24] <jovan2> bcsaller: a related question - how many subordinates might be typical? and maximum?
[17:25] <bcsaller> jovan2: 0 is quite common, if they are using them in their deployment 1-3 would be in the normally expected range, there isn't a hard max, but you'll quickly tax your machines if you use too many 
[17:26] <bcsaller> jovan2: It looks like that number is the count of services related to that subordinate, which makes sense 
[17:26] <bcsaller> for example "how many things are related to this monitoring service"
[17:27] <jovan2> bcsaller: I guess you are looking at the subordinate block? I'm looking at the little chart icon on the left-hand side of a normal service block.
[17:28] <bcsaller> the little 'chart' (and why is that a chart looking thing anyway?) is on the subordinate 
[17:28] <bcsaller> normal services don't have them
[17:29] <jovan2> bcsaller: see slide 2: https://docs.google.com/a/canonical.com/file/d/0BwhxhFfxY6uqY0FGaDh5RHFMUzA/edit
[17:30] <jovan2> bcsaller: I believe the chart-like thingy is supposed to indicate monitoring
[17:31] <bcsaller> jovan2: we don't have any monitoring, also these wireframe you linked seem to predate the visual design work, that chart widget is the block hanging off a subordinate service now
[17:32] <bcsaller> jovan2: I put one up at http://uistage.jujucharms.com:8080/
[17:32] <bcsaller> puppet 
[17:32] <bcsaller> the sparkline is some sort of aspirational element that makes no sense here 
[17:34] <jovan2> bcsaller: Ok I see what you've done, but see the second to last slide in the wireframes.
[17:35] <bcsaller> jovan2: Ahh, you're saying that normal services should show a count if/when they have subordinates running as well
[17:35] <jovan2> bcsaller: right
[17:35] <bcsaller> still shouldn't be a sparkline ;)
[17:35] <bcsaller> but yeah, I don't know if there is a card for that yet
[17:38] <jovan2> bcsaller: I think Nick thought subordinates could only be for monitoring purposes. If this is not so, can you give more examples please?
[17:38] <jovan2> bcsaller: if you could email me that would be great, I have to go soon.
[17:39] <bcsaller> puppet is a good example, but they can be used in many ways. Sometimes with framework charms they represent the application itself, so for example, if its a django or rails charm, the users application might be the subordinate
[17:39] <bcsaller> depending on how the charm was authored it might be the app is a custom charm and the web framework is the subordinate, we don't require it to be any one way. And we don't know about how that is structured 
[17:40] <bcsaller> jovan2: do you need more?
[17:41] <jovan2> bcsaller: thanks, that's good for now. I might some more questions tomorrow :)
[17:41] <bcsaller> np, have a good one
[17:56] <bac> Makyo, i looked at staging with firefox and dragging lines around had no perceptible lag.  moving service boxes is pretty laggy, though.  acceptable, i'd think, but noticeable.
[17:59] <Makyo> bac, Yeah.  It's still just a speed increase, not a fix.  Accessing node attributes in FF is very slow.
[18:05] <gary_poster> Makyo, big +1 on your fix for bug 1076413 that you asked for review on.
[18:05] <_mup_> Bug #1076413: Intermittently, svg content div is too wide by 1 pix <juju-ui:Fix Released> < https://launchpad.net/bugs/1076413 >
[18:06] <Makyo> \o/
[18:46] <tveronezi> Makyo: The application seems normal in ff. I see no difference from the chromium version.
[18:46]  * tveronezi lunch brb
[18:46] <Makyo> tveronezi, Alright, thanks.
[19:00]  * tveronezi back
[19:00] <gary_poster> hazmat, in juju-ui.  no rush
[20:25] <gary_poster> bcsaller, including yours, their are five remaining environment view refactoring cards, right?
[20:25] <gary_poster> there
[20:25] <bcsaller> sounds right
[20:29] <gary_poster> cool bcsaller thanks.  I'm sending out a note highlighting them to everyone.  They are not specced in the bugs, so I will ask everyone to contact you.  If the Europeans can start one, it might be nice to spec one out with writing, or confer with me on a hangout and see if I can do it after a discussion. Per discussion with Kapil, I'm also going to say that (1) we have through next week to get these landed and (2) ea
[20:29] <gary_poster> ch one should be landed with tests.  I'd like to verify with you if any of the cards are blocked; and if any of them are arguably optional from one perspective or another, without causing significant ugliness/pain.
[20:29] <gary_poster> I'd be happy to do that here or in a hangout
[20:29] <bcsaller> still might be premature, there are no examples yet, still working on that 
[20:29] <gary_poster> oh ok
[20:31] <gary_poster> can anyone help accelerate that with you bcsaller?  I don't know about your experience with pair programming, but with a good combination it really can be a big benefit.
[20:32] <bcsaller> makyo and I did ok during the sprint, not sure though
[20:33] <gary_poster> ok, leave it up to you bcsaller, though am worried about timeline and the ability of others to help swarm.
[20:34]  * gary_poster needs to get children from school
[20:34] <gary_poster> biab
[20:34] <bcsaller> gary_poster: I still have the prototype from the sprint which I'm porting to the new framework, so that could possible be a starting point, but I'd rather finish what I have 
[20:34] <bcsaller> ok, ttyl
[20:38] <Makyo> Anyone experienced YUI node.simulate(event) saying "Uncaught TypeError: Cannot read property 'sourceEvent' of null" before?
[20:38] <Makyo> This merge didn't even touch that line, and it's breaking.
[20:54] <bcsaller> Makyo: Haven't seen that one but I often have unrelated changes break tests
[20:59] <gary_poster> no
[21:19] <Makyo> Oops, was a d3 thing.  d3.mouse was expecting d3.event to be defined.  Easy to get around for testing by saying d3.event = {};
[21:42]  * tveronezi brb
[21:54]  * tveronezi back
[22:34]  * Makyo dogwalks