| Saviq | veebers, hey, around yet? | 18:39 |
|---|---|---|
| veebers | Saviq: Hi, I' | 19:40 |
| veebers | m aruond now | 19:40 |
| veebers | err I'm around now* | 19:40 |
| Saviq | veebers, hey | 19:43 |
| Saviq | veebers, I left you a note on your "u8 tests use upstart" MP | 19:43 |
| Saviq | veebers, I'll be around for some time still if you get it to a "ready for review" state | 19:45 |
| veebers | Saviq: This is the OSK stuff? | 19:47 |
| veebers | Saviq: a couple of things, why isn't OSK running at that stage, does it die when unity8 is stopped? Also, none of the unity8 tests at use the OSK for the tests themselves (as stated in the bug) | 19:48 |
| Saviq | veebers, it crashes sometimes, yeah | 19:49 |
| Saviq | veebers, but the new unity8 job makes sure it's started | 19:49 |
| Saviq | veebers, so as long as we launch unity8 with upstart, should be good | 19:49 |
| Saviq | veebers, the password entry do | 19:50 |
| Saviq | veebers, well, they type stuff in | 19:50 |
| Saviq | veebers, but autopilot uses maliit internally | 19:50 |
| veebers | Saviq: oh ok. So no need to merge the fix the specifically starts OSK, just merging the 'start with upstart' will do? | 19:50 |
| Saviq | veebers, yeah, and making the "recreate the finger" workaround not on Desktop | 19:52 |
| Saviq | veebers, ap using maliit is bug #1238645 btw - to track what we want to do with it | 19:52 |
| ubot5 | bug 1238645 in Unity 8 "Shell does not get autopilot keyboard input if maliit isn't running" [Undecided,In progress] https://launchpad.net/bugs/1238645 | 19:52 |
| veebers | Saviq: autopilot only uses maliit internally if it's using the osk backend, it's not here. The only reason that it pops up during the tests is because a text input becomes focused | 19:53 |
| Saviq | veebers, how can you tell it's not using the osk backend on devices? | 19:53 |
| Saviq | veebers, or do you mean on desktop it does not? | 19:53 |
| Saviq | veebers, oh btw | 19:53 |
| Saviq | veebers, unity8.conf job - we should move it to lp:unity8 | 19:54 |
| Saviq | veebers, do it in your MP | 19:54 |
| Saviq | veebers, and I'll make sure of removing it from the ubuntu-touch-session | 19:54 |
| Saviq | -the | 19:54 |
| veebers | Saviq: I mean on device, I can tell 2 ways: in the logs you see something like: DEBUG _uinput:79 - Pressing o (24) (notice the _uinput) and that the keyboard isn't doing anything while things are being typed in | 19:55 |
| veebers | Saviq: I don't follow, the 'unity8.conf job'? | 19:55 |
| Saviq | veebers, upstart | 19:55 |
| Saviq | veebers, unity8.conf is in lp:ubuntu-touch-session - we need to move it to unity8 if we want to run unity8 on the desktop via upstart for ap tests | 19:56 |
| Saviq | veebers, regardless - starting maliit makes sure we do get the keyboard input | 19:56 |
| veebers | Saviq: yes, I can confirm that's the same for me (re: keyboard) | 19:57 |
| Saviq | veebers, so starting u8 for testing will get us maliit anyway | 19:57 |
| veebers | Saviq: right, so: Don't merge the 'start maliit' fix, add the u8.conf which will make it work for desktop and it's ready | 19:58 |
| Saviq | veebers, we still want: | 19:59 |
| Saviq | 16- from autopilot.input import _uinput | 19:59 |
| Saviq | 17- _uinput._touch_device = _uinput.create_touch_device() | 19:59 |
| Saviq | 18+ if model() != "Desktop": | 19:59 |
| Saviq | 19+ from autopilot.input import _uinput | 19:59 |
| Saviq | 20+ _uinput._touch_device = _uinput.create_touch_device() | 19:59 |
| Saviq | 21+ #### | 19:59 |
| Saviq | veebers, as that crashes compiz and/or Xorg on desktop | 19:59 |
| Saviq | veebers, but yeah | 19:59 |
| Saviq | 23+ #### FIXME: This is a work around re: lp:1238645 #### | 19:59 |
| Saviq | 24+ if model() != "Desktop": | 19:59 |
| Saviq | 25+ subprocess.call(["/sbin/initctl", "start", "maliit-server"]) | 19:59 |
| Saviq | 26+ def stopMaliit(): | 19:59 |
| Saviq | 27+ subprocess.call(["/sbin/initctl", "stop", "maliit-server"]) | 19:59 |
| Saviq | 28+ self.addCleanup(stopMaliit) | 19:59 |
| Saviq | we don't need anymore | 19:59 |
| veebers | Saviq: ah understood | 19:59 |
| Saviq | veebers, btw, there's no python bindings for upstart? it's kinda ugly to call initctl everywhere | 20:00 |
| Saviq | veebers, ah, and shouldn't it use _patch_environment for QT_LOAD_TESTABILITY as well? | 20:02 |
| Saviq | veebers, also | 20:03 |
| Saviq | 84+ self._using_upstart = False | 20:03 |
| Saviq | 85+ if model() != "Desktop": # or check env | 20:03 |
| Saviq | 86+ self._using_upstart = True | 20:03 |
| veebers | Saviq: hmm, I agree re: ugly I'm just double checking for bindings now | 20:03 |
| Saviq | why don't we not want to use upstart on desktop? | 20:03 |
| veebers | Saviq: hmm, no, _patch_environment is there for the difference between using and not using upstart | 20:03 |
| veebers | if we'regoing to use upstart on desktop that changes | 20:04 |
| Saviq | veebers, yeah - why would we not want to run under upstart | 20:04 |
| Saviq | veebers, can use upstart on desktop too, no? | 20:04 |
| veebers | Saviq: It's not that we wouldn't it's just that it wasn't at the time. I"m not sure, I assume that we can use upstart on desktop | 20:04 |
| Saviq | veebers, where we would like *not* to, potentially, is when running tests on a local installation - unless obviously we can point upstart at a different dir to find unity8.conf | 20:05 |
| veebers | Saviq: which reminds me, with the MR as it currently is the only way to test a unity8 branch that is in devlopment will be to build a package, install then run the tests | 20:05 |
| Saviq | in case unity8 is not installed system wide | 20:05 |
| Saviq | ↑ that | 20:05 |
| veebers | Saviq: right, :-) | 20:05 |
| Saviq | ;) | 20:05 |
| veebers | Saviq: I'm pretty sure that we could write an override file that points to the path of the binary | 20:06 |
| veebers | i.e. exec /path/to/unity8/in/dev | 20:06 |
| veebers | actually, we'll need to do that on the desktop right so we can pass it the -geo etc. | 20:06 |
| Saviq | veebers, I think I'm ok with that limitation | 20:07 |
| Saviq | or well, right... | 20:07 |
| Saviq | we should try and find a way to run the local version :/ | 20:08 |
| veebers | Saviq: right, I think the override version will work, I can test it out. | 20:08 |
| veebers | Saviq: also, that repo you linked me (lp:ubuntu-touch-session) apparently doesn't exist | 20:08 |
| Saviq | right, looking | 20:08 |
| veebers | cheers | 20:09 |
| Saviq | veebers, https://launchpad.net/session-manager-touch | 20:09 |
| Saviq | veebers, yeah, an .override could work indeed | 20:12 |
| mhr3 | for a moment i was wondering whether it's monday already | 20:13 |
| Saviq | veebers, or maybe even - maybe we could prepend PATH? | 20:13 |
| Saviq | mhr3, for some people it is ;) | 20:13 |
| mhr3 | Saviq, it shouldn't be for you though :) | 20:14 |
| Saviq | veebers, if we set-env PATH to prepend builddir/install/bin, think that'd work? | 20:14 |
| Saviq | veebers, or well, we could build support for something like that into the job | 20:15 |
| Saviq | so that we don't require manual intervention from people | 20:15 |
| Saviq | mhr3, blah blah blah ;P | 20:15 |
| mhr3 | Saviq, workaholic :P | 20:17 |
| mhr3 | otoh i spent yesterday couple of hours trying to figure out what's wrong with mediascanner... so, ehm, maybe i shouldn't call names :P | 20:18 |
| Saviq | ;) | 20:22 |
| veebers | Saviq: well, the test already gets the path to the binary, I was going to write an override file if the path isn't system. Although I presume that set-env'ing PATH would work too | 20:24 |
| veebers | Saviq: ah, prepending PATH would work for the binary but not the args (i.e. geo on desktop) | 20:25 |
| Saviq | veebers, yeah, args are something I don't know how to do with upstart | 20:26 |
| Saviq | veebers, but well, should be possible, shouldn't it? | 20:27 |
| Saviq | veebers, like we can pass GEO=blah and use that in the upstart job? | 20:27 |
| veebers | Saviq: the only way I know of is using the override file :_\ | 20:27 |
| Saviq | veebers, or even ARGS=-blah -blah | 20:27 |
| veebers | Saviq: perhaps, I'm not sure | 20:27 |
| Saviq | veebers, yeah, you can just "start unity8 GEOMETRY=blah" and then use it as "exec unity8 -geometry=$GEOMETRY" | 20:28 |
| veebers | Saviq: ah, this is in the unity8.conf right? (the exec un . . .) | 20:29 |
| sergiusens | Saviq, veebers pass args through a set-env and consume them from an upstart override job? | 20:32 |
| sergiusens | or patch the real upstart job | 20:32 |
| veebers | sergiusens: that's wha Saviq is suggesting and patch in unity8.config | 20:32 |
| veebers | sergiusens: ^_^ | 20:33 |
| sergiusens | veebers, sorry, only read the first 4-5 lines of my further back backlog | 20:33 |
| veebers | sergiusens: no worries, I appreciate the help/feedback | 20:33 |
| sergiusens | well I'm +1 | 20:33 |
| Saviq | veebers, no | 20:39 |
| Saviq | veebers, well, why set-env | 20:39 |
| Saviq | there's arguments to jobs | 20:39 |
| Saviq | or well | 20:39 |
| Saviq | "initctl start unity8 FOO=bar" and "inictl start unity8 FOO=baz" might be different jobs | 20:39 |
| Saviq | veebers, so yeah, it might be better to pass through a set-env then | 20:40 |
| Saviq | or no, "instance" clause is what's doing it :D | 20:40 |
| veebers | Saviq: right, but those vars set by set-env need to be consumed at some stage right? | 20:41 |
| Saviq | veebers, AFAICT no need for set-env on them - just: | 20:41 |
| Saviq | initctl start unity8 FOO=bar | 20:41 |
| Saviq | and then in the .conf | 20:41 |
| Saviq | you can use $FOO | 20:41 |
| Saviq | I'm good with ARGS | 20:41 |
| Saviq | and so "exec unity8 $ARGS" | 20:41 |
| Saviq | in unity8.conf | 20:42 |
| Saviq | sergiusens, ↑? | 20:42 |
| veebers | Saviq: cool (thats' what I was suggesting in unity8.conf) | 20:42 |
| veebers | Saviq: minor issue with just bringing in unity8.conf to lp:unity8, it contains this: | 20:43 |
| veebers | post-start script | 20:43 |
| veebers | sleep 12 | 20:43 |
| veebers | /usr/bin/ofono-setup | 20:43 |
| veebers | end script | 20:43 |
| veebers | (which won't work on desktop) | 20:43 |
| Saviq | veebers, let's hope it's not going to be a critical issue (just a warning) | 20:43 |
| Saviq | veebers, and I'll talk to people to move it out of unity8.conf tomorrow | 20:43 |
| Saviq | veebers, if it is critical - just move it out, and I'll talk to people where to put it again | 20:44 |
| sergiusens | Saviq, that's good, it's how the application job does it | 20:44 |
| veebers | Saviq: Hmm, I thought it brought up the crash dialog, but maybe i was wrong | 20:45 |
| Saviq | sergiusens, yup | 20:45 |
| Saviq | veebers, if it does - just remove it, I'll ask someone to put it somewhere in a better place | 20:45 |
| veebers | Saviq: cool, will do. | 20:45 |
| sergiusens | Saviq, that can be a separate job | 20:46 |
| Saviq | sergiusens, yup, I thought so | 20:46 |
| Saviq | veebers, it just occurred to me, we can use the same for the binary path | 21:20 |
| Saviq | veebers, i.e. | 21:20 |
| Saviq | initctl start unity8 BINARY=/path/to/binary ARGS= | 21:20 |
| Saviq | "-foo -bar" | 21:20 |
| Saviq | and then in the .conf: | 21:20 |
| Saviq | exec ${BINARY-unity8} $ARGS | 21:20 |
| Saviq | ${BINARY:-unity8} that is | 21:21 |
| Saviq | assuming it'll get parsed by bash and not by sh | 21:21 |
| Saviq | biab | 21:21 |
| veebers | Saviq: nice, will try that too. Just trying to upgrade to sort some issues out | 21:29 |
| veebers | Saviq, do you know if there is anything else I need to do to get unity logging when started with upstart on desktop? I'm trying to determine if/why it's having issues with QT_LOAD_TESTABILITY | 22:15 |
| Saviq | veebers, not logging for you in ~/.cache/upstart/unity8.log is it? | 22:16 |
| * veebers triple checks | 22:16 | |
| Saviq | veebers, indeed, it's quiet there | 22:18 |
| veebers | Saviq: thanks, I think I was checking ~/.config not ~/.cache :-\ oops | 22:18 |
| Saviq | veebers, ah no | 22:18 |
| Saviq | it just takes long to start | 22:18 |
| Saviq | stupid hud | 22:18 |
| veebers | Saviq: right, so I don't see "Loading testability driver." if I just use QT_LOAD_TESTABILITY, but I do if I add -testability to the args :-\ | 22:20 |
| * Saviq tries | 22:21 | |
| Saviq | veebers, indeed, interesting | 22:23 |
| Saviq | veebers, but if I just go "QT_LOAD_TESTABILITY=1 unity8" - it works | 22:23 |
| veebers | Saviq: but if you use set-env QT_LOAD_TESTABILITY=1 does that work? | 22:25 |
| Saviq | veebers, it's unset after set-env for some reason :S | 22:25 |
| veebers | Saviq: ugh, odd :-\ | 22:27 |
| veebers | Saviq: at the moment then I have an "if desktop: args.append('-testability')" | 22:27 |
| Saviq | veebers, yeah, but if set-env doesn't work - we'll have issues with the paths anyway | 22:28 |
| Saviq | veebers, had to pass -g | 22:29 |
| veebers | Saviq: its odd as the mocks seem to work (when running the test it has the "Alph release, not ready . . .") | 22:29 |
| * veebers tries | 22:29 | |
| Saviq | veebers, that's 'cause there is nothing not-mocked available | 22:29 |
| Saviq | veebers, on desktop | 22:29 |
| veebers | Saviq: oh, very good point | 22:31 |
| Saviq | veebers, I think we need -g indeed | 22:31 |
| veebers | Saviq: just tried and it works for me, adding now | 22:31 |
| Saviq | veebers, btw, there's reset-env | 22:31 |
| Saviq | veebers, although if we'd be overriding an existing value, it's probably better what you're doing | 22:32 |
| veebers | Saviq: when I tried that on Friday it browe everything for me, i.e. unity8 never connected to dbus after issuing that command, had to reboot etc. | 22:32 |
| veebers | Saviq: wasn't sure if that was expected (i.e. reset as in set eberything back to empty) or a bug | 22:32 |
| Saviq | veebers, I think expected, and anyway it would reset it to the "original" value | 22:33 |
| Saviq | as in the one that upstart was started with | 22:33 |
| Saviq | not the one that was there before we used set-env | 22:33 |
| Saviq | veebers, so.... because on the desktop we're running *in* an upstart job (unity7) - we need to use --global | 22:33 |
| veebers | Saviq: right, but I found it odd that if I used the command reset then unity8 wouldn't connect to dbus afterward at all | 22:34 |
| veebers | Saviq: ah ok makes sense, I've added that to the set-env calls | 22:34 |
| Saviq | veebers, on device / during otto we wouldn't need it, as the commands are ran outside of upstart jobs | 22:35 |
| Saviq | veebers, dbus env is set by dbus when it starts | 22:35 |
| Saviq | veebers, so if you reset it, unity8 wouldn't know it | 22:35 |
| veebers | Saviq: ah I see re: --global, would there be any issue using it on device anyway? | 22:36 |
| veebers | Saviq: oh, thank makes sense re: dbus, thanks for clarifying :-) | 22:36 |
| Saviq | veebers, I don't think there would | 22:36 |
| Saviq | veebers, it's actually implied | 22:36 |
| Saviq | veebers, when ran outside of a job | 22:36 |
| veebers | Saviq: cool, I'll use it regardless of desktop/device then :-) | 22:36 |
| Saviq | +1 | 22:36 |
| veebers | Saviq: I've just pushed the updated branch | 23:15 |
| veebers | Saviq: I think though that it still needs something handling OSK. It appears that trying to `stop unity8 while the OSK is up breaks things | 23:16 |
| veebers | unity and the osk is still on screen and unity's status is post-start, if I stop maliit-server it works again | 23:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!