=== _mup__ is now known as _mup_ [13:13] sinzui: How's it coming with staging? [13:13] abentley, ghastly [13:13] sinzui: Anything I can do to help? [13:13] abentley, Two efforts to create apache have failed [13:14] sinzui: Yikes. [13:14] abentley, Both deploys never got an IP, the agent state is pending [13:14] sinzui: Is it the IP address shortage? That would cause machines to fail to spin up at the nova level. [13:15] abentley, and somehow I lost my branch that sanitises categories [13:16] abentley, I have been using w3m and can confirm charmworld + mongodb + elasticsearch are happy [13:16] sinzui: one trick there is to expose the charmworld app and it'll be present on the port 6543 I think? or 2464, whatever we default to now. [13:17] sinzui: Well, we could tranfer the external IP address to the charmworld app server if necessary. [13:17] abentley, as rick_h wrote, the port will be 6543 [13:18] abentley, Note I still see 645b2404-9179-4a8b-8136-7f238964aa6b | juju staging instance 4 [13:18] ^ that is the zombie Juju thinks it destroyed [13:18] * sinzui ponders nova as a means to decommission the instance [13:19] sinzui: You used terminate-machine? I am not sure whether it is reliable. [13:20] sinzui: The problem with terminating via nova is that the IP address famine means someone could take the address of that machine and we'd be unable to start a replacement. [13:21] abentley, right [13:21] sinzui: Perhaps we should move staging to lcy01, but we'll need a new external IP address, so we'll need to re-map DNS. [13:22] While I can use nova to suspend/resume, I cannot so anything that permits us to gain access to what runs in the vm. [13:22] sinzui: Rebooting doesn't help? [13:22] abentley, we cannot ssh into it [13:23] sinzui: We cannot ssh into it in order to reboot it, or we cannot ssh into it after we reboot? [13:23] before [13:23] I could not ssh into it to see what was up and fallback to reboot [13:24] I didn't see an alternate means to get into the instance using nova [13:24] sinzui: There is a "nova reboot" command. [13:25] Didn't do anything for me yesterday. [13:25] sinzui: what about get-vnc-console? [13:25] I don't know about that [13:26] oh. [13:27] * sinzui checks backscroll [13:27] abentley, we might have a chance now === teknico1 is now known as teknico [13:27] reboot failed yesterday (while the instance was running), I destroyed two services since then and the reboot says I have an agent [13:28] sinzui: woot! [13:29] We are now waiting for the third replacement apache to start and join charmworld === teknico is now known as teknico-phone [14:14] morning [14:14] party on hatch [14:15] looks like haswells are starting to make it into the lenovo's http://www.engadget.com/2013/07/09/lenovos-t440s-thinkpad-coming-soon/ [14:22] sinzui: The options migration failed deployment. I've rolled back to r298. Should be simple to fix, so I won'd do a rollback. [14:22] it will probably still only have an HDMI out making it useless for me heh [14:22] sinzui: i.e. I won't land a revert for now. [14:22] abentley, understood [14:29] luca: gary_poster has there been talk about any limitations to the autocomplete results? For example, only reviewed charms? [14:33] sinzui: chat? [14:33] yes [14:34] sending invite. [14:34] rick_h: not along those lines, gary_poster might have a plan but I'm not sure [14:35] rick_h: luca he is away today [14:36] rick_h: hatch want to talk it through in about 10 mins? [14:36] well isn't it trivial to add filters to the ac results? [14:36] luca: that's ok. I just wanted to double check as the approach is a bit different each way. [14:37] hatch: well, basically it comes down to using a full model and token widgets to display the completion suggestions vs not. [14:38] ohh - ok well I would say use the token widget and then if we need to use ones with less information we can handle that in the GUI [14:38] hatch: right, there's a bunch of logic on which icon to display, the reviewed badge, etc that would need to be duped and I'm trying to think through a DRY around all that. [14:38] hatch: but, if we're only completing reviewed charm none of that logic matters so figured I'd ask :) [14:39] what makes a charm 'reviewed' [14:39] how long do they sit unreviewed? [14:39] hatch: they're reviewed by a couple of the ~charmers team and most will probably never be reviewed. [14:40] never be reviewed? [14:40] hatch: yea, if you fork the mysql charm and upload it to use it, it'll never really be reviewed as there's an official reviewed mysql charm out there. [14:41] ohh hmm [14:41] so the AC will only show 'approved' charms but the full search results will show all of them? [14:41] hatch: yea, that's kind of the question. A/C is a method to shortcut to a selected charm. [14:42] luca: hatch yea, let's chat if that's ok. I'd like to talk it out. [14:42] haha ok give me a few minutes [14:44] rick_h: luca in guichat [14:52] luca, I've got a question when you have a moment. [14:57] hatch: rick_h do we need to talk about search? I'll have a prototype to show you in roughly 5 mins? [14:57] sure pop in real quick [15:10] abentley: got a sec to chat? [15:10] rick_h: Okay. [15:12] luca: can you join in this call real quick? https://plus.google.com/hangouts/_/8e337c1da033485408fb4e6723267db4247e4f42?hl=en [15:13] rick_h: sure [15:17] jujugui, Can I add libpeerconnection.log to .bzrignore? It seems to be an empty file generated on test-server. [15:17] SGTM [15:18] sinzui: can you join the hangout ^^ please? Have a sec that is? [15:18] Makyo: ok to me [15:19] Makyo: let er rip [15:19] Thanks. Will be in review in a mo'., [15:20] augh, everytime I have to go to old jujucharms.com do to something I get disgusted. [15:20] new GUI is sooooo nice [15:21] * hatch is glad that was before his time [15:21] ;) [15:38] orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/config-storage-2/+merge/173757 > [15:39] I can [15:39] abentley, r-me [15:40] r=me [15:43] Makyo: looking at your branch. Are you only dealing with the icon if it's got one and not going to display the fallbacks then? [15:44] rick_h, for this branch, yes. I need to get on to a first pass at updating the service block SVGs today. [15:44] Makyo: ok. [15:45] luca, need to ask you about those when you have a chance. [15:45] Makyo: if you get to the fallbacks let me know. I'm finding that maybe that work should be abstracted out of the template file in charm-token.handlebars and more into a model or helper somewhere. [15:45] rick_h, alright. I didn't dig too much into that, but I will. [15:46] Makyo: yea, it's not in an easy place for you to reuse like this atm. [15:46] Makyo: I'm free now if you are [15:48] luca, the email you sent had the black squircles with the connectors slightly extended. however, in the UX/styling demo, it's that black outline surrounding the original service block. Which direction should I head in? [15:48] sinzui: did you set the revno to 300? [15:49] abentley, I did not [15:49] sinzui: Hmm. Maybe tarmac's back, then. [15:49] abentley: yea, I assumed it came back up when I got the 'jenkins is back to normal' email [15:49] Makyo: the normal state should be this: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1QkNacGhCX0hXNW8/edit?usp=sharing [15:50] Makyo: clicked/hover state: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1eUIzbFNjZjdyMEU/edit?usp=sharing [15:50] luca, alright. Was just curious after seeing https://dl.dropboxusercontent.com/u/10004366/juju-gui/index.html [15:50] Makyo: When it's just been added to the canvas it should show the charm icon instead of the health circle [15:51] luca, the charm icon branch is in review right now. [15:51] Makyo: yeah, Ant hasn't implemented the block stuff yet [15:51] Makyo: nice :) [15:51] rick_h: Oh. I don't get those. [15:51] luca, alright, cool. Will aim to have that for today. [15:51] Makyo: nice, thanks [15:52] sinzui: second time's the charm with prepare-upgrade. [15:52] jujugui call in 8 [15:52] Kanban now. [15:52] what he said! [15:54] sinzui: who do I talk to about "Useful links"? [15:54] google [15:54] *snicker* [15:55] Brat :) [15:55] rofl [15:56] luca, me I think. [15:56] sinzui: ah, well, they are being moved to a section in the summary tab [15:56] sinzui: the designs will be finished tomorrow [15:56] understood luca [15:57] sinzui: cool, thanks :) [15:58] luca, jcastro, jcsackett. I just tested what users see when sharing a juju-gui URL using G+ itself. It was a private post with you so that we can see what the experience is like. [15:59] jujugui guichat now [16:00] sinzui: oh yeah, there's some metadata G+ expects [16:01] we should make it so the charm's icon is automatically in there [16:01] I was just looking this up the other day, investigating [16:01] +1 [16:02] sinzui: here it is [16:02] https://support.google.com/webmasters/answer/176035?hl=en [16:02] http://schema.org/docs/gs.html#microdata_how [16:02] https://www.google.com/webmasters/tools/richsnippets [16:05] sinzui: can we discuss sharing? [16:08] Makyo: one thing I noticed is that the install hook does not install the python-cheetah package, which it indirectly uses [16:09] teknico, hmm. Okay, will poke around there. [16:09] Makyo: thanks [16:10] teknico, what I'm seeing from the GUI is it's not passing the cs: schema when it tries to deploy, so I get juju.charm.errors.CharmURLError: Bad charm URL u\'~marcoceppi/precise/discourse-18\': a URL with a user must specify a schema\n [16:11] Makyo: that might need tweaking when converting from BrowserCharm to Charm models during deploy [16:11] Makyo: that cs: url is in the BrowserCharm.code_source object I believe. [16:11] rick_h, ah, alright. I'll poke around the deploy stuff where it does that conversion. [16:11] Makyo: sorry, BrowserCharm.url is where it's at [16:11] that's the cs: url [16:12] http://manage.jujucharms.com/api/2/charm/precise/apache2-2 shows an example json dump that turns into the model Makyo [16:12] \o/ thanks [16:16] rick_h, teknico, in app/views/charm-panel.js line 873, the deployer is only getting the id attribute; is that where it would need the URL? [16:16] Deployer's the wrong word. The deploy function that's passed to the browser. [16:18] Makyo: so yea, that charm model should have a url attribute. I'm not sure what you're doing the cs: stuff for so can't say what's up with _setPanel() [16:21] Makyo: no, if the passed-in function is the one at line 760, it only needs the charm id [16:21] jcastro: sinzui rick_h who do I need to talk to about sharing? [16:22] I am one of them [16:22] luca: I am also one [16:22] jcastro: [16:22] I did the little text for the twitter section [16:22] jcastro: wrong person [16:22] jcastro: oops [16:22] sinzui: lets talk quickly on a hangout? [16:22] jcastro: ^ [16:22] okay [16:23] teknico, ah, okay. Either way, it looks like the id is ~marcoceppi/precise/discourse, and it should have a schema on the beginning when it actually deploys. [16:23] Makyo: right [16:23] Makyo: right, but we don't consider the schema part of the id in the model and the api. [16:23] Makyo: so the id will never have that, it's the url [16:24] rick_h, Yeah, so we should be able to just change that, I think. Which is maaaaybe line 605? [16:24] var url = charm.get('id'); [16:24] sinzui: https://plus.google.com/hangouts/_/2302ec8be280f94a7841473e1dbbc7e8e43cb204?authuser=1&hl=en [16:24] jcastro: https://plus.google.com/hangouts/_/2302ec8be280f94a7841473e1dbbc7e8e43cb204?authuser=1&hl=en [16:24] Makyo: looks ok from there, but not familiar enough to say 'go for it' [16:26] luca: I am EODing in a minute, only working a half day today and I have a charm championship page to do still [16:26] luca: whatever you guys decide just lmk [16:27] uhm, how do we get the schema in there? I cannot see it [16:29] teknico, just change it to var url = charm.get('url'), looks like. [16:29] I set a breakpoint there and checked charm.getAttrs() [16:29] oh, good to know, thanks [16:29] Makyo: teknico right, the url is the url not the id now. Should be good to pull from the model url. [16:29] Makyo: I wonder why it is only a problem with this specific charm, though [16:30] teknico: no, I think it's a change in the old charm model data vs the new. [16:30] teknico, I'm thinking it's a problem with all user charms due to the change. [16:30] Makyo: the one thing I worry about is if an old instance can get in here, but since it's in deploy side I don't think it can [16:30] Makyo: oh, ok then [16:31] rick_h, yeah. I think the only way would be if they were to deploy from the old panel, which is now mutually exclusive from the browser. [16:31] Makyo: right, so I'm pretty sure you're safe with your one-liner change. [16:31] Makyo: but want to make sure it's clear what the diff is and how it might cascade around a little bit [16:32] rick_h, Yeah. I think it'd be good to go through a bunch of different types of charms and ways of deploying (DnD and add button) to make sure we're always getting the same sort of info. [16:32] Makyo: yea, anything that goes through the Browser code will be an instance of BrowserCharm cast into a Charm and that's what's in here. [16:33] and the api promises that the url will be there. [16:33] Cool, that should help, yeah. [16:36] bac: I made review changes and reproposed if you have time to look that branch over again: https://codereview.appspot.com/11013043/ [16:39] hatch: you might want to look at the method renamings in that branch and see if you're still happy with them [16:39] yup reading it now [16:39] well reading the replies [16:39] I have come to love rebind :) [16:40] what's POJO? [16:40] Makyo: great, thanks a lot for the help! [16:41] teknico, cheers [16:47] bcsaller: I can't deploy a service and then view it using the new service inspector [16:48] hatch: Plain Old Java(Script) Objects, comes from java but means plain Object derivatives [16:48] ohh [16:48] DD ceph, click deploy, click it to view inspector...console error [16:48] so something without the .get method in the case referenced [16:48] hmm [16:49] it was a fresh checkout/make of your branch [16:49] Uncaught TypeError: Object [object Array] has no method 'toArray' service.js:1210 [16:50] and that charm is also tasteless, that is, it's testless ;-) and written in bash :-P [16:52] hatch: able to reproduce locally, looking into it [16:52] there is another error past that one [16:53] rick_h, jcsackett: Did this icon come from the old api (the /json url) or the new api http://uistage.jujucharms.com:8086/~nextrevision/precise/openvpn-3/ [16:53] sinzui: the icons comes because it has a category of 'application' which is invalid. It needs to be applications (s) [16:54] sinzui: so the icon comes because of a broken sprite [16:54] rick_h, I know that... [16:54] bcsaller: alrighty [16:54] sinzui: i'm with rick_h, i don't think i understand what you're asking. [16:54] sinzui: ok, so everything on this page is from the new api [16:54] sinzui: I'm not 100% following the question I guess. [16:54] rick_h, Did it get the category from api 2 or /json [16:54] sinzui: api2 [16:55] rock. This is fixed on staging [16:55] * sinzui is still scouring the network requests to convince himself the /json url was not called [16:56] sinzui: ah, yea. Use chrome, load the page with the network tab open, then click the 'xhr' button on the bottom of the tools [16:57] thank you for reminding me about the filter. I am incompetent rick_h [16:57] hatch: ahh, shallow, the changes around model handling didn't propagate through the modellist handler properly, it was calling selectBindModel on its own product [16:58] sinzui: cool, darn handy tool in our network waterfall for sure. [17:06] bcsaller: ahhh [17:07] hatch: I'm now able to create the error we talked about before where an old inspector (two services on canvas, switch to second) is still running in the background. Not related to this branch, but an issue [17:08] crud I thought your branch would solve that [17:08] arg [17:08] *I hoped* [17:10] I just got rank burnt by order of operations [17:10] * hatch goes to grab the aloe and a grade 4 text book [17:12] hatch: I think I see the fix though, its just not calling the right things in the inspector singleton mgmt code [17:13] trying a fix now [17:13] cool thanks [17:19] hatch: Makyo who do we need to talk about relations and building them? [17:20] luca, Sure. At this point, I think we'll be able to implement most things reasonably quickly, just need a direction to head in. [17:20] luca: I hear there are a lot of good dating sites in London [17:21] :P [17:21] haha ok sorry [17:21] yeah I am pretty confident the code is all there it's just the interaction we want to narrow down [17:21] narrow/peg down [17:22] right now the 'long click' isn't discoverable [17:22] thenagain, neither was the menu [17:22] Makyo: we will join guichat in 2 mins :) [17:23] luca, alright [17:23] can I join in on this too? [17:23] Sure [17:23] cool [17:23] http://jsbin.com/evehit/6 [17:24] pretty cool :) [17:24] it looks/feels the best in firefox [17:24] that's just because it has easing on it's scrolling [17:25] hatch, we're starting. [17:25] sorry guichat was having issue connecting [17:33] hatch: I pushed fixes to the outstanding issues, it properly unbind now [17:33] awesome! [17:33] thanks [17:36] * Makyo runs out to pick up dogs. [17:37] jcsackett: I saw your reply on the bug - are you in Chrome as well? [17:37] hatch: what version of chrome are you running? Maybe a version thing? [17:37] OSX - 27.0 [17:38] hatch: k, 29 here so shouldn't be a version issue then [17:38] odd my Ubuntu Chrome is 28 [17:38] are you running the beta channel? [17:39] dev channel [17:39] ahh gotcha [17:39] so many chrome versions haha [17:39] should only be 3 :) [17:39] stable, beta, dev [17:39] yeah then for each OS [17:39] haha [17:39] but they're released together [17:40] who knows, maybe my osx hasn't made the rounds yet [17:41] 27 would be stabel, 28 beta, 29 dev [17:41] yeah my Ubuntu is on stable I thought [17:41] who knows [17:41] I'd guess not [17:41] bcsaller: QA'ing again [17:42] bcsaller: heh you're gona be maaaaad at me [17:42] I found another bugt [17:42] doh [17:43] hmm can't repro now... [17:43] possible cache issue [17:43] ok nope there it is [17:44] DD ceph, deploy, inspector, click <- S, E, D, Units [17:44] then the toArray error shows in the console [17:45] I think the error occurs when a change comes in on the delta [17:45] it's very odd I can't seem to repro all the time [17:46] ahh if you follow those steps [17:46] then just let it sit [17:46] it'll eventually error [17:49] hatch: I'd seen something like that as well, thought it was fixed, but looking into it now [17:49] great [17:50] I see the real issue [18:07] hatch: are you available for a short chat about transitions in a couple of minutes [18:11] i am [18:11] ^ benonsoftware [18:11] benji: [18:11] damn autocomplete [18:11] benji: whenever you're ready [18:12] hatch: hatch I'm in guichat [18:19] hatch: the model list handler was way too aggressive, I'm surprised we didn't see that issue sooner, tough it would have been hard to spot. It was calling render/update on way too many things including non-model list viewlets [18:19] hatch: pushed the revision [18:24] ohh heh so this code is way better now then [18:24] haha [18:27] hatch: there is still an issue in the updates, but yes as so as I have it properly resolved it will be [18:54] ahh ok [18:54] (sorry was on call with benji) [18:57] hatch: a fix is pushed if you can verify it as well when you have time [18:57] seems to be working fine here [18:59] ok will pull down [19:02] bcsaller: looks good [19:02] propose? [19:05] hatch: I'll push it up again, just takes so long :( [19:06] ohhh I know [19:06] it would be cool if we could have some super powerful box sitting around we could get to pull down the branch and build [19:09] I have a spare server that's probably faster but not by enough that it would make a difference having to 'build' to run the tests [19:16] hatch: proposed again, quite a lot of fixes on that branch now [19:17] haha yeah... [19:23] bcsaller: do you think there should be tests for the edge cases which you just solved? [19:25] hatch: ideally yes :-/ [19:26] you just want to land this branch don't you? [19:26] ;) [19:28] tbh I'd like to see this land so I can get on wit my branch [19:28] followup with tests? [19:30] orangesquad: Could you please review https://code.launchpad.net/~abentley/charmworld/autocomplete/+merge/173799 ? [19:30] hatch: I'll make a carc [19:30] hatch: I'll make a card [19:30] * sinzui looks [19:34] bcsaller: lgtm'd [19:34] jujugui: one more +1 needed for https://codereview.appspot.com/11013043/ [19:34] bcsaller: looking [19:35] thanks [19:35] careful....there be dragons [19:35] now I fully expect my branch to explode after merging it in :) [19:38] abentley, what do you think will happen if the autocomplete query is for 'fo%20'. I think this becomes 'fo ' and it doesn't match anything and it doesn't break anything. [19:39] but maybe some smart function strips the trailing space [19:39] sinzui: My guess is that it would match any charms whose names began with 'fo ', but we don't have any. [19:40] I think the gui needs to be certain to strip whitespace. A leading space will be confusing [19:40] it would be cool if you could do a forEach on an array in reverse [19:40] (without tricks) [19:41] abentley, r=me [19:41] sinzui: Thanks. [19:45] abentley, This is my thoughts about the svg problem: http://pastebin.ubuntu.com/5859420/ [19:47] sinzui: I find the notion of a 96x96 vector graphic confusing. Don't they just need to be square? [19:48] abentley, Yes in the big picture. The template svg specifies the default rendering is 96x96 [19:49] we can detect if the default template was not used. I don't want to enforce the template [19:51] abentley, svgs DO have width and height attributes and even if the template is not used, detecting unsupported dimensions is trivial [19:52] sinzui: Ok. [19:54] abentley, Do we care about file size? DoSing the gui is bad. Well, I think we know something about this because the wikimedia icon contains a fat png [19:54] sinzui: I was going to just use python-magic and reject anything that wasn't svg. Going so far as to validate images doesn't seem like it should be our problem. Maybe proof should do that? [19:54] abentley, I think proof should do that. proof is run after we build the CharmFileSet [19:55] We can call magic as we build the set [19:56] sinzui: As an advocate for the backend, my only concern about file size would be on the ingest side. On output, we have solid caching. [19:57] sinzui: In terms of the GUI, it shouldn't be an issue, because only promulgated charms are going to show their icons. [19:57] abentley, apache2 and wikimedia are both promulgated. [19:58] one has a png and the other has an embedded png [19:59] abentley, we wouldn't be treating this issue as a bug of the mistakes in the icons were fixed in April when we discovered the problem [20:00] sinzui: Right, but the maintainers aren't malicious. I assume the svg-with-embedded-PNG is a legitimate wikipedia logo that just happens to be big. It's not a DoS, though, and is only going to affect those who encounter that charm. [20:01] sinzui: If you want to cap file size, it's fine by me. [20:01] abentley, I think you prefer that we do the minimum to ingest to deal with this issue (use magic to reject liars). Update proof to demand the issue be fixed [20:01] I can update proof. I have other fixes I want to add to it [20:02] sinzui: I think that's accurate. [20:02] * sinzui ponders how proof could be taught to report that the maintainer is wrong because the branch owner is different [20:02] well that is not a good idea [20:03] Teams will often own charms, but they will rarely have email addresses [20:04] sinzui: I don't think proof can know what the branch owner will be. [20:04] sinzui: Unless we tell it, I suppose. [20:05] I really want to set my own juju agenda. The package-origin and maintainer-owner problems lead to confusion and are vulnerabilities that no one is talking about [20:06] sinzui: Maybe we should overwrite maintainer with branch owner at ingest time? [20:06] sinzui: I don't see a lot of value in having them vary. [20:07] That hides errors. But we could record that we know there is something wrong. Write now, we know it because we few can see the problem [20:07] right now ^ [20:08] sinzui: I go back and forth on whether the maintainer field has any value. The fact that it's so often wrong suggests it's not important. [20:08] abentley, rick_h brought up the author/owner issue in regards to the charm token today. User do need to see both, and they need to know that something is wrong when they differ [20:09] abentley, juju certainly doesn't require it. [20:09] sinzui: Author is a third thing. That's something you get from bzr metadata :-) [20:09] The field is flawed since teams can own branched, but not have email addresses [20:09] indeed [20:13] abentley, I think the charm/branch owner is who juju and the community cares about. The maintainer field is a means for a the owner to provide the preferred contact address. This too is unneeded if juju and juju-gui could point to Lp about how to contact or contribute [20:15] sinzui: Makes sense. [20:19] rick_h: autocomplete is implemented on staging. [20:21] sinzui: I am ready for new work and assume it should be versions. Chat? [20:21] abentley, yes and yes [20:39] hatch: that should be landed and ready for you to merge [21:18] bcsaller: thanks yas [21:34] bcsaller: Makyo I think you can drag your branches into the done column :) [21:34] hatch, yep, thnks [21:36] Makyo: you aren't going to make us QA this SVG code are you? ;_ [21:36] ;) [21:37] hatch, I totally am. Lucky for you, all it requires is for you to deploy a service. [21:38] *phew* [21:39] Well, preferably two services, and create a relation. [21:40] welllll O K [21:40] :) [21:40] reviewing [21:42] Makyo: rgb color? [21:42] hatch, yanked from the demo. [21:42] I don't care either way, we should probably stick with one or the other :) [21:42] hatch, I can see about converting, though. [21:42] hatch, yeah. [21:42] colorpicker.com [21:42] is what I use :) [21:42] Thanks. [21:43] rgb(a) kind of makes more sense for our support matrix buuuuuuuut whichever :) [21:43] Yeah [21:43] I care so litle about it I'm not even going to comment on the review :D [21:44]