[04:30] huwshimi hey [04:33] hatch: Hey [04:33] thanks for the comment [04:35] unfortunately that means I have to re-write a bunch of stuff...lol [04:35] but it's a lot nicer approach [04:35] hatch: No problems. We seem to be heading in the direction of using these state classes for all our "widgets" that have multiple states. I figure it'd be good to stay consistent. [04:35] hatch: Yeah, I know it's a bit of a pain [04:36] so, the idea then is that any time there is a state change in the UI we wlll add a new class and appropriate nested stuff [04:37] that was a question [04:37] :) [04:38] hatch: Well, swap out the state class, but yeah, I think this approach would work [04:39] ok cool [04:40] hatch: I'm pretty sure it was your idea :) [04:40] lol this last little while has been nuts [04:40] yay me? [04:40] nah, yay you! [04:41] so my comment https://github.com/juju/juju-gui/pull/424 is because objects keys aren't in any order [04:41] so just because you add two things in a row in an object doesn't mean they will be in that order [04:42] it's likely that they will be in order but there is no guarantee [04:42] only arrays are guaranteed to be in order [04:42] hatch: Yeah, but if we build this list in the dom based on the list of keys and then grab the first key to select the first item it seems to maintain the order [04:43] it does, but it's not guaranteed [04:44] you can make two loops through an object's keys and get them in two different orders [04:44] if we only have it in that format then it's the way it's got to be [04:45] hatch: Yeah, I get that, I guess the other way to do it would be to grab the id off the first token in the dom [04:45] well...what do you think? [04:46] is there any real issue in selecting one that's not the first? [04:46] hatch: Only that it would be weird to have a machine that is not at the top of the list selected by default [04:47] well I'll leave it up to you :) [04:47] hatch: I can grab it from the dom, that would always do the right thing. [04:48] ok cool [04:56] hatch: I called out the state classes when I landed my branch, but I'll try make sure it's clearer next time so the person picking up the work can see them. [04:57] cool [05:10] huwshimi ok I'm taking off, have a good night [05:11] hatch: Night! === uru-afk is now known as urulama === rogpeppe2 is now known as rogpeppe [08:33] frankban: up for continuing? [08:34] rogpeppe: morning, sure! [08:34] frankban: i'm in the standup === rogpeppe is now known as rogpeppe1 === urulama is now known as uru-brunch === uru-brunch is now known as urulama [10:20] frankban: back [11:11] morning party people [11:14] frankban: if you get a sec can I get the low down on the reproduction steps for the bug in quickstart you guys fixed against 1.20? We're working on trying to figure out some sort of CI [11:15] frankban: and curious why we didn't hit that bug in normal use of quickstart against dev releases [11:15] rick_h__: welcome back [11:15] rick_h__: `chat? I am in the daily hangout [11:15] frankban: help, tie me down before I run away! [11:15] frankban: sure thing [11:24] * frankban lunches [11:31] rogpeppe: frankban email forwarded to peeps from carla about bundle details per the call last week with bac and I and UX. [11:32] rick_h__: thanks [11:32] rogpeppe: frankban just as an fyi on some data UX needs for bundles eventually in case any of it fits current WIP. [12:04] rogpeppe: bac frankban make sure to check out https://github.com/juju/juju/pull/250 and provide any feedback we have on the style guide. [12:05] if approved and landed it's something we should be aware of and pick up I think. [12:08] rick_h__: where should i put the card for bug 1339005 ... maintenance/review? [12:08] urulama: looking [12:08] urulama: ok, so just file it and I'll traige and add a card. [12:09] urulama: I'll add it to the on deck backlog for maintenacne [12:09] maintence [12:09] bah [12:09] urulama: we only use high and low importances. If it's high, we should try to fix it, if it's low, we ack it but don't promise to get to it any time soon (really ever) [12:11] urulama: when you get time let's catch up [12:11] jrwren: same ^ [12:11] morning [12:12] morning bac, made it to NC safely? [12:13] rick_h__: i'm gonna pick up my kids in 45min, change location. is 10AM ok for you? [12:14] urulama: party [12:14] urulama: I mean yes :) === urulama is now known as uru-afk [12:21] rick_h__: eventually. our original flight went through with no problems on friday but i'm still glad we postponed. the thought of getting stuck in ATL was unpleasant. [12:21] bac: hah, not a fan of our great south? :P [12:23] rick_h__: not a fan of sleeping in any airport [12:23] bac: good call === uru-afk is now known as urulama [12:27] rogpeppe: I am back, please ping me when you are ready [12:27] frankban: will do. currently perusing rick_h__'s comments [12:29] rick_h__: thanks for the link/email [12:30] rick_h__: machine/unit counts can be easily calculated by clients IMHO, agree with you re: owner details, the current spec allows for easily adding customized API later [12:33] frankban: i'm in the hangout, BTW [12:39] frankban: yea, maybe I'm getting ahead of myself. I have this fear that those counts will be filter/selection criteria for searches [12:39] frankban: but they're not currently so you're right, for display purposes they can be client side calc'd [12:45] rick_h__: wanted you to be aware of bug 1316174 -- it affects users on precise trying to bootstrap local envs. it's a juju-core issue but affects quickstart [12:45] <_mup_> Bug #1316174: 'precise-updates/cloud-tools' is invalid for APT::Default-Release [12:47] bac: looking [12:47] did we loose the ability to hide subordinate relation lines? [12:48] looks like we draw in gray with the little box to the side of the sub service, we used to be able to click the box and hide the sub rel lines, but it hasn't seem to worked in a while. [12:48] hazmat: yes, we're supposed to be getting to controlling it with the deployed service inspector [12:48] hazmat: is the box still there? /me goes to try it out, been a while. [12:48] rick_h__, yes its still there [12:49] hazmat: what UI box is there to hide then? [12:49] them? [12:50] bac: :/ ok. Will make sure it's brought up. [12:51] frankban: rogpeppe is there a card on the board for the current WIP? [12:51] rick_h__: no, I'll create one, thanks [12:51] frankban: ty much [12:53] rick_h__, off subordinate services there is a ... line to a subordinate count box, that box is supposed to toggle display of that's sub service's relation lines [12:54] hazmat: ah ok. checking existing bugs now. [12:55] rick_h__: you around in 10m? [12:55] jrwren: on a call but can ping when I get off [12:55] perfect [12:56] rick_h__, don't think there is one.. its been broken for a long time (at least 6months). [12:56] hazmat: right, I know we've talked a lot about showing/hiding lines including subordinates and we've got work this cycle to allow it with all services [12:57] hazmat: I'll file a bug and see if there's a quick fix, some code that's not getting run or if it's actually been removed [12:58] rick_h__, ok [12:58] hazmat: https://bugs.launchpad.net/juju-gui/+bug/1339029 [12:58] <_mup_> Bug #1339029: show/hide a subordinate relation line not functioning [12:58] hazmat: will ask mayko to take a peek at it and see if it's something we can hook back up easily [12:59] rick_h__, even if there's a long term thought on rel display, subordinates are a special case given their cross cutting concerns in an env, ie. is has 6-8 subordinate rels to every service. [12:59] rick_h__, cool, thanks [12:59] hazmat: the work to show/hide any rel line is scheduled late into the cycle so won't be updated soon. [12:59] hazmat: right, the idea is that you can show/hide the blocks and lines for any service in an environment [13:01] luca: add a call to the meeting? [13:01] rick_h__: forgot, doing it now [13:01] rick_h__: https://plus.google.com/hangouts/_/canonical.com/jaas-catch-up?authuser=1 [13:01] luca: ty much [13:02] jrwren: regarding the sprint in London - heard you're really close to rick_h__ (what's a 100km in usa ;)) , so, if calls would not suffice, you can probably just meet and get over details, so, don't worry about the sprint [13:03] * urulama needs to pick up the kids now [13:46] jrwren: ping [13:46] pong [13:46] jrwren: meet in the standup hangout? [13:46] yes [13:47] whoops, others are there [13:47] new room? [13:47] yep, getting invite together [13:47] https://plus.google.com/hangouts/_/g6xwjb53dpltyqiu66zdkmpnvma?authuser=1&hl=en [13:48] change the authuser part of the url to your own google accounts [13:51] hey, hatch__, i've pushed up all the work from yesterday we discussed. can you take a look? https://github.com/juju/juju-gui/pull/422 [13:51] you bet [13:51] odd I can't change my name to hatch [13:55] jcsackett you didn't address my comment in viewlet-manager.js [13:55] hatch__: ...actually i did. i don't know why that didn't get pushed up. [13:56] heh, welllllll push'r'up [13:56] hatch__: huh. it pushed up the change to service-inspector but not viewlet...weird. [13:56] hatch__: how goes, when you get a sec I'd like to meet up with you and kadams54 and get caught up on where we are with MV [13:57] it looks like half the cards are blocked and now following why and want to make sure we plot a path through that asap [13:57] rick_h__ sure, 20mins? [13:57] hatch__: k [13:58] rick_h__: ping [13:58] urulama: howdy [13:58] urulama: ready to chat? [13:58] rick_h__: sure [13:58] urulama: k, invite on the way [13:59] urulama: https://plus.google.com/hangouts/_/g5fbbzj56dl7cjvipytcasn5zma?authuser=1&hl=en [13:59] rick_h__: ok, tnx, see that the room is busy :D [14:03] hatch__: pushed. [14:11] jcsackett man git really did the diff odd with your branch heh === hatch__ is now known as hatch [14:12] hatch: yes. [14:12] i find git frequently does terrible things with diffs. [14:14] it tries super hard to keep old lines even if they don't make any sense in the context heh [14:14] "no you saved THIS curly bracket" lol [14:16] hatch: yeah. and it seems super easily thrown off by lines moved around. [14:17] "you deleted this line and and move that one...better mark the whole file as a conflict!" [14:21] rick_h__ I'm ready whenever you are [14:22] hatch: coolio, kadams54 available? [14:22] rick_h__: yup [14:22] kadams54: https://plus.google.com/hangouts/_/gsmrjulttdrhsdmyukjid7aenma?authuser=1&hl=en [14:35] hatch: saw your comment on retry; how would retry get the inspectors object? because it just sets up y.later, which only returns a timer. [14:37] jcsackett otp [14:40] luca: if you can file that bug with the roll overs I'll get huw to look at it tonight [14:40] rick_h__: awesome, I’ll do it now [14:44] rick_h__: https://bugs.launchpad.net/juju-gui/+bug/1339092 [14:44] <_mup_> Bug #1339092: Implement roll over and states for machine view tokens [14:45] luca: ty [14:47] jcsackett ok done, I'll look into HOW to do what I mentioned heh [14:47] it'll definitely require a bit of a refactoring [14:47] (reworking?) :) [14:47] hatch: yeah, Y.later doesn't even let you set a callback or something for the function, which is both odd and vexing. [14:48] hatch: i hope not much--this work has taken way too long to get through review already. :p [14:48] I added one other comment as well [14:48] hatch: if we don't find a simple way, then Y.later can just retry the dispatcher. [14:48] right, but wasn't that what you were trying to avoid in the first place? [14:49] hatch: well, it's what used to happen. this seemed better, but it sets up a problem. [14:49] hatch: so we can fall back to what used to happen, which wasn't broken. [14:50] jujugui call in 10, kanban please [14:52] jcsackett: hatch why a retry loop? is this for when we load the env for the first time and the data's not there yet from the env? [14:52] jcsackett the only 'simple' way is to call the inspector dispatcher again [14:52] rick_h__: right. [14:52] hatch: then i say that's what we do. [14:52] the other way is way to complicated and whtnot [14:52] jcsackett: can we not just tie up to the db events like we talked about before? [14:52] agreed [14:52] b/c i don't think spending much more time on this is valuable. [14:52] yeah I'm find with switching it back, it's a simple fix then [14:53] rick_h__: the comingsoon to azure card, is that something you'd like to do now? [14:53] rick_h__: as i recall, no, b/c the dispatcher doesn't wait on db. [14:53] bac: yes, if you care to take it. [14:53] jcsackett: right, but who cares about the dispatcher? [14:53] dispatcher don't wait for nobody! [14:54] rick_h__: this is all about dispatch. [14:54] rick_h__: i don't understand the second part of the description, but yeah. [14:54] we have to retry, b/c dispatch doesn't wait for db and throws a fit when it can't find the data it needs. [14:54] so we tell it to retry b/c the data will be there in a moment. [14:54] bac: ah, the second part was a question on do we just serve out the jenkins workspace as a 'comingsoon' but that could be bad [14:55] bac: the idea was that the -merge job would eaily update a local path and just serve out the gui [14:55] bac: vs a new machine [14:55] bac: meet in standup pre stand up and chat? [14:56] rick_h__: i just submitted an hr request for tomorrow as we discussed last week. [14:56] bac: rgr [14:59] jujugui call in 2 [15:00] kadams54: ^ [15:00] Joining [15:13] rick_h__: when you finish with calls: what's machine view :D [15:14] urulama http://comingsoon.jujucharms.com/machine/:flags:/mv/ [15:14] it show the actual juju machines and allows you to fiddle with the placement of units and whatnot [15:15] this is a new feature in the GUI and apparently.....a very long one to implement :) [15:15] hatch: tnx [15:21] urulama: yea, it's manual placement for the GUI [15:21] hatch: updated PR. [15:22] jcsackett thanks will look again [15:26] hey, there he is [15:26] Makyo: I removed you from that bug fyi [15:37] jrwren: responeded to the bug report, thanks for looking into that [15:38] jrwren: can you go ahead with the update to the CN and file a bug on the gui for the user help? [15:38] hatch: going to get food and then we can chat. [15:38] sure, is it fixable? [15:38] jrwren: is what fixable? [15:38] rick_h__ cool thanks [15:39] oh, the bug is just for docs for this. OK. [15:39] I was just thinking, "why file a bug, if it can't be fixed", but it can be documented [15:39] jrwren: yea, the browser can try to do some detection and at least help point the user 'hey I can't connect you might check xxx' [15:40] ah, ok. [15:40] right now the lack of user feedback makes them think juju is broken vs their browser [15:40] this bug is on juju-gui, should it just be this same bug, or a new one? [15:41] jrwren: a new one, this one is on both the charm and the gui. I think having one aroudn the ssl cert for the charm is cool and the other for the gui being helpful [15:41] ok [15:41] jcsackett two qa issues posted [15:43] hatch: huh. haven't seen that. let me see if i broke something addressing last few comments. [15:43] sure thing [15:45] hatch: ok, that first one seems to be fallout i missed from moving the change event firing out of viewlet manager (and is in fact the reason that i put it in the viewlet manager in the first place. i'm digging into why it doesn't work now) [15:46] that second one, i have no idea. [15:46] this damn branch. [15:48] jcsackett it's likely a state issue [15:48] hatch: so, this is fallout from moving to the just checking model.id hasn't changed to see if we should re-render or make a new one. [15:49] b/c we don't actually destroy this._inspector when the inspector closes. [15:49] that's issue #2? [15:49] yeah. [15:49] well we should be destroying it [15:49] hatch: i concur. [15:49] +1 [15:49] be sure to add a test :PPP [15:49] hatch: i'm looking into why it doesn't get destroyed. [15:52] hatch: oh man, we've never destroyed it; it doesn't get destroyed in develop either. so it's not just a simple case of a broken dispatch change. [15:52] hatch: safe to say that when state sees metadata with inspector: null we can kill this._activeInspector? [15:53] jcsackett you bet - I'm curious though as to why it's not, the enptysectiona method should be destroying it [15:53] ohhhh [15:53] I bet that's what happened [15:53] "that" == what now? [15:54] oh wait nm you fixed that [15:54] ok look into emptysectiona method [15:54] it should be being called and destroying the inspector [15:54] https://github.com/jaycee/juju-gui/blob/dispatch-details/app/subapps/browser/browser.js#L390 [15:57] hatch: this is fun. [15:58] this._inspector.destroy() is getting called. [15:58] immediately after which, you can still check this._inspector and find an object. [15:58] same in develop if you look at this_activeInspector. [15:58] oh...right, duh [15:58] destroy() calls the destructor cycle, it doesn't null out the ref [15:58] should empty section set it to undefined or something? [15:58] null probably, yeah [15:58] null....undefined....whatever [15:59] heh [15:59] yeah, that fixes that. [16:05] what we talked about: https://bugs.launchpad.net/juju-gui/+bug/1339155 [16:05] <_mup_> Bug #1339155: gui should display help when wss fails due to incorrectly accepted certificate [16:05] hatch: so it looks like the onHide function in service-inspector isn't even being called? it's just jumping straight to viewlet managers hideSlot, despite my setting click on close-slot to onHide in the service inspector. [16:05] thoughts? [16:05] ty jrwren [16:05] rick_h__: i've added some suggestions to the "new hire" doc [16:06] urulama: ty much [16:06] rick_h__: should I start working on that bug? [16:07] jrwren: just the CN one in the charm [16:07] ah, did that. [16:07] jrwren: so that it doesn't lead to juju.ubuntu.com but to their own env [16:07] jrwren: ok, is that reviewed and landed then? [16:07] point me to docs on that process? [16:07] jrwren: there's a hacking doc around the charm with some functional tests. [16:08] got it. [16:08] jrwren: please share [16:08] jrwren: so you need to pull down the charm code, update it, push it up under your name space, create a merge request from launchpad, and ping to get a review [16:08] http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/files [16:08] http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/view/head:/HACKING.md [16:08] guess I shouldn't have bzr push :parent then. ooops [16:09] rick_h__: tnx [16:09] jcsackett hmm lemme take a look [16:09] jrwren: heh, nope [16:09] I'm not sure [16:09] jrwren: urulama nothing ever lands without review and all stuff should be forked to your own name space (in github or LP) and a pull request/merge proposal created to be signed off on [16:10] jrwren: urulama and we try hard to create a HACKING doc in each project to help describe the workflow for devs [16:10] also for charm/quickstart development we use lbox [16:10] can't promise them, but try to [16:11] i don't know lbox [16:11] frankban: we do for the charm? [16:11] rick_h__: yes [16:11] ok, looks like we need some updating to the hacking docs [16:11] rick_h__: +1 [16:12] frankban: this lbox? https://launchpad.net/lbox [16:12] urulama: yes [16:12] urulama: jrwren lbox is a tool written to help push reviews through reitveld [16:12] it allows for some nicer code review tooling and lbox helps sync with the launchpad merge proposals/etc [16:12] * urulama was happy for a minute not to have to deal with new stuff ... oh well ... :D [16:13] i wondered what that .lbox file was in the charm [16:13] yea, it runs a pre-pull request hook basically to make sure tests pass locally before pushing [16:13] quickstart docs don't mention lbox either :/ [16:13] jcsackett found it [16:14] https://github.com/juju/juju-gui/blob/develop/app/views/viewlets/charm-details.js#L93 [16:14] jcsackett see the e.halt() in that method? That's why it's not being called....e.halt() is the devil which we need to use because I bet the X is an anchor tag [16:15] jrwren: urulama ok, good finds some old docs on lbox :) https://github.com/juju/charm-tools/blob/master/HACKING.txt#L29 [16:15] jrwren: urulama and I think last time we had to go the go get lbox route [16:15] jcsackett so if so the X needs to be changed from an anchor into a span, then that e.halt() can be removed and then it'll work [16:15] sudo go get launchpad.net/lbox will install it globally or you can do it local/etc [16:16] rick_h__: why sudo? isn't the go/bin dir enough? [16:16] urulama: that's what I mean, you choice [16:18] jrwren damn that safari thing sure sucks.... [16:18] jrwren: so from here, can you make sure to run the functional tests of the charm with what you've landed [16:18] jrwren: otherwise it's a minor change and should be good, just want to make sure no tests were relying/checking that [16:19] hatch: SECURITY! :) [16:19] "SECURE ALL THE THINGS!!!!" [16:19] rick_h__: yes, doing that. [16:19] jrwren: ty much [16:20] jrwren: let me know when you've got time to chat [16:22] was JUST going to run out to lunch. [16:23] lets chat, then I'll run. [16:23] jrwren: sorry, was meant to be hatch [16:23] jrwren: go to lunch, we're good [16:23] hatch: let me know when you've got time to chat [16:23] oh, in that case, I'm running out for a bit. brb in 45min or less. [16:23] rick_h__ 1 min [16:24] jujugui: bye all, fun day ;) [16:24] urulama: g'night [16:24] bye urulama [16:24] urulama: night [16:25] rick_h__ standup room? [16:25] hatch: k [16:25] * urulama gets embarrassed for checking out during daytime ;) [16:25] hatch: new room [16:25] nope it's full [16:25] heh === urulama is now known as uru-afk [16:42] * jcsackett discovers he was disconnected from znc for some reason. [16:43] hatch: is there any fallout to always calling addTarget on viewlets to the view manager? then the viewlet's close can just fire the change event. [17:13] man all these hangouts have killed my battery [17:13] jcsackett the only issue is that it may fire an event that someone up the chain is listening for [17:13] so it'll react accidentally to the event [17:14] there is also a performance issue....but neither of these are very big negatives tbh [17:14] if you had like 100's then yeah it would suck, but there is only one so... [17:16] jcsackett ^ [17:18] rick_h__ sorry it wasn't the oatmeal it was http://techcrunch.com/2014/07/04/just-be-present/ [17:20] hatch: I do like this "I’d bet you’ll find most of the ones without people in them pretty boring." [17:20] hatch: but yea nice post [17:20] I just found it funny because it showed up right under your post about your fireworks pics [17:21] :) sometimes I've got good timing [17:22] haha [17:23] well you can take some solace in knowing that yours are awesome [17:24] hatch: so based on our call, did you want to shuffle the cards around? move the coding one back and the other back to code? [17:24] jcastro: and if your two cards are one chunk feel free to combine [17:24] bah jcsackett ^ [17:25] oooh, you're going to let me move your cards around? I'd _love_ to reprioritize stuff! [17:26] hah! [17:26] you and Mark S can duke it out [17:26] I'd pay to see that [17:28] rick_h__ yep I'll re-org them [17:31] * rogpeppe is done for the day [17:31] g'night all [17:40] rick_h__: i can combine, but it's two branches, one done but dependent on changes from the one currently on review. [17:41] jcsackett: ah ok cool [17:41] jcsackett: I didn't realize it was two branches knew you were working through the review of one [17:51] http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/view/head:/HACKING.md says juju-test is part of charm tools, but... it does not seem to be for me. did this change from ppa:juju/stable -> ppa:juju/dev [17:53] jrwren: it used to be, I think it's just a single file and in the tree now? I don't think you need that. [17:54] which tree? [17:55] jrwren: the charm [17:55] jrwren: sorry, new laptop and don't have the sources locally. Working on looking. [17:55] i'm looking too [18:01] oh! my bad. [18:01] i need both juju/devel and juju/stable PPA [18:01] poor assumptions here. [18:03] jrwren: no, this is what I mean by the documentation being out of date on that. Apologies on our end. [18:03] they should be copy/pastable [18:03] they are. [18:04] i assummed that I didn't need hte ppa the documentation wrote, because stable v. devel [18:04] charm-tools is in stable ppa, but not devel ppa. Its really my bad. [18:04] ah gotcha [18:04] maybe I'll update HACKING.md with a note stating as much. [18:08] jrwren: yea,a if it threw you off it's likely to catch someone else as well [18:17] whoa, selenium. cool. [18:19] putting the functional into the functional tests wheeee [18:23] rick_h__: is there a special flag in the gui that will show the icon on personal branches? [18:24] also, if so, what is that flag [18:24] ps <3 [18:25] marcoceppi: no, it's never gotten done. Only for local charms deployed [18:25] whyyy have you all forsaken meeeeeeee [18:25] marcoceppi: because you didn't send enough pie [18:26] * marcoceppi bakes a ton of pie [18:26] marcoceppi: honestly, because i added a branch do it it and then it actually broke things and I've never gotten to write code again and it's never gotten fixed :) [18:28] rick_h__: any way to get this in to gui? We're looking down teh barrel where people want to demo stuff and are putting pressure to promulgate charms because they can't see silly little icons, but these charms are demoware not store stuff [18:28] Damnit, got pinged for an appointment I forgot about. Will be back in a bit. [18:29] Makyo: have fun [18:29] marcoceppi: not until after machine view is out [18:29] marcoceppi: we're under the gun for this. I'm happy to make it a task after that [18:29] and that's not going to happen by the 18th? [18:30] heh, I'm hoping, but only just by the 18th [18:30] rick_h__: cool, should I open a bug to track this request? [18:30] * marcoceppi is excited for machine view [18:30] and then we're out of town so we'd start it the week after that [18:30] hmm, thought we had a bug. Let me look [18:33] marcoceppi: https://bugs.launchpad.net/juju-gui/+bug/1260854 [18:33] <_mup_> Bug #1260854: we really need to support icons for all charms, at least as an option [18:33] marcoceppi: I did one branch that did it for charms, but then that broken icons for bundles and caused us to not release it [18:34] rick_h__: cool, thanks man [18:34]