[12:16] <bac> hey benji, check it out http://staging.jujucharms.com/bundle/~jorge/mediawiki-simple/mediawiki-simple
[12:20] <rick_h_> downloaded!
[12:42] <rick_h_> frankban: ah, thanks for the bug update. Makes sense. it was a drive-by when I was testing out the instructions in the bundle deploy tab in the gui and didn't have juju-core installed yet
[12:43] <frankban> rick_h_: np
[12:59] <bac> hey lbox, would it be too much to retry my google credentials, especially at the end of a 10 minute process?
[13:18] <bac> rick_h_: your merge destroyed my branch...  :(
[13:18] <bac> you did warn me...
[13:18] <gary_poster> hey bac, lp thinks you have a merge conflict in https://code.launchpad.net/~bac/juju-gui/send-bundle-id-to-deployer/+merge/195598
[13:19] <gary_poster> oh you are talking about that :-P
[13:25] <rick_h_> bac: :(
[13:26] <rick_h_> bac: let me know if there's anything I can do to help 
[13:27] <bac> rick_h_: thanks, but i don't think so.  just have to re-qa now.  no biggie.
[13:27] <rick_h_> bac: cool
[13:39] <gary_poster> frankban, doing review/qa
[13:40] <frankban> gary_poster: thanks! guihelp: anyone available for another review of https://codereview.appspot.com/28250044 ? thanks
[13:40] <rick_h_> frankban: sure thing, can peek at it in a few
[13:40] <frankban> rick_h_: great thank you
[13:55] <gary_poster> frankban, while qa-ing, idea: would be nice to have a quickstart option that exposes webbrowser options chrome, chromium, firefox, and (would require registering extra options in webbrowser module) chrome incognito and chromium incognito.  Would be convenient for qa plus for people who don't default to a browser we support
[13:55] <frankban> gary_poster: +1
[13:56] <gary_poster> frankban, also, this idempotent functionality is cool :-)
[13:57] <frankban> gary_poster: :-) yes it makes quickstart more useful
[14:05] <hatch> morning, how was everyones weekend?
[14:11] <gary_poster> good 'nuff.  yours?
[14:13] <hatch> decent until last night
[14:13] <gary_poster> when?
[14:13] <hatch> found a slow water leak at 12:00am
[14:13] <hatch> had to fix it before sleeping
[14:13] <hatch> lol
[14:13]  * hatch tired
[14:14] <gary_poster> ugh
[14:14] <gary_poster> sorry
[14:15] <hatch> yeah sheesh quick breaking my pipes!
[14:15] <hatch> lol, you'd make a good Canadian ;)
[14:19] <hatch> frankban: I put my slides for my talk up this weekend - sorry no screencast yet but coming soon http://fromanegg.com/post/67170468715/intro-to-go-from-a-javascript-developer-barcamp-yxe
[14:21] <frankban> hatch: cool, will take a look. how was your talk?
[14:24] <hatch> frankban: it went really well, lots of good questions about juju/go/js and there was about 100 people there, so fairly large crowd
[14:24] <frankban> hatch: nice!
[14:25] <hatch> yeah - and like always everyone is super impressed with Juju :D
[14:25] <hatch> well, and the GUI since that's how I demo'd it haha
[14:26] <frankban> hatch: oh! you also demoed the gui. cool, looking forward for watching the screencast
[14:30] <hatch> frankban: heh yeah, it was just as an asside because I had some extra time but people were really impressed
[14:31] <hatch> one of the questions "how do you configure bundles before deploying them?" cc/ gary_poster ;)
[14:31] <gary_poster> hatch, heh :-)
[14:31] <gary_poster> cool
[14:32] <rick_h_> frankban: I'm not following why the bootstrap check can't be the results of juju status? It fails if the env doens't exist, isn't bootstrapped, and you get a known res if it is. You'll see machine 0. So it's a single positive check?
[14:34] <hatch> rick_h_: before i forget, did you end up filing that bug about the guiserver returning the wrong info?
[14:34] <rick_h_> frankban: also, side note. Can we get a terminal wipe/clear after the "Created new window"
[14:34] <rick_h_> hatch: oh! thanks. It's on my notepad here. 
[14:34] <rick_h_> frankban: time for a chat actually? some questions on stuff from friday 
[14:35] <hatch> heh same here and I didn't see the email so I was curious :D
[14:35] <frankban> rick_h_: status can fail for a lot of reasons. and even if we have a bootstrap node, the agent can be down. moreover I prefereed to just bootstrap in order to not waste extra-time for the very common case when the environment is not bootstrapped
[14:35] <rick_h_> frankban: ok
[14:35] <gary_poster> frankban, rick_h_, -1 on wipe/clear, but understand goal, I think.  Would be interesting in hearing other solutions
[14:36] <gary_poster> but scrollback--including password for now!--too nice to have to wipe
[14:36] <rick_h_> gary_poster: well, not wipe, but there's a terminal code I think that moves the line correctly so that you don't get $prompt $message
[14:36] <gary_poster> +1 on that, right
[14:36]  * rick_h_ remembers having to do something a while ago searches memory
[14:36] <frankban> guihelp: I don't remember if the following is in the guiserver docs: when deploying a bundle, some info about what's going on can be found in two places: 1) https://<gui-server-address>/gui-server-info and 2) /var/log/upstart/guiserver.log
[14:37] <bac> jujugui: review, please, old skool style (lbox hates me this morning): https://code.launchpad.net/~bac/juju-gui/send-bundle-id-to-deployer/+merge/195598
[14:37] <hatch> bac on it
[14:37] <hatch> bac: is this the 4XX error you're seeing again?
[14:37] <gary_poster> frankban, ack.  Could you add to...maybe both quickstart and charm docs?  Somewhere. :-)
[14:38] <bac> hatch: i just went through the QA for the second time today.  do it if you want or pass, up to you.  (it takes a while)
[14:38] <bac> hatch: yeah, 404 failure on tests from lbox
[14:38] <bac> hatch: plus dumb google auth error.  just decided to skip it this time.
[14:39] <hatch> just make sure someone does it :)
[14:39] <frankban> gary_poster: sure
[14:39] <rick_h_> frankban: let me know when you get a few min to chat on the bug/issue from friday
[14:39] <frankban> rick_h_: now is ok
[14:39] <hatch> these diffs are sure hard to read
[14:39]  * hatch spoiled
[14:41] <rick_h_> frankban: https://plus.google.com/hangouts/_/72cpimpnpmmm1v3304ph2cjoa8?hl=en
[14:43] <hatch> bac: so the bundle object data is always required but the id is optional - can't we pull the id from the bundle data then?
[14:43] <bac> no
[14:43] <bac> not in the yaml
[14:45] <hatch> so if someone drags the yaml in, we pass the id in?
[14:47] <hatch> I don't think that we do
[14:47] <hatch> so in that case it would be undefined anyways
[14:50] <gary_poster> Rhetorical question: Why does it seem slower to load the GUI from jujucharms.com than from a Juju deployment running the real tool? :-/
[14:51] <hatch> 3 layers of firewalls
[14:51] <hatch> oh sorry, Rhetorical
[14:51] <hatch> lol
[14:51] <gary_poster> yeah, was thnking something along those lines :-/
[14:51] <gary_poster> the firewalls, that is ;-)
[14:51] <rick_h_> gary_poster: london 
[14:52] <rick_h_> gary_poster: jujucharms.com crosses the ocean, ec2 is a EST DC
[14:52] <gary_poster> ah, yeah, maybe so
[14:52] <gary_poster> I mean, that's true :-)
[14:52] <rick_h_> plus the three fireealls :)
[14:52] <gary_poster> but maybe that's the explanation
[14:52] <gary_poster> yeah
[14:52] <rick_h_> err firewalls
[14:53] <rick_h_> yea, there are times I think hosting all our stuff out of a central London location hurts us from a performance perspective. In my US is the center of the world view of things 
[14:53] <hatch> hehe
[14:53] <gary_poster> :-)
[14:54] <hatch> http://www.dell.com/us/business/p/xps-13-linux/pd.aspx
[14:54] <hatch> looks like they come with touch screen, haswell, ubuntu
[14:55] <hatch> credit...card....burning....
[14:55] <rick_h_> no trackpoint :(
[14:56] <hatch> you're clingin to the past....man....no need for a trackpoint when you have touchscreen.....man
[14:57] <rick_h_> ugh, I don't believe in touchscreen laptops
[14:57] <hatch> I didn't either
[14:57] <rick_h_> already have a fit when my wife points at things and touches it on accident
[14:57] <hatch> haha
[14:57] <gary_poster> ipad + keyboard = great experience
[14:57] <hatch> lying in bed browsing the internet a touchscreen would be nice
[14:58] <rick_h_> I've got my N10 + keyboard and it's cool for some things, but I get annoyed at touching the screen. I'm too terminal/vim/keyboard all the things! I guess
[14:58] <rick_h_> every time to move my hands off the keyboard I feel like someone's going to bring a rule down on my hand :)
[14:58] <rick_h_> tablet for that
[14:58] <hatch> mouse --move --left 10 --click
[14:58] <rick_h_> (the bed browsing) I do <3 the N10 for a lot of that casual stuff
[15:00] <bac> hatch: missed your question.  yes, if the yaml is deployed from a local file then the bundle has no ID and it is not credited in charmworld.
[15:00] <hatch> bac: right, so we can 'always' parse the id out of the object, if no id, then no problem
[15:00] <hatch> so you don't need to deal with passing it in externally
[15:01] <bac> hatch: what line are you refering to?
[15:01] <hatch> well it could be implemented in env.bundleImport()
[15:02] <rick_h_> frankban: ok, submitted under https://bugs.launchpad.net/charms/+source/juju-gui
[15:02] <hatch> then you wouldn't need all of the extra data flying around
[15:02] <hatch> (plz correct me if I just
[15:03] <hatch> "don't get it")
[15:03] <hatch> :)
[15:03] <bac> hatch: first, i don't know what env.bundleImport is.
[15:03] <hatch> got a second for a quick call?
[15:03] <rick_h_> hatch: it's moved remember
[15:03] <bac> sure
[15:03] <hatch> https://plus.google.com/hangouts/_/72cpi0qnq012rqp4mojqnq42kg?hl=en
[15:04] <frankban> rick_h_: thanks, so this means that it's an error only when you deploy that bundle, right? It is not the interaction between two subsequent deployments. What happen if you deploy a working bundle aftre a failing one?
[15:05] <rick_h_> frankban: if I deployed the bundle on it's own it works fine
[15:05] <rick_h_> frankban: so it only died out when I first had the failing one
[15:05] <gary_poster> frankban, LGTM with small and trivials; QA good, though I added a second note about something that didn't go as your QA instructions prescribed.
[15:07] <frankban> gary_poster: thanks, re your QA note, in the previous step I added "juju deploy -e ec2 juju-gui" after the service removal...
[15:07] <gary_poster> frankban, oh, sorry!
[15:07] <frankban> gary_poster: np, I did that, it works ;-)
[15:08] <gary_poster> frankban, cool :-)
[15:09] <gary_poster> bac, you don't need another review/qa, right?
[15:09] <bac> no
[15:09] <gary_poster> k
[15:09] <gary_poster> good, 'cause I wasn't going to give one. ;-P
[15:13] <frankban> gary_poster: great stuff in you review, thanks! only one question: how should the core bug be? "please don't change your error message"? a --format for an error seems weird to me, but maybe I am wrong
[15:14] <frankban> gary_poster: maybe "expose a safe way to know if an env is bootstrapped"
[15:16] <frankban> rick_h_: so discourse does not fail unless another bundle failed before?
[15:16] <frankban> rick_h_: or discourse bundle intermittently fails, and when it does, the error is empty?
[15:17] <gary_poster> frankban, heh.  Minimally, we can describe the problem to them and ask for ideas. As an idea, though, a --format that affects both normal output and error output seems reasonable to me FWIW--you are asking for a machine-readable response, whatever the response is.  What you suggested is similar to my "minimally" bit; if you go that way, I would s/safe/safe, machine-readable/ or something
[15:17] <rick_h_> frankban: jenkins does not get the failure status unless discourse was run before hand and failed
[15:19] <frankban> gary_poster: ack
[15:21] <frankban> rick_h_: ack, I was looking the wrong bug: https://bugs.launchpad.net/charms/+source/juju-gui/+bug/1252295
[15:21] <_mup_> Bug #1252295: guiserver bundle deployment error is empty <juju-gui (Juju Charms Collection):Triaged> <https://launchpad.net/bugs/1252295>
[15:21] <rick_h_> frankban: ah ok. Yea filed those as two parts. One is the error being empty which can happen on its own. 
[15:22] <rick_h_> frankban: the second was the first failure making the second one register as failed
[15:22] <frankban> gary_poster: rethe already_bootstrapped argument. perhaps I can make deploy just take a "to" argument and make the check in "run"
[15:22] <frankban> rick_h_: cool thanks
[15:23]  * gary_poster looking/thinking
[15:25] <frankban> gary_poster: sorry, s/already_bootstrapped/env_type
[15:25] <gary_poster> ah!
[15:25] <frankban> gary_poster: well, maybe it's not a great idea. and +1 on s/already_bootstrapped/check_preexisting or similar
[15:26] <gary_poster> frankban, I like the idea of replacing  env_type with to.  Keeps the local function simpler, and the arguments more self-describing
[15:27] <frankban> gary_poster: cool, ok
[15:27] <gary_poster> frankban, fwiw, when you said already_bootstrapped at first, I was trying to make it work, :-) and thought you meant something that seems maybe interesting.
[15:27] <gary_poster> you would split up deploy service and deploy unit into two functions
[15:28] <gary_poster> and run would get the status and decide what to do (perhaps from a third function)
[15:29] <gary_poster> frankban, shrug, might make code simpler to read?  it would keep the deploy functions only about deploying
[15:29] <gary_poster> which might be nice
[15:30] <gary_poster> just an idea from trying to make sense of a miscommunication, so feel free to ignore :-)
[15:31] <frankban> gary_poster: hum... it seems interesting, but then you have to pass service_data and unit_data, or put the logic in run... something to investigate in a future branch?
[15:32] <gary_poster> frankban, +1, or not :-)
[15:32] <frankban> gary_poster: cool ok :-)
[15:36] <bac> hatch: finally!  https://codereview.appspot.com/28440043
[15:37] <hatch> hah yay!
[15:39] <hatch> bac: lgtm'd with a comment as we discussed
[15:42] <frankban> gary_poster: filed bug 1252322
[15:42] <_mup_> Bug #1252322: Expose a safe/machine readable way to check if an environment is already bootstrapped <juju-core:New> <juju-quickstart:Triaged> <https://launchpad.net/bugs/1252322>
[15:42] <gary_poster> cool frankban thanks
[15:43] <rick_h_> frankban: LGTM'd and qa ok. Thanks for the update! This should allow me to use it on lxc now as long as I pre-bootstrap yay
[15:44] <frankban> rick_h_: not yet ;-) we still have an explicit check for local providers (and the bits in deploy is actually a yagni). but I planned lxc support to be my next quickstart card
[15:45] <rick_h_> frankban: ah right, but the deploy a bundle doesn't worry about the local provider. That's mainly what I was try to get at
[15:46]  * rick_h_ looks again, maybe I'm not in my lxc happy place 
[15:50] <Makyo> jujugui call in 10
[15:51] <hatch> hey Makyo did you ever find out a good set of apps for doing a screencast on Ubuntu?
[15:51] <Makyo> RecordMyDesktop + Audacity + kdenlive
[15:52] <Makyo> Though I'm still working on finding the best transcoding rate for kdenlive to get rid of artifacting.
[15:52] <Makyo> RMD records at 15fps which kdenlive doesn't like.
[15:53] <hatch> hmm - I wonder if I can use http://www.telestream.net/screenflow/overview.htm in OSX but have it cast the Ubuntu vm
[15:53] <Makyo> This happened last time you asked, too :)
[15:54] <hatch> yeah I'm indecisive because it's a $100 gamble haha
[15:54] <hatch> http://www.omgubuntu.co.uk/2013/04/lightworks-enter-public-beta this was also just released
[15:58] <gary_poster> jujugui call in 2
[16:12] <benji> jujugui: well, I guess that was the wrong window to close
[16:12] <hatch> lol
[16:12] <gary_poster> lol
[16:12] <rick_h_> benji: drops the mic and leave "I'm outta here"
[16:12] <benji> heh
[16:13] <benji> as a live sound guy, I will kill anyone that drops a mic on purpose
[16:14] <rick_h_> just know who to give that fisher price mic to 
[16:14] <benji> SM58s are indestructable
[16:14] <rick_h_> gary_poster: http://techcrunch.com/2013/11/18/surveymonkey-enterprise/ is interesting fyi
[16:16] <gary_poster> rick_h_, huh, cool, thanks.  will forward to Luca and Charline
[16:27] <hatch> hey look at that I got the YUI is not defined error
[16:27] <hatch> first time I think
[16:27] <hatch> well at least now I know what the issue is
[16:27] <hatch> jujucharms.com is not serving the all-yui.js file at all
[16:28] <hatch> it 404'd
[16:28] <gary_poster> hatch, I get it
[16:28] <hatch> oh really? yours still downloads -and- throws the error?
[16:28] <luca__> gary_poster: do you have a hangout?
[16:29] <gary_poster> luca__, https://plus.google.com/hangouts/_/calendar/Z2FyeS5wb3N0ZXJAY2Fub25pY2FsLmNvbQ.nm61lc93dnv0a4s18q2tt3650c
[16:29] <gary_poster> hatch, error is intermittent
[16:30] <hatch> yeah it's working again - I'm just saying that the issue is not related to anything clientside - the server is closing the connection to all-yui.js
[16:34] <hatch> dumb question but what is #!/bin/bash called ? I'm trying to figure out if sublime can enable syntax highlighting based on it
[16:34] <rick_h_> shebang
[16:34]  * hatch turns on safesearch
[16:34]  * hatch searches for shebang
[16:34] <hatch> lol
[16:34] <rick_h_> http://www.sublimetext.com/forum/viewtopic.php?f=3&t=14656
[16:36] <rick_h_> hmm, https://sublimetext.userecho.com/topic/20806-syntax-highlight-based-off-shebang-lines/ says it should be doing it 3yrs ago
[16:36] <hatch> heh yeah - it definitely doesn't
[16:37] <hatch> just configuring the applysyntax plugin
[16:37] <hatch> oh that might have been for sublimetext 1
[16:48] <frankban> gary_poster: re charm URL check (if a pre-existing service is found in the env): is it ok for you to make another card?
[16:49] <gary_poster> frankban, on call but ok.  you do it? :-)
[16:49] <frankban> gary_poster: sure :-)
[16:49] <gary_poster> thx
[16:59] <hatch> blarg
[16:59] <hatch> is there a juju hook api somewhere?
[16:59] <rick_h_> hatch: heh, it was about 10 sessions at the last sprint
[16:59] <rick_h_> nick is getting the first api for a hook written up currently :)
[17:00] <hatch> this just reading charms for the various commands is driving me nuts
[17:00] <rick_h_> yea, those meetings were painful imo. I like clear documented standards, but a large group of people want the flexibility/don't hold it back stuff in place now
[17:02] <hatch> I asked in #juju hoping that someone has something
[17:02] <rick_h_> good luck :)
[17:02] <hatch> hah
[17:02] <hatch> actually....
[17:02] <hatch> I do have 1 q you may be able to help me out with....time for a quick hangout?
[17:02] <rick_h_> sure
[17:03] <hatch> https://plus.google.com/hangouts/_/72cpj792njti59826rubg1v7ls?hl=en
[17:03] <hatch> oh wait
[17:03] <hatch> cancel that
[17:03] <hatch> https://plus.google.com/hangouts/_/76cpilhst0i5ii6btp3crpe6e4?hl=en
[17:03] <hatch> that one
[17:22] <frankban> hazmat: ping
[17:29] <hazmat> frankban, pong.. in meetings all day fwiw. watsup?
[17:31] <frankban> hazmat: ok, feel free to read this later. re unit placement in machine: in the code path followed when the GuiEnvironment is used, an int value is never converted to a string. Either the Deployment object or the GuiEnvironment itself can make that conversion. What do you prefer? If you want to avoid that conversion to be done in a lower layer (the Deployment class) I can quickly set up a branch which does it in t
[17:31] <frankban> he GuiEnvironment.
[17:41] <hazmat> frankban, oh... yeah.. this is the issue from friday
[17:41] <frankban> hazmat: yes
[17:42] <hazmat> frankban, i think service or deployment is the most appropriate
[17:43] <hazmat> frankban, the service already has get unit_placement property that would be a good spot for the conversion and a test
[17:43] <Makyo> http://eleks.github.io/js2js/
[17:45] <frankban> hazmat: sounds good, do you want me to work on this?
[17:48] <hazmat> frankban, if you need it the next day, that's probably best, else i can cover it.
[17:48] <hazmat> er. within the next day
[17:49] <frankban> hazmat: it's not that urgent, I believe end of this week can be ok
[17:59] <hazmat> frankban, cool
[17:59] <frankban> hazmat: great thank you
[18:04] <frankban> guihelp: I need 1 quick review for a documentation only branch: https://codereview.appspot.com/28490043
[18:04] <frankban> thank you
[18:04] <Makyo> frankban,  on it
[18:04] <hatch> sure
[18:04] <frankban> Makyo: thanks
[18:04] <hatch> oh darn
[18:04] <bac> doh
[18:04] <hatch> ok
[18:04] <hatch> :)
[18:07] <hatch> ughhhh
[18:10] <hatch> when requestin a boolean value from `config-get` it returns 'False' which is not a boolean value according to bash
[18:27] <hatch> benji: you kickin around?
[18:27] <benji> hatch: yes... I think
[18:28] <hatch> benji: http://bazaar.launchpad.net/~hatch/charms/precise/failtester/trunk/view/head:/hooks/handler do I have to quote the $hook and $fail_* to get them to compare as strings?
[18:28]  * benji looks
[18:28] <hatch> line 51: False: command not found
[18:28] <hatch> is the error I'm getting
[18:28] <hatch> which means that the $fail_start command is trying to execute as "False" or something
[18:30] <benji> hatch: you can use double brackets and not have to quote
[18:30] <hatch> oh ok so change them all to [[ ]]
[18:30] <hatch> thanks, I didn't know that
[18:32] <hatch> I wish that juju returned real boolean values
[18:32] <hatch> for bash
[18:32] <hatch> True/False I think are -only- booleans in Go
[18:33] <benji> right, double all the square brackets and you should be good to go
[18:33] <benji> (double brackets are a bash extension that is much saner than the Posix single brackets)
[18:34] <hatch> I really need to study bash more
[18:34] <hatch> the tutorials are.....thick
[18:34] <hatch> :)
[18:35] <hatch> here we go, 4th time is the charm, then this charm is done
[18:35] <hatch> charm
[18:35] <hatch> :)
[18:41] <hatch> sweet works
[18:41] <hatch> thanks
[18:59] <hatch> note to self....dont try and create a bunch of lxc's at once
[19:00] <rick_h_> hatch: :)
[19:00] <rick_h_> hatch: yea, I think my limit on my desktop is around 20
[19:00] <rick_h_> over that and things lock up for a long while, IO bound 
[19:01] <hatch> yeah the box has raid 1 too so it's really bound
[19:01] <hatch> heh
[19:05] <hatch> Dart 1.0 was released
[19:05]  * hatch starts to port the GUI
[19:13] <gary_poster> heh
[19:16] <rick_h_> hatch: come on https://twitter.com/mitsuhiko/status/401096744198758400
[19:16] <hatch> see he has the right idea
[19:16] <rick_h_> surely you're ready to take that port and go to typescript
[19:16] <hatch> I write dart in typescript
[19:16] <rick_h_> then we can check out rust and see if it offers anything :P
[19:17] <hatch> lol
[19:17] <hatch> I don't know who this guy is but I hope that his comment is joking
[19:17] <rick_h_> Armin?
[19:17] <hatch> yeah
[19:17] <rick_h_> he's famous python dude 
[19:18] <rick_h_> though I'm not sure how much python he does these days
[19:19] <hatch> I just hope he realizes that Dart may compile down to js like typescript but it is also it's own language
[19:20] <rick_h_> yes, I'm pretty sure he's aware
[19:20] <hatch> you never know on these internets...you never know
[19:20] <hatch> have I mentioned how much I love the gui?
[19:20]  * hatch frames a picture of it on his desk
[19:21] <hatch> I just wish I could deploy a specific url from the GUI
[19:25] <bac> thanks for the note bcsaller
[19:25] <bcsaller> :)
[19:29]  * hatch shakes juju "let me deploy from launchpad"
[19:30] <hatch> jcastro: is discourse.ubuntu.com supposed to be mobile only css?
[19:31] <hatch> looks fixed now :)
[19:42]  * hatch is taking lunch
[19:55]  * gary_poster switches computers, because he needs to sit outside, because it is gorgeous
[20:33] <hatch> rick_h_: doesn't charmworld ingest every 15?
[20:34] <rick_h_> hatch: rgr
[20:34] <hatch> hmm
[20:34] <rick_h_> hatch: 00 15 30 45
[20:34] <hatch> https://localhost:1111/sidebar/search/~hatch/precise/failtester-3/?text=failtester is on v3
[20:34] <rick_h_> hatch: then it takes a few min to process
[20:34] <hatch> and v5 was pushed like an hour ago
[20:34] <rick_h_> hatch: well, it's meant to fail right? does it pass proof?
[20:34] <hatch> oh lol
[20:34] <hatch> actually it should...
[20:35] <rick_h_> well try it out, if it fails proof then it won't ingest
[20:35] <hatch> can I just deploy from launchpad somehow?
[20:35] <rick_h_> hatch: sure, bzr branch .... && juju deploy --local ....
[20:35] <hatch> ok so no :D
[20:35] <rick_h_> :)
[20:35] <hatch> kind of a crazy limitation
[20:36] <rick_h_> meh, why? it's one extra command to pull it down local
[20:36] <rick_h_> and you get safety/checks and such if you use the store based stuff, which we want to encourage charm authors to get their charm into and users to look for latest/best charms
[20:36] <rick_h_> seems kind of natural to me
[20:37] <hatch> right, but it's an aritificial limitation
[20:37] <hatch> every other package manager allows you to point to any location
[20:37] <rick_h_> yep, for the good of the users
[20:37] <rick_h_> apt-get install random_url ?
[20:37] <rick_h_> :)
[20:37] <rick_h_> mac store install random_url ?
[20:37] <hatch> npm install <url> go get <url>
[20:38] <rick_h_> that's a library, not a software package 
[20:38] <rick_h_> that's for developers and in some languages requires extra flags and such
[20:38] <rick_h_> pip install http:// fails
[20:38] <rick_h_> you have to -e git@....
[20:38] <hatch> charm proof is broken
[20:38] <hatch> darn
[20:39] <rick_h_> since by default it looks for things that it knows are buildalbe in the pypi 'store'
[20:39] <rick_h_> how is charm proof broken?
[20:39] <hatch> it's forcing me to add a revision file....which is deprecated
[20:39] <rick_h_> update it recently? 
[20:39] <hatch> just installed it
[20:39] <hatch> heh
[20:39] <rick_h_> hmm, I thought it was a warning?
[20:39] <rick_h_> it's still darn handy because there's a -u flag on juju deploy that'll auto increment the version and help force an update over the cache
[20:40] <hatch> W: No icon.svg file.
[20:40] <hatch> E: no copyright file
[20:40] <hatch> E: revision file in root of charm is required
[20:40] <rick_h_> ah, cool
[20:40] <hatch> so the docs or proof is wrong
[20:41] <hatch> wonder who would know which is which?
[20:42] <rick_h_> https://bugs.launchpad.net/charm-tools then I guess. Get it a warning. 
[20:42] <rick_h_> it is useful in charm dev ime until they add a no-cache or something flag
[20:43] <hatch> hmm this is interesting
[20:43] <hatch> I've never actually 'cared' while pushing a charm
[20:43] <rick_h_> no, proof is run in charmworld during ingest
[20:43] <rick_h_> proof is up to you. You don't need to get your charm in charmworld
[20:43] <rick_h_> it's just encouraged
[20:43] <hatch> well I do if I want to deploy it without pulling it down
[20:43] <rick_h_> and a bzr push doesn't run proof since you just installed it
[20:44] <rick_h_> sure, but you can push it, and pull it down on another computer and use it
[20:44] <rick_h_> and share with others, etc
[20:44] <hatch> yeah - I'm not sure that's a good experience
[20:44] <rick_h_> right, it sucks...so that you'll proof and fix things to get the good experience
[20:44] <hatch> maybe it's because the documentation isn't explicit
[20:44] <rick_h_> I know the publishing your charm docs talk about proof/etc
[20:45] <hatch> like maybe on the 'deploying charms' page if it said "this is why you can't deploy from launchpad, here is what you should do"
[20:45] <hatch> right now it says <repository>:<series><service>
[20:45] <hatch> which kind of implies that you CAN use other repositories
[20:46] <rick_h_> #4 https://juju.ubuntu.com/docs/authors-charm-store.html
[20:46] <rick_h_> so I think the juju-core store can point at different repositories
[20:46] <rick_h_> charmworld only looks at the official juju-core store off LP
[20:47] <rick_h_> and that's just an artifact of 'technically you can do' vs 'what you should be doing'
[20:47] <hatch> yeah I think the docs maybe need to be a little bit more explicit maybe
[20:48] <hatch> honestly I have no idea how up to v3 got into charmworld
[20:48] <hatch> it's never had a revision or copyright file haha
[20:48] <rick_h_> well I wonder if there's something else there then. Maybe we ignore those errors in charmworld? 
[20:49] <hatch> is there any way I can get a report of the charmworld ingest?
[20:49] <hatch> just to see what the issue is?
[20:51] <rick_h_> not really :/ http://manage.jujucharms.com/~hatch/precise/failtester
[20:51] <rick_h_> shows the lint status, but if it pulled in 3 revs it must ignore those errors
[20:51] <rick_h_> hmm, and rev 4 diff seems innocent enough
[20:52] <hatch> and the lint check results are different than my local lint check results heh
[20:52] <rick_h_> hatch: ah, it's not in the juju-core store https://store.juju.ubuntu.com/charm-info?charms=cs:~hatch/precise/failtester
[20:52] <hatch> ok I don't know what you mean
[20:52] <rick_h_> hatch: yea, that'll probably be a revision thing. mjc will only update proof when told to manually
[20:52] <hatch> ohh
[20:52] <rick_h_> hatch: yea, basically it's not your fault and not charmworld's fault. It's in juju-core's hands
[20:53] <hatch> so.....should I file a bug somewhere?
[20:53] <hatch> I guess I don't really understand the problem
[20:53] <rick_h_> yea, it's the black hole. We've hit issues here before but I've not been sure either. 
[20:53] <rick_h_> last time hazmat did some poking at things for us. There was some revision issue that caused grief. I don't recall the details 100%
[20:54] <hatch> so do you think that adding the revision file should fix it?
[20:54] <rick_h_> hazmat: is there someone we can bug about the core-store not pulling in a revision for a charm? 
[20:54] <rick_h_> hatch: only incidentilly as it'll add a new revision that might be picked up by the store
[20:54] <hatch> ahh - darn I hate black boxes
[20:56] <rick_h_> hatch: so basically charmworld checks that the store knows about your revision https://store.juju.ubuntu.com/charm-info?charms=cs:~hatch/precise/failtester 
[20:56] <rick_h_> hatch: if it doesn't we don't ingest it since you can't deploy it
[20:57] <hatch> ahh ok that makes sense
[20:57] <rick_h_> hatch: juju deploy hits this store, not charmworld to do the actual deploy work
[20:57] <hazmat> rick_h_, use juju publish the charm is probably broken
[20:57] <hazmat> publish will give some feedback, alternatively its a really simple go program to walk through the charm validation/errors from core
[20:57] <rick_h_> hazmat: rgr hatch ^^
[20:57] <hatch> cool I'll try that
[20:57] <rick_h_> hazmat: cool, thanks
[21:02] <hatch> ohh
[21:02] <hatch> apparently you can't have a requires and provides with the same name
[21:03] <hatch> guess I should have assumed that
[21:03] <hatch> thanks hazmat rick_h_
[21:10] <hatch> rick_h_: your CHC meetups are they actually in coffeeshops?
[21:10] <rick_h_> hatch: yes
[21:10] <hatch> they don't seem to mind?
[21:10] <hatch> or are there no 'presentations' ?
[21:10] <rick_h_> no, the last place had a meeting room in the back and we rented it out each week
[21:10] <hatch> oh that's cool
[21:11] <rick_h_> no, we've done a couple of 'let's check out YUIConf videos on the wall'
[21:11] <rick_h_> but it's mostly dedicated time to hack on something you care about of your own choice each week
[21:11] <hatch> cool - we have had a few small dev meetups but the issue is always the location
[21:11] <rick_h_> no matter how busy the week gets, I've got 2hrs of wed night to hack on my bookmark app, or read that article I was meaning to get to, or to vent, etc
[21:12] <rick_h_> yea, our shop got bought by another coffee chain and they opened up the room and then changed closing time from 10pm to 8pm
[21:12] <rick_h_> so I had to go hunting for a new coffee shop to hit up this weekend
[21:12] <hatch> oh darn
[21:12] <rick_h_> visited a couple of places
[21:14] <bac> jujugui: just deployed a bundle.  used the gui to destroy both services.  both removed from canvas.  but 'juju status' shows mysql still hanging around.  known issue?
[21:15] <bac> oh, it is marked 'dying' and has been for a while.
[21:15] <hatch> yeah it takes a long time to die sometimes
[21:15] <hatch> at least in my experience
[21:15] <hatch> what is 'a while' ?
[21:15] <hatch> ive seen it take 30mins sometimes :/
[21:18] <bac> gah, really?
[21:19] <bac> it's only been 10-15 minutes.  i just picked another test bundle with no overlapping services
[21:20] <rick_h_> bac: yea, done that before as well
[21:20] <rick_h_> jenkins is a good alt
[21:20] <hatch> yay updated
[21:21] <hatch> revno not matching the bzr val is odd though :)
[21:49] <hatch> man I'd really love to know why discourse.ubuntu.com keeps switching to mobile styling
[22:10] <hatch> and FINALLY I have finished testing my charm
[22:10] <hatch> boy that takes a long time
[22:10] <hatch> good thing I could do other stuff hah
[22:14] <hatch> I'll be writing up an email to the juju mailing list but here it is if anyone wants to use it until then https://jujucharms.com/fullscreen/search/~hatch/precise/failtester-5/?text=failtester
[22:55] <bac> jujugui (i.e. hatch): quickstart review? https://codereview.appspot.com/28520044/  no rush, i'm sure frankban will get to it in his morning.
[22:58] <Makyo> bac, on it.
[22:59] <bac> oh, hi, Makyo.  forgot you were still around.
[22:59] <Makyo> Yeah, just got back from dogwlak.
[22:59] <Makyo> Or however you spell it.
[22:59] <Makyo> Sun sets so early these days :/
[22:59] <bac> that's how i always spell it