#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 cisneroselizabeth@example.net. <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 2014-05-12 <thomi> veebers: hey man, I'm back <thomi> veebers: any luck on the release jobs? <veebers> thomi: hey I can see that something odd happened with this one: http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/122/label=daily-mako/testReport/mediaplayer_app.tests.test_player_with_video/TestPlayerWithVideo/test_scene_selector_operation_with_touch_/ <veebers> apparently, WireProtocolVersionMismatch but the stack trace is coming from python2.7 <thomi> the WPVM error is actually a red herring in this case <thomi> AP assumes that if any DBusException happened during the GetVersion()call, that the version is 1.2 <veebers> I see we get a failure for 'ubuntu_filemanager_app.phablet-test-run' in both, so something is happening here <veebers> right <veebers> I suspect that app has been renamed <thomi> which app? <veebers> ubuntu_filemanager <thomi> what makes you think that? <veebers> I think renamed to filemanager <veebers> looking at the smokeeng dash <veebers> last time we consistently had that error was when the rss reader was renamed too <thomi> hmm, odd that the tests still exist for the old version then <veebers> where are you seeing the old version tests? <thomi> well, ubuntu_filemanager_app <veebers> I think phablet-setup-tests may only pull in filemanager or something similar <thomi> hmm, well, we're running the tests for something called ubuntu_filemanager_app - do you think that's incorrect? <veebers> thomi: yeah, I think the job needs updating (i.e. the list of tests to run) <veebers> It should be changed so that it pulls the list of test names from the tool that generates it <veebers> From memory there is a way to get a list of test suites <veebers> we should be using that not the hardcoded list <thomi> ok. what I'm saying is that it's odd that those tests pass, if the app has been renamed. Totally agree that we shouldn't need to fuck about like this though :) <veebers> thomi: where are you seeing the tests pass? I'm seeing a total failure with no tests run <veebers> hence why this 'ubuntu_filemanager_app.phablet-test-run ' is in the failures and not a list of ubuntu_filemanager_app tests <thomi> ah wait, I see now <thomi> sorry <thomi> I was reading the log wrong <veebers> ah makes sense now <veebers> I'll follow up with andy and see if we can't make that job smarter in that regard <veebers> moving on to the ubuntu_clock_app, the same 5 failures appear in the smokeeng and both gatekeeper jobs <veebers> so it looks like there are issue there outside of a newer AP <veebers> (I'm just confirming/comparing the smokeeng run with 1.5) <veebers> thomi: oh that latest AP video of yours is F-ing awesome! well done :-) <thomi> heh, you think it works? <thomi> it's really hard to get the 'art' and the voice track lined up <thomi> also, there's an IRC pop up from you that appears at one stage :) <thomi> so you're on youtube now :) <thomi> it's nothing embarrasing though :( <veebers> thomi: hah I wondered who the popup was from :-) <thomi> if you watch it in HD you can see it quite clearly <veebers> If I could make a suggestion, it would be to somehow have the brushes etc. on hot-keys so the cursor isn't jumping around the screen and removing the color picker side bar <veebers> thomi: odd, i tried that but it stayed blurry for me :-P <thomi> yeah, that's going to be my next trick - do it all in fullscreen mode <veebers> nice <veebers> the handwriting has improved quite nicely ;-) <thomi> heh <thomi> the trick is confidence. confidence, and many, many, many takes <veebers> heh :-) Well it worked out really well. You should link to the latest video in the channels topic too * thomi changed the topic of #ubuntu-autopilot to: Autopilot documentation is at http://developer.ubuntu.com/api/devel/ubuntu-14.04/autopilot/ | latest tutorial video is: https://www.youtube.com/watch?v=En1MaDDp9_8 <veebers> ^_^ <veebers> thomi: so you know who I would ask about some minor improvements to the smokeng dash? Is that something we do and propose or is someone looking after it? <thomi> I don't really know. I guess we'd talk about what you want first, whip up a quick feature spec... TBH be honest we're most likely going to be the ones to do it I guess <thomi> which is ok, as long as we can get it merged <veebers> thomi: aight, it should be pretty simple. I just wanted the test suite added to the title, makes it easy to scroll through many tabs that way <veebers> thomi: unless you have any objections I'll fire off the gateway keeper again with those suites we saw fail (changing ubuntu_filemanager_app -> filemanager) <veebers> thomi: I take that there is no objections? :-) <thomi> hmm? <thomi> go for it <thomi> veebers: did you see http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/124/ ? <veebers> thomi: Not recently I'll look now <veebers> hmm, has a couple more errors thanks to filemanager. Is also a different image ver from run 122 (18:20140509:20140506.1 vs 21:20140510.1:20140506.1) <thomi> veebers: that wasn't a full run, right? <veebers> thomi: the most recent? No, was just the suites that appeared in the fail list from run 122 (with renamed filemanager) <thomi> hmmm <thomi> not really sure what to do - suggestions? * veebers ponders <veebers> thomi: perhaps an email to the devs or ubuntu-phone stating 'These are the errors/fails we have. x is considered faulty tests (as per failures in smokeeng) the others are either new or faulty too' <veebers> and put the effort onto the devs to ensure the tests are correct <thomi> hmmmm - the run without our PPA had similar failures - do those failures show up on the CI dashboard? <veebers> That's what I mentioned earlier on (comparison of smokeeng to failures.) the clock app matches failures in both our run and smokeeng dash <veebers> I'm just checking the weather app now actually as it lookslike the match up <veebers> The weather app failures match up with the smokeeng failures, just double checking the clock failures but suspect the same thing <veebers> thomi: same thing with the clock app except we have an extra failure 'test_toggle_alarm_status_must_enable_or_disable_alarm'. <thomi> is it consistent? Maybe we should re-run the clock-app tests? <veebers> thomi: consistent? you mean between runs of the gatekeeper? I'll have to check again. I just compared the latest gatekeeper against the latest smokeeng <veebers> thomi: Perhaps we should re-run clock and weather to make sure it is consistent though <thomi> yeah <thomi> can you kick it off please? <veebers> sure ting <veebers> done <tscheck> Hello. <tscheck> I'm struggling with the vis tool on the 14.04 release using the qt4testapp from the libautopilot_qt unit tests. I don't see QDeclarativeItem. Is this a know issue? <tscheck> export QT_SELECT=qt4 <tscheck> /usr/share/libautopilot-qt/qt4testapp -testability /usr/share/libautopilot-qt/qt4.qml & <tscheck> autopilot vis <tscheck> When I run a simple test case with a print_tree() and a sleep, vis shows the element. <cgoldberg> tscheck, hey.. you can file a bug and it will get triaged... there has been some recent work on vis tests <cgoldberg> tscheck, https://bugs.launchpad.net/autopilot-qt/+filebug <balloons> elopio, you about? Got a couiple ?'s for you. how's reminders tests looking? And I believe you and team work on SDK testing; would EDS fall under that; at least the extensions we have for alarms and things? <elopio> balloons: all tests just passed <elopio> https://code.launchpad.net/~elopio/reminders-app/test_with_account/+merge/218688 <elopio> can you merge it? <balloons> ohh yes I kicked it off again :-) <balloons> it answered my question, hah <balloons> merging now <elopio> balloons: and about eds, ChrisGagnon is working on enabling all the tests for the qt components. <elopio> I'm not sure how well tested is eds already. <elopio> balloons: take a look at the last slide: https://docs.google.com/a/canonical.com/presentation/d/14Jpe7UDo-emqLgSFii5uPF-fPy0BoAQTX1kMfwU5AnI/edit#slide=id.g3381b7c66_1126 <elopio> we should talk to him to see if he has eds in the roadmap. <balloons> elopio, but we have custom work on it right? I mean the issues we see are with our addon components which we ship with the sdk. Right? <balloons> ty for letting me know to talk to Chris ;- <elopio> balloons: yes, if the work is on our branches, we should have tests for it. If it's on someone else's branches, we should contribute tests there. <tscheck> @cgoldberg: Ok. I will file it. <elopio> one other important thing we discussed with the sdk team is about code coverage. <elopio> we don't really know where we are missing tests. <balloons> elopio, so I think it <balloons> so it's 2 pronged. I should make sure Chris is getting upstream tests going for it, and I guess make sure it's on your team's radar to add it to the sdk testsuite? <elopio> balloons: it's a thin line between chris and me there. So probably we should all talk about it to see who takes care of what. <elopio> I'm going to take a look at the eds components that we add. <balloons> elopio, awesome. It's something I'd like to get on the schedule for Malta as it's a constant regressor for my team (core apps). <elopio> balloons: ok, please reply to julien's email about call for topics, so we have it on schedule. <balloons> elopio, yep will do. Just wanted to see if it was on someone's radar or not, and if work had been done <balloons> no worries and thank you! <thomi> morning <veebers> morning <thomi> barry: who should I talk to if I want to convince someone to package the 'youtube' sphinx third party plugin from https://bitbucket.org/birkenfeld/sphinx-contrib/src/940757f22e335f6ae98521621201683d6bab1d60/youtube/?at=default ? We already package opther plugins from the same repo, just not that one <barry> thomi: is it on pypi? i'd help sponsor it into debian if you package it up :) <thomi> the packaging is the hard part - I've never done it for something that I'm not the upstream for <barry> thomi: it's *probably* easy: https://wiki.debian.org/Python/LibraryStyleGuide <thomi> barry: when is your EOD? <barry> thomi: at least another hour away <thomi> barry: cool - will let you know <thomi> barry: ugh, won't get to it today it looks like - will send you an email overnight :) <barry> :) <thomi> barry: so, do I make a debioan/ dir in a checkout of the upstream source? <thomi> barry: or in a completely seaprate branch? <barry> thomi: <barry> thomi: i've found it easiest when package something brand new, to create the debian/ inside an unpacked upstream tarball. once you have a package that builds and looks good, then you can take the .dsc and import/inject that into the vcs of your choice. that's assuming you'll want to maintain it in debian, which i suggest (i.e. it's not ubuntu specific) <thomi> barry: OK, I'll do my best, and you can tell me where I've stuffed it up tomorrow. <thomi> right now I need moar coffee <barry> :) <veebers> thomi: we may have an issue with filemanager and ppa autopilot. I'm rerunning the gatekeeper without the ppa and just filemanager so we can compare results on the same hardware etc. <thomi> veebers: ok - keep me posted please :) <veebers> thomi: can do <barry> thomi: what's the eta for the final uploads to eradicate py2 from touch? <thomi> hey barry - just emailed you, assumed you'd EOD'd already :) <thomi> barry: we're landing the AP parts now <thomi> just doing the final checks (how's that going veebers?) <barry> thomi: i was, but i couldn't resist seeing how a build was going :) <thomi> barry: I'd expect the autopilot package to land today <veebers> thomi: re-running the job as something failed <veebers> (see #ci) <thomi> veebers: that's not finished yet? oh, you mean, re-re running :) <veebers> ack :-) <thomi> boooo #ubuntu-autopilot 2014-05-13 * veebers reboots <veebers> thomi: we may have an issue with AP 1.5 & filemanager (http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/128/) I'm re-re-re-running with the ppa enabled this time in case there was a recent fix or something <veebers> thomi: to clarify, the linked job was without the ppa 100% passing <veebers> trying now with the ppa to get (more) resutls <veebers> results* <thomi> hmm, interesting <thomi> I'll start flashing my device <veebers> thomi: now that mine is actually charged I'll do the same <veebers> thomi: I see that you fired off another gatekeeper for filemanager, but it seems to have had troubles <thomi> ugh, what happened? * veebers looks futher <thomi> I probably messed it up somehow <thomi> veebers: BTW, you need to manually install python3-autopilot for now <veebers> thomi: hmm, yeah "filemanager_app.phablet-test-run" <veebers> it should be just filemanager <veebers> (no -app) <thomi> ugh <thomi> can you re-kick off please/ <thomi> ? <veebers> thomi: oh? how come? (re: manually installing) <veebers> yeah sure <thomi> veebers: because otherwise it doesn't install 1.5 <veebers> fyi: http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/131/ <thomi> because autopilot-touch is already in the seed <thomi> so the current installed python3-autopilot satisfies the dependency <veebers> thomi: ugh, click. damn, you meant in the params for the job <veebers> this is the actual one: http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/132/ <thomi> hmm? yeah <thomi> sorry :) <veebers> nw, killed and restarted that job. Luckily I clicked now and not after the run :-) <veebers> ugh, thomi this is the 2nd time I've seen this failure (but I had a successful run after the first time I saw it): http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/132/label=daily-mako/console <veebers> namely the error; I: Unlock failed, script output: 'initctl: unable to determine sessions <thomi> veebers: kick it off again I guess, and maybe file a bug with the infrastructure people <veebers> (I pinged the CI guys about this earlier but haven't heard back, I fear they're all EOD) <veebers> thomi: aye, that's teh plan :-) <veebers> the* <veebers> hmm, perhaps I borked it. I forgot to add the ppa (after all that ruse to add python3-autopilot to it) <thomi> veebers: may as well change the job defaults for the python3-autopilot thing <thomi> no need to install python-autopilot any more, so just change it <veebers> thomi: ok, that shouldn't effect other people that may use that job? (namely Saviq which I understand does sometimes) <thomi> shouldn't <thomi> if it does, they can get their own :P <veebers> heh, aight, changing now <thomi> veebers: any luck with the latest run? <veebers> thomi: good question, I'll check now <veebers> thomi: no, now there are 3 failures: http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/133/testReport/ <thomi> veebers: can you investigate please? <veebers> thomi: I'll just purge the ap testing ppa I added and add the silo. I'll bother you and pick your brain if it appears to be something with the new xpathselect stuff :-) <thomi> what new xpathselect stuff? <thomi> oh <thomi> you mean in autopilot <veebers> thomi: sorry, yes <thomi> hang on, I think I can see the roblem already <thomi> look at the error in: http://q-jenkins.ubuntu-ci:8080/job/autopilot-release-gatekeeper/133/label=daily-mako/testReport/filemanager.tests.test_filemanager/TestFolderListPage/test_cancel_rename_file_with_touch_/ <thomi> veebers: ^ * veebers looks <veebers> thomi: you'll have to elaborate <thomi> see anything odd there? <thomi> read the error message <veebers> this? name '<class 'ubuntuuitoolkit._custom_proxy_objects.popups.ActionSelectionPopover'>' <thomi> right <thomi> WTF <thomi> that's not a class name <veebers> no, it's not <thomi> but I can't seem to reproduce that in ipython <thomi> I know python 3 does something with fully qualified names <veebers> odd, I'll see if I can step through and see better what's happening. <thomi> veebers: but I'd say that's what the issue is <veebers> It's really odd that there are now 3 failing but 2 befpre <veebers> before* <thomi> odd that the ActionSelectionPopover selection doesn't appear int he log <thomi> veebers: maybe run it with -vv, so we can see the debug log <thomi> but yeah, the class isn't being stringified properly I'll bet <veebers> thomi: hmm, i don't think I can do that with the gatekeeper job, but I'll try on my locally flashed device <thomi> veebers: right, I meant locally <veebers> coolio, on it <thomi> I'm happy to look at this with you, if you want to share your screen in a G+ hangout <veebers> thomi: let me get the device ready and see if I can reproduce it, otherwise sounds good <veebers> thomi: fyi running the filemanager tests locally on my desktop (on Trusty) all tests pass, still running on the device <thomi> you're running v1.5 & py3 on the desktop? <veebers> thomi: yes, just trying to get a 'reproducable' quicker <thomi> sure <thomi> hmmm <veebers> thomi: phone just finished, I get the failure, seeing if I can narrow it down to running just one test <thomi> veebers: crap, I just realised that my instinct was wrong <thomi> veebers: the fully qualified name is a red herring I'm afraid <veebers> thomi: hmm, ok :-\ I'll keep poking <thomi> but I'll fix that log message anyway <veebers> coolio <thomi> veebers: for your consideration, when you get the time: https://code.launchpad.net/~thomir/autopilot/temp-dev-fix-class-name/+merge/219286 <thomi> Personally, I think it should go in the release - happy to leave that decision to you though <veebers> thomi: cool,I should be able to look at that tonight <veebers> thomi: that code looks familiar, didn't I propose a MP that did this the other day? * veebers is confused <thomi> veebers: that was for a different case <thomi> veebers: that was for a log message - this is for SNFE <thomi> veebers: but year, same thinko <thomi> I'm surprised we didn't catch this case when you filed your original MP, but oh well <veebers> thomi: ah ok, no longer confused <thomi> glad to hear it :) <veebers> well, perhaps 'less confused' is a more accurate statement <veebers> thomi: hmm, just running the failing test now passes for me on the device >:-| I'll poke around and see if I can narrow it down to a single failing or at least a combination that fails <thomi> hmmm <thomi> are you running with -vv? <veebers> thomi: I am now, I modified phablet-test-run to use -vv <thomi> would be really interesting to see the queries that are being run <thomi> in both cases <veebers> thomi: yeah, I'm running this 1.5 now, then I'll purge and run again with 1.4 + -vv and compare against the failing etc. <veebers> thomi: ugh awesome, this time around I get 1 test fail with SNFE 1 x ValueError error & 1 x AssertionError failure :-\ <veebers> so it's inconsistent <thomi> veebers: pastebin? <veebers> thomi: http://paste.ubuntu.com/7455887/ <thomi> ugh - we *really* need to fix that logging bug <veebers> heh. Gotta love the "Key pressed!" log message :-) <thomi> heh, and the "<skip>Can't do this properly on desktop or phablet</skip>" <veebers> heh :-P <veebers> thomi: how come I only see one instance of "'GetState Query(b'/comubuntufilemanager/QQuickView/MainView[id=2]//ActionSelectionPopover[objectName="fileActionsPopover"]')" before exception raised? <veebers> I would have assumed 10 lines in the log then eht exception <thomi> veebers: can you 'bzr blame' the source and see who's been touching the source? <thomi> veebers: PB line #? <thomi> veebers: it's just a select_single not a wait_select_single <thomi> oh wait <thomi> yeah <thomi> what I said <veebers> thomi: sorry I must be being slow, bzr blame which source? <thomi> the test source <veebers> ah good point <veebers> can do <thomi> You could try making it a wait_select_single and see if that improves things <veebers> thomi: hmm, I wonder if this version of AP is faster which is why 1.4 works currently <thomi> could be, although if it is, it won't be by much. <thomi> I haven't done any explicit optimisations <veebers> thomi: hmm ok. Hey, is there a nice why to 'blame' a whole directory? <thomi> don't think so - that doesn't really make sense <thomi> what would it show? <thomi> mode changes to the directory maybe, but I suspect that's not what you want :) <veebers> *shrug* split-pane with a tree of files and clicking them shows the diff/blame for that file <thomi> ahh, gotchya <thomi> bzr log does that then :) <thomi> even better - it does it with the author as the first index :) <thomi> bzr qlog tests/autopilot/ <thomi> or whatever <veebers> thomi: ah, that's what I'm doing at the moment :-) <veebers> thomi: so might be of interest, looking at the logs balloons recently made changes to the tests, one being this http://pastebin.ubuntu.com/7455926/ (changing wait_select_single -> get_action_selection_popover) <veebers> where get_action_selection_popover is in the ubuntu ui toolkit ap and uses select_single <thomi> hmmm <thomi> what does that method use? <veebers> I'll try patching that to use wait_select_single and see <veebers> thomi: you mean get_action_selection_popover? <thomi> yeah <veebers> thomi: [17:35:12] <veebers> where get_action_selection_popover is in the ubuntu ui toolkit ap and uses select_single <veebers> I'm just about to re-run the test on the device with the uuitk patched to use wait_select_single <veebers> thomi: hmm, Without seeing the logs (still running) it seems that I saw a failure run past where the devices screen was blank white. It would be interesting to see the phones state (cpu usage etc.) during the test <thomi> veebers: I'm going to EOD now <thomi> veebers: can you please email whoever looks after that app with a link to the failures, our investigation, and ask them to look into it as a matter of urgency please? <veebers> thomi: ack. sure, can do <thomi> we *really* need to release AP tomorrow, which means whoever owns these tests needs to either allow us to release, or get them fixed :) <thomi> feel free to CC me <thomi> thanks man <thomi> talk to you later maybe. <veebers> thomi: If I can't find the dev for filemanager I may have to email the phone list <veebers> thomi: aye, night o./ <thomi> veebers: why didn't bzr blame work? <thomi> I thought you identified balloons? <veebers> thomi: right, but should it be on his shoulders? I don't know. I can start with him and he can hopefully fwd if needed <thomi> veebers: right, but you can get a complete list of authors with bzr blame, right? <thomi> I don't understand why you'd need to use the ML <veebers> thomi: I'll also add Chrs/robotfuel as it looks like both of them have looked at the flakiness of tests latetly <thomi> awesome <veebers> thomi: leave it to me I'll sort it out <thomi> schweet <thomi> going to have a beer and dinner <thomi> laters!@ <robotfuel> veebers: what's flaky? <veebers> robotfuel: isn't is super late for you? Perhaps you're clock is flaky ;-) <veebers> robotfuel: thomi and I are investigating some failures in the filemanager autopilot tests when using the to-be-released autopilot 1.5 <robotfuel> yes, I have some ideas. I was too busy with other stuff to fix it today, I am going to sleep so I can fix it in the morning. <robotfuel> veebers: can you email me instructions for using ap 1.5? <robotfuel> like which ppa I use? <veebers> robotfuel: awesome, ppa is: ci-train-ppa-service/landing-003 <veebers> robotfuel: should I email you and balloons re: pretty much what we've discussed here? <robotfuel> sure <veebers> robotfuel: I'll link to the gatekeeper job that we've been using to run it too <robotfuel> veebers: thanks again, good night <tscheck> Hi, is there are reason, why the qt and gtk modules in autopilot/introspection have no api doc pages? <tscheck> See: http://unity.ubuntu.com/autopilot/_modules/autopilot/introspection/ <tscheck> When you use the Quick search of the online help, you can't find any info on signals. <tscheck> Hm. There is another online help without qt and gtk modules at: http://developer.ubuntu.com/api/devel/ubuntu-14.04/autopilot/_modules/autopilot/introspection/ <tscheck> Strange. <tscheck> Shall I file a bug? <balloons> tscheck, those are strange links <balloons> I don't believe the pages you found are meant to be published atm.. meaning, http://unity.ubuntu.com/autopilot/_modules/autopilot/introspection/gtk.html for instance <balloons> looks quite old <tscheck> balloons: I see. But the first link are the official api docs, right? Any info about why the qt and gtk modules are not created? <balloons> tscheck, not offhand. some devs will be around in about 5 hours and they should have an answer for you <balloons> elopio, did you ever make an optionselector emulator? <elopio> balloons: robotfuel did. It's already published. <balloons> elopio, I remember it, I just don't see it <balloons> and I need it now :-) <elopio> balloons: http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/tests/autopilot/ubuntuuitoolkit/_custom_proxy_objects/_optionselector.py <elopio> ubuntuuitoolkit.OptionSelector, that's the new namespace. <balloons> elopio, is trusty missing this? <elopio> balloons: I don't know. <elopio> that's a question for bzoltan. <balloons> seems to be the case.. <balloons> ok, I finally found what you are talking about and I'll give it a try now. Looks nice <balloons> but yea, the package in trusty doesn't have it afaict <elopio> balloons: we should probably backport it. <elopio> it's not going to be hard to have the autopilot package of the toolkit working on trusty and on utopic <balloons> elopio, turns out, problem solved. zoltan said sdk team pushes updates to there ppa. ppa:ubuntu-sdk-team/ppa. I've asked francis to add that ppa to the jenkins builders so we should be covered <elopio> oh, well, maybe a little hard because they add features like the new header <elopio> balloons: nice, thanks. <thomi> barry: did you get a chance to look at my packaging stuff? <barry> thomi: not yet. will soon <thomi> cool - thanks :) <veebers> morning <thomi> nuclearbob: cgoldberg: quick thing: <thomi> we said in a meeting that you guys were going to attend the qa/ci meeting and talk about something, was it the subunit integration work? <cgoldberg> thomi, yea <thomi> in any case, we need to talk about that between ourselves first, so you have all the facts :) <cgoldberg> thomi, can you bring it up tomorrow in the call? im about to EOD <thomi> Do you think we can do that in the TnT standup tomorrow, or should we make a separate call? <thomi> that answers that question :) <cgoldberg> :) night #ubuntu-autopilot 2014-05-14 <balloons> elopio, it seems the AP docs for ubuntu-ui-toolkit have been removed from the ubuntu-ui-toolkit branch <elopio> balloons: I didn't know the docs where on the branch. <elopio> I thought you generated them manually and uploaded them to the server. <balloons> http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/revision/975 <balloons> elopio, yes.. they were checked in and part of the build. <balloons> they were supposed to be synced to the server <balloons> that didn't happen, but it seems the docs too are gone <elopio> hum, balloons: in what directory were they? <balloons> there own dir.. you can see in the bzr diff there I linked <balloons> i'll have to track it down later.. but I want a new build so the docs are updated <balloons> back in a bit <Letozaf_> balloons, elopio hi <balloons> Letozaf_, hello <Letozaf_> balloons, hello howzit ? <balloons> Letozaf_, good. So elopio was hoping to help you get your branch merged <balloons> Letozaf_, he put together this branch as you saw to add a notebook. https://code.launchpad.net/~elopio/reminders-app/autopilot-add_notebook/+merge/219237 <Letozaf_> balloons, yes is he about ? <balloons> Letozaf_, I'm going to assume he'll show up in a second. I spoke with him about this a bit ago <Letozaf_> balloons, ok * Letozaf_ is looking at the branch <barry> \o/ <balloons> or perhaps elopio won't appear :-) Letozaf_ did you get the sdk installed? <Letozaf_> balloons, yes <balloons> Letozaf_, were you able to get it working at all? <Letozaf_> balloons, mmm... can fidle with it but I never really used it <balloons> Letozaf_, I believe the idea is to use it to add a notebook and a note first, then run your tests. Does that make sense? <Letozaf_> balloons, yes <thomi> morning <Letozaf_> balloons, I installed evernote-sdk-python but think I will need help for using it <balloons> Letozaf_, well since elopio isn't appearing let me give it a whirl <elopio> hey <elopio> Letozaf_, balloons: I was having lunch. <Letozaf_> elopio, hello :-) <balloons> elopio, :-) <elopio> how can I help? <balloons> Letozaf_, is here.. time to finish out the branch <balloons> Letozaf_, this is a quick start guide, I was going to point you to here first: https://github.com/evernote/evernote-sdk-python <balloons> we need a bit of code to create the note and notebook <elopio> balloons: can you top approve my other branch so it gets into trunk? <balloons> elopio, ohh yes, sorry :-) <elopio> Letozaf_: balloons: let me write a script to create notes using the sdk. <Letozaf_> elopio, ok <balloons> your branch is landing now <balloons> Leo's that is <thomi> barry: did you get a moment to look at the sphinxcontrib packaging? * barry ties his shoes <barry> thomi: whu? you talkin' to me? <barry> thomi: no. i suck. keep bugging me until i do! i'm very close to finishing up this other big mass of hack. <thomi> barry: oh don't worry, I'm pretty persistent, I'll keep bugging you :) <thomi> if it takes too long you might find I start visiting you in person :) <barry> thomi: jeebus! get off my back man! <barry> :) <thomi> :) <elopio> balloons: we won't be able to run the reminders tests with python3 until thrift is ported. <balloons> elopio, that's a hard depends we have i believe. for the image, we need py3 <Letozaf_> balloons, elopio it's getting quite late here in Itlay :) do you mind if I come back tomorrow night ? <balloons> Letozaf_, since I threw a brick into elopio plans, hehe, that's probably a good idea <elopio> yup <Letozaf_> balloons, elopio ok guys see you tomorrow buona notte :-) <elopio> our options are to push the thrift port, or to do our own client that doesn't use thrift. <balloons> buona notte Letozaf_ * balloons pokes barry <elopio> balloons: do we have any dev contacts in evernote? They should be the most interested on making their sdk work with py3. <balloons> elopio, we do <balloons> https://github.com/evernote/evernote-sdk-python3 <balloons> they've been working on it <elopio> balloons: oh, they include a thrift library ported with 2to3 <barry> balloons: hey <balloons> hey barry I was just poking you about doing porting work to python3 :-) Since I told Leo we can't use py2 modules <elopio> balloons: so, should we tell daniel to publish on the ppa that thrift as python-thrift? <elopio> balloons: so, should we tell daniel to publish on the ppa that thrift as python3-thrift? <barry> what's "py2"? :) <barry> py2 must die <balloons> perfect barry.. you are playing the role beautifully * barry bows... ACTING! <balloons> elopio, we could just use the experimental code, sure. It should be more than enough for our needs which are extremely basic <balloons> I should say it's not experimental, more like not feature complete <balloons> elopio, and yes python3-thrift <balloons> I didn't even catch on, sorry should have noticed and mentioned it sooner <robotfuel> elopio: https://code.launchpad.net/~chris.gagnon/ubuntu-ui-toolkit/autopilot_wait_for_popover/+merge/219601 I have a simple mp for the uitk <robotfuel> elopio: can you review when you have time? <elopio> robotfuel: yes, I can. #ubuntu-autopilot 2014-05-15 <xnox> \o/ released <Saviq> thomi, now <Saviq> thomi, I saw your ap 1.5 change <thomi> Saviq: cool - any chance you can get it reviewed, merged, and landed? :) <Saviq> thomi, some, yes ;) <thomi> Saviq: for the price of a beer in Malta? <Saviq> thomi, ;) <nik90> elopio, balloons: Do you happen to know if the new SDK Headers are support by the emulator helper functions? Just curious since I am getting a branch ready in the clock app to make the transition but wondering the AP side of things. <nik90> s/support/supported <balloons> nik90, elopio is the best person to answer that <balloons> however, I believe work was being done in conjunction. I'd have to dig to find the mp <nik90> balloons: ok. I sort of remember t1mp fixing the AP while implementing the new transitions but wanted to confirm with you guys. <nik90> s/transitions/headers <elopio> nik90: yes, you should have helpers for the new features of the header. <nik90> elopio: awesome <xnox> autopilot gurus, please help =) <xnox> http://paste.ubuntu.com/7468524/ says in the end 4 failures, yet, i can only find one FAIL <xnox> FAIL: gallery_app.tests.test_album_view.TestAlbumView.test_add_photo <xnox> what are the other failures? <elopio> nuclearbob, cgoldberg: do you know what could cause this? <elopio> AttributeError: 'module' object has no attribute 'get_classname_from_path' <elopio> http://575.979.1648:8080/job/generic-mediumtests-utopic/190/testReport/junit/reminders.tests.test_reminders/RemindersTestCaseWithoutAccount/test_go_to_account_settings_with_mouse_/ <cgoldberg> elopio, this looks suspicious in the log: <cgoldberg> file:///usr/share/reminders/qml/ui/NotesPage.qml:83: TypeError: Cannot read property 'reminder' of null <cgoldberg> file:///usr/share/reminders/qml/ui/NotesPage.qml:79: TypeError: Cannot read property 'reminder' of null <cgoldberg> file:///usr/share/reminders/qml/reminders.qml:287:30: Unable to assign null to QQuickAnchorLine <elopio> cgoldberg: I think that's safe to ignore, as the videos show the application being properly displayed. <balloons> elopio, this is from https://code.launchpad.net/~dpm/reminders-app/fix-1317683-update-template/+merge/219669? basically showing that trusty works, while utopic doesn't right/ <cgoldberg> elopio, can I see reminders/__init__.py ? <elopio> cgoldberg: http://bazaar.launchpad.net/~reminders-app-dev/reminders-app/trunk/view/head:/tests/autopilot/reminders/__init__.py <cgoldberg> elopio, dbus.get_classname_from_path ? <cgoldberg> it overrides validate_dbus_object and calls that ^^ but what is that? <elopio> that's how nuclearbob told me to use a python class that's different from the qml class. <elopio> hey, the method was removed! <cgoldberg> weird.. i tried from command line and I can see that attribute fine <cgoldberg> elopio, but it's not in API docs <cgoldberg> elopio, in changelog for 1.5: Autopilot introspection package now has a cleaner API <elopio> balloons: on trusty we have autopilot 1.5 and on utopic 1.4? or something like that? <cgoldberg> elopio, locally... i have 1.4 on trusty.. but 1.5 landed in utopic afaik <nuclearbob> elopio: sorry about that, I was in a meeting, I'm reading the scrollback now, did you get something resolved? <cgoldberg> elopio, so did 1.5 break tests? <elopio>
{'channel': 'ubuntu-autopilot', 'month': 5}