[00:03] <huwshimi> rick_h_: Any specific cards you'd like me to take a look at today?
[00:03] <rick_h_> huwshimi: the big thing I'm going to try to QA and land the stuff from jcsackett and Makyo
[00:04] <rick_h_> huwshimi: and so the big thing is QA of the changes
[00:04] <huwshimi> rick_h_: OK, I can do some QA.
[00:04] <rick_h_> if you want to help QA those that's cool and once I can get them in we want to QA and see if we're good for release tomorrow
[00:36] <mbruzek> rick_h_, Thanks for responding.  I have deployed the charm with the "" values in there, it starts up on its own.  There is not a way to unset a variable (that I know of at least).
[00:37] <mbruzek> rick_h_, There was no other code changes other than config.yaml, so I am looking through the code to see if the config-changed hook uses None or empty string on any of those variables.
[00:38] <rick_h_> mbruzek: ok
[00:38] <mbruzek> rick_h_, So far I see a comment on the password configuration option # Normalize empty string passwords to None.
[00:39] <mbruzek> So setting password to "" looks safe, the other ones seem to be related to ssh keys which are harder to track down but I am on it.
[00:39] <mbruzek> Do you know of a way to unset a value?
[00:40] <rick_h_> mbruzek: https://juju.ubuntu.com/docs/commands.html
[00:40] <rick_h_> there's unset in there
[00:40] <rick_h_> mbruzek: but we don't support that in the gui
[00:41] <mbruzek> unset: set service config options back to their default
[00:41] <rick_h_> mbruzek: right
[00:41] <mbruzek> OK let me rephrase that, I don't know of a way to set a config value to None.
[00:41] <rick_h_> mbruzek: oh ok
[00:41] <rick_h_> right
[00:42] <mbruzek> I will get to the bottom of this.  I was just looking for any red flags from the GUI team if they KNOW this is an unsafe option.
[00:43] <mbruzek> When I was still green I reviewed the rabbitmq-server charm and it has some values that did not have defaults, so I defaulted them to "" and James Page noticed that was wrong because the code handles None differently than "" so I actually had to change them back.
[00:45] <rick_h_> mbruzek: yea, there was a giant thread about it before
[00:46] <mbruzek> That is what I am trying to avoid here... I will review this as normal
[01:28] <huwshimi> rick_h_: With the mv flag I am unable to deploy a charm. Are you able to?
[01:29] <huwshimi> hmm... doesn't work on comingsoon for me either.
[01:29] <rick_h_> huwshimi: you need Makyo's branch that hooks up the button
[01:29] <rick_h_> huwshimi: that uses the state control stuff and you have to enter a magic command into the console to 'deploy'
[01:30] <huwshimi> rick_h_: I was just trying with the button in the inspector. Does that not work either?
[01:30] <rick_h_> huwshimi: right, so that just 'queues' up the deploy
[01:30] <huwshimi> ah right
[01:30] <rick_h_> huwshimi: that's the work that the deployer bar is doing
[01:30] <rick_h_> huwshimi: so it's in a middle state right now
[01:31] <huwshimi> rick_h_: I see. That branch is landing now I see.
[01:32] <rick_h_> huwshimi: yea, hoping to get that going so we can demo the working flow of inpsector on the left, going through deployer bar, and then into machine view
[01:32] <huwshimi> Nice
[01:32] <rick_h_> it's not complete, but we can demo that we've got all the ideas in place and we just need more time to finish stringing the wires to everything
[01:40] <rick_h_> huwshimi: can you qa this one from me as well please? https://github.com/juju/juju-gui/pull/261
[01:40] <huwshimi> Sure
[01:40] <rick_h_> thanks
[03:05] <rick_h_> heh, lovely WebDriverException: Message: None ; Stacktrace:
[03:05] <rick_h_> yay for no messages
[03:06] <rick_h_> huwshimi: any luck qa'ing https://github.com/juju/juju-gui/pull/261 ?
[03:06] <huwshimi> rick_h_: Just started :)
[03:06] <huwshimi> (was having lunch)
[03:06] <rick_h_> ah gotcha thanks
[03:10] <huwshimi> rick_h_: This branch is just repositioning the inspector panel, not reusing the existing browser details panel?
[03:11] <rick_h_> huwshimi: it's using the same container space
[03:11] <huwshimi> rick_h_: Ah, ok.
[03:11] <rick_h_> huwshimi: so the inspector popout panels are going into the same container the charm details uses
[03:11] <rick_h_> the bws-view-data or whatever
[03:11] <huwshimi> rick_h_: Great!
[03:12] <huwshimi> rick_h_: The animations seem to have broken
[03:12] <rick_h_> huwshimi: on which ones?
[03:12] <huwshimi> rick_h_: The details panel sliding in for the browser or the inspector
[03:13] <rick_h_> the inspector ones don't animate
[03:13] <rick_h_> I'll look if I broke the details one as well
[03:13] <huwshimi> rick_h_: Well, they should if they re-use the same node though right?
[03:13] <rick_h_> it might be a follow up to make the details from the inspector animate like the service ones.
[03:13] <rick_h_> they need more work
[03:14] <rick_h_> well, they use the same container, but don't use the same code path yet
[03:14] <rick_h_> I've kind of hacked them in for now with a follow up card to make them true views vs just viewlets
[03:14] <rick_h_> the css chain is probably a bit different. It might be an easy fix, not sure
[03:15] <rick_h_> ok, so the charm details animations work ok
[03:15] <huwshimi> rick_h_: That's strange, I don't see them.
[03:16] <rick_h_> oh, no they don't with the feature flag in please
[03:16] <rick_h_> place
[03:16] <rick_h_> bah
[03:16] <rick_h_> that's broken on trunk as well http://comingsoon.jujucharms.com/:flags:/il/
[03:16] <rick_h_> so this branch did not break it, it's the new navigation stuff
[03:17] <huwshimi> oh I see
[03:19] <huwshimi> rick_h_: There are lots of places that if a url doesn't exist then the gui breaks instead of handling them (e.g. http://localhost:8888/inspector/service_29/:flags:/il/)
[03:19] <huwshimi> (I know that's unrelated)
[03:19] <huwshimi> (To this branch)
[03:19] <rick_h_> huwshimi: yes, that's due to the inspector stuff. I'm trying to think about it. In a live environment we want those to work.
[03:20] <rick_h_> for the demo environment we want to just skip them I think
[03:20] <rick_h_> but we'll have to tackle that and figure out a good path. The idea is that you'll be able to link me to the inspector of a service in our shared live environment
[03:24] <huwshimi> rick_h_: I found another bug, but it happens on comingsoon as well. With the 'il' flag, if you click a charm in the sidebar and it opens the details panel and then you click 'deploy' the console shows an error: Cannot read property 'setStyle' of null
[03:24] <rick_h_> looking
[03:25] <rick_h_> huwshimi: ok, something in the sticky heading stuff blowing up there
[03:25] <rick_h_> huwshimi: will add a card
[03:26] <huwshimi> rick_h_: It's a really strange place to have an error. Doesn't seem related.
[03:26] <rick_h_> huwshimi: yea, I think there's some scroll event between the view getting killed for the inspector
[03:27] <rick_h_> and when the charm search/etc goes away
[03:27] <huwshimi> Ah you could be
[03:27] <huwshimi> *yeah
[03:27] <rick_h_> and when the scroll event tries to figure out the size/etc the nodes are gone
[03:27] <rick_h_> and it bombs
[03:28] <huwshimi> yeah that makes sense
[03:29] <rick_h_> yea, that event isn't setup using addEvent()
[03:29] <rick_h_> so it's not destroyed with the view
[03:29] <rick_h_> https://github.com/juju/juju-gui/blob/develop/app/subapps/browser/views/charmresults.js#L154
[03:29] <rick_h_> so changing it to use the event tracker/addEvent should fix it hopefuly
[03:30] <rick_h_> oh hmm, it's in the destructor though
[03:38] <huwshimi> rick_h_: I've finished the QA. Anything else you'd particularly like me to take a look at?
[03:39] <rick_h_> huwshimi: if you want to look at that error that'd be cool
[03:39] <huwshimi> rick_h_: Sure.
[04:01] <rick_h_> huwshimi: one other thing in qa'ing stuff here myself. The scrollbar fix actually messed up the inspector view a little bit in the :flags:/il
[04:01] <rick_h_> huwshimi: since it has a scrolling body it has a scroll bar in a diff location
[04:02] <huwshimi> oh
[04:02] <rick_h_> huwshimi: so that scrollbar showing fix is only when it's a charm result (editorial or search)
[04:02] <rick_h_> huwshimi: I missed that in qa originally, my bad
[04:03] <rick_h_> anyway, doesn't look like we'll be able to release tomorrow. Thanks for the qa in helping to point out issues out there.
[04:03] <rick_h_> huwshimi: have a good day
[04:03] <huwshimi> rick_h_: OK no problems. Night!
[04:04] <rick_h_> huwshimi: can you put yourself on the card for today please?
[04:05] <huwshimi> rick_h_: Done.
[04:05] <rick_h_> ty much. You leave tomorrow?
[04:06] <huwshimi> rick_h_: I leave on Sunday, and then get to the US on Sunday :)
[04:06] <rick_h_> lol oh ok hten
[04:06] <huwshimi> Tomorrow is a public holiday here.
[04:06] <rick_h_> ah ok
[04:07] <rick_h_> well if I don't run into you before vegas safe travels. Looking forward to getting together
[04:08] <huwshimi> rick_h_: Thanks, will be good to see you too. Have a good trip down.
[10:33] <rick_h_> frankban: was the git checkout stuff broken in the precise version of the charm?
[10:35] <frankban> rick_h_: trying the same on precise charm
[10:35] <rick_h_> frankban: also, the little guy wants to sleep in today. Is it ok to push back out 1-1 a little bit this morning?
[10:35] <rick_h_> frankban: I'm working on replicating it here. I hit it trying to put together a demo branch for kapil yesterday.
[10:36] <rick_h_> deploying to ec2, and I have precise as the default series in my ec2 env
[10:36] <frankban> rick_h_: ok
[10:37] <frankban> rick_h_: I need to go out for lunch in 24 mins, other than that I am available nay time
[10:37] <frankban> any even
[10:37] <rick_h_> frankban: ok cool. Let's try after lunch then. bac is out so I don't have anything else until our stand up
[10:38] <rick_h_> and I'll see about duping this. I need to update my envs and switch my default series. bye bye precise! :)
[10:38] <frankban> :-)
[10:39] <frankban> rick_h_: also trying with a local env: juju bootstrap --upload-tools --series precise shoudl work around the bug
[10:39] <rick_h_> frankban: cool, yea I hit this because i wanted a real env so wondering if there's something in the version of git I hit. It had a strange error trying to do the clone of the new repo from git.
[10:52] <rick_h_> frankban: verified the trusty charm does not fail on this issue. So another case of just use the latest charm silly
[10:52] <rick_h_> frankban: my hard coded default-series in the environments.yaml bit me
[10:53] <frankban> rick_h_: but it should work with the precise charm too, we test both scenarios on ec2
[10:54] <frankban> rick_h_: have to go, will ping you later
[10:54] <rick_h_> frankban: have fun, thanks for checking up on it
[11:56] <rick_h_> frankban: I'm back from taking the boy to day care. Let me know when you're back from lunch and we can do our call
[12:01] <frankban> rick_h_: I am back, joining the call
[12:28]  * rick_h_ goes to make coffee and breakfast
[13:13] <jcsackett> Morning, all.
[13:13] <rick_h_> party
[13:15] <mbruzek> Good morning
[13:16] <rick_h_> mbruzek: hey, I saw the emails about the charm stuff from jose. I missed you were talking about our charm lol
[13:17] <mbruzek> frankban, Thanks for commenting on the juju-gui merge proposal.  I have a follow up question. If this next review passes should I not merge it with the charm in precise/juju-gui ?
[13:17] <rick_h_> mbruzek: no, we run our own promulgated charm.
[13:17] <mbruzek> Sorry I didn't make that more clear rick_h_
[13:17] <rick_h_> mbruzek: it's not a ~charmers root charm and all changes should go through the team
[13:17] <rick_h_> mbruzek: it's the one charm you guys shouldn't have to worry about :)
[13:18] <mbruzek> rick_h_, so what should I do with Jose's MP?
[13:18] <rick_h_> http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/files
[13:18] <rick_h_> mbruzek: so I think he replied to frankban that he'd update in the right place
[13:19] <frankban> mbruzek: as I mentioned to him, he should repropose the branch against our development branch: lp:~juju-gui/charms/trusty/juju-gui/trunk
[13:19] <mbruzek> The way I read it, he would do that "later"
[13:20] <frankban> mbruzek: yeah, so I think we can safely close this MP
[13:20] <mbruzek> OK I will do that then.
[13:21] <frankban> mbruzek: thanks
[13:27] <frankban> rick_h_: what do you think about removing lp:~juju-gui/charms/precise/juju-gui/trunk and lp:~charmers/charms/precise/juju-gui/trunk? those branch will be no longer updated and can generate confusion
[13:27] <rick_h_> frankban: sounds good to me.
[13:28] <frankban> rick_h_: no luck: This branch cannot be deleted as it has 22 branches sharing revisions.
[13:28] <hazmat> rick_h_, i don't see any 'local' charm specificity in the apis on the state server for charm file retrival
[13:28] <rick_h_> frankban: maybe pushed a MOVED file like we did with the gui when we moved to github?
[13:28] <mbruzek> frankban, What is the preferred fix here?  Leave login-help without a default?  If we do that then that allows users to set login-help to "" when they don't want anything displayed there.  Or change the if statement to generate the default text when login_help is None or empty string?
[13:29] <rick_h_> hazmat: hmm, talked with frankban about that this morning and we've added a card to make it non-local charm specific in the core api
[13:30] <mbruzek> frankban utils.py line 366
[13:31] <rick_h_> hazmat: I'll look for his patch there. The gui branch tries to load the files from juju but it responded that the charm couldn't be found so all the icons were just broken. So something is in there.
[13:32] <hazmat> rick_h_, k, i'll try exploring with it a bit more.. i was just reviewing apiserver/charms.go
[13:32] <frankban> mbruzek: I don't have a strong opinion, and I don't know the story behind the decision to make proof warn when there is no default. A None default makes sense for the login-help, as you mentioned. On the other side I don't see so much value in having an empty login help. So I guess implementer choice?
[13:33] <mbruzek> frankban, I am OK with that one option exist without default.  I just wanted to see if that was OK with the gui team
[13:33] <rick_h_> hazmat: looking https://code.launchpad.net/~frankban/juju-core/get-charm-api/+merge/207994
[13:34] <frankban> mbruzek: +1 from me, let's leave login-help as is
[13:40] <rick_h_> hazmat: maybe only local charms are in the storage location we're looking in? Does juju store those in a different path or naming convention? I also don't see anything 'local' specific/filtering there.
[13:40] <hazmat> rick_h_, different naming convention
[13:40] <hazmat> in provider storage for store charms
[13:41] <rick_h_> hazmat: ok, so that might be the issue. we're using the url local:precise/charm and if it's not cs:precise/charm then we'll have to tweak that to find it in juju land
[13:53] <hazmat> rick_h_, found the issue
[13:54] <hazmat> rick_h_, that code should be using the state api to get its download url of a charm
[13:54] <hazmat> rick_h_, at the moment its just using its own notion of the storage name/key
[13:55] <rick_h_> hazmat: k, can you file a bug to that effect and assign it to yellow squad and I'll update our card on the board with a link to that
[13:56] <jcsackett> rick_h_: i'm thinking of taking on the new state inspector issues for local charms on project a--there an easier way to look into that than bootstrapping an environment with local charms?
[13:56] <rick_h_> jcsackett: yes, the code should work for sandbox as well. So the issue is pre environment work
[13:57] <rick_h_> jcsackett: let me know if you want to walk through any of the cards.
[13:58] <jcsackett> rick_h_: how does one setup a local charm in sandbox mode?
[13:58] <jcsackett> rick_h_: i'm happy to chat via hangout if you prefer.
[13:59] <frankban> hazmat: interesting, re state api, where are you looking at?
[13:59] <frankban> jcsackett: you can just drag and drop a zipped charm to the canvas
[13:59] <jcsackett> frankban: oh, nice. i didn't know that.
[14:00] <rick_h_> jcsackett: yea, we use hatch's ghost charm to test :)
[14:00] <rick_h_> jcsackett: so you download the zip from github (download zip button) and drag it onto the environment and it should popup an inspector asking you to choose a series and upload it
[14:00] <hazmat> frankban,  state/charm.go  -> BundleURL()
[14:02] <hazmat> frankban, name := charm.Quote(curl) ; storage.get(name) only works with local charms.. it should really be using the charm state api to retrieve the url and just download it direct from that instead of using storage apis at all.
[14:03] <jcsackett> rick_h_: ah, i see, and that upload inspector is not loading. ok, easy enough to reproduce.
[14:03] <rick_h_> jcsackett: right, I've not looked to know what the root issue is. It's definitely due to the state stuff so need to see how it used to work and port it over to the new world order
[14:04] <rick_h_> jcsackett: which may be easy/pita depending on how it works currently
[14:04] <rick_h_> jcsackett: but let me know if you hit any questions
[14:04] <jcsackett> rick_h_: well, i've looked into a bunch of the new state handling stuff, so i'm in the right headspace. i'll ping you as i hit stumbling blocks.
[14:09] <frankban> hazmat: so charm, err := state.Charm(curl) and the using an http client to retrieve charm.BundleURL()?
[14:09] <hazmat> frankban, yes.. or juju-core/downloader
[14:17] <frankban> cool
[14:20] <rick_h_> jujugui going to push back the standup 30min if that's ok. Want to check in on the #is call at the top of the hour
[14:20] <jcsackett> fine by me.
[14:20] <kadams54>  Ditto
[14:20] <frankban> np
[14:20] <rick_h_> ty
[14:22] <rick_h_> frankban: you need reviews right? I'll do one after the calls. We need a second?
[14:22] <frankban> rick_h_ thanks, jujugui: yes I need a second one
[14:24] <jcsackett> frankban: i can be the other. link?
[14:25] <frankban> jcsackett: https://codereview.appspot.com/90570044
[14:26] <jcsackett> frankban: cool, looking.
[14:26] <frankban> thanks
[14:36] <kadams54> guihelp Currently getting this error when running tests in browser: "No juju config to fetch charmworld store url"
[14:37] <kadams54> I suspect it's due to networking issues (not on my usual network) and vagrant. Was wondering if anyone had ever seen it before.
[14:37] <rick_h_> kadams54: that's failing something? It shoulnd't be an issue.
[14:37] <kadams54> The test runner aborts when it hits that.
[14:37] <rick_h_> I think it's just dumped as a warning/message
[14:37] <kadams54> OK, well then it dumps and then the test runner just stops running
[14:37] <kadams54> Oh wait
[14:37] <kadams54> Hah
[14:38] <rick_h_> yea, that's just a warning error and is normal/fine
[14:38] <kadams54> Apparently the test runner did not stop running
[14:38] <kadams54> It just took minutes for a test to run
[14:38] <rick_h_> gotcha
[14:38] <rick_h_> cool
[14:38] <kadams54> I'd always hit reload or whatnot after 30 seconds of nothing going on
[14:39] <kadams54> But since I'm complaining about it in IRC, it had enough unmolested time to get through the hangup and move on…
[14:39] <rick_h_> lol yay irc
[14:40] <kadams54> I think there may be some sort of leak in our tests (or maybe mocha)… I've noticed that when I re-run the suite multiple times in a particular tab, it gets slower and slower. Opening up a new tab seems to fix the problem.
[14:42] <kadams54> Error: timeout of 100000ms exceeded
[14:43] <rick_h_> kadams54: ok, so taht's an async test that did not complete
[14:43] <rick_h_> kadams54: look for a missing done() in the async bit
[14:43] <rick_h_> kadams54: or check that the async/etc got hit/fired
[14:47] <rick_h_> kadams54: push/paste the test if you need another set of eyeballs
[14:49] <jcsackett> kadams54: i've experienced a similar issue (leak-like slowdown) when running tests in the browser; when running them via test-{debug,prod} everything's a lot speedier.
[14:50] <kadams54> Yeah, everything is speedier, but there's some issue with phantomjs and vagrant where they bomb out.
[14:50] <kadams54> :-(
[14:50] <jcsackett> just use an LXC instead of vagrant. :p
[14:50] <rick_h_> jcsackett: those osx users don't have lxc
[14:50] <rick_h_> jcsackett: though that's an interesting question of does the issue exist when lxc in a vm is used as the environment
[14:51] <jcsackett> rick_h_: lxc...in a vm...on your main laptop. that may be too many turtles.
[14:51] <rick_h_> moar turtles!
[14:53] <kadams54> jcsackett: http://the.taoofmac.com/space/HOWTO/Vagrant
[14:53] <kadams54> I'd actually like to get this up and running :-)
[14:54] <jcsackett> wow.
[14:57] <kadams54> rick_h_: https://gist.github.com/kadams54/a3268988a82c8e9e089c
[14:57] <kadams54> I suspect the problem is in line 40
[14:58] <kadams54> But with that said, I'm wondering if any of the tested stuff in here is relevant anymore
[14:58] <rick_h_> kadams54: hmm so setting withHome on the view needs to trigger something that hits the showHome method
[14:59] <rick_h_> I'm not sure that's automatic. I can look after this call to look at that
[14:59] <kadams54> Since sidebar is now a much more dumb container and the home stuff has moved
[14:59] <rick_h_> kadams54: right, so this is an example of a test that does't matter to sidebar, but does to search.js and editorial.js now
[15:00] <kadams54> Yeah, I'd been trying to move over just some of the assertions, but on review, the entire test needs moving.
[15:01] <rick_h_> kadams54: rgr sounds good
[15:04] <rick_h_> kadams54: right so that test it checking https://github.com/juju/juju-gui/blob/develop/app/subapps/browser/views/view.js#L91 is bound correctly
[15:05] <rick_h_> kadams54: so this is part of the MainView that is injested into search.js and editorial.js via the charmresults.js
[15:12] <jcsackett> frankban: am i just seeing what i want to see, or is the 'bad wolf' stuff in quickstart a dr. who reference?
[15:12] <frankban> jcsackett: it is
[15:12] <jcsackett> \o/
[15:12] <frankban> :-)
[15:13] <frankban> jcsackett: so you understand it's a really bad error message
[15:13] <jcsackett> indeed, end of the world type stuff. :p
[15:22] <jcsackett> frankban: lgtm on your code with one comment, i'm starting qa now but probably won't finish until after the standup.
[15:22] <frankban> jcsackett: cool thanks
[15:25] <rick_h_> jujugui call in 5
[15:29] <rick_h_> jujugui call in 2 ... 1 ... where's makyo to do this for me :P
[15:31] <jcsackett> rick_h_: be there momentarily, fighting with G+.
[15:32] <rick_h_> kadams54: ^
[15:44] <kadams54> Yeah, sorry, I spaced the 11:30 time and left to run an errand
[15:45] <rick_h_> kadams54: ok, let us know if there's anything we can do to help with your branch.
[15:45] <kadams54> Will do
[15:45] <rick_h_> kadams54: only news is no release today obviously, qa last night brought out a few more cards of work
[15:45] <kadams54> ok
[15:46] <kadams54> jujugui: the main thing I had for standup is that there's a family emergency I need to take care of before Vegas, so I may be in and out more on Friday.
[15:46] <rick_h_> kadams54: ok
[15:47] <kadams54> Nothing too big, just needed to setup some appointments
[15:55] <jcsackett> frankban: i'm having issues qaing b/c my network is playing poorly with repositories and the juju pkgs ppa won't install/update. i'll try again later today from another network. it's not your branch tho.
[15:55] <jcsackett> or rick_h_, if you can handle qa ^
[15:56] <rick_h_> jcsackett: k, can look at that after review
[16:04] <hatch> so I've found out that sublime text is a huge power hog
[16:05] <hatch> it could be some of the plugins but it big time drags the battery down
[16:05] <rick_h_> hatch: welcome back to vim :P
[16:05] <rick_h_> hatch: heads up, we need to noddle on viewlets in a inspector-left world.
[16:05] <hatch> haha, it seems every sprint I hop back into vim land
[16:05] <rick_h_> hatch: and if viewlets and the manager make sense any more
[16:05] <hatch> maybe it'll stick one of these days
[16:06] <rick_h_> hatch: we've got a training crew ready to meet you in vegas
[16:06] <hatch> lol
[16:07] <hatch> I don't see how the inspector-left has any impact on viewlets/viewlet-manager.....it could probably be renamed though
[16:07] <hatch> we still need a view manager I think
[16:07] <hatch> there was a bunch of stuff added into viewlet-manager for the inspector which can probably be refactored out
[16:07] <rick_h_> hatch: I'm having to work the popup viewlets out of the view manger because they're not a sub dom child element
[16:07] <hatch> so sure, we can chat about it, there is definitely room for improvment
[16:07] <rick_h_> hatch: so all rendering, event bubbling, etc don't work
[16:08] <hatch> oh for the left (now right) breakout?
[16:08] <rick_h_> hatch: right
[16:08] <rick_h_> all of that breaks becaus the inspector is the root element all delegation goes from (container, etc)
[16:08] <hatch> ahhh ok ok yeah that has always been tacked on - we can definitely improve that
[16:09] <rick_h_> so the viewlet-manager/etc isn't helping much, I'm more having to work around the system.
[16:09] <hatch> chat in Vegas or sooner?
[16:09] <rick_h_> and then we need to figure out the routing straight to a popup stuff
[16:09] <hatch> right right
[16:09] <rick_h_> hatch: vegas is fine, just a heads up to ponder it
[16:09] <hatch> cool will do, I'll look at it
[16:09] <rick_h_> hatch: I've worked around it for now, but I've got a card to think of a better long term solution and would appreciate your feedback/input
[16:11] <hatch> oops heh
[16:11] <rick_h_> wrong button :P
[16:11] <hatch> yep haha
[16:12] <hatch> yeah it definitely needs some work to do right
[16:12] <rick_h_> hatch: cool, so speaking of pondering I'm going to go ponder my lunch choices. Thinking I'll leave my bat-cave today
[16:12] <hatch> enjoy!
[16:12]  * rick_h_ goes to find foods and biab
[18:03] <rick_h_> kadams54: hangout?
[18:03] <kadams54> Yup
[18:03] <kadams54> Will be there shortly
[19:12]  * rick_h_ heads out, have a good nigth all
[19:13] <rick_h_> err night
[19:59] <Makyo> jujugui having trouble getting juju to play with LXC, machine one never provisions.  I seem to remember something about clearing mongo caches; is that what I'm missing?
[20:04] <rick_h_> Makyo: there's a known but where a trusty host can't bring up precise machines or something atm
[20:05] <rick_h_> Makyo: make sure you've got a default series and that it's trusty for the bootstrap node I think
[20:05] <Makyo> Okay, thanks
[20:05] <rick_h_> Makyo: frankban was working around this bug in https://launchpad.net/bugs/1309455 today
[20:05] <_mup_> Bug #1309455: The auto-generated local env does not work in trusty <juju-quickstart:In Progress> <https://launchpad.net/bugs/1309455>
[20:06] <Makyo> Aha!  Thanks rick_h_
[20:30] <jcsackett> rick_h_: i've sorted the issue--apparently my debugger wasn't working right when i thought render didn't pop up--it's just rendering beneath the charmbrowser so it's invisible (unless you zoom out via browser controls rather than app). do we want this to render where it used to, or are all inspectors supposed to be on the left?
[20:32] <jcsackett> assuming all on the left, we can either set it to push the charmbrowser down so it's visible? or replace the browser a la the service inspector? the latter is, i think, considerably more work.
[20:33] <rick_h_> jcsackett: all on the left
[20:33] <jcsackett> right, like i assumed. so then appearance wise, should it take up all the space of the sidebar like the service inspector?
[20:33] <rick_h_> jcsackett: so we should remove the browser instance, and put the inspectot in its place
[20:33] <rick_h_> yep
[20:34] <rick_h_> the interesting question is that it's not really a routable item...
[20:34] <jcsackett> rick_h_: right.
[20:34] <rick_h_> so ssoi
[20:34] <rick_h_> bah
[20:34] <rick_h_> lag
[20:34] <rick_h_> so, we might need to do something where we hide/restore the browser stuff in there
[20:34] <rick_h_> as part of working around this
[20:34] <jcsackett> yeah.
[20:35] <rick_h_> jcsackett: so will have to look at where it gets created and determine the best path forward on it
[20:35] <jcsackett> "it" being the request-series inspector?
[20:35] <rick_h_> I'm not sure off the top of my head, for the ghost inspector we do "route"
[20:35] <rick_h_> jcsackett: yes
[20:36] <rick_h_> jcsackett: thinking it through,the normal process is to drop the charm, select the series, and then you get a ghost inspector, which is routed
[20:37] <rick_h_> jcsackett: so if we just hide the browser, then once you pick a series it needs to get destroyed, along with the browser stuff
[20:37] <rick_h_> if you close out, and choose not to complete the process we need to show back the browser
[20:37] <rick_h_> jcsackett: want to point me where in the code the inspector is created and we can see if there's a sane way to hide the browser?
[20:38]  * rick_h_ will brb going to start a movie for the little guy.
[20:38] <jcsackett> rick_h_: ok.
[20:39] <jcsackett> so, it's created in service.js, which sets up the drag/drop handler for zip files. it has a method which calls the create/render code for the request-series thing, so that could handle hiding the charm browser at the same time.
[20:40] <rick_h_> looking, just want to make sure it's got easy enough access to the browser bits
[20:42] <rick_h_> ok, so it looks like it destroys the existing service inspector with the topo.fire('destroyServiceInspector')
[20:43] <rick_h_> but that may/may not be open. It really does need to set something in the state. Like component: "inspector", metadata: { services: services, file: file}
[20:44] <jcsackett> rick_h_: that was my thought and my fear.
[20:44] <jcsackett> :p
[20:44] <rick_h_> jcsackett: call?
[20:44] <jcsackett> s'why i wanted you to tell me to just make it work the way it used to.
[20:45] <jcsackett> rick_h_: migrated to a coffee shop that may be less than ideal, but let's give it a go.
[20:45] <rick_h_> yea, but that's no good. The topo.fire() needs to be a "destroy anything that's sticking around right now, but restore it if I close the dippy deployment inspector" which is basically what state does
[20:46] <rick_h_> https://plus.google.com/hangouts/_/7ecpj54iefa352n1pbj99t88eg?hl=en
[20:49] <jcsackett> rick_h_: i dropped, reconnected, and now i can't hear you.
[20:49] <jcsackett> do you even see me in the call?
[20:50] <rick_h_> byeok, I dropped
[20:50] <jcsackett> well, i can hear you typing.
[20:50] <rick_h_> heh, ok
[20:50] <rick_h_> well I'm out now. Something hung on my end as well
[20:50] <jcsackett> rick_h_: ok, let me try again, calling you from the hangout app on my phone.
[20:50] <jcsackett> i think the wifi at the shop may not be up to this. :p
[20:51] <rick_h_> k
[20:53] <jcsackett> it's calling you on G+...i can't send a url, b/c iphone.
[20:53] <jcsackett> your canonical account.
[20:54] <jcsackett> ...or this is just a bust. i can sprint home and we can try in a few?
[20:54] <jcsackett> didn't think it would be *this* hangout hostile.
[20:54] <rick_h_> jcsackett: ok, no biggie
[20:54] <rick_h_> it's close to EOD and such
[20:55] <rick_h_> jcsackett: we can catch up in the morning and plot a path
[20:55] <jcsackett> rick_h_: fair. i'll figure this out a bit more, talk early AM tomorrow?
[20:55] <jcsackett> and you just said basically the same thing. so yeah, i'll ping you tomorrow morning.
[20:55] <rick_h_> jcsackett: rgr, take a peek at the state stuff. We'll need a new url test in the state code that builds an inspector component with metadata that says "this is a local charm deploy"
[20:56] <rick_h_> so poke around the new ui, test_ui_state.js, etc
[20:56] <jcsackett> and *doesn't* make it a component of the URL.
[20:56] <rick_h_> well the component is still inspector
[20:57] <rick_h_> but the metadata will have to instruct it which 'type' to build. We've got a few now
[20:57] <rick_h_> there's the normal service inspector, the local charm deploy, and the upgrade one I think.
[20:57] <rick_h_> anyway, poke around and we'll chat in the morn
[21:00] <jcsackett> Dig.


[03:00] <fishcooker> apk ini apkah di surabaya kah?
[03:00] <fishcooker> *sorry typo
[06:19] <jchodyniecki> installed snappy on ESXi, virtualbox, and vagrant and the ubuntu/ubuntu user/pass doesn't work on any of them
[06:19] <jchodyniecki> any help?
[08:22] <JamesTait> Good morning all; happy Monday and happy Scrabble Day! :-D
[13:49] <dholbach> mvo, https://code.launchpad.net/~dholbach/click-reviewers-tools/run-pyflakes3/+merge/255821
[14:27] <fionnan> Anyone getting `ERROR: Could not generate AppArmor profile for docker_docker_<IP_ADDRESS>.json...` when installing docker on a fresh snappy instance?  Traceback is here: http://pastebin.com/ChQmLUmq
[14:54] <mterry> snappy-go no longer allows you to build a snap with an unknown framework?
[15:01] <pendigging> Recently update snappy app docker <IP_ADDRESS> fails to install on ubuntu core dev 15.04.
[15:01] <pendigging> ubuntu@localhost:/var/log$ sudo snappy install docker docker      8 MB     [[15:02] <pendigging> Any workaround?
[15:04] <ogra_> asac, ^^^^
[15:04] <ogra_> two people already
[15:04] <fionnan> yup
[15:08] <jdstrand> pendigging: are you using the latest promoted image or the latest devel-proposed?
[15:08] <jdstrand> pendigging: actually, can you paste: system-image-cli -i
[15:09] <pendigging> ubuntu@localhost:~$ system-image-cli -i current build number: 145 device name: generic_amd64 channel: ubuntu-core/devel last update: 2015-02-24 19:19:17 version version: 145 version ubuntu: 20150223.2 version raw-device: 20150223.2 ubuntu@localhost:~$
[15:09] <jdstrand> let me try
[15:11] <jdstrand> pendigging: ah, that is the old promoted image
[15:11] <jdstrand> fionnan: hey, can you give the output of: system-image-cli -i
[15:13] <jdstrand> pendigging: you need to update your system with snappy update and reboot
[15:14] <pendigging> jdstrand:   Tx much!   I will give it a whirl!
[15:24] <fionnan> jdstrand: yup, here you go
[15:24] <fionnan> http://pastebin.com/NLt2exvx
[15:25] <pendigging> jdstrand:  That worked for me.  Again, tx :-)
[15:25] <jdstrand> fionnan: right, the same thing I told pendigging applies to you. you need to update your system with snappy update
[15:25] <jdstrand> pendigging: nice!
[15:25] <jdstrand> asac: re ogra's ping, I handled it
[15:34] <dholbach> links:
[15:34] <dholbach> http://developer.ubuntu.com/snappy
[15:34] <dholbach> https://developer.ubuntu.com/snappy/porting/
[15:35] <lool> thnka dholbach
[15:35] <dholbach> https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/files/head:/docs/
[15:35] <dholbach> anytime
[15:35] <lool> repeating for the couple of recent joiners
[15:36] <lool> http://developer.ubuntu.com/snappy
[15:36] <lool> https://developer.ubuntu.com/snappy/porting/
[15:36] <lool> https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/files/head:/docs/
[15:43] <elopio> http://www.wefearchange.org/2015/04/creating-python-snaps.html
[15:43] <elopio> I'm playing with ^
[15:55] <lool> slide deck with links: https://docs.google.com/a/canonical.com/presentation/d/1DCeQ1lSsZQaGAyUeJGOdCbTVstG1DYViw9wc2GUpK7w/edit#slide=id.g606de2313_017
[16:22] <lool> sergiusens: the porting guide says snappy-dev/beta for the PPA with latest device-flash; I'm using snappy-dev/tools though; which one is the right one?
[16:22] <lool> NB: there are trusty users here
[16:23]  * ogra_ always uses phablet-team/tools
[16:23] <ogra_> :P
[16:34] <fionnan> jdstrand: Cheers!
[16:36] <sergiusens> lool: I'm on trusty
[16:36] <sergiusens> lool: and using the tools ppa, that said I need to copy it to beta
[16:38] <lool> sergiusens: I told everyone to use the tools PPA now
[17:12] <lool> sergiusens: do you have the power adapter for the ninja SDK? if not, what's the voltage?
[17:12] <vila__> mvo: https://bugs.launchpad.net/ubuntu/+source/snappy/+bug/1443557 feel free to re-assign
[17:23] <mvo> vila__: thanks, I put it on our trello board
[18:39] <elopio> jodh: ping. We are at the snappy sprint and they told us you have been running tests.
[18:39] <elopio> jodh: could you join #ubuntu-quality and tell us which kind of tests have you been running, and the kind of errors you have found?
[19:34] <tgm4883> Having difficulty getting the snappy image booting on the beaglebone black. following the instructions on http://www.ubuntu.com/things#try-beaglebone I've got the image on the micro SD card, but when the card is inserted I don't seem to get anything happening on the beaglebone. Just the one power light
[19:35] <tgm4883> puting other things on the card (debian, ubuntu) boots up fine
[19:35] <lool> hwang4: https://docs.google.com/a/canonical.com/presentation/d/1DCeQ1lSsZQaGAyUeJGOdCbTVstG1DYViw9wc2GUpK7w/edit
[19:36] <hamo> mvo: ping
[19:36] <mvo> hamo: pong
[19:37] <hamo> mvo: Hi...https://bugs.launchpad.net/ubuntu/+source/snappy/+bug/1443599
[19:37] <hamo> mvo: I found some issue during usage
[19:37] <hamo> mvo: and I have proposed a patch, could you help to review it?
[19:38] <mvo> hamo: YES, sounds great, let me have a look
[19:38] <hamo> mvo: thanks :-)
[19:44] <hamo> mvo: I saw you approve it... Thanks very much for your reivew
[19:44] <hamo> mvo: what should I do next?
[20:26] <mvo> hamo: hm, let me think about this for a minute or two
[20:29] <lool> Nikolay: http://people.canonical.com/~ogra/ninja/README
[20:29] <lool> ogra_: ^ was that the latest ninja sdk bits you had?
[20:29] <lool> ogra_: we're running a hands on workshop and I've proposed Nikolay to create an OEM snap for ths board
[20:48] <sergiusens> hamo: if you want to contribute, maybe adding support for snappy info to list the oem snaps if they exist
[20:48] <sergiusens> hamo: or the other one would be to have snappy list follow the spacing spec
[21:22] <tbo_> can I chroot into snappy from ubuntu?
[22:02] <sergiusens> mvo: Chipaca https://code.launchpad.net/~sergiusens/snappy/installFactorX/+merge/256042
[22:31] <Chipaca> sergiusens: when you feel like taking a break, https://code.launchpad.net/~chipaca/snappy/touch/+merge/255650


[03:17] <pero> where can i get the actual extension for chromium's unity web apps? i've lost it and get it back it no matter what (reinstalling chromium-browser, unity-webapps-common, etc)
[07:44] <tvoss> Saviq, ping
[07:47] <tvoss> Saviq, for when you wake up: https://code.launchpad.net/~thomas-voss/unity-mir/refactor-oom-score-adj-to-rely-on-process-cpp/+merge/194797
[07:47] <tvoss> and https://code.launchpad.net/~thomas-voss/unity-mir/refactor-process-group-operations-to-rely-on-process-cpp/+merge/194804
[08:56] <Saviq> tvoss, I like all the red
[09:14] <tvoss> Saviq, :)
[09:15] <Saviq> tvoss, missing debian/control entry, though
[09:16] <tvoss> Saviq, yup, fixing
[09:16] <tvoss> Saviq, please don't top-approve, yet
[09:17] <Saviq> tvoss, k
[09:23] <tvoss> Saviq, updated
[09:23] <Saviq> tvoss, cheers
[09:24] <tvoss> Saviq, now if only jenkins was with us again
[09:24] <Saviq> tvoss, ;)
[09:37] <cooljckd> hi guys
[09:37] <cooljckd> anybody on the keyboard ?
[09:39] <cooljckd> i just wanted to ask you guys in there is any repo for ubuntu in mauritius
[09:39] <cooljckd> if*
[09:40] <cooljckd> i mean a server locally in mauritius
[09:40] <cooljckd> because the moment we have to download everything from the uk
[09:41] <cooljckd> and it sucks
[09:41] <cooljckd> to have to download updates on a daily basis from here with this type of bandwidth
[09:43] <cooljckd> i mean what would cost you make a git server on the island and commit resent security updates to it automatically from anywhere
[09:43] <greyback> cooljckd: you should be able to choose a repo closer geographically.  That's ridiculous
[09:46] <cooljckd> so even if you choose another repo it stills sucks
[09:47] <cooljckd> l know its crazy
[09:47] <greyback> well then you need to talk to your local telecom company
[09:47] <cooljckd> but seems they dont trust the local operators
[09:47] <greyback> routing all traffic half way around the world is crazy sounding
[09:48] <cooljckd> well all can be proven
[09:48] <cooljckd> of course
[09:48] <cooljckd> if you dought my info
[09:48] <cooljckd> just check for yourself
[09:48] <greyback> no I don't doubt you
[09:49] <cooljckd> so i've to the uk recently
[09:49] <cooljckd> i bandwidth there is 33 mb for the average jo
[09:49] <cooljckd> its cool to work there
[09:50] <cooljckd> dont get me wrong i love to travel but i still like my country
[09:51] <cooljckd> and im trying to find a way to make think ok for me and everybody using linux
[09:51] <cooljckd> in mauritius
[09:51] <cooljckd> have a better experience
[09:51] <cooljckd> using there fav os
[09:51] <greyback> sure. But unfortunately there's no mirror on Mauritius right now :(
[09:51] <cooljckd> was there any
[09:52] <greyback> not that I know of
[09:52] <cooljckd> i vpn and ssh to germany everyday
[09:53] <cooljckd> and i dont have any problem
[09:53] <cooljckd> working from out here
[09:53] <greyback> cooljckd: maybe there'd be interest in establishing a mirror. Have you talked with these guys: http://lugm.org/
[09:54] <cooljckd> well i guess i just keep looking for a distro that can suit my needs
[09:54] <cooljckd> thanks for answering anyway
[09:54] <greyback> good luck
[09:54] <cooljckd> hehe
[09:54] <cooljckd> luck has nothing to do with this
[09:55] <cooljckd> its a teritorial thing
[09:55] <cooljckd> i mean you cant expect some windows lovers to let linux traffic out now can you
[09:56] <greyback> Well I'd hope your ISPs are linux users
[09:56] <cooljckd> well maybe someday maybe
[09:56] <cooljckd> in 30 years
[09:56] <cooljckd> perhaps
[09:57] <cooljckd> when worlds ends and the zombies invades
[09:57] <cooljckd> anyway i hope im still there then
[09:57] <cooljckd> bye
[09:57] <cooljckd> cheers
[09:58] <greyback> bye! Hope you find a solution somehow :)
[11:11] <nic-doffay> tsdgeos, can we land this today? https://code.launchpad.net/~nicolas-doffay/unity8/search-history-persist/+merge/193935
[11:11] <tsdgeos> nic-doffay: the landers are dead
[11:12] <nic-doffay> tsdgeos, ah still.
[11:12] <tsdgeos> nic-doffay: any reason you need it today?
[11:16] <tvoss> tsdgeos, the landers sounds a bit like the elders :)
[11:16] <tsdgeos> :D
[11:17] <nic-doffay> tsdgeos, not particularly.
[11:18] <tsdgeos> oka
[11:36] <tsdgeos> dandrader: i added you to https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1250412
[11:36] <tsdgeos> if you can share some thoughts on it
[11:36] <tsdgeos> it'd be cool
[11:37] <tsdgeos> dednick: man, i can't repro the crash anymore :(
[11:37] <dednick> tsdgeos: hm.
[11:37] <dandrader> tsdgeos, well, it's an InverseMouseArea, not an InverseTouchArea. :P
[11:38] <tsdgeos> dandrader: i know
[11:39] <tsdgeos> dandrader: so i guess you're suggesting we strip the code that makes MouseArea work with TouchEvents?
[11:40] <dandrader> tsdgeos, added a comment
[11:41] <dandrader> tsdgeos, I don't think MouseArea has any code about touch events
[11:41] <dandrader> tsdgeos, it's all in QQuickWindow
[11:41] <tsdgeos> QQuickWindow has
[11:41] <tsdgeos> let's kill it
[11:41] <tsdgeos> by your suggestion
[11:41] <tsdgeos> doesn't make any sense
[11:42] <tsdgeos> ok, you were joking
[11:42] <tsdgeos> i'll stop continuing your joke as it's obvious it's not working
[11:42] <dandrader> tsdgeos, I wonder why they did it like that. If it's an optimization or something...
[11:43] <dandrader> tsdgeos, I stumbled upon it while doing the "touch ownership" work. I had to use a Qt private API in order to dispatch a touch event to an item
[11:43] <dandrader> there's a QQuickItemPrivate::dispatchTouchEvent() "public" method that QQuickWindow calls
[11:44] <dandrader> intenally it just call QQuickItem::touchEvent()
[11:44] <dednick> tsdgeos: mine isn't either
[11:45] <dandrader> tsdgeos, It  might be worth proposing a Qt patch to make touch events go through the regular QObject::event
[11:45] <tsdgeos> dednick: maybe something changed at the model level that sends stuff in a different order
[11:45] <dandrader> tsdgeos, in the worst case, if they reject it, we will at least know why they did it like that
[11:45] <tsdgeos> dandrader: good luck with that (yeah i've had a bad day with our Qt friends today)
[11:46] <tsdgeos> dednick: hopefully i'll be able to fake the test with the info you got yesterday, let's cross fingers :D
[11:48] <dandrader> tsdgeos,  well,  I will hunt down the author of that dispatch code and ask why it's like that...
[11:48] <dandrader> (easier than proposing a patch)
[11:48] <tsdgeos> good luck :-)
[11:48] <tsdgeos> obviously they are ont sure it's right
[11:48] <tsdgeos> since the code has stuff like
[11:49] <tsdgeos>         // XXX todo - should sendEvent be doing this?  how does it relate to forwarded events?
[11:52] <dandrader> tsdgeos, hmm, that's pretty old code, from the beginnings of QML. I bet it was just an overlooked...
[11:52] <dandrader> s/an//
[11:52] <tsdgeos> one can hope :-)
[11:52] <dandrader> :)
[11:53] <dandrader> ok, I'm motivated enough to come up with a patch now
[11:53] <Cimi> where is Unity.Application?
[11:53] <Cimi> in which package?
[11:55] <greyback> Cimi: libunity-mir1
[11:55] <Cimi> greyback, it's already the newest version
[11:55] <Cimi> greyback, that means I have wrong includes maybe
[11:57] <greyback> Cimi: probably yeah
[11:57] <tsdgeos> unity-mir ?
[11:57] <tsdgeos> Cimi: ↑↑↑
[11:57] <greyback> Mirv: ping
[11:59] <Saviq> om26er, re: https://code.launchpad.net/~om26er/unity8/helper_dont_try_unlock_if_already_unlocked/+merge/194839
[12:00] <Saviq> om26er, IIUC the RuntimeWarning should be raised if it's already unlocked
[12:00] <Saviq> om26er, does that not happen for you?
[12:00] <Saviq> om26er, please make sure veebers has a look at that MP
[12:00] <om26er> Saviq, it seems to be not working here. with the screen unlocked it tried the swipe() and failed
[12:01] <om26er> Saviq, yes, I was going to email him that
[12:02] <Cimi> I added http://paste.ubuntu.com/6404934/
[12:03] <Cimi> but it still doesn't find unity.application
[12:03] <Cimi> how do you do this in cake?
[12:03] <Mirv> greyback: pong
[12:04] <greyback> Mirv: heya, I think I know the answer to this before I ask, but worth a try: I'm working with Qt5.2 from the beta2 PPA. There wouldn't be debug symbols available for it, would there?
[12:06] <Mirv> greyback: those are compiled with -debug & CONFIG+=debug, so qtbase5-dbg, qtdeclarative5-dbg etc should in theory be what the doctor ordered?
[12:07] <greyback> Mirv: ah really?! Yay!
[12:07]  * greyback was searching for *-dbgsym, duhh
[12:07] <greyback> Mirv: magic, thank you
[12:07] <Mirv> greyback: yeah, I kept those local changes from the trusty 5.1.1 builds. you're welcome.
[12:11] <dandrader> tsdgeos, About Qt work: I should work on the "stable" branch, right?
[12:11] <tsdgeos> dandrader: stable is for 5.2.1, release is for 5.2.0, devel is for 5.3.0
[12:12] <tsdgeos> at this point i thikn stable == rlease
[12:12] <dandrader> tsdgeos, so I suppose things on stable are fed to devel?
[12:12] <tsdgeos> kind of
[12:13] <tsdgeos> i think so yes
[12:29] <Cimi> cmake ^^
[12:40] <tsdgeos> dednick: meh i can't find a way to create a test that causes the crash
[12:40] <tsdgeos> mhr3: there was any release to any scope package yesterday?
[12:45] <tsdgeos> doesnt' seem like there was
[12:50] <dandrader> tsdgeos, found a bug about the qquickitem::event issue https://bugreports.qt-project.org/browse/QTBUG-32004
[12:50] <tsdgeos> :D
[12:51] <tsdgeos> now we just need them to fix it ;-)
[12:52] <dandrader> tsdgeos, will try to get that bug from Frederik
[12:52] <tsdgeos> oka
[13:03] <mzanetti> mhr3: everything should be fixed now: https://code.launchpad.net/~mzanetti/unity8/music-preview/+merge/193803
[13:05] <greyback> Wellark: ping
[13:11] <mzanetti> Saviq: o/
[13:11] <Saviq> mzanetti, welcome back
[13:11] <mzanetti> Saviq: thanks. from what I see jenkins is currently off
[13:11] <Saviq> mzanetti, yeah, in transit
[13:12] <mzanetti> Saviq: should I re-top-approve approved branches?
[13:12] <Saviq> mzanetti, if there are some that should be re-top-approved, sure
[13:12] <mzanetti> Saviq: e.g.: https://code.launchpad.net/~mzanetti/unity8/launcher-small-tweaks/+merge/191380
[13:12] <Saviq> mzanetti, we're in auto mode now (well, when jenkins is back, that is)
[13:13] <mzanetti> Saviq: ah ok... yeah. wasn't sure if you still want to trigger one by one
[13:13] <Saviq> mzanetti, that one was never top-approved was it :)
[13:13] <mzanetti> Saviq: I think it was
[13:13] <Saviq> mzanetti, why would it be un-top-approved then?
[13:13] <Saviq> mzanetti, jenkins didn't report anything on it
[13:13] <Saviq> re: autolanding at least
[13:14] <mzanetti> Saviq: I assumed you un-approved them in order not to flood jenkins when it starts picking up stuff again
[13:14] <Saviq> mzanetti, ass-you-me
[13:14] <Saviq> mzanetti, I didn't un-approve anything, let me see my mail history
[13:14] <mzanetti> not sure I follow the whole pun
[13:15] <Saviq> mzanetti, "when you assume, you make an ass of u and me"
[13:15] <mzanetti> ah
[13:15] <greyback> sounded like an invitation to me ;)
[13:15] <Saviq> greyback, not for you
[13:16] <Saviq> mzanetti, on that note, I'm still able to break the view behind switching previews quite easily
[13:16]  * mzanetti checks
[13:17] <greyback> Saviq: I can live with that
[13:17] <Saviq> mzanetti, just swipe between two previews at row boundary, or at category end
[13:18] <Saviq> mzanetti, seems to be easiest to reproduce with the last results in a scope
[13:18] <mzanetti> Saviq: ok. but this was working.
[13:18] <Saviq> mzanetti, it is working, but sometimes it isn't ;D
[13:18] <mzanetti> Saviq: with latest trunk it's 100% broken here
[13:19] <Saviq> mzanetti, maybe something else affected it
[13:19] <mhr3> tsdgeosnot really, why?
[13:19] <mzanetti> I'll try to fix
[13:20] <mhr3> tsdgeos, not really, why?
[13:20] <Saviq> tsdgeosnot
[13:22] <mzanetti> Saviq: shouldn't the Audio element use the media player service implicitly?
[13:22] <Saviq> mzanetti, that's a good question
[13:22] <Saviq> mzanetti, it could indeed
[13:22] <mzanetti> Saviq: I'd say yes. on meego it does for example
[13:23] <mzanetti> because we want *all* Audio {} elements to shut up when there is a phone call incoming for example
[13:23] <Saviq> mzanetti, yeah
[13:23] <Saviq> mzanetti, right, so once we provide a QtMultimedia backend for our media service, that would still work fine
[13:23] <Saviq> mzanetti, ok then, +1
[13:24] <mzanetti> I'd say so
[13:27] <mhr3> mzanetti, wrt the music preview, could you make the whole track row clickable?
[13:28] <mzanetti> mhr3: technically sure. design-wise I personally wouldn't like that. let me ask rosie
[13:38] <dandrader> tsdgeos, have you compiled qtdeclarative recently?
[13:48] <Saviq> dednick, "[nick-dedekind] Search label should hide when dash isn't focused: INPROGRESS" I think that was fixed
[13:48] <Saviq> dednick, and re: "[nick-dedekind] Replace the SEARCH label with current lens name or the search query (in double quotes) when page header goes out of view - proportionally to header's visible portion: INPROGRESS" please ask design folk that's still the desired solution
[13:49] <dednick> Saviq: partially. still available when previewing which screws it up becuse it tries to show keyboard.
[13:49] <Saviq> dednick, ok
[13:49] <dednick> ok, will ask about other one
[13:49] <Saviq> dednick, [...] as they've been iterating the search behaviour recently
[13:50] <dandrader> tsdgeos, nevermind. I had an outdated qtbase
[13:54] <hashken> I was trying out the GMail Unity Webapp
[13:54] <hashken> Whenever I open the GMail webapp from dash, GMail is just opened as a tab in the current Firefox Window and also there is no GMail icon in the launcher.
[13:55] <hashken> Searching online shows a lot of people facing such problems.
[13:55] <hashken> My impression was that when an webapp is opened it will open in it's own window with it's own icon and behave separately from firefox
[13:56] <hashken> What is the actual behavior that is to be expected?
[13:58] <mhr3> Saviq, is there a way to take screenshots with mir now?
[13:59] <mhr3> Saviq, designers miss that a lot :)
[14:04] <Saviq> mhr3, there's a script
[14:04] <mhr3> Saviq, oh?
[14:05] <Saviq> mhr3, http://lmgtfy.com/?q=ubuntu+phone+mir+screenshot ;)
[14:05] <mhr3> lmgtfy... :P
[14:06] <dednick> Saviq: so apparently the whole dash is being redesigned. so...
[14:08] <kgunn> dednick: !?
[14:09] <dednick> kgunn: well, i don't really know the extent of redesign, but the doc "Dash Visual Design 14.04" is no longer "entirely" valid. Some new dash toolkit coming in.
[14:10] <kgunn> dednick: ah..yeah
[14:10] <kgunn> dednick: less freaked out...that's the template stuff
[14:13] <dednick> kgunn: ok, just saw the doc. was just a bit of sensationalisation.
[14:14] <kgunn> dednick: well...where designers are involved...that's totally possible "let's start over!" :)
[14:15] <nic-doffay> Cimi, are you busy with this? https://bugs.launchpad.net/unity8/+bug/1152150
[14:29] <Cimi> nic-doffay, we have to dig this probably outside shell
[14:35] <Saviq> nic-doffay, Cimi, yeah, it's a lower-level (Qt-level) thing
[14:41] <nic-doffay> Saviq, does your comment on this still stand currently? https://bugs.launchpad.net/unity8/+bug/1224552
[14:41] <nic-doffay> About measuring by the category height.
[14:41] <Saviq> nic-doffay, yes
[14:42] <nic-doffay> Saviq, what do you mean by a two-step animation?
[14:44] <Saviq> nic-doffay, only the visible part of the category should be resized / animated - the rest should be expanded / collapsed in one frame
[14:44] <Saviq> nic-doffay, so, when expanding → animate to shell height within a duration, then just change the height to the target value
[14:45] <Saviq> nic-doffay, when collapsing → change the height to shell height, then animate to target value
[14:45] <Saviq> nic-doffay, makes sense?
[14:48] <nic-doffay> Saviq,  yep gotcha.
[15:15] <mhr3> Saviq, need to pick your brainz - re the scopes plugin, your idea was to keep providing the current functionality and register new types different higher version, so we'd have qmlRegisterType<Scope>("Scope", 0, 1, ...) and qmlRegisterType<NewScope>("Scope", 0, 2, ...), is that right?
[15:15] <mhr3> Saviq, and then when everything is "ready" we'd remove the 0.1 stuff?
[15:15] <Saviq> mhr3, yeah, sounds about right
[15:15] <Saviq> mhr3, and then the dash app would import 0.2 already
[15:16] <Saviq> mhr3, you could also have a completely separate plugin
[15:16] <Saviq> mhr3, if you went for a major version bump
[15:16] <Saviq> mhr3, then you'd install it in Unity.1, for example
[15:16] <mhr3> Saviq, yea, i was just thinking which one makes more sense
[15:16] <Saviq> mhr3, depends on how similar the APIs will be
[15:16] <mhr3> it's unlikely you'd use both at the same time...
[15:17] <mhr3> well... ultimately the api is just exposing a bunch of models
[15:17] <Saviq> mhr3, also, for minor versions
[15:17] <mhr3> so it could be kept fairly consistent
[15:17] <Saviq> mhr3, you can in theory use the same object, but mark certain methods as per-revision
[15:17] <mhr3> don't think we'd need that atm
[15:17] <Saviq> yeah I know
[15:18] <Saviq> mhr3, I think it's fine to keep in a single plugin - this way you won't need to copy stuff around
[15:19] <mhr3> Saviq, my current dilemma is whether to branch the repo and start removing stuff, or branch the repo and just start adding stuff :)
[15:19] <Saviq> mhr3, the versioning system is more about backwards compatibility, which we don't care about for the moment
[15:19] <Saviq> mhr3, the unity8 repo?
[15:20] <mhr3> Saviq, no, the scopes plugin repo
[15:20] <Saviq> mhr3, for the new version, you mean?
[15:20] <Saviq> mhr3, what would you remove?
[15:20] <mhr3> Saviq, yes, i'd basically remove everything old api related
[15:21] <mhr3> so really just the headers would stay
[15:21] <mhr3> not even all of them :)
[15:21] <Saviq> mhr3, well, we want both version to work for the time being, no?
[15:21] <Saviq> mhr3, from the same source?
[15:21] <mhr3> do we? :)
[15:21] <mhr3> that's my ultimate question i guess
[15:22] <Saviq> mhr3, I think so, yes, to support the current unity dash and the new dash app
[15:22] <Saviq> mhr3, well, plan is to transition to new scopes by 14.04 anyway, isn't it
[15:22] <mhr3> in that case it's clear what needs to be done
[15:22] <Saviq> mhr3, so we'd remove the old plugin before then anyway
[15:26] <mhr3> sil2100, that reminds me, zmqpp in universe yet? :)
[15:27] <vesar> Saviq, hi dude. Would you have any quick solution to my problem? I'm trying to run mzanetti's branch on device and when ./run_on_device -s it gives me following: http://paste.ubuntu.com/6405829/
[15:28] <vesar> Saviq, I did also touch /userdata/.writable_image && reboot before that already
[15:32] <Cimi> mterry, hey
[15:32] <mterry> Cimi, hello!
[15:36] <Cimi> mterry, I tried running your latest revision on the desktop, it fails with unity.applciation
[15:37] <mhall119> seb128: thostr_ is gone, but https://blueprints.launchpad.net/ubuntu/+spec/client-1311-mediascanner-roadmap still need to be accepted for the uds-1311 sprint
[15:37] <mterry> Cimi, yeah, because we use OSKController or some such
[15:38] <Cimi> mterry, yes, but why doesn't work on the desktop?
[15:38] <Cimi> mterry, missing include?
[15:38] <seb128> mhall119, can you do that? I've some launchpad issues from that box (need to remember it when I'm back to my desktop a bit later otherwise)
[15:39] <mterry> Cimi, no.  Because the desktop doesn't provide a Unity.Application plugin, like Touch does.  It will work on Touch, or you can point it at a mock Unity.Application on your desktop.  unity8 builds a mock version for running on a desktop and I pointed the wizard at that when testing
[15:39] <seb128> mhall119, or is there somebody else around who can accept it?
[15:39] <mterry> Cimi, let me see if I can find my command line
[15:40] <mterry> Cimi, nope, it's left my bash history.  But basically I'd build unity8 trunk, then set QML2_IMPORT_PATH to unity8's builddir/tests/mocks/ or some such
[15:40] <mterry> Cimi, or just comment out the OSKController bit
[15:40] <mterry> Cimi, and the Unity.Application import
[15:41] <mhr3> vesar, was that about the music-preview branch?
[15:41] <mhr3> vesar, if so i should have that on my device in a sec
[15:42] <sil2100> mhr3: yes! Actually it's in universe - 3.2.4 is enough?
[15:42] <mhr3> where sec == ~10minutes :)
[15:43] <mhr3> sil2100, are you sure about that? aren't you talking about zmq itself? we need the c++ bindings for it -> zmqpp
[15:45] <Cimi> mterry, ok
[15:45] <Cimi> mterry, I cannot test the wifi page, I don't have wifi on my virtual machine
[15:45] <mhall119> seb128: I can, I just don't want to accept BPs for tracks that aren't mine, unless the track lead asks me to of course :)
[15:46] <Cimi> mterry, can you see what's working there until I get the phone working? (my ubuntu phone does not boot)
[15:46] <mhall119> seb128: accepted, it'll be imported into summit in the next hour or so
[15:46] <mterry> Cimi, you are running saucy still?  :)
[15:46] <seb128> mhall119, thanks
[15:46] <mhall119> np
[15:46] <Cimi> mterry, trusty
[15:46] <mterry> Cimi, OK, I can test
[15:46] <mterry> Cimi, which branch?
[15:46] <Cimi> mterry, yours
[15:47] <mterry> Cimi, k
[15:48] <tsdgeos> dednick: did my answer solve your concern about the test?
[15:51] <dednick> tsdgeos: yep. thanks
[16:03] <vesar> mhr3, no it's one launcher related branch
[16:03] <vesar> mhr3, thanks anyway
[16:04] <mhr3> vesar, yea, sorry, don't have that one
[16:08] <mhall119> davidcalle: ping me when you're around
[16:10] <davidcalle> mhall119, pong
[16:11] <mhall119> davidcalle: hey, so I'm working on these scopes API docs
[16:11] <mhall119> I started parting the python html docs, but then remembered that we should be promoting C, is that still correct?
[16:12] <mterry> Cimi, I don't see anything on the WiFi page in my branch
[16:12] <davidcalle> mhall119, it is, but server-side scopes can still be in Python
[16:12] <mterry> Cimi, I see the page, just no content.  No stderr output either
[16:12] <Cimi> mterry, does the wifi plugin on the system settings work at least?
[16:12] <mterry> Cimi, fair question...
[16:12] <mhall119> davidcalle: do you think we should make docs for both?
[16:12] <mterry> Cimi, yeah
[16:13] <Cimi> mterry, it's a good start
[16:13] <Cimi> mterry, I just need to get this bloody thing working
[16:13] <davidcalle> mhall119, I think so. Even if there is still no formal process to submit them for inclusion, the server is open to new scopes.
[16:13] <Cimi> thing = phone
[16:14] <mterry> Cimi, in case I didn't mention, I proposed the team branch for merging.  So don't commit back to that same one if you land a wifi fix.  I'd like to land the team branch and then propose further fixes directly to system-settings trunk
[16:14] <mhall119> davidcalle: ok, one more thing, is there anything in the docs that indicates that a class is for a specific "section"?
[16:14] <mhall119> like, there classes are for previews, these classes are for filtering, these classes are for the search scopes, etc
[16:14] <Cimi> mterry, ok
[16:16] <davidcalle> mhall119, I'm not sure about C scopes, but for Python ones, it's not that straightforward. Python scopes must have a set of methods with specific names which return specific objects. They are ran by the scope-runner app, which call these methods.
[16:17] <Cimi> mterry, ok phone works, how do I test the app on the phone?
[16:18] <mterry> Cimi, I haven't done it in a while....  if things still work the same, you should be able to actually install it
[16:18] <mterry> like the .deb
[16:18] <mterry> and reboot
[16:18] <Cimi> ok
[16:18] <Cimi> mterry, but the wizard?
[16:19] <davidcalle> mhall119, so, I can help you finding what is what in the doc, but I don't think it will be useful (for Python) if these "specific methods" are not documented as well.
[16:21] <mhall119> davidcalle: are the docs at http://developer.ubuntu.com/api/devel/ubuntu-13.10/python/Unity-7.0.html sufficient for writing a python scope?
[16:21] <mhall119> that's what I'm using
[16:25] <davidcalle> mhall119, not without a tuto.
[16:25] <mhall119> ok, well we have a tutorial for C, so I'll concentrate on those docs first
[16:26] <mhall119> davidcalle: these giraffe docs are pretty sparse though, is there anywhere I can get a short description of what each class is used for, and perhaps what each method does?
[16:35] <davidcalle> mhall119, not that I know of. A lot of them are used by the scope-runner, not by scopes themselves, that's probably why they are not very explicit.
[16:36] <davidcalle> mhall119, I could get you some info about those that are actually used in scopes
[16:39] <tsdgeos> Saviq: http://pastebin.kde.org/pcfzadvzl :-)
[16:39] <tsdgeos> Saviq: looks "good enough" to me
[16:40] <tsdgeos> gonna run the tests now to see if it regresses something and will add my test too
[16:40] <tsdgeos> and submit
[16:40] <Saviq> tsdgeos, "QV8Engine" :?
[16:41] <tsdgeos> Saviq: yeah the naming is amazing :D
[16:41] <Saviq> too many Vs
[16:41] <tsdgeos> their "semi-public" class is still called QV8Engine
[16:42] <tsdgeos> so they now have a QV8Engine::getV4()
[16:42] <tsdgeos> :D
[16:42] <tsdgeos> wonder why
[16:42] <Saviq> tsdgeos, cool, thanks for pushing
[16:42] <Saviq> tsdgeos, it did feel it's an omission as opposed to a conscious decision...
[16:43] <tsdgeos> it does
[16:43] <Saviq> tsdgeos, so that fixes the original 5.0 bug, too, I expect?
[16:43] <tsdgeos> Saviq: sure
[16:43] <tsdgeos> you you don't need the "variable" anymore
[16:43] <Saviq> cool beanz
[16:44] <tsdgeos> just pass it around and that's it
[16:44] <Saviq> tsdgeos, awesome
[17:00] <nic-doffay> Saviq, are you aware of any property in FilterGrid which is bound to the shell height?
[17:00] <Saviq> nic-doffay, there isn't one, but it shouldn't be there
[17:01] <Saviq> nic-doffay, it's the LVWPH that should control that animation, so that it's consistent regardless of whether FilterGrid is used or anything else
[17:03] <nic-doffay> Saviq, I'm not sure I follow. Must the FilterGrid animation be removed then?
[17:04] <Saviq> nic-doffay, there's two separate animations there - we should think of fixing that
[17:05] <Saviq> nic-doffay, tsdgeos will know more, please make sure to talk to him about this tomorrow
[17:06] <tsdgeos> that's going to be a bit of a pain
[17:06] <tsdgeos> but yeah let's talk tomorrow
[17:06]  * tsdgeos eods
[17:07] <Saviq> nic-doffay, but yeah, it feels like there should be no animation on height in FilterGrid itself, but there's probably a reason why it'st here
[17:10] <Wellark> greyback: pong
[17:10] <Wellark> greyback: sorry, didn't notice your ping on "this side" before
[17:10] <greyback> Wellark: no problem, I found what I needed anyway.
[17:10] <nic-doffay> Saviq, sure.
[17:57] <didrocks> mhall119: the french loco would want to discuss about their DPI (Dash Privacy Interface) at vUDS. Do you have a slot for it? https://blueprints.launchpad.net/dash-privacy-interface/+spec/community-1311-loco-projects-introducing-dash-privacy-interface
[17:58] <didrocks> mhall119: preferably in the last day slots


[06:36] <dholbach> good morning
[10:58] <daker> faenil_: is everything OK for the RTL ?
[10:59] <faenil_> daker: sorry?
[10:59] <daker> faenil_: just asking :)
[10:59] <faenil> daker: sorry I don't get the context :)
[11:00] <daker> faenil: you are the person working RTL stuff for UITK, right ?
[11:01] <faenil> daker: ahm...nope :)
[11:01] <daker> faenil: ok
[11:01] <faenil> daker: I just did the ListItemLayout component, and I made it so that RTL should work there :)
[11:01] <daker> ah ok i see
[18:11] <mhall119> beuno: ping
[18:12] <beuno> mhall119, yo
[18:12] <mhall119> beuno: hey, can you add ubuntu-sdk-15.04.1(-*) frameworks to the store ahead of OTA 7 being released?
[18:13] <mhall119> that will allow app developers to publish apps using the latest Ubuntu.Components
[18:13] <beuno> mhall119, I can. I would like, however, for the person who actually uploaded the framework to also get into the habit of adding it to the store as well
[18:14] <mhall119> beuno: you mean the person who puts it in the image?
[18:14] <mhall119> or the person who uploads the API docs
[18:14] <mhall119> because one of those is me :)
[18:14] <beuno> mhall119, the person who uploads it to the archive
[18:14] <mhall119> ok, not me then
[18:14] <mhall119> mvo probably
[18:15] <mhall119> I'd be happy to add them when I get the corresponding docs online, but I don't know what some of the fields are, like policy vendor/policy version
[18:15] <beuno> right, they have to match what is being uploaded
[18:15] <beuno> I don't know it either  :)
[18:16] <beuno> mhall119, so, pass this link along to whoever uploaded it: https://myapps.developer.ubuntu.com/dev/click-apps/frameworks/
[18:16] <mhall119> pmcgowan: ^^ do you know who put the ubuntu-sdk-15.04.1 frameworks on the phone images?
[18:17] <janimo> mhall119, do you happen to have a changelog for 15.04.1 ?
[18:18] <mhall119> janimo: changelog of the framework?
[18:18] <mhall119> beuno: what has to match other than the name?
[18:18] <beuno> mhall119, all the other pieces of metadata
[18:18] <beuno> they are enforced
[18:19] <pmcgowan> mhall119, beuno I think it was sil asking int he other channel, its been someone different every time
[18:20] <mhall119> pmcgowan: we need whomever did it for 15.04.1 to add the corresponding data into the store using the link beuno provided above
[18:21] <mhall119> that will both populate the manifest.json editor dropdown in QtCreator and allow uploading apps using the latest APIs
[18:21] <mhall119> pmcgowan: and while we're at it, we should decide on what the post-OTA7 framework is going to be so we can start getting it setup too
[18:22] <pmcgowan> mhall119, good point
[18:22] <pmcgowan> .2-dev I would think
[18:24] <janimo> mhall119, yes, changelog between 15.04 and 15.04.1 from an app developer pov
[18:24] <mhall119> janimo: ah, no, sorry
[18:24] <mhall119> maybe bzoltan_ can provide something for that
[18:25] <janimo> mhall119, any short summary of what changed? For app devs the it's unclear whether or when they should bump the sdk version
[18:25] <janimo> apart from the 'use latest stable' advice
[18:27] <mhall119> janimo: new components like AdaptivePageLayout
[18:27] <mhall119> but I don't know the specifics
[18:45] <bzoltan_> janimo:  it is hard to say what interests you... the UITK chanegs can go to super detailed level. Please check out the changelog http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/debian/changelog and see if you find any exciting new feature or important bugfix. I personally do recommend to use  the latest stable release
[22:10] <gerlowskija> Does anyone know to what extent golang is supported for scope development.  I've found a number of tutorials and other resources for Go development, but it's not listed as an option for scope development here: https://developer.ubuntu.com/api/scopes/, and I'm having trouble finding SDK documentation for golang (the C++ SDK docs are here, for comparison: https://developer.ubuntu.com/api/scopes/cpp/sdk-15.04/)
[22:14] <gerlowskija> fwiw I found some golang SDK docs on golang.org, but they seem to be a release behind the current C++ docs (15.04), and many of the links pointing to developer.ubuntu.com pages are broken.
[22:14] <gerlowskija> I'd love to use go-lang to develop my scope, just wanted to check if the go framework was maybe deprecated or something.
[22:31] <gerlowskija> (Just saw this trick in the channel topic.  Hope it isn't too 'loud' as notifications go: appdevs ^^
[22:34] <ahayzen> gerlowskija, searching for "Go" returns https://developer.ubuntu.com/en/gomobile/ but that redirects you back to the start page
[22:35] <ahayzen> and https://developer.ubuntu.com/en/scopes/tutorials/developing-scopes-go/
[22:38] <gerlowskija> Right, I'd found the tutorials, I guess I was looking for SDK docs more than anything.  The ones on golang.org have a few broken links that make them a bit tough to use (e.g. https://developer.ubuntu.com/en/api/scopes/sdk-14.10/previewwidgets/, https://developer.ubuntu.com/en/api/scopes/sdk-14.10/previewwidgets/)
[22:40] <ahayzen> gerlowskija, mhall may know as he does the docs.. otherwise i would ask tomorrow in the day EU timezone when more people are likely to be around
[22:40] <gerlowskija> I can infer things based on the corresponding C++ pages, so I don't *need* to find Go-specific versions of those pages, but I also wanted to allay my worry that golang only currently enjoys partial support.  Glad to hear it's fully supported!
[22:41] <gerlowskija> Thanks for responding ahayzen, I'll try tomorrow at some point then.
[22:41] <ahayzen> no problem :-)