[09:15] <kalikiana> ubuntu-qa, ping, build errors in uitk sphinx docs https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1431749
[09:19] <rhuddie> kalikiana, thanks, I'll log that issue and have a look
[09:20] <kalikiana> thanks, rhuddie!
[09:58] <rhuddie> kalikiana, I used sphinx-build to build the doc from trunk, it worked fine for me. how did you run it?
[09:59] <kalikiana> rhuddie: CI does https://jenkins.qa.ubuntu.com/job/ubuntu-sdk-team-ubuntu-ui-toolkit-staging-vivid-i386-ci/273/console
[10:01] <rhuddie> kalikiana, do you know if this is a new problem?
[10:02] <kalikiana> rhuddie: not really. I just noticed while checking the logs for unit test results
[10:02] <kalikiana> so it may or may not have been there for some time
[10:07] <rhuddie> kalikiana, ok. the fact it builds ok locally, suggests to me its a ci environment issue, but I'll check to see if anyone else has any clue on it
[10:27] <rhuddie> kalikiana, from this it looks like the tests/autopilot folder needs to be on sys.path, so ubuntuuitoolkit module can be found and imported: http://sphinx-doc.org/ext/autodoc.html#directive-automodule
[10:31] <kalikiana> rhuddie: oh, I guess it's run before install… and needs to set the build folder
[10:31] <rhuddie> kalikiana, yeah. it says you add it to the conf.py file in: ubuntu-ui-toolkit/documentation/autopilot-helpers/conf.py
[10:32] <kalikiana> aha! there's a comment mentioning that in fact
[10:33] <rhuddie> kalikiana, ah yes, right at the top :)
[10:34] <kalikiana> I haven't really done anything with sphinx… I just got worried when I see fatal errors :-D
[10:34] <kalikiana> I'll give that a try and see if I can make ci work
[10:34] <kalikiana> thank you for the pointers!
[10:35] <rhuddie> kalikiana, yeah, hopefully that should sort it out, no prob.
[13:26] <kalikiana> ubuntu-qa, ping, how can an Autopilot test be run using upstart? we need a way to test URI handling API in context of https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1429899
[13:29] <elopio> kalikiana: hello.
[13:30] <elopio> kalikiana: autopilot has a method to launch the apps with upstart
[13:30] <elopio> two actually. Give me a second...
[13:30] <elopio> http://people.canonical.com/~nskaggs/autopilot/api/autopilot.testcase.html
[13:31] <elopio> launch_click_package and launch_upstart_application.
[13:32] <elopio> on the toolkit, when we define the application as a QML and use the base class UbuntuUIToolkitWithFakeAppRunningTestCase, it is using launch_upstart_application.
[13:34] <kalikiana> hmmm so you're saying it already is upstart?
[13:35] <kalikiana> elopio: so for sending URIs is it required to be a click package?
[13:35] <kalikiana> looking at the docs atm
[13:36] <elopio> kalikiana: no, you can do it with launch_upstart_application.
[13:36] <elopio> kalikiana: now, the problem with URI handling is that url-dispatcher gets configured only when mir is running. Currently we have no qpa other than the one in mir client.
[13:36] <elopio> so if you are running this on desktop without mir, url-dispatcher will not handle the uris.
[13:38] <kalikiana> okay. so this would be phone-only for now - I can live with that for the moment, considering right now we have 0 testing for it in the uitk
[13:39] <kalikiana> "it" being UriHandler API in QML and StateSaver being affected by ContentHub behavior
[13:39] <kalikiana> elopio: how do you pass an URI then?
[13:40] <kalikiana> hmm there's launch_upstart_application vs. launch_test_application, the former has uris=[]
[13:41] <elopio> kalikiana: I would try to add some QML tests in there that don't require a QPA. Maybe putting a mock in http://doc.qt.io/qt-5/qml-qtqml-qt.html#openUrlExternally-method
[13:41] <elopio> kalikiana: hm, wait, maybe we are talking about different things in here.
[13:42] <elopio> can you describe the test that you want for me?
[13:42] <kalikiana> elopio: that unfortunately is completely different
[13:43] <kalikiana> elopio: so, we have UriHandler which takes URIs via DBus. but it relies on upstart implementing org.freeDesktop.application which the uitk merely listens to
[13:43] <kalikiana> that means we can only test it if upstart is actually running
[13:44] <kalikiana> elopio: on a desktop right now nothing is registered at all if you just launch an app
[13:44] <kalikiana> since there's no object there
[13:44] <kalikiana> I believe libnih is implementing the application object
[13:46] <elopio> I don't see any uri service on dbus on my desktop.
[13:46] <elopio> could it be the problem that the service is not installed?
[13:47] <kalikiana> that's what I was trying to say - as far as I understand upstart is implementing that service
[13:47] <elopio> (you got me lost, and now it's me asking the question, that's good customer support :)
[13:47] <kalikiana> and UriHandler piggypacks on that via the pid
[13:47] <kalikiana> which is part of the object path
[13:47] <elopio> kalikiana: upstart is running on desktop, and with ubuntu_application_launch you are using it. tedg is the one I would ask about it.
[13:48] <kalikiana> in fact the app_id, not pid
[13:48] <kalikiana> elopio: well, upstart doesn't launch anything on a current desktop, though ;-)
[13:49] <kalikiana> so autopilot has to do whatever is needed to make up for it
[13:49] <elopio> kalikiana: autopilot is using upstart to launch the application when you call launch_upstart_application.
[13:50] <kalikiana> okay, so in theory it might be as simple as passing a URI to launch_upstart_application
[13:52] <elopio> kalikiana: that's where I get lost. What kind of URI are you talking about?
[13:53] <elopio> the "uri" parameter that method receives is documented as:
[13:53] <elopio> app_uris – Parameters used to launch the click package. This parameter will be left empty if not used.
[13:53] <kalikiana> for example file:///home/phablet/Pictures/nyancat.png
[13:55] <elopio> kalikiana: I see. I haven't tried that, but if the docs are correct, it should work.
[13:58] <elopio> except on desktop, where we seem to be missing a dependency.
[13:59] <elopio> I have libnih-dbus1 installed, but I don't see the service.
[14:03] <kalikiana> elopio: uris don't seem to be passed
[14:03] <kalikiana> elopio: a related problem might be that APP_ID is never set
[14:05] <elopio> kalikiana: how do you pass the uris on the command line?
[14:05] <kalikiana> I don't, I'm using the API
[14:06] <kalikiana> hmmmm os.environ['APP_ID'] = application_name should work, right?
[14:06] <elopio> kalikiana: I'm lost. sorry.
[14:07] <kalikiana> elopio: I'm passing uris via launch_upstart_application and verifying that they show up in the QML
[14:07] <kalikiana> except they don't
[14:07] <elopio> kalikiana: in the phone?
[14:07] <kalikiana> elopio: no, on the desktop
[14:07] <kalikiana> as you suggested only upstart should be needed
[14:13] <elopio> kalikiana: yes, but I really don't know how this works so you shouldn't pay a lot of attention to me.
[14:13] <elopio> I thought that ubuntu-app-launch could not pass parameters to the apps.
[14:14] <elopio> kalikiana: do you have an example I could use to check it in the phone? I would like to see what happens in there.
[14:15] <kalikiana> I wouldn't know how you would use an example that's not a test - the point is to pass URIs
[14:16] <kalikiana> and really why doesn't it take my environment variable?
[14:18] <elopio> kalikiana: if it uses upstart, then you need to set the variable with inictl set-env.
[14:18] <elopio> kalikiana: I want to give a try to the test in the phone. That's the example I meant.
[14:18] <kalikiana> I think there must be some fundamental problem here, it "runs" syntax errors happily
[14:21] <kalikiana> aha!
[14:21] <kalikiana> so for some odd reason file-based tests use launch_test_application
[14:21] <kalikiana> that explains it
[14:23] <kalikiana> elopio: was this forgotten by any chance? we have two entirely different launch setups
[14:23] <kalikiana> and the second one can't use uris
[14:24] <elopio> kalikiana: ah, sorry, I thought it was the other way around.
[14:24] <elopio> kalikiana: not forgotten, just pending: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1305190
[14:26] <kalikiana> I'll try a string base dtest for now
[14:35] <kalikiana> interestingly all string-based tests fail for me now
[14:35] <kalikiana> unchanged
[14:38] <elopio> kalikiana: with something like autopilot.exceptions.ProcessSearchError: Search criteria (pid = 24498, object path = '/com/canonical/Autopilot/Introspection') returned no results ?
[14:39] <kalikiana> elopio: no, rather http://ix.io/gSi
[14:39] <kalikiana> even staging with no changes does that for me
[14:40] <kalikiana> elopio: could it be because I'm running systemd as init?
[14:40] <elopio> kalikiana: could be. I don't see that in the latest staging tests.
[14:43] <kalikiana> elopio: this is my branch in any case https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/uriPassingPOC/+merge/252906
[14:44] <elopio> kalikiana: I will give it a try in the phone. If it doesn't work, I'll report a bug to autopilot.
[14:44] <kalikiana> thanks!
[14:45] <kalikiana> I need a break now, bbl
[15:02] <dkessel> elopio: i just noticed you were interested in a quassel client for ubuntu phones in 2014 - have you found one yet?
[15:02] <elopio> dkessel: nop. Still waiting.
[15:02] <dkessel> too bad
[15:07] <elopio> dkessel: yes, the web clients that we have on the phone don't work well.
[15:08] <elopio> they don't keep the connection open.
[20:49] <dobey> elopio: whoot! so with the little fix to ubuntu-app-test i landed a couple hours ago, the pay-ui autopilot tests all pass in jenkins now on a real device, along with my pay-ui MP :)
[20:57] <elopio> dobey: awesome!
[20:57] <elopio> what was the fix about?
[20:58] <dobey> ubuntu-app-test was always exiting with 0, and we need to verify that pay-ui exits with certain exit codes; so i had to fix it to exit with the same status code as the child process
[20:59] <dobey> and the pay-ui MP is to make it use ubuntu-app-test when mir is the display server (and depend on ubuntu-app-test in the autopkgtest config)
[21:00] <elopio> dobey: thank you!
[21:01] <dobey> but now i have to wait to land that in trunk until after the other pay-ui bit is tested/released though, i think