=== chihchun_afk is now known as chihchun [05:49] Damnit, mir_demo_client_eglplasma! Why can't you find the socket? [06:00] RAOF: Cos we moved it in the server but failed to update libmirclient, I think [06:01] I would have pointed that out if the MP didn't fly by and land without me noticing [06:02] RAOF: If that's right, can you log a bug? [06:03] 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] Sounds pointy [06:26] good morning :) [06:27] Dear gdb: plz learn to C++. [06:27] No love, Chris. [06:30] RAOF, for printing values? [06:30] tvoss_: Indeed. [06:30] * tvoss_ always forgets the package that adds pretty printing of stl containers [06:31] To gdb? [06:31] RAOF, yup [06:32] tvoss_: When you remember, do tell [06:33] 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:35] Hm. [06:35] Looks like it might be in libstdc++-4.8-dbg? [06:36] RAOF, just pinged doko [06:36] Surely pretty-printing is a generic template thing? Should be... [06:36] i.e. Not STL-specific [06:36] duflu, it relies on python to do the pretty printing [06:37] Hah [06:37] RAOF, that would be libstdc++6-4.8-dbg, correct? [06:37] tvoss_: Yeah. Just trying to get it to actually work :) [06:37] RAOF, likewise [06:38] duflu: But you'd really really like STL-specific pretty printers, so that your std::map doesn't expand to 200 characters of entirely impenetrable implementation details. [06:38] RAOF: No, I'd like pretty printing for any template. Not just the STL. Just like clang does [06:39] I'd like that too. [06:39] I'd like both less stupid template expansions, *and* std::map = [{1, "one"}, {2, "two"}, …] [06:41] RAOF, duflu this mail also helps: http://lists.kde.org/?l=kdevelop&m=125326438617051&w=2 [06:42] although I would have thought that we have packaged that functionality, too [06:43] tvoss_: I can only get python syntax errors out of that. :( [06:43] Sadness ☹ [06:46] tvoss_: Ah. The pretty printers aren't python3 code. [06:46] ah [06:47] And since gdb links to the 3.3 runtime... [06:47] RAOF, now that's a bit annoying then [06:50] tvoss_: Ah, but running 2to3 on it appears to work. [06:50] RAOF, got a nice pastebin? [06:51] * tvoss_ wonders whether having pretty printers in our retracing-infrastructure would result in more easily readable stacktraces [06:51] tvoss_: sudo 2to3 --write /usr/share/gcc-4.8/python/libstdcxx/v6/printers.py [06:51] RAOF, that's easy :) [06:56] RAOF, I get http://paste.ubuntu.com/6234780/ === chihchun is now known as chihchun_afk [07:00] tvoss_: Oh, you do 2. from http://sourceware.org/gdb/wiki/STLSupport, but with /usr/share/gcc-4.8/python [07:01] RAOF, nope, that's from libstdc++-4.8-dbg [07:03] 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:04] Hm. Do we build without rtti? The pretty-printer is an ugly-printer without it :) [07:05] RAOF, nope, we never disabled rtti === chihchun_afk is now known as chihchun [07:06] 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, (__gnu_cxx::_Lock_policy)2>' [07:08] duflu, re: bug 1227739 I assume that work will go in after 13.10 release ? [07:08] 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:09] 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:10] ... everyone's too busy to review them one way or the other [07:10] RAOF, https://sourceware.org/bugzilla/show_bug.cgi?id=14235 [07:10] sourceware.org bug 14235 in python "verbose RTTI message polluting traces" [Normal,New] [07:11] duflu, right. there is still work in unity-mir needed after your branches get merged? [07:11] or any other component [07:11] om26er: Yeah, *maybe*. Would be unpredictable as to whether the fix works otherwise. [07:12] The unity-mir fix is trivial. I'm just not familiar with building/testing that project [07:12] Umm, I mean platform-api? [07:16] 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] Ubuntu bug 1238107 in maliit-framework (Ubuntu) "maliit-server crashed with SIGSEGV in __GI___pthread_mutex_lock()" [Medium,Confirmed] [07:17] Saviq, alf_ was looking into a similar issue [07:18] Saviq: I was planning to look into at after updating the phone [07:18] s/at/it/ [07:18] alf_, great thanks, let me know if you need help! [07:18] Saviq: will do [07:19] Saviq: so, just 'stop unity8' to reproduce? [07:19] I got a webbrowser crash with the same trace on build 95 this morning bug 1239522 [07:19] bug 1239522 in webbrowser-app (Ubuntu) "webbrowser-app crashed with SIGSEGV in __GI___pthread_mutex_lock()" [Medium,New] https://launchpad.net/bugs/1239522 [07:20] alf_, yeah [07:20] jibel, yeah, it's something in mirclient most probably [07:20] jibel: @1239522, is the webbrowser-app reproducible consistently? [07:20] jibel: the crash I mean [07:21] alf_, no, I was trying all the apps to verify none of them was completely trashed. I'm searching a way to reproduce. === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:41] duflu, re: bug #1238107 I believe alf_ said bug #1233988 was slightly different [07:41] 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] 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] actually [07:41] * Saviq builds platform-api [07:42] Saviq: ah, so the fix for 1233988 is not yet in? [07:42] 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] alf_, it's Fix committed everywhere [07:42] duflu, +1 [07:42] Saviq: but not released... [07:42] alf_, yup [07:43] alf_: I assume you verified the platform-api was smart enough to at least check for connect failure? [07:43] .. i.e. returning false is not in vain [07:45] alf_, actually it's released in platform-api https://code.launchpad.net/~phablet-team/platform-api/trunk [07:45] 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] on Thursday [07:46] Right, but the bug may still exist. Only as an error now rather than a crash [07:47] Although platform-api could still be abusing libmirclient and cause it to crash elsewhere [07:47] Perhaps we should strengthen libmirclient so it doesn't get blamed for bad parms... [07:47] alf_, duflu, I'm still getting that crash reliably in maliit-server when stopping unity8 [07:47] Saviq: what about 1233988 ? [07:47] somewhat reliably at least [07:47] bug #1233988 [07:47] 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:48] alf_, I never knew how to reproduce it... the trace seems exactly the same.. [07:48] Saviq: I'm not confident the fixes so far are sufficient so maybe just reopen instead of duplicating in new bugs [07:48] duflu, sure - your call [07:48] duflu: Let me investigate a bit further today, and I will merge as needed [07:50] Saviq: Most importantly I just want to prevent people from working on duplicates. They're unaware of duplicating effort etc [07:50] duflu, I understand [07:50] duflu, works for me [07:50] alf_: Should we be looking up valid_connections for all libmirclient API calls? [07:51] Probably wouldn't hurt [07:51] And it would stop crash reports from landing in Mir [07:52] Hmm, actually it wouldn't. But it would allow us to instantly say "not a Mir bug" [07:59] duflu, alf_ I still get the maliit-crash on reboot [07:59] so sounds like not fixed indeed [07:59] Saviq: No problem, just reopen [08:00] 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] alf_, ok ;) [08:01] alf_, http://pastebin.ubuntu.com/6234953/ [08:02] Saviq: so is this with the default platform-api package, or something you built? [08:02] alf_, default papi, my mir trunk + https://code.launchpad.net/~kdub/mir/android-buffer-syncfence/+merge/189717 [08:02] alf_, can downgrade mir if you think it matters [08:04] 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:05] alf_, will do [08:06] Saviq: hmm, just a moment to check something [08:07] alf_, holding [08:11] 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:12] alf_: One of the duplicates today clearly showed MirConnection's this==NULL [08:14] 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] tvoss_: ^^ ? [08:14] right now it just asserts [08:15] alf_, yes, returning null would be correct [08:15] alf_, admittedly, error handling should be better, but right now, NULL indicates error [08:15] I think we need to protect libmirclient from false accusations and error-check the connection parameters [08:20] duflu: +1 [08:48] alan_g, ping [08:48] tvoss_: hi [08:49] alan_g, hey there, can I ask you to review https://code.launchpad.net/~kdub/mir/android-buffer-syncfence [08:49] tvoss_: it is on my list [08:49] alan_g, ack, we would like to land the mp asap, so would be great if you could bump priority [08:52] 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] alan_g, #ubuntu-desktop [08:53] tvoss_: ta [08:59] * duflu sees clipping bugs on iOS 7 and feels better about life [09:00] duflu: :) [09:01] It's kind of nice generally that Apple has lowered the bar/standard for UIs :) [09:06] My wire dislikes iOS7 nearly as much as Windows8 [09:06] -r +f? [09:09] 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:21] 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:22] 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 [10:11] 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] lp:~mir-team/mir/verify-MirConnection [10:12] duflu: Sure, I'll have a look later [10:12] Saviq: https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-more/+merge/190908 and [10:12] Saviq: https://code.launchpad.net/~afrantzis/qtubuntu/fix-1233988-more/+merge/190907 [10:12] alan_g: Cool, ta [10:13] alf_, cool! [10:14] alf_, will test asap [10:14] 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:15] alf_, so a better message at least [10:15] alf_, and no crash [10:15] alf_, well, I *know* why it can't connect - it's being shut down :) [10:16] 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:17] alf_, indeed === chihchun is now known as chihchun_afk [10:28] 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:29] Saviq: some kind of race perhaps? How does upstart now when unity8 has started, so it can start maliit-server? [10:29] alf_, they stop "in concert" and indeed it's not 100% reproducible [10:29] alf_, but you can run the unity8 ap tests suite - should get you some .crash files [10:36] 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] ogra_, ↑ can you shed some light there? [10:37] it waits until the PID it got returns something ... [10:39] Saviq, alf_ http://upstart.ubuntu.com/cookbook/#expect [10:40] ogra_: thanks [10:40] 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] alf_, yeah, I know [10:41] Saviq: does unity8 daemonize? [10:41] alf_, nope [10:41] so tracking the first PID should be fine then [10:42] (i.e no need to set "exepect") [10:42] 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] (except if you fork more than once) [10:45] 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] *quest [10:45] is teher a sprecific socket or file maliit should wait for ? [10:46] upstart has ways to make it do that === chihchun_afk is now known as chihchun [10:46] (you could drop "on started unity8" and make it ie "start on created socket file") [10:47] (and stop on removed ...) [11:14] 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:19] 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] alan_g, got it [11:32] alan_g, for kdub's branch: could you give it a more detailed review before kdub fixes the tests? [11:34] tvoss_: that was my plan === hikiko is now known as hikiko|lunch [11:34] alan_g, thx, would help a lot [11:38] tvoss_, btw, https://bugs.launchpad.net/unity8/+bug/1238645 is apparently valid for mir/qtubuntu/somewhere [11:38] Ubuntu bug 1238645 in Unity 8 "Shell does not get autopilot keyboard input if maliit isn't running" [Undecided,In progress] [11:39] Saviq, looking [11:39] 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] even with the workaround that we have [11:39] or workaround--, but upstart++ starting maliit-server for us [11:40] hmmm, so key events are sent via uinput? [11:42] just add an env var check to maliits upstart job [11:43] make it a no-op if the var is set ... export it from AP [11:46] Saviq, what ogra_ said ^? [11:46] tvoss_, yes they are [11:46] ogra_, it's not about maliit not being started [11:46] ogra_, it should be unrelated [11:46] ah, k [11:46] i thought maliit blocks uinput [11:48] ogra_, that's actually an interesting idea. Saviq, didn't we see the permissions on /dev/uinput change recently? [11:49] tvoss_, well, yeah, it changes to "bluetooth" for me [11:49] tvoss_, but works regardless of that [11:50] 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:53] Saviq, ack, looking into it === tvoss_ is now known as tvoss|dentist [12:00] root@ubuntu-phablet:/# grep uinput /lib/udev/rules.d/* [12:00] /lib/udev/rules.d/61-autopilot-uinput.rules:# Creates autopilot group specific access to /dev/uinput [12:00] /lib/udev/rules.d/61-autopilot-uinput.rules:KERNEL=="uinput", SUBSYSTEM=="misc", SYMLINK="autopilot-uinput", GROUP="autopilot", MODE="0660" [12:00] /lib/udev/rules.d/70-android.rules:ACTION=="add", KERNEL=="uinput", OWNER="system", GROUP="bluetooth", MODE="0660" [12:01] Saviq, tvoss|dentist ^^^ [12:01] i guess we should drop it from the android rules :) [12:02] (and if GROUP=autopilot is wrong adjust thios too) === hikiko|lunch is now known as hikiko === jhodapp|afk is now known as jhodapp === alan_g is now known as alan_g|lunch [12:53] 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:57] Saviq: because, all the backtraces we have for this issue point to this happening during application (Qt platform) setup [12:58] Saviq: in any case, the new MPs for platform-api and qtubuntu should make this clearer === tvoss|dentist is now known as tvoss === alan_g|lunch is now known as alan_g [13:09] alf_, might be indeed, am building them now === chihchun is now known as chihchun_afk [13:11] 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] Ubuntu bug 1238116 in unity8 (Ubuntu) "unity8 crashed with SIGSEGV in QIcon::~QIcon()" [Medium,Confirmed] [13:12] alf_, right, that one's solved with https://code.launchpad.net/~aacid/unity-mir/waitforme/+merge/190716 [13:13] alf_, and it uncovered a few other bugs now indeed [13:13] alf_, since we're destroying stuff proper now [13:14] alf_, I'm just building qtubuntu now and will let you know of what changed asap [13:15] Saviq: thanks (note you need both the MPs to see the effect) [13:15] alf_, yup, papi already built [13:25] Saviq, I do see events getting into mir with autopilot and maliit not running [13:26] tvoss, yeah, we need to track them up the stack [13:27] greyback, I added a video to bug 1234538 [13:27] bug 1234538 in unity8 (Ubuntu) "With Mir enabled - Applications randomly failed to start" [High,Confirmed] https://launchpad.net/bugs/1234538 [13:27] Saviq, I have a gut feeling that maliit goes away and the focus chain in unity is not correctly restored or something [13:28] jibel: thanks. That video I guess with a recent image? [13:28] greyback, 96 [13:28] jibel: perfect, thanks. Will look [13:28] tvoss, if maliit is stopped *before* unity8 starts [13:29] tvoss, it doesn't work either [13:29] Saviq, hmmm ... which would then mean, that qt/qml somewhere checks if an input-method is available [13:35] jibel: last question: that a galaxy nexus or nexus4? [13:35] greyback, mako/nexus4 [13:36] jibel: Ok, I'll try it there. [13:39] mzanetti: that one new to me, thanks for that [13:40] mzanetti: is it logged? I can't find it? [13:40] greyback: noticed when developing the Ubuntu Authenticator on the weekend [13:40] greyback: no, didn't report it yet [13:40] greyback: it doesn't really hit users, but it [13:40] is annoying for app developers [13:40] mzanetti: every fix is a good fix [13:42] mzanetti: what issue is that? [13:42] davmor2: run an app from the command line, lock the screen, press ctrl+c to stop the app, unlock the screen -> Boom! [13:43] Saviq, got it [13:47] alf_, so yeah, "FATAL: QUbuntu: Could not create application instance", but still getting crashes [13:47] alf_, and/or unity8 locking up [13:47] collecting .crashes now [13:50] 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:51] alf_, I can get you both, yeah [13:51] alf_, I can also get you packages I'm seeing that in, if you want them [13:52] Saviq: yes, a cross check with what I have would be good, since I can't get the crash... [13:58] alf_, so... http://people.canonical.com/~msawicz/repo.tar.gz - still uploading [13:58] alf_, that is: [13:58] mir + https://code.launchpad.net/~kdub/mir/android-buffer-syncfence/+merge/189717 [13:59] platform-api + https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-more/+merge/190908 [13:59] qtubuntu + https://code.launchpad.net/~afrantzis/qtubuntu/fix-1233988-more/+merge/190907 [13:59] unity8 + https://code.launchpad.net/~unity-team/unity8/ap_launch_unity_with_upstart/+merge/190886 [14:00] session-manager-touch + https://code.launchpad.net/~saviq/session-manager-touch/drop-unity8 === dandrader is now known as dandrader|afk [14:00] Friday's unity-api + https://code.launchpad.net/~aacid/unity-mir/waitforme/+merge/190716 [14:00] alf_, you can just add it as a repo in sources.list and upgrade from it [14:01] alf_, you can disregard unity8 and session updates, though [14:01] alf_, will ping you when it uploads [14:05] alf_, https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1239712 here is the current trace [14:05] Ubuntu bug 1239712 in maliit-framework (Ubuntu) "maliit-server crashed with SIGABRT in raise()" [Undecided,New] [14:11] alf_, uploaded [14:12] hm [14:12] I think I understand the gbm fail [14:14] this makes it a bit harder though === dandrader|afk is now known as dandrader [14:25] mlankhorst: what's the cause for the gbm fail? [14:27] the gbm piping expects a gbm surface type [14:28] but I think it can be workarounded.. [14:29] hold on [14:31] in particular the createNewDrawable call, I'm writing a workaround atm.. === alan_g is now known as alan_g|lunch [14:39] well that was easy [14:39] now both work [14:40] http://paste.debian.net/57430/ gg hf kthxbye [14:41] the #if 0 code can be removed or kept, it works either way [14:42] alf_/RAOF: ^ [14:43] mlankhorst: \o/, so this fixes the nested mir case totally? === alan_g|lunch is now known as alan_g [14:46] it fixed eglflash unnested for me, so I would assume so [14:48] mlankhorst: awesome, I will try when the phone drops in priority, probably near EOW [14:50] 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] mlankhorst: is the diff against egl-platform-mir-egl-image-i965-experiment ? [14:54] hm no it's a diff against my previous diff :P [14:54] I think I had some changes on top [14:56] alf_: yeah, apply this one first http://paste.debian.net/57441/ [15:01] 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] Saviq: can you verify that you get a maliit crash after 'start unity8' and not after 'stop unity8'? [15:03] alf_, trying [15:03] alf_, it'd make sense indeed [15:09] kdub, hey there :) [15:09] hello tvoss [15:10] kdub, so you are the most wanted person today :) [15:12] kdub, would be great if you could jump on fixing the test failures on https://code.launchpad.net/~kdub/mir/android-buffer-syncfence [15:13] kdub, if that is fixed, we could land the branch [15:13] yep, #1 on the list for today [15:13] kdub, cool [15:13] kdub, let me know if I can help [15:18] alf_, confirmed [15:18] alf_, /me adds "sleep 2" to maliit job... [15:19] damn [15:19] alf_, yeah, confirmed [15:19] alf_, could we not SIGABRT when can't connect to server? [15:19] ogra_, can we add "sleep 2" to maliit-server before starting? [15:19] ergh, why is that [15:21] that adds 2 secs to the session startup, can you solve it in any other way ? [15:21] (i just spent two weeks to get the boot below 30sec again) [15:22] ogra_, maliit starts too early [15:23] ogra_, Mir in unity8 isn't yet ready [15:23] Saviq, then fix unity to not tell upstart it is started when it is notz [15:23] ogra_, how? [15:23] make it wait ? dunno [15:24] 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] ogra_, nope [15:24] ogra_, we're not forking at all, though [15:24] ogra_, we're not daemonizing [15:25] ogra_, but will look through upstart cbook [15:25] please ask slangasek how to do it right then [15:25] i think he can help here [15:26] (or if slangasek isnt around, probably xnox or stgraber can help they are both upstart aces :) ) [15:26] (or even jodh as upstart upstream) [15:26] hm? [15:27] xnox, the unity8 upstart job seems to return before unity8 is actualyl ready ... causing dependent jobs to start to early [15:27] ogra_: invoke tedg =) unity8 should emit started unity8, until ready =) [15:27] ogra_: if there is a dbus known-name that unity8 exports, jobs can start on started that. [15:27] ogra_: thanks to the dbus bridge. [15:28] Or we could ask unity8 to emit sigstop when ready and have the job wait on that. [15:28] I believe upstart has a mode for that. [15:28] well, any kind of landmark will do i guess [15:28] xnox, would initctl emit --no-wait unity8_ready (in unity) with a corresponding start on unity8_ready in maliit upstart conf work? [15:28] Saviq, ^ [15:28] i'm just opposed to add sleeps back into upstart jobs [15:29] Yup, here it is: http://upstart.ubuntu.com/cookbook/#expect-stop [15:29] 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] tvoss: tedg: expect stop is far better. [15:30] tvoss, seriously, unity8 should just DTRT :) [15:30] ogra_, we are trying to find out what the right thing is :) [15:30] before we write 100 line upstart jobs [15:30] ogra_, *you* might know, but simple question: how does a process signal "I'm ready" back to upstart? [15:30] tvoss, There seems to be three idioms used here: 1) be fast, 2) sigstop, 3) fork but not until you're ready [15:31] right [15:32] tedg, why not emit an expicit signal? sounds like the best solution in an event-based job control system? ;) [15:32] tedg, s/signal/event [15:32] tvoss, thats the sigstop ... [15:33] ogra_, yeah, I meant event then [15:33] 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] from where ? [15:33] 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] ogra_, from unity8, just calling "initctl emit --no-wait unity8_ready" [15:33] whenever that is the case [15:33] ugh [15:34] tvoss, Then what would people use the "started unity8" event for? It seems like we'd be wasting that one. [15:34] just make your binary DTRT ... if there is no expect mode for your binary behavior, ask jodh to add one [15:35] tvoss, i think tedg's sigstop suggestion is the best we can do as a quick solution [15:35] sounds clean enough, yeah [15:37] Saviq, if you are happy, I'm too [15:37] * Saviq wonders when to emit it ;D [15:38] Saviq, whenever qtguiapplication is constructed I would think [15:39] alan_g, alf_, pushed fixes for the unit tests... they were just test problems, no code change [15:39] kdub: ok [15:40] tvoss, Throw in an idle event, then the first time you hit the mainloop without events... [15:40] tvoss, don't we need to spin the loop? [15:41] 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] testing... one minute [15:42] Saviq, not sure ... [15:43] 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:44] kdub: thanks (I'm trying to track down the interaction - at least this should require the same fix) [15:51] ogra_, can upstart check if a file exists? [15:52] tvoss, yes, with the file bridge [15:52] (as long as it is a regular file) [15:52] ogra_, yup, we just need to check if we are running on mir [15:53] ogra_, can we check if file && socket exist? [15:53] Saviq, socket is tricky [15:53] file is easy [15:53] ogra_, basically, if [ -e ~/.display-mir ] wait_for(/run/user/32011/mir_socket) [15:54] Saviq, and on my tablet where i have two users ? :) [15:54] ogra_, I don't think that's a valid use-case right now [15:54] tvoss, Saviq is adding the SIGSTOP in the code right after the file creation not an option ? [15:55] ogra_, I think Saviq is looking for a way to live without the sigstop for now [15:55] :( [15:57] no I'm not [15:57] I'm just looking for a good way to do it [15:57] and asking *when* to safely emit the sigstop [15:58] I'm fine with emitting it wherever - but someone knowing Mir needs to tell me when is it safe already [15:58] 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] alf_, is this ping cancellable? [15:58] alf_, you got a +1 from me 30s ago :) [15:59] Saviq: the .wait() will just return immediately, no need to cancel :) [16:00] :) [16:02] alan_g, alf_ do we signal back to mir if the communicator is ready to take connections? [16:02] alf_, approved and top-approved [16:03]