#ubuntu-autopilot 2014-05-08
<fginther> thomi, regarding the slowness with archiving artifacts... Jenkins has a little quirk, it can run multiple instances of a job at once, but it has to complete them in order
<fginther> so build #200 was probably stuck waiting for build #199 to finish
<thomi> ugh
 * thomi slow claps for jenkins
<fginther> :-)
<veebers> thomi: fyi https://code.launchpad.net/~veebers/autopilot/fix-type_name-str-conversion/+merge/218726
<balloons> ping elopio
<elopio> balloons: pong
<balloons> elopio, I was wondering if you could review this MP quickly; https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/mock-test-env/+merge/218494. I'm trying to fix how tests setup and launch and I believe this is how it should look
<elopio> balloons: yes! nice. I'll look at it.
<balloons> excellent.. there is some small tweaks I'll want to do to reminders as well.. namely add the _patch_home function
<elopio> balloons: there's a InitctlEnvironmentVariable in ubuntuuitoolkit.fixture_setup that takes care of the clean up.
<elopio> balloons: you should use that, because if the variable had a previous value, you shouldn't unset it. You should return to that previous value.
<balloons> elopio, ahh, gotcha
<elopio> balloons: and your fake home is a perfect candidate to be added to ubuntuuitoolkit.fixture_setup
<elopio> many apps will use it.
<balloons> elopio, in theory everything should use it
<elopio> yes, that would be safer and cleaner.
<elopio> balloons: I remember that I patched the home for filemanager tests. And then they started failing because the app had no access to the tmp dir on the phone.
<elopio> is that different now?
<balloons> elopio, I know I did stuff as well with fm. As it stands now, I make a temp directory, then force the tests to navigate to it before running
<balloons> elopio, https://code.launchpad.net/~nskaggs/ubuntu-filemanager-app/setup-ap-env/+merge/218836. I did fm this way too.. I think it's fine
<elopio> ok.
<balloons> elopio, sorry.. so I changed file manager to be the same as what you are looking at with calendar. I meant to say, in trunk it uses the temp dir, plus navigate to it first
<elopio> yes, I was just wondering what happened there.
<elopio> balloons: I don't like that the way we select the binary to run. That's related to my cmake branch with the run task.
<balloons> elopio, I actually spoke with thomi a little about using cmake to run tests
<elopio> I would prefer something like autopilot run ubuntu-filemanager-app LAUNCHER=click BINARY_PATH=/opt/.../
<balloons> he was concerned about making non-standard ways of doing things.. in other words he'd like to always see autopilot as the runner
<balloons> I told him we'd prefer args passing :-)
<elopio> well, autopilot is the runner. We are using cmake just because it knows the paths.
<balloons> yes, but the call is through cmake
<balloons> which he wasn't so keen on
<elopio> balloons: so what does he propose as a way to know the path?
<balloons> so I quickly did reminders as well; lp:~nskaggs/reminders-app/setup-ap-env
<balloons> elopio, passing the args I think works for him
<balloons> and in our case if we then use cmake to make the call anyway, perhaps it's fine
<balloons> he just didn't like not being able to run the tests without having cmake installed
<elopio> balloons: he will be able. He would just have to know the paths.
<balloons> elopio, right, so I think as you just proposed works fine
<balloons> but AP needs to support passing args is all
<balloons> which he said is on the list :-)
<elopio> I have tons of emails to read. Today I won't code more, I will read and reply :)
<elopio> balloons: anyway, that's something we can add later to your branch.
<balloons> so elopio you are saying I should get_initctl_env_var first, then set it back it's initial value rather than set, and unset it
<elopio> balloons: no, I'm saying that you should call self.useFixture(ubuntuuitoolkit.fixture_setup.InitctlEnvironmentVariable(HOME=temp_dir))
<elopio> it will take care of everything.
<balloons> ahh, I see now
 * balloons opened fixture_setup
<balloons> elopio, so, the patching of home could be the same.. just a fixture
<elopio> balloons: yes, the python module has fixture for that
<balloons> ok, so I won't rampage beyond the 3 apps I've done and we should plan to go that route
<elopio> temp_dir_fixture = fixtures.TempDir()
<elopio> self.useFixture(temp_dir_fixture)
<elopio> temp_dir = temp_dir_ficture.path
<elopio> self.useFixture(fixtures.EnvironmentVariable('HOME', newvalue=temp_dir)
<elopio> balloons: that will make your code a lot smaller.
<balloons> elopio, that would be inplace of using the patcher on the desktop.. but not for click, correct?
<elopio> balloons: yes, for click you would use InitctlEnvironmentVariable from the toolkit.
<elopio> balloons: what is Xauthority for?
<balloons> elopio, that's for jenkins only. if you mess with /home it will fail to spawn the xsession
<elopio> balloons: that would be nice as a comment on the code.
<balloons> elopio, :-)
<balloons> elopio, updated the mp
<elopio> balloons: you need to copy the xauthority before the useFixtures that update HOME
<balloons> elopio, bah, good catch
<elopio> balloons: also, it would be clearer if you wrap that part in a copy_xauthority file.
<elopio> * copy_xauthority_file method.
<balloons> really another method? ok, can do
<elopio> balloons: yes, methods are good :)
<elopio> balloons: do you want me to make the fixture for this on the toolkit ?
<balloons> elopio, yes that's a good idea
<elopio> balloons: ok, please report a bug for me and it will be on my todo for next week.
<elopio> or maybe tomorrow, looks fun.
<balloons> elopio, :-) Yes, I'll try and hold off on rampaging through all the apps.. But I need to fix a few, so I'll push this version to those
<elopio> ok
<elopio> balloons: final comment, I think that def setup_environment(self): would be better named get_launcher_and_type
<elopio> but, that's the part I would remove.
<balloons> elopio, ok. what do you mean you would remove?
<balloons> the method altogether?
<elopio> balloons: yes. If we tell from the runner that we want to launch the click app, there's no need to check which paths exist.
<balloons> mmm.. true, but at the moment we're forced to guess
<elopio> balloons: yes.
<balloons> so you don't forsee a need in the future to have a get_launcher_and_type method.. So for now should I move it into setup?
<balloons> btw, setUp drives me crazy.. I just realized it's not sanely setup, all lowercase
<elopio> no no no.
<elopio> methods are good.
<elopio> it's easier to remove it later if it's in a separate method.
<balloons> I agree, just confused by what you were saying I guess. Ok, so I'll rename it
<elopio> it should be set_up, as the gods of python would have wanted it.
<balloons> setup is one word :-)
<elopio> really?
<balloons> I would support setUp over set_up if it was two words
<elopio> balloons: what is this for?
<elopio> 106	+ '-q', self.local_location_qml,
<balloons> ahh yes.. I meant to mention that. I added back code to find the local qml file and pass it. We do it for the installed version, so we should do it for the local version also
<balloons> imho, nothing wrong with being explicit. Although in theory the binary was updated to just find the proper qml file as needed
<balloons> I did the same with file manager
<balloons> elopio, care to put your stamp on https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/mock-test-env/+merge/218494?
<elopio> balloons: sure. Thanks for making the changes.
<balloons> elopio, ty.. and https://code.launchpad.net/~nskaggs/ubuntu-filemanager-app/setup-ap-env/+merge/218836 too.. I take it you've seen the reminders mp also :-)
<elopio> balloons: on the reminders one, you need a commit message.
<balloons> :- done
<elopio> balloons: hey, one thing about this
<elopio> 29	- local_location_binary = '../../src/app/reminders'
<elopio> 30	+ local_location = os.path.dirname(os.path.dirname(os.getcwd()))
<elopio> oh, no, I get it.
<balloons> k
<elopio> balloons: now, we need to discuss what to do with the oauth evernote token.
<elopio> if we just put it on the branch, somebody could mess with our account affecting the tests.
<elopio> we could revoke it and update the test with the new one, so might not be a big deal.
<elopio> but it's a hole.
<balloons> ping barry
<barry> balloons: pong
<balloons> barry, so playing with file manager and I noticed it was still running as py2. I investigated in phablet-test-run and found the import check for python3
<balloons> it fails if you give a full test name it seems for file manager
<balloons> barry, ie,  ImportError: No module named 'filemanager.tests.test_filemanager.TestFolderListPage'; 'filemanager.tests.test_filemanager' is not a package
<barry> balloons: what's the command line you used?
<balloons> barry, phablet-test-run -v filemanager.tests.test_filemanager.TestFolderListPage.test_cut_directory
<balloons> elopio, the token can be inserted at build time, just like the weather app
<barry> balloons: i have to think that's a bug in autopilot3
<barry> i don't remember how it's doing test discovery
<balloons> oO, I get to blame thomi eh?
<balloons> I don't remember.. but I like the idea of blaming
<barry> esp. since he's not here yet :)
<elopio> balloons: that's more likely because you don't have some py3 dependencies installed.
<elopio> I've been running with autopilot3 and I generally use the full test name.
<balloons> elopio, essentially jenkins has the token and the job will insert it when it runs. the source tree will have a config file with the token info blanked
<balloons> elopio, yea, I don't remember ever seeing this issue before
<elopio> balloons: that sounds pretty cool.
<elopio> how do I do it?
<balloons> elopio, but then again, on the desktop you are running directly.. on the phablet, unless it blows up maybe I never noticed it was secretly running as py2
<balloons> elopio, we talk to fginther about it, but we'll mimic weather.. I don't think it's pressing so I don't want to mess with it atm
<elopio> balloons: ok. Lets just not forget about it.
<balloons> trying to close down open issues, not make more, heh :-) I wouldn't hold your merge on it
<elopio> later I can revoke this, and give the new one to francies.
<balloons> elopio, right, we can go through that process if it comes to it
<elopio> balloons: what seems to be holding it now is that the jenkins runner is offline.
<elopio> fginther already applied a change suggested by mardy, and my debug branch has passed.
<elopio> I would like to confirm on the real branch before merging it.
<balloons> elopio, I'll file a bug about the token now
<balloons> elopio, well  now I've got fm running via py3, I'm still getting autopilot.introspection.dbus.StateNotFoundError: Object not found with name '<class 'filemanager.emulators.Popover'>'.
<balloons> it's weird.. hmm
<elopio> balloons: that doesn't happen with py2? that would be weird indee.
<elopio> *indeed
<balloons> elopio, I'm thinking it might be a name change thing from ubuntu_filemanager_app -> filemanager
<robotfuel> balloons: the manifest.json has the right name filemanager
<balloons> it's just bizarre as I see the Popover class in emulators.. and inside the module, under the proper directory..
<balloons> ohh.. heh, I think the explanation is much simpler.. I get it now.. nevermind. The tests are actually failing
<balloons> the popover isn't being found.. but the code is ;-)
<balloons> barry, so looks like I get to blame phablet-test-run instead ;-)
<barry> balloons: yay!
<balloons> elopio, https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1317639. can't assign for some reason
<ubot5> Ubuntu bug 1317639 in Ubuntu UI Toolkit "Add /home patching to autopilot helper" [Undecided,Confirmed]
<thomi> morning
<alesage> thomi I'm writing a multi-app test, what's a good way to set the testability flag globally so that every app that's launched gets it?
<alesage> thomi my test is 'change wallpaper', which opens gallery-app
<thomi> alesage: it's best not to, TBH - let autopilot handle that for you when it launches the app
<thomi> alesage: oh, I see
<thomi> alesage: in that case, you need to set some upstart override files I believe
<thomi> we don't currently have a good solution for this
<alesage> thomi ok so I'll investigate the upstart override--any further hints?  or where has this happened before, etc.?
<thomi> alesage: hmmmm
<thomi> alesage: I know someone's done this
<thomi> alesage: I'm prettys ure veebers knows more
<thomi> he'll be online in < 40 minutes
<alesage> thomi ok also I'm asking ted about a method thx
<thomi> alesage: it'd be awesome if apps with testability opened other apps with testability
<thomi> maybe you can ask for that feature :)(
<xnox> alesage: initctl set-env --global QT_TESTABILITY=1
<xnox> alesage: or whatever the variable is.
<xnox> alesage: this way all apps launched will get that flag in their environemnt.
<alesage> xnox, thanks very helpful, will test now
<alesage> ok new wrinkle: gallery-app not upstart-launched :) thx regardless xnox
<alesage> veebers, I wonder if you have a thought on this, trying to get an externally-launched app to launch with the -testability flag
<alesage> veebers, question mark?
<veebers> alesage: self.launch_test_application() from within a testsuite will do it
<veebers> does that help?
<alesage> veebers, in this case I'm not the one launching--when changing the wallpaper the gallery-app is launched externally
<alesage> veebers, although I might just open it preemptively hmm
<veebers> alesage: if it's launched outside of autopilot or our control that makes it harder
<veebers> alesage: how is gallery-app launched? I suspect that an upstart override file has already been suggested
<alesage> veebers, I don't think it's under upstart
<thomi> alesage: really? that surprises me
<thomi> alesage: I know it's not click
<thomi> but i thought it was upstart
<alesage> I'm just doing the initctl list and not finding it
#ubuntu-autopilot 2014-05-09
<elopio> thomi, veebers: I have a customproxyobject that has a slow_drag method in it. I want to test the number of times that drag method was called.
<elopio> I can't use mock to count the number of time drag was called, because that would do nothing instead of dragging.
<elopio> and I can't make a test class that inherits from my customproxyobject class and counts the number of times drag was called, because I won't be able to use it on select_single
<elopio> I'm out of ideas, but I might be missing some simple and straight-forward way to do it.
<elopio> thomi, veebers: how would you do it?
<veebers> elopio: hmm, I'm just checking a couple of ideas out. My first suggestion was super gross so I didn't even type it out :-)
<thomi> elopio: a decorator?
<veebers> I'm sure you acn do it thought, just pondering it
<thomi> elopio: make a decorator that counts calls
<veebers> thomi: aye, that's what I was thinking, wrap the call and have it count
<elopio> thomi, veebers: but then it will count always. Not just for my test.
<thomi> elopio: hmmm
<veebers> could you have something like: with MethodCaller(object) as smoething:\n\n print something['method_'name'] => 12
<thomi> veebers: but that only works if he controls the call site
<thomi> elopio: make your custom proxy class count the calls only when it's been enabled with a context manager
<thomi> so you'd do:
<elopio> I didn't get that.
<thomi> with my_custom_proxy_class_instance.count_calls():
<thomi>     # test code
<thomi> assert my_custom_proxy_class_instance.call_count == 12
<elopio> I mean, the methodcaller solution.
<elopio> thomi: ok, I don't like that, but I guess I'll go with it.
<thomi> elopio: it's quite an unusual requirement
<elopio> my ideal solution was something like mock.patch(CustomProxyObj, 'slow_drag'), so I didn't have to touch the original class
<elopio> but instead of patching it with a mock, it keeps the same slow_drag implementation but records the call_count.
<thomi> elopio: why do you want this? There's probably a better way
<thomi> counting the number of calls seems like you're testing the wrong thing TBH
<elopio> I'll propose it to mfoord, charge a cent for everybody who uses it, and then I will earn one cent.
<elopio> thomi: on the qquicklistviews we have to drag the list many times in order to find items, right?
<elopio> I'm now working with circular lists
<elopio> if we drag too fast, we skip some items
<elopio> but as it's circular, we might end up spinning many times until by mere chance we make visible the item we were looking for.
<thomi> heh
<elopio> I want a test that verifies that we are spinning only the expected number of times.
<elopio> thomi: but you might be right. It could be that I'm too involved in the current solution that I can't think of an alternate test for this.
<elopio> let me know if you have one in mind.
<thomi> I think I'd do it based on the visible contents perhaps?
<elopio> ok, that could work.
<elopio> check what's the current selected index.
<elopio> drag once.
<elopio> check that the selected index is now the old one + 1
<elopio> it's a little harder when the drag is for more than one item at a time, because the toolkit doesn't tell you properly the numer of visible items. But that's a problem for later.
<elopio> thomi, veebers: thanks! looks better now.
 * elopio goes to the gym to become big and strong.
<thomi> elopio: uhh, no worries.
<thomi> didn't realyl do much to help :)
<chess> in Your first Autopilot test, I am unable to install  libautopilot-qt python-autopilot
#ubuntu-autopilot 2015-05-04
<ahayzen> Hey, I'm trying to port the music-app to Ubuntu.Components 1.2 which includes a new MainView (appears as MainView12) however when I run autopilot it comes back with "ValueError: More than one custom proxy class matches this object: Matching classes are: <class 'music_app.MainView12'>,<class 'ubuntuuitoolkit._custom_proxy_objects._mainview.MainView'>." ... what is the best way around this? Settings validate_dbus_object() to return False
<ahayzen> works but then it won't use my helper if I understand the code correctly :/
<balloons> afternoon ahayzen
<ahayzen> o/
<ahayzen> balloons, this is the mp i'm working on https://code.launchpad.net/~ahayzen/music-app/refactor-bump-framework-1504/+merge/258126 (ignore the jenkins failures as that is failing due to it trying to run 15.04 framework on a 14.10 machine) and it will 'pass' locally as it has the return False in it but is this really the right way of doing it?
<balloons> ahayzen, lol, what a hack to disbale validation heh. It's interesting <class 'music_app.MainView12'> exists
<ahayzen> well i made it :)
<ahayzen> MainView12 that is
<balloons> I guess I should look at the full branch
<ahayzen> it doesn't work as it can't find the type if you leave it as MainView so I set my helper to MainView12 but then you hit the duplication issue lol
<ahayzen> hmmm and it partially works by not requesting by type and only by objectName as timp suggested yesterday...
<ahayzen> balloons, doing this seems to 'work' http://pastebin.ubuntu.com/10984596/ but then is that still using my helper?
<ahayzen> seems to be :) balloons i think i solved my own issue :)
<balloons> ahayzen, ahh right.. I didn't get a chance to open the code just yet, but indeed
<ahayzen> balloons, is that the right way to go do you think? by only specifying the objectName ?
<balloons> the versioning issues requiring versioned classnames should be squashed, afaik
<balloons> on the select's, can't you just select the MainView type, no objectname
<balloons> ?
<ahayzen> let me try...
<ahayzen> "autopilot.exceptions.StateNotFoundError: Object not found with name 'MainView'."
<balloons> and selecting MainView12
<balloons> ?
<ahayzen> then under vis it appears as MainView12 .. hence why i went down that route...
<ahayzen> balloons, and having a MainView12 helper? or a MainView helper?
<balloons> a MainView helper. But it sounds like that bug is still around
<balloons> https://bugs.launchpad.net/autopilot-qt/+bug/1341671
<ahayzen> "NameError: name 'MainView12' is not defined"
<ubot5> Ubuntu bug 1341671 in Autopilot Qt Support "Versioned QML classes are not recognized by their public type name" [High,Confirmed]
<ahayzen> and then if the helper is MainView12 you get that duplicate one I said at the start
<ahayzen> yeah seems to be ^^ bug and the ones linked
<balloons> seems elopio_ would say, do it as you did in the paste
<balloons> https://bugs.launchpad.net/autopilot/+bug/1350532
<ubot5> Ubuntu bug 1350532 in Autopilot "validate_dbus_object can cause more than one class in the cpo cache" [Undecided,New]
<balloons> use objectname to select it
<ahayzen> ok i'll do that for now then :) thanks balloons
<balloons> ahayzen, however thanks for the heads up on those bugs.. Time to ask veebers and company nicely to take them on :-)
<ahayzen> hehe
<balloons> I thought they had been fixed!
 * ahayzen now tries to figure out the best way to please PEP8
#ubuntu-autopilot 2015-05-05
<balloons> veebers, can I get your opinion on some autopilot bugs?
<balloons> it's 4 bugs, all dealing with how we select qml types: https://bugs.launchpad.net/autopilot-qt/+bug/1341671
<ubot5> Ubuntu bug 1341671 in Autopilot Qt Support "Versioned QML classes are not recognized by their public type name" [High,Confirmed]
<veebers> basure
<balloons> https://bugs.launchpad.net/autopilot/+bug/1210265
<ubot5> Ubuntu bug 1210265 in Autopilot Qt Support "The namespace of qml types is ignored" [Undecided,New]
<balloons> https://bugs.launchpad.net/autopilot/+bug/1337004
<ubot5> Ubuntu bug 1337004 in Autopilot "Make it easier to select a custom proxy object with a class name different from the QML type" [Undecided,New]
<balloons> https://bugs.launchpad.net/autopilot/+bug/1350532
<ubot5> Ubuntu bug 1350532 in Autopilot "validate_dbus_object can cause more than one class in the cpo cache" [Undecided,New]
<balloons> these rear there heads on occasion and can mean you have to do some weird workarounds
<veebers> balloons: aye, they have been around for a while :-) I'm happy to put it on the suggested backlog and advocate them to be worked on (might need a little exploration first). I think that elopio fgimenez and vila would agree?
<fgimenez> veebers, indeed :)
<vila> veebers: definitely worth triaging and refined in cards
<elopio> veebers: balloons, fgimenez: there's this one: https://trello.com/c/Ps8r0gef/39-project-qa-spike-investigate-issues-around-qt-selection-and-propose-alternatives
<vila> elopio: and now this one too https://trello.com/c/Jr1cPpOd/162-projects-tools-gate-test-tools-with-autopkgtest-and-block-when-tests-fail
<veebers> vila: I might be missing something; is that card related?
<veebers> elopio: ack, all 4 of those bugs balloons posted covered by that card?
<elopio> veebers: I think so. I have a hard time with those bugs, because some are overlapped and some are not related.
<veebers> elopio: ok, perhaps first point of action for that card is a task to consolidate the bugs :-)
<balloons> I was trying to find more or less all the issues surrounding autopilot and qml not being in sync and causing issues with selecting objects
<vila> veebers: as a way to allow us to release faster, more often, with less risks, more bugfixes like the one above
<veebers> vila: ah ack
<vila> veebers: sorry for being a bit light on the details ;)
<fgimenez> elopio, veebers the latter bug seems to be a more generic problem, maybe not only related to qt, but they all can be solved together
<veebers> fgimenez: right, the last bug there isn't a qml/qt issue, looks like an autopilot one
<balloons> elopio, looks like as usual you are ahead of the game on this.. that card looks good
<elopio> @everybody, please leave your comments on the cards.
<elopio> there's many things I don't understand, so it's likely the bug report and the card are missleading.
<balloons> can someone add me to the board? I can't comment
<vila> balloons: can't you subscribe ?
<fgimenez> i can't either, could someone add me too?
<balloons> it's a bit odd.. I expected it to be more open, since it's in the org
<vila> balloons, fgimenez: hmm, I think there are issues with the cards being too easy to move from one lane to the other
<vila> balloons, fgimenez: you're added
<fgimenez> vila, thanks!
 * vila crashes ;-D
<balloons> ty!
<balloons> thanks guys1
<fgimenez> leaving guys, see you tomorrow o/
#ubuntu-autopilot 2015-05-07
<veebers> thomi: Are you able to make me channel op? I'm attempting to update the topic (unless you want to just update for me.)
<thomi> there you go
<thomi> FWIW, you could have oped yourself, I'm pretty sure
<veebers> oh, heh, cheers
* veebers changed the topic of #ubuntu-autopilot to: Autopilot documentation can be found here: http://developer.ubuntu.com/api/autopilot/python/1.5.0/ | latest tutorial video is: https://www.youtube.com/watch?v=jkLtbmQxXYc
<veebers> thomi: appears I can't, I'm unable to de-op myself :-)
<thomi> lol
<thomi> irc fail
<thomi>  /cs deop #ubuntu-autopilot veebers
<thomi> try that ^^
<veebers> ack
<veebers> thomi: /cs is an unknown command
<thomi> oh right, that's a shortcut I set up
<veebers> the command that works but denies me is: /msg chanserv deop #ubuntu-autopilot veebers
<thomi> hmmm
<thomi> I was pretty sure I didn't configure any access controls. let me see
<thomi> veebers: try now please
<thomi> You didn't have +o set
<veebers> thomi: sweet, that works. Cheers
<thomi> veebers: you should be able to +o anyone else who you think needs that power with:
<thomi>  /cs flags #ubuntu-autopilot <nick> +o
<thomi> SA /cs help flags for a list of flags
<veebers> thomi: awesome, thanks for that
#ubuntu-autopilot 2017-05-14
<fili> hi guys, can you help me to install autopilot?
