=== jcsackett_ is now known as jcsackett [12:04] hi everyone [12:05] * gary_poster does not look forward to inbox [12:05] hi gary_poster [12:06] hi :-) [12:12] we really do need to make a concerted effort to reduce the number of noise emails we get, it is not just annoying, it increases the chance that we'll miss something important [12:26] benji, friday card? [12:26] gary_poster: say again? [12:26] oh, the email thing [12:26] sure [12:27] yeah [12:27] thanks === rogpeppe1 is now known as rogpeppe [12:44] hey bac, should I review the "find an appropriate machine image" branch or wait for changes from Jeff's review? [12:44] gary_poster: i'm almost done answering. give me a few minutes. thanks for asking. [12:45] cool [12:56] gary_poster: done [13:06] gary_poster: our 1:1 conflicts with the uds session. i can do it most any other time today or tomorrow [13:07] ok bac, thanks. I will drag it somewhere or other, or you are welcome to if you look at my schedule also [13:07] i'll let you do it since you have more scheduled stuf [13:07] f [13:09] gary_poster: hi, thanks for the review! weekly call? [13:09] frankban, urgh, sorry :-) [13:09] joining [13:09] :-) [13:58] adeuring: So Launcpad's getBranchTips API works is that if the branch is promulgated, the series it is linked to are the last element of the tuple. So in "["~charmers/charms/precise/apache2-passenger/trunk", "jorge@ubuntu.com-20130422194721-qz44aua2wpkri90p", ["precise"]]" the final "precise" indicates that this is a promulgated branch. [13:58] abentley: ok, thanks === Makyo|out is now known as Makyo [14:14] bac thanks for those changes - just wondering if you are going to add the section on how to change the server image stuff in your new script to the docs [14:15] hatch: when approved, before landing, i'll update that section to deprecate it. [14:15] alrighty - I just didn't see a comment about it [14:15] lgtm'd [14:15] hatch: did you mention it and i didn't reply? if so, sorry. [14:16] sok, it happens :) [14:18] \o/, jenkins is happy again [14:18] yay! [14:18] thank you bac [14:18] thanks to frankban's branch i suspect [14:18] thank you frankban :-) [14:19] :-) [14:23] being that prod doesn't support 404's it makes it impossible to test the after-login-redirect on prod [14:31] ack decoratedRelation [14:31] oops [14:31] :) [14:32] bac, thank you for attending charm dev tooling. that may prove to be essential for us this cycle [14:32] I wanted to be there but not enough to come back to work :-) [14:32] did you learn anything of interest? [14:32] gary_poster: yes, but it is still a bit of a mess. it is not clear to me what the path is for reconciling the libraries [14:32] ok [14:33] We may want to lead some of this [14:33] That way we have what we want, at least in part [14:33] the two overlapping ones are charm-support and our stuff [14:33] right [14:33] If we port charm-support to use our stuff, assuming our tests are as good or better, we might get a good resolution [14:34] i think we need to work with matthew to decide how to merge them. i fear that existing code bases will make neither party interested in moving to the other [14:34] gary_poster: you mean make existing charm-support a wrapper? [14:34] I wonder if their charms are actually using host.py directly [14:34] well, the overlap is in host.py AIUI [14:34] if we make one package that is low-level utils (our stuff) [14:34] Makyo, are you around? [14:35] and convert the charm-support to use them [14:35] charm-support bits [14:35] then it may be easiest all around [14:35] hatch, Yes, what's up? [14:35] is anyone going to UDS Charm Testing in 30 minutes? [14:35] I want to propose that [14:35] I was supposed to bac, but I think I need to prepare for other things. jujugui, do we have any volunteers for Juju Charm Testing in 30 minutes? [14:36] gary_poster: yes [14:36] thanks frankban [14:36] gary_poster: I'll be there [14:36] thanks teknico [14:36] Makyo, in my new login branch (the one that fixes the url issue) there is an error being thrown in views.DecoratedRelation (Cannot read property 'modelId' of undefined ) [14:37] this only happens on prod build [14:37] frankban, teknico: tips: be sure to set up "lower third" banner in G+ with the color, logo, and your title. if you don't they'll ask you to [14:37] gary_poster: is the web page enough, or do we use hangout to attend? [14:37] so I see that modelId is trying to be accessed on a service which is undefined [14:37] bac: unfortunately the toolbox is not working for me :-/ [14:37] and that is called on 'update' [14:37] frankban, teknico: also you've got to go to the hangout not just the session page if you want to participate [14:37] but what causes it to update? [14:37] bac, they need to ask Antonio for that url, right? [14:37] I am thinking that it's updating before the deltas are in? [14:37] bac: right, where's the hangout url? [14:37] the hangout url I mean [14:38] hatch, no clue. I can't really switch right now. Maybe check with bcsaller ? [14:38] gary_poster, teknico: ask someone to paste it to IRC or the etherpad [14:38] Makyo, ok np, just figured bcuz d3 :) [14:38] teknico, frankban I suggest asking arosales out of band beforehand [14:38] hatch, that's not d3, that's topology. Probably fired by db update, but yeah, can't quite check right now. [14:38] bcsaller: good morning :-) [14:38] Makyo, hatch bcsaller is out for rest of week at Google I/O. Doesn't mean Makyo should drop everything, but just to be aware [14:39] gary_poster, ah, thanks [14:39] oh right I forgot that he was there [14:39] I'm here for a few minutes now [14:39] hi bcsaller. Did you get google glasses? :-) [14:39] ok real quick :) what causes update to fire on the relation topology code [14:39] * arosales reading back scroll . . . [14:39] he got a Pixel....lucky!! [14:39] gary_poster: pixel chromebook [14:39] ah, cool@! [14:40] sorry arosales. could you give frankban and teknico hangout url for charm testing please? [14:40] trying to get Ubuntu on it before I head back [14:40] I'll take it off your hands if you don't like it [14:40] no problem....I'll take the burden [14:40] heh [14:40] gary_poster, will do. [14:41] I'll post it into #ubuntu-uds-servercloud-2 irc room too [14:41] :) [14:41] gary_poster, frankban teknico hatch ^ [14:41] so bcsaller do you know - off the top of your head - what causes the relation update code? [14:41] cool thanks a lot arosales [14:41] arosales: thanks, I'm there already [14:41] I create a new hangout URL about 5-10 minutes before each one starts. [14:42] hatch: db update triggers topo.update which will call it for the relation module [14:42] Google + On air requires a new hangout for each session. [14:43] ok so if service is undefined during the update that would mean that the deltas haven't fully come in yet? [14:45] hatch: its possible it could be trying to resolve the charm still [14:46] bcsaller, alright - thanks just wanted some insight as to what the sequence was here before debugging because it only happens on prod so it's a little difficult to debug [14:46] well...only on prod and only on initial login [14:46] jujugui, I'm trying to land a branch (bcsaller's one) and the lbox check fails horribly, has anyone seen this? http://pastebin.ubuntu.com/5670997/ [14:47] not I [14:47] I couldn't have even proposed it with that [14:47] nope [14:49] bcsaller: how do you mean? [14:49] I mean to propose make check had to run here, so I didn't get that [14:50] bcsaller, thanks - I was able to resolve right away with that little bit of insight :) [14:51] so because prod doesn't support extra paths does orange not test on prod? [14:51] bcsaller: yeah, that's the output of "make check" [14:51] ^ sinzui (just curious because I want to make sure this all works before proposing) [14:52] bcsaller, so how is IO? I was able to catch a couple talks in the background but I am sure there are a lot more on the ground [14:53] hatch: its been alright, some useful tips from the chome side of the house relatated to avoiding repaints and tracking leaks [14:54] I think I heard that one....the redbox one with the slide out left panel? [14:54] hatch: yes [14:54] yeah some pretty cool stuff there that can probably help us out [14:54] going to be an android/java dev by the time you come back? [14:54] yeah, I was watching the redraws on the gui, we can do better [14:55] hatch: android studio is a big improvement [14:55] I was reading about that last night - really going to help adoption I think using a 'real' ide [14:55] not that eclipse isn't a real ide.... ;) [14:57] gary_poster, were you able to find a workaround to pipe diffs to sublime? [14:57] * hatch has been working in Ubuntu [14:57] hatch, no, not on linux. I write to file :-/ . frankban and teknico also use it; maybe they have a better answer? [14:59] hatch: I write to file too [14:59] this is unacceptable!! one of you pythonites should write a patch ;) [14:59] hatch, tried qdiff? [15:00] or meld [15:00] Meld's good too. [15:00] I haven't even heard of them :) I'll take a look, on OSX I could just pipe to sublime so it was never an issue [15:00] thanks I'll look into those [15:00] bzr qdiff (or you might not find it) [15:01] sudo apt-get install qbzr [15:01] qdiff is in apt [15:01] meld is standalone and for when you want to do something with the files relative to the diff, qdiff is more for review [15:01] doesn't qbzr make it like git? shared folders and the like? [15:01] hatch, that's cobzr [15:01] oh ok [15:02] hatch, qbzr is just a Qt wrapper around a bunch of bzr commands. [15:02] gotcha - installing [15:03] I'll give meld a go too [15:04] bcsaller, so are there more talks than the 5 in each block that are listed online? [15:04] yeah [15:04] I thought so [15:05] else those would be some full rooms :) [15:05] either way, they are [15:06] can I pipe a diff to meld? or do I have to use the GUI? [15:07] help file only shows via the gui [15:08] gary_poster: Hi Gary, are you available for a quick catch up with Ale and me? [15:08] hatch: not sure what you want to pipe, what would you normally use? [15:09] hatch, Orange does run "make test-prod" though individuals may may mistakes from time to time. [15:09] on osx I `bzr diff | sub` [15:09] sure luca. http://tinyurl.com/guichat (it is free and I am there now) or somewhere else? [15:09] gary_poster: sure [15:09] cool [15:09] sinzui, ok that's what I meant - they don't go into the browser and test it on prod....I was wondering it there was a way to make it appear without changing the url [15:09] hatch, when I review, I pull the branch and run the tests myself to be sure tests run in several scenarios. [15:10] hatch, I hope that tarmac will provide some assurances that I forgetful developers are reminded before anything can merge [15:11] :) I just wanted to make sure that there wasn't some secret way to test the browser on prod in the browser before I propose :) [15:11] hatch, I don't know of a better way than exploring the site during development and review at this time. :( [15:11] yeah that's fine - just thought I'd check before assuming [15:11] hatch, this is also why I am slow when doing gui reviews [15:12] because assuming makes an ass out of u ming [15:12] wait that's not right... [15:12] haha [15:12] :P [15:13] I think there is a card to get prod working to redirect 404's to root but until then.... :-) [15:28] gary_poster, I am also checking with the orange team but would any folks here be interested in joining the Charm Store feeback loops session at the top of the hour? [15:28] http://summit.ubuntu.com/uds-1305/meeting/21694/servercloud-s-juju-charmstore-feedback-loops/ [15:37] jujugui when you have a chance could I get a QA and review on https://codereview.appspot.com/9445043/ thanks [15:39] hatch: will do [15:40] thanks sir [15:40] arosales, sorry was on call. jujugui can anyone join the session arosales mentioned in 20 minutes? I would suggest that whoever joins think about bundles and whether they fit into the discussion in an interesting way. [15:41] this would be in lieu of our daily call for whoever joins [15:41] so only one volunteer would be good. :-) [15:42] gary_poster, thanks. I haven't gotten any volunteers from orange atm, but I think a few of them are out this week. [15:42] arosales, yeah I know rock and jc are, who would be the most obvious choices afaik [15:42] rick [15:44] bac, your post on bzr went missing. Is that still written down somewhere? [15:44] Makyo: the alias for pulltrunk? [15:44] Yeah [15:44] shoot [15:45] Makyo: bzr alias pulltrunk="pull -d :parent" [15:45] benji, can you find the link for statsd emitter implementations in different languages? I see different servers but not emitters [15:45] sure [15:45] I know I'd seen it before though [15:45] thank you [15:46] gary_poster: https://github.com/etsy/statsd/wiki#client-implementations [15:46] cool thanks benji! [15:46] np [15:46] bac, thanks [15:47] bac, oh, looks like it was a draft post that was only showing up when I was logged in. [15:47] hatch when you are wondering what to do next, lemme know please :-) [15:47] Makyo: it should be published now [15:47] Makyo: i thought i had [15:47] bac, cool, thanks! [15:48] the wp interface is a holy mess. [15:48] Yes. Yes. [15:48] gary_poster, shoot - I'm just reviewing my last branch [15:48] bac, It's a little clearer if you're running your own copy, but only a little. [15:48] hatch, :-) k [15:48] Makyo: well the multiple editor views kills me [15:48] hatch, let's do it after call [15:49] sounds good [15:49] bac: there's a "the" and an "interface" too many ;-) [15:49] bac, yeah, true. [15:52] jujugui call in 8. please update kanban [15:55] benji are you fairly confident that the "last value" of each statsd metric will be sufficient for the metadata display we want? or is there some interaction between values over time that we need to worry about? I read about it this weekend but was not clear and have not taken the time to improve my understanding [15:57] gary_poster: I belive that for some of the stats types (guage for sure, maybe others, my memory needs to be refreshed) the last value is all we will need to display a good value; I am pretty sure there is at least one other type that we will have to track over time in order to display something meaningful [15:58] perhaps a card for someone to research and cogitate on the topic would be good (I'll volunteer if I can get out from under this memory leak) [15:58] jujugui call in 2 [15:59] sinzui, are you able to go to vUDS charmstore thing or should I delegate someone so we have at least someone there? [15:59] Oh, bugger. I forgot. [15:59] Yes I want to attend [15:59] thank you gary_poster [16:00] ok thanks sinzui. arosales I didn't have any volunteers, and sinzui will be there. I'll see if anyone else can join late. [16:00] sinzui, thanks [16:00] bac ping to join guichat [16:00] as long as there is one rep that is good [16:01] cool thanks arosales [16:02] sinzui, https://plus.google.com/hangouts/_/0668cba98347aa731901ad12783d4ba70dd1bebe?authuser=0&hl=en [16:35] hatch: doing QA for you. when using devel/rapi what is the login password? [16:37] after landing my jenkins-fixing branch, jenkins died. a retry and it is back to normal. hope i didn't introduce fragility. [16:37] weird stuff installed in /usr/local, bah. cleaned it all up [16:37] bac, admin [16:37] hatch: admin no worky [16:37] it says the pw is incorrect? [16:38] gary_poster: still good to land bcsaller's branch? [16:38] teknico, yes [16:38] hatch: if i hit localhost:8888 and then logout, enter 'admin' as password it says it is incorrect *and* the canvas background goes dark [16:38] let me try it locally [16:38] hatch: and when that happens the password entry box is no longer selectable [16:39] hatch: and the url goes from localhost:8888/login/ to localhost:8888/logout/ [16:40] hatch: given that bit of bad QA i think i'll excuse myself for lunch if that's ok. i'll look at it again as soon as i return. ok with you? (it is fried chicken day at fattie's and she runs out fast!) [16:42] bac, hmm I think you have a bad merge [16:42] there is no more /logout/ paths [16:42] hmm [16:42] I'm just trying now [16:43] yeah I am unable to reproduce [16:46] did you merge into trunk or just check out the branch? [16:48] hatch: i have a fresh trunk then merged your branch [16:48] hatch: i've tried against sandbox and rapi. against rapi i get the same behavior except for the redirect to /logout [16:48] hatch: the merge shows 180 changed lines, just like your MP [16:50] hmm try just checking out the branch [16:50] I'll try merging trunk here [16:50] see if i can repro [16:51] oh bac index.html has been edited [16:51] you might need appcache-force [16:52] the logout button is now a div not a link [16:53] so I wonder if that might be the issue [16:53] ahhh [16:53] hatch: appcache-force did not help. neither did clearing browser data. [16:53] hatch: if i shelve your changes all works [16:53] ok something is broken with trunk here [16:54] trunk wfm [16:54] my trunk index.html has the logout link as an but on launchpad its a div [16:55] i see an [16:55] yeah that's wrong [16:55] see http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/view/head:/app/index.html#L102 [16:55] so something is broken there [16:55] and here for that matter [16:55] * hatch deletes his trunk dir [16:57] there we go [16:57] bac, delete your trunk dir and then re-checkout trunk [16:58] hatch: nothing was wrong with my trunk [16:59] i cleared my browser, make clean; make appcache-force; make devel and then it worked [16:59] you said it had an for a logout link [16:59] ohh ok [16:59] hatch: nope, my browser element did [16:59] sorry sorry [16:59] anyway it seems to work now [16:59] glad we wont' have to deal with appcache anymore after Makyo s branch lands [16:59] :) [17:00] indeed [17:00] appcache has so much potential but it's implementation is just wako [17:04] hatch: QA is fine. LGTM with some changes [17:04] * benji runs a sandbox (with simulateEvents on) to check for memory leaks over lunch. [17:04] * bac lunches [17:04] thanks bac! [17:10] sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/related-charms/+merge/164223? [17:11] * sinzui does [17:11] anyone else available for a QA and review on https://codereview.appspot.com/9445043/ ? [17:41] gary_poster, fyi jcastro will have the hangout link for the Juju Gui session coming up. [17:42] ack thanks arosales [18:03] jujugui join #ubuntu-uds-servercloud-2 and https://plus.google.com/hangouts/_/041beb28b529693593663161927dfd82747426c9?authuser=0&hl=en pls :-) [18:05] jujugui also suggest opening http://pad.ubuntu.com/uds-1305-juju-gui-development rather than summit page [18:12] if you need the ubuntu logo, look here: http://design.ubuntu.com/wp-content/uploads/logo-ubuntu_cof-orange-hex.png [18:36] if anyone has a graph of my use of the word "um" per minute they can keep it to themselves ;-) [18:36] we should start a vUDS award for best background; that could get interesting [18:36] :-) [18:36] -----/\--______----^-- [18:36] heh [18:37] actually I was just thinking about how well you do at impromptu public speaking [18:37] heh, thanks. I do better when I'm not rushing from one thing to the next, I think :-) [18:38] bac, actually, do you have a few minutes for guichat? [18:38] gary_poster: yep [18:38] thanks [18:46] anyone available for a review/qa on https://codereview.appspot.com/9445043/ ? [18:46] hi abentley. I have a question about the behaviour of related charms [18:51] abentley, It seems possible (because a test does not show it is not) that a charm could be listed among it's related charms. Eg apache requires and provides http, and I think its popularity would guarantee it to be listed among the other related charms. Except that is is not an "other" charm. Are we concerned about this? [18:52] hatch, sure [18:52] thanks Makyo [18:53] sinzui: Yes, I would expect Apache to be "related" to itself. [18:53] sinzui: I think it's an imperfect user experience, but I decided not to worry about it. [18:54] sinzui: One issue is that there are a bunch of Apache charms, so blacklisting just the current charm doesn't reduce the problem significantly. [18:54] sinzui: Maybe we should blacklist all charms with the same charm name (i.e. "apache2"). What do you think? [18:55] I think Identical name would make sense. [18:55] sinzui: Okay. Do you want that in this branch or a followup? [18:55] abentley, We could treat this as a follow up issuse. [18:55] okay, we agree, r=me [18:58] sinzui: Do you think we should reduce the weight of charms with differing distroseries? Technically, such charms can be used together, but I think people prefer to use the same series where possible. [18:58] Good point. [18:59] thanks Makyo ! [18:59] hatch, reply was missing an 'a', so here you go: aaaaaaaaaaaaaaaaaaaaaaaa [18:59] * hatch takes those a's to keep for later [19:01] Just in case. [19:01] abentley, is it possible for a oneiric charm to match? I think I would like m_3 or jcastro to say the GUI/browser should not be showing charms for obsolete series...meaning stop indexing them too. [19:03] sinzui: +1 on disabling indexing for unsupported series... maybe with a round of pings to maintainers if no more recent versions of charms exist [19:04] m_3, yes, that is one of my concerns. maybe manage.jujucharms.com should continue to show them so that maintainer can see the last know reports about them [19:04] sinzui: Yes, it's possible for oneiric charms to match, just as they would for another search. We'd have to delete them from the index for them to stop showing up. Or maybe we should mark them as obsolete and penalize the scores of obsolete series charms. [19:06] My thoughts about preserving reports are flawed. Juju and charm proof are changing. A great charm for oneiric might be a bad charm for precise. [19:07] sinzui: Don't we auto-clone the branches when we create a new Ubuntu series? Should we do that here? [19:07] abentley, I'd like to stop ingesting them. I think preventing them appearing in the GUI is good, but I think I still want m.jc to let me see the obsolete series charms. Ubuntu on Lp lets me do that. [19:09] sinzui: The motivation for stopping ingestion is because they are unmaintained and won't stand up to newer versions of proof, etc? [19:09] abentley, I think we stopped. after the first try. m_3 might know the reason? Maybe it was because cloning branches when creating a new series confuses user. Precise is still the series we want users developing for. [19:10] abentley, right. Why fix/update charms for series we don't want people to deploy? [19:12] sinzui: My reason to keep ingesting them is the behaviour of ingest changes periodically. For example, I'm working on a branch to stick icon.svg in gridfs. If we don't ingest the charms, they won't get updated, and we [19:12] will have worse compatibility problems than we do now. [19:12] benji, did you see i found a known issue with python-requests and https proxy? bummer. [19:12] sinzui: We could handle some of those cases with migrations. [19:12] bac: no I handn't seen that; bummer indeed [19:14] sinzui: But in other cases, we'll start ingesting new data, so re-ingesting the charm seems like the only viable way to update the mongodb/es representation. [19:14] bac: The one I filed? [19:15] abentley, possibly. Since the tools are changing, but oneiric is not, the situation is a conundrum. I don't think we will be backporting charm-tools to oneiric for authors to run. The charms were held to a difference standard. [19:15] abentley: no, this one [19:15] https://github.com/kennethreitz/requests/issues/905 [19:22] sinzui: The related charms for Apache are kind of absurd anyway. "Oh you [19:22] 're interested in apache? Have you considered deploying WordPress, openerp or juju-gui?" [19:25] gary_poster, would you like me to create tickets for this parent/child view stuff? [19:30] hatch just made it in story 1 [19:30] oh ok thanks [19:53] sinzui: When you get a chance, could you please review https://code.launchpad.net/~abentley/charmworld/reindex-failure/+merge/164254 ? It's remarkably short. [19:54] They're replacing our power meter, will drop in a few. [19:54] Makyo, using too much power? [19:55] turn off the bitcoin mining machines! ;) [19:55] Nah, upgrading to the smart meters. Which is good, the one we have currently is awful. [19:55] mine is a spinning aluminum disk [19:55] pretty sure it's not 'smart' :) [19:56] Hah, yeah, ours is too. We had one of the 110v legs go out, though, which damaged our stoves and one of my RAID disks, so it's desperately needed. [19:56] ahhh that's no good [19:57] It was a little funny, because power would only run in the house if we turned on a burner on the stove. [19:57] And by funny, I mean dangerous. [19:57] lol [19:58] "what you doing?" "oh just boiling water to watch tv" "???" [19:58] Haha [20:01] abentley, looking now [20:02] abentley, and I just approved it. Thank you. [20:02] sinzui: Thanks. [20:45] gary_poster: are you getting canonicaladmin alerts now? === BradCrittenden is now known as bac [20:49] sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/icon-as-file/+merge/164262 ? [20:54] where did FileSaver.js come from? it needs to be added to our 'do not lint or fix list'. [20:54] * bac does same [20:56] bzr st [20:58] * sinzui does [21:01] abentley, r=me. I'll let you approve the merge itself [21:02] sinzui: Thanks. [21:03] Dogwlk [21:03] hatch, can I borrow one of those 'a's? I seem to be having problems. [21:03] oh hey yeah sure np [21:03] * hatch hands an a [21:05] \o/ [21:07] anyone up for a code review? https://codereview.appspot.com/9449044 it is my unbouncing of the textarea inputs branch. will need QA to appreciate the fix. [21:08] * bac -> dog2fort [21:15] bac, yes? though if you just sent me one I didn't get it [21:36] hey sinzui, you around? [21:36] I am [21:37] hey sinzui. I'd like to mark bug 1178462 as high for GUI while not marking it high for you all. Basically, we have committed to delivering it for 13.10 [21:37] <_mup_> Bug #1178462: Can't drag a charm from the charm browser sidebar to the main canvas

[21:37] but I don't want you to have a record that you need to implement it [21:38] any ideas? [21:38] move it to high and remove your tag seems like the right thing to me [21:38] gary_poster, I'm not against it. I think I originally set it medium because I understood it to be a new requirement. [21:39] cool sinzui. would it help you if I removed the tag, or don't bother? [21:39] I move a number of bugs to medium a couple of weeks ago to distinguish between what we want to do this month verses next month [21:40] yeah, remove the tag since we can have it hgh [21:40] sone. thanks sinzui. [21:40] done I mean [21:40] fab, Thank you for raise this to my attention [21:41] np [21:42] oh sinzui, not being able to turn the left hand charm browser on will become a blocker for us next week. I think we are only waiting on speed and reliability of manage.jujucharms.com. Do you know yet when that will be ready? [21:43] I think it will. [21:43] We just need to complete the svg change [22:54] jujugui: i cannot use google hangouts (via the new icon) with my canonical account. it hasn't been enabled. has anyone else seen this regression?