[10:35] <marcoceppi> hey guys
[10:35] <marcoceppi> quickstart, no --upload-tools flag?
[10:45] <frankban> marcoceppi: no, we don't have that option
[10:45] <marcoceppi> frankban: could you add it?
[10:46] <marcoceppi> frankban: quickstart doesn't work on maas because maas needs --upload-tools
[10:46] <frankban> marcoceppi: you can just run "juju bootstrap --upload-tools" and then quickstart will reuse the environment already bootstrapped. 
[10:46] <marcoceppi> frankban: well, we were doing quickstart -i :)
[10:46] <marcoceppi> which is so sexy
[10:47] <frankban> marcoceppi: FWIW quickstart -i can be used to run an existing environment. anyway, is this a maas bug?
[10:47] <marcoceppi> frankban: it's a juju-core/streams bug
[10:48] <marcoceppi> frankban: well, we run juju init, then quickstart -i to edit the default maas stuff
[10:48] <marcoceppi> makes the demo more impressive
[10:48] <frankban> marcoceppi: understood, could you please file a bug on quickstart, describing this use case?
[10:55] <marcoceppi> frankban: will do
[10:55] <frankban> marcoceppi: thanks
[11:49] <frankban> hazmat: morning, could you please review https://code.launchpad.net/~frankban/juju-deployer/improve-guiserver-feedback/+merge/203915 ?
[12:37] <BradCrittenden> morning frankban.  i landed my quickstart branch yesterday even though i was getting intermittent errors on charm deploy like https://pastebin.canonical.com/103823/ even with juju 1.17.1.  the admin-secret was correctly being used to authenticate so i assumed it was unrelated to my branch.  just a heads up in case i assumed wrong.
[12:43] <ahasenack> hi guys, is the juju-gui charm branch really this big?
[12:43] <ahasenack> 135336kB   221kB/s - Fetching revisions:Inserting stream:Estimate 3772/3247                                                                                             
[12:43] <ahasenack> bzr branch is still going
[12:44] <ahasenack> it finally finished, short of 152Mb
[12:45] <bac> ahasenack: development on juju-gui is now happening on github at https://github.com/juju/juju-gui
[12:46] <bac> ahasenack: the Launchpad page for the project needs to be updated to reflect that.
[12:46] <ahasenack> bac: what does that mean? lp:charms/precise/juju-gui is invalid?
[12:46] <bac> ahasenack: my apologies.  no the *charm* is still on launchpad.  the code for the app is on github.
[12:47] <bac> so lp:charms/precise/juju-gui is still correct
[12:47] <ahasenack> and huge
[12:47] <ahasenack> if I do juju deploy juju-gui it will fetch 150Mb?
[12:48] <ahasenack> that's the amount "bzr branch lp:charms/precise/juju-gui" said it downloaded
[12:48] <bac> ahasenack: the charm is big due to bundled dependencies but i'm surprised it is that big.
[12:48] <ahasenack> bac: can you try, on a fresh directory outside any bzr local repo? 
[12:49] <bac> ahasenack: if you use juju-quickstart to deploy the charm will not be downloaded to your local machine before deploying (unless you're using a local environment).
[12:49] <ahasenack> I'm not using juju quickstart
[12:49] <ahasenack> after branch,
[12:49] <ahasenack> $ du -hs juju-gui/
[12:49] <ahasenack> 78M	juju-gui/
[12:50] <frankban> ahasenack: that's the size of the branch, not the size of the single checkout. I believe most of space is for /bzr
[12:50] <bac> juju downloads the charm before pushing it to your provider.  if you were to use juju-quickstart the charm is deployed directy to your provider.
[12:50] <frankban> .bzr even
[12:50] <bac> s/directy/directly/
[12:50] <ahasenack> frankban: the du size is about half of what bzr said it downloaded, fwiw
[12:51] <ahasenack> if you use juju-deployer, it will branch the charm branch first, and then deploy locally. I don't know if there is a "light" branch that can be used
[12:52] <frankban> ahasenack: the charm includes the current juju-gui release, it is now ~4.6MB but used to be ~40MB. That's why over time the branch size increased a lot
[12:52] <rick_h_> ahasenack: because we package up releases of the gui into the charm along with deps so that it's offline installable it gets big
[12:52] <ahasenack> it got big because of the revisions
[12:52] <rick_h_> ahasenack: rgr
[12:52] <ahasenack> if you once had a 100Mb tarball in it, then remove it and add a 5Mb instead, the branch will still at least be 100Mb big
[12:52] <rick_h_> ahasenack: a shallow checkout shouldn't be that big
[12:52] <bac> juju-gui: juju-deployer should be doing a lightweight checkout not a branch
[12:53] <rick_h_> exactly
[12:53] <rick_h_> it's what we do with the gui itself when you specify a branch to use as the gui source. No need for revision history to deploy
[12:54] <ahasenack> bzr co --lightweight lp:charms/precise/juju-gui <-- this downloaded roughly 5Mb
[12:54] <rick_h_> ahasenack: that's the plan
[12:54] <ahasenack> maybe it should use bzr export
[12:54] <bac> bac@trusty64:/tmp$ bzr checkout --lightweight lp:charms/precise/juju-gui
[12:54] <bac> bac@trusty64:/tmp$ du -sh juju-gui
[12:54] <bac> 5.7M	juju-gui
[12:55] <bac> oops, didn't see you'd done the same
[12:56] <ahasenack> co --lightweight is still a bound branch
[12:57] <rick_h_> ahasenack: yea, just minus the history so it should be just fine for juju-deployer needs. 
[12:57] <ahasenack> rick_h_: ok, I'll ask hazmat
[12:57] <ahasenack> wither co --l or export even
[12:57] <ahasenack> either
[12:57] <frankban> bac: re: the error: never encountered, it does not seems related to your branch or to quickstart in general
[12:58] <frankban> bac: relatedly, could you please take a look at https://codereview.appspot.com/58680043 ? (quick branch)
[12:58] <rick_h_> ahasenack: I'll file it as a bug on the deployer
[13:00] <ahasenack> deployer has the --update option, so I think co --l is better than export
[13:00] <rick_h_> ahasenack: add notes/tweak https://bugs.launchpad.net/juju-deployer/+bug/1274494 please
[13:00] <_mup_> Bug #1274494: deployer does not do lightweight checkouts of charms <juju-deployer:New> <https://launchpad.net/bugs/1274494>
[13:01] <ahasenack> thanks
[13:01] <rick_h_> but yea, we've tried to optimize the gui charm a bit but it's got a big history as we weren't always so light weight. 
[13:02] <rick_h_> gary_poster: brought it up and brought down the size only recently
[13:02] <rick_h_> jujugui cool article on helpful ec2 tips/tricks. I like the billing monitoring bits https://launchbylunch.com/posts/2014/Jan/29/aws-tips/
[13:06] <bac> frankban: will do
[13:09] <bac> frankban: done
[13:10] <bac> rick_h_: any reason we didn't keep juju-gui on launchpad and do an import from github?
[13:13] <frankban> bac: thank you
[13:15] <rick_h_> bac: because I didn't think/now we could change it like that and what came up in discussion was noting a MOVE
[13:20] <bac> rick_h_: it may be, too, that vcs-imports from git are not reliable.  can't recall.
[13:20] <bac> rick_h_: but if someone unwittingly checks out from lp, they get 40MB for one file.  :)
[13:21] <rick_h_> bac: heh, tis true
[13:37] <benji> rick_h_: I need to pair with someone.  Let me know when you have time.
[13:38] <rick_h_> benji: rgr, on call atm but will ping when off
[13:39] <benji> rick_h_: thanks
[13:43] <bac> frankban: lightweight bzr checkouts directly from launchpad become unusable with your _vcs_branch prompt!
[13:44] <frankban> bac: uhm, I'll try it, maybe we have to revert to using bzr info
[13:45] <bac> frankban: in that scenario, i think using bzr anything will be a huge hit.
[13:46] <frankban> bac: ah! because it fetches info from lp
[13:46] <bac> yeah.  so just 'cd download-cache' causes the world to stop
[13:50]  * benji considers becoming an electrician
[14:00] <hatch> frankban do u have juju 1.17.1 installed? can you try and bootstrap local without sudo? It's throwing an error here
[14:02] <hatch> frankban thanks for the review btw 
[14:02] <frankban> hatch: I'll try ASAP
[14:04] <hatch> thanks
[14:04] <hatch> bac https://twitter.com/imlxgr/status/427916382748291073 lol
[14:05] <bac> ha.  but that's not me.  i'm carpel tunnel free (atm)
[14:05] <bac> well i have them, they aren't messed up
[14:05] <bac> atm
[14:05] <hatch> haha
[14:08] <rick_h_> benji: off the call
[14:09] <benji> rick_h_: I'm on one now. :)
[14:10] <rick_h_> benji: see you later :)
[14:10] <benji> k
[14:10] <hazmat> frankban, gui branch merged and deployer 0.3.1 released to pypi
[14:11] <frankban> hazmat: great thanks!
[14:30] <frankban> hatch: what error?
[14:36] <hatch> frankban that sudo is required
[14:36] <hatch> and then any attempts after wards fail with some odd error about connecting to a local ip 
[14:36] <hatch> I have to go and manually delete the folders to fix it
[14:39] <frankban> hatch: even if you changed the path to include $GOPATH/bin, quickstart invokes juju with its full path (i.e. /usr/bin/juju) so you are actually using 1.16. To test your branch I'd suggest to temporary change the cmd to just "juju". Now you must detsroy the environment using 1.16. Moreover (and I forgot to mention it in the review), I'd keep the 'sudo privileges required to bootstrap the environment' message also w
[14:39] <frankban> hen using 1.17, since sudo is still required, and the only difference is that it is invoked by core and not by quickstart
[14:40] <hatch> frankban I mean I was just using core, not quickstart
[14:41] <hatch> v 1.17.1 of core seems to require sudo for local environments
[14:41] <frankban> hatch: revno?
[14:42] <hatch> frankban no revno, installed from the repo
[14:42] <hatch> er
[14:42] <hatch> ppa
[14:43] <hatch> 1.17.1-precise-amd64
[14:43] <hatch>  /usr/bin/juju
[14:43] <frankban> hatch: I don't see it here: https://launchpad.net/~juju/+archive/stable
[14:44] <frankban> hatch: are you using trusty? are you sure juju is installed from the PPA and not from universe?
[14:44] <hatch> I'm on precise....
[14:44] <frankban> hatch:  apt-cache madison juju-core
[14:45] <hatch> https://gist.github.com/hatched/f10981633e833e0b3073
[14:48] <hatch> you're not seeing the same?
[14:52] <frankban> hatch: no... I think it's worth asking core devs about this. it seems 1.17 is no longer published in the stable ppa. in trunk I have 1.17.2 and it does not require sudo. 
[14:53] <hatch> ok so then I need to update quickstart then to test for the 'patch' 
[14:53] <hatch> because 1.17.1 definitely asks for sudo
[14:57] <frankban> hatch: I'd ask core devs if the release you have is reliable. If they consider 1.17 a development release we could in theory directly check for 1.18
[14:59] <bac> gary_poster: call in 2 minutes?
[15:00] <frankban> bac: I guess call in 30
[15:05] <bac> frankban: i meant our 1:1
[15:05] <bac> sorry for not being clear
[15:06] <frankban> bac: oh ok
[15:06] <gary_poster> bac replied on pm, but https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.b6tepoq090fnj4qfdg23a3okhg
[15:10] <hatch> frankban ok 1.17.2 is the first version to not require sudo
[15:10] <benji> out of context programmer quote of the day: "Sometimes a ball of mud is better than a tree." -- gary_poster 
[15:10] <gary_poster> lol :-)
[15:10] <benji> rick_h_: ping me when you have a few minutes
[15:10] <rick_h_> benji: ping
[15:11] <benji> rick_h_: I'll make a hangout
[15:11] <frankban> hatch: is 1.17 a development version? will it be released to the stable ppa?
[15:13] <hatch> frankban odd releases are not considered stable 
[15:13] <benji> rick_h_: https://plus.google.com/hangouts/_/7acpi97gmmj5u8id27kf6un30g?hl=en
[15:14] <frankban> hatch: so, as a consequence, I assume they are not published in the stable PPA. If so, I'd say, from our perspective, no sudo if version >= 1.18
[15:17] <hatch> I suppose that's reasonable, is there any negative side effects you can think of if someone uses sudo on 1.17.2+ ?
[15:17] <hatch> I can't think of any
[15:20] <frankban> hatch: not sure, however, quickstart always install juju-core from the PPA (or from the base repos, assuming a newer version is present). So, if we can ensure development versions never land on the PPA or on production, we are ok with 1.18 check
[15:23] <Makyo> jujugui call in 7ish.
[15:24] <hatch> ok sounds good
[15:27] <frankban> guihelp: I need one QA (there is not so much to review) for https://codereview.appspot.com/55230044 (charm). Anyone available?
[15:30] <Makyo> jujugui call now ish
[15:30] <gary_poster> oh thanks Makyo
[15:37] <bac> jujugui: roger now says the mongo error from juju is a different known problem
[16:26] <hatch> I think that a pure functional js application would be a pretty cool system
[16:27] <hatch> but...but....events
[16:31] <rick_h_> events are a means to an end that's all
[16:31] <rick_h_> we have them, but their use can be a disaster so it has to be guided
[16:32] <rick_h_> thanks gary_poster interesting points for me to think on now. /me wants to demo some inverse system of my current system
[16:32] <gary_poster> rick_h_: :-) cool.  thanks for pushing the layer idea.  I agree it needs to be addressed, and needs a champion
[16:36] <Makyo> FYI James is home sick, so will be taking care of food/walking dogs/etc. 
[16:37] <hatch> I downloaded and started playing EVE lastnight
[16:37] <hatch> we'll see if I enjoy it after the 14 day trial
[16:43] <rick_h_> Makyo: review done will qa. Let me know if you disagree with my notes or are confused by them
[16:44] <hatch> Makyo starting review
[16:44]  * hatch still thinks it looks like fish on a pole
[16:45]  * hatch is still thinking about a purely functional js app
[17:00] <dimitern> hatch, gary_poster, I'm proposing a fix for bug 1273464 at the moment
[17:00] <_mup_> Bug #1273464: putcharm api fails for compressed charm contents wrapped in a folder <api> <charms> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1273464>
[17:01] <hatch> dimitern thanks :)
[17:01] <gary_poster> fantastic thanks dimitern
[17:01] <hatch> it's kind of an odd duck but it solves a lot of issues cross platform :)
[17:01] <dimitern> it even works with arbitrary nested dirs, as long as all the metadata, config and revision files are in the same dir
[17:02] <hatch> awesome!
[17:02] <dimitern> https://codereview.appspot.com/54680045 there it is, if you want to take a look
[17:03] <hatch> dimitern FYI I'm to report back to the GUI team the status on the new api work so can you please include me in the discussions as they come up
[17:03] <dimitern> hatch, sure, I'll remember - we don't have immediate talks scheduled though
[17:03] <hatch> even better :P
[17:06] <hatch> Makyo does Object.create() do a deep clone of the prototype you pass into it? I can't remember
[17:13] <hatch> Makyo ok I thought I was right but I just wanted to be sure http://jsbin.com/efeSAxUq/1/
[17:16] <Makyo> hatch, that's existing style  ¯\_(ツ)_/¯
[17:21] <hatch> Makyo ok review complete - mind checking the comments over and letting me know if you want to chat about anything
[17:28] <Makyo> hatch, we had a lot of talk this morning about consistency; I hope my responses are in line with that.  In short, I don't want to maintain two things that act in exactly the same way for different models in totally different ways; nor do I want scope-creep for this task.
[17:28] <hatch> :+1:
[17:28] <Makyo> ty
[17:28] <hatch> (that doesn't quite have the same effect without the emoticon) :)
[17:29] <Makyo> Will create a slack card for investigating factories, though. Kind of an abuse of constructors for no real benefit, seems like.
[17:29] <hatch> yeah, it may have been left over from a refactor or something
[17:30] <Makyo> Exactly. BoundingBox works the same way, but there's been work on it since it was created.
[17:48] <hatch> rick_h_ lol this._cleanups.pop()(); go javascript
[17:48] <rick_h_> hatch: no sense taking up memory creating a var we don't need :)
[17:49] <hatch> haha 
[17:49] <rick_h_> especially in hidden back end util code
[17:53] <hatch> rick_h_ is there a deepEquals in python's assert? I can't seem to find the docs on the assert stuff
[17:53] <hatch> I'm probably looking in the wrong places
[17:53] <rick_h_> hatch: what are the two bits of data?
[17:53] <hatch> here is what the util method is returning return int(major), int(minor), patch
[17:54] <rick_h_> ok, so you're returning a tuple. You should be able to just assertEqual that
[17:55] <hatch> self.assertEqual('foo', 'bar', 'baz', return_value)
[17:55] <hatch> like so?
[17:55] <rick_h_> no, self.assertEqual((foo, bar, baz), return_value)
[17:55] <rick_h_> with quotes
[17:55] <hatch> ok cool
[17:55] <hatch> where are those docs anyways?
[17:55] <hatch> the assert ones
[17:55] <rick_h_> http://docs.python.org/2/library/unittest.html
[17:55] <rick_h_> see 
[17:55] <rick_h_> http://docs.python.org/2/library/unittest.html#assert-methods
[17:55] <rick_h_> in  particular
[17:56] <hatch> ok yep I was looking in the wrong place :)
[17:56] <hatch> thanks
[17:56]  * rick_h_ is so glad he got the 32gb N10
[17:56] <rick_h_> remind me I need to get the 64 if they ever update it
[17:56] <rick_h_> offline movies on planes ftw
[17:57] <hatch> yeah 16H on the same plane will suuuuuck
[17:57] <hatch> haha
[17:57] <hatch> were you able to get business class?
[17:57] <rick_h_> no :/
[17:58] <hatch> boo urns
[17:58] <hatch> probably serious $ for the upgrade
[18:02]  * gary_poster been on calls straight since five hours ago :-)
[18:02] <gary_poster> Time for lunch
[18:02] <rick_h_> gary_poster: :/ lunch + motrin!
[18:02] <gary_poster> :-)
[18:23] <bac> hi hatch -- the work you're doing with quickstart and sudo, can you explain it briefly?
[18:24] <bac> is using sudo no longer required for bootstrapping a local env?
[18:25] <hatch> bac sort of
[18:25] <hatch> :) ...
[18:25] <hatch> so
[18:25] <hatch> in versions 1.17.1 and lower you will still require sudo for local deployments
[18:25] <bac> hatch: and in higher it disallows it?
[18:25] <hatch> anything higher, the not quite yet released 1.17.2,  and higher it is not required
[18:26] <bac> hatch: it seems juju-core trunk not only doesn't requires it but errors if you try to use sudo
[18:26] <hatch> so since 1.17 is a dev release I'm setting quickstart to not use it in 1.18 and higher
[18:26] <hatch> oh?
[18:26] <hatch> hmm that's unfortunate
[18:26] <hatch> what's the error?
[18:26] <bac> yeah
[18:26] <hatch> ok then I'll have to fix quickstart to target 1.17.1 and lower for sudo and not for anything else
[18:27] <bac> so i'm trying to do interop testing with quickstart and juju-core trunk and there is no way to launch locally with the current combo
[18:27] <hatch> man this is confusing hah
[18:27] <hatch> yeah sorry, once I finish this quickstart branch then it will work
[18:28] <hatch> I just have to finish the tests now, so once I finish my lunch I'll finish those up and you can test with this branch
[18:28] <bac> ok
[18:30] <bac> hatch: can't i just comment out the 'cmd.insert('sudo')' line?
[18:30] <hatch> I suppose you could
[18:30] <hatch> :)
[18:30] <bac> seems to workish
[18:31] <hatch> ish?
[18:31] <hatch> what does that break?
[18:31] <bac> well, it got past that point and is chewing along.  so far so good.
[18:32] <bac> workish means it is in the process of working.
[18:32] <hatch> gotcha :) ok running back to lunch, ping if you need
[19:01] <hatch> rick_h_ need review on your pr?
[19:02] <rick_h_> hatch: no, just self-reviewd it. Small and I waited to amke sure CI passed so should be good
[19:02] <hatch> you don't destroy the container :(
[19:02] <Makyo> Someone have 30sec free?
[19:02] <hatch> yup
[19:02] <rick_h_> hatch: that's the point, you can't the way the code works now
[19:02] <Makyo> hatch,  comment LGTM QA okay on https://codereview.appspot.com/55230044
[19:03] <Makyo> Still can't get rv to let me log in.
[19:03] <rick_h_> hatch: I gave it a special class and will update the bug that it needs some love
[19:03] <hatch> Makyo done
[19:03] <Makyo> hatch, thanks!
[19:04] <hatch> rick_h_ ohh the notifiers are left in the dom after each test 
[19:04] <hatch> I see
[19:04] <rick_h_> hatch: because the notifier has Anim code that comes in after a set timeout and expects to do things
[19:05] <hatch> yeah....we should fix that
[19:05] <rick_h_> hatch: if you pull the container the Anim dies an ugly death
[19:05] <hatch> :)
[19:05] <rick_h_> hatch: thus the bug :)
[19:05] <hatch> haha
[19:29] <hatch> rick_h_ what would cause  ```major, minor, patch = version_string.split('.', 2)``` to fail, in frankban's review he gave an example where it was involved in a try/except but I can't seem to get it to downright fail in the command line
[19:30] <hatch> the docs don't give any indication either
[19:30] <rick_h_> hatch: link to the review? The only thing I could see is if the version string wasn't 3 parts but two
[19:30] <rick_h_> or not a string, maybe None
[19:31] <hatch> well if it wasn't a string then ok
[19:31] <rick_h_> or didn't container a .?
[19:31] <hatch> but can a shell-out return non string values?
[19:31] <hatch> https://gist.github.com/hatched/8716939
[19:31] <hatch> rick_h_ there is the method with his suggested changes
[19:32] <rick_h_> hatch: so I'd make sure to note the format expected. "1.17.0-trusty-amd64" and then the only thing I'd watch out for is assuming three parts
[19:32] <rick_h_> will 2.0 be reported as 2.0.0
[19:32] <rick_h_> or 2.0?
[19:33] <rick_h_> or that you got no output, so if output was None
[19:33] <hatch> that would have failed on the split though
[19:33] <rick_h_> hatch: not sure tbh. 
[19:33] <rick_h_> hatch: right
[19:34] <hatch> ok so maybe he just suggested incorrectly
[19:34] <hatch> I'll put the try around the split instead
[19:34] <hatch> the first one that is
[19:34] <rick_h_> hatch: link to his note? maybe if I read what he said I can be more helpful?
[19:35] <hatch> https://code.launchpad.net/~hatch/juju-quickstart/no-more-sudo/+merge/203846/comments/476131 almost at the bottom
[19:36] <rick_h_> hatch: ok, so yea. It's fine the way it is. The try/except is good in case you get back something unexpected. 
[19:36] <rick_h_> hatch: so what was the original questoin? what could cause you to hit the exception?
[19:37] <hatch> https://gist.github.com/hatched/8716939 see the new.py is what I just changed it to
[19:37] <hatch> yeah I was trying to hit the exception for testing but coudln't without it failing before there
[19:37] <rick_h_> oh crap my pebble shipped...Tues :(
[19:37] <hatch> I think my new version is what he intended
[19:38] <rick_h_> hatch: what happens if the version string is 2.0
[19:38] <rick_h_> ?
[19:38] <hatch> then you get ['2', '0']
[19:38] <hatch> splits never return errors that I could find (or read on the docs)
[19:39] <rick_h_> http://paste.ubuntu.com/6845543/
[19:39] <rick_h_> hatch: ^
[19:39] <hatch> ohh unpacking is the issue
[19:39] <rick_h_> type python on the terminal and give it a try :)
[19:39] <hatch> yeah I have been, I didn't think the unpacking would be an issue
[19:39] <hatch> ok so...
[19:40] <hatch> https://gist.github.com/hatched/8716939
[19:40] <hatch> newnew.py
[19:40] <rick_h_> the first one is pretty safe
[19:40] <rick_h_> sure, works I think
[19:40] <hatch> because output could never be anything but a string?
[19:42] <rick_h_> I don't think so. but the call could fail
[19:43] <rick_h_> if you don't have juju installed or something
[19:43] <rick_h_> but I think that's promised at this point?
[19:43] <hatch> right and that's already caught earlier in the app
[19:43] <hatch> yeah
[19:43] <rick_h_> k
[19:43] <hatch> ok reverting to what he had
[19:43] <rick_h_> cool
[20:18] <hatch> the python test runner is irritating me
[20:18] <hatch> it's like sometimes it bails without throwing an error if another test fails sometimes
[20:20] <hatch> rick_h_ is there a .only equivalent in the python test suite?
[20:24] <hatch> bah figured it out
[20:33] <benji> I'm down to three test failures.
[20:37] <hatch> yay
[20:51] <bac> hey hatch, i was thinking the version of juju-core i hand-built called itself 1.17.2 ... but i wonder if it'll get bumped to 1.18 when released.  will impact the cut-off for your sudo work.  may want to touch bases with roger about it.
[20:51] <hatch> bac 1.17.2 will be released in the dev side of things
[20:51] <hatch> but the public releases will be 1.18.x
[20:51] <bac> for anyone following along, the mongo-on-fire error occurs with the 1.17.2 patch
[20:51] <hatch> the sudo stuff I have checks for below 1.17.2
[20:52] <bac> yeah, that'll work
[20:52] <hatch> https://code.launchpad.net/~hatch/juju-quickstart/no-more-sudo
[20:52] <hatch> here is the branch if you want to see my changes
[20:54] <bac> hatch: you've got conflicts...
[20:54] <benji> oh man, those three tests only fail on a second run (reload of the test page)
[20:55] <hatch> bac BLARG *grumble grumble grumble*
[21:00] <rick_h_> benji: check the url hash
[21:00] <rick_h_> benji: that's the card/issue Makyo brought up yesterday
[21:00] <rick_h_> and I'll hopefully take a peek at tomorow/during flight
[21:01] <rick_h_> benji: the test run has to start with a clean url (no hash) or it'll fail 
[21:02] <benji> rick_h_: yep, I realized that was the problem.  Given that you know too, I assume it is a pre-existing condition.
[21:02] <rick_h_> benji: yep, card in the slack task lane to look into it
[21:03] <benji> ok
[21:03] <benji> (I suggest that since it has cost me at least an hour of work it should be urgentified.)
[21:03] <rick_h_> benji: as I said, hoping to work on it in travel tomorrow
[21:04] <benji> cool
[21:06] <bac> hatch: i think your local_bootstrap_requires_sudo is broken for some values, e.g.  1.18.1 and 2.17.2
[21:14] <hatch> 2.17.2 works
[21:14] <hatch> 1.18.1 doesnt
[21:15] <hatch> I switched the wrong > :/
[21:15] <hatch> thanks for the catch bac
[21:16] <bac> ah, right, 2.17.1 didn't...
[22:02] <huwshimi> Morning
[22:11] <gary_poster> hey huwshimi.  talk to you soon
[22:12] <huwshimi> Sure!
[22:17] <mhall119> rick_h_: just wanted to say thanks for your juju help the other day, it seems the root cause of my problems was that staging wasn't using postgresql:db-admin when it should have
[22:39] <huwshimi> rick_h_, hatch: Do either of you happen to know if you can resize the Phontom viewport in a single test?
[22:40] <hatch> huwshimi I dont' know, I would also be pretty confident saying not the way our test structures are currently done
[22:40] <hatch> but you can fire a fake resize event, no?
[22:41] <hatch> if you like, you can push the code up and I can take a look
[22:41] <huwshimi> hatch: I need to test two things... when the viewport starts at 1024px and another when it gets resized below that.
[22:41] <huwshimi> hatch: I'll push it up
[22:43] <rick_h_> mhall119: coolio glad you got it working
[22:45] <rick_h_> huwshimi: I'd think it should be a selenium test to do that
[22:45] <rick_h_> huwshimi: hatch http://stackoverflow.com/questions/16664433/how-to-resize-current-browser-window-in-selenium-webdriver-with-java
[22:45] <rick_h_> huwshimi: /me isn't sure what you're working
[22:45] <hatch> rick_h_ can selenium resize the window?
[22:45] <rick_h_> hatch: see the linky 
[22:45] <hatch> oh cool
[22:46] <hatch> sorry my internet today has been bonkers
[22:46] <hatch> so much lag
[22:46] <rick_h_> hatch: it's using the java driver but should be available in all drivers
[22:46] <hatch> I'm probably being DOSd
[22:46] <rick_h_> I told you not to disagree with me. Too easy to take down those canadian interwebs :P
[22:46] <hatch> lol, I need the internet we have at the head office
[22:46] <hatch> 1GB/min lol
[22:48] <hatch> rick_h_ when I had that issue about string vs int you mentioned that it was something to do with ascii to unicode conversion....is there docs about this issue?
[22:50] <rick_h_> hatch: don't recall the issue but yea tons of unicode docs but it's a bit of a black pit. Block out some time. 
[22:50] <rick_h_> http://lucumr.pocoo.org/2013/7/2/the-updated-guide-to-unicode/ maybe
[22:50] <rick_h_> http://kunststube.net/encoding/ for generic unicode info 
[22:50] <hatch> oh haha, the issue was "17" >= 17 == False but "1" >= 1 == True 
[22:51] <rick_h_> oh, that's not unicode based stuff
[22:51] <hatch> yeah I know about unicode, I was more interested in the technical issues with this 
[22:51] <rick_h_> that's just  http://www.asciitable.com/
[22:52] <hatch> I'm not pickin up what you're puttin down
[22:52] <huwshimi> rick_h_, hatch: I've mocked out the tests for what I'm trying to achieve: https://github.com/huwshimi/juju-gui/commit/2225754cb0d26e50ffb6faae8f40b9bd98dbd2b8
[22:52] <rick_h_> so python objects have __eq__ methods (see http://www.rafekettler.com/magicmethods.html) and when you do str == int it uses those methods to compare the values
[22:53] <hatch> huwshimi yeah setting the size does not fire a resize event
[22:53] <hatch> huwshimi you may be able to do Y.one(Y.config.win).fire('windowresize')
[22:53] <hatch> or whichever resize event you're using
[22:54] <hatch> Y.one(Y.config.win).simulate('resize') might be the proper syntax
[22:54]  * hatch opens up the code
[22:55] <hatch> huwshimi look at test_d3_components.js:150
[22:55] <hatch> rick_h_ ahhh ok, see these are the things the language tutorials just seem to miss hah.
[22:56] <rick_h_> hatch: for int, __eq__ just checks they're the same integer value. however, you had a string. When you == a string and in it, it compares the int value of that string. Which is the character code for it. So you were getting "character code for "7" which is 55
[22:56] <hatch> gotcha, yeah that makes perfect sense once you know how it's working
[22:57] <rick_h_> hatch: rgr, so yea. Look at the acsii table and you'll see that 55 is the code for a 7 character
[22:57] <rick_h_> http://www.asciitable.com/
[22:57] <hatch> yeah
[22:57] <hatch> makes perfect sense
[22:57] <hatch> cool that you can define your own magic methods
[22:57] <huwshimi> hatch: If I use that can you set it to a particular size?
[22:58] <rick_h_> yea, so let's say you create a class "boats" and want to be able to say if boat1 > boat2, you can flesh out hte magic methods that describe how to compare boats (say by a tonnage attribute)
[22:58] <rick_h_> and make that actually work out just fine
[22:58] <hatch> huwshimi the second parameter to simulate is a custom options object. I've never used it but it reads like it 'should' work to supply a custom 'what happened' object
[22:58] <huwshimi> hatch: Additionally, I'm not sure if that helps me to set the initial size of the page without firing a resize
[22:59] <hatch> http://yuilibrary.com/yui/docs/api/classes/Node.html#method_simulate
[22:59] <hatch> rick_h_ yeah that's super cool
[22:59] <hatch> might get confusing if you lose context as to what a boat is
[22:59] <hatch> being loosely typed and all
[23:31] <rick_h_> huwshimi: gary_poster is the AU going down tonight?
[23:31] <huwshimi> rick_h_: Should be any minute now
[23:32] <rick_h_> huwshimi: k, joined but no one around so was curious
[23:32] <huwshimi> rick_h_: Oh, is there a regular url again?
[23:33] <rick_h_> huwshimi: there was a url on the calendar event so used that
[23:33] <huwshimi> I usually just get an invite
[23:33] <huwshimi> Ah right
[23:33] <rick_h_> oh, well let me know where to be when it's time
[23:36] <gary_poster> me here