#juju-gui 2013-08-01 <gary_poster> hey huwshimi, another thing to put after icons but before SASS is to style the settings page, if you could. The ghost styles are perfect, and the same code is producing the html for post-deployed settings, so I suspect there's something fairly simple to do to get it working there. It might be a re-fix for you--ISTR you might have already done this. If so, sorry about us missing that :-( * gary_poster runs away into the night <huwshimi> gary_poster: I'll take a look, I haven't touched linda89@example.com. <hatch> huwshimi: just to elaborate on the settings stuff a bit - there is also a IE10 bug ticket about the settings layout issue <hatch> so if you are going to tackle that might as well keep that in mind <huwshimi> hatch: OK thank <huwshimi> s <teknico> gary_poster: one on one now, right? <gary_poster> teknico, yes, almost <bac> rick_h: have you ever seen the charmworld test suite get wedged where things ran very slowly and known good tests started failing with elasticsearch errors like (paraphrasing) ShardNotAvailableError? i rebooted, blew away the fake HOME directory and all tests pass now. * frankban lunches <gary_poster> benji, will be late. I have extra time at end so we will have time :-) <benji> gary_poster: that <benji> 's fine <gary_poster> lol <gary_poster> ok thanks <benji> the enter key and ' key are closer together this morning <rick_h> bac: yes, I've seen that. I didn't have ES running <rick_h> ends up I had to update the ppa and install it <rick_h> I *thuoght* I had ES, but figured maybe I'd missed an upgrade or something after doing what you did. <bac> rick_h: thx <sinzui> abentley, bac: do either of your have time to review https://code.launchpad.net/~sinzui/charms/precise/juju-gui/nagios/+merge/177588 <bac> sinzui: i will in a bit <sinzui> Excellent news. A train has derailed and if I smell ammonia I am too turn off the air conditioners <jcsackett> sinzui: eeee. <hatch> yesterday wasps, today ammonia....might be time to move if the danger level keeps increasing at this rate <hatch> :) <teknico> on a positive (?) note, the ammonia might kill the wasps <hatch> and flys <jcsackett> ...what keeps setting me as away... <jcsackett> hatch: danger follows sinzui whereever he goes. <hatch> lol <sinzui> We've kept the shootings to a minimum since I had children * jcsackett laughs <sinzui> Little does jcsackett know that I was held under suspicion of attempted murder <jcsackett> eh, i've always suspected. <jcsackett> you're a suspicious character, sinzui. :-) <jcsackett> no one with that many tie-tacks could be an innocent. <sinzui> Little do people realise that I am a geek in disguise. Paving the way for all geeks to look good and get dates <hatch> all geeks can get dates it just takes us longer....like 10 years <hatch> lol <sinzui> See, I beat that by 5 years <sinzui> or maybe 9 <hatch> haha <sinzui> or 1 <jcastro> rick_h: click-results thing fix today? <sinzui> I cannot think which what this works <rick_h> jcastro: coming, waiting on one other branch to get through. Last I heard an update was planned to get out this afternoon under an updated release * jcastro nods <jcastro> thanks man <rick_h> bac: is comingsoon all fixed up? <jcastro> that's really my only "kicks me in the face" bug. <rick_h> jcastro: yea :/ <jcastro> rick_h: after this I promise to not bother you for at least another 24 hours. heh. <bac> rick_h: it was yesterday <rick_h> jcastro: :P yea you can see it fixed on comingsoon <rick_h> bac: cool, I missed what was up with that. <jcastro> rick_h: oh indeed. <bac> rick_h: upgrade to d3 caused 'make build-prod' to fail. cleaned out the old and it was happy again <rick_h> bac: ah, good stuff. <jcastro> rick_h: generally speaking if I see something fixed on comingsoon it hits prod __X__ days after? What's X usually? <rick_h> jcastro: hmm, only recently had this going and so far it's 4-6 days? <jcastro> ok <rick_h> jcastro: so working that out I think. <hatch> jujugui looking for two reviews and a qa https://codereview.appspot.com/12205043/ <hatch> gary_poster: what do we do with the Needs Reboot and Security Upgrades Available? Should there be a link to landscape? <hatch> hey luca how was your time off? <gary_poster> hatch, yes. luca could we have inspector icons for that, btw? <gary_poster> hatch open in new window <gary_poster> hatchj oh no <gary_poster> don't open in new window :-P <luca> hatch: gary_poster hey guys, It was good thanks :) <hatch> gary_poster: no? Won't they have to log in separately anyways? <gary_poster> y, though they can stay logged in on gui and landscape. last time we said it would be in same window. don't remember why, but was just sticking with past decision. obv I still kinda agree with you :-) <gary_poster> hatch, luca, if you want to make a different decision together +1 :-) <luca> gary_poster: hatch they link to landscape but I was going to email you a request to make them open in a new window <gary_poster> yay :-) <hatch> excellent <gary_poster> I wish I remember the argument to have it in the same window <gary_poster> just so we would know <hatch> so a single button 'go to landscape' or some icon of some sort <gary_poster> but...yeah. prefer new window <hatch> gary_poster: I 'think' it had something to do with the session storage <hatch> being window specific <gary_poster> hatch, ah right <gary_poster> so if you go from LS back to GUI <gary_poster> then you have to log in again <gary_poster> let's try this instead :-P <hatch> yep new winder is is <gary_poster> cool <jcastro> rick_h: I was pointing out mysql as one that works <rick_h> jcastro: ah, read it as another example of fail. <rick_h> jcastro: cool, so yea, simple file extension issue <gary_poster> hatch, please ask me about css name changes on noon call. rick_h has to do with deployment, you might care too. <gary_poster> hatch sorry I mean on weekly call (@ my noon ;-) ) <rick_h> has to do with deployment? ok <luca> gary_poster: I think I remember a conversation on changing Hooks to Source but is there any document for it <rick_h> luca: I thought gary_poster did that at the sprints <rick_h> luca: yea, the tab is already called Source and the description/info at the top of that tab updated <gary_poster> luca there was a bug about it filed by Nick Veitch. I decided that it was nicer to rename the tab to "Source" rather than remove all files that were no a hook <gary_poster> so addressed the bug in that way <luca> gary_poster: that's right, I remember seeing the bug. We can discuss it next week :) <gary_poster> luca, cool, thanks, look forward to it. <benji> gary_poster: I swear.... The juju-gui-charmers charm trunk appears broken. <benji> agent-state: error <benji> agent-state-info: 'hook failed: "start"' <benji> I'll diagnose but this will likely cause a delay in landing my branch. <gary_poster> benji :-( :-( <gary_poster> benji please give me more details when you have them. pyjuju or juju core? <benji> gary_poster: juju-core; I'll keep you apprised. <gary_poster> thanks <hatch> gary_poster: created a card in the second row of inspector for the viewlet docs <gary_poster> benji, seesm like the change would be in juju core if so. we haven't changed lately <gary_poster> thanks hatch <gary_poster> benji, I mean, in a way that should affect that <hatch> our webserver is based on tornado right? <rick_h> hatch: rgr <hatch> thx <benji> gary_poster: we did this to ourselves: http://paste.ubuntu.com/5936817/ <gary_poster> benji...yes but if so... :-( been that way a looong time and nobody told us <benji> that's because they can't start the gui to click on the feedback tab <gary_poster> benji and it was definitely working relatively recently <gary_poster> 2013-07-18 <benji> we just made this change yesterday I think; I reviewed the branch that removed the charm world URL config setting (I didn't think it would have this side-effect of course) <gary_poster> benji did you deploy with any special options <benji> juju bootstrap --upload-tools && juju deploy --repository ~/juju-charms local:juju-gui -u <gary_poster> benji this change would not cause that key error: http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/revision/69 <hatch> rick_h: have a second for another hbs q? <gary_poster> of course the fact that this happened yesterday makes me sad. I though we had done that a long time ago--was sure of it in fact, because we had used this for jujucharms.com <rick_h> hatch: sure <benji> gary_poster: I think this was a change in the gui, not the charm; this is just an initial reaction at this point though, I'm trying to confirm <hatch> rick_h: thx ok here is what I'm trying to do https://gist.github.com/hatched/7bbbc76b881fa20d7b92 which obviously is not supported <gary_poster> benji, but we haven't made a release since 0.8.1 <benji> that's a good point; I wonder why this is happening <hatch> rick_h: basically i need it to parse an array to see what buttons are to be shown, and if it's in that array then show it <bac> sinzui: branch for review when you have a moment. https://code.launchpad.net/~bac/charmworld/bundle-search/+merge/178107 <rick_h> hatch: so you have to build it in the View layer before you pass it to the template. See _buildQAData in the subapp browser charm.js view <gary_poster> benji fwiw I'm trying to dupe with pyJuju now <bac> abentley: would like for you to look at it too. ^^ <rick_h> hatch: it sucks, but it's the best way to do it and that way you can test it as well. <benji> k <hatch> rick_h: ahh - yeah that's exactly what I was trying to avoid :) <hatch> thanks for sanity checking <rick_h> hatch: yea, try as you might. I've had to break down and do it in several places. <Makyo> jujugui call in 5 kanbaaaaaan <gary_poster> hatch I am in guichat if you want to talk early about css thing <gary_poster> Makyo, thanks :-) <sinzui> bac: I wont be able to get to it today <bac> sinzui: ok <gary_poster> jujugui weekly call in 2 <gary_poster> orangesquad weekly call in 2 <hatch> luca: in the unit lists in the new inspector the resolve/retry/replace section.... <hatch> not all sections need all buttons <hatch> should they be left or center justified? <hatch> aligned* <luca> hatch: centered please :) <hatch> sounds good....and for the landscape statuses <hatch> what do you want the 'go to landscape' button to say? <hatch> or look like.... <bac> gary_poster: after lunch i'd like just a few minutes to nail down exactly what you want for IoM bundle deploy demo. <gary_poster> ack thanks bac * benji lunches. <gary_poster> hatch, rick_h wanna talk now, in 15 min, or 1 hr? :-) <hatch> I'm good whenever <rick_h> gary_poster: just cooking up lunch, 1hr? <rick_h> or you guys can watch me eat on google-cam :) <hatch> what are you having? <rick_h> skillet meal <hatch> yeah I have no idea what that is <rick_h> lol, frozen meal in a bag you stick on the stove for 10min and then eat <hatch> ohh haha <hatch> I'll probably have a sandwitch <hatch> although a grilled sandwitch also sounds good <gary_poster> hatch, rick_h cool thanks :-) talk to you in 1 hr <rick_h> hatch: had grilled cheese/ham earlier in the week :P <Makyo> "This version of SublimeText 2 has expired"? Boo >:/ <rick_h> :P vim never expires <Makyo> rick_h, +1000 <hatch> Makyo: expired? <hatch> using a demo? <Makyo> hatch https://twitter.com/bzr_pull_makyo/status/362988795529940992/photo/1 <Makyo> hatch, their demos don't expire, per their website. I think it's just "please please use the most recent" <hatch> ohhh right <hatch> vim needs a paid version <rick_h> they do, it's called vim. Just pay to their selected charity <hatch> I mean so that they can develop the product to make it more user friendly :) <rick_h> there are two sets of tools in the world. consumer grade and pro grade. Consumers can't easily use pro grade. (camera, sound equipment, ... editors) :P <hatch> things aren't "discoverable" <Makyo> gVim is prosumer <hatch> and editing the config is....well.....heh <Makyo> Sigh. <hatch> I thought I found somewhere that had a config manager <hatch> for vim <Makyo> There's a few. <Makyo> There's https://github.com/spf13/spf13-vim which sits on top of a manager thing, I think. <Makyo> That had too many features for me, though. <Makyo> I couldn't see the code for all of the extra STUFF in there. <hatch> haha <Makyo> I just use stock vim, my vimrc, and ctrlp. <rick_h> jujugui review time please. ï»¿ï»¿https://codereview.appspot.com/12272043 <rick_h> and hatch sorry, I forgot I said I'd do your review. Looking for it now <hatch> yeah...that's right! <rick_h> hatch: linky? <hatch> https://codereview.appspot.com/12205043/ <hatch> Makyo: the time to setup the vimrc I think is what ultimately drove me away from it <rick_h> hatch: booo, that's back to back "error old chunk mismatch" <hatch> seriously?? <hatch> ugh <rick_h> hatch: next sprint, we'll take care of you <hatch> I'll repropose <rick_h> hatch: I'm on 3rd generation of my vimrc setup <Makyo> hatch, I've not had a single one of your reviews work, tbh, been going off MPs. <rick_h> hatch: k, thanks <Makyo> hatch, but yeah, vimrc is something you can build off others; I think both rick_h and I have good ones you could maybe crib from. <rick_h> yea, but don't ever copy anything you don't understand wtf it is. That lead from gen 1 to gen 2 <hatch> haha <rick_h> "my vim's not working, wtf...it must be one of these 200+ lines of crap I copied from some dude" * rick_h deletes all <hatch> rick_h: Makyo missmatch fixed <rick_h> hatch: thanks, looking now <hatch> tons of results about the chunk missmatch error, must be a reitveld error <hatch> rietveld <hatch> whatever <hatch> I was actually considering webstorm ide <hatch> has some really cool api docs parsing stuff <hatch> rick_h: btw I'm reviewing your branch, will also qa <rick_h> hatch: ty <hatch> lol nice test file diff <rick_h> yea, warning in the description <rick_h> had hoped reitveld would just show the indentation change, but nope :( <hatch> I bet the bzr diff shows it as all new <rick_h> yea <rick_h> bzr hates indentation changes <jcsackett> rick_h: looking at your MP now. <rick_h> jcsackett: ty <jcsackett> rick_h: making sure i understand, the important bits of the test changes are the setup/teardowns for the display tree suite? <rick_h> jcsackett: correct, the browser dom create method is shared among all suites in the new closure. The setup/teardown is adjusted to take care of things that showView auto did before. <hatch> Chrome has an update....50 tabs open....not updating :P <rick_h> hatch: no tests? <hatch> rick_h: where we are going....we don't neeeeed tests <hatch> but really though there is a card to write the ghost tests <hatch> it's still a little to much in flux imho <rick_h> hatch: up for a chat on the branch then. I'm missing some changes and really ugh about a no-test branch that goes into modifying form elements/config data <hatch> sure <hatch> your branch also failed qa....dun dun dunnnnn <rick_h> gary_poster: we up to chat ? <rick_h> hatch: doh! I qa'd. Curious what was found. Did you hit a back button again? /me always forgets to test that part <hatch> just getting repro <hatch> rick_h: ok updated the review <rick_h> hatch: rgr, thanks <hatch> guichat about my branch? <rick_h> sure thing <gary_poster> hatch, rick_h <gary_poster> yeah, guichat <rick_h> gary_poster: rgr * Makyo has to go take the dogs to dogcamp. Back in a little bit. <gary_poster> Makyo, bac either of you ready/able to talk? <bac> gary_poster: i am <gary_poster> bac cool. guichat is busy let me make a hangout <gary_poster> Makyo, you're the only one left. :-) I saw you are out; np. ping on your return. <gary_poster> benji, what's the status? <rick_h> gary_poster: guichat empty <benji> gary_poster: I've been successful in deploying the juju-gui-charmers trunk against pyJuju, but goJuju gives me the same error; I'm going to chalk it up to my goJuju being broken somehow and am moving forward QAing against pyJuju. <gary_poster> rick_h, :-) thanks <gary_poster> benji, super weird since that looks like such a bltant python error. but glad you can move forward <Makyo> gary_poster, back. <hatch> benji: kind of like your termbeamer but for sublime, vim and emacs https://floobits.com/ <benji> I saw that the other day. It looks really cool. <hatch> also found http://codeshare.io <rick_h> benji: mentioned termbeamer 3 times at PyOhio <rick_h> I should have done an open space demo'ing it. <rick_h> benji: one question came up I wasn't sure about, can you use it with your own jabber server? (mozilla folk wanted to know) <benji> did it appear and offer to help you get back to the land of the living? <benji> yep, it only needs xmpp, it doesn't do anything google-specific (AFAIK) <rick_h> benji: cool, told them I thought so but only used it with my google account <benji> and there's a new option to use a purpose-built server; one runs on termbeamer.com or they can run their own <rick_h> yea, had mentioned you were working on that. You need a blog post we can reshare around the inter-webs :) <hatch> http://finalterm.org/ <benji> finalterm looks cool, especially the context-sensitive menus; I haven't given it a try yet though <hatch> so many things to try out, who has the time <hatch> this is why I have so many tabs open <hatch> because I also have 100s of bookmarks so things just get lost haha <hatch> one of these days I'll put them into evernote or something <Makyo> There are probably better solutions for bookmarking. Just a guess, though ^^ <Makyo> Er, hatch ^^^ <rick_h> *cough* bmark.us *cough* <Makyo> Was gonna say :) <abentley> sinzui: chat? <hatch> haha <sinzui> abentley, in 2 minutes? <abentley> sinzui: okay <hatch> I have a lot of stuff in evernote <hatch> but I know the featureset rick_h has in bmark is pretty darn close :) <hatch> even if it is in python :P <rick_h> hey, I updated YUI for you :P <hatch> haha I saw that <rick_h> it's nearly 50% JS <hatch> is there a bmark.ca? <hatch> :P <rick_h> no, but you can deploy your own <hatch> should modernize the styles of it, put it on bmark.io or something and then charge /yr :P <hatch> use bootstrap 3 even!!! <hatch> lol <rick_h> nevar! die bootstrap <rick_h> I should update to pure though. Using older responsive YUI grids <hatch> can't....stop....sneezing <hatch> man I wish I could open up the rietveld comments in my code <hatch> unlikely they have an api though <rick_h> very simple api https://code.google.com/p/rietveld/wiki/APIs <rick_h> would have to fetch the issue metadata, with messages, and then parse those out I think. <hatch> ehh too much work <gary_poster> benji, please keep me up to date on charm progress. I should be stopping now but I need to make sure we have a release in progress <benji> gary_poster: I am doing what I hope is the last test now... we'll see. <gary_poster> cool <gary_poster> thanks <jcastro> gary_poster: I have no problem making the README file a documentation thing, I just need to know which ones are valid? <jcastro> README, README.md and ... ? <bac> abentley, benji: i have changed my plans to work tomorrow so i'll be around to help with the demo <abentley> bac: Cool. <bac> abentley: changes per review have been made. diff is updating now <jcastro> hey sinzui <abentley> sinzui: I haven't figured out how to make juju-deployer export an environment. <sinzui> hi jcastro <jcastro> sinzui: is there a way we can generate a list of charms in the store that have READMEs that either are .rst or .markdown? <jcastro> I can go through and fix em all up * sinzui thinks <sinzui> jcastro, I can run a query on staging to do that. I can do that tomorrow. <jcastro> rock and roll <jcastro> sinzui: hey so, actually <jcastro> remember how we wanted to do a charm audit anyway? <sinzui> jcastro, I think you mean all charms owned by charmers <jcastro> maybe start seeding the queue with stuff like that? * sinzui copies scrollback to keep the task <jcastro> yeah so now that we're not smoked from OSCON maybe we should chat like tomorrow about how to seed the queue with audit tasks, etc? <sinzui> abentley, :( * sinzui tries to remember what he did <hatch> bcsaller: kickin around? <bcsaller> hatch: yeah <hatch> return view.createServiceInspector(service, {databinding: {interval: 0}}); <hatch> what does the interval effect? <bcsaller> we delay the updateDOM unless interval is 0 so its needed to test sync style <bcsaller> otherwise updateDOM will fire only after some period w/o calling, 150ms I think <sinzui> abentley, jitsu export > staging.jc.com.deployer <sinzui> abentley, https://pastebin.canonical.com/95362/ <hatch> ahh ok thanks <abentley> sinzui: thanks. <sinzui> abentley, so I think there might be version issues between what I did lat May and today's deployer <bac> abentley: what does a deployer file branch look like? does it just have a single .yaml or .cfg file in it? special naming? <gary_poster> thanks jcastro. <abentley> bac: Yes, it's a single file named "bundles.yaml". <bac> thanks abentley <abentley> sinzui: Yes, there has been skew. In current configs, there is an outer dict of bundles, and services is a dict, not a list. <sinzui> yeah, services is what looked wrong <abentley> sinzui: Also, relations looks wrong. <abentley> bac: Have you run "make lint"? Some of the indentation looks like it would be rejected. <abentley> bac: r=me aside from that. <hatch> rick_h: do you happen to still be around? <rick_h> hatch: kinda, booking a flight for the wife but EOD. I know your branch needs a look. I'll try to peek here in the next 20ish <hatch> thanks, it's proposing now <hatch> issues are fixed and I added ghost-inspector tests and the outline of what is to be followed once this lands <BradCrittenden> thanks abentley for the re-review. it is lintfree. <hatch> I also moved the ghost inspector test card onto the board under me <hatch> so I'll be on it right after this lands <benji> gary_poster: QA looks good; I'm doing a gui upgrade (from 0.8.0 or 0.8.1) now to QA my change specificially, but I think we'll be in the clear <gary_poster> great thanks benji! <hatch> rick_h: updated <hatch> gary_poster: this will be 0.8.2 right? <gary_poster> hatch, I guess so, yeah <hatch> save 0.9 for the inspector :) <hatch> OR should 0.10 be the inspector <gary_poster> :-) <hatch> oooOOo <gary_poster> lol <hatch> it's so much work that we jumped 2 spots <gary_poster> heh <gary_poster> I'm trying out lp:~gary/juju-gui/hackreleasefiles now <benji> gary_poster: QA looks good (no style or sprite issues) <benji> I'll do the merge in the morning (deployments near EOD being a bad idea) <hatch> are Friday morning deployments better than Thursday night? <hatch> debate! :P <benji> Yes. Debate over. <benji> Tuesday morning deployments being the holy grail. After all, who wants to create problems on a Monday. <hatch> true true <bac> sinzui: do you have a deployer file for deploying jujucharms? i hear you do. <sinzui> bac. I do. <bac> sinzui: would it be compelling for an IoM demo? if so, can you share it with me? <sinzui> bac, the file is from IS and I think it is the old format though <bac> sinzui: ok. wiki.yaml from the deployer configs looks serviceable <gary_poster> benji, ok thank you. <gary_poster> it appears building a branch now requires that g++ be available <gary_poster> so the charm is broekn for that use case atm afaict <rick_h> hatch: I've got to head to swim class in a minute. I don't have time to go back over the branch, sorry. Please rope someone else in to help get it in for huw <gary_poster> hey hatch, seen this node error before <gary_poster> http://pastebin.ubuntu.com/5937801/ <rick_h> as temping as code review on the lake beach might seem <hatch> rick_h: haha ok <hatch> gary_poster: looking <hatch> gary_poster: what version of node are you running? <gary_poster> hatch this is on the charm. 0.8.23 <hatch> ok one sec lemme check out node-sass <gary_poster> hatch fwiw that came from bin/generateTemplates <hatch> engines: { node: '>=0.10.0' }, <gary_poster> hatch, ah :-( <gary_poster> hatch I have that on raring but in charm... <gary_poster> linda89@example.com... <gary_poster> yup https://launchpad.net/~juju-gui-charmers/+archive/stable <gary_poster> 0.8.23-1chl1~precise1 <hatch> we should really try to upgrade node again <hatch> do we have time? <gary_poster> pfft, not before Friday morning :-P <hatch> what's odd is that I run the most recent 'stable' node on my desktop/laptop and can deploy just fine <hatch> s/deploy/buil <hatch> d <hatch> maybe the error we ran into has been resolved <hatch> of course the easiest thing to do would be to comment out node-sass <hatch> :) <gary_poster> hatch, that's what I was thinking. :-/ are we using it for anything? <hatch> looking <hatch> nope <hatch> it was a setup branch for the following sass changes <gary_poster> right <hatch> so in lib/templates.js you can comment out the require('node-sass') <gary_poster> hatch, could you tell me the least invasive way to disable it? I need to go help with dinner and will investigate afterwards <gary_poster> oh <gary_poster> :-) thanks <hatch> and one more <hatch> remove the node-sass line from the package.json <hatch> then you'll need to remove the shrinkrap file and regenerate it <hatch> which is simply `npm shrinkwrap` <gary_poster> hatch shrinkwrap not available in my local npm :-/ <gary_poster> must run will be back iab <hatch> jujugui anyone around able to do areview https://codereview.appspot.com/12205043/ <bcsaller> sure <hatch> thanks <hatch> bcsaller: the tests are coming up right after this lands, card is already in active coding :) just FYI <Makyo> Heading down to the hotel, back to work after check-in. <hatch> bcsaller: lol "scary scoping, and it get worse." <huwshimi> Morning <hatch> morning huwshimi <gary_poster> morning <gary_poster> huwshimi, hatch, bcsaller, call in 1 in guichat <hatch> huwshimi: I'll probably be hangin around cleaning up some stuff and reading blogs so ping me if ya run into any issues <huwshimi> hatch: Thanks. <hatch> oh huwshimi also if you're working on the inspector be sure to pull in trunk as I did a bunch of css stuff today <hatch> must.....close....chrome....tabs * gary_poster restarts hoping that chrome will be ok again... <gary_poster> back soon #juju-gui 2013-08-02 <huwshimi> gary_poster: Are you around? <gary_poster> huwshimi, unfortunately :-P <gary_poster> not for your sake, for the sake of staring at my branch :-) <huwshimi> :) <gary_poster> hey hatch, if you are around could you give https://codereview.appspot.com/12306043 a once over? I'm going to ask Francesco to review, land, qa and release the gui his tomorrow morning. then I'll ask benji and curtis to coordinate testing the charm upgrade and the GUI upgrade. <gary_poster> email sent <gary_poster> I'm outta here. Bye all. I'll check email occasionally <hatch> gary_poster|away: sorry I was out - I'll give it a review now. cya! <rick_h> frankban: seen the emails. If there's anything I can help with please let me know. <frankban> rick_h: thank you. I just landed a branch that should fix the service menu bug. I am going to QA now for the release, more QA eyes can help <rick_h> frankban: rgr, will pull it down. <frankban> rick_h: everything seems to work here, except for a bug also present in the current release: destroying a service from the service detail view does not work <rick_h> frankban: hmm, works here. That's the popup menu when you click on a service? <rick_h> frankban: ah, I see, when you click on it in details. My bad <frankban> rick_h: no, double click a service, and then click the destroy button, yes <rick_h> yea, the "are you sure" dialog pops up and the immediately closes <frankban> rick_h: exactly, I don't think this is a release blocker <rick_h> ok, I'll file a bug for the moment on that then. Looking into the reason right now <frankban> rick_h: cool, please ping me if you think there is a really quick solution for the problem <rick_h> frankban: yea, it's showing as -hidden so something in the code is running a .hide(). I'm not familiar with the detail view. Will go with a bug for now if it's not a blocker. <frankban> rick_h: I assume it's not a blocker b/c it's not a new bug <rick_h> ah, interesting. I'd agree then. And there's a workaround to destroy from the service icon <rick_h> frankban: one line fix <frankban> rick_h: great! <rick_h> frankban: http://paste.mitechie.com/show/986/ <rick_h> frankban: can you apply please? My trunk is a little messed up due to an accidental commit to trunk and I need to clean it up <frankban> rick_h: sure, thank you <frankban> rick_h: charmbrowser QA seems great to me, could you please confirm? <rick_h> frankban: yes, I've not been able to break it. +1 <frankban> rick_h: do you have time to write a quick changelog for this release, so that I can put that in the changes.yaml file? if not, no worries. <rick_h> frankban: sec. /me looks <rick_h> frankban: should just be able to go through the releasable cards right? <frankban> rick_h: yes, or here: http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/changes <rick_h> frankban: k, working on it <frankban> rick_h: thanks <rick_h> frankban: http://paste.mitechie.com/show/987/ I think works going at it a little quickly. Rest of the cards are charmworld or not really 'changelog' items <frankban> rick_h: nice, thanks! <benji> frankban: how goes the release? <frankban> benji: QA is done. Now starting the release process. I am also running the CI tests, just in case. <benji> cool <bac> benji: are you going to work on the iom demo today? i've created cards and reference the google doc. <benji> bac: I have some availability, but my main priority is upgrading the charm. I should have some time but I don't know for how long. <benji> I'll help any way I can. <bac> benji: ok, i didn't know how far you'd gotten on the charm <benji> it is ready to go; I'm waiting on the release now <benji> well, my changes are ready to merge, that's what I'm doing now * bac loves the yaml. deployer example config had one line missing an indentation space and it went nuts. <benji> yeah, significant whitespace will never catch on <bac> hey, that's different! :) <bac> benji: and the py interpreter gives a better error message than 'expected key missing' <benji> there is that; I guess every good idea can be done badly <frankban> guihelp: CI tests fail during the charm installation :-/ (make distfile): http://pastebin.ubuntu.com/5939960/ <frankban> guihelp: I assume there is an error in deploying the charm using a branch as juju-gui-source? Should we consider this a release blocker? <teknico> frankban: uhm, no idea <benji> frankban: I am not aware of that bug (but I haven't tried it recently either) <adeuring> abentley: could you have a look at this mp? https://code.launchpad.net/~adeuring/charmworld/1206158-dl-count-by-week-half-year/+merge/178265 <abentley> adeuring: sure. <abentley> adeuring: r=me. <frankban> benji: I am trying to dupe using juju-core. I'll also check if this is a regression introduced after the last stable release. If so, I don't think we should go on, otherwise, I'll proceed with the release. Sounds good? <rick_h> frankban: hmm, I just did a fresh checkout/build and didn't hit that. <frankban> rick_h: yeah. Build works locally here too. What nodejs version are you using? <rick_h> frankban: 0.10.8 <benji> frankban: sounds good; note that I merged my changes to juju-gui-charmers trunk within the last hour so it is possible that I caused any problems with those changes (but I don't see how) <rick_h> benji: gary_poster's branch yesterday updated a npm file with a bunch of 'mechanical' looking changes <rick_h> I wonder if anything in there wasn't good <adeuring> abentley: thanks <frankban> benji: CI uses cs:~juju-gui/precise/juju-gui . That's a different charm, right? <abentley> bac, benji: Can we do a hangout on bundles? <benji> frankban: I don't know exactly how it works, but my understanding is that the juju-gui-charmers trunk is the source for the official gui charm. My understanding is that within 15-20 minutes of landing to trunk the new charm should be in force <rick_h> frankban: looking at https://codereview.appspot.com/12306043/patch/1/1004 some of the grunt items were version updated? contextify was updated from 0.1.5 to 0.1.6 <bac> abentley: sure <benji> abentley: I'm consumed with release things at the moment <frankban> rick_h: I have v0.10.5 locally. The charm (precise) installs v0.8.23. Perhaps this is relevant? <rick_h> frankban: ouch! <rick_h> frankban: yea, that's not good if it's that far behind. <frankban> yeah, I guessed so :-/ <rick_h> doesn't hacking still require going through a nodejs ppa? <rick_h> I would have expected the charm to also pull the sudo add-apt-repository ppa:chris-lea/node.js ppa <rick_h> ? <rick_h> as it's what we dev against <rick_h> sinzui: around? did IS change/frown on this? <sinzui> rick_h, that wont work <abentley> rick_h: IS generally want to use only things in the main archive or the precise-cat archive (or whatever series is appropriate). <rick_h> frankban: I'm going to guess we've got bigger issues then. I'm not sure how we released before tbh with a 0.8 nodejs <sinzui> rick_h, frankban. I think all packages need to be installed in "cat" which is mad available via the exec.d hack <frankban> rick_h: this can be a very old regression <sinzui> we need an rt to place a package in cat. <sinzui> PS there is 1 webops today. He has 2.5h before EOD. I hope to monopolise him to move charmworld's mongodb <frankban> rick_h: I believe the charm takes npm from https://launchpad.net/~juju-gui-charmers/+archive/stable <rick_h> ugh, friday release fail <frankban> s/npm/nodejs/ <rick_h> frankban: oh hmm, and that's an old release from that ppa it appears. <rick_h> frankban: so yea, I've no idea how this works I guess :/ We're running 2 large versions ahead in dev, just updated the revisions of some deps, and things went boom on production. <sinzui> frankban, rick_h, webops make fat charms. they don't deploy the ones we give them. The can update their scripts to pull a branch of need dep, then add it to the charm. <rick_h> sinzui: well at this point I'm confused. If we've been running an old version for a known reason for a while then I don't want to suggest updating it <rick_h> I'm guessing we're on 0.8 for a reason then? However, it seems devs are all on 0.10 <hatch> yes <rick_h> I know hatch has tinkered with nodejs versions so we'll bug him <rick_h> ...starting now <hatch> lol <frankban> sinzui, rick_h: I also believe webops deploy from releases. This bug only affects deployment using branches (e.g. juju-gui-source=lp:..). node/npm are only required to create releases from branches. <sinzui> frankban, correct <rick_h> frankban: ah, that's what you mean by 'old regression' then? Maybe deployment from branches has had issues for a while but only now seeing? <hatch> reading backlog <antdillon> rick_h, My branch is lp:~ya-bo-ng/juju-gui/typography-charm-details <frankban> rick_h: exactly, especially considering the functional test in the charm uses a fake branch <hatch> frankban: is g++ installed? <sinzui> rick_h, the webops script retrieves the tarball from lp and places it in the charm, <rick_h> frankban: k, then I guess it sounds like it's a non-blocker if we can get a release build? <rick_h> antdillon: thanks, I'll create a card on the board for it and try to get some eyeballs on it after we get teh release issues worked through . <frankban> rick_h: yes, that's what I am checking with juju-core. Even like that, I am nervous making a release without being able to run the CI tests (and they are broken in canonistack for quite a while) <antdillon> rick_h, Awesome thank you! <rick_h> frankban: yes, agreed there <frankban> rick_h: g++? is that a new requirement for the charm? <frankban> sorry, hatch ^^^ <hatch> frankban: yes <hatch> I'm not sure why though <hatch> I just know that gary had an issue attempting to deploy when it wasn't installed <frankban> http://nooooooooooooooo.com/ <rick_h> lol <rick_h> npm dep requiring c-speedups? w..t..f <frankban> there is no mention of g++ in the charm sources, nor in our ppa (https://launchpad.net/~juju-gui-charmers/+archive/stable) <hatch> can't we just add apt-get install g++ ? <hatch> to see if that fixes it? <frankban> I suppose we can * rick_h runs and gets more coffee... <rick_h> I can't look <hatch> hmm I think this shrinkwrap is busted <hatch> it's changed a ton of versions <hatch> on trunk I can no longer run make <hatch> make: *** No rule to make target `app/assets/javascripts/d3.v2.js', needed by `build-shared/juju-ui/assets/modules.js'. Stop. <hatch> d3.v2 was removed.... <bac> hatch: make clean <frankban> hatch: we switched to d3 v3 <hatch> yeah... I did a fresh checkout <hatch> hoping that fixes it <hatch> yeah must have had something hanging around <hatch> frankban: is it attempting to build now with g++? * benji reboots <bac> sinzui: staging.jujucharms.com is broken when trying to view a specific charm <bac> sinzui: can i get login access to staging? <frankban> hatch: right now I am trying to understand what revision introduced this regression. rick_h: this is not an old bug, juju set -e go juju-gui juju-gui-source=lp:juju-gui:897 worked well <sinzui> bac, sure. It is just a special nova file to source <rick_h> frankban: I'd assume it was gary's branch that changed the shinkwrap.json? <bac> sinzui: i noticed staging was dead after i pushed my bundle branch. sadly i didn't check it before so i don't know if that is the culprit <sinzui> bac. mongo is angry <sinzui> OperationFailure: !loc.isNull() <frankban> rick_h: I am testing revision 917. then I will go with 918, which is Gary's branches I merged this morning. <adeuring> abentley: seems that the mongodb on staging is badly broken. Try to access any charm deital page... <adeuring> File "/home/webops_deploy/charmworld/local/lib/python2.7/site-packages/pymongo/mongo_client.py", line 789, in __check_response_to_last_error <adeuring> raise OperationFailure(details["err"]) <adeuring> OperationFailure: !loc.isNull() <rick_h> frankban: rgr <frankban> "Friday, never hesitate..." <abentley> adeuring: looking. <rick_h> frankban: I thought it was "Friday, never again"? <rick_h> oh well <abentley> sinzui: adeuring says staging mongodb is badly broken. I am investigating. <sinzui> abentley, well that is bad, because I switched it last night <abentley> sinzui: Right. <sinzui> and production switched 10 minutes ago <abentley> sinzui: it has a relation error. <frankban> rick_h: 917 fails with the same error. That's not Gary's branch * sinzui not see that <sinzui> ah, yes I do see that * rick_h goes to look at 917 * rick_h looks at hatch <bac> abentley: not sure if you saw my message, but this seems to have happened after i pushed a bundle branch to launchpad. <bac> abentley: trying to ingest locally i get http://paste.ubuntu.com/5940134/ <teknico> ha-ha, hatch broke the world ;-) <rick_h> frankban: ok, so something between 897 and 917? <frankban> rick_h: yes, trying to re-run the config-changed hook after installing g++ <abentley> bac: Weren't we going to test locally before pushing? <rick_h> frankban: can you try 915? I wonder if the scss stuff which broke some things is still there <teknico> (sorry hatch, just teasing you :-) ) <rick_h> frankban: I wonder if there's more deps than just the scss package still in the npm file that won't work. <adeuring> sinzui: well, managae.jujucharms.com does not seem to be affected: http://manage.jujucharms.com/charms/precise/apache2 works,m while http://staging.jujucharms.com/charms/precise/apache2 fails <bac> abentley: we talked about testing the deployer file against the deployer locally, which i did, but not about ingesting a local file. once it was pushed on LP staging found it. <sinzui> adeuring, agreed. the staging errors do not appear until 5 hours ago. We have seen this happen 3 weeks ago * sinzui off to present <abentley> bac: I thought getting a working deployer file was my responsibility. <bac> abentley: if the staging errors happened 5 hours ago then it isn't related <hatch> frankban: let me know if adding g++ fixes <abentley> sinzui: I believe the error is due to a stale charm-- it's running scripts/worker, which was supplanted by ingest-queued. <bac> abentley: afaik, we never assigned tasks until this morning when i made kanban cards. i sent a message here about it. <sinzui> abentley, oh dear. <sinzui> orangesquad: per https://docs.google.com/a/canonical.com/document/d/1AoMhTdrominYLBS8iHbZLW_Ji2OH3mNhUzoHjetnD9w/edit , you can see I ran /srv/deploymgr/charmworld restart <sinzui> ^ I left a copy of all the commands run <frankban> hatch: sure. rick_h: I'll try 915 later. Anyway, the real bug here is that our devenvs and our production env are really different <rick_h> frankban: +1, I'll add a discuss card I guess. <hatch> rick_h: the reason for the shrinkwrap updates is because those modules specify loose deps so when shrinkwrap was re-run it updated those loose versioned deps <frankban> rick_h: yes, please, thanks <rick_h> hatch: yea, gotcha. just trying to find something that 'changed' recenly and that's hitting close to home <rick_h> only other recent npm change I can think of is the scss work <hatch> well node-gyp requires gcc and g++ on OSX so I'm going to assume that it's also missing on 12.04 <hatch> and for some reason it's exposed itself now... <rick_h> so what needs node-gyp <rick_h> yea, node-gyp is a native build tool, so something wants to build a native package compiling on the target. Why do we need that now all of a sudden? <hatch> one theory is that it included a bin in linda89@example.com but removed in 0.1.6 <hatch> but that's all I got <hatch> :) <abentley> bac: I have concerns that we may not be adequately filtering out bundles for API 2 that I wanted to discuss before pushing a bundle. <bac> abentley: shall i delete the branch? <hatch> rick_h: also the reason we are using node sass and not pysass is because the node stuff is automatically hooked up to our watch system <hatch> where the python stuff isn't <abentley> bac: if it's older than 15 minutes, it doesn't matter. <bac> abentley: let's talk when you get a chance <rick_h> grrr, I can't find anything that 'deps' on node-gyp. Just that it's installed globally and deps on npm <abentley> bac: sure. <rick_h> hatch: ok, yuea. It's in the contextify build <hatch> cool I was right <hatch> lol <hatch> my hypothesis has now been confirmed <frankban> benji, hatch, rick_h : installing g++ seems to fix the problem, I'll add the dependency in the charmers charm, then I'll merge the charmers charm into our juju-gui charm, and then I'll try CI again... * hatch waits for his interviews <hatch> frankban: sorry about my timezone, I could have told you that sooner ;) <benji> frankban: I'm glad you figured it out. Do be careful with the merge. It is my understanding that the charmers charm is old an disused. <abentley> sinzui: The charm is not stale; the "scripts/ingest" script is broken. <abentley> sinzui: Other methods of ingesting should work. <frankban> hatch: we encountered this problem right before you arrived. We spent the Friday morning fixing other things, so do not excuse yourself for being in Canada <hatch> lol <rick_h> hatch: ok, so that's the d3 update <rick_h> hatch: d3 requires jsom which requires contextify <rick_h> frankban: so it all comes down to our d3 upgrade which was recent and probably broke it <frankban> rick_h: yes, it seems so, double checking with CI <hatch> this is my biggest gripe with node/npm <rick_h> hatch: so that would explain why gary ran into the issue <hatch> packages are like the wild friggen west <hatch> where we're going - we don't NEEED stability <rick_h> hatch: well, you'd expect that to be in giant letters in a changelog or something for going from 2-3. That's a big req change <hatch> that's what I mean <hatch> authors update deps with no testing <hatch> then claim it works with every version of node by using the > <hatch> npm is awesome - but I think it needs less features to restrict people to do the right thing <hatch> sooooo many packages broke when 0.10 came out simply because they said they worked in >=0.8.x <rick_h> everyone fights it though. Even python/pypi just recently stopped serving beta/alpha packages out as the most recent package by default. <rick_h> hah, yea when you know that anything > 0.8 would be an api break. It's the point of using big version numbers <hatch> right <hatch> so many people in the community release things using 0.x forever <hatch> things never hit 1.0 release <hatch> I think it's so they don't have to provide a stable product lol <rick_h> meh, just ignore the 0. 0.7 to 0.8 to 0.10 == breaks <frankban> benji: charms updated (fix added to charmers, and then merged charmers into juju-gui) <hatch> awesome <hatch> rick_h: rumor has it 0.12 will be 1.0 so we can hope :) <rick_h> hatch: fine, then 1.0 to 1.1 will break :P <benji> frankban: great! let me know when the GUI release is done <frankban> benji: I'll let you know IF the release will be done <hatch> rick_h: nope it's a 1.0 release, no api breaking changes allowed! <hatch> frankban: lol <hatch> be optomistic :) <benji> heh, I guess that will work too <hatch> optimistic even <hatch> I really need to get an irc client with spell check <rick_h> jujugui looking for a second person to help review/qa antdillon's changes https://codereview.appspot.com/12343044 <benji> rick_h: I'll take a look <rick_h> thanks benji <antdillon> benji, rick_h Thank you <abentley> sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/ingest-uses-ingest-queued/+merge/178310 ? <hatch> what's going on with the typography.less file? <hatch> the type class name has no relation to the contents within it <benji> rick_h, antdillon: I don't see a diff, only "error: old chunk mismatch" <abentley> bac: Let's chat. <rick_h> benji: hmm, working for me :/ <antdillon> benji, Working for me <benji> hmm <sinzui> abentley, r=me <antdillon> benji, This not working? https://codereview.appspot.com/12343044/patch/1/1005 <benji> rick_h, antdillon: apparently only the side-by-side diffs are broken; the stright-up diffs are fine; I'll look at those <rick_h> benji: ah, reitveld fail <benji> apparently <hatch> rick_h: frankban on my tasklist is to attempt to update our packages and node to be up to date next week (re your card in discuss) <rick_h> hatch: yea, but the larger issue is more the diff in dev vs production <rick_h> we should have hit this issue when d3 was upgraded, not a week later during a deploy attempt <hatch> oh well prod will then need to be updated as it'll fall over hard :) <rick_h> hatch: and it sounds like this g++ issue was hit, but not brought up. <frankban> hatch: cool, thanks <hatch> somehow I ended up working on two branches at once <bac> abentley: ok, can you set up a hangout? i need to move rooms. <abentley> bac: https://plus.google.com/hangouts/_/b3e9170262ba4b41f761dee440dcbb9ac111cf3d?hl=en-GB <rick_h> antdillon: landing your branch. It won't be in the release today, but will be on comingsoon later today. <frankban> guihelp: http://pastebin.ubuntu.com/5940316/ I presume this only means that the unit tests in ie are particularly slow... Please confirm my impression <frankban> rick_h: please don't land GUI branches <rick_h> frankban: :/ sorry. Figured it was -r locked. It just completed <frankban> rick_h: no worries. Does antdillon change need to be QA'd? <rick_h> frankban: as to the test run, yea it says they passed, there's the skipped. Not sure why it said it can't complete. <antdillon> rick_h, Cool thanks <rick_h> frankban: no, it was qa'd as part of review. Small css font changes to the browser <frankban> rick_h, antdillon: so it will be included in the release. guihelp: please don't land GUI branches <hatch> frankban: yes we have a number of unit tests which are skipped - they shouldn't be causing it to be incomplete though <abentley> bac: The URL structure is http://manage.jujucharms.com/api/3/bundle/~sinzui/mysql-5/tiny as described here: https://docs.google.com/a/canonical.com/document/d/1H1PH0q9Mr8pSvTmRnEgptrlC-OQZK7i-Le-1SzpJG5Y/edit <frankban> hatch: that can be a problem in CI tests, but it does not block the release. unit tests passed in firefox <hatch> ok great <hatch> I have huw's branch to land so let me know when it's ok :) <abentley> sinzui: r325 and later should not be deployed to production. <sinzui> abentley, understood. Since webops are off in 1h and I am away next week. I think we have little opportunity to shoot ourselves in the foot <abentley> sinzui: Tarmac is no longer setting the revno of charmworld after landing. The value is currently -1. Suspect it's related to the lcy02 changes. diogo isn't around. <benji> call today? Maybe it is at 11 since we'll not be doing a retrospective since Gary is out. <hatch> benji: I was thinking at 10 <hatch> in 1h <hatch> just the standup <hatch> the retro was yesterday <hatch> :) <benji> cool, 11 it is ;P <hatch> haha <sinzui> damn it abentley. I swear that lazy service goes on holiday every time Diogo takes off work <sinzui> abentley, surely tarmac needs it ssh config changed <abentley> sinzui: Yes, I expect that's the problem. <hatch> rick_h: do you use vim in multiple terminal panels (using tmux or the like) or use some vim pane manager? <rick_h> hatch: I use a tiling window manager + vim <rick_h> tmux and such is just gravy and kept seperate <rick_h> hatch: vim comes with 'pane managers' called splits. http://lococast.net/archives/111 <rick_h> and buffers really <jcastro> we do charm schools with both vim and tmux splits <hatch> right now I work in tmux splits but each window is it's own terminal so I always forget to add my ssh key or osmething to one <hatch> which just irritates me heh <hatch> so that's why I was wondering :) <rick_h> hatch: use an ssh-agent <rick_h> hatch: then you init your ssh key on boot and never worry about it again <hatch> there is some wakoness to osx > ubuntu sshing <hatch> I have to run `exec ssh-agent bash` every time <hatch> http://fromanegg.com/post/45733384142/nfs-between-ubuntu-vm-and-osx-host <rick_h> https://help.github.com/articles/working-with-ssh-key-passphrases says that on OSX they can be saved in the keychain <hatch> it's not the passphrase <hatch> it's that the env variables for ssh-agent don't exist <hatch> I haven't spent the time to track that
{'channel': 'juju-gui', 'month': 8}