[02:53] <rick_h_> wheee bug spam 
[02:53] <rick_h_> but with that I think I'm spent. party on 
[02:53] <rick_h_> huwshimi: though can you update your card? I thought I saw a pull request for your card that's in branch start
[02:54]  * rick_h_ runs away
[03:10] <huwshimi> Ah yes
[09:48] <frankban> rogpeppe1: morning and LGTM. If you agree, we can proceed like the following: you remove cmd stuff from core and I move the store commands from core to store. How does it sound?
[09:49] <rogpeppe1> frankban: sgtm
[09:49] <frankban> rogpeppe1: cool, I just found a typo on the cmd branch
[09:50] <rogpeppe1> frankban: oh yes?
[09:50] <frankban> rogpeppe1: yes, in a comment, so nothing bad
[10:10] <frankban> rogpeppe1: what's the idiomatic way to add a command to a package? creating a cmd dir and subdirs for each command, each one including a main package?
[10:10] <rogpeppe1> frankban: yup
[10:10] <frankban> rogpeppe1: cool thanks
[10:48] <frankban> rogpeppe1: I encountered code like this: http://pastebin.ubuntu.com/7638321/ . Do we have any conventional meaning for those kind of blocks?
[10:49] <rogpeppe1> frankban: looks a bit weird to me - it doesn't seem like there's any purpose to the extra scope
[10:50] <rogpeppe1> frankban: where's the code?
[10:51] <frankban> rogpeppe1: you can found those additional scopes in both cmd/charm-admin test files
[10:51] <rogpeppe1> frankban: ha
[10:51] <rogpeppe1> frankban: i found three almost identical places
[10:51] <rogpeppe1> frankban: definite copypasta
[10:51] <frankban> rogpeppe1: ok I'll fix those in charmstore
[10:51] <rogpeppe1> frankban: i see no reason for the block at all
[10:52] <frankban> rogpeppe1: are there cases where blocks like them are not meaningless?
[10:52] <rogpeppe1> frankban: ah, i *think* i see what they were trying to do
[10:52] <rogpeppe1> frankban: i think they thought that defer is block-scoped
[10:53] <frankban> rogpeppe1: yes, each block has its own defer
[10:54] <frankban> rogpeppe1: AFAICT there is no need to do that, and also defer should come right after the error check
[10:54] <rogpeppe1> frankban: they should do the close (not deferred) just after the Fprintf
[10:55] <rogpeppe1> frankban: but this would be a better way to do it:
[10:55] <rogpeppe1> frankban: http://paste.ubuntu.com/7638340/
[10:55] <frankban> rogpeppe1: right ioutil.WriteFile
[10:56] <frankban> rogpeppe1: ok I'll change all the occurrences
[10:57] <rogpeppe1> actually, it needs configPath to be saved: http://paste.ubuntu.com/7638343/
[11:34] <frankban> rogpeppe1: could you please take a look at https://github.com/juju/charmstore/pull/3 ?
[11:35] <rogpeppe1> frankban: looking
[11:40] <bac> frankban: thanks for the review
[11:41] <frankban> bac: yw, what do you think?
[11:41] <bac> frankban: still digesting.  i think it is probably a good idea.
[11:44] <rogpeppe1> frankban: reviewed
[11:46] <frankban> rogpeppe1: thanks
[11:46] <frankban> rogpeppe1: do you want to remove those commands from core as part of your cmd removal branch?
[11:47] <bac> frankban: one issue, is in setup we need the platform before calling _get_packaging_info, which is needed to create the parser.  so there is a chicken-egg thing to sort out
[11:47] <rogpeppe1> frankban: feel free to do it independently if you like
[11:48] <bac> frankban: your suggestion has a parser before determining the platform
[11:48] <rogpeppe1> anyone know how to do in git the equivalent of "bzr revert somefile.go otherfile.go" ?
[11:48] <rick_h_> frankban: were we able to keep updating the older precise charm? I thought we had something that didn't work so we were only updating precise. 
[11:48] <rick_h_> rogpeppe1: git checkout file.go 
[11:49] <rick_h_> rogpeppe1: will return it back to the original state
[11:49] <rogpeppe1> rick_h_: and that doesn't affect HEAD ?
[11:49] <rogpeppe1> rick_h_: thanks
[11:50] <rogpeppe1> rick_h_: that worked beautifully and extracted me from a nasty situation...
[11:51] <frankban> bac: IC. In this case let's keep retrieving the platform at the beginning of setup, and then call _validate_platform(platform, parser) near the end
[11:52] <bac> frankban: yeah, that's doable and avoids the program exit
[11:52] <bac> sounds good
[11:53] <frankban> rick_h_: trusty and precise charms share the same development codebase. We just need to push to both cs locations when releasing. IIRC the only broken bit in the precise charm is juju-gui-source={some git branch}
[11:54] <frankban> bac: great
[11:54] <frankban> rogpeppe1: ok, I'll do that after lunch
[11:55] <rick_h_> frankban: ah, maybe that's what I was thinking. I thought it was something in changes in git. 
[11:55] <rick_h_> frankban: thanks, we'll get the precise one updated today as well
[11:56] <frankban> rogpeppe1: I see your point re VCS history, but at this point I'd be inclined to just merge it. Sounds good?
[11:56] <rogpeppe1> frankban: yeah, sgtm
[11:56] <frankban> rogpeppe1: thanks
[11:56] <rogpeppe1> frankban: the history that gets imported is all mangled anyway.
[11:57] <rogpeppe1> frankban: i just go back to lp...
[12:14]  * frankban lunches
[13:05] <rick_h_> bac: frankban should we wait on a release blog post for quickstart until 1.4? 
[13:05] <bac> rick_h_: yes, i think so
[13:05] <rick_h_> bac: frankban I was going to write up a small blurb for the blog for 1.3.5 but notice the 1.4 card 
[13:05] <rick_h_> bac: ok cool, will hold off
[13:16] <rick_h_> jujugui very small docs branch for review please. https://github.com/juju/juju-gui/pull/387
[13:17] <frankban> rick_h_: done
[13:18] <rick_h_> frankban: ty much
[13:41] <frankban> rogpeppe1: could you please review https://github.com/juju/juju/pull/92 ?
[13:42] <rogpeppe1> frankban: looking
[13:43] <rogpeppe1> frankban: reviewed
[13:44] <frankban> rogpeppe1: thanks +1 on adding a dependencies.tsv to charmstore
[13:52] <frankban> rogpeppe1: and here it is: https://github.com/juju/charmstore/pull/4
[13:52] <bac> frankban: changes made, so please have a look when you can: https://codereview.appspot.com/108930045
[13:52] <bac> frankban: the changes did simplify the tests somewhat, which is always a good sign
[13:52] <frankban> bac: I'll look in a minute
[13:52] <frankban> bac: great
[13:53] <rogpeppe1> frankban: LGTM
[13:56] <frankban> rogpeppe1: thanks
[14:03] <rick_h_> hatch: morning, happen to still have the charm files downloaded? 
[14:03] <rick_h_> hatch: I was mistaken in not doing the precise charm
[14:03] <hatch> I do yep
[14:03] <hatch> oh ok
[14:06] <rick_h_> luca: heads up, shot down on a deploy on friday by IS so I'm on the schedule for a deploy first thing monday morning
[14:07] <rick_h_> hatch: cool, if you can merge/update the precise one as well and let me know I'd appreciate it. I want to hold off on the blog post until that gets ingested. 
[14:16] <luca> rick_h_: bloody IS! jk no problem, monday might be a better day to do it
[14:16] <rick_h_> luca: yea, sorry for the delay. We didn't quite get things wrapped up in time yesterday
[14:16] <frankban> bac: review done, thanks for the changes
[14:16] <luca> rick_h_: did we solve the onboarding issue?
[14:17] <rick_h_> luca: well after looking at it it's not a total mishap. It doesn't show in the right place, but the image is still good/sound so we decided we could release as is and update it
[14:18] <luca> rick_h_: ok, can I see it on comingsoon/mv?
[14:18] <rick_h_> luca: no mv needed. Just go to comingsoon, click in the "Help and feedback" and click on tutorial
[14:19] <rick_h_> luca: then go next/next until you see the inspector one
[14:19] <luca> ok, thanks. Will check it out
[14:19] <rick_h_> yea, appreciate the look and we'll be bugging you to find out how you want to handle moving/adjusting it. 
[14:19] <rick_h_> luca: then again, with the MV and other onboarding stuff on the schedule not sure if it's worth the time to update. 
[14:20] <luca> rick_h_: yeah
[14:20] <luca> rick_h_: in the onboarding the inspector is still on the right hand side
[14:21] <rick_h_> luca: right, that's what we're talking about. It's kind of tossed up there like a headless ghost
[14:21] <rick_h_> luca: but to move it over to the left doens't quite work out as a static image since the height is 'whatever the user's browser is'
[14:21] <rick_h_> luca: but as for a tutorial of "here's what a cool inspector looks like' the image is accurate and recognizable so left it for now
[14:32] <hatch> I am inspector, hear me roar 
[14:35] <hatch> rick_h_ ok the precise charm has been updated - so I'm guessing 30mins or so and it should be live
[14:35] <rick_h_> hatch: rgr, thanks. I'll keep an eye on ingestion
[14:37] <hatch> rick_h_ after the call today did you want to chat about that rendering perf stuff? Or beore?
[14:37] <hatch> before
[14:37] <rick_h_> hatch: either or works for me
[14:37] <hatch> sure, I'll hop in the friday room now
[14:37] <rick_h_> k, /me finds headphones
[14:47] <luca> rick_h_: it’s looking all good to me and Ale, lets launch. We’ll change it soon.
[14:47] <rick_h_> luca: sounds good, will launch it monday
[14:47] <rick_h_> I'll have a release blog post up in a bit here once the charms are loaded into charmworld
[14:47] <luca> rick_h_: thanks rick + team :)
[14:48] <rick_h_> jujugui team rocks :) and call in 12 so kanban it up please. 
[14:55] <hatch> for those who use w=1 on github....are you still able to comment on the code with w=1? the commenting functionality doesn't work for me
[14:59] <bac> jujugui: i cannot get to the calendar so i don't have the URL.  can someone paste it please?
[14:59] <rick_h_> sure thing
[14:59] <rick_h_> bac: https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso?authuser=1
[14:59] <rick_h_> jujugui call about now
[15:01] <rick_h_> jcsackett: ^
[15:01] <rick_h_> kadams54: ^
[15:01] <jcsackett> rick_h_: freaking google is saying i don't have the plugin *again*.
[15:01] <jcsackett> working on it.
[15:01]  * jcsackett is growing to loathe google.
[15:01] <kadams54> having problems connecting as well
[15:01] <kadams54> The little green quotes icon just keeps jiggling away
[15:01] <rick_h_> kadams54: chrome did that to me yesterday had to use FF
[15:23] <hatch> rick_h_ hey when you get a chance I need a set of tasks for focus on
[15:24] <hatch> shall I do the cleanup now?
[15:24] <rick_h_> hatch: yea, I think if you don't mind I'd like to move forward on those
[15:24] <rick_h_> and then we'll pull makyo back over from IL to MV 
[15:25] <hatch> sure, sounds like a plan
[15:26] <hatch> woah I'm working on something that's not unsched
[15:26] <rick_h_> hatch: but let me know if you want a break and work on something else. Nothing in there is required this week kind of stuff
[15:26] <rick_h_> :)
[15:26] <hatch> nah it's ok - unless you want me to go work on some three.js for fun today....
[15:26] <hatch> no?...
[15:26] <hatch> :P
[15:26] <rick_h_> hah
[15:27] <hatch> I swear it has implications for the GUI!
[15:27] <hatch> haha
[15:27] <rick_h_> hey, you were all happy to be working on sched work for a change. Why mess it up? :P
[15:27] <hatch> haha
[15:28] <hatch> living closeish to the airport is kind of cool, there are so many cool planes 
[15:28] <bac> frankban: hey, got a second to look at jenkins for brew? http://bot.brew.sh/job/Homebrew%20Pull%20Requests/11953/version=mavericks/console
[15:29] <bac> frankban: it looks like even calling '--version' is pulling in urwid that is failing on their test platform, likely due to being headless
[15:29] <frankban> bac: sure
[15:32] <frankban> bac: looking
[15:34] <bac> frankban: it is in manage/_create_save_callable.  i wonder if we moved the import of cli.views locally if it would go away
[15:35] <frankban> bac: importing views should not run anything at module level
[15:35] <frankban> bac: _start_interactive_session is explicitly cvalled in the traceback
[15:36] <bac> frankban: yeah, i see that now
[15:36] <frankban> bac: this smells: pkg_resources.run_script('juju-quickstart==1.3.5', u'juju-quickstart')
[15:36] <frankban> bac: it seems quickstart is run without --version for some reasons
[15:42] <bac> frankban: i think that is ok b/c sys.argv is being set prior
[15:42] <frankban> bac: yeah
[15:42] <bac> frankban: this works for me:
[15:42] <bac> [bac@sol ~]$ /usr/local/Cellar/juju-quickstart/1.3.5/libexec/bin/juju-quickstart  --version
[15:42] <bac> juju-quickstart 1.3.5
[15:43] <bac> frankban: i think the problem is we're deciding whether it is interactive or not before processing the command line args
[15:43] <bac> so we see it is interactive even though --version won't take advantage of it
[15:45] <frankban> bac: if --version is set, parser.parse_args() should call sys.exit before even caling _setup_env
[15:47] <bac> frankban: yep, verified
[15:47] <frankban> bac: so something in their environment is preventing argparse to exit
[15:48] <bac> frankban: or it isn't getting the argument
[15:48] <frankban> bac: yes
[15:52] <bac> frankban: shifting gears, any thoughts on the precise / mock version issue?  we rely on mock >= 1.0.1 pretty heavily.  seems like a backport is in order.
[15:52] <frankban> bac: to launch tests on precise?
[15:52] <bac> frankban: yes, the tests fail on precise.  let me grab the log
[15:53] <frankban> bac: don't we install mock with pip? 
[15:54] <bac> frankban: https://launchpadlibrarian.net/177510623/buildlog_ubuntu-precise-i386.juju-quickstart_1.3.5%2Bbzr80%2Bppa23%7Eubuntu12.04.1_FAILEDTOBUILD.txt.gz
[15:55] <bac> frankban: the build farm doesn't appear to use pip.  only installs ubuntu packages
[15:55] <bac> makes sens
[15:55] <bac> s/sens/sense/
[15:56] <frankban> bac: so I guess you updated the packaging repo to run the tests before building 
[15:56] <frankban> bac: and that's really good
[15:57] <bac> frankban: i did not consciously do that
[16:01] <frankban> bac: :-) but it is there (in debian/rules) I think we have two options: 1) as you mentioned, backport mock, and put it on the PPAs (it should be easy) or 2) change debian/rules so that tests are run with make check
[16:02] <frankban> bac: if the current packaging setup reflects the one used by the distro release, then I'd vote 1)
[16:02] <bac> frankban: oh, ok, that was part of the reconciling with the ubuntu package that robie requested
[16:02] <bac> frankban: yes, that is the case
[16:03] <bac> frankban: yeah, backport seems the way to go
[16:03] <frankban> bac: yes, the brew stuff instead is weird
[16:04] <bac> frankban: back to the brew issue, i've got no ideas.  testing is pretty heavy weight, too
[16:07] <bac> frankban: going to grab lunch.  if you have any bright ideas before your EoD i'm all ears! :)
[16:08] <frankban> bac:  I see a problem
[16:08] <frankban> bac: "JUJU_HOME=/tmp/frack juju-quickstart --version" works
[16:09] <frankban> bac: "JUJU_HOME=/tmp/frack juju quickstart --version" starts the interactive session
[16:09] <frankban> spot the difference
[16:10] <rick_h_> dashes are important? :)
[16:16] <hatch> rick_h_ fyi - I have an env spinning up to test that latest bug report
[16:19] <rick_h_> hatch: ok cool. I replied and added a card for that. Kind of floored. 
[16:20] <hatch> I'm guessing that I won't be able to reproduce :)
[16:20] <hatch> it's a little sparse on the details but who knows, maybe Ill get luky haha
[16:21] <rick_h_> heh, yea it is a bit vague but sounds like "gaaahhhh the horror everyone is dead!"
[16:21] <hatch> lol!!
[16:21] <hatch> "I'm not dead yet"
[16:21] <rick_h_> and you can't help but want to ask "it's ok now...tell us what happened out there?"
[16:22] <hatch> haha
[16:32] <frankban> bac: I've found the problem: it is a juju-core bug: in juju/cmd/envcmd/environmentcommand.go:environCommandWrapper.Init, if the default environment cannot be retrieved, the wrapped EnvironCommand.Init is not called. For this reason, without a juju environment, basically juju does not pass the arguments to the plugin
[16:32] <frankban> rogpeppe1: ^^^
[16:33] <kadams54> guihelp: any of the US/CA folks know if we need to stay a Saturday night for the sprint?
[16:33] <frankban> bac: so, a solution for brew could be testing juju-quickstart --version and not "juju   quickstart"
[16:34] <hatch> kadams54 why?
[16:34] <rick_h_> kadams54: I found if I flew out sat I was ok. 
[16:34] <hatch> oh I see
[16:34] <kadams54> I was initially planning on flying out Sunday, 7/20 and coming back Friday, 7/25
[16:34] <rogpeppe1> frankban: hmm, i don't understand how this is a bug
[16:34] <rick_h_> kadams54: the price diff for the extra day wans't that much
[16:34] <hatch> kadams54 I find it best if you pick a flight that gets there in the MORNING on sunday
[16:34] <rogpeppe1> frankban: if Init fails, surely things should progress no further?
[16:35] <kadams54> Is the price diff just in flights, or does it have to do with the hotel as well?
[16:35] <rick_h_> kadams54: yea, I'd plan on flying out sat and arriving sunday on the overnight flights. At least what I tend to do. 
[16:35] <hatch> then you stay up until about 9pm, and you're minimally jet lagged on monday
[16:35] <frankban> rogpeppe1: IMHO Init should not fail if there is no default env
[16:35] <hatch> yep same here
[16:35] <kadams54> OK, will do.
[16:35] <rogpeppe1> frankban: it only fails if there's no default env and no environment has been explicitly specified
[16:35] <hatch> it was considerably cheaper for me to stay an extra day on the front
[16:35] <hatch> like $400 
[16:35] <rick_h_> right
[16:36] <frankban> rogpeppe1: no default env, and even no juju home can be an expected use case for plugins. e.g. that's the exact case for quickstart
[16:36] <hatch> but I haven't booked the flights yet so will see :)
[16:36] <hatch> but as it stands right now I'll be landing there Sat morning
[16:36] <rogpeppe1> frankban: so how is an environment command supposed to know what environment to operate on?
[16:36] <rogpeppe1> frankban: if there's no default env and no env specified
[16:36] <frankban> rogpeppe1: right now juju still calls the external plugin but doesn't pass arguments, and that seems broken
[16:36] <hatch> kadams54 the hotel rooms are about $200USD/night so you can take that into consideration
[16:36] <kadams54> Are we flying into Heathrow?
[16:36] <hatch> yes
[16:37] <hatch> LHR
[16:37] <hatch> there are some tricks to getting around too which we can fill you in on
[16:37] <hatch> I've spent a bunch of time exploring :)
[16:37] <rick_h_> lol, don't walk there :O
[16:37] <hatch> why noT!!!!
[16:37] <hatch> lol
[16:37] <frankban> rogpeppe1: quickstart is a plugin, and handles the fact there is no default env pretty well
[16:38] <rogpeppe1> frankban: ha, so all plugins have to be env commands
[16:38] <rogpeppe1> frankban: i'd missed that
[16:38] <frankban> rogpeppe1: in general, I think finding the environment to work with should be plugins' business
[16:39] <rogpeppe1> frankban: yeah, i'm not sure why RunPlugin is doing what it's doing
[16:40] <kadams54> I've heard the Jack the Ripper Walking Tour is not to be missed.
[16:41] <frankban> rogpeppe1: that's not an urgent bug, we can work around that: bac: I am +1 on avoid testing both juju and quickstart in brew. we are interested in quickstart, and I assume juju is tested as well when installed by brew. so just adding the dash hopefully will fix the problem
[16:41] <rogpeppe1> frankban: ah, it's just so that the juju env can be passed in an env var rather than as a flag. i guess it saves the plugin doing all the JUJU_ENV magic
[16:41] <rogpeppe1> frankban: ha, and extractJujuArgs is horribly bogus
[16:42] <rogpeppe1> frankban: it won't work if you do juju someplugin -e=foo
[16:42] <rogpeppe1> frankban: or (assuming there's another single-letter flag, say -z) -ze foo
[16:43] <frankban> rogpeppe1: yeah, there is area for improvements in that part of the code: silently removing arguments is not good
[16:44] <rogpeppe1> frankban: silently *perhaps* removing the *possibly wrong* arguments is even worse
[16:44] <frankban> rogpeppe1: :-)
[16:44] <rogpeppe1> anyway, it's trivial to work around
[16:44] <rogpeppe1> for the time being
[16:44] <rogpeppe1> just set JUJU_ENV=xxx
[16:56] <hatch> rick_h_ on the latest Safari even accepting the self signed cert isn't making the GUI load
[16:56] <hatch> invalid certificate chain on the websocket it's saying
[17:04] <rick_h_> hatch: there's a trick to it
[17:04] <rick_h_> hatch: you have to hit an extra button and accept. 
[17:05] <rick_h_> hatch: let me get my laptop, sec
[17:05] <hatch> ohh lol
[17:05] <rick_h_> hatch: is there an env you have up and running?
[17:05] <hatch> yep
[17:05] <rick_h_> sec, let's hangout and I can show it, easier that way
[17:05] <rick_h_> hatch: standup?
[17:05] <hatch> sure sec
[17:18] <kadams54> US peeps: am I correct in thinking that I don't need a visa?
[17:18] <hatch> are you a criminal?
[17:18] <kadams54> Nope
[17:18] <hatch> then you should be ok lol
[17:18] <rick_h_> lol
[17:18] <hatch> sorry that was phrased wrong
[17:18] <hatch> have you ever been CAUGHT 
[17:18] <kadams54> British Embassy web site is telling me I don't need one, so I think I'm good :-)
[17:18] <hatch> :P
[17:18] <kadams54> lol
[17:19]  * rick_h_ goes to get lunchables. 
[17:19] <hatch> I'm in the common wealth - I walk in, fist bump the guards and carry on
[17:19] <kadams54> Ha!
[17:19] <hatch> rofl
[17:20] <kadams54> In my head you said "G'day mate" while doing that.
[17:21] <kadams54> So a lovely mismash from across the commonwealth.
[17:23] <bac> going through customs to enter montreal was one of the most pleasant of those experiences
[17:23] <bac> dude was bored, i guess, wanted to talk about agile development, etc.  was very odd.
[17:23] <bac> well, bored and nerdy
[17:26] <hatch> kadams54 lol!!
[17:27] <hatch> bac haha cool
[17:47]  * rogpeppe1 is done for the day
[17:47] <rogpeppe1> happy weekends all
[17:49] <hatch> enjoy your weekend rogpeppe1 
[18:13] <bac> wow, backportpackage is the world's best thing ever!
[18:13] <bac> backportpackage -d precise -s trusty -u ppa:juju-gui/quickstart-beta python-mock
[18:13] <bac> done
[18:27] <rick_h_> bac: you don't say...that looks kind of cool
[18:28] <bac> easy and worked.  usually you don't get both.
[18:47] <rick_h_> ok, I'm outta here. Time to pack the camper. Everyone have a great weekend!
[18:52] <hatch> cya lata rick_h_  have a good one
[18:55] <jcsackett> juju-gui: can someone tell me where existing services get loaded into the db?
[18:56] <jcsackett> my ack and grep fu is weak.
[18:57] <kadams54> jcsackett: ugh, I'm pretty sure frankban told me this once…
[18:57] <kadams54> jcsackett: …but I've slept since then!
[18:57]  * jcsackett laughs
[18:58] <kadams54> Looking…
[19:00] <kadams54> I think in models/handlers.js
[19:00] <kadams54> Beginning on line 217
[19:00] <kadams54> https://github.com/juju/juju-gui/blob/develop/app/models/handlers.js#L217
[19:04] <jcsackett> kadams54: thanks.
[19:08] <hatch> stepping away for lunch
[19:09] <hatch> jcsackett if you're looking from via the delta path then the handlers.js is correct
[19:09] <hatch> you can also grep for db.services to find places where it's interacted with
[19:09] <bac> jujugui: anyone got travel auth from teh ramm yet?
[19:09] <kadams54> Nope.
[19:10] <hatch> bac yep and purchased
[19:10] <bac> huh
[19:10] <bac> what'd it cost?
[19:10] <hatch> maybe I just got lucky
[19:10] <hatch> or maybe I bought him a doughnut 
[19:13] <hatch> ok now I'm really leaving for lunch :) 
[20:14] <rick_h_> bac: not gotten anything either
[20:14] <rick_h_> bac: on either of my trips
[20:14] <bac> ok.
[20:17] <hatch> holy smokes I almost forgot my juju env running
[20:21] <hatch> jujugui do we know if an orange box can be hooked up to the interwebs for us to play with remotely for testing the gui?
[21:26] <rick_h_> hatch: yes, they have a network attached to them
[21:26] <hatch> rick_h_ ok cool thanks - I was hoping so, so maybe we could hook into an orange box to try and repro that bug
[21:30] <rick_h_> hatch: removing luca from the sidebar bug. We've had the chat and the decision was to make hiding the sidebar a keyboard shutcut for pro users that don't need the show/hide handholding
[21:30] <rick_h_> hatch: there's a card to work on it, I've added the bug number to the card
[21:31] <hatch> ohh ok cool I didn't know about that - that's a good idea though
[21:31] <rick_h_> yea, decent compromise and I think we can make machine view flexible enough to runwithout the widebar (hopefully)
[21:31] <hatch> yeah I am pretty sure it's good to go css wise
[21:32] <hatch> are you camping now?
[21:32] <hatch> :)
[21:32] <rick_h_> not yet, just finished loading up
[21:32] <rick_h_> waiting for the wife to get home in 5
[21:32] <rick_h_> and getting the boy prepped
[21:33] <rick_h_> will probably be 'camping' in 2hrs ish
[21:35] <hatch> ahh :)
[21:35] <hatch> so much for 5pm camping :)
[21:36] <rick_h_> yea, took a bit extra time to get everything ready. Really have to do some prep during hte week. 
[21:36] <rick_h_> ok, well going to get finish up .
[21:36] <rick_h_> have a good weekend!
[21:44] <hatch> you too cya