=== xnox_ is now known as xnox === lderan_ is now known as lderan === vrruiz_ is now known as rvr [12:41] thomi, did the new autopilot land with my needed apparmor changes? [12:41] balloons: yes [12:41] balloons: I wonder if you could please help us get the 1.5 docs online? [12:42] we *really* need them to be online now [12:42] thomi, I thought we took care of all that in Malta. I'll ping dpm again to sync [12:43] balloons: AFAICT they're still not online [12:43] indeed, I agree.. I still see 1.4 [12:45] balloons, were the apparmor changes todo with the fix to writing to /tmp by using the autopilot/fakeenv? [12:47] ahayzen_, the apparmor changes in the last AP release were supposed to solve our /tmp issue yes [12:48] balloons, hmmm i tried to resolve the issue, i'm correct in thinking we had to move to ~/autopilot/fakeenv like the calendar? [13:11] afternoon elopio [13:14] thomi, ping... got a sec? [13:14] cgoldberg: maybe, what's up? [13:15] thomi, quick question with my video branch.. stuck replacing that sleep statement i was working on my last day at malta [13:15] I'm trying to check for the recordmydesktop /tmp directory before I stop the video capture. [13:15] It looks like testtools PathExists() matcher doesn't work with globs/wildcards.. you need an exact directory name (which is unknown before the test starts). Got another idea how I can check if the /tmp/rMD-session* directory eventually exists? [13:16] cgoldberg: why not use glob.glob, and wait till it doesn't equal the old value? [13:17] ah.. nice.. that should work. just wait in a loop until timeout? [13:17] cgoldberg: use the EVentually matcher :) [13:17] cgoldberg: which takes a callable [13:17] self.assertThat(lambda: glob.glob(...), Eventually(NotEquals(old_value))) [13:17] or something like that [13:18] cool... that should do [13:18] thanks much [13:18] btw, I marked my branch as WIP, but will resubmit for review in a little bit once I push that up... if you have any time to look [13:20] thomi, david says https://launchpad.net/ubuntu/utopic/amd64/python3-autopilot/1.5.0+14.10.20140526.1-0ubuntu1 still contains AP 1.4 docs [13:21] thomi, also on this; https://code.launchpad.net/~thomir/ubuntu-calendar-app/trunk-fix-ugly-bits/+merge/221099, I find the local_location_qml change interesting. [13:23] I guess it's simpler and still relative; I'll adopt it [13:26] balloons: hello! [13:26] balloons: sorry, I really don't have time to look now - can you ping me tomorrow if it's still outstanding please? [13:26] how are you feeling now? [13:28] thomi, the 1.4 docs is the important bit.. I was just commenting on your proposed merge; I don't need you to look at it, sorry to confuse [13:28] balloons, regarding AP docs. I just looked at the sphinx conf.py, and I see there might be an issue with the version it reports if for example you download the tarball [13:29] balloons, it pulls the version number from debian changelog. if you have a source tarball and no changelog, it defaults to whatever is specified in conf.py... which is currently: [13:30] # The short X.Y version. [13:30] version = '1.4 [13:30] cgoldberg, ahh.. that would be why then [13:30] so the 1.5 docs are up, they simply say 1.4 [13:30] balloons, thats what it looks like. I'll MP a fix to conf.py [13:31] elopio, feeling a bit more alive.. I think I'm on the road to recovery now [13:32] cgoldberg, shall we tweak the current docs to say 1.5 in the interim? [13:33] balloons, if you have access, yes.. since my change won't land until next release [13:33] you can either regenerate the docs with the changelog present.. or just hack the generated html [13:33] cgoldberg, sure thing, will do [13:42] balloons, this should do it: https://code.launchpad.net/~coreygoldberg/autopilot/fix-docs-version/+merge/221381 we'll land it for next release [15:28] elopio, you EOD? [15:28] balloons: nop. [15:29] fighting autopilot weird view on inheritance. [15:29] elopio, how far along did you get on the sdk helper for env setup? [15:29] balloons: for home? [15:29] it's merged into staging. [15:29] yes [15:30] oO, can I see? I've been working on it this morning with Jamie, and I think calendar finally works [15:31] however we have something to discuss with it. We have to create 9 directories atm; not sure if more will be needed or not.. Jamie says /home is setup for clicks and they are prevented from making any dirs themselves [15:31] he suggested cloning /home into our temp_dir and pruning what we don't want [15:32] as it stands, we make the new /home and set it up from scratch. If something changes in /home, our helper will need to change else apparmor errors will sweep the tests [15:33] balloons: https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1317639-patch_home/+merge/220805 [15:34] elopio, so that won't work out of the box on the phone [15:34] balloons: all that you are mentioning is new to me. That's why you can't get sick anymore :) [15:35] elopio, yes I didn't want this to linger all week.. I'm sorry :-( [15:35] I didn't know it wouldn't work without additional tweaks either.. until I can confirm, I leave room for error [15:35] balloons: don't worry, I'm joking. [15:35] lol.. I know.. at least about the being sick part [15:35] balloons: so is this usable at all? [15:36] elopio, have a look at this mp: https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/fix-ap-env-setup/+merge/221416 [15:37] it seems to work for calendar. You can see the 9 dirs I create; everything else is the same, but I do additional post-setup work. [15:37] As it stands, yes your branch will work, but the additional dir creation would have to be done in the test in order for apparmor to not whine [16:15] elopio, does what I said above make sense? ^^ [16:19] balloons: sorry, I got distracted with a branch. [16:19] balloons: wow, so many things to create. [16:20] the other way, we would have to delete only one dir from home with the name of the app, right? [16:22] elopio, well, we would need to cleanup anything we felt could potentially mess with the results I guess.. [16:22] Or maybe just anything we know the test writes in [16:22] which sort of leads us back to where we started with backing up directories [16:23] we also have the time and potentially storage issues of running a full copy on /home [16:24] I don't like the idea, as it's just not the clean solution we are looking for. I don't care if we have to make 20 dirs, as long as we can be assured we've setup things properly and won't break stuff [16:30] balloons: I meant, make a new temp home, and copy into it everything that was on the real home [16:31] except the directory with the application data. [16:31] and the new temp dir, or we will end in wonderland. [16:34] elopio, yes.. see my concerns with doing the copy above [16:34] 1) storage space [16:34] 2) time to copy if many files [16:34] 3) potential hidden conflicts [16:34] 4) some apps do write to other dirs (music for instance uses mediascanner) [16:35] balloons: ahh, sorry, my brain is about to stop. [16:35] 5) Not as clean as setting up a pristine environment ;-) [16:35] balloons: ok, then lets make the 9 directories. [16:35] elopio, I feel the same way, different reason though, heh [16:35] and we need a better test on the toolkit that tells us if we could launch the app, so it will break when app armor rules change. [16:35] elopio, well I'm concerned about both approaches.. the thing I think that stops me on the copy is the storage issue [16:36] balloons: wait a second while I go up to my room [16:36] * elopio migrates to a warmer place. [16:43] balloons: I'm back. [16:43] elopio, warmer I hope? :-) [16:44] starting to get warmer. The cleaning lady keeps turning on the air. [16:56] elopio, so I guess we'll go with the create the dirs approach then? I wouldn't worry about modifying your helper just yet.. We need this in a few apps, so I'm going to push the function as part of _init_.py. I want to ensure we're not missing a directory for instance :-) [16:56] once everything is converted over we'll see where we land [16:56] balloons: I will start thinking how to test it on the SDK [16:57] my helper in any of the two approaches just needs more directories. We can create them, or copy them. I'm not sure which one is best, so either way seems fine for now. [18:21] balloons, just read scrollback. do you need environment isolation between tests? as in... do you want to create the dirs once for a test suite.. or do you want it created fresh between each test? might be nice to use a Fixture instead of adding to __init__.py . just wondering if the env gets poluted between tests [18:57] cgoldberg, https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1317639-patch_home/+merge/220805 [18:59] balloons, right.. so don't you wanna add your dirs there, instead if in __init__ of every app test suite? [19:00] cgoldberg, most certainly.. the helper will need updated [19:02] balloons, cool. that gives you nice isolation.. especially if you remove the dirs in the Fixture as a Cleanup step [19:04] and as to the copy vs. create... both are feasible.. but I wouldn't copy existing /home. I think it would be better to create a fresh env structure in your source tree and copy that. or else just create them in the fixture [19:07] balloons, let me know if you need a hand... I like small tasks besides hacking Autopilot itself :) [19:11] cgoldberg, well I'm still seeing apparmor issues.. [19:12] calendar works, but music doesn't.. and I'm seeing issues in calc even though it's not been migrated [19:12] I'd prefer to construct things as opposed to copy [19:14] balloons, that's fine. the end result is the same if you are copying from a known source (not existing /home) ... my main point was to do them in a Fixture instead of __init__ [19:15] cgoldberg, check on the fixture.. The idea of copying a prisitine source is interesting, but you would have to bundle it with the toolkit [19:15] well the toolkit helper [19:16] right... you check in a pristine dir. and have your test call a fixture that sets up and tears down the env between tests [19:17] basically a hybrid your yours and Leo's branch :) [19:17] with some dirs checked into bzr [19:18] I guess that's an implementation detail for the helper :-) [19:18] I still think I prefer the creation [19:18] mostly I just want it to work [19:18] heh [19:21] fair enough :)