#ubuntu-autopilot 2014-05-26
<alesage_> nik90_, ping
<nik90_> alesage_: pong
<alesage_> nik90_, hi, charles and I are investigating a clock-app-related bug
<alesage_> nik90_, having some trouble getting the autopilot tests running though, wonder if you can advise
<nik90_> alesage_: hi, yeah I just saw your comment on th ebug
<nik90_> alesage_: so are you running the tests on the device or on the desktop?
<alesage_> nik90_, on the desktop
<nik90_> alesage_: ok. Can you check the version of qtdeclarative5-ubuntu-ui-toolkit-plugin.
<nik90_> alesage_: The last I checked, the SDK did have a function called click_action_button()...although the error log says otherwise
<nik90_> I will run that test on my desktop and check now
<alesage_> nik90_, thanks, my version is 0.1.46+14.04.20140408.1-0ubuntu1
<nik90_> alesage_: can you make sure you have 0.1.46+14.10.20140520-0ubuntu1~0trusty2
<alesage_> nik90_, are you on a PPA?
<nik90_> alesage_: yeah, I am using the SDK PPA for 14.04 as recommended by the SDK team
<alesage_> nik90_, are you able to run these clock-app autopilot tests on a device proper?  finding some setup errors http://pastebin.ubuntu.com/7520055/
<nik90_> alesage_: yeah I can run the tests on the device without any issue
<alesage_> nik90_, you're using the phabet-test-runner, or from the source?
<nik90_> alesage_: the way I run it is by, "phablet-click-test-setup" which sets up your deivce
<alesage_> nik90_, ok new information thanks
<nik90_> alesage_: then, "click-buddy --dir . --provision" from inside the clock app source folder which will install clock app tests on your device
<nik90_> alesage_: then a simple "phablet-test-run -v ubuntu-clock-app" shoudl work
<alesage_> nik90_, thanks
<nik90_> alesage_: np
<alesage_> nik90_, consider adding the above to the readme, eh?
<alesage_> for the testing pleasure of future generations :)
<nik90_> alesage_: true, I should do that..the thing is the instructions keep changing...but a readme is still a good idea
#ubuntu-autopilot 2014-05-27
<ahayzen> Hi, i'm trying to run autopilot on device (#51utopic) for the music-app but i keep getting ImportError: No module named 'ubuntuuitoolkit' any ideas what I have done wrong?
<elopio> barry: do you know why your dialer py3 branch is failing?
<barry> elopio: i don't
<barry> raise StateNotFoundError(type_name, **kwargs)
<barry> autopilot.exceptions.StateNotFoundError: Object not found with name '*' and properties {'objectName': 'historyDelegate0'}.
<barry> elopio: i'll merge in trunk (which has changed a bit) and re-push.  let's see if that helps
<thomi> ahayzen: Hi - it sounds like you don't have the ubuntu-ui-toolkit-autopilot package installed
<ahayzen> thomi, hmm how does that get installed on device? phablet-click-test-setup ?
<thomi> ahayzen: ummm, I'm not actually sure - I thought it was in the image seed, but perhaps not.
<thomi> ahayzen: this should be all you need: https://wiki.ubuntu.com/Touch/Testing
 * ahayzen notices some strange bzr errors and runs it again
<ahayzen> thomi, cool thanks :) ... also do you know anything about the issue of autopilot trying to write to /tmp ?
<thomi> ahayzen: I know that autopilot writes to /tmp, I wasn't aware there was an issue
<ahayzen> thomi, i believe calendar was fixed? but i think we (music-app) suffer the same issue https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1319382
<ubot5> Ubuntu bug 1319382 in Ubuntu Music App "apparmor denials during autopilot testing" [High,Triaged]
<thomi> ahayzen: ahhhhh, I've just been looking at that code
<ahayzen> thomi, we are going to try and land this soon https://code.launchpad.net/~music-app-dev/music-app/use-mediascanner2.0/+merge/214140 which redoes alot of autopilot stuff but it still suffers the same issue
<thomi> ahayzen: The first pass fix is in, I believe, but it needs some bug fixing
<thomi> ahayzen: check out the recent revisions to calendar-app maybe
<ahayzen> thomi, ok thanks
 * thomi reads the MP
<ahayzen> thomi, autopilot is running now \o/ not sure what happened before had things like 'bzr: ERROR: Server sent an unexpected error'
<thomi> ahayzen: :-/
<thomi> ahh well, at least it works now
<ahayzen> thomi, i'll retry the mediascanner2 branch see if that suffers the same apparmor stuff we had last week
<thomi> ok
<thomi> sorry I can't be more useful. balloons should be back soon I think
<ahayzen> yeah must have picked up something in malta :( poor balloons
<cgoldberg> barry.. ping ... got a sec?   I was just reading about API changes in psutil 2.0 package ... and ran across your request to get psutil updated in debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741291
<ubot5> Debian bug 741291 in src:python-psutil "python-psutil: Please update to psutil 2.0" [Normal,Fixed]
<barry> cgoldberg: yep
<barry> cgoldberg: fwiw, i just fixed a related breakage in system-image
<cgoldberg> barry.  we use psutil inside Autopilot.  seems easy to port to 2.0... but I'm trying to figure out when that package will reach Ubuntu?
<barry> cgoldberg: utopic has 2.1.1 now
<barry> (trusty still has 1.2.1)
<cgoldberg> barry.. wow.. and Autopilot didn't break in Utopic?
<cgoldberg> ah.. most API changes are just deprecated, not removed
<barry> cgoldberg: yep.  the one that broke for me is Process.cmdline -it's now a function
<ahayzen> thomi, yeah it is still being denied things to /tmp i'll see if i can patch up similar to calendar, thanks for your help :)
<elopio> barry: yes, thanks. I'll take a look in a while.
<barry> cgoldberg: https://github.com/giampaolo/psutil/blob/master/HISTORY.rst#200---2014-03-10
<cgoldberg> yea.. i know we use get_children in Autopilot... and maybe a few other things.    I'll search the Autopilot codebase and see what else we use and create a task for my team of porting to psutil 2.x
<barry> cgoldberg: cool.  let me know if i can help
<cgoldberg> barry, thanks.  I hope it will be trivial though
<barry> cgoldberg: should be i think.  np!
<cgoldberg> although, i think there are areas around process management that we don't use psutil for and we probably should
 * thomi makes a sadface at psutil landing without running the AP tests
<thomi> cgoldberg: can you figure out if that's actually broken something, and if it has, barry can we back it out please?
<thomi> I'm getting uo to my EOD :(
<cgoldberg> thomi, I'm not here btw :)  day off.. just stopped in because i read a blog post about psutil
<thomi> doh :(
<cgoldberg> thomi, want me to add a task to our backlog for porting to psutil 2.x ?
<barry> thomi: i don't think we should back out psutil update.  the api differences should be easy to work around, even if you want to maintain pre-2.0 compatibility
<cgoldberg> i can do the port once after I get my video fixture landed
<thomi> cgoldberg: well, I'd rather have it fixed than have a card, but sure, knock yourself out :)
<thomi> barry: I guess i'm woried about "autopilot being broken" right now in the image, since we've just made a release
<thomi> I can see it'd be easy for people to do a 2+2=5
<cgoldberg> thomi, i can get it fixed this week.. but will put a card up so i dont forget :)
<barry> cgoldberg: thanks.  yeah, it would be a royal PITA to revert the psutil update in utopic
<cgoldberg> thomi, i'm still trying to decipher if anything broke, or if we are just getting deprecation messages
<cgoldberg> thomi, card added.. I'll chase it down tomorrow
<cgoldberg> l8r
<thomi> cgoldberg: thanks
#ubuntu-autopilot 2014-05-28
<elopio> barry: there's a wrong import on the dialer branch.
<barry> elopio: looking
<barry> that should be an easy fix
<barry> not even needed in py2 :)  pushed r137
#ubuntu-autopilot 2014-05-29
<balloons> thomi, did the new autopilot land with my needed apparmor changes?
<thomi> balloons: yes
<thomi> balloons: I wonder if you could please help us get the 1.5 docs online?
<thomi> we *really* need them to be online now
<balloons> thomi, I thought we took care of all that in Malta. I'll ping dpm again to sync
<thomi> balloons: AFAICT they're still not online
<balloons> indeed, I agree.. I still see 1.4
<ahayzen_> balloons, were the apparmor changes todo with the fix to writing to /tmp by using the autopilot/fakeenv?
<balloons> ahayzen_, the apparmor changes in the last AP release were supposed to solve our /tmp issue yes
<ahayzen_> balloons, hmmm i tried to resolve the issue, i'm correct in thinking we had to move to ~/autopilot/fakeenv like the calendar?
<balloons> afternoon elopio
<cgoldberg> thomi, ping... got a sec?
<thomi> cgoldberg: maybe, what's up?
<cgoldberg> thomi, quick question with my video branch.. stuck replacing that sleep statement i was working on my last day at malta
<cgoldberg> I'm trying to check for the recordmydesktop /tmp directory before I stop the video capture.
<cgoldberg>  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?
<thomi> cgoldberg: why not use glob.glob, and wait till it doesn't equal the old value?
<cgoldberg> ah.. nice.. that should work.  just wait in a loop until timeout?
<thomi> cgoldberg: use the EVentually matcher :)
<thomi> cgoldberg: which takes a callable
<thomi> self.assertThat(lambda: glob.glob(...), Eventually(NotEquals(old_value)))
<thomi> or something like that
<cgoldberg> cool... that should do
<cgoldberg> thanks much
<cgoldberg> 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
<balloons> 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
<balloons> 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.
<balloons> I guess it's simpler and still relative; I'll adopt it
<elopio> balloons: hello!
<thomi> balloons: sorry, I really don't have time to look now - can you ping me tomorrow if it's still outstanding please?
<elopio> how are you feeling now?
<balloons> 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
<cgoldberg> 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
<cgoldberg> 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:
<cgoldberg> # The short X.Y version.
<cgoldberg> version = '1.4
<balloons> cgoldberg, ahh.. that would be why then
<balloons> so the 1.5 docs are up, they simply say 1.4
<cgoldberg> balloons, thats what it looks like.  I'll MP a fix to conf.py
<balloons> elopio, feeling a bit more alive.. I think I'm on the road to recovery now
<balloons> cgoldberg, shall we tweak the current docs to say 1.5 in the interim?
<cgoldberg> balloons, if you have access, yes.. since my change won't land until next release
<cgoldberg> you can either regenerate the docs with the changelog present.. or just hack the generated html
<balloons> cgoldberg, sure thing, will do
<cgoldberg> balloons, this should do it:  https://code.launchpad.net/~coreygoldberg/autopilot/fix-docs-version/+merge/221381   we'll land it for next release
<balloons> elopio, you EOD?
<elopio> balloons: nop.
<elopio> fighting autopilot weird view on inheritance.
<balloons> elopio, how far along did you get on the sdk helper for env setup?
<elopio> balloons: for home?
<elopio> it's merged into staging.
<balloons> yes
<balloons> oO, can I see? I've been working on it this morning with Jamie, and I think calendar finally works
<balloons> 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
<balloons> he suggested cloning /home into our temp_dir and pruning what we don't want
<balloons> 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
<elopio> balloons: https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1317639-patch_home/+merge/220805
<balloons> elopio, so that won't work out of the box on the phone
<elopio> balloons: all that you are mentioning is new to me. That's why you can't get sick anymore :)
<balloons> elopio, yes I didn't want this to linger all week.. I'm sorry :-(
<balloons> I didn't know it wouldn't work without additional tweaks either.. until I can confirm, I leave room for error
<elopio> balloons: don't worry, I'm joking.
<balloons> lol.. I know.. at least about the being sick part
<elopio> balloons: so is this usable at all?
<balloons> elopio, have a look at this mp: https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/fix-ap-env-setup/+merge/221416
<balloons> 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.
<balloons> 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
<balloons> elopio, does what I said above make sense? ^^
<elopio> balloons: sorry, I got distracted with a branch.
<elopio> balloons: wow, so many things to create.
<elopio> the other way, we would have to delete only one dir from home with the name of the app, right?
<balloons> elopio, well, we would need to cleanup anything we felt could potentially mess with the results I guess..
<balloons> Or maybe just anything we know the test writes in
<balloons> which sort of leads us back to where we started with backing up directories
<balloons> we also have the time and potentially storage issues of running a full copy on /home
<balloons> 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
<elopio> balloons: I meant, make a new temp home, and copy into it everything that was on the real home
<elopio> except the directory with the application data.
<elopio> and the new temp dir, or we will end in wonderland.
<balloons> elopio, yes.. see my concerns with doing the copy above
<balloons> 1) storage space
<balloons> 2) time to copy if many files
<balloons> 3) potential hidden conflicts
<balloons> 4) some apps do write to other dirs (music for instance uses mediascanner)
<elopio> balloons: ahh, sorry, my brain is about to stop.
<balloons> 5) Not as clean as setting up a pristine environment ;-)
<elopio> balloons: ok, then lets make the 9 directories.
<balloons> elopio, I feel the same way, different reason though, heh
<elopio> 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.
<balloons> elopio, well I'm concerned about both approaches.. the thing I think that stops me on the copy is the storage issue
<elopio> balloons: wait a second while I go up to my room
 * elopio migrates to a warmer place.
<elopio> balloons: I'm back.
<balloons> elopio, warmer I hope? :-)
<elopio> starting to get warmer. The cleaning lady keeps turning on the air.
<balloons> 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 :-)
<balloons> once everything is converted over we'll see where we land
<elopio> balloons: I will start thinking how to test it on the SDK
<elopio> 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.
<cgoldberg> 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
<balloons> cgoldberg, https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1317639-patch_home/+merge/220805
<cgoldberg> balloons, right.. so don't you wanna add your dirs there, instead if in __init__ of every app test suite?
<balloons> cgoldberg, most certainly.. the helper will need updated
<cgoldberg> balloons, cool.  that gives you nice isolation.. especially if you remove the dirs in the Fixture as a Cleanup step
<cgoldberg> 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
<cgoldberg> balloons, let me know if you need a hand... I like small tasks besides hacking Autopilot itself  :)
<balloons> cgoldberg, well I'm still seeing apparmor issues..
<balloons> calendar works, but music doesn't.. and I'm seeing issues in calc even though it's not been migrated
<balloons> I'd prefer to construct things as opposed to copy
<cgoldberg> 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__
<balloons> cgoldberg, check on the fixture.. The idea of copying a prisitine source is interesting, but you would have to bundle it with the toolkit
<balloons> well the toolkit helper
<cgoldberg> right... you check in a pristine dir. and have your test call a fixture that sets up and tears down the env between tests
<cgoldberg> basically a hybrid your yours and Leo's branch :)
<cgoldberg> with some dirs checked into bzr
<balloons> I guess that's an implementation detail for the helper :-)
<balloons> I still think I prefer the creation
<balloons> mostly I just want it to work
<balloons> heh
<cgoldberg> fair enough :)
#ubuntu-autopilot 2014-05-30
<balloons> elopio, ping! perchance do you know where francis is at in Malta?
<balloons> or someone else from ci who can have a look?
<elopio> balloons: I can see robru in this room. The rest are either having coffee or at a meeting about stress testing.
<balloons> elopio, <3. I need someone to restart http://91.189.93.70:8080/computer/mediumtests-utopic-slave/?
<elopio> they are all back now.
<balloons> thanks elopio
#ubuntu-autopilot 2015-05-26
<thomi> elopio: is veebers sick these days? or did he stay over in FL?
<elopio> thomi: he stayed.
<thomi> ahh
<thomi> you enjoy the sprint?
<elopio> thomi: I did. Nice to be in a sunny place, for a change.
<elopio> how are you doing these days?
<thomi> heh.. I'm doing well. microservices have got me keeping busy :D
<thomi> I know more juju and mojo than I want to :D
#ubuntu-autopilot 2015-05-28
<nik90> elopio: ping
#ubuntu-autopilot 2016-06-03
<Dav> Hello Everyone
<Dav> Can someone tell me how to get the Autopilot plugin for Qt?
<Dav> I get the error when run this command: sudo apt-get update && sudo apt-get install qtcreator-plugin-autopilot
<dobey> Dav: is that some openstack thing?
<dobey> and yes, it appears to not exist in the ubuntu archive, so you'd get an error, since there is no such package
<Dav> right, so what else can I do to get it?
<dobey> well, i have no idea what you're asking about
<dobey> if it's some openstack autopilot then, then you should probably ask in #ubuntu-openstack
<dobey> this channel is about the autopilot gui testing framework
