[01:56] <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
[01:57] <fginther> so build #200 was probably stuck waiting for build #199 to finish
[01:57] <thomi> ugh
[01:57]  * thomi slow claps for jenkins
[02:00] <fginther> :-)
[02:10] <veebers> thomi: fyi https://code.launchpad.net/~veebers/autopilot/fix-type_name-str-conversion/+merge/218726
[15:44] <balloons> ping elopio
[15:45] <elopio> balloons: pong
[15:46] <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
[15:47] <elopio> balloons: yes! nice. I'll look at it.
[15:48] <balloons> excellent.. there is some small tweaks I'll want to do to reminders as well.. namely add the _patch_home function
[15:51] <elopio> balloons: there's a InitctlEnvironmentVariable in ubuntuuitoolkit.fixture_setup that takes care of the clean up.
[15:52] <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.
[15:52] <balloons> elopio, ahh, gotcha
[15:52] <elopio> balloons: and your fake home is a perfect candidate to be added to ubuntuuitoolkit.fixture_setup
[15:53] <elopio> many apps will use it.
[15:53] <balloons> elopio, in theory everything should use it
[15:53] <elopio> yes, that would be safer and cleaner.
[15:54] <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.
[15:54] <elopio> is that different now?
[15:54] <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
[15:55] <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
[15:55] <elopio> ok.
[15:56] <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
[15:58] <elopio> yes, I was just wondering what happened there.
[15:59] <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.
[16:00] <balloons> elopio, I actually spoke with thomi a little about using cmake to run tests
[16:00] <elopio> I would prefer something like autopilot run ubuntu-filemanager-app LAUNCHER=click BINARY_PATH=/opt/.../
[16:00] <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
[16:00] <balloons> I told him we'd prefer args passing :-)
[16:01] <elopio> well, autopilot is the runner. We are using cmake just because it knows the paths.
[16:01] <balloons> yes, but the call is through cmake
[16:01] <balloons> which he wasn't so keen on
[16:01] <elopio> balloons: so what does he propose as a way to know the path?
[16:01] <balloons> so I quickly did reminders as well; lp:~nskaggs/reminders-app/setup-ap-env
[16:02] <balloons> elopio, passing the args I think works for him
[16:02] <balloons> and in our case if we then use cmake to make the call anyway, perhaps it's fine
[16:02] <balloons> he just didn't like not being able to run the tests without having cmake installed
[16:03] <elopio> balloons: he will be able. He would just have to know the paths.
[16:03] <balloons> elopio, right, so I think as you just proposed works fine
[16:03] <balloons> but AP needs to support passing args is all
[16:03] <balloons> which he said is on the list :-)
[16:04] <elopio> I have tons of emails to read. Today I won't code more, I will read and reply :)
[16:04] <elopio> balloons: anyway, that's something we can add later to your branch.
[16:05] <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
[16:06] <elopio> balloons: no, I'm saying that you should call self.useFixture(ubuntuuitoolkit.fixture_setup.InitctlEnvironmentVariable(HOME=temp_dir))
[16:06] <elopio> it will take care of everything.
[16:07] <balloons> ahh, I see now
[16:07]  * balloons opened fixture_setup
[16:07] <balloons> elopio, so, the patching of home could be the same.. just a fixture
[16:08] <elopio> balloons: yes, the python module has fixture for that
[16:08] <balloons> ok, so I won't rampage beyond the 3 apps I've done and we should plan to go that route
[16:08] <elopio> temp_dir_fixture = fixtures.TempDir()
[16:08] <elopio> self.useFixture(temp_dir_fixture)
[16:08] <elopio> temp_dir = temp_dir_ficture.path
[16:09] <elopio> self.useFixture(fixtures.EnvironmentVariable('HOME', newvalue=temp_dir)
[16:10] <elopio> balloons: that will make your code a lot smaller.
[16:13] <balloons> elopio, that would be inplace of using the patcher on the desktop.. but not for click, correct?
[16:14] <elopio> balloons: yes, for click you would use InitctlEnvironmentVariable from the toolkit.
[16:17] <elopio> balloons: what is Xauthority for?
[16:18] <balloons> elopio, that's for jenkins only. if you mess with /home it will fail to spawn the xsession
[16:18] <elopio> balloons: that would be nice as a comment on the code.
[16:18] <balloons> elopio, :-)
[16:35] <balloons> elopio, updated the mp
[16:40] <elopio> balloons: you need to copy the xauthority before the useFixtures that update HOME
[16:42] <balloons> elopio, bah, good catch
[16:42] <elopio> balloons: also, it would be clearer if you wrap that part in a copy_xauthority file.
[16:42] <elopio> * copy_xauthority_file method.
[16:42] <balloons> really another method? ok, can do
[16:43] <elopio> balloons: yes, methods are good :)
[16:43] <elopio> balloons: do you want me to make the fixture for this on the toolkit ?
[16:44] <balloons> elopio, yes that's a good idea
[16:44] <elopio> balloons: ok, please report a bug for me and it will be on my todo for next week.
[16:45] <elopio> or maybe tomorrow, looks fun.
[16:45] <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
[16:47] <elopio> ok
[16:48] <elopio> balloons: final comment, I think that def setup_environment(self): would be better named get_launcher_and_type
[16:49] <elopio> but, that's the part I would remove.
[16:49] <balloons> elopio, ok. what do you mean you would remove?
[16:49] <balloons> the method altogether?
[16:50] <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.
[16:50] <balloons> mmm.. true, but at the moment we're forced to guess
[16:52] <elopio> balloons: yes.
[16:52] <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?
[16:53] <balloons> btw, setUp drives me crazy.. I just realized it's not sanely setup, all lowercase
[16:53] <elopio> no no no.
[16:53] <elopio> methods are good.
[16:53] <elopio> it's easier to remove it later if it's in a separate method.
[16:54] <balloons> I agree, just confused by what you were saying I guess. Ok, so I'll rename it
[16:54] <elopio> it should be set_up, as the gods of python would have wanted it.
[16:54] <balloons> setup is one word :-)
[16:54] <elopio> really?
[16:54] <balloons> I would support setUp over set_up if it was two words
[17:30] <elopio> balloons: what is this for?
[17:30] <elopio> 106	+ '-q', self.local_location_qml,
[17:31] <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
[17:31] <balloons> imho, nothing wrong with being explicit. Although in theory the binary was updated to just find the proper qml file as needed
[17:31] <balloons> I did the same with file manager
[17:33] <balloons> elopio, care to put your stamp on https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/mock-test-env/+merge/218494?
[17:37] <elopio> balloons: sure. Thanks for making the changes.
[17:38] <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 :-)
[17:41] <elopio> balloons: on the reminders one, you need a commit message.
[17:41] <balloons> :- done
[18:13] <elopio> balloons: hey, one thing about this
[18:13] <elopio> 29	- local_location_binary = '../../src/app/reminders'
[18:13] <elopio> 30	+ local_location = os.path.dirname(os.path.dirname(os.getcwd()))
[18:14] <elopio> oh, no, I get it.
[18:15] <balloons> k
[18:18] <elopio> balloons: now, we need to discuss what to do with the oauth evernote token.
[18:19] <elopio> if we just put it on the branch, somebody could mess with our account affecting the tests.
[18:19] <elopio> we could revoke it and update the test with the new one, so might not be a big deal.
[18:19] <elopio> but it's a hole.
[18:22] <balloons> ping barry
[18:22] <barry> balloons: pong
[18:23] <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
[18:23] <balloons> it fails if you give a full test name it seems for file manager
[18:23] <balloons> barry, ie,  ImportError: No module named 'filemanager.tests.test_filemanager.TestFolderListPage'; 'filemanager.tests.test_filemanager' is not a package
[18:23] <barry> balloons: what's the command line you used?
[18:24] <balloons> barry, phablet-test-run -v filemanager.tests.test_filemanager.TestFolderListPage.test_cut_directory
[18:25] <balloons> elopio, the token can be inserted at build time, just like the weather app
[18:25] <barry> balloons: i have to think that's a bug in autopilot3
[18:25] <barry> i don't remember how it's doing test discovery
[18:25] <balloons> oO, I get to blame thomi eh?
[18:26] <balloons> I don't remember.. but I like the idea of blaming
[18:26] <barry> esp. since he's not here yet :)
[18:26] <elopio> balloons: that's more likely because you don't have some py3 dependencies installed.
[18:27] <elopio> I've been running with autopilot3 and I generally use the full test name.
[18:27] <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
[18:27] <balloons> elopio, yea, I don't remember ever seeing this issue before
[18:27] <elopio> balloons: that sounds pretty cool.
[18:27] <elopio> how do I do it?
[18:28] <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
[18:28] <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
[18:28] <elopio> balloons: ok. Lets just not forget about it.
[18:29] <balloons> trying to close down open issues, not make more, heh :-) I wouldn't hold your merge on it
[18:29] <elopio> later I can revoke this, and give the new one to francies.
[18:29] <balloons> elopio, right, we can go through that process if it comes to it
[18:29] <elopio> balloons: what seems to be holding it now is that the jenkins runner is offline.
[18:30] <elopio> fginther already applied a change suggested by mardy, and my debug branch has passed.
[18:30] <elopio> I would like to confirm on the real branch before merging it.
[18:31] <balloons> elopio, I'll file a bug about the token now
[18:35] <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'>'.
[18:35] <balloons> it's weird.. hmm
[18:37] <elopio> balloons: that doesn't happen with py2? that would be weird indee.
[18:37] <elopio> *indeed
[18:38] <balloons> elopio, I'm thinking it might be a name change thing from ubuntu_filemanager_app -> filemanager
[18:39] <robotfuel> balloons: the manifest.json has the right name filemanager
[18:40] <balloons> it's just bizarre as I see the Popover class in emulators.. and inside the module, under the proper directory..
[18:42] <balloons> ohh.. heh, I think the explanation is much simpler.. I get it now.. nevermind. The tests are actually failing
[18:42] <balloons> the popover isn't being found.. but the code is ;-)
[19:15] <balloons> barry, so looks like I get to blame phablet-test-run instead ;-)
[19:15] <barry> balloons: yay!
[19:57] <balloons> elopio, https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1317639. can't assign for some reason
[20:05] <thomi> morning
[20:16] <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?
[20:16] <alesage> thomi my test is 'change wallpaper', which opens gallery-app
[20:16] <thomi> alesage: it's best not to, TBH - let autopilot handle that for you when it launches the app
[20:16] <thomi> alesage: oh, I see
[20:17] <thomi> alesage: in that case, you need to set some upstart override files I believe
[20:17] <thomi> we don't currently have a good solution for this
[20:17] <alesage> thomi ok so I'll investigate the upstart override--any further hints?  or where has this happened before, etc.?
[20:18] <thomi> alesage: hmmmm
[20:18] <thomi> alesage: I know someone's done this
[20:18] <thomi> alesage: I'm prettys ure veebers knows more
[20:18] <thomi> he'll be online in < 40 minutes
[20:18] <alesage> thomi ok also I'm asking ted about a method thx
[20:18] <thomi> alesage: it'd be awesome if apps with testability opened other apps with testability
[20:19] <thomi> maybe you can ask for that feature :)(
[20:21] <xnox> alesage: initctl set-env --global QT_TESTABILITY=1
[20:21] <xnox> alesage: or whatever the variable is.
[20:21] <xnox> alesage: this way all apps launched will get that flag in their environemnt.
[20:28] <alesage> xnox, thanks very helpful, will test now
[20:48] <alesage> ok new wrinkle: gallery-app not upstart-launched :) thx regardless xnox
[20:48] <alesage> veebers, I wonder if you have a thought on this, trying to get an externally-launched app to launch with the -testability flag
[20:48] <alesage> veebers, question mark?
[20:50] <veebers> alesage: self.launch_test_application() from within a testsuite will do it
[20:50] <veebers> does that help?
[20:51] <alesage> veebers, in this case I'm not the one launching--when changing the wallpaper the gallery-app is launched externally
[20:51] <alesage> veebers, although I might just open it preemptively hmm
[20:51] <veebers> alesage: if it's launched outside of autopilot or our control that makes it harder
[20:52] <veebers> alesage: how is gallery-app launched? I suspect that an upstart override file has already been suggested
[20:52] <alesage> veebers, I don't think it's under upstart
[20:53] <thomi> alesage: really? that surprises me
[20:53] <thomi> alesage: I know it's not click
[20:53] <thomi> but i thought it was upstart
[20:53] <alesage> I'm just doing the initctl list and not finding it