| === chihchun_afk is now known as chihchun | ||
| RAOF | Damnit, mir_demo_client_eglplasma! Why can't you find the socket? | 05:49 |
|---|---|---|
| duflu | RAOF: Cos we moved it in the server but failed to update libmirclient, I think | 06:00 |
| duflu | I would have pointed that out if the MP didn't fly by and land without me noticing | 06:01 |
| duflu | RAOF: If that's right, can you log a bug? | 06:02 |
| RAOF | duflu: I don't think it's a new change. This *should* be all code that worked on another laptop. | 06:03 |
| * RAOF is not running this from trunk, but from nested-spike. | 06:03 | |
| duflu | Sounds pointy | 06:03 |
| tvoss_ | good morning :) | 06:26 |
| RAOF | Dear gdb: plz learn to C++. | 06:27 |
| RAOF | No love, Chris. | 06:27 |
| tvoss_ | RAOF, for printing values? | 06:30 |
| RAOF | tvoss_: Indeed. | 06:30 |
| * tvoss_ always forgets the package that adds pretty printing of stl containers | 06:30 | |
| RAOF | To gdb? | 06:31 |
| tvoss_ | RAOF, yup | 06:31 |
| duflu | tvoss_: When you remember, do tell | 06:32 |
| duflu | Cos I've tried dropping the STL from a great height and it just won't die. So being able to debug would be next best thing | 06:33 |
| RAOF | Hm. | 06:35 |
| RAOF | Looks like it might be in libstdc++-4.8-dbg? | 06:35 |
| tvoss_ | RAOF, just pinged doko | 06:36 |
| duflu | Surely pretty-printing is a generic template thing? Should be... | 06:36 |
| duflu | i.e. Not STL-specific | 06:36 |
| tvoss_ | duflu, it relies on python to do the pretty printing | 06:36 |
| duflu | Hah | 06:37 |
| tvoss_ | RAOF, that would be libstdc++6-4.8-dbg, correct? | 06:37 |
| RAOF | tvoss_: Yeah. Just trying to get it to actually work :) | 06:37 |
| tvoss_ | RAOF, likewise | 06:37 |
| RAOF | duflu: But you'd really really like STL-specific pretty printers, so that your std::map<foo, bar> doesn't expand to 200 characters of entirely impenetrable implementation details. | 06:38 |
| duflu | RAOF: No, I'd like pretty printing for any template. Not just the STL. Just like clang does | 06:38 |
| RAOF | I'd like that too. | 06:39 |
| RAOF | I'd like both less stupid template expansions, *and* std::map<int, string> = [{1, "one"}, {2, "two"}, …] | 06:39 |
| tvoss_ | RAOF, duflu this mail also helps: http://lists.kde.org/?l=kdevelop&m=125326438617051&w=2 | 06:41 |
| tvoss_ | although I would have thought that we have packaged that functionality, too | 06:42 |
| RAOF | tvoss_: I can only get python syntax errors out of that. :( | 06:43 |
| RAOF | Sadness ☹ | 06:43 |
| RAOF | tvoss_: Ah. The pretty printers aren't python3 code. | 06:46 |
| tvoss_ | ah | 06:46 |
| RAOF | And since gdb links to the 3.3 runtime... | 06:47 |
| tvoss_ | RAOF, now that's a bit annoying then | 06:47 |
| RAOF | tvoss_: Ah, but running 2to3 on it appears to work. | 06:50 |
| tvoss_ | RAOF, got a nice pastebin? | 06:50 |
| * tvoss_ wonders whether having pretty printers in our retracing-infrastructure would result in more easily readable stacktraces | 06:51 | |
| RAOF | tvoss_: sudo 2to3 --write /usr/share/gcc-4.8/python/libstdcxx/v6/printers.py | 06:51 |
| tvoss_ | RAOF, that's easy :) | 06:51 |
| tvoss_ | RAOF, I get http://paste.ubuntu.com/6234780/ | 06:56 |
| === chihchun is now known as chihchun_afk | ||
| RAOF | tvoss_: Oh, you do 2. from http://sourceware.org/gdb/wiki/STLSupport, but with /usr/share/gcc-4.8/python | 07:00 |
| tvoss_ | RAOF, nope, that's from libstdc++-4.8-dbg | 07:01 |
| RAOF | tvoss_: Yeah, but the python path is wrong (specifically, /usr/lib/debug/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18-gdb.py appears to not add the sys path correctly) | 07:03 |
| RAOF | Hm. Do we build without rtti? The pretty-printer is an ugly-printer without it :) | 07:04 |
| tvoss_ | RAOF, nope, we never disabled rtti | 07:05 |
| === chihchun_afk is now known as chihchun | ||
| RAOF | Sayeth the pretty-printer: std::shared_ptr (count 2, weak 0) 0x60dbd8, surface_map = warning: RTTI symbol not found for class 'std::_Sp_counted_ptr_inplace<mir::client::ConnectionSurfaceMap, std::allocator<mir::client::ConnectionSurfaceMap>, (__gnu_cxx::_Lock_policy)2>' | 07:06 |
| om26er | duflu, re: bug 1227739 I assume that work will go in after 13.10 release ? | 07:08 |
| ubot5 | bug 1227739 in Mir "Mir continues to render background application surfaces even when they're not visible" [High,In progress] https://launchpad.net/bugs/1227739 | 07:08 |
| duflu | om26er: Unclear. I'm told the current work is exceptional to the freeze. But really I can't even get the prereq branches landed yet | 07:09 |
| duflu | ... everyone's too busy to review them one way or the other | 07:10 |
| tvoss_ | RAOF, https://sourceware.org/bugzilla/show_bug.cgi?id=14235 | 07:10 |
| ubot5 | sourceware.org bug 14235 in python "verbose RTTI message polluting traces" [Normal,New] | 07:10 |
| om26er | duflu, right. there is still work in unity-mir needed after your branches get merged? | 07:11 |
| om26er | or any other component | 07:11 |
| duflu | om26er: Yeah, *maybe*. Would be unpredictable as to whether the fix works otherwise. | 07:11 |
| duflu | The unity-mir fix is trivial. I'm just not familiar with building/testing that project | 07:12 |
| duflu | Umm, I mean platform-api? | 07:12 |
| Saviq | hey folks, is anyone looking at https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1238107 - it's the most visible hang/crash at the moment for me - since it happens almost every time you stop unity8 | 07:16 |
| ubot5 | Ubuntu bug 1238107 in maliit-framework (Ubuntu) "maliit-server crashed with SIGSEGV in __GI___pthread_mutex_lock()" [Medium,Confirmed] | 07:16 |
| tvoss_ | Saviq, alf_ was looking into a similar issue | 07:17 |
| alf_ | Saviq: I was planning to look into at after updating the phone | 07:18 |
| alf_ | s/at/it/ | 07:18 |
| Saviq | alf_, great thanks, let me know if you need help! | 07:18 |
| alf_ | Saviq: will do | 07:18 |
| alf_ | Saviq: so, just 'stop unity8' to reproduce? | 07:19 |
| jibel | I got a webbrowser crash with the same trace on build 95 this morning bug 1239522 | 07:19 |
| ubot5 | bug 1239522 in webbrowser-app (Ubuntu) "webbrowser-app crashed with SIGSEGV in __GI___pthread_mutex_lock()" [Medium,New] https://launchpad.net/bugs/1239522 | 07:19 |
| Saviq | alf_, yeah | 07:20 |
| Saviq | jibel, yeah, it's something in mirclient most probably | 07:20 |
| alf_ | jibel: @1239522, is the webbrowser-app reproducible consistently? | 07:20 |
| alf_ | jibel: the crash I mean | 07:20 |
| jibel | alf_, no, I was trying all the apps to verify none of them was completely trashed. I'm searching a way to reproduce. | 07:21 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| Saviq | duflu, re: bug #1238107 I believe alf_ said bug #1233988 was slightly different | 07:41 |
| ubot5 | bug 1233988 in maliit-framework (Ubuntu) "duplicate for #1238107 With Mir enabled: platform-api apps crash with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Fix committed] https://launchpad.net/bugs/1233988 | 07:41 |
| ubot5 | bug 1233988 in maliit-framework (Ubuntu) "With Mir enabled: platform-api apps crash with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Fix committed] https://launchpad.net/bugs/1233988 | 07:41 |
| Saviq | actually | 07:41 |
| * Saviq builds platform-api | 07:41 | |
| alf_ | Saviq: ah, so the fix for 1233988 is not yet in? | 07:42 |
| duflu | Saviq: I'm not convinced. But I'm also not convinced we fixed it properly first time. We should at least get to the stage where the known fixes are released, then re-assess if there's still a problem | 07:42 |
| Saviq | alf_, it's Fix committed everywhere | 07:42 |
| Saviq | duflu, +1 | 07:42 |
| alf_ | Saviq: but not released... | 07:42 |
| Saviq | alf_, yup | 07:42 |
| duflu | alf_: I assume you verified the platform-api was smart enough to at least check for connect failure? | 07:43 |
| duflu | .. i.e. returning false is not in vain | 07:43 |
| Saviq | alf_, actually it's released in platform-api https://code.launchpad.net/~phablet-team/platform-api/trunk | 07:45 |
| alf_ | duflu: Saviq: yes, it fails an assertion... but now that I think about it, I think I tried it in debug mode, not sure if the assertion is fired in the package version too | 07:45 |
| Saviq | on Thursday | 07:45 |
| duflu | Right, but the bug may still exist. Only as an error now rather than a crash | 07:46 |
| duflu | Although platform-api could still be abusing libmirclient and cause it to crash elsewhere | 07:47 |
| duflu | Perhaps we should strengthen libmirclient so it doesn't get blamed for bad parms... | 07:47 |
| Saviq | alf_, duflu, I'm still getting that crash reliably in maliit-server when stopping unity8 | 07:47 |
| alf_ | Saviq: what about 1233988 ? | 07:47 |
| Saviq | somewhat reliably at least | 07:47 |
| Saviq | bug #1233988 | 07:47 |
| ubot5 | bug 1233988 in maliit-framework (Ubuntu) "With Mir enabled: platform-api apps crash with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Fix committed] https://launchpad.net/bugs/1233988 | 07:47 |
| Saviq | alf_, I never knew how to reproduce it... the trace seems exactly the same.. | 07:48 |
| duflu | Saviq: I'm not confident the fixes so far are sufficient so maybe just reopen instead of duplicating in new bugs | 07:48 |
| Saviq | duflu, sure - your call | 07:48 |
| alf_ | duflu: Let me investigate a bit further today, and I will merge as needed | 07:48 |
| duflu | Saviq: Most importantly I just want to prevent people from working on duplicates. They're unaware of duplicating effort etc | 07:50 |
| Saviq | duflu, I understand | 07:50 |
| Saviq | duflu, works for me | 07:50 |
| duflu | alf_: Should we be looking up valid_connections for all libmirclient API calls? | 07:50 |
| duflu | Probably wouldn't hurt | 07:51 |
| duflu | And it would stop crash reports from landing in Mir | 07:51 |
| duflu | Hmm, actually it wouldn't. But it would allow us to instantly say "not a Mir bug" | 07:52 |
| Saviq | duflu, alf_ I still get the maliit-crash on reboot | 07:59 |
| Saviq | so sounds like not fixed indeed | 07:59 |
| duflu | Saviq: No problem, just reopen | 07:59 |
| alf_ | Saviq: at least my part of the fix was not about not getting a crash, but getting a better crash (and not in Mir ;)) | 08:00 |
| Saviq | alf_, ok ;) | 08:00 |
| Saviq | alf_, http://pastebin.ubuntu.com/6234953/ | 08:01 |
| alf_ | Saviq: so is this with the default platform-api package, or something you built? | 08:02 |
| Saviq | alf_, default papi, my mir trunk + https://code.launchpad.net/~kdub/mir/android-buffer-syncfence/+merge/189717 | 08:02 |
| Saviq | alf_, can downgrade mir if you think it matters | 08:02 |
| alf_ | Saviq: Can you try with a custom built platform-api? Just the package version but with -DCMAKE_BUILD_TYPE=Debug, to ensure the assertion for invalid connections is actually compiled in. | 08:04 |
| Saviq | alf_, will do | 08:05 |
| alf_ | Saviq: hmm, just a moment to check something | 08:06 |
| Saviq | alf_, holding | 08:07 |
| alf_ | Saviq: ok, please continue :) You may want to add a debug message for 'connect_suceeded' in u_application_instance_new_from_description_with_options src/ubuntu/mirclient/ubuntu_application_api_mirclient.cpp (that's where the assertion should fire, but no harm in having an extra message there) | 08:11 |
| duflu | alf_: One of the duplicates today clearly showed MirConnection's this==NULL | 08:12 |
| alf_ | duflu: ok, so the problem probably is that platform-api should handle connection failures better. I wonder... is u_application_instance_new_from_description_with_options supposed to return NULL if the call fails? | 08:14 |
| alf_ | tvoss_: ^^ ? | 08:14 |
| alf_ | right now it just asserts | 08:14 |
| tvoss_ | alf_, yes, returning null would be correct | 08:15 |
| tvoss_ | alf_, admittedly, error handling should be better, but right now, NULL indicates error | 08:15 |
| duflu | I think we need to protect libmirclient from false accusations and error-check the connection parameters | 08:15 |
| alf_ | duflu: +1 | 08:20 |
| tvoss_ | alan_g, ping | 08:48 |
| alan_g | tvoss_: hi | 08:48 |
| tvoss_ | alan_g, hey there, can I ask you to review https://code.launchpad.net/~kdub/mir/android-buffer-syncfence | 08:49 |
| alan_g | tvoss_: it is on my list | 08:49 |
| tvoss_ | alan_g, ack, we would like to land the mp asap, so would be great if you could bump priority | 08:49 |
| alan_g | tvoss_: OK. Do you know the best place to ask about network problems? (I'm a bit distracted by: my desktop stopped connecting to wired or wireless after I crashed X on Friday. Even installing a fresh image didn't fix - even though it works fine off the memory stick image) | 08:52 |
| tvoss_ | alan_g, #ubuntu-desktop | 08:52 |
| alan_g | tvoss_: ta | 08:53 |
| * duflu sees clipping bugs on iOS 7 and feels better about life | 08:59 | |
| alf_ | duflu: :) | 09:00 |
| duflu | It's kind of nice generally that Apple has lowered the bar/standard for UIs :) | 09:01 |
| alan_g | My wire dislikes iOS7 nearly as much as Windows8 | 09:06 |
| duflu | -r +f? | 09:06 |
| duflu | I'm not convinced Win8 was a step backwards compared to Win7. But Apple have killed a large chunk of their distinctiveness and competitive advantage with iOS7. And that's good for Ubuntu. | 09:09 |
| alan_g | duflu: she's comparing Win8 with WinXP (but IMO win8 introduced a lot of silly traps for the user - e.g. two independent IE installs) | 09:21 |
| duflu | To Microsoft's credit, at least with Win8 you generally don't need to install drivers any more. And the compositing feels nice and smooth | 09:22 |
| duflu | alan_g: I've got to run, but would you be able to check this out and see why it's hanging in integration-tests?... | 10:11 |
| duflu | lp:~mir-team/mir/verify-MirConnection | 10:11 |
| alan_g | duflu: Sure, I'll have a look later | 10:12 |
| alf_ | Saviq: https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-more/+merge/190908 and | 10:12 |
| alf_ | Saviq: https://code.launchpad.net/~afrantzis/qtubuntu/fix-1233988-more/+merge/190907 | 10:12 |
| duflu | alan_g: Cool, ta | 10:12 |
| Saviq | alf_, cool! | 10:13 |
| Saviq | alf_, will test asap | 10:14 |
| alf_ | Saviq: note: this is not a fix of why maliit-server can't connect to the mir server, but at least now you should be getting a clear FATAL message from Qt (which is what the xcb backend does when it fails to connect) | 10:14 |
| Saviq | alf_, so a better message at least | 10:15 |
| Saviq | alf_, and no crash | 10:15 |
| Saviq | alf_, well, I *know* why it can't connect - it's being shut down :) | 10:15 |
| alf_ | Saviq: There will be a crash == qFatal() == abort(). But we can change this to just print a message and exit cleanly... although the right solution here is to find why maliit is trying to connect to a server that is shutting down. | 10:16 |
| Saviq | alf_, indeed | 10:17 |
| === chihchun is now known as chihchun_afk | ||
| alf_ | Saviq: the problem is that I can't reproduce the maliit crash with 'stop unity8'. Of course, the maliit crash is very easy to recreate in general: just run maliit-server manually after 'stop unity8'. | 10:28 |
| alf_ | Saviq: some kind of race perhaps? How does upstart now when unity8 has started, so it can start maliit-server? | 10:29 |
| Saviq | alf_, they stop "in concert" and indeed it's not 100% reproducible | 10:29 |
| Saviq | alf_, but you can run the unity8 ap tests suite - should get you some .crash files | 10:29 |
| alf_ | Saviq: In upstart unity8.conf, we call 'exec unity8'. How does upstart know when unity8 has *really* started (i.e. it's ready to accept client connections?), so it can start maliit-server (maliit-server.conf: 'start on started unity8')? | 10:36 |
| Saviq | ogra_, ↑ can you shed some light there? | 10:36 |
| ogra_ | it waits until the PID it got returns something ... | 10:37 |
| ogra_ | Saviq, alf_ http://upstart.ubuntu.com/cookbook/#expect | 10:39 |
| alf_ | ogra_: thanks | 10:40 |
| alf_ | Saviq: "If your daemon has a "don't daemonize" or "run in the foreground" mode, then it's much simpler to use that and not run with fork following. One issue with that though, is that Upstart will emit the started JOB=yourjob event as soon as it has executed your daemon, which may be before it has had time to listen for incoming connections or fully initialize." | 10:40 |
| Saviq | alf_, yeah, I know | 10:40 |
| alf_ | Saviq: does unity8 daemonize? | 10:41 |
| Saviq | alf_, nope | 10:41 |
| ogra_ | so tracking the first PID should be fine then | 10:41 |
| ogra_ | (i.e no need to set "exepect") | 10:42 |
| alf_ | ogra_: yes, but we fall into the "Upstart will emit the started JOB=yourjob event as soon as it has executed your daemon, which may be before it has had time to listen for incoming connections or fully initialize." case | 10:42 |
| ogra_ | (except if you fork more than once) | 10:42 |
| ogra_ | i know slangesek is on a querst to look through all ubuntu touch upstart session jobs, you probably want to wait for his input | 10:45 |
| ogra_ | *quest | 10:45 |
| ogra_ | is teher a sprecific socket or file maliit should wait for ? | 10:45 |
| ogra_ | upstart has ways to make it do that | 10:46 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | (you could drop "on started unity8" and make it ie "start on created socket file") | 10:46 |
| ogra_ | (and stop on removed ...) | 10:47 |
| Saviq | alf_, arguably, since mir clients are not supposed to die when mir dies, shouldn't it also just wait for it to be ready and reconnect? | 11:14 |
| alan_g | Saviq: alf_ we're a long way from that scenario working. (I'm currently fixing a client-side hang in the API when the server dies) | 11:19 |
| Saviq | alan_g, got it | 11:19 |
| tvoss_ | alan_g, for kdub's branch: could you give it a more detailed review before kdub fixes the tests? | 11:32 |
| alan_g | tvoss_: that was my plan | 11:34 |
| === hikiko is now known as hikiko|lunch | ||
| tvoss_ | alan_g, thx, would help a lot | 11:34 |
| Saviq | tvoss_, btw, https://bugs.launchpad.net/unity8/+bug/1238645 is apparently valid for mir/qtubuntu/somewhere | 11:38 |
| ubot5 | Ubuntu bug 1238645 in Unity 8 "Shell does not get autopilot keyboard input if maliit isn't running" [Undecided,In progress] | 11:38 |
| tvoss_ | Saviq, looking | 11:39 |
| Saviq | tvoss_, and I think we're seeing the result of it https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-maguro/2412/?#showFailuresLink | 11:39 |
| Saviq | even with the workaround that we have | 11:39 |
| Saviq | or workaround--, but upstart++ starting maliit-server for us | 11:39 |
| tvoss_ | hmmm, so key events are sent via uinput? | 11:40 |
| ogra_ | just add an env var check to maliits upstart job | 11:42 |
| ogra_ | make it a no-op if the var is set ... export it from AP | 11:43 |
| tvoss_ | Saviq, what ogra_ said ^? | 11:46 |
| Saviq | tvoss_, yes they are | 11:46 |
| Saviq | ogra_, it's not about maliit not being started | 11:46 |
| Saviq | ogra_, it should be unrelated | 11:46 |
| ogra_ | ah, k | 11:46 |
| ogra_ | i thought maliit blocks uinput | 11:46 |
| tvoss_ | ogra_, that's actually an interesting idea. Saviq, didn't we see the permissions on /dev/uinput change recently? | 11:48 |
| Saviq | tvoss_, well, yeah, it changes to "bluetooth" for me | 11:49 |
| Saviq | tvoss_, but works regardless of that | 11:49 |
| Saviq | i.e. perms no perms, if maliit is working - input is delivered (generally - as we can see there are still failures) - if not - no | 11:50 |
| tvoss_ | Saviq, ack, looking into it | 11:53 |
| === tvoss_ is now known as tvoss|dentist | ||
| ogra_ | root@ubuntu-phablet:/# grep uinput /lib/udev/rules.d/* | 12:00 |
| ogra_ | /lib/udev/rules.d/61-autopilot-uinput.rules:# Creates autopilot group specific access to /dev/uinput | 12:00 |
| ogra_ | /lib/udev/rules.d/61-autopilot-uinput.rules:KERNEL=="uinput", SUBSYSTEM=="misc", SYMLINK="autopilot-uinput", GROUP="autopilot", MODE="0660" | 12:00 |
| ogra_ | /lib/udev/rules.d/70-android.rules:ACTION=="add", KERNEL=="uinput", OWNER="system", GROUP="bluetooth", MODE="0660" | 12:00 |
| ogra_ | Saviq, tvoss|dentist ^^^ | 12:01 |
| ogra_ | i guess we should drop it from the android rules :) | 12:01 |
| ogra_ | (and if GROUP=autopilot is wrong adjust thios too) | 12:02 |
| === hikiko|lunch is now known as hikiko | ||
| === jhodapp|afk is now known as jhodapp | ||
| === alan_g is now known as alan_g|lunch | ||
| alf_ | Saviq: I wonder if what's happening with maliit etc is that the server crashes, maliit aborts, it's respawn and then fails to connect to the non-existent mir server. | 12:53 |
| alf_ | Saviq: because, all the backtraces we have for this issue point to this happening during application (Qt platform) setup | 12:57 |
| alf_ | Saviq: in any case, the new MPs for platform-api and qtubuntu should make this clearer | 12:58 |
| === tvoss|dentist is now known as tvoss | ||
| === alan_g|lunch is now known as alan_g | ||
| Saviq | alf_, might be indeed, am building them now | 13:09 |
| === chihchun is now known as chihchun_afk | ||
| alf_ | Saviq: Unfortunately, I am not able to get maliit to crash with 'stop unity8' (tried about 20 times now). I do get https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1238116 all the time though... | 13:11 |
| ubot5 | Ubuntu bug 1238116 in unity8 (Ubuntu) "unity8 crashed with SIGSEGV in QIcon::~QIcon()" [Medium,Confirmed] | 13:11 |
| Saviq | alf_, right, that one's solved with https://code.launchpad.net/~aacid/unity-mir/waitforme/+merge/190716 | 13:12 |
| Saviq | alf_, and it uncovered a few other bugs now indeed | 13:13 |
| Saviq | alf_, since we're destroying stuff proper now | 13:13 |
| Saviq | alf_, I'm just building qtubuntu now and will let you know of what changed asap | 13:14 |
| alf_ | Saviq: thanks (note you need both the MPs to see the effect) | 13:15 |
| Saviq | alf_, yup, papi already built | 13:15 |
| tvoss | Saviq, I do see events getting into mir with autopilot and maliit not running | 13:25 |
| Saviq | tvoss, yeah, we need to track them up the stack | 13:26 |
| jibel | greyback, I added a video to bug 1234538 | 13:27 |
| ubot5 | bug 1234538 in unity8 (Ubuntu) "With Mir enabled - Applications randomly failed to start" [High,Confirmed] https://launchpad.net/bugs/1234538 | 13:27 |
| tvoss | Saviq, I have a gut feeling that maliit goes away and the focus chain in unity is not correctly restored or something | 13:27 |
| greyback | jibel: thanks. That video I guess with a recent image? | 13:28 |
| jibel | greyback, 96 | 13:28 |
| greyback | jibel: perfect, thanks. Will look | 13:28 |
| Saviq | tvoss, if maliit is stopped *before* unity8 starts | 13:28 |
| Saviq | tvoss, it doesn't work either | 13:29 |
| tvoss | Saviq, hmmm ... which would then mean, that qt/qml somewhere checks if an input-method is available | 13:29 |
| greyback | jibel: last question: that a galaxy nexus or nexus4? | 13:35 |
| jibel | greyback, mako/nexus4 | 13:35 |
| greyback | jibel: Ok, I'll try it there. | 13:36 |
| greyback | mzanetti: that one new to me, thanks for that | 13:39 |
| greyback | mzanetti: is it logged? I can't find it? | 13:40 |
| mzanetti | greyback: noticed when developing the Ubuntu Authenticator on the weekend | 13:40 |
| mzanetti | greyback: no, didn't report it yet | 13:40 |
| mzanetti | greyback: it doesn't really hit users, but it | 13:40 |
| mzanetti | is annoying for app developers | 13:40 |
| greyback | mzanetti: every fix is a good fix | 13:40 |
| davmor2 | mzanetti: what issue is that? | 13:42 |
| mzanetti | davmor2: run an app from the command line, lock the screen, press ctrl+c to stop the app, unlock the screen -> Boom! | 13:42 |
| tvoss | Saviq, got it | 13:43 |
| Saviq | alf_, so yeah, "FATAL: QUbuntu: Could not create application instance", but still getting crashes | 13:47 |
| Saviq | alf_, and/or unity8 locking up | 13:47 |
| Saviq | collecting .crashes now | 13:47 |
| alf_ | Saviq: ok, so if the hypothesis is correct, the "FATAL: QUbuntu: Could not create application instance" should be from the second (respawned) run of maliit-server. Can we verify this, e.g., by getting the stack trace of the first run if it crashed, or some kind of upstart log? | 13:50 |
| Saviq | alf_, I can get you both, yeah | 13:51 |
| Saviq | alf_, I can also get you packages I'm seeing that in, if you want them | 13:51 |
| alf_ | Saviq: yes, a cross check with what I have would be good, since I can't get the crash... | 13:52 |
| Saviq | alf_, so... http://people.canonical.com/~msawicz/repo.tar.gz - still uploading | 13:58 |
| Saviq | alf_, that is: | 13:58 |
| Saviq | mir + https://code.launchpad.net/~kdub/mir/android-buffer-syncfence/+merge/189717 | 13:58 |
| Saviq | platform-api + https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-more/+merge/190908 | 13:59 |
| Saviq | qtubuntu + https://code.launchpad.net/~afrantzis/qtubuntu/fix-1233988-more/+merge/190907 | 13:59 |
| Saviq | unity8 + https://code.launchpad.net/~unity-team/unity8/ap_launch_unity_with_upstart/+merge/190886 | 13:59 |
| Saviq | session-manager-touch + https://code.launchpad.net/~saviq/session-manager-touch/drop-unity8 | 14:00 |
| === dandrader is now known as dandrader|afk | ||
| Saviq | Friday's unity-api + https://code.launchpad.net/~aacid/unity-mir/waitforme/+merge/190716 | 14:00 |
| Saviq | alf_, you can just add it as a repo in sources.list and upgrade from it | 14:00 |
| Saviq | alf_, you can disregard unity8 and session updates, though | 14:01 |
| Saviq | alf_, will ping you when it uploads | 14:01 |
| Saviq | alf_, https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1239712 here is the current trace | 14:05 |
| ubot5 | Ubuntu bug 1239712 in maliit-framework (Ubuntu) "maliit-server crashed with SIGABRT in raise()" [Undecided,New] | 14:05 |
| Saviq | alf_, uploaded | 14:11 |
| mlankhorst | hm | 14:12 |
| mlankhorst | I think I understand the gbm fail | 14:12 |
| mlankhorst | this makes it a bit harder though | 14:14 |
| === dandrader|afk is now known as dandrader | ||
| alf_ | mlankhorst: what's the cause for the gbm fail? | 14:25 |
| mlankhorst | the gbm piping expects a gbm surface type | 14:27 |
| mlankhorst | but I think it can be workarounded.. | 14:28 |
| mlankhorst | hold on | 14:29 |
| mlankhorst | in particular the createNewDrawable call, I'm writing a workaround atm.. | 14:31 |
| === alan_g is now known as alan_g|lunch | ||
| mlankhorst | well that was easy | 14:39 |
| mlankhorst | now both work | 14:39 |
| mlankhorst | http://paste.debian.net/57430/ gg hf kthxbye | 14:40 |
| mlankhorst | the #if 0 code can be removed or kept, it works either way | 14:41 |
| mlankhorst | alf_/RAOF: ^ | 14:42 |
| alf_ | mlankhorst: \o/, so this fixes the nested mir case totally? | 14:43 |
| === alan_g|lunch is now known as alan_g | ||
| mlankhorst | it fixed eglflash unnested for me, so I would assume so | 14:46 |
| alf_ | mlankhorst: awesome, I will try when the phone drops in priority, probably near EOW | 14:48 |
| mlankhorst | the code inside #if 0 was the former default, the #if 0 simply allowed me to test any client without starting nested mir | 14:50 |
| alf_ | mlankhorst: is the diff against egl-platform-mir-egl-image-i965-experiment ? | 14:50 |
| mlankhorst | hm no it's a diff against my previous diff :P | 14:54 |
| mlankhorst | I think I had some changes on top | 14:54 |
| mlankhorst | alf_: yeah, apply this one first http://paste.debian.net/57441/ | 14:56 |
| alf_ | Saviq: with your packages what I am seeing is that the maliit-server crash is happening when starting up 'start unity8' not when stopping, reinforcing that maliit tries to connect too soon, fails/aborts, gets respawned and manages to connect | 15:01 |
| alf_ | Saviq: can you verify that you get a maliit crash after 'start unity8' and not after 'stop unity8'? | 15:01 |
| Saviq | alf_, trying | 15:03 |
| Saviq | alf_, it'd make sense indeed | 15:03 |
| tvoss | kdub, hey there :) | 15:09 |
| kdub | hello tvoss | 15:09 |
| tvoss | kdub, so you are the most wanted person today :) | 15:10 |
| tvoss | kdub, would be great if you could jump on fixing the test failures on https://code.launchpad.net/~kdub/mir/android-buffer-syncfence | 15:12 |
| tvoss | kdub, if that is fixed, we could land the branch | 15:13 |
| kdub | yep, #1 on the list for today | 15:13 |
| tvoss | kdub, cool | 15:13 |
| tvoss | kdub, let me know if I can help | 15:13 |
| Saviq | alf_, confirmed | 15:18 |
| Saviq | alf_, /me adds "sleep 2" to maliit job... | 15:18 |
| Saviq | damn | 15:19 |
| Saviq | alf_, yeah, confirmed | 15:19 |
| Saviq | alf_, could we not SIGABRT when can't connect to server? | 15:19 |
| Saviq | ogra_, can we add "sleep 2" to maliit-server before starting? | 15:19 |
| ogra_ | ergh, why is that | 15:19 |
| ogra_ | that adds 2 secs to the session startup, can you solve it in any other way ? | 15:21 |
| ogra_ | (i just spent two weeks to get the boot below 30sec again) | 15:21 |
| Saviq | ogra_, maliit starts too early | 15:22 |
| Saviq | ogra_, Mir in unity8 isn't yet ready | 15:23 |
| ogra_ | Saviq, then fix unity to not tell upstart it is started when it is notz | 15:23 |
| Saviq | ogra_, how? | 15:23 |
| ogra_ | make it wait ? dunno | 15:23 |
| ogra_ | did you try different expect lines for the upstart job (and did you check the double fork stuff etc as explained in the upstart cookbook) | 15:24 |
| Saviq | ogra_, nope | 15:24 |
| Saviq | ogra_, we're not forking at all, though | 15:24 |
| Saviq | ogra_, we're not daemonizing | 15:24 |
| Saviq | ogra_, but will look through upstart cbook | 15:25 |
| ogra_ | please ask slangasek how to do it right then | 15:25 |
| ogra_ | i think he can help here | 15:25 |
| ogra_ | (or if slangasek isnt around, probably xnox or stgraber can help they are both upstart aces :) ) | 15:26 |
| ogra_ | (or even jodh as upstart upstream) | 15:26 |
| xnox | hm? | 15:26 |
| ogra_ | xnox, the unity8 upstart job seems to return before unity8 is actualyl ready ... causing dependent jobs to start to early | 15:27 |
| xnox | ogra_: invoke tedg =) unity8 should emit started unity8, until ready =) | 15:27 |
| xnox | ogra_: if there is a dbus known-name that unity8 exports, jobs can start on started that. | 15:27 |
| xnox | ogra_: thanks to the dbus bridge. | 15:27 |
| tedg | Or we could ask unity8 to emit sigstop when ready and have the job wait on that. | 15:28 |
| tedg | I believe upstart has a mode for that. | 15:28 |
| ogra_ | well, any kind of landmark will do i guess | 15:28 |
| tvoss | xnox, would initctl emit --no-wait unity8_ready (in unity) with a corresponding start on unity8_ready in maliit upstart conf work? | 15:28 |
| tvoss | Saviq, ^ | 15:28 |
| ogra_ | i'm just opposed to add sleeps back into upstart jobs | 15:28 |
| tedg | Yup, here it is: http://upstart.ubuntu.com/cookbook/#expect-stop | 15:29 |
| xnox | tvoss: sure, but also ugly. And please add "emits unity8_ready" in the unity8.conf, for documentation purposes to know which job is expected to emit that event. | 15:29 |
| xnox | tvoss: tedg: expect stop is far better. | 15:29 |
| ogra_ | tvoss, seriously, unity8 should just DTRT :) | 15:30 |
| tvoss | ogra_, we are trying to find out what the right thing is :) | 15:30 |
| ogra_ | before we write 100 line upstart jobs | 15:30 |
| tvoss | ogra_, *you* might know, but simple question: how does a process signal "I'm ready" back to upstart? | 15:30 |
| tedg | tvoss, There seems to be three idioms used here: 1) be fast, 2) sigstop, 3) fork but not until you're ready | 15:30 |
| ogra_ | right | 15:31 |
| tvoss | tedg, why not emit an expicit signal? sounds like the best solution in an event-based job control system? ;) | 15:32 |
| tvoss | tedg, s/signal/event | 15:32 |
| ogra_ | tvoss, thats the sigstop ... | 15:32 |
| tvoss | ogra_, yeah, I meant event then | 15:33 |
| tedg | tvoss, I think it depends on the case, if it's just "when it starts" there's no reason to have anything other than the "started" signal, and we should make that better. | 15:33 |
| ogra_ | from where ? | 15:33 |
| tedg | tvoss, For indicators I added one, and my logic there was that Unity8 may start and do other stuff before it wants the indicator services. | 15:33 |
| tvoss | ogra_, from unity8, just calling "initctl emit --no-wait unity8_ready" | 15:33 |
| tvoss | whenever that is the case | 15:33 |
| ogra_ | ugh | 15:33 |
| tedg | tvoss, Then what would people use the "started unity8" event for? It seems like we'd be wasting that one. | 15:34 |
| ogra_ | just make your binary DTRT ... if there is no expect mode for your binary behavior, ask jodh to add one | 15:34 |
| ogra_ | tvoss, i think tedg's sigstop suggestion is the best we can do as a quick solution | 15:35 |
| Saviq | sounds clean enough, yeah | 15:35 |
| tvoss | Saviq, if you are happy, I'm too | 15:37 |
| * Saviq wonders when to emit it ;D | 15:37 | |
| tvoss | Saviq, whenever qtguiapplication is constructed I would think | 15:38 |
| kdub | alan_g, alf_, pushed fixes for the unit tests... they were just test problems, no code change | 15:39 |
| alf_ | kdub: ok | 15:39 |
| tedg | tvoss, Throw in an idle event, then the first time you hit the mainloop without events... | 15:40 |
| Saviq | tvoss, don't we need to spin the loop? | 15:40 |
| alan_g | kdub: @ServerShutdown/OnSignal.* - can you confirm that test works fine when run on its own? (I've seen similar problems on the desktop - https://code.launchpad.net/~alan-griffiths/mir/fix-client-hang-on-server-death/+merge/190935/comments/438530) | 15:41 |
| kdub | testing... one minute | 15:41 |
| tvoss | Saviq, not sure ... | 15:42 |
| kdub | alan_g, yes, with running the test on its own, I see it pass in 2-3 seconds, when ran with the group, it appears to hang | 15:43 |
| alan_g | kdub: thanks (I'm trying to track down the interaction - at least this should require the same fix) | 15:44 |
| tvoss | ogra_, can upstart check if a file exists? | 15:51 |
| ogra_ | tvoss, yes, with the file bridge | 15:52 |
| ogra_ | (as long as it is a regular file) | 15:52 |
| tvoss | ogra_, yup, we just need to check if we are running on mir | 15:52 |
| Saviq | ogra_, can we check if file && socket exist? | 15:53 |
| ogra_ | Saviq, socket is tricky | 15:53 |
| ogra_ | file is easy | 15:53 |
| Saviq | ogra_, basically, if [ -e ~/.display-mir ] wait_for(/run/user/32011/mir_socket) | 15:53 |
| ogra_ | Saviq, and on my tablet where i have two users ? :) | 15:54 |
| tvoss | ogra_, I don't think that's a valid use-case right now | 15:54 |
| ogra_ | tvoss, Saviq is adding the SIGSTOP in the code right after the file creation not an option ? | 15:54 |
| tvoss | ogra_, I think Saviq is looking for a way to live without the sigstop for now | 15:55 |
| ogra_ | :( | 15:55 |
| Saviq | no I'm not | 15:57 |
| Saviq | I'm just looking for a good way to do it | 15:57 |
| Saviq | and asking *when* to safely emit the sigstop | 15:57 |
| Saviq | I'm fine with emitting it wherever - but someone knowing Mir needs to tell me when is it safe already | 15:58 |
| alf_ | tvoss: Saviq: (async ping for a review of https://code.launchpad.net/~afrantzis/qtubuntu/fix-1233988-more/+merge/190907 and https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-more/+merge/190908) | 15:58 |
| Saviq | alf_, is this ping cancellable? | 15:58 |
| Saviq | alf_, you got a +1 from me 30s ago :) | 15:58 |
| alf_ | Saviq: the .wait() will just return immediately, no need to cancel :) | 15:59 |
| Saviq | :) | 16:00 |
| tvoss | alan_g, alf_ do we signal back to mir if the communicator is ready to take connections? | 16:02 |
| tvoss | alf_, approved and top-approved | 16:02 |
| alan_g | tvoss: Who is this "mir" you refer to | 16:03 |
| tvoss | alan_g, the "rest" of the system, and the shell sitting on top | 16:03 |
| alan_g | tvoss: the connector is ready as soon as "start()" returns - what other signal do you want? | 16:05 |
| tvoss | alan_g, ack. Saviq, would that help? | 16:05 |
| * Saviq looks | 16:06 | |
| Saviq | greyback, help | 16:08 |
| greyback | Saviq: whassup? | 16:08 |
| Saviq | greyback, in unity-mir, are we calling start() anywhere explicitly? | 16:08 |
| alan_g | tvoss: Saviq connector->start() is called in DisplayServer::run() before main_loop->run() | 16:08 |
| greyback | Saviq: no | 16:08 |
| Saviq | greyback, we're trying to find a place to emit a SIGSTOP for upstart to know we're ready | 16:09 |
| Saviq | to accept client connections | 16:09 |
| Saviq | greyback, any ideas where to put it? | 16:10 |
| greyback | run_mir ? | 16:10 |
| Saviq | greyback, and that is called where? | 16:11 |
| greyback | Saviq: called by unity-mir, in QMirServer::runWithClient | 16:12 |
| Saviq | greyback, mhm, so basically just before returning from main()_ | 16:12 |
| greyback | Saviq: yeah. That too late? | 16:12 |
| Saviq | greyback, no, not unless it's unity-mir that emits the SIGSTOP | 16:13 |
| Saviq | greyback, since we can't do it in unity8's main, as we're looping there | 16:13 |
| greyback | Saviq: it /could/ | 16:13 |
| greyback | but seems to be something that Mir should do, no? | 16:13 |
| ogra_ | greyback, mir isnt started by upstart | 16:14 |
| Saviq | ogra_, it is ;) unity8 == mir | 16:14 |
| Saviq | greyback, we'd need it for sflinger, too | 16:14 |
| ogra_ | greyback, the prob we try to solve is that upstart needs to know when unity is ready to only then start all the depending jobs | 16:14 |
| greyback | ogra_: yep, that's understood. I'm trying to decide if it's Mir's job to send that signal, or instead the user of Mir (i.e. unity8) does it | 16:15 |
| Saviq | greor well | 16:15 |
| Saviq | greyback, that means we should be able to emit it in startShell, no? | 16:15 |
| greyback | Saviq: yes | 16:16 |
| Saviq | greyback, since by that time mir will be running already | 16:16 |
| Saviq | orks | 16:16 |
| greyback | yep, that'll work | 16:16 |
| greyback | and yeah, I'm fine with that | 16:16 |
| ogra_ | greyback, the PID that upstart fired up needs to return the info | 16:16 |
| Saviq | ogra_, it's the same PID | 16:16 |
| Saviq | ogra_, there is no separate process for Mir | 16:17 |
| ogra_ | greyback, (i dont care about internals the SIGSTOP needs to come from unity itself) | 16:17 |
| ogra_ | oh, ok | 16:17 |
| ogra_ | well then whatever :) | 16:17 |
| greyback | ogra_: mir is just a library, unity8 loads it. | 16:17 |
| greyback | :) | 16:17 |
| Saviq | ok, /me emits in startShell() | 16:17 |
| Saviq | but first - food | 16:17 |
| tvoss | Saviq, enjoy :) | 16:18 |
| ogra_ | yay | 16:19 |
| ogra_ | :) | 16:19 |
| alf_ | Saviq: greyback: Reading the code I don't think startShell will do | 16:21 |
| alf_ | Saviq: greyback: the startShell is invoked through a thread which is called in the *init_server* callback of run_mir | 16:22 |
| Saviq | alf_, ;( | 16:23 |
| alf_ | Saviq: greyback: the server object will have been created at the point, but not run | 16:23 |
| alf_ | Saviq: greyback: server objects | 16:23 |
| Saviq | ok, you guys talk, me really food | 16:24 |
| alf_ | Saviq: greyback: I think the sanest way is for the shell server configuration to subclass the Connector class and override start() to emit the signal after calling the parent start() | 16:25 |
| greyback | alf_: well I expected the server to be running, as startShell creates a mir client which connects ok | 16:25 |
| Saviq | greyback, yeah, but only when we exec(), no? | 16:25 |
| Saviq | greyback, so it might be sheer luck | 16:26 |
| alf_ | greyback: Isn't that an inprocess client? It doesn't go through the socket I think. | 16:26 |
| greyback | alf_: aha | 16:26 |
| alan_g | alf_: there are probably saner ways | 16:26 |
| greyback | ok yes I see startShell will be called before server.run() | 16:26 |
| racarr | Morning | 16:27 |
| alan_g | Evening | 16:28 |
| greyback | alf_: yes your suggestion would work. alan_g what's a better way? | 16:28 |
| alf_ | alan_g: probably, but without changing the mir code? | 16:28 |
| alf_ | greyback: alan_g: ideally, we could emit some kind of event when the server starts up fully, e.g., by injecting an event in our main_loop? | 16:30 |
| alan_g | alf_: The thing is that implementing Connector (as a proxy for the_connector()?) only tells about part of the initialization | 16:31 |
| alan_g | I'd imagine implementing MainLoop would be better - as everything is started by the time run() is called. | 16:32 |
| alan_g | But really I think there should be some sort of status notification (and also for pause/resume) | 16:34 |
| tvoss | alan_g, +1 | 16:34 |
| greyback | +1 | 16:34 |
| alf_ | alan_g: so extending pause_resume_listener I guess | 16:35 |
| alan_g | alf start_pause_resume_stop_listener? | 16:36 |
| alf_ | alan_g: server_status_listener? | 16:36 |
| alan_g | alf_: lgtm | 16:38 |
| alf_ | alan_g: ok, tomorrow then :) | 16:39 |
| kgunn | alf_: you approve kdub's fence improvements now too ? | 16:40 |
| alf_ | kgunn: yeap, thanks for reminding me | 16:41 |
| alf_ | kgunn: done | 16:41 |
| kgunn | alf_: efharisto | 16:42 |
| tvoss | kgunn, wow, I'm impressed | 16:43 |
| alan_g | "Ευχαριστώ" would be impressive | 16:45 |
| kgunn | :) ...i'll let that merge...gonna run, then i'll do the all the prep to get it in | 16:46 |
| === alan_g is now known as alan_g|EOD | ||
| racarr | tvoss: So was there practice ont he static initialization dealio | 17:04 |
| racarr | progress& | 17:04 |
| racarr | * | 17:04 |
| tvoss | racarr, nope, I think we need to transition papi over to gcc 4.8 | 17:05 |
| tvoss | racarr, post v1, though | 17:05 |
| racarr | tvoss: Hmm ok | 17:06 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrade | ||
| === dandrade is now known as dandrader | ||
| om26er | is there a ppa for Mir development branch somewhere ? | 18:44 |
| === thomi_ is now known as thomi | ||
| thomi | morning | 19:23 |
| racarr | Morning thomi | 19:40 |
| kgunn | racarr: would you mind a review & hopefully approve of https://code.launchpad.net/~mir-team/mir/bump-deb-changelog14-mirserver6/+merge/189990 | 19:50 |
| kgunn | racarr: oops | 19:50 |
| kgunn | sorry...wrong link | 19:50 |
| kgunn | racarr: i meant this one https://code.launchpad.net/~mir-team/mir/bump-deb-changelog15-mirserver7/+merge/191029 | 19:51 |
| racarr | kgunn: oi | 19:51 |
| racarr | kgunn: looks ok to me | 19:53 |
| kgunn | racarr: gracias | 19:54 |
| racarr | thomi: How can I use autopilot and a python console | 20:52 |
| racarr | to make key events :D | 20:53 |
| thomi | racarr: like this: | 20:56 |
| thomi | from autopilot.input import Keyboard; kbd = Keyboard.create(); kbd.type("some text") | 20:57 |
| thomi | or: kbd.press_and_release("Delete") | 20:57 |
| thomi | ... for "special" keys etc | 20:57 |
| racarr | thomi: Perfect. Thanks | 20:59 |
| kgunn | racarr: ok...one more...merging from dev to trunk...mind approving https://code.launchpad.net/~mir-team/mir/development-branch/+merge/191055 | 21:15 |
| kgunn | robert_ancell: hey...was just merging to trunk, how did duflu know there were merge conflicts that one time ? | 21:15 |
| robert_ancell | kgunn, the MP in Launchpad showed errors | 21:16 |
| robert_ancell | that one does not | 21:16 |
| kgunn | robert_ancell: that's what i thot....was just double checking | 21:16 |
| kgunn | what does it look like ?? yellow or something in the diff ? | 21:16 |
| kgunn | robert_ancell: | 21:17 |
| robert_ancell | kgunn, there are errors in the diff, i.e. "===" "<<<" type things | 21:17 |
| kgunn | robert_ancell: ah!! thanks... | 21:17 |
| robert_ancell | but also the list of files with conflicts is at the top under the "Merge Into" heading | 21:18 |
| kgunn | robert_ancell: same as when you do merge on bzr | 21:18 |
| robert_ancell | or somewhere nearby that | 21:18 |
| robert_ancell | yes | 21:18 |
| === jhodapp is now known as jhodapp|afk | ||
| racarr | kgunn: mergemergemerge | 21:24 |
| kgunn | racarr: thanks dude | 21:25 |
| racarr | kgunn: Do you know of a bug # for the thing where autopilot tests and sometimes apps | 21:30 |
| racarr | are getting | 21:30 |
| racarr | extra key events? | 21:30 |
| kgunn | racarr: let me dig one moment | 21:30 |
| kgunn | racarr: i don't see a bug like that...was it reported against a specific app ? | 21:36 |
| racarr | kgunn: I'm not sure it ever was | 21:46 |
| racarr | its just shown up in a bunch of autopilot tests failures | 21:47 |
| racarr | somewhat intermittently it seems | 21:47 |
| racarr | and apparently riccm ses it on real usage sometimes | 21:47 |
| racarr | ill sync with him when he gets back | 21:47 |
| kgunn | racarr: cool...do you have a fix ? or you're just aware of it as a legit problem ? | 22:03 |
| kgunn | racarr: maybe log a bug to track ? | 22:03 |
| racarr | kgunn: https://code.launchpad.net/~robertcarr/platform-api/fix-event-translation/+merge/191059 hopefully a fix :) | 22:04 |
| racarr | kgunn: I think the remaining half of the autopilot keyboard issues | 22:41 |
| racarr | is just key repeat... | 22:41 |
| racarr | since the OSK doesn't use this code path | 22:41 |
| racarr | or X mir -.- | 22:41 |
| racarr | I am trying to decide | 22:41 |
| racarr | if it's ok to just turn off key repeat | 22:42 |
| racarr | for now | 22:42 |
| racarr | basically autopilot presses, releases key, maybe that takes a long time to run | 22:42 |
| racarr | you get repeats | 22:42 |
| kgunn | racarr: ok...you're saying turn off key repeat only for AP's ? | 22:42 |
| kgunn | i would think folks would probably wig out if you turned it off all the time | 22:43 |
| racarr | well the thing is, then we would have to add it as an option, etc which is more stuff | 22:44 |
| racarr | but really | 22:44 |
| racarr | xmir uses it's own input, so it doesnt change xmir | 22:44 |
| racarr | the osk uses the seperate codepath so it doesn't change the osk | 22:44 |
| racarr | Is there actually any using | 22:44 |
| racarr | mir input with physical keyboards | 22:45 |
| racarr | for 13.10? | 22:45 |
| racarr | I guess it doesn't hurt to just make it an option... | 22:46 |
| racarr | thomi: IF we make a mir option for disabling key repeat, can things be set up so all the autopilot runs configure mir this way? | 22:46 |
| racarr | press("K") release("K") is always a race with key repeat enabled | 22:47 |
| thomi | racarr: but aren't key repeats at that level handled by separate key repeat events? | 22:48 |
| thomi | racarr: also, I'm not sure what the key repeat timeout is set to in mir, but if you look at the autopilot logs, the press & release events are pretty close together. | 22:49 |
| racarr | thomi: In cases where we get extra events I mean? | 22:49 |
| racarr | thomi: No what the timeout is set to, there is always a case | 22:49 |
| racarr | press("K") | 22:50 |
| racarr | autopilot gets preempted | 22:50 |
| racarr | stuff happens | 22:50 |
| racarr | release("K) happens after the timeout | 22:50 |
| racarr | you get repeat. | 22:50 |
| thomi | racarr: right, but I'm saying that the AP logs look like the press and release happens pretty close together. | 22:50 |
| thomi | hmmmm | 22:50 |
| thomi | veebers: perhaps we should just turn on the OSK backend by default? | 22:51 |
| thomi | oh, right - he went to the gym | 22:51 |
| racarr | thomi: I guess it's a half second | 22:52 |
| racarr | I don't know if it's really key repeat causing this...there was also this other bug that the fix-event-translation bug above is about that could be pretty related | 22:52 |
| thomi | racarr: so... can you actually reproduce this, or are you guessing that this is the cause? | 22:53 |
| veebers | thomi: I'm just out the door now, right now the OSK backend won't work until this MR is merged: https://code.launchpad.net/~veebers/ubuntu-keyboard/update_autopilot_emulators/+merge/190319 | 22:53 |
| racarr | so unless we have some logs of test failures with the duplicated events and key press differences greater than .5 second (where can I find such detailed logs/produce them myself?) | 22:53 |
| veebers | thomi: so I'm gonig to approve it now | 22:53 |
| veebers | going* | 22:53 |
| racarr | thomi: No! Just guessing. I can't reproduce it at all | 22:53 |
| thomi | racarr: ahh, ok | 22:53 |
| thomi | racarr: I'd be surprised if we saw > 500ms lag between press and release | 22:53 |
| thomi | not saying it can't happen, but... | 22:54 |
| thomi | I think something else is at fault here | 22:54 |
| racarr | mm | 22:54 |
| racarr | maybe it was fix-event-translation *Crosses fingers* | 22:54 |
| racarr | i need to find a test I can trigger it on and | 22:54 |
| racarr | dig down | 22:54 |
| racarr | it seems like it can show up in ubuntu-ui-toolkit so ill try that over and over again :p | 22:59 |
| racarr | out for some excercise brb | 23:40 |
| racarr | perhaps really more of a bbiab situation :p | 23:40 |
| lool | mir building in PPA | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!