[00:34] woo! expenses filed. Only took 3 months [00:38] hehe [00:40] now that vegas is filed I feel less obligated to file london ones :) [00:40] huwshimi: hey, how goes? Wanted to check up on your branches [00:40] and let you know that hatch and frankban are working on the 'deleting things' problems in the back end [00:40] rick_h__: I have a million things in progress :) [00:41] so should be able to revisit that branch later on [00:41] huwshimi: yea, seems like it. I wanted to see what was up, anything stuck you need a hand with, etc. [00:42] rick_h__: I talked to hatch about landing the deleted states (they just won't be visible) and then hooking them up when that's done (hence me moving the card back) [00:42] If you'd prefer me to wait I can [00:42] huwshimi: hmm, ok. I trust you on it. [00:42] :) [01:21] hah, poor huw was a photo target a bit https://www.flickr.com/photos/7508761@N03/14730078876/in/photostream/ [01:24] It's almost as if I was being followed :) [01:24] Nice photos! [01:25] hah, yea I was following you around a lot [06:22] morning all [06:28] urulama: Morning [06:32] huwshimi: anything particular regarding your cards on the board that need review or are in coding (to pass the message to the daily call)? [06:33] urulama: Only that I need second reviews on a couple of them. Thanks! [06:35] huwshimi: ok, np [08:14] frankban: morning [08:14] urulama: hi [09:06] frankban: do you know if rogpeppe is out today? [09:06] urulama: i'm around [09:06] rogpeppe: oh, hi, sorry :D [09:06] urulama: np :-) [09:07] rogpeppe: any news regarding the change of core to charm.v2? [09:07] urulama: i've been around for hours :-) [09:07] urulama: core is blocked until its critical bugs are resolved [09:07] urulama: so no branches are landing that aren't fixing those bugs [09:07] rogpeppe: ok, tnx for the info [09:07] urulama: i've got approval to land it though [09:08] rogpeppe: \o/ [09:12] rogpeppe: didn't have time to ask before ... any sessions this week? [09:14] urulama: this week and every week :-) [09:14] urulama: tuesday night it was [09:14] urulama: and absolutely rockin'! [09:15] rogpeppe: nice, glad to hear! [09:15] urulama: it was good on the friday night in london actually. i presume you didn't try and fail to find it. [09:16] rogpeppe: we wanted to have a session today (with the gypsy swing band, and me cooking), but the weather is really bad :( well, after Nuremberg it is [09:16] urulama: music and home cooking, the perfect combo :-) [09:16] rogpeppe: no, i was in the museum for nearly 4h ... i guess the sms didn't get through :( [09:17] urulama: nope, i haven't got any sms messages from you since thursday [09:18] afk for 10 minutes [09:18] * urulama lunches ... woke up early today [10:13] rogpeppe: what do you have in mind for the charm refactoring? [10:13] urulama: i'd doing exactly as i suggested in my email to juju-dev [10:13] s/i'd/i'm. [10:15] rogpeppe: aaa, the URL/ReferenceURL, cool [10:24] urulama: https://github.com/juju/charm/pull/31 [10:25] will take a look in 5min [10:26] urulama: thanks [10:31] rogpeppe: found this work done by hazmat ... find it interesting https://github.com/kapilt/juju-tosca [10:33] urulama: thanks for pointing to that [10:47] morning [10:49] rick_h__: morning [10:58] rick_h__: morning [10:59] guihelp: I need reviews/QA for https://github.com/juju/juju-gui/pull/469 . Thanks! [11:10] * frankban lunches [11:21] rogpeppe: i like how more uniform the code is now with new URL & referenceURL [11:21] urulama: cool [11:22] rogpeppe: i see that you're already on the way to change the charmstore ... making charm.v2 obsolete (in a way) [11:23] urulama: well, who knows who is already using charm.v2? :-) [11:24] * urulama makes a wild guess that all the users are mostly present here :D [11:28] urulama: i don't mind leaving v2 behind. we don't need to maintain it. [11:28] urulama: i do think it's important to change the version number though. [11:29] urulama: BTW i'm just investigating to see what the Resolve method does. There don't appear any tests for it, and it's only called once in the entire of juju-core [11:30] rogpeppe: let's welcome our new charm.v3 :) [11:30] urulama: let's :-) [11:30] rogpeppe: regarding core - makes sense, they do depend on full URLs [11:41] morning [11:46] urulama, context?.. that's an in progress oasis std thingy.. [11:47] hazmat: i've done the voting for ODS talks and noticed your OASIS and Juju ... just passed the git url to rogpeppe as a curiosity [11:47] hey rick_h__ can you decipher http://ci.jujugui.org:8080/job/jenkins-github-lander-merge/27/console [11:49] urulama, oh.. nice [11:50] hazmat: are you targeting to make juju bundles easy to integrate into heat with tosca support? [11:52] urulama, that's a secondary goal.. first goal.. is tosca import into juju.. outbound, we'll be an embedded an orchestrator... re heat i'd prefer to embed directly [11:53] hazmat: nice! [11:53] bac: otp, looking [11:53] bac: go into the workspace and do 'git fetch' and try to :shipit: again [11:54] rt [11:54] bac: the workspace for that, not sure why it's empty, but I think that's the answer [11:59] frankban: will be 2min late here sec [11:59] rick_h__: np [12:15] rick_h__, jcsackett: new jenkins-github-lander has been installed on both of our jenkins instances. [12:16] bac: ty much [12:16] rick_h__: it is not released anywhere, right? [12:17] yay for safety [12:17] bac: no, not currently [12:17] rick_h__: does curtis use it? [12:17] bac: can you ping mgz and let him know about the bug/update [12:17] oh, ok [12:17] bac: they're using it, but they've got a fork they're using [12:17] with all the bug blocking landing/etc stuff [12:17] I've not looked where they're keeping their fork [12:57] jrwren: i haven't seen any return type comment from you, FYI [12:58] jrwren: ha, it came in a different thread [12:58] jrwren: ignore me :- [12:58] ) [12:58] jrwren: see http://godoc.org/labix.org/v2/mgo/bson#Getter [12:59] jrwren: to implement an interface, the methods must have exactly the same type signature [12:59] jrwren: so returning (string, error) would not work [12:59] rogpeppe: oh, you are implementing some interface there? [12:59] rogpeppe: I missed that bit. Is it a mgo interface? [13:00] jrwren: it's mentioned in the doc comment for the method [13:00] jrwren: bson.Getter [13:00] jrwren: it's understood by the marshaling code that mgo uses to talk to mongodb [13:00] ok. [13:00] new to go and lack of coffee. It makes complete sense now. ty [13:03] jrwren: np [13:07] rogpeppe: have you seen the comment from Casey about urls? [13:07] urulama: yeah [13:08] urulama: i've been chatting with him on #juju-dev about it [13:08] rogpeppe: tnx [13:18] jcsackett: kadams54 around? can you guys take some time this morning to go through huw's branches please? [13:19] he's got 5 in review atm [13:21] rick_h__: ah, yes, i talked to huw this morning and he asked for second reviews on his branches [13:22] urulama: yep, we'll get those cleared out today one way or another. [13:25] rogpeppe: on the charmstore charm review you mentioned the bug with godeps doing things in parallel. i thought you fixed that weeks ago. [13:26] bac: no, i didn't change the default [13:26] ah, ok. i misremembered that you did [13:26] bac: (like a fool, i thought i'd have some time to investigate the actual issue :-]) [13:26] rogpeppe: if we need the time we need to create a card and have it as something to get scheduled [13:27] rogpeppe: is this something we can file a bug for and then add the bug as a card to the board's backlog to get scheduled up? [13:27] rick_h__: given that there's a workaround, i'm not sure it's worth scheduling our time for [13:28] rogpeppe: ok, is there a bug to document the issue/workaround? [13:28] rick_h__: i've pushed a fix. the workaround is now in place for anyone that uses a fresh version of godeps [13:28] rick_h__: (unless they explicitly use a -P flag) [13:28] rogpeppe: oh gotcha [13:40] rick_h__: on it. [13:40] the voting interface on ods is kinda of baroque [13:40] hazmat: :) [13:40] jcsackett: <3 [13:41] hazmat: i've searched using names, opened all links in different tabs ... that helped a bit [13:46] urulama, i just want a listing to scan titles.. seems obvious [13:46] paging through one at a time through 2500 submissions is inane [13:46] their basically encouraging author/company/topic specific voting by forcing search [13:47] instead of browsing [13:49] hazmat: search for "at" or "of" ... you'll get list of all [13:49] well, list of all that have these words ;) [13:52] urulama, nice trick [13:59] frankban, bac, jrwren: here are the changes to make the charm store use the new charm.v3 API [13:59] https://github.com/juju/charmstore/pull/49 [14:01] rogpeppe: tests failed [14:01] urulama: yes, because charm.v3 hasn't landed yet [14:02] rogpeppe: how come? :D :D (just kidding) [14:02] jujugui: have to go now ... be back in 4h [14:02] urulama: i am hoping that someone might get around to deciding that it looks ok [14:02] urulama: have fun [14:02] rick_h__: tnx [14:03] rick_h__: joining 1:1 now [14:11] frankban is the card you have in review the same as the one I have in starting? [14:12] I thought you were on the pending removal changes [14:14] hatch: it's not the same, but it's related: it handles the db and ecs name changes, not the deployment panle ones [14:14] hatch: would you like to review it? [14:15] sure - you should be able to add one line and do my card as well [14:15] :) [14:15] I'll look in a minute [14:15] rick_h__ oh I see the email that's why you moved my old card back into coding [14:15] I thought LK was broken again [14:17] rick_h__ it was also my intention not to make those changes we had talked about on the front end, but on the back end [14:17] that's going to be a lot of code to ship to the client for that usecase [14:18] or should I just do it? [14:24] hatch: I thought per our conversation that was the work your card was going to be doing [14:24] hatch: that's why it was the target/blocker on release. It's a UX issue we need to fix right away, and the client has the abliity to do it in a pure autocomplete sense [14:24] hatch: and doing it server side is special casing the search needs for a single widget/component. [14:25] well we already hit a different endpoint for it [14:25] hatch: I'd like us to get the client side updated for the best UX [14:25] hatch: no, we don't [14:25] hatch: we add a query string flag to the search endpoint [14:25] that basically turns on 'prefix matching' [14:25] and does not filter/process results [14:25] hatch: call? [14:26] oh I thought it was a different endpoint because it had 'autocomplete' in the url [14:26] it's just a query string flag onto the same endpoint [14:26] and if we match on the start of a word is turned on/off based on that flag [14:26] ahh - well then that's broken [14:26] lol [14:27] the cf-mysql is in the matching results [14:27] so I'd prefer we try to get the client side widget fix in asap to fix the issue and make mark s happy and the fastest/best way to do that is in the client result [14:27] hatch: right, heh that's true. I think we broke that with ngraming [14:27] because we needed to match somethingCMS via searching for CMS [14:27] jcsackett: can I have a second review from you for https://github.com/juju/juju-gui/pull/469 when you have time [14:27] ok I'll fix this up [14:27] ? [14:27] hatch: ty [14:28] hatch: Makyo kadams54 and jcsackett are helping with huw's reviews that are outstanding. I'd appreciate it if you guys could help as the seconds. [14:29] mark the cards with the tags to prevent doubling up, but between the 4 of you guys should hopefully be able to move those 5 branches forward [14:29] oh, 4, one is in landing now [14:29] yeah I just shipped one [14:29] just doing the review on frankban's branch now [14:32] frankban I don't think this technique is going to work [14:32] the deployer bar results are built from the ecs [14:33] if the ecs values dont' change until deploy then we can't update the deployer bar [14:33] we need to use the 'old' method and loop through and update the appropriate records when it changes [14:34] hatch: unless the deployer bar uses the db to retrieve the model starting from its id [14:35] right but that's not how it's done now - right now the deployer bar listens for a 'changeSetModified' event then loops through the changeset [14:35] hatch: I am really trying to avoid these kind of ecs mutations [14:35] frankban: hatch so sounds like we need a matching update to the changelog rendering? [14:36] to pull from db at render time to go with this change? [14:36] kadams54: you're looking at https://github.com/juju/juju-gui/pull/466 right? i'm trying to make sure the card and the PR are the same ones. [14:36] frankban yeah I agree but it feels like we are doing it half way [14:36] hatch: if we need to mutate the ecs as a consequence of a user input, than that seems to me a fail [14:36] jcsackett: correct [14:36] and we'll never be able to remmeber if we need to poll the db or the ecs [14:36] kadams54: awesome. [14:37] bbiab [14:37] Ah crap, forgot about the two review thing and just shipped the onboarding PR. [14:40] rick_h__: ^ should I come to standup prepared for the stocks and humiliation galore? [14:40] kadams54: you've been shamed, carry on [14:40] :-) [14:41] kadams54: if you had any questions or want feedback on your review bribe a friend to peek at the landing change please [14:41] * kadams54 ponders which mentor would be the cheapest to bribe. [14:42] hatch: from my perspective, the db should be the single source of truth, and the idea of "changing a change in the changeset" doesn't feel so natural... I feel like it's going to be difficult to debug. [14:43] frankban: +1, but hatch's feedback is good that this branch will break rendering. This branch needs to update that to follow this convention in order to land. Am I understanding this correctly? [14:44] rick_h__: rendering is already broken on trunk: name changes are not reflected on the panel [14:44] rick_h__: my branch affects how you will solve that [14:44] frankban: ok, so existing bug. /me looks for a card for that [14:44] frankban: ah, that's why hatch is noticing, that's a card he's tryinug to do [14:45] rick_h__: yes [14:45] hatch: so why does frankban's changes not allow you to solve your cards with that in effect by repointing where the rendered names come from? [14:46] so my problem is that if we are going this direction (which I agree is a good one) the ecs needs to drop the extranious data and use the db as the source of truth on commit. The deployer bar then needs to listen to any changes in the db and then determine if it needs to update anything in it's list, and so-on [14:46] at the moment we are going only part-way there which is just going to get confusing and introduce potential bugs [14:46] I'd much rather get MV out the door then go back and fix things [14:47] hatch: frankban ok, let's chat post-standup and plan a path that will work for this [14:47] rick_h__: sure [14:47] otp atm and can't meet pre-call [14:47] np [14:49] frankban: safe to bet that you now don't need that second review? sounds like that PR may see some major changes. [14:49] maybe... [14:49] :) [14:50] jujugui call in 10 [14:52] kadams54: i see you've got a card in review, but there's no pr up yet--is PR coming, or has this already been reviewed? [14:52] Which card? [14:54] kadams54: "display services without machines ..." [14:54] is LK just not updating for me? [14:54] jcsackett: you are right I don't need that now. however, your I'd be interested in your opinion on the design decision if you want to take a look [14:54] frankban: ack, i'll take a look then. [14:55] jcsackett: hmm… that should have a PR… one moment… [14:55] jcsackett: thanks [15:00] makyo_: call please [15:12] * makyo_ zooms back home [15:17] rick_h__: i just posted two vacation requests and a holiday for september. [15:22] bac: cool loading [15:28] jujugui lf another review on https://github.com/juju/juju-gui/pull/465 [15:29] Makyo: reviewed [15:31] hatch: why the change list shown when you click deploy and the one displayed when you click "X changes" are two different code paths? [15:32] hatch: UX reasons? [15:38] frankban I'm not sure I didn't write this [15:38] hatch: ok [15:38] hatch: frankban ask jcsackett [15:38] hatch: frankban there is some UX diff and such, I know there was some talk of reuse when it was added but don't recall the final fallout [15:38] rick_h__: i think that was "sprint to demo" fallout. [15:39] heh [15:39] jcsackett: this is making the changes button work. That was after the sprint stuff [15:39] rick_h__, jcsackett: fine thanks [15:39] rick_h__: we've touched it since then, but i remember hitting the two paths before that. [15:39] rick_h__, jcsackett: refactoring that is a separate task [15:40] rick_h__: in any event, while there are some differences, you can probably extract that into something more common. [15:40] frankban: +1, it can def wait. [15:46] ok I just found this....live stream..... wowzers http://www.nasa.gov/multimedia/nasatv/index.html [15:46] man, I want to chromecast that fullscreen [15:47] right??!?!?! [15:49] * rogpeppe pulls the $$merge$$ trigger on https://github.com/juju/juju/pull/253 [15:49] fingers crossed [15:50] kadams54: ping me when you've got a PR up for your card. [15:50] hatch: cool! [15:50] Yup, writing up QA instructions right now. FYI, it'll require a real env. [15:50] rick_h__ people these days just don't seem to understand the amazeballsness of this stuff :) [15:52] frankban, hatch: y'all still dicussing the ecs/deployer issue? fwiw looking at frankban's PR i dig the approach, but i can see where it trips us up. i would like us to move in that direction though. [15:52] jcsackett sorry we already did [15:52] ended up with a good way forward [15:53] hatch: oh, i didn't want to be in the meeting, i just want to know the outcome. :p [15:53] oh ok then in that case... [15:53] when the deployer bar gets opened to list the tasks it will query the db when required for the real values instead of extracting them from the ecs [15:53] that way it doesn't actually have to listen to the db for changes [15:53] woot! phone upgrades ftw. 4.4.4 finally [15:53] jcsackett: good to know, we will follow that approach, I will just add a commit to that branch to also handle the deployer panel [15:53] and we aren't live updating the dom anyways [15:54] hatch: so you are going to tackle that for your branch then? [15:54] rick_h__ nice - on the Moto? [15:54] jcsackett no frankban will add it to his [15:54] hatch: yea, dev edition [15:54] nice [15:54] hatch: ah, ok. i'll take a look at frankban's PR when that commit hits then. [15:54] I'm not sure what I'm on (goes to grab phone) [15:54] well, take another look. [15:54] jcsackett: thanks, appreciated [15:55] dammit, i missed my window of opportunity. juju-core is blocked again. [15:55] 4.4.2 here :) on the HTC One m7 retail edition :) [15:55] rogpeppe: saw that :( [15:56] how does it get blocked? [15:56] fialing CI? [15:56] hatch: yea [15:56] when you're big enough that stuff has to be landable before a CI run can complete. [15:57] may we never get that big :) [15:58] haha - their CI runs must take a while [16:00] rick_h__: +1 [16:02] rogpeppe: if you get some break time could you do us a favor as a juju-core friendly person? We need to generate the list/chart of containers that are valid for different machines/environments. [16:02] rogpeppe: what does juju allow? Does it even know the rules? I know AMZ can only have an LXC, for instance. And an LXC (local) I think can only have a KVM, etc [16:03] rick_h__: jeeze, i have little idea. last i looked, the only place containers worked reliably was on maas (and perhaps openstack) [16:03] rick_h__: does networking now work between containers on ec2? [16:04] rick_h__: i know there's been lots of work in that direction, but i don't know what the current status is [16:04] rogpeppe: understood. I believe lxc containers should work. I know there was work for nested lxc on local. There's an email thread around that going on currently. [16:04] rogpeppe: right, I assumed at some point juju would say yes/no when a request was made that the rules would be encoded there in core. [16:04] rogpeppe: and you'd be best able to know where that might lie [16:04] rick_h__: it's a rats' nest [16:05] rogpeppe: oh yay [16:06] rick_h__: i'm not even sure it forbids you from starting containers that may not work [16:06] rick_h__: thumper's the man to speak to about this stuff [16:06] rogpeppe: ok, my sadness levels are increasing. [16:07] rogpeppe: ok, will do. I'll add a card and will see what we can figure out. Thanks [16:17] rick_h__: where should we create cards that are dependent on ditching the mv flag? that whole updated unit count thing we discussed can't be done until we can rip out all the old scaling stuff, which won't happen until mv is gone. [16:17] * frankban bbiab [16:18] is that on deck, or further off? [16:19] frankban I updated your card on the board and deleted mine [16:21] jcsackett: sorry, was looking elsewhere. What unit count thing? [16:22] jujugui I still need one more review for https://github.com/juju/juju-gui/pull/465 [16:23] rick_h__: maybe i didn't talk with you about this, just hatch. once we only have the new scale out there's a bunch of unit count handling we don't need to do anymore; i was starting in on killing it in the branch i just put up for review, and then realized it screwed up the w/o MV path. [16:24] basically: should refactors that depend on MV flag being gone go in on deck, or pool? that's the question. :p [16:24] jcsackett: I've been moving them to on deck [16:24] rick_h__: awesome, thanks. [16:24] jcsackett: but you're right, they're post-release cleanup cards [16:24] * jcsackett is excited to have that refactor done. [16:30] jcsackett you forgot to run lint again [16:31] :P [16:35] i have a pre push hook that keeps telling me it's ok. [16:35] but it seems to not run, or something. [16:36] sure takes a long damn time for not running anything. [16:36] lol [16:36] jcsackett review done, I added a couple comments, I'll hold off on QA until you take a look [16:38] hatch: responded. [16:43] jcsackett annnnd replied [16:43] :) [16:45] *grumble grumble grumble* I think the cs is doing an ingestion again [16:47] rick_h__, I got two +1s from rogpeppe and jrwren on jujusvg. Since we don't have CI hooked up, is that just a plain click-the-green-button merge, then? [16:47] Just making sure I've got the process down [16:47] Makyo: i'd say so [16:48] Makyo: i'm guessing you made the changes i suggested? [16:48] rogpeppe, yeah, and pushed. Thanks for the suggestions - much simpler now. [16:48] Makyo: cool, thanks. [16:50] listening to some stuff I hadn't listend to in years. man, the start of mahler 1, 4th movement is quite something. [16:50] Mahler's dreamy~ [16:51] Makyo: my grandmum gave me a tape of it when i was about 9; i don't think i've listened to it since the tape wore out about 10 years later :-) [16:52] Makyo: i recently threw out a large box of tapes, but not before i made a copy of them all as a Spotify playlist... [16:52] rogpeppe, yeah! I did that with a bunch of CDs a while back (though some I had to buy off iTunes or the like if they weren't on spotify) [16:53] hatch: so we can move it into addUnits, but we're going to have to call it once for every unit that's added, b/c it requires the service and there's no guarantee that we're adding units of just one service. [16:53] which seems like a lot of churn. [16:53] dont' we have to do that anyways now that we are manually updating the unit_count? [16:55] hatch: no, we can do a bunch of addUnit ops and then sync once per service. [16:55] hmm [16:55] hatch: but nevermind, given we're going to kill this as soon as remove the mv flag i think it's temporarily fine. [16:55] what I'm trying to avoid is the introduction of bugs because someone forgot to call some obscure method in another part of the app [16:56] hatch: yeah. [16:56] we run it for every call of onDelta--clearly it can't be hurting us that much. [16:56] good point [16:56] jcsackett: https://github.com/juju/juju-gui/pull/471 ready for QA and review. [16:57] hatch: of course now a ton of tests crap their pants. [16:57] hatch: i'll continue pursuing this after i review kadams54 branch. [16:58] jcsackett heh you should be able to just stub it out [16:58] hatch: yes. in like 90 places. [16:58] a *lot* of things deal with addUnits. :p [16:58] hmm, and you're saying that we will be removing this call in the near future? [16:59] hatch: ideally, but i can't guarantee a timeline. [17:00] i think you're right about moving it so we don't have a landmine for someone else. [17:00] and once we dig into this to remove it we may only be removing part of it. [17:00] kadams54: lint. [17:00] alright sounds good [17:00] jcsackett: yeah, fixing :-( [17:02] I don't know Mahler's 1st. I only know 5th, 9th, and 10th. 1st is good eh? [17:06] kadams54: so, machineData.id is how we know if the machine has a service? [17:06] the check seems a little obtuse to me, as it's written. [17:07] I would switch it around… machineData.id is how we know if a service has a machine associated with it. [17:07] kadams54: no, it's fine, just making sure i understood. [17:07] obtuse to me doesn't always imply wrong. :p [17:07] And yes, that's why the check has comments above it :-) [17:11] kadams54: updating my live env to check yours QA could take a bit. [17:11] in the meantime, juju-gui, https://github.com/juju/juju-gui/pull/471 needs a second review. [17:11] er, jujugui ^ [17:12] Makyo: +1, just make sure that tests pass before hitting that button please [17:14] yay, meeting break. /me goes to get lunchables [17:53] kadams54: my local environment completely fubarred itself (nothing to do with your code) [17:53] i'm having to start up a new one, so further delays on QA. [17:54] jcsackett: While I'm relieved that my changes didn't do it, sorry this QA is so painful. [17:55] kadams54: i always have *really* bad luck setting the source for the gui charm. [17:55] i'd say there's a 1 in 3 chance it'll crap out and never recover for me. [17:56] guihelp: anyone know why juju websocket requests aren't showing up in Chrome's dev tools (Network tab, websocket filter enabled) for me? [17:57] kadams54: reload the page? The network tab must be open at the start of the page load to get them [17:57] kadams54 quit using Canary? [17:57] sorry - had to [17:57] hatch: Hah! THe latest and greatest web dev tools is *why* I use Canary :-) [17:57] +1 [17:57] hatch: :P [17:58] rick_h__: I think that's likely the problem, thanks. [18:00] jrwren: 1st is awesome. [18:01] jrwren: but i might be biased 'cos it was the first i ever heard [18:02] Melborn, Sydney or BBC ? [18:03] kadams54: call? [18:03] rick_h__: ah yes, sorry, be right there in a minute [18:11] bac, jrwren, urulama: https://github.com/juju/charmstore/pull/50 [18:11] rick_h__: FYI i now have goahead on the charm.v3 changes. [18:11] rick_h__: will push tomorrow [18:12] g'night all [18:12] rogpeppe: good night [18:12] rogpeppe: excellent news on v3! [18:12] rogpeppe: c u tomorrow [18:12] urulama: yup [18:12]