#ubuntu-autopilot 2014-07-14
<balloons> elopio, can you have a quick look and chat about switching from'from ubuntuuitoolkit import emulators as toolkit_emulators' to using the custom_proxy_objects?  https://code.launchpad.net/~nskaggs/reminders-app/switch-emulators-to-proxy-object/+merge/226706
<elopio> balloons: in one second.
<elopio> balloons: you don't need to import _custom_proxy_objects
<elopio> actually, you should not import the private methods.
<elopio> *modules
<balloons> elopio, yes this is really a quick hack, and I realize I'm not doing it right
<balloons> so I just pushed and figured I'd ask :-)
<elopio> all the objects are exported in ubuntuuitoolkit, so you can do ubuntuuitoolit.UbuntuUIToolkitCustomProxyObjectBase
<elopio> balloons: import ubuntuuitoolkit
<elopio> and replay all toolkit_emulators for ubuntuuitoolkit.
<elopio> that's it. And thanks for the updates.
<balloons> elopio, well apparently we found out today all the apps that have the deprecation warning are running under python2, as phablet-test-run sees it as an error and falls back to py2
<elopio> balloons: yes, on reminders there's a workaround for that
<balloons> a fix is being pushed, but I thought I should just clean them all up
<elopio> and fginther fixed it on phablet tools, but it needs to land.
<balloons> elopio, well xnox is also looking at it atm..
<elopio> balloons, xnox: https://bugs.launchpad.net/ubuntu/+source/phablet-tools/+bug/1327325
<ubot5> Ubuntu bug 1327325 in phablet-tools (Ubuntu) "phablet-test-run will fail if the python3 import prints something to std" [High,Confirmed]
<balloons> elopio, yep already seen it :-)
<elopio> ok, I thought xnox was doing the fix again.
<elopio> oh, yes, he did an alternate fix.
<elopio> xnox: https://code.launchpad.net/~fginther/phablet-tools/fix-ptr-python3-import-check/+merge/222391
<elopio> you even approved it :)
<xnox> elopio: right yeah, that one was better.
<xnox> why did it not land yet?
 * xnox dputs it into the archive.
<elopio> xnox: don't know.
<balloons> ok elopio, so I swapped to as you suggested. however, the other side of the question is I'm still seeing the warning. I was trying to figure out why
<fginther> xnox, elopio, confusion over the process and not realizing that it had not landed until elopio brought it up again about a week ago :-(
<elopio> balloons: that's because I'm stupid
<fginther> (confusion on my part that is)
<elopio> and ubuntuitoolkit imports emulators, so it will always be thrown.
<elopio> I need to fix that.
<balloons> elopio, that was what I was seeing, just wanted a sanity check
<xnox> fginther: finishing test build and will dput in a sec.
<balloons> elopio, mind if I try fixing it?
<balloons> or can you do it quickly?
<elopio> balloons: not at all. I would appreciate it a lot.
<balloons> kk.. I'll add it to the list and try and clean everything up
<elopio> balloons: I think it would be just removing the import emulators from ubuntuitoolkit.
<elopio> but I'm not sure, so it might be quick but need to confirm. And I didn't have that on my TODO for this week, so feel free to do it.
<balloons> right, if it's quick I'll propose the mp today, if not it'll go on the list
<elopio> balloons: an alternate solution if that doesn't work is to swallow the warning when importing it from the __init__.py.
<balloons> elopio, mm.. ok ack
<elopio> ping thomi, veebers
<elopio> we have a big bad problem with the versions of QML components.
<veebers> elopio: hey how's it gong?
<veebers> oh
<thomi> sup elopio?
<thomi> elopio: I saw the bug
<thomi> elopio: and directed veebers to it as well
<veebers> I'm looking at it now
<elopio> the thing is that when they make a new version of Button, autopilot will see Button11 as the class name
<elopio> so with a new version of the toolkit, we can break all the existing autopilot tests.
<elopio> I'm not sure what's a good solution for that. I'm not even sure what's possible and what is not.
<thomi> elopio: yeah, that's not so cool
<thomi> elopio: I suspect it'll need some digging in autopilot-qt
<thomi> elopio: it'd be great to get a reproducer though
<thomi> the bug report is kind of vague
<thomi> elopio: can you (or someone else) please prepare a tarball that contains everything we need to reproduce?
<veebers> thomi, elopio: Yeah I agree, it'll probably need some digging into libauotpilot-qt. elopio can you provide an easy way to reproduce
<veebers> heh :-)
<thomi> I'm about 90% more likely to look at it then
<thomi> wot he sed
<veebers> elopio: I won't be able to look at it today, not sure if thomi is available sooner. But we'll look at it as soon as we can
<veebers> thomi: :-)
<thomi> ... once there's a reproducer there
<veebers> right
<elopio> thomi, veebers: if you inspect the clock with autopilot vis you will see a Page10. Would that be enough?
<thomi> elopio: not really
<veebers> elopio: a sample test script would be much better
<thomi> elopio: a *small* example
<thomi> max 10 lines
<elopio> I'll try to get one.
<thomi> the clock has so many components it's impossible to find the rigth one in autopilot-qt
<elopio> thomi, veebers: I've attached the examples to the bug:
<elopio> https://bugs.launchpad.net/autopilot-qt/+bug/1341671
<ubot5> Ubuntu bug 1341671 in Autopilot Qt Support "Versioned QML classes are no longer recognized by their public type name" [Undecided,New]
<thomi> elopio: which file do I run with qmlscene?
<elopio> thomi: qmlscene -testability name_of_file.qml
<thomi> elopio: right, but which one
<elopio> oh, sorry.
<elopio> thomi: both. We currently have the problem with pages.
<elopio> so any app using a Page will either show page10 or page11.
<elopio> but as we almost never use pages directly, it wasn't bad.
<elopio> now they will do the same with Button, which will be a huge pain.
<elopio> the first one will show you how it will look for current apps
<elopio> the second one for the apps when they update the version.
<thomi> elopio: OK, so you expect the 'Page' component to show up as 'Page', right?
<elopio> thomi: I'm not sure what to expect.
<elopio> as a new version might add features, it would be useful to be able to match it by version. Have a helper for Page10 and an different one for Page11.
<thomi> elopio: well, I can't fix this if you don't tell me what you want :)
<elopio> but it sucks that old apps will have to update.
<thomi> right now we present the Qml type name without much change
<elopio> thomi: what I was going to propose to you and veebers was a meeting with the toolkit guys tomorrow, to find a strategy for new versions.
<thomi> ugh
<elopio> thomi: and what I would love to see is being able to match many qml types to a single python class. Something a little better to what we have with the validate dbus method.
<elopio> but I'm not sure if that's a good strategy to go forward.
<elopio> we will need a custom proxy object for Button, for example. And that's something you didn't want before.
<veebers> elopio: not to use versions? ;-)
<elopio> veebers: yes, make my life easier should be the first option :D
<veebers> heh
<thomi> elopio: ack, it's been on my mind for a while
<thomi> elopio: actually - that's the soluton!
<thomi> man... I could kiss you right now :D
<elopio> for the current problems, I think I would be happy with something like this:
<elopio> class Button(base_proxy):
<elopio> qml_types = ['Button', 'Button10', 'Button11']
<elopio> thomi: no kisses please :) I accept hugs, but not too often.
<thomi> elopio: well, it'd be similar
<thomi> elopio: what timeframe is this needed for? I cna throw together a proposal and get you a copy by tomorrow I think
<thomi> best guess for implementation time right now is about 3 days...
<thomi> if I do it
<elopio> thomi: I think we can delay the release of the new button version, but not for long as the deadlines are already passed
<elopio> but we have never been able to release a toolkit in less than a week, so 3 days sounds perfect.
<thomi> elopio: writing a spec now. WIll you be around in 30 minutes to read a first draft?
<elopio> thomi: I will.
<thomi> ok, will ping you
<elopio> thomi: you should probably know of all the issues I've been having with the validate_dbus, so we don't hit them again with your proposal.
<thomi> elopio: I'm aware of some of them anyway, and this will fix that
<thomi> elopio: feel free to follow along: https://docs.google.com/a/canonical.com/document/d/1dLdjvRbrILs3314dBM7sKazHDJgeFe3i2E5Rk5pJHTM/edit#
<elopio> thomi: awesome. You can have one kiss.
<thomi> hmmm
<thomi> elopio: so you want one unified class called 'Button' that will work for both Button10 and Button11, right?
<elopio> thomi: yes.
<thomi> elopio: and the test author doesn't know which one it is?
<thomi> so, this isn't what you want:
<thomi> select_single(Button, version=10)
<elopio> thomi: hum, I haven't thought about that one, but doesn't seem useful for our current case.
<thomi> so, the one limitation I can't get past right now is that xpathselect has no way to say "select an object whose name starts with 'Button'", or "select an object whose name is one of 'Button10', 'Button11', etc.
<thomi> although that wouldn't be the hardest thing to add.
<elopio> thomi: but if you do it matching a substring, it would also match something like ButtonFOO.
<thomi> elopio: yeah, I think I prefer the second variant
<elopio> thomi: yes, that's the only want I need.
<thomi> it would mean that custom proxy classes would need to be updated every time you bumped the version number
<thomi> but TBH that's probably a good thing.
<elopio> thomi: that's would mean that we need a custom proxy class on the toolkit per every component that it provides.
<elopio> for me that's good
<thomi> elopio: hmmm, yes, it would
<elopio> but you said it was bad for components like button which will not provide any methods.
<thomi> that's ok?
<thomi> yeah, it's a bit icky
<elopio> well, it makes my life a lot easier. That way I can provide a certified set of helpers, and just concentrate on keeping them working...
<elopio> if people use something different and it breaks, it would not be my fault.
<thomi> understood
#ubuntu-autopilot 2014-07-15
<thomi> elopio: thoughts? https://docs.google.com/a/canonical.com/document/d/1dLdjvRbrILs3314dBM7sKazHDJgeFe3i2E5Rk5pJHTM/edit#
<thomi> elopio: you have edit / comment rights now
<elopio> checking.
<thomi> elopio: I need to go to lunch and run some errands in town. I'll be back in about an hour. Please leave notes (if you have any) in that docuemnt
<elopio> thomi: is the comma part of xpath? I thought it would be something like |
<elopio> thomi: ack, I'll comment.
<thomi> elopio: well, we can make it part of it
<thomi> elopio: I'm open to alternative suggestions for syntax though
<thomi> ok, bbs
<elopio> thomi: I might not be here when you return. It looks really good for me. I left you some comments, and I will show it to the toolkit devs tomorrow.
<thomi> elopio: ok, thanks
<thomi> elopio: still around?
<thomi> veebers: could you please review https://code.launchpad.net/~thomir/autopilot/refactor-test-logger/+merge/226063
<elopio> thomi: I'm back.
<thomi> elopio: I replied to your comments
<thomi> elopio: note that no one will ever actually see the query bytestring
<thomi> elopio: but I expanded the code examples to show how this fits with the existing validate_dbus_object method
<elopio> thomi: I thought xpathselect was a subset of xpath. If that's private, do it as you prefer.
<elopio> I'll report the bug about the cache tomorrow. It will take a little more time to make a small example for that one.
<thomi> elopio: yeah, it's only commonality is the name :)
<thomi> I picked a poor name 3 years ago, and it stuck :(
<thomi> ever since then I've hated it
<elopio> thomi: rename it to xps ;)
<thomi> that's a good idea, I might just do that
<thomi> libxps
<elopio> barry: hey, can you resubmit your mediaplayer branch with this one as a prerequisite?
<elopio> https://code.launchpad.net/~canonical-platform-qa/mediaplayer-app/fix1341956-test_no_video/+merge/226774
<barry> elopio: sure
<barry> elopio: done.  crossing fingers! :)
<elopio> barry: thanks.
<elopio> barry: please fill the MP checklist on your mediaplayer branch
<elopio> https://wiki.ubuntu.com/Process/Merges/Checklists/system-apps
<barry> elopio: done; let me know if that's sufficient
<elopio> barry: well, now that you ask, it would be nice for you to merge with the prerequisite, so Jenkins gives you the approval.
<barry> elopio: you want me to merge the prereq branch into mine and push?
<elopio> barry: yes. That way the test that fails on your MP will be skipped.
<barry> elopio: gotcha
<barry> elopio: done
<elopio> barry: thanks.
#ubuntu-autopilot 2014-07-17
<veebers> thomi: Can you review my latest changes to the screenshot MP for the Gdk importing please? https://code.launchpad.net/~veebers/autopilot/adding_screenshots_to_details/+merge/225423
<thomi> sure
<thomi> veebers: diff line 24 needs more info I think
<veebers> thomi: i.e. details for why the order matters etc. ?
<thomi> veebers: yes, ideally with a bug report
<thomi> veebers: also, if you specify 'version' to one of the import functions, but they've already been imported, what happens?
<veebers> thomi: hmm, that's a very good point. I think I'll remove the version stuff
<veebers> that was there to solve a previous version, so I think just having 3.0 there is fine
<thomi> veebers: other than that, it looks good to me
<veebers> thomi: coolio thanks. I'm just filing the bug then will update docstring
<veebers> thomi: what's the best way to file a bug when I know the package name? a search in launchpad for 'gir1.2-gtk-3.0' gives me binary package pages
<thomi> ubuntu-bug?
<veebers> oh yeah, forgot about that. I poked around and found "https://launchpad.net/ubuntu/+source/gtk+3.0", I'll give ubuntu-bug a whirl though
<veebers> thomi: fyi have pushed the fix
<thomi> veebers: done
<veebers> thomi: awesome, thanks
#ubuntu-autopilot 2014-07-18
<veebers> elopio: ping, hey you available to do a MP review for me?
<elopio> veebers: I am. Give me the link please.
<veebers> elopio: awesome, https://code.launchpad.net/~veebers/autopilot-qt/enable-datamodel-elements-add-new-nodes/+merge/224061
<veebers> elopio: will you be around much longer? I was about to get lunch but can hold off if you want me around to query etc.
<elopio> I'm going to have dinner soon but then I'll be back.
<elopio> I can leave you comments on the MP and we can chat after eating.
<elopio> veebers: one big details is that I have no idea what I'm reviewing here.
<elopio> I've never seen autopilot-qt code before.
<thomi> elopio: there's a first time for everything :)
<veebers> elopio: ah right, well we can hangout quickly if you want and can give you a quick overview
<veebers> elopio: thomi has (and I'll get a re-review too) reviewed so between the 2 of you it should get good coverage for AP related things as well as general code quality
<elopio> veebers: I'll just read it and get some context first.
<veebers> elopio: sweet, I'll head out for lunch. Thanks again :-)
<elopio> veebers: I'm going out for dinner. I'll continue with the branch when I'm back.
#ubuntu-autopilot 2014-07-19
<gerlowskija> I'm trying to run autopilot tests on an emulator with phablet-test-run, but I'm getting an error message: "sh: 1: /usr/bin/python: not found"  Has anyone seen something similar before?
#ubuntu-autopilot 2015-07-14
<balloons> veebers! hello my friend
<balloons> I am one curious cat on when we might see an new autopilot release. And specifically, I want https://code.launchpad.net/~nskaggs/autopilot/add-wm-sandbox-run/+merge/242274 in it :-)
<veebers> balloons:hey o/
<veebers> balloons: I could probably do one soon as I have a fix for unit test failures on wily. that would bring it in check with the vivid overlay (with the pointer fix)
<balloons> right.. that's also weird to have vivid overlay be > wily
<balloons> but then, the overlay is a different story :-)
<veebers> heh yeah, helps to make things a little more complicated. I'm not even sure if I can land in vivid overlay right now
<balloons> ok. And the release ofc would still be Autopilot 1.5 yes? I take it 1.6 is being held up with all these quick fixes going in?
<veebers> balloons: aye, would still be 1.5
<veebers> balloons: d'oh, I thought I had top approved this ages ago, was a little confused why it might not have been released
<veebers> balloons: let me top approve now and get a release in action
<veebers> is a good opportunity to sync wily/vivid
<balloons> veebers, that would be excellent. The new plugin for the SDK really needs to functionality
<veebers> balloons: I'm not sure I follow that?
<balloons> lol.. my typing / long day
<balloons> in short, I need to use a WM with the sandbox script, but can't until this is released
<balloons> and I too had thought it had gone in
<veebers> balloons: ah I see. Yeah sorry about that, hiccup on my part. Once merged to trunk I'll do the mojo needed to try get a branch that will land in v/w
<veebers> or failing that just do 2 releases
 * balloons pictures veebers whispering incantations
<veebers> ^_^
<ahayzen> Hi, is there a way of telling autopilot to launch the app as if it was going to run the tests (eg run setUp() etc), but not actually run them so i can test/debug the mocking/fixtures ?
<veebers> ahayzen: launching the app is separate to the tests or fixtures. You can always use a debugger and set a breakpoint where you want to start digging.
<veebers> i.e. import pdb; pdb.set_trace()
<veebers> although I like using ipdb instead as its a little nicer
<ahayzen> but i want to test why the fixtures/mocking aren't working, so i just want to 'run' the tests...without actually running the tests
<veebers> ahayzen: well, you could always write a standalone script and test the fixtures that way, but if you're wanting to debug a test you're going to have to run the test
<ahayzen> ok :-) i guess i could just have an empty test thinking about it
#ubuntu-autopilot 2015-07-16
<andreb> hi all
#ubuntu-autopilot 2015-07-17
<josharenson> I'm trying to write an AP test for unity8 SessionContainer. The test involves checking the number of running sessions, so it would be nice to be able to test for sessions.length > 1. Is there a way for AP to do this on a high level, or should I figure something else out inside unity8?
