[00:11] <Makyo> Whew, got it.  Man, ingest is a long path!
[00:12] <rick_h_> Makyo: :)
[09:10] <frankban> hi dimitern: so, IIUC, rsyslog-gnutls is now required to be installed in the local machine to bootstrap a local environment, right?
[09:11] <dimitern> frankban, hey, that's right
[09:11] <frankban> dimitern: and this will be a requirement for 1.18
[09:13] <dimitern> frankban, yes, but it seems juju-local doesn't list rsyslog-gnutls as a dependency
[09:13] <frankban> dimitern: asking because, if that's the case, we'll need to update quickstart as well.
[09:14] <dimitern> frankban, isn't quickstart about installing juju-local?
[09:15] <frankban> dimitern: quickstart installs the juju stable PPA, and then apt get installs juju-core, lxc and mongodb-server
[09:16] <dimitern> frankban, from source?
[09:16] <frankban> dimitern: apt-get install
[09:16] <dimitern> frankban, ah, sorry - from the ppa
[09:17] <dimitern> frankban, ok, so does it install juju-local package?
[09:17] <frankban> dimitern: no
[09:17] <dimitern> frankban, it should
[09:17] <frankban> dimitern: I guess juju-local is a meta-package for  juju-core, lxc and mongodb-server, correct?
[09:17] <dimitern> frankban, http://paste.ubuntu.com/7037530/
[09:18] <frankban> dimitern: cool, and you'll add rsyslog-gnutls I suppose
[09:18] <dimitern> frankban, I pinged jamespage about it
[09:20] <frankban> dimitern: so effectively installing juju-local means a complete installation, also supporting cloud providers
[09:20] <dimitern> frankban, it should be enough
[09:22] <frankban> dimitern: I'll investigate why we decided to install single packages instead of juju-local. If there is no valid reason, I'll change quickstart to just install juju-local from the PPA.
[09:22] <dimitern> frankban, tyvm
[09:23] <frankban> dimitern: thank you!
[09:30]  * hazmat totally missed were quickstart went to using urwid
[09:30] <hazmat> whe
[09:30] <hazmat> when
[09:31] <hazmat> frankban, there's a change in jujuclient 0.17.3 that's worth noting.. occassionally juju core will disconnect all api clients
[09:32] <hazmat> for watches specifically, i added a default parameterized behavior that will auto reconnect them
[09:34] <frankban> hazmat: interesting, auto_reconnect=True
[09:35] <frankban> hazmat: IIRC there was a similar bug some weeks ago, is this different?
[09:36] <hazmat> frankban, its the same bug.. roger had re-worked timeouts in the api server which is why it had got marked closed last time.. 
[09:36] <hazmat> frankban, but another manifestation of the same err, is that juju api-server goes awol occassionally
[09:37] <hazmat> something about a failure around mongodb socket, and then it disconnects all clients
[09:37] <hazmat> core agents auto reconnect  and handle
[09:37] <frankban> hazmat: ack, so this will be fixed in 1.18 I suppose
[09:37] <hazmat> frankban, unclear.. 
[09:38] <frankban> :-/
[09:38] <frankban> hazmat: are you planning an update for the jujuclient packages in the juju stable ppa? if so, we'll need to also update quickstart
[09:39] <frankban> hazmat: I am also thinking about the jujuclient tgz in the gui charm, perhaps we need to use the last release there too
[09:43] <frankban> hazmat: moreover, a mega-watcher random disconnection on 1.18 would also be a big problem for javascript clients (e.g. the GUI)
[09:43] <frankban> rogpeppe: ^^^
[09:45] <rogpeppe> frankban: i'm planning to look at that today
[09:46] <rogpeppe> frankban: i haven't yet managed to reproduce the problem yet though
[09:46] <hazmat> frankban, i had it pushed to trusty
[09:46] <hazmat> frankban, i haven't really touched the stable ppa..
[09:46]  * hazmat wonders if he can bribe someone to update deployer and client in there
[09:46] <frankban> rogpeppe: cool, thanks
[09:47] <hazmat> rogpeppe, i've gotten about a dozen people reporting in the last two weeks.. i think canonistack environments help to reproduce ;-)
[09:49] <rogpeppe> hazmat: i guess i will try to repro inside canonistack then
[09:50] <frankban> hazmat: could you please ping us on PPA update? unrelated: are you still living on the wrong timezone?
[09:51] <frankban> hazmat: re urwid, yeah, we use that for the environment management CLI
[09:52] <frankban> hazmat: the only downside is that it's not easy to make it work on windows, so maybe we'll need another solution when porting quickstart there
[09:52] <rogpeppe> hazmat: from the bug report (lp#1284183) it's not entirely clear how platform specific the repro script is
[09:52] <_mup_> Bug #1284183: jujuclient.EnvError: <Env Error - Details:  {   u'Error': u'watcher was stopped', u'RequestId': 9, u'Response': {   }} <api> <status> <juju-core:Triaged> <https://launchpad.net/bugs/1284183>
[09:53] <hazmat> frankban, toddler
[09:53] <hazmat> frankban, if you want to push it yourself your welcome to.. your pushing quickstart there?
[09:54]  * frankban thinks about pyside
[09:54] <hazmat> frankban, over pyqt?
[09:54] <frankban> yeah
[09:54] <frankban> hazmat: toddler?
[09:55] <hazmat> frankban, baby not sleeping well
[09:55] <frankban> hazmat: OIC
[09:57] <hazmat> frankban, yeah.. never been clear to me pyside was going to keep up.. its already well behind on qt 5 support afaics
[09:57] <hazmat> frankban, the only reason i've seen people choose pyside is licensing..
[09:59] <frankban> hazmat: interesting, I did not look at that ecosystem for a while
[10:01] <frankban> hazmat: so https://code.launchpad.net/~ahasenack/+archive/python-jujuclient and https://code.launchpad.net/~ahasenack/+archive/juju-deployer-daily , right?
[10:05] <frankban> hazmat: I'll take care of copying binaries over to the juju stable ppa. I plan to do that on my next quickstart slot (next week probably, maybe earlier).
[10:06] <hazmat> frankban, awesome thanks.. i think the distro packaging is different, it fetches from pypi
[10:09] <frankban> hazmat: yeah I think we have the same situation with quickstart, where trusty uses pypi and our PPA builds use a launchpad recipe
[12:06] <rick_h_> yea, they've packaged the deps up from the pypi
[12:07] <frankban> rick_h_: when you have time, could we please have a call?
[12:11] <rick_h_> frankban: sure thing
[12:12] <rick_h_> frankban: https://plus.google.com/hangouts/_/CONVERSATION/UgxGu-UJzXYihe-SGLV4AaABAQ?hl=en&hscid=1394021535421286643&hpe=11omarnn9ff7sl&hpn=Francesco%20Banconi&hisdn=Francesco%20Banconi&hnc=0&hs=35
[12:38] <frankban> rogpeppe: in the near future we might want to add the following fields to the mega-watcher MachineInfo: Life, Series, ContainerType, Jobs SupportedContainers, Constraints, ParentId and maybe also Adresses. do you see any problems with that path?
[12:42] <rogpeppe> frankban:  mostly seems fine
[12:43] <rogpeppe> frankban: ContainerType and ParentId can be inferred from the machine id
[12:44] <bac> frankban: i need a charm review if you have a moment: https://codereview.appspot.com/71230043
[12:44] <frankban> rogpeppe: yeah, that's what we do now, and we can keep doing it
[12:44] <rogpeppe> frankban: machine Constraints are an implementation detail and should not be exposwed
[12:44] <frankban> rogpeppe: so, should we use HardwareCharacteristics?
[12:44] <rogpeppe> frankban: SupportedContainers may not always be set (but if it is, it is valid)
[12:44] <rogpeppe> frankban: yes
[12:46] <frankban> rogpeppe: cool, so,  what about: Life, Series, HardwareCharacteristics, SupportedContainers, SupportedContainersKnown, Jobs, Addresses
[12:46] <frankban> bac: sure
[13:06] <jcsackett> bac: i forgot to ping you yesterday after putting the test up. it's now up at https://code.launchpad.net/~jcsackett/charmworld/bad-average/+merge/209272
[13:06] <bac> jcsackett: cool
[13:06]  * bac looks
[13:09] <frankban> bac: done
[13:09] <bac> jcsackett: nice, thanks.  approved.
[13:09] <bac> frankban: thanks
[13:09] <jcsackett> bac: thanks!
[13:14] <benji> has anyone seen errors like this when doing a "make devel"?
[13:14] <benji> npm ERR! Error: ENOENT, open '/home/benji/work/juju-gui/github/node_modules/node-spritesheet/node_modules/q-fs/test/partial.js
[13:15] <frankban> benji: npm -v && nodejs -v
[13:15] <rick_h_> benji: can you paste the whole block there? I've seen ENOENT stuff before. 
[13:15] <frankban> ??
[13:15] <benji> 1.4.3
[13:15] <benji> v0.10.26
[13:15] <frankban> uhm... same here
[13:16] <rick_h_> benji: you've got the sys deps, imagemagick ?
[13:16] <benji> rick_h_: I did what HACKING said, other than that I have no idea
[13:16] <benji> thanks for checking frankban 
[13:16] <rick_h_> benji: ok, it's in hacking but asking to verify
[13:17] <rick_h_> the only thing around spriting would be base node issues and missing imagemagick library used to do the spriting
[13:17] <rick_h_> that I can think of off the top of my head with the one liner there
[13:25] <frankban> rick_h_: cards created
[13:25] <rick_h_> frankban: thanks
[13:26] <frankban> rick_h_: what's the goal of "Update machine/unit models with extra data now available"?
[13:26] <rick_h_> frankban: well, there was existing data and then there's the ability to pull data via new calls? Or maybe there's not. 
[13:26] <rick_h_> frankban: so the first card was about fleshing out our models with existing data, and then updating them with what we need from the new addmachine calls
[13:27] <rick_h_> frankban: so does addmachine give us access to anything we didn't have? Or maybe it sounds like it's all the in delta and we've got that covered now?
[13:28] <frankban> rick_h_: so, addMachines returns something like {
[13:28] <frankban>             err: 'only defined if a global error occurred'
[13:28] <frankban>             machines: [
[13:28] <frankban>               {name: '1', err: 'a machine error occurred'},
[13:28] <frankban>               {name: '2/lxc/1', err: null}
[13:28] <frankban>               // One entry for each machine/container added.
[13:28] <frankban>             ]
[13:28] <frankban>           }
[13:28] <frankban> rick_h_: so I don;t see any new info for us
[13:28] <rick_h_> frankban: ok, then we can ditch that card
[13:29] <rick_h_> frankban: gone, thanks for checking up on it. 
[13:29] <frankban> rick_h_: cool. Fortunately we can parse the parent/container relationships from the machine names
[13:30] <rick_h_> benji: any luck?
[13:31] <rick_h_> benji: want to look at doing a screenshare/call to try to see what's up? 
[13:31] <frankban> rick_h_: so right now we have name, agent_state, agent_state_info from the watcher + parentId parsing the name. I guess it is everything we need for machine view 1.0
[13:32] <rick_h_> frankban: and we have the machine spec info ?
[13:33]  * bac afk...bbiab
[13:33] <frankban> rick_h_: machine spec is used to deploy units to a specific machine: this is now enabled, and IIRC units have an attribute for the machine name they belongs to
[13:34] <rick_h_> frankban: so we need the machine constraint metadata. 
[13:34] <rick_h_> frankban: sharing the machine view pdf with you, should have an email
[13:35] <frankban> rick_h_: ok, I'll take a look after lunch
[13:39] <benji> rick_h_: here are the first few lines of "make devel" and the first (of many, many) errors I get: http://paste.ubuntu.com/7038531/
[13:41] <rick_h_> benji: check the owner of ~/tmp and ~/.npm and make sure it's you. 
[13:41] <rick_h_> benji: and if you try a make clean-all and make devel again does it hit the same issue?
[13:45] <benji> rick_h_: yep, me in both cases
[13:47] <benji> if I remove those two directories and run "make devel" again, I get a different first error:
[13:47] <benji> npm ERR! EEXIST, mkdir '/home/benji/work/juju-gui/github/node_modules/yui'
[13:48] <rick_h_> a make clean-all should remove all of those directories and start again
[13:48] <rick_h_> clear the cache that is and local copies
[13:48] <benji> I don't think clean-all touches ~/.npm
[13:49] <rick_h_> but node_modules isn't in ~/.npm
[13:49] <rick_h_> /home/benji/work/juju-gui/github/node_modules/yui
[13:50] <rogpeppe> 1284183
[13:50] <rogpeppe> frankban: seems reasonable, although i'm not entirely sure we need SupportedContainersKnown
[13:50] <rogpeppe> frankban: s/reasonable/good/
[13:53] <rick_h_> benji: it looks from this traceback that you had an npm install get part way and fail one time and it doesn't like to re-run. So make clean-all should remove the existing stuff and restart.
[13:54] <rick_h_> benji: the thing to see if the failing traceback on a clean first-run of the npm install if it fails again
[13:54] <benji> rick_h_: I had the same thought and am running several sequentially now
[13:55] <rick_h_> maybe you just hit a network snafu on a pass and got unlucky?
[13:55] <benji> I don't think so.  It has never failed consistenly like this before.
[13:56] <benji> I suspect either some setup setup that we forgot to document or a recent change that breaks new installs but works on old installs and we haven't noticed because we use git
[13:57] <rick_h_> benji: ok so I'm confused. Are you getting any successful runs after a make clean-all? You mentioned running sequentially now?
[13:57] <frankban> rogpeppe: fo you mean SupportedContainers can be null when they're not determined and a map when they are?
[13:57] <rick_h_> not sure how using git effects the npm install?
[13:57] <benji> I have not had a single successful run since re-installing my OS.
[13:58] <rick_h_> benji: the only recent change was the nodejs upgrade. Several of us have gone through the hacking doc on new installs of trusty. I'll setup a fresh lxc to see if I can dupe
[13:59] <benji> since we install locally, and any amount of "make cleaning" will never be enough, there can be a hysteresis that causes existing builds to continue to work while new ones break
[14:00] <rick_h_> benji: right, so an lxc test is a good sanity check. But I know I've done three trusty fresh installs and gotten it running
[14:01] <frankban> rick_h_: we already have support for adding machines/containers with a set of constraints. We currently don't receive HardwareCharacteristics from the meta-watcher. To be clear, we can set constraints for new machines but we cannot show hardware for existing machines. Looking at the slides, the current situation seems ok for now.
[14:01] <rick_h_> frankban: ok, good to know. There was some design around putting machine hardware characteristics in the UX but if that got pulled out even better
[14:02]  * rick_h_ migrates to coffee shop to run from cleaners. back in a few min
[14:06] <frankban> rick_h_: an idea could be to replace the 6-weighted card we removed with two 3-weighted cards to 1) update core MachineInfo and 2) reflect new info in our machine models. But I am ok if, as you mentioned, you want this work to be done later
[14:07] <rogpeppe> frankban: yes
[14:07] <rogpeppe> frankban: or an array
[14:07] <frankban> rogpeppe: +1 then, yeah I mean, a sequence in general
[14:08] <frankban> rogpeppe: oh, yes I used map I intended slice
[14:13] <rick_h_> frankban: yea, let's stick in in the on deck for now. We've added the existing new stuff in maint. 
[14:14] <rick_h_> frankban: and if we get time we can pull them from on deck to work on this 2wk cycle if we can
[14:15] <frankban> rick_h_: ok sounds good
[14:36] <hatch> benji hey what error are you getting when trying to build the gui?
[14:36] <benji> hatch: here's what I get from a fresh build http://paste.ubuntu.com/7038531/
[14:37] <rick_h_> benji: http://paste.ubuntu.com/7038757/ works from a clean machine to running gui
[14:37] <rick_h_> benji: I created an empty trusty lxc, set that as install-gui.sh and run it and end up with a gui running
[14:37] <rick_h_> benji: this is without any bind to my home directory or anything
[14:37] <benji> rick_h_: I'll try that as a script
[14:38] <rick_h_> benji: I'm running it a second time to verify on another clean lxc 
[14:38] <benji> I don't think this machine is dirty, I've only installed about 10 packages (other than GUI things)
[14:38] <rick_h_> benji: understood, just trying to duplicate your issues on as clean as I can get. Don't even have the ppa install command 
[14:38] <hatch> benji does npm have access to /usr/lib ?
[14:39] <hatch> does it work if you run it with sudo?
[14:39] <benji> hatch: I doubt it; it's not being run as root
[14:40] <benji> I'm not about to run it as root
[14:41] <rick_h_> benji: ok, verified that script on a new empty lxc brings up the gui in one shot
[14:41] <rick_h_> benji: just watch the user:group in the chown 
[14:41] <benji> rick_h_: thanks; running it now
[14:41] <rick_h_> and <3 google wifi at starbucks. 6Mb/s downloads ftw 
[14:41] <hatch> benji npm needs access to ~/.npm and /usr/local/lib/node_modules
[14:41] <benji> rick_h_: chown?  where did those come from?
[14:42] <rick_h_> benji: that's because when you first run npm install -g (global) it creates those two directories for your user owned by root
[14:42] <benji> hatch: the gui's npm install doesn't install to /usr/local/lib/node_modules
[14:42] <rick_h_> benji: so to be able to use them for the make devel local deps, you have to chown them to writ ethem
[14:42] <rick_h_> benji: this is why I was asking about if ~/.npm and ~/tmp was owned by you or root. 
[14:42] <benji> rick_h_: is that in HACKING?
[14:42] <rick_h_> benji: yes
[14:42] <rick_h_> benji: well the chown isn't
[14:42] <hatch> benji ok then ~/tmp needs access too then
[14:43] <hatch> I had these in my hacking doc updates but SOMEBODY thought that it was too harsh :P
[14:43] <rick_h_> benji: that's why it was the first thing I asked about. If the directories already existed you're fine, only on a fresh intsall does it bring that up
[14:43] <rick_h_> hatch: no, you had it where root owned everything
[14:44] <rick_h_> or no, you chowned /usr/lib 
[14:44] <rick_h_> to your local user 
[14:44] <hatch> yeah
[14:44] <hatch> :)
[14:44] <rick_h_> which was not going to fly
[14:44] <rick_h_> :P
[14:45] <hatch> it is pretty stupid that the node/npm install doesn't fix the folder permissions for it to actually work
[14:45] <rick_h_> well it's stupid that a -g install touches your home directory at all
[14:45] <rick_h_> if I'm doing something globally nothing per user should be involved
[14:45] <rick_h_> there's a system /tmp for that
[14:46] <rick_h_> javascript jabber just put out a podcast with the npm guys. I'm tempted to listen to see if my rage at them will go down at all
[14:46] <rick_h_> or just go higher
[14:47] <hatch> higher
[14:47] <hatch> definitely higher
[14:47] <rick_h_> that's a safe bet
[14:47] <hatch> lol
[15:01] <rick_h_> hatch: any reason for me not to use Y.isInstanceOf to check for a charm vs a bundle model?
[15:01]  * hatch needs more backstory
[15:02] <rick_h_> hatch: I want to do X if charm model and Y if bundle model. I don't see a single instance of Y.Assert.isInstanceOf in our code and it makes me think I'm missing something
[15:03] <hatch> assert.equal(x instanceof Y.juju.models.Bundle, true)
[15:03] <hatch> like that?
[15:03] <rick_h_> no, it's for real code not tests
[15:03] <rick_h_> I guess I can just check object.NAME
[15:03] <luca__> rick_h_: hatch I'm working on the UX for upgrading a charm in the inspector in regards to this bug: https://bugs.launchpad.net/juju-gui/+bug/1252586 if we remove it from the list of quick action notifications and maybe put a "Change version" link in the header which takes you to a dedicated space within the inspector that would be ok?
[15:03] <_mup_> Bug #1252586: Upgrade service is given too much real-estate <juju-gui:Triaged by lucapaulina> <https://launchpad.net/bugs/1252586>
[15:04] <hatch> if (x instance of Y.juju.....) ?
[15:04] <hatch> luca__ well imho the header might be the wrong place for it
[15:04] <hatch> it's a very limited use action
[15:05] <luca__> hatch: ok, sooooo where do you think it should live? Maybe in the configuration section?
[15:05] <hatch> so I'd even go as far as to put it on the configuration panel
[15:05] <hatch> yeah
[15:05] <luca__> hatch: thats the only other place I could think of
[15:05] <luca__> I don't really want to have a new pane for it
[15:06] <hatch> no I agree
[15:06] <hatch> just taking a look one sec
[15:06] <luca__> should we alert users to new upgrades?
[15:06] <hatch> I'm thinking it should go in the configuration pane, maybe above the 'Import configuration file' button?
[15:07] <hatch> hmm
[15:07] <luca__> so populate a quick action notification for new upgrades, which disappears once they've looked at it?
[15:07] <rick_h_> luca__: hatch what about just making it something that either pops out a panel or that clears the inspector space and takes it over ?
[15:07] <hatch> this would look like the 'service is being destroyed' notifications? 
[15:07] <hatch> ^ luca__ 
[15:08] <hatch> rick_h_ I was thinking expands to push the settings down
[15:08] <luca__> hatch: no, a black notification like errors or running
[15:08] <rick_h_> hatch: luca__ I'm not sure a fan in the config because changing the version will change the config available
[15:08] <rick_h_> hatch: it's kind of two different things there
[15:08] <luca__> rick_h_: interesting
[15:08] <hatch> quick hangout?
[15:08] <luca__> sure
[15:08] <hatch> loading.....
[15:09] <hatch> https://plus.google.com/hangouts/_/7ecpjqdgivcbmgclulgpeuekf8?hl=en
[15:23] <luca__> hatch: rick_h_ cheers!
[15:23] <hatch> :)
[15:24] <hatch> rick_h_ ok back to your object compare issue....
[15:25] <rick_h_> hatch: ignore me, I've got something that works for now
[15:25] <hatch> hah ok cool
[15:50] <Makyo> jujugui call in 10
[15:53] <rick_h_> jujugui small review please https://github.com/juju/juju-gui/pull/160
[15:53] <jcastro> rick_h_, can you ping me when the gui can show recommended bundles?
[15:53] <rick_h_> jcastro: that's the branch ^^
[15:53] <jcastro> jawesome
[15:53] <rick_h_> jcastro: will do, should be on comingsoon in a couple of hours. Won't be on jujucharms until next release
[15:54] <hatch> jujugui deploying local charms is broken on comingsoon until I land my current branch....sowwy
[15:54] <rick_h_> hatch: doh
[15:54]  * hatch blames the qa'ers
[15:54] <hatch> :P
[15:54] <rick_h_> ruh roh
[15:54] <rick_h_> what's wrong?
[15:55] <hatch> it's trying to create an instance which doesn't exist
[15:55] <hatch> simple one line fix
[15:59] <Makyo> jujugui call in 1
[16:00] <hatch> benji ping
[16:00] <benji> hatch: pong
[16:00] <hatch> call now
[16:00] <benji> ah
[16:07] <benji> I waved goodbye to everyone on the hangout and then realized that I don't have a camera plugged in.
[16:07] <rick_h_> lol
[16:08] <rick_h_> we all waved back, mustbe magic
[16:10] <hatch> haha
[16:17] <hatch> rick_h_ yeah they are talking about the $ now
[16:17] <rick_h_> hatch: heh good to know
[16:21] <hatch> basically nodejitsu was running a single huge couchdb for the entire npm db
[16:21] <hatch> ....
[16:21] <hatch> that's why it kept crashing
[16:27] <rick_h_> yea
[16:27] <hatch> so the $ was so nodejitsu could afford to keep npm running
[16:27] <hatch> it had nothing to do with npm inc
[16:28] <hatch> I'm just surprised noone said 'hey maybe running a single huge instance is a bad idea'
[16:28] <rick_h_> yea, but I can't see $300K going to a couple month's bandwidth bill
[16:29] <hatch> well no, I'm pretty sure they raised that expecting to fund the year
[16:29] <hatch> then npm peaced out
[16:29] <hatch> lol
[16:29] <hatch> they didn't cover that, but that's my guess
[16:30] <rick_h_> exactly, it sure seems like they're sitting aorund with $250K sitting in their back pockets
[16:30] <rick_h_> :/
[16:30] <hatch> nodejitsu is, yeah....
[16:30] <hatch> not entirely sure what they should do with that
[16:30] <hatch> I mean, the project they were hoping to support just kinda left 
[16:30] <hatch> lol
[16:31] <hatch> and I didn't know this....but issac wrote npm before he started at joyent as a personal project
[16:33] <hatch> rick_h_ your CI failed - in case you missed that
[16:33] <rick_h_> right
[16:33] <rick_h_> hatch: I got it, updated branch is running
[16:33] <rick_h_> make lint fml
[16:33] <hatch> lol
[16:33] <hatch> gota get into the habit of pre-lint and testing :P
[16:33] <hatch> I am thinking of putting it as my pre-push hook :)
[16:38] <hatch> *sigh* fixing tests
[16:38] <hatch> fixing tests is demoralizing lol
[16:39] <hatch> "awesome this works so great.......*32 test failures*.....son of a...."
[16:51] <rick_h_> hatch: looks like it's the theme of the day https://twitter.com/git_clone_makyo/status/441254662885212160
[16:51] <rick_h_> lol
[16:52] <hatch> haha damnit
[16:52] <Makyo> Sigh~
[16:54] <Makyo> I hate to ruin its excitement.  It just can't help itself!  EEEEEE
[16:57] <hatch> haha
[16:59] <Makyo> Got the comment that it looks like a Roguelike.  "It is very dark. You are likely to be eaten by an out-of-date mock."
[16:59] <rick_h_> hah
[16:59] <hatch> hahaha
[17:12] <benji> jujugui: I have a very small documentation branch that would have prevented me wasting a day getting the GUI set up: https://github.com/juju/juju-gui/pull/161
[17:12] <hatch> looking
[17:12] <rick_h_> benji: done
[17:13] <benji> thanks
[17:13] <benji> hatch: you missed your chance
[17:14] <hatch> 32 failures > 3 failures > 16 failures > 5 failures AHHHHHHHHH
[17:15] <rick_h_> come on, you know that the failure count in the tests is never worth a dran
[17:15] <rick_h_> darn
[17:15] <rick_h_> once a test fails all kinds of things fail for no good reason
[17:15] <rick_h_> one test at a time
[17:16] <hatch> lol
[17:17] <hatch> aswing-and-a-miss
[17:18] <hatch> I have found that running suites in the browser is way faster than running them in the console
[17:18] <Makyo> Yes.
[17:19] <Makyo> Don't even need to worry about .skip then
[17:19] <Makyo> Er... .only
[17:23] <hatch> 2!
[17:23] <Makyo> 102 -> 97  here.  So many mocks to fix.
[17:27] <rick_h_> Makyo: what changed so bad? the charm url?
[17:28] <Makyo> rick_h_, We get the service info back from that method in the JSON, but previously, we ignored everything except errors in that object.
[17:32] <Makyo> rick_h_, So half of those are "expecting 3 values to unpack, only got two" and half are missing arguments in mocked methods expecting to receive that info.
[17:38] <rick_h_> Makyo: ah, gotcha
[17:41] <hatch> oh I love yui bugs
[17:41] <rick_h_> what did you break now? :P
[17:42] <hatch> for whatever reason, a view is being destroyed but it's leaving it's container in the dom
[17:42] <rick_h_> that's the way it works
[17:42] <rick_h_> isn't it? if you give it a container?
[17:43] <hatch> nope http://yuilibrary.com/yui/docs/api/files/app_js_view.js.html#l318
[17:43] <hatch> ohhh
[17:43] <rick_h_> http://yuilibrary.com/yui/docs/api/files/app_js_view.js.html#l160 you have to pass the option to delete
[17:43] <hatch> waitasecond
[17:43] <hatch> yeah
[17:43] <hatch> what the farquad 
[17:43] <rick_h_> if (options && (options.remove || options['delete'])) {
[17:44] <rick_h_> so it's the way it's supposed to work :)
[17:44] <hatch> why the heck would you ever want to leave the container in the dom?
[17:44] <rick_h_> because you often render a View into an existing container
[17:44] <rick_h_> or swap views in that container
[17:44] <rick_h_> taking the container out would be a pita
[17:44] <hatch> but a view renders it's own container if one isn't provided
[17:44] <hatch> so it should know that and remove it
[17:44] <rick_h_> it's not a widget with a boundingBox to keep 
[17:45] <rick_h_> k, so maybe it should destroy ones it creates, but it doesn't
[17:45] <rick_h_> and hasn't worked that way
[17:46] <hatch> crazy, maybe I've always passed in a container so I never noticed it
[17:46] <rick_h_> yea, not sure. 
[17:46] <rick_h_> learn something new every day
[17:46] <rick_h_> but yea, we often in tests do a makeCotnainer and then destroy that container
[17:46] <rick_h_> so it tends to get cleaned up that route
[17:46] <rick_h_> and maybe didn't notice
[17:47] <hatch> yeah, well good thing we had this test :)
[17:47] <rick_h_> :) 
[17:47]  * rick_h_ pats the test on the head...good test, good
[17:47] <hatch> haha
[17:49] <benji> frankban: would "Support ToMachineSpec in fake backend  ServiceDeploy and  AddServiceUnits calls" be a good card for me to take?
[17:50] <frankban> benji: sure, the arg is already in the real go env
[17:51] <rick_h_> benji: https://github.com/juju/juju-gui/pull/152 is the recent branch to the go env
[17:51] <rick_h_> oh, you reviewed it, heh
[17:52] <benji> :)
[17:53] <benji> frankban: I'm a little surprised it is marked as size 3.  Are there complications I'm not seeing?
[17:55] <rick_h_> benji: well, when we scored it we didn't know there was a 'crib this branch for how it's done' in the time allocated. And that score is time to get through review and land as well.
[17:55] <benji> ok
[17:57] <frankban> benji: as Rick said, and also I guess some time can be spent for some investigations on the real juju-core side. e.g. what happens if the specified machine/container does not exist in the env?
[17:57] <benji> makes sense
[18:00] <Makyo> 97 -> 7 :P
[18:02] <hatch> nice
[18:02] <hatch> I'm doing a final run now
[18:02] <hatch> planning on a few
[18:02] <hatch> lol
[18:03] <hatch> w000t 0
[18:26] <Makyo> Woo! OK (SKIP=1)
[18:26] <rick_h_> and there was much rejoincing
[18:26] <rick_h_> err joicing
[18:26] <rick_h_> or something
[18:32] <Makyo> Man, I can't hold both git and bzr in my head at the same time :(
[18:33] <rick_h_> heh, welcome to the rest of us :)
[18:33] <rick_h_> every day I do something backwards
[18:52] <hatch> hmm
[19:16] <Makyo> Did... did _mup_ just go out for coffee?
[19:19] <hatch> oo boy laggy
[19:19] <hatch> Makyo that was the NSA installing new logging software
[19:19] <hatch> lol
[19:19] <Makyo> Rewriting _mup_ in coffeescript, brb
[19:19] <hatch> lol
[19:20] <hatch> Makyo the other day I was reading a blog post that said "Atom plugins can be written in JavaScript" lol
[19:20] <hatch> so I am clearly not the only person haha
[19:20] <rick_h_> lol
[19:20] <Makyo> Pff :)
[19:23] <hatch> actually I saw a review on Atom which showed it and sublime side-by-side and Atom had a pretty big lag comparatively  - I hope that's not indicative of webkit based apps on the desktop 
[19:23] <Makyo> It seems okay to me.
[19:23] <Makyo> Granted I only briefly played around with it with the CS game thing.
[19:23] <hatch> yeah - I'm not sure one would notice if they aren't side by side
[19:24] <hatch> but it was probably 500ms difference
[19:24] <hatch> changing tabs 
[19:24] <Makyo> Which I mostly wrote in Vim because Vim had good literate CS support.
[19:26] <hatch> jujugui lf a review/qa on https://github.com/juju/juju-gui/pull/162 plz and thanks
[19:26] <hatch> rick_h_ ok on to reviewing your branch
[19:26] <rick_h_> hatch: ty
[19:31] <hatch> holy crud we need to index the bundle table
[19:31] <hatch> lol
[19:31] <hatch> wow that's slow
[19:32] <hatch> rick_h_ review done
[19:36] <hatch> anyone able to review my branch atm? 
[19:36] <hatch> I'm going to continue on with it so I'd like to try and catch any issues up front :)
[19:40] <rick_h_> hatch: can in a sec
[19:40] <hatch> cool thanks
[19:41] <hatch> I think someone is DOS'ing someone in my internets 
[19:41] <hatch> is so slow
[19:41] <rick_h_> suuuure, blame it on the DDOS
[19:48] <Makyo> On today's Not-The-0nion: I'm glad to hear that Macaulay Culkin is in a pizza-themed Velvet Underground cover band playing percussion and kazoo. http://thepizzaunderground.bandcamp.com/
[20:04] <hatch> lol wut
[20:05] <Makyo> That's 9 minutes of my life I'll never get back.
[20:05] <Makyo> Strange things happen when you leave people home alone.
[20:05] <hatch> rofl
[20:42] <rick_h_> Makyo: I know we talked about grabbing a inspector card, but if you could peek at that bug I mentioned yesterday next and walk me through that I'd appreciate it. 
[20:42] <rick_h_> after all this fun, but just to setup the next up circle
[20:43] <Makyo> rick_h_, Sure, though leave for vet in 15 or so.  If it's after EOD for you, I can probably get it done  if you want to hand it off.
[20:43] <rick_h_> hatch: how many views does this make?
[20:43] <rick_h_> Makyo: yea, I returned it to the ready to code yesterday to grab this one for the recommended issue
[20:43] <hatch> umm
[20:43] <hatch> I need more context
[20:44] <rick_h_> hatch: well there's two cards for "update viewlets to be views"
[20:44] <Makyo> rick_h_, okay.  That's the d3 error?
[20:44] <rick_h_> hatch: so curious if this is a good time to move the card or if we're not half way ther eyet?
[20:44] <rick_h_> Makyo: yep
[20:44] <rick_h_> damn, using my kenisis, the air keyboard, and my thinkpad keyboard I think I'm getting worse at typing on all three of them
[20:46] <hatch> rick_h_ oh I'm leaving it there until I finish my current branch
[20:46] <hatch> then I'll move it
[20:46] <hatch> we will be 1/2 way then
[20:46] <rick_h_> hatch: ok, put it in review then?
[20:46] <hatch> not yet
[20:47] <hatch> not till my new new branch lands
[20:47] <hatch> :)
[20:47] <rick_h_> hatch: or by 'current' you mean next?
[20:47] <hatch> yeah sorry
[20:48] <rick_h_> k cool
[20:49] <Makyo> Alright, vet now, shouldn't be long.
[20:49] <rick_h_> have fnu Makyo 
[20:54] <hatch> the microwave just turned on
[20:54] <hatch> and there goes my wifi
[20:54] <hatch> lol
[20:55] <rick_h_> hah
[20:56] <hatch> I think I'm going to go buy me a cable today too
[21:00] <rick_h_> I'm out all, night 
[21:00]  * rick_h_ runs away
[21:01] <hatch> cyaz
[22:23] <hatch> oh boy this databinding stuff really is complicated
[22:23] <hatch> maybe we should move to react
[22:51] <hatch> rick_h_ https://bugs.launchpad.net/juju-gui/+bug/1288450
[23:04] <hatch> 1000+ line diff and the only lint warning is that I forgot to doc a file
[23:04] <hatch> w000t
[23:04] <hatch> lol
[23:07] <rick_h_> hatch: k
[23:07] <hatch> that one should probably be critical?
[23:07] <hatch> make test-debug
[23:07] <hatch> bah
[23:08] <rick_h_> hatch: yea
[23:08] <hatch> well for the morning I'll have 16 test failures to fix
[23:09] <hatch> then the service config viewlet will be done
[23:09] <hatch> this one was a lot of work
[23:23] <Makyo> jujugui charmworld reviews/QA: https://codereview.appspot.com/71070051
[23:33] <Makyo> hatch, https://twitter.com/horse_js/status/441355172510314496
[23:33] <hatch> rofl
[23:35] <Makyo> The one problem I ran into that I really didn't like about CS was the optional parens were irregular if you were dealing with passing the result of a function call as an argument in another function call.
[23:35] <Makyo> but you could get around that with newlines.
[23:36] <Makyo> And it screwed with order of operations.
[23:44] <hatch> oh, that is a little wako