#ubuntu-autopilot 2014-09-08
<balloons> veebers, ronru asked me to wrap and sort the packaging for https://code.launchpad.net/~nskaggs/autopilot/fix-1328600/+merge/227399 so I did. Should be all set and all yours now
<veebers> balloons: sweetbix, I'm taking a look now. Did you see my query from earlier? (re: how does this effect current tests, do they need changes, have you tested it against, say, the cal. app)
<balloons> veebers, no I didn't see your query. So this should allow the calendar app and clock app to actually run tests against the datepicker
<balloons> I tried my original changes long ago against them, but haven't tried them since. Umm.. It would be useful to run the UITK tests without the qml tests to workaround the bug.
<balloons> I would say that's the best way to confirm things
<veebers> balloons: hmm, those are quite some packaging changes there :-P but if robru approves it that's ok by me. Normally I would ask that un-related changes like that are in a different pre-req branch
<balloons> veebers, yea I agree it muddle the water on packaging, but he requested it, so :-)
<veebers> balloons: ack, fair enough. Can you get his 'ok stamp' on that MP please
<balloons> veebers, yes I'll ask him to do so
<veebers> thomi: do you know why python3-autopilot relies on libjs-jquery & libjs-underscore? I can imagine it being a build dep for the docs, but not the python3-autopilot package
<thomi> veebers: it's a build-dep, is it not?
<veebers> thomi: it's both
<veebers> well, it's in the buld-deps
<thomi> veebers: it's for coverage docs
<thomi> the kbd shgortcuts
<veebers> thomi: ah ok, that makes sense
<thomi> no idea why it's a dependency of ap tho
<veebers> (well after decoding that sentence ;-) )
<veebers> oh, I got confused. So we don't know why it's a dep for the python3-autopilot package?
<veebers> balloons: I get a test error: http://pastebin.ubuntu.com/8294055/
<balloons> veebers, hmmm...
<veebers> I pulled, built packages, installed and ran that one test (autopilot.tests.functional.test_types)
<balloons> veebers, is DateTime(2013-12-31 23:00:00) coming from autopilot then? that would seem interesting.
<veebers> balloons: that datetime aka reference will be coming from item.foo, right?
<thomi> veebers: I don't know why it's a dependency, no - sorry
<veebers> thomi: ack, I'll investigate further
<balloons> veebers, my expectation is you would get 2014-01-01 in your local time from the qml, and we then compare it to the datetime object we create. I expect both to be 2014-01-01. the only diff between your run and my local run should be the local timezone that is assigned
<balloons> do you agree? If so, it would seem something isn't quite right.
<veebers> balloons: let me read what the test is doing
<veebers> balloons: hmm, the DateTime init is receiving timestamp: 1388487600 which seems fine (think), but poking around with the debugger I see these: http://pastebin.ubuntu.com/8294235/
<veebers> am I confused or is something not right happening there
<balloons> veebers, ohh I get it
<thomi> veebers: one method applies DST, the other does not
<veebers> ah right
<balloons> veebers, at least jenkins loves me :-) green is green
<veebers> balloons: heh :-) it's just that pesky NZTZ
<balloons> veebers, what concerns me I guess is the property is read from the qml and converted to local time for you, so it's not 2014-01-01.
<balloons> which is fine, it just means my reference date needs to expect that
<balloons> which is what we said we wanted.. so I think it's ok to tweak the ref object
<balloons> veebers, do you agree with this? http://paste.ubuntu.com/8294466/
<balloons> mmm.. I suppose I should derive the timestamp from the date
<veebers> balloons: no, that's effectively just going to test that an objects value is the same as a copy of that object (using the references timestamp)
<balloons> yep yep
<veebers> what if the timestamp has been changed or whatever
<veebers> balloons: also, seeing that code I'm a little concerned that existing autopilot tests will need to change to reflect the changes within autopilot
<balloons> veebers, http://paste.ubuntu.com/8294543/?
<balloons> little crazy..
<veebers> that seems a little heavy handed. Perhaps there needs to be a change in autopilot-qt (and -gtk)?
<balloons> does it work locally for you?
<balloons> veebers, the goal of this silliness was to replicate current behavoir
<balloons> the idea was not to break anything and continue with the local timezone idea
<veebers> balloons: ah ok, so not suggested as a fix?
<veebers> sorry I'm a little confused onw :_\
<balloons> veebers, the paste? sorry I was jumping back to your thoughts about " also, seeing that code I'm a little concerned that existing autopilot tests will need to change to reflect the changes within autopilot"
<balloons> on the overall changes, I was attempting to not break anything, which became painful at times
<balloons> we could simply assume everything is in UTC and store things in utc etc.. a bit saner
<veebers> balloons: ah ok, I asked that because this test is effectively doing what one would do in a test (i.e. compare the date against what was returned from the dbus procy object)
<veebers> if you're having to do a bunch of code to produce an object to compare against we might have a problem
<balloons> right.. I'm struggling with what I want this functional test to be.. and also a bit sad to see it fails for you.. But we understand why
<veebers> right ok, I think I'm back up to speed now :-) I'll try your paste and make sure it works for me
<veebers> balloons: that latest paste of yours passes on my machine
<balloons> veebers, right excellent. It passes because I'm replicating exactly what I expect that object to be after being read by autopilot
<balloons> the question I suppose now is, are you happy with how autopilot treats the date/
<balloons> veebers, I suppose we should simply run uitk tests and see what happens
<balloons> minus the datepicker workaround changes I made
<veebers> balloons: that would be a good start, are you able to make that so?
<veebers> heh 'make it so'. balloons: put a hamburger on an intercept course with my mouth, make it so
<balloons> veebers, I'm hungry.. no dinner yet for me!
 * balloons running
#ubuntu-autopilot 2014-09-09
<balloons> veebers, uitk datepickers seem happy
<veebers> balloons: interesting, I wonder why this test (which should be similar to what's happening in the uitk tests) is failing.
<veebers> balloons: oh wait, I should run the tests here too to be certain :-)
<veebers> balloons: are you running them on your desktop or phone?
<balloons> veebers, I did both. But on the phone I removed the min and max in the qml inside test_date_picker.py
<balloons> I can confirm it doesn't blow up even after removed, which was the original bug :-)
<veebers> heh :-)
<veebers> balloons: to make it easy for me (because I'm lazy) which branch are you testing, I'll test it here on my desktop
<balloons> veebers, I pulled lp:ubuntuuitoolkit
<balloons> there's a ton in there.
<veebers> ah right
<balloons> the calendar tests don't use the datepicker directly, but I suspect that's the other best thing to try
<balloons> the uitk is fine, I wouldn't worry, since it was mostly about the datepicker being correct
<balloons> calendar app is lp:ubuntu-calendar-app
<balloons> I don't suspect we'll see any errors
<balloons> ^^ I was wrong
<balloons> veebers, so calendar fails and has some problems
<balloons> I'm just running on the desktop and running the tests in trunk
<balloons> reading the local datetime from the qml property doesn't mess with datetime.now anymore
<veebers> balloons: :-\ I don't understand your last comment there, 'dpesn
<veebers> d'oh "doesn't mess with datetime.now"?
<balloons> yea.. just pointing out they fail. .. ohh the datetime from qml property doesn't mesh with datetime.now.. in other words, the date is wrong
<balloons> *mess=mesh
<balloons> hehe
<balloons> for me; local 2014-09-07 23:00:00-04:00, today 2014-09-08 20:32:55.012863
<balloons> you can see it's about 21 hours off
<veebers> balloons: hmm, i'm not sure off the top of my head how to attack that sorry. I also need to pop out to run some errands. I'll be back in a little bit
<balloons> veebers, wow.. nvm.. turns out the test fails unless you are in UTC.. crazy
<balloons> veebers, so the trunk tests fail unless run as UTC. If I swap to UTC, everyting passes under the new code and it mirrors the old
<veebers> balloons: sorry errands took longer than expected. That's interesting, I would have to take a look at the code in libautopilot-qt to see what it's sending down the line re: dates
<balloons> veebers, yea, you could compare before and after to see if it's the same.
<veebers> balloons: I can't really do that right now though as I have a couple of other things to handle :-\
<veebers> balloons: it must be getting late for you too, right?
<balloons> veebers, I'll play with the prints another time.
#ubuntu-autopilot 2014-09-12
<nik90> elopio: ping me when you are online. We can discuss https://code.launchpad.net/~canonical-platform-qa/ubuntu-clock-app/xvfb_and_qml_tests/+merge/234421
<elopio> ping nik90
<nik90> elopio: hey
<nik90> elopio: I was looking at your MP in the morning
<nik90> elopio: and when opening it in qtc, I noticed Qml tests disabled: xvfb-run not found
<nik90> this was on my laptop which has xvfb installed
<elopio> nik90: hello. I was just trying to run the tests with xvfb, because fginther said they failed for him on CI.
<elopio> but lets see... On qtcreator, on the build -> make menu
<elopio> I only see check, autopilot, install, uninstall. How do I get to run make test?
<nik90> me too
<nik90> I used to do it manually from terminal
<nik90> so I used to do mkdir builddir && cd builddir
<nik90> cmake .. && make
<nik90> then make test
<balloons> elopio, fyi, francis's experiments are not in the normal clock app CI jobs
<elopio> nik90: making from the builddir doesn't work because cmake is creating the files on the root of the branch.
<elopio> http://paste.ubuntu.com/8327808/
<elopio> balloons: you mean that they are not run on MPs?
<nik90> elopio: the steps I mentioned above works for me
<nik90> elopio: well the tests don't run since I am trying to run this on trusty
<nik90> elopio: but make test correctly shows the tests
<balloons> elopio, no they are not atm. francis tried but didn't succeed in getting them to run..
<balloons> they are not in the mp jobs
<elopio> nik90: I might had a cmake cache or something. Now it's writing the files on the builddir.
<elopio> and yes, make test works.
<elopio> so I'm not sure where are you getting the message that xvfb is not found.
<nik90> elopio: so when you opened it in qtc, how did you run the tests?
<nik90> elopio: since I don't see tests in the build->make menu
<elopio> nik90: I didn't run them from qtc. That was my first question.
<nik90> elopio: ah ok..I don't think it will work with qtc, or atleast that's not the goal.
<nik90> elopio: command line works
<elopio> nik90: I'm confused :)
<elopio> but if you think it's ok, I'm ok.
<nik90> elopio: I am a bit confused as well :P
<nik90> elopio: ok so previously one couldn't run qml tests in qtc.
<nik90> elopio: when you changed the cmake files, I figured you added a custom target for make tests to make it runnable from within qtc.
<nik90> elopio: but I see that wasn't the case, which is why I said it is okay
<elopio> nik90: well, make test doesn't need a custom target. I thought qtc would find it anyway.
<elopio> and in your initial implementation, you didn't have a custom target either.
<nik90> yup I didn't
<elopio> I could add one to see what happens.
<nik90> its just a luxury, so if you want to go ahead
<elopio> hum, but then add_test I think wouldn't work.
<elopio> zbenjamin: how can we run make test from qtcreator?
<zbenjamin> elopio: well you could add a custom run configuration that executes make test in the builddirectory
#ubuntu-autopilot 2015-09-09
<balloons> o/
<gang66> Hello balloons
<nik90> hey
<balloons> hey guys
<balloons> so it's time to solve your autopilot issues!
<nik90> :)
<balloons> just finishing up the last little details on https://core-apps-jenkins.ubuntu.com/
<nik90> ooh nice
<gang66> ./ubuntu_clock_app/fixture_setup.py:                'sudo setprop custom.location.testing {}'.format(test),
<gang66> ./ubuntu_clock_app/fixture_setup.py:                'sudo restart ubuntu-location-service && '
<balloons> nik90, yea you can see my email. Login and you can build away
<gang66> Why do we need these sudo there?
<balloons> you can't restart the location service without it.
<balloons> it's more a bigger question of why we need to restart location service
<nik90> I don't remember adding that line either
<nik90> Could it be to show the location-trust-store prompt and press the "ok" button?
<nik90> at one point clock-app was failing because of it, and we fixed it once the trust-store became testable
<balloons> right. If there's anymore of those, it's not a testable service, we should pushback on making sure it is testable. But I think we've rooted all those out
<nik90> balloons: I am admiring the jenkins service at the moment. Its so cool that I can provide it with branch link, framework to see if it passes or not! Superb! No more having to do empty commits in the Mp just to kick jenkins to rebuild and test.
<nik90> wait is jenkins running it on the krillin device *and* a local machine? Or just krillin atm?
<balloons> nik90, jenkins builds on a machine, but the tests run on the krillin
 * nik90 leaves university. bbs
<balloons> so, do the tests run for you guys?
<balloons> as in, does the app launch and try to do something/
<gang66> nope it is just crashing
<nik90> balloons: no it crashes after opening the app. Pretty much at MainView12 point
<balloons> I'm trying again with a fresh branch
<balloons> I'm not even getting that far, imho
<gang66> https://core-apps-jenkins.ubuntu.com/job/adt-krillin/15/artifact/logs/autopilot-stderr/*view*/
<gang66> autopilot.exceptions.StateNotFoundError: Object not found with name 'MainView'.
<gang66> I'm curious why it cannot find MainView
<balloons> there we go, finally it launches
<balloons> ok, I'm on the same page as you now :-)
<balloons> gang66, the issue with mainview is because of versioned qml classes and autopilot
<balloons> indeed, mainview12 is the mainview, fun times
<balloons> here's the bug 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]
<gang66> How we could workaround it?
<balloons> I need to check and see if some code landed in autopilot 1.5
<balloons> the fix is really in autopilot itsel
<balloons> indeed, it landed in 1.5, sweet
<nik90> oh
<nik90> what are we using in vivid jenkins at the moment? Autopilot 1.4 or 1.5?
<balloons> vivid jenkins does make it hard
<balloons> mmm.. but it's using the overlay, so we should be fine
<balloons> yep, it should be using  1.5.1+15.04.20150908-0ubuntu1
<balloons> ok, so the fix is what's described in here https://code.launchpad.net/~canonical-platform-qa/autopilot/fix-cpo-having-different-name-1337004/+merge/262047/comments/668227
<balloons> nik90, you about?
<nik90> balloons: yes
<balloons> so autopilot is complaining about finding multiple mainview matches
<balloons> and indeed I see several mainviews amongst the qml files. I assume this hasn't changed from before
<nik90> multiple mainviews in the qml files?
<balloons> app/upstreamcomponents/PageWithBottomEdge.qml:    MainView {
<balloons> app/ubuntu-clock-app.qml:MainView {
 * nik90 checks
<nik90> balloons: app/upstreamcomponents/PageWithBottomEdge.qml:    MainView { doesn't exist
<nik90> it is a comment
<nik90> looking at http://bazaar.launchpad.net/~ubuntu-clock-dev/ubuntu-clock-app/trunk/view/head:/app/upstreamcomponents/PageWithBottomEdge.qml
<balloons> ahh indeed ;-)
<nik90> ;)
<balloons> Nevertheless, AP isn't happy. ValueError: More than one custom proxy class matches this object: Matching classes are: <class 'ubuntu_clock_app.PageWithBottomEdge'>,<class 'ubuntu_clock_app.ClockPage'>,<class 'ubuntu_clock_app.MainView'>
<balloons> so I'll sort it
<nik90> ok, I am installing autopilot 1.5 from the PPA on my vivid machine now
<nik90> hmm I am actually in wily
<balloons> you forgot you upgraded?
<nik90> doesn't 15.10 get autopilot 1.5 without PPAs?
<balloons> yep
<nik90> its my development machine. So I kind of forgot about it :P
 * nik90 updates
<balloons> I actually dropped one of my machines back to trusty for fun. So I have no vivid
<nik90> oh...I realize how easy it is when developing on the latest development release.
<balloons> yea, autopilot is very unhappy
<balloons> it can't even traverse the tree :-(
<balloons> nik90, so I'd like to set an objectName for the MainView as one way to stop AP from being so confused. However, the app won't run if I set one
<nik90> hmm, the app doesn't run?
<nik90> let me try setting it
<balloons> yes please
<nik90> balloons: in ubuntu-clock-appq.qml, we already have the objectName of mainView set to 'clock'
<nik90> http://bazaar.launchpad.net/~ubuntu-clock-dev/ubuntu-clock-app/trunk/view/head:/app/ubuntu-clock-app.qml#L33
<balloons> lol, ok let me try again
<balloons> I tried the fix out on music, it works
<balloons> so it should fix clock too
<ahayzen> ...did someone mention music ? ;-)
<balloons> ahayzen, so let me give you a little diff
<nik90> ;D
<balloons> ahayzen, http://paste.ubuntu.com/12323350/
<ahayzen> heh the MainView vs MainView12 thing
<balloons> ahayzen, that little method is a 'nice way' of working around the greater bug
<ahayzen> looks it :-)
<balloons> it also lets you set the query name for anything you wish, so you can call a local class 'andrewisawesome' and have it point at anything in the tree
<ahayzen> sweet :-)
<balloons> nik90, clock however isn't so nice.. It really is confused. I think we're hitting https://bugs.launchpad.net/autopilot/+bug/1350532 too
<ubot5> Ubuntu bug 1350532 in Autopilot "validate_dbus_object can cause more than one class in the cpo cache" [High,Confirmed]
<nik90> :/
<balloons> in a moment veebers will be here
<balloons> then we'll get out the pitchforks
<balloons> ahah, ok, so I get why now
<balloons> woot, success
<nik90> wat did you do?
<balloons> I did the simple fix, but I realized it was our own class declarations that was causing AP to go nuts
<balloons> clockpage and pagewithbottomedge were both pulling in mainview also
<nik90> oh
<balloons> i thought it was in the qml, but lol, nope it's in our helpers
<balloons> ok, let me commit this
<nik90> so does it run now?
<balloons> yea, it tries to do things now
<nik90> cool
<balloons> lp:~nskaggs/ubuntu-clock-app/fix-ap-mainview
<balloons> you still get my debugging info if you pull that now, lol
 * nik90 test
<balloons> rev 380 is more or less a clean base to fix things
<ahayzen> balloons, the new coreapps jenkins looks awesome btw :-)
<balloons> I'm glad you like it. Some more goodies and tweaks to do, but it's ready to rock.
<balloons> we've been delayed on getting the MP functionality working
<balloons> I still have my MP ready and waiting on your project
<balloons> nik90, so are you going to attempt to actual correct the tests now or ? I don't want us both working on the same thing, heh
<nik90> balloons: I am going to be real busy with uni for the next 1-2 weeks. But its something that me and gang66 are putting emphasis on for this release.
<balloons> ok, I'll keep going and see if I can't get at least one test running and propose something
<balloons> thanks for the help in deciphering this
<nik90> balloons: oke, but beware the whole navigation has changed..so its going to be lot of change to get that first test passing.
<nik90> (code wise)
<balloons> righto
<nik90> balloons: and thnx a lot :)
<veebers> barry: Hey if you're around, I believe this bug should be considered fix released? https://bugs.launchpad.net/autopilot/+bug/1488175
<ubot5> Ubuntu bug 1488175 in Autopilot "FTBFS on Wily" [Undecided,In progress]
<veebers> barry: unless there are other issues?
<barry> veebers: i *think* it's due to testtools bugs, but this is mostly for tracking.  if it's messing you up, the bug can be closed
<veebers> barry: ah right, this is failing to build in the 3.5 ppa right?
<barry> veebers: yep
<barry> veebers: i suspect it would also fail if we rebuilt testtools in the archive
<veebers> barry: ah ok, that's not good :-\ Is there anything I can do to help? Or is it waiting on something else
<barry> veebers: upstream testtools isn't compatible w/ the version of twisted we have in the archive.  there's a patch that *almost* gets us there, but i'm chasing down one last failure.  i'll update the ap bug once it all gets straightened out.  thanks for your help tho, much appreciated!
<veebers> barry: nw, I'll be interested to see how it goes
<barry> veebers: me too :)
