[01:29] veebers: the bamf process manager will not work with xvfb? [01:33] hum, and I'm also having problems with ubuntu_upstart_launch [01:34] elopio: Are you saying you're having issues with using autopilot under xvfb? [01:35] veebers: yes. I'm trying to run the toolkit tests with autopilot3-sandbox-run [01:35] the ones that use ubuntu_upstart_launch failed to launch [01:35] elopio: hmm, I wonder if it's setting the environment variables as expected. I'm not sure oof the top of my head sorry, I don't have experience with the -sandbox-run script yet' [01:36] and the ones that use launch_test_application fail because they use the process manager to resize the window. [01:37] elopio: have you had it working in the past or is this a new attempt? [01:37] veebers: it's the first time I try it. [01:39] elopio: what are you running? I would like to give it a try [01:40] veebers: [01:40] bzr branch lp:ubuntu-ui-toolkit/staging [01:40] cd staging [01:40] qmake [01:40] make [01:40] source export_modules_dir.sh [01:40] cd tests/autopilot [01:40] autopilot3-sandbox-run -X -d ubuntuuitoolkit.tests.custom_proxy_objects.test_listitems.SwipeToDeleteTestCase.test_swipe_item_to_wrong_direction [01:40] something l ike that. [01:56] elopio: I'm pretty sure it's due to unity (and thus bamf) not running in the created environment, similar reason for the upstart issue. I'm just trying to confirm now [01:57] I'm not sure what bamf is, but yes, it says no applications are running even when they are on the launch_test_application case [02:01] hmm, I don't think I"m exactly right, but I'm on the right path [02:30] veebers: without xvfb or xephyr we can't run autopilot autopkgtests, right? [02:30] elopio: can I ask what you're using it for? I'm still poking around at the moment (re: the bamf stuff, I suspect the upstart stuff is a different ketle of fish) [02:31] elopio: honestly I don't know much about the autopkg tests, but I would say you're correct [02:31] elopio: that question of mine was directed in general, not your query re autopkgtests :-) [02:31] veebers: I'm trying to start running the autopilot tests as autopkgtests. The toolkit team is the one that suffers more because they have too many tests, so I tried to start there. [02:31] ah, right make sense [02:40] thomi: who would a good person to talk to about bamf nowadays? It looks like there needs to be 'something else' added to use it within Xephyr [02:40] huh? you shouldn't need to [02:40] you're running unity 7, right? [02:43] thomi: yeah I am, but it's not working as expected when using the autopilot3-sandbox script (which uses Xephyr & dbus-launch to create a new environment) so it's not using the same bamf connection as my desktop [02:43] well no, it wouldn't [02:43] but you also don't want it to, right? [02:44] thomi: why wouldn't I? At the moment elopio is trying to use it to run tests, and it's failing for him because the process_manager (bamf) isn't working for him [02:45] veebers: because you want bamf to match the nested apps, not the apps on your desktop [02:45] so I suspect you're not running unity7 in your nested session [02:45] or perhaps running u7, but not the bamfdaemon (although that should be auto-started, I believe) [02:45] thomi: no you misunderstood (or I didn't exaplion well). You're right I don't want it to match the apps on my desktop [02:46] it's the apps launched within the new newsted environment that aren't showing up in bamf [02:46] how do you know that? [02:46] thomi:right, there is no unity7 within the nested X [02:46] thomi: d-feet and ipdb [02:46] how are you connecting to the nested dbus session with d-feet? [02:47] from within my python dbugger I get os.environ['DBUS_SESSION_BUS_ADDRESS'] and plug that into d-feets 'connect to different bus' [02:48] ok, so I don't think your apps will be mapped unless u7 is running [02:48] but WRT your original question, I'd ask someone like Trevino or Stephen Webb [02:48] thomi: right, I guess that's the answer we're looking for. The 'something else' is unity7 :-) [02:49] I'm a little concerned that the toolkit tests need bamf :-/ [02:49] thomi: it shouldn't. But I want to resize the window and bamf is the only backend for that at the moment. [02:49] thomi: ok, also; Ted G is the man to talk to about ubuntu-app-launch right? (elopio is also having issues with that using the sandbox) [02:50] thomi: how could I resize an app on xephyr or xvfb without unity7 running? [02:50] yes, tedg is libUAL [02:51] elopio: why do you want to resize the app, and how do you do this on a device? [02:51] sweet, cheers thomi [02:51] thomi: I want to simulate the size the window will get on a device. [02:51] elopio: ahhhh [02:51] just for desktop runs. On the devices I don't do it. [02:51] that's really nasty [02:52] can't you set the window geometry when you launch it? [02:52] thomi: no. ubuntu-launch-app doesn't know about geometries [02:52] elopio, you could set the xephyr screen size [02:52] that was ted's explanation. [02:52] no wait, that doesn't affect the app [02:53] elopio: well, this is a really nasty hack, and TBH I'm not surprised we're finding problems with it [02:53] I don't understand why libUAL would have to know about *anything* in the command line parameters [02:53] but there you go - that whole area is a huge ball of oddness [02:53] thomi: it's a little bad. But shouldn't we be able to resize windows anyway? [02:54] elopio: on a platform where that makes sense, sure, and you can [02:54] elopio: but you're trying to do it on a platform that we don't support [02:54] (i.e.- a raw X session, with no desktop manager) [02:56] you are right, xephyr doesn't let me resize the app manually either. [02:58] veebers: if I change the xephyr window size, the app is just scaled in it. It seems to me that the only way to do it is to pass the window size when launching the app. [02:58] elopio: right, I redacted my suggested as soon as I said it, sorry :-\ [02:58] I could skip the device simulation scenarios for now. But we need the launch upstart working. [03:00] veebers: martin put some insteresting things about upstart here: /usr/share/autopkgtest/setup-commands/ubuntu-touch-session [03:01] * veebers looks [03:01] elopio: where would I see that on my system? DO I need to install something else? [03:01] veebers: sudo apt-get install autopkgtest [03:01] ahh, makes sense [03:07] elopio: right, it looks like there is some more details needed for upstart when using the sandbox script. Are you able to reuse the autopkgtest stuff somehow for what your doing? [03:07] veebers: I'm trying to set up the autopkgtests on the package to then run them with that setup script to see what happens. [03:07] elopio: ah ok, sweet. Let me know how it goes [03:08] I'm understanding half of what I'm doing :) I'm collecting tons of questions for Martin. [03:10] ^_^ [03:13] elopio: oh, thanks for update the touch duration branch of yours. Approved [03:13] veebers: thanks to you for the review. [04:16] veebers: the launch still fails with that set up. [04:17] elopio: :-( Can you tell why it fails? [04:18] veebers: it says the same thing as on xvfb, RuntimeError: Timed out while waiting for application to launch [04:18] it just takes a lot longer to say that [04:18] elopio: which part timed out? Is this autopilot, or the process manager or something else? [04:19] http://paste.ubuntu.com/8155837/ [04:20] veebers: it's autopilot waiting for upstart to launch the app. [04:21] elopio: are you able to write a simple example/script that launches an upstart app in Xephyr (without using autopilot)? We want to single out if it's autopilot or the upstart/dbus setup that's getting in the way [04:24] let me read the man [04:29] veebers: this seems to work [04:30] $ Xephyr -screen 1280x1024 :1 & [04:30] $ initctl set-env --global DISPLAY=:1.0 [04:30] $ ubuntu-app-launch dialer-app [04:30] if you have the dialer-app package installed. [04:31] elopio: what happens if you setup the "initctl set-env --global DISPLAY=:1.0" in the autopilot test? i.e. before the app is launched [04:32] I'm trying [04:32] hmm actually that's silly of me [04:32] oh actually maybe not [04:32] I was confusing ENV with the initctl set-env. [04:34] veebers: the xephyr display started by autopilot is :5.0, but it doesn't work. [04:34] it still fails to launch the app. [04:34] elopio: do you see anything come up on the xephyr screen? [04:35] veebers: nothing. [04:35] oh, but this works. [04:35] $ Xephyr -screen 1280x1024 :1 & [04:35] $ initctl set-env --global DISPLAY=:1.0 [04:35] $ autopilot3 run ubuntuuitoolkit.tests.custom_proxy_objects.test_listitems.SwipeToDeleteTestCase.test_swipe_item_to_wrong_direction [04:35] it's just the sandbox the one that fails to launch it. [04:37] elopio: hmm, so you're saying that running that makes it work (i.e. the app appears on the xephyr screen)? [04:37] veebers: yes. [04:37] elopio: I would say that it's the dbus stuff breaking it then (as the sandbox script uses dbus-launch) [04:38] elopio: you could prove that by editing the sandbox script to remove the dbus-launch part and running it, it will use your normal session bus but that's ok [04:38] this isn't a solution, but some debugging btw :-) [04:40] veebers: well, it would still miss the initctl set-env part. [04:41] elopio: oh sorry, I meant to say add that in (in the sandbox script) [04:42] veebers: yes. With the set-env and without the dbus-launch, the sandbox works. [04:43] elopio: It looks like there needs to be more setup for ubuntu-app-launch to work with the different session bus, but isn't that what that script that you linked me does? [04:45] veebers: I thought so. It could be that what failed on my adt-run execution was the missing set-env [04:45] I can try, but that's going to take longer than what I'll remain awake. I'll leave it running. [04:46] elopio: heh, let me know how it goes ^_^ [12:59] hey guys [12:59] is there any way for me to wait for a Qt signal in a test? [13:02] balloons: ^ any idea? [15:08] zbenjamin: there's a discouraged way to do it [15:08] http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/introspection/qt.py [15:08] it's undocumented and thomi keeps saying that we should remove it, because it almost always means that you are using autopilot wrong. [15:08] what are you trying to do? Maybe we can find an alternative. [15:08] elopio: why is the QtSignalWatcher discouraged? and what is the correct way [15:09] zbenjamin: when you are doing black box testing through the UI, you take the role of a real user. [15:09] real users don't have access to signals. They need to be notified through the UI. [15:17] so if you are waiting for something, there must be a visual clue for it. [22:40] veebers, can I use something that is python 3.3+ only in autopilot? [22:42] balloons: um, 3.3 is default in Utopic right? [22:43] python3.4 I thought is default? [22:44] balloons: ah, you might be right. Right so now autopilot is python3 and i utopic you can use what is default there (i.e. 3.4) [22:44] awesome