[00:24] <hatch> hey huwshimi you have IE right? Can you QA something for me?
[00:27] <huwshimi> hatch: Sure
[00:27] <hatch> thanks! https://codereview.appspot.com/12683044/
[00:28] <hatch> it fixes drag and drop in IE
[00:28] <hatch> I coudln't make it break but....ya know....ie
[00:28] <hatch> so I was hoping for another QA :)
[00:31] <huwshimi> hatch: Sure, give me a few minutes to get it all set up
[00:31] <hatch> yeah no rush, just comment on the review when you're done
[00:31] <hatch> Im not going to do anything more on it until tomorrow
[00:33] <huwshimi> ugh, the vm needs to do updates
[00:35] <huwshimi> hatch: Just QAing that we can drop a charm onto the "start adding charms!" message?
[01:02] <hatch> huwshimi: that's the specific bug that this fixes yes
[01:02] <hatch> IE has a odd issue where depending on where you drag from it'll either drag the whole element, or just one of the text blocks
[01:03] <hatch> that's not fixed and not a priority right now
[01:05] <huwshimi> hatch: Updates look like they might have killed my vm :(
[01:05] <huwshimi> Might have to rebuild it
[01:06] <huwshimi> Oh, now it's doing more updates
[01:20] <rick_h> hey huwshimi, having fun?
[01:21] <huwshimi> rick_h: Soooo much fun
[01:21] <rick_h> :)
[01:23] <hatch> haha that happened to me earlier this week
[01:23] <hatch> the updates just.....stopped it from working for a bit
[01:33] <huwshimi> hatch: Yeah working now
[01:33] <huwshimi> hatch: I can't get past the "Your browser is not fully supported" screen with the inspector flag turned on...
[01:36] <huwshimi> Or even with the flag turned off now...
[01:41] <huwshimi> Oh, I clicked some kind of compatibility mode thing
[01:49] <huwshimi> hatch: QAs OK
[02:09] <hatch> huwshimi: son of a B I did the EXACT same thing
[02:09] <hatch> that's a blog post!
[02:10] <hatch> seriously I spent like 20mins trying to figure out why the heck it wouldn't load
[02:17] <huwshimi> hatch: :)
[08:19] <teknico> gary_poster: pong
[08:20] <teknico> gary_poster: sorry about yesterday afternoon, had to leave a little early
[08:20] <gary_poster> teknico, np
[08:24] <gary_poster> teknico, are you available for a hangout?
[08:24] <teknico> gary_poster: yep
[08:24] <gary_poster> teknico, ok will be using ipad so not guichat
[08:25] <teknico> gary_poster: do you want me to setup one?
[08:27] <gary_poster> teknico, I've tried to hangout with you twice :-P sure you try now
[08:27] <teknico> ok, switching google accounts...
[11:04] <rick_h> yay friday
[11:04] <sinzui> Hi jujugui. I am seeing this error for every test ftest when I test the charm on canonistack
[11:04] <sinzui> ERROR Missing config 'username', 'password', 'project-name' required for userpass auth\n"
[11:05] <sinzui> Any clues?
[11:08] <hazmat> sinzui, OS_ env vars for creds
[11:08] <sinzui> hmm.
[11:08]  * sinzui looks at novarc
[11:09] <hazmat> sinzui, just source it, if you haven't already
[11:09] <hazmat> env | grep OS_
[11:09] <sinzui> hazmat, I did. I think I soured the wrong one
[11:28] <sinzui> hazmat, I have confirmed I did source properly. I think my env is not ignored my make ftest. I can see that running that will destroy the juju environment I previously bootstrapped and deployed to
[12:46] <rick_h> luca__: ping, around?
[12:54] <rick_h> gary_poster: luca__ I'm trying to match up the design image as best I acn without actual dimensions and the fact that the category icons don't look like the ones used in the mock up. http://uploads.mitechie.com/lp/autocomplete_design.png is where I'm at. Please give it a look over. I've got some tests to write and then I'll put it up. 
[13:42] <rick_h> jujugui review time please. Autocomplete for all. notes and qa instructions included along with link to the design reference. https://codereview.appspot.com/12545044
[13:42] <jcsackett> rick_h: looking.
[13:42] <rick_h> gary_poster: I'll hold off on landing until the screenshot is ok'd by design. 
[13:42] <rick_h> thanks jcsackett 
[13:45] <jcsackett> rick_h: confused about the "is Category" check. is the id this is looking at a charm id, e.g. soemthing like "cs:foo/bar"?
[13:45] <rick_h> jcsackett: sorry, previous branch. We manually add categories into the results and build a manual id to make them work with charm-tokens
[13:45] <jcsackett> maybe i'm not so much confused as surprised that "cat:foo/bar" is a valid charm id we get, if that's the case.
[13:45] <jcsackett> ah, ok.
[13:45] <rick_h> jcsackett: that id is cat:~gui/
[13:46] <jcsackett> so this is more about shoe-horning in categories so they work with the charmtoken for autocomplete display.
[13:46] <rick_h> jcsackett: see line 158 in that file/diff (expand all)
[13:46] <rick_h> jcsackett: correct, this way categories get an icon, behave/look like charm-tokens
[13:46] <jcsackett> rick_h: dig, that makes sense. thanks.
[13:46] <rick_h> jcsackett: http://uploads.mitechie.com/lp/autocomplete_design.png for a screenshot (but please qa)
[13:47] <gary_poster> rick_h, here.  just had one of those...interesting meetings. :-)  jamie will look at it in a few minutes
[13:47] <rick_h> gary_poster: hah, it is friday where the most interesting ones take place :)
[13:47] <jcsackett> ah, the ever growing use case of the charm token...who knew it would end up in so many palces ...
[13:47] <rick_h> jcsackett: charm-token is the most reusable widget in the history of canonical widgets :)
[13:47] <jcsackett> rick_h: whoo!
[13:47] <jcsackett> (as long as you're willing to beat some data with a hammer for it)
[13:48] <rick_h> jcsackett: hey, you have to agree to its API :)
[13:48] <jcsackett> fair. :-P
[13:52] <adeuring> abentley: could you have a look here: https://code.launchpad.net/~adeuring/charmworld/1204985-address-key-error/+merge/179443 ?
[13:53] <abentley> adeuring: Sure.
[13:58] <jcsackett> rick_h: code looks good, QAing now.
[14:01] <jcsackett> rick_h: not a bug per se, but when i do 'apach' apache2-passenger is above apache2, which seems like an odd sorting.
[14:02] <rick_h> jcsackett: yea, it's based on weighting from the server and such. We can file something upstream in charmworld but I just take it as I get it
[14:05] <jcsackett> rick_h: review up. LGTM, QA ok, some notes.
[14:09] <abentley> adeuring: Please update the comments to indicate that Charm.store_url has a revision and Charm.address does not.  With that change, r=me.
[14:09] <adeuring> abentley: ack, thanks
[14:16] <benji> abentley: I'm doing final QA of my branch; how do I give myself admin access to my local charmworld?
[14:17] <abentley> benji: Admin access to the web site like charmers have?
[14:17] <benji> yep
[14:18] <abentley> benji: log in.  Anyone who's a member of juju-jitsu can log can act like a charmer on dev instances.
[14:18] <abentley> s/can log can act/can act/
[14:18] <benji> cool
[14:20] <abentley> benji: including staging.
[14:26] <benji> abentley: "403 Forbidden"; from https://launchpad.net/~juju-jitsu: "You are an indirect member of this team"
[14:27] <abentley> benji: Wacky.  I am also an indirect member of the team.
[14:27] <abentley> (but it works for me)
[14:27] <benji> abentley: I'm visiting /charms/precise/apache2/featured/edit, if that makes any difference
[14:28] <abentley> benji: The login operation should work the same everywhere.
[14:30] <abentley> benji: I was able to mark a charm featured locally.
[14:31] <abentley> benji: I did it just now.  (precise/apache2, in fact)
[14:31] <benji> ok, thanks.  I'm building a fresh trunk to see if it is a problem on my branch.
[14:31] <benji> I get a 403 on trunk too.
[14:32] <abentley> benji: You get that error when you click "login" on your dev instance?
[14:32] <benji> abentley: nope, after I login and I visit t/charms/precise/apache2/featured/edit
[14:34] <benji> abentley: I figured it out: the team membership checkbox is not automatically checked when loggin in through two-factor auth so it wasn't sent to the app (that seems like something we should fix)
[14:35] <abentley> benji: We have it fixed for production.  For dev instances, login.ubuntu.com does not trust your dev instance like it trusts launchpad, so it lets the user decide what info to communicate.
[14:35] <benji> makes sense
[14:35] <benji> in that case a big-ole message on login.ubuntu.com would be nice 
[14:37] <abentley> benji: Sorry, I lied.  We have it fixed for *staging*, but not *production*.
[14:37] <benji> k
[14:40] <abentley> benji: What would the message say?
[14:41] <benji> something along the lines of "UNLESS YOU CLICK ON THINGS BELOW, THIS PROBABLY WON'T DO WHAT YOU THING IT WILL DO"
[14:44] <abentley> benji: In some cases, the site will continue happily along, in other cases, it will prompt you for the missing data.  Maybe we could trigger it on the teams extension, since that's a case where having the user supply the data later is not an acceptable alternative.
[14:45] <benji> that would be nice
[15:01] <jcsackett> jujugui: weekly now, right?
[15:02] <benji> jcsackett: I figured we were skipping weekly because of no Gary, and having the daily at the same time
[15:02] <jcsackett> benji: i'm just going by what's on the calendar.
[15:03] <benji> pfft, calendars!  the next thing you know you'll be wanting style guides and tests
[15:03] <rick_h> 'by the book' suckers :P
[15:04] <hatch> jcsackett: sorry I was waiting until 9:#0
[15:04] <hatch> keep it the same as the rest of the wk
[15:04] <hatch> because we wont' really have much of a retrospective
[15:04] <bcsaller> more time for coffee then
[15:05] <jcsackett> this has been a week of mutiny.
[15:06] <rick_h> how dare you attempt to cage me with your schedules, limits, and rules!
[15:07] <hatch> lol
[15:22] <hatch> jujugui guichat in 8 kanban now
[15:23] <benji> call at 9:#0 huh?  I guess the capital "3" really emphasizes the time
[15:24] <hatch> exactly what I was going for!
[15:29] <hatch> jujugui guichat in 1
[15:31] <hatch> jujugui starting without you
[15:32] <teknico> http://www.youtube.com/watch?v=4FfXLMpr_DY
[15:43] <abentley> benji, bac: Do you want to have another sync call today?
[15:43] <bac> abentley: sure, after lunch?
[15:44] <benji> abentley: sure; how about after you review the branch that I haven't proposed yet?
[15:44] <abentley> bac: Works for me.
[15:44] <rick_h> lol
[15:44] <rick_h> bcsaller: https://codereview.appspot.com/12545044/ is the link for the review
[15:44] <abentley> bac: My lunch is in 15 minutes.
[15:44] <bcsaller> rick_h: thanks I was looking
[16:30] <hatch> bcsaller: can you do that reviewon the ie branch? https://codereview.appspot.com/12683044/
[16:33] <benji> abentley: when I visit /api/2/charms/interesting I get an error about "No mapping found for [downloads] in order to sort on".  I expect there is something I have to run to create and populate that index, do you know what it is?
[16:51] <abentley> benji: charmworld/jobs/cstat.py will update that.  We should really add downloads to the mapping, though.
[16:51] <benji> abentley: cool, thanks
[16:52] <abentley> benji: np.
[16:52] <hatch> hey do we have a guide to get the Go dev env up and running somewhere?
[17:00] <hatch> what the shit ie is now giving me an 'unspecified error' on identical code from yesterday
[17:10] <rick_h> thanks bcsaller 
[17:11] <rick_h> hatch: you load IE in anger, you might be bitten :P
[17:11] <hatch> I'm so bloody pissed off right now
[17:14] <hatch> the error number is .... get this ...  -2147467259
[17:14] <hatch> who uses NEGATIVE Numbers for error numbers
[17:18] <benji> abentley-lunch: I would appreciate a review of my feature breakout branch: https://code.launchpad.net/~benji/charmworld/featured-breakout/+merge/179503
[17:19] <abentley> benji: I just got back.  Are you psychic?
[17:21] <benji> I get that a lot.
[17:25] <abentley> benji: Your branch reintroduces the 'qa' attribute that I've removed.  Is that an accident?
[17:25] <benji> abentley: yep; ignore that I must have fixed some conflicts wrong
[17:27] <abentley> benji: at 215, I don't think CharmTestCase needs to derive from MongoTestBase
[17:30] <hatch> jujugui can someone with IE10 pull down my ie branch and QA it? I can't get this branch to run at all anymore, even on revno's that passed QA
[17:37] <abentley> benji: This looks good as far as it goes, but it doesn't introduce a migration, so it's not landable.
[17:38] <abentley> benji: Also, I think I suggested using a modified construct_charm_id to generate revisionless charm ids.  I'm doing that in my upcoming branch, and it would be nice for the ids to line up.
[17:40] <abentley> benji, bac: I'm up for a sync-up whenever you are.
[17:41] <bac> abentley: sure
[17:41] <bac> abentley: guichat now?
[17:41] <abentley> bac: sure
[17:47] <hatch> I was finally able to get it working again...
[17:56] <benji> abentley: I forgot to bzr add the migration file, I've pushed a fix.  Lunching now.
[18:46] <bac> abentley: does promulgated=true imply the owner is ~charmers?
[18:46] <abentley> bac: It is common, but not always the case.
[18:47] <bac> abentley: i'm wedged then.  in my current version i'm using the basket_id to be ~owner/basket/revno
[18:48] <bac> abentley: for a promulgated bundle the url is /api/2/bundle/api/2/bundle/basket/revno/name
[18:49] <bac> abentley: i mean: /api/2/bundle/basket/revno/name
[18:49] <abentley> Right.  Well, I think it would make sense if the basket ID was not affected by promulgation.  Would that help?
[18:56] <abentley> bac: An example of promulgated=True, owner !charmers is http://manage.jujucharms.com/charms/precise/juju-gui
[18:57] <bac> abentley: right.  so i need to extract the owner from the basket_id.
[18:57] <abentley> bac: I don't understand why.
[18:58] <abentley> bac: The owner is in the payload/basket_data, so why not use it directly?
[18:59] <bac> abentley: for the promulgated case i showed above, the query is:
[18:59] <bac> query = {'basket': basket_id, 'name': path[2], 'promulgated': True}
[18:59] <bac> abentley: the basket in mongo will be prefixed by the owner name.  in this lookup i don't know the owner's name
[19:01] <abentley> bac: I had hoped you wouldn't need to basket itself when retrieving a bundle.  Can we fix it so you don't?
[19:02] <bac> abentley: we have to support URLs like /api/2/bundle/basket/revno/name so we only have (basket, revno, name) to work with for the query.  i'm open to suggestions
[19:04] <abentley> bac: Okay, so what data do you need, that's currently in the basket?
[19:04] <jcsackett> jujugui: is anyone else getting a string of 304s when they run test-server? i've just updated from trunk, and hadn't yet today. observing the behavior in trunk as well as my own branches that updated.
[19:05] <bac> abentley: chat?
[19:05] <bac> might be faster
[19:05] <benji> abentley: I pushed my branch with the un-added migration file added.
[19:05] <abentley> bac: sure.
[19:05] <hatch> jcsackett: yup lots-o-304
[19:05] <abentley> benji: I saw that, but not a fix for the QA stuff.
[19:05] <benji> abentley: oh, I forgot that :) 
[19:05] <benji> fixing now
[19:07] <jcsackett> hatch: does it move past hitting those two files over and over with 304 for you? i just keep getting test timeouts with that.
[19:08] <hatch> GET /test/charm%20icon%20url 404 2ms
[19:08] <hatch> GET /juju-ui/assets/svgs/service_module.svg 304 5ms
[19:08] <hatch> lemme run the full suite
[19:08] <hatch> sec
[19:08] <hatch> jcsackett: the tests appear to be running as expected
[19:08] <jcsackett> hatch: hrm. not for me.
[19:09] <jcsackett> i do 304 on js-yaml over and over and then get a timeout.
[19:10] <abentley> benji: Also, I posted earlier: I think I suggested using a modified construct_charm_id to generate revisionless charm ids.  I'm doing that in my upcoming branch, and it would be nice for the ids to line up.
[19:10] <hatch> yup 100% finished on a very slightly modified version of trunk
[19:12] <benji> abentley: will do 
[19:12] <abentley> benji: I am just putting up a branch that modifies construct_charm_id
[19:14] <benji> abentley: this is how I did it: http://paste.ubuntu.com/5967438/
[19:14] <abentley> benji: This is how I did it: https://pastebin.canonical.com/95719/
[19:16] <benji> abentley: given that we'll always be hardcoding the boolean parameter, two functions makes more sense to me; but it won't kill any kittens
[19:18] <jcsackett> alright, clean checkout time.
[19:19] <abentley> orangesquad, bac or benji: Could you please review https://code.launchpad.net/~abentley/charmworld/pre-versioned-ids-for-charms/+merge/179521 ?
[19:19] <benji> abentley: I'll take a look
[19:24] <hatch> jujugui looking for 2 very quick reviews and a quick qa on https://codereview.appspot.com/12704043/ plz and thx
[19:25]  * hatch lunching
[19:47] <abentley> benji: I've never really heard this "always be hardcoding" rationale before.  What's the virtue having two functions to avoid hardcoding?
[19:49] <benji> the hardcoding rationale is mine, but the "a single boolean that changes the way a function works is an anti-pattern" thought has been around for a while
[19:49] <benji> the virtue would be that having two named, straight-line (i.e., no loops or branches) functions is more straight-forward than one function that can do two things
[19:50] <benji> this is a bikeshed, though, so we've probably already spilled enough digital ink over it ;)
[20:24] <hatch> bcsaller: replied, and class changes being re-proposed
[20:24] <bcsaller> hatch: thanks
[20:28] <hatch> bcsaller: ok repropose finished
[20:30] <hatch> jujugui also if there is anyone else available to review it, it's only like a 8line diff
[20:31] <benji> hatch: I'll look
[20:31] <hatch> thanks
[20:34] <hatch> benji: lol
[20:34] <benji> :)
[20:35] <hatch> thanks for the review - I'd like to use a real name but 80chars
[20:35] <hatch> I suppose I could store the string in a smaller var
[20:38] <benji> hatch: you can use a longer name and split the line instead
[20:40] <hatch> yeah it's fixed :)
[20:41] <hatch> benji: do you know if we have a 'get started with go' guide for juju?
[20:42] <benji> hatch: I don't think we have anything company-made
[20:42] <hatch> ahh ok - I was thinking this weekend I might give Go a go
[20:42] <hatch> I'll find something online
[20:44] <hatch> don't know what I'll make
[20:45] <hatch> what do people make with serverside languages now?
[20:45] <hatch> lol
[20:46] <hatch> everything I do has a gui
[20:50] <abentley> hatch: I prefer to think of them as non-JavaScript languages :-)
[20:51] <hatch> abentley: lol even my serverside is done in js now - but it's job is to respond to a gui lol
[20:52] <hatch> oo a console based todo app
[20:52] <hatch> that's what I'll do
[20:53] <hatch> jcsackett: you should probably make sure the tests CAN fail ;)
[21:12] <bac> abentley, benji: you're both near EOD but if you'd like to do a review: https://code.launchpad.net/~bac/charmworld/bundles-display/+merge/179541
[21:13] <benji> bac: sure
[21:13] <bac> thanks benji.  i'll bbiab
[21:22] <hatch> bcsaller: so on the settings inspector page when I change a field it's background turns a light grey and I get a red star
[21:22] <hatch> after clicking save, it should clear those ui changes no?
[21:24] <bcsaller> hatch: yes, it should, the model should be set, that was working fine before
[21:24] <bcsaller> maybe I broke something moving the viewlets about, there was a bit of merging there for that
[21:24] <hatch> ok I'm on a fresh trunk checkout - the model is being updated on save
[21:24] <bcsaller> I'll look into in a few if you're not on it
[21:25] <hatch> I'm just working on the button bug right now
[21:25] <hatch> that might expose the issue as well
[21:31] <hatch> bcsaller: ahh this button issue does look related to the conflict stuff
[21:37] <bac> dogwalk cut short by monsoon
[21:42] <hatch> bcsaller: hey there must have been a bad merge if this ever did clear on save
[21:42] <hatch> because it looks like that only happens on conflict resolution
[21:43] <hatch> would you have an idea of where that method may be? Or if it was just forgot
[21:44] <bcsaller>   hatch: this is vs trunk or should I look at your branch?
[21:44] <hatch> bcsaller: might as well just look at trunk
[21:45] <hatch> I only changed one string so far heh
[21:45] <bcsaller> ok, checking into it now
[21:48] <bcsaller> hatch: it looks like the config/constraints callbacks do trigger clearChangedValues still
[21:48] <hatch> yep
[21:48] <hatch> but it's not responsible for clearing the UI
[21:49] <hatch> the conflict method in the viewlet is responsible for that
[21:49] <bcsaller> yeah.. its not bound
[21:49] <hatch> so do we have a slight architecture issue here?
[21:49] <bcsaller> which has already been invoked
[21:49] <bcsaller> looks like a minor one, I can cook up a fix for that 
[21:50] <hatch> well I'm wondering if we shouldn't define a clear conflict UI method
[21:50] <hatch> so kind of normalize this conflict method a bit
[21:50] <bcsaller> I think in my testing I always pushed it down the conflict pipeline and that resovled it
[21:51] <hatch> oh ok, do you want to tackle this bug?
[21:51] <hatch> or would you like me to?
[21:52] <bcsaller> hatch: either way, tell me what you'd prefer
[21:52] <hatch> umm I can do it, lets have a quick chat in a minute to make sure I'm on the right page
[21:53] <bcsaller> hatch: thought syncedFields might be the proper place
[21:53] <bcsaller> look like you could loop the <input>s and clear that state
[21:53] <hatch> in guichat
[22:31] <bac> thanks benji