[00:15] so I reinstalled [00:15] I got the same bug, but eventually it started [00:16] the timing for pressing power button might matter [00:43] racarr, kgunn: Pretty good news [00:44] racarr, kgunn: It was borderline unstable, but now that I have hud with it, unity8 doens't crash anymore and boot is much more stable [00:44] and everything is going in archive, one at a time [01:17] lool: thanks man! [01:18] kgunn: we have an issue with Hud [01:18] kgunn: it's likely regressing the desktop [01:19] kgunn: who would be able to help this? [01:19] kgunn: I can land without it, but the results will be crappy [01:19] lool: i assume its likely backend ?? ted would be best [01:19] but doesn't seem on [01:19] ted isn't up til 10 hours [01:19] at least [01:19] i know the issues were around the backend.... [01:20] kgunn: So they added a platform-api backend [01:20] kgunn: but on desktop I think we still want bamf [01:20] but we dropped the bdep [01:20] olli_: you on ?? ^ [01:20] lool: thostr_ will be our best bet euro am [01:21] ok [01:21] I might try just adding the bdep [01:21] you could get some sleep man and hit it in the morning [01:21] yeah that too [01:22] ricmm_: know anyone who knows about hud backend ?? ^ [01:26] back [01:26] seems like we definitely need bamf on desktop [01:31] lool: Good to hear image is working better with hud :D [01:31] is boot faster now too? [01:32] unity mir boot has been really slooow [01:32] and ive kind of suspected it has to do with errors about hud timeouts :p [01:45] kgunn, yep [04:19] kgunn: what happened? [04:20] lool: I explicitly remember them saying "we both tested on desktop and phone and all works fine" [04:21] lool: how did the MR land to trunk if it didnt have the bamf build dep? [04:22] oh that was 3 hours ago [04:22] crap [04:22] his fix looking good [04:22] * ricmm_ -> zzz [04:25] kdub_: btw if you are still around [04:26] kdub_: timings show that unity8 is busy blocking on buffer swap for about ~50ms per frame every other frame or so [04:26] when rendering intensively [04:31] racarr: kind of suspected? its a known thing since ever! [05:18] ricmm_: I guess I didnt know it was known because the one or two times I mentioned it no one said anything [05:18] and I was just like [05:18] ok move on! [05:21] Ok. How have I managed to break egl-platform-mir? [05:26] RAOF: If you expect either a useful or amusing answer, I can't comment [05:32] racarr: (1) log off, else (2) Should bug 1233245 have Mir task? [05:32] bug 1233245 in Mir "[mir] key events not working through input devices (aka volume up/down)" [Critical,Triaged] https://launchpad.net/bugs/1233245 [05:33] that bug is done afaik [05:33] ricmm_: BTW, the "50ms per frame", what device? [05:33] mako [05:33] Oh. Mako should be better than that already [05:34] theres a whole bug going on since the fencing was introduced to remove the tearing [05:34] of course it *should* be [05:34] but it hasnt been for a while [05:34] ricmm_: Yeah I was going to point you at that bug [05:35] ricmm_, do you know if kdub tried switching to triple buffering while I was sleeping? [05:35] tvoss: he didnt because apparently its not trivial to do [05:38] It occurs to me we have a significant bottleneck for touch with only one Android person on mir-team [05:49] Dear bandwidth: where have you gone? :( [05:57] didrocks, salut :) [05:57] hey tvoss! === Stskeepz is now known as Stskeeps [06:35] lool: Which PPA contains the packages you used to test the fix to the close.qml crash (or have the packages reached the archive now)? [06:51] lool: FWIW, with latest packages from the archive, I can't reproduce the crash anymore [06:54] Bah! How was mesa mis-built? [06:56] * mlankhorst looks at excuse calendar [06:57] high pressure system failure [07:05] Current theories include: cosmic rays, and clang. [07:06] well a computer generated my excuse, so it's more reliable [07:06] But did cosmic rays affect the computer's output? [07:08] we're not in space [07:08] Yes we are [07:08] * duflu goes to close the pod bay doors [08:02] alf_: it's all in #90 now [08:02] alf_: racarr also gets the crash with latest tip [08:02] alf_: I haven't tried again though [08:02] alf_: maybe we landed something else from archive in image that we were lacking in testing [08:06] lool: are you tests with mako or maguro [08:06] ? [08:08] alf_: haven't retried yet [08:08] alf_: but if you're not seeing it with latest image great [08:08] alf_: mako [08:09] lool: ok, please give it another try when you can and let me know [08:09] yup [08:09] breakfast first [08:49] Hey I got my phone back!... How do I tell the image number (like "90")? [08:50] duflu: cat /etc/media-info gives you some information, which you can use to find the image number [08:50] Ta [08:52] duflu: of course, if you upgrade packages then this is not accurate any more [08:52] None seem to need upgrading... [08:53] duflu, just reflash 90 :) [08:53] Did we kill off /tmp/mir_socket for unity8? [08:55] duflu: look in $XDG_RUNTIME_DIR [08:57] tvoss: a great problem with reflashing is that it deletes your development environment on the phone... it's a big waste of time to set it up again (get all the build-deps and -dbg(sym) packages, tools etc) [08:58] alf_: +1 [08:58] alf_: (and every time I think I understand it well enough to write a script something changes) [09:01] hm anyone got something for me to look at? :P [09:04] duflu: since you have a fresh image, do you have a moment to try https://bugs.launchpad.net/qtubuntu/+bug/1237052 ? [09:04] Error: Could not gather data from Ubuntu for bug #1237052 (https://launchpad.net/bugs/1237052). The error has been logged [09:04] alf_: Just put it away. I'll get back to it soon [09:05] alan_g, https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags/+merge/190316 [09:05] duflu: ok, btw you don't need to build anything, all fixes are in the archive now (check my last comment in that bug) [09:06] tvoss: ack [09:07] alan_g, waiting for CI to produce a testable package [09:07] mlankhorst: nested Mir EGLImage support is still pending if you are interested ;) [09:08] hm fine :P I'll poke it a bit more [09:10] mlankhorst: I know that RAOF also took another look recently, but I am not sure if there was any progress [09:10] RAOF: ^^ [09:10] mlankhorst: (or at least that he wanted to take a look) [09:20] tvoss: see https://code.launchpad.net/~thomas-voss/mir/add-pthread-linker-and-preprocessor-flags/+merge/190316/comments/436722 [09:23] alan_g, duflu: it's about our own usage of pthread [09:23] tvoss: Can you detail the findings in the MP? [09:24] duflu, the linked bug points to a very weird issue when a client tries to access the display configuration. Same happens for maliit server, which results in a lot of crashes during test automation [09:25] tvoss: Ah yes, spent time staring at those crashes today [09:25] duflu, alan_g was able to reproduce the issue with a simple program using a std::unique_lock and not adding -pthred [09:25] -pthread [09:25] tvoss: the maliit server definitely pulls in pthreads [09:25] alan_g, but: our client library is not compiled with that flag [09:25] alan_g, and that's where the exception is thrown [09:26] tvoss: It's a theory, but I'm not convinced the Mir code is in need of any more "-pthreads", because it would be crashing immediately in the same way (which it doesn't) [09:27] tvoss: what duflu said [09:27] duflu, anyway, I'm only sticking to what the pthread manual suggests: add -pthread [09:27] alan_g, duflu I'm basically waiting for jenkins to produce a testable package, thus the mp [09:27] duflu: I don't think it hurts to try this [09:27] AFAIK -pthread just defines some macros and adds -lpthread to LDFLAGS [09:28] duflu, implementation defined [09:28] duflu, usually REENTRANT is set, but could be more complex for arm for example [09:28] alan_g: It's likely unnecessary bloat to link libraries not all binaries need. Though I suspect all Mir binaries do :/ [09:29] duflu, if you have got a better idea to solve it -> go for it :) as long as the maliit server crashes are down to 0 in http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/90:20131010:20131010/4644/ [09:29] duflu: If it fixes the problem that is a useful data point [09:29] duflu, library bloat -> micro optimization, let's save that for later [09:29] Not worth arguing... [09:30] duflu, ack [09:30] tvoss: Worth a try. Linked bug 1233988 too [09:30] bug 1233988 in platform-api (Ubuntu) "With Mir enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Confirmed] https://launchpad.net/bugs/1233988 [09:31] duflu, thx [09:31] duflu, can you give the package a spin, too, once ci spits it out? [09:32] tvoss: Sure but I think I'll be gone before then. [09:32] duflu, ack :) [09:40] alf_: huh? this is messed up [09:40] oh nm :P [09:55] alf_: so I assume the problem is in the nested mir somewhere, what is the image supposed to be for empty server, is it cleared? [09:56] mlankhorst: yes, it's glClear()-ed, and then surfaces are composited [09:58] lool: any luck with https://bugs.launchpad.net/qtubuntu/+bug/1237052 ? [09:58] Ubuntu bug 1237052 in qtubuntu "Apps that close themselves crash trying to use deleted EGL resources" [Undecided,Fix committed] [10:01] * duflu goes to play with vegetables [10:05] alan_g, https://jenkins.qa.ubuntu.com/job/mir-saucy-amd64-ci/831/console [10:05] alan_g, is that known? [10:07] tvoss: it wasn't to me - but https://bugs.launchpad.net/mir/+bug/1236698 [10:07] Ubuntu bug 1236698 in Mir "The following tests FAILED: 99 - memcheck(unit-tests.PublishedSocketConnector.*) (Failed)" [High,Triaged] [10:09] alan_g, are you on it? [10:09] tvoss: I'll add it to my list [10:12] alf_: sorry didn't have time so far, but I do now [10:14] alf_: and it worked! [10:14] alf_: So I didn't have all the in distro changes when I tried that yesterday; I definitely had updated qtubuntu, and had an intermediate update of the mir packages, but not anything else [10:14] lool: \o/ [10:14] alf_: but now with image #90 it passed [10:15] alf_: sorry for the delay in confirming [10:15] alf_: huh.. [10:15] why is dri2_create_image_khr_pixmap never called? :P [10:15] alf_: I'm glad it's fixed after all, I almost didn't take qtubuntu in because of this [10:16] alf_: updated bug too [10:16] lool: thanks [10:17] oh nm [10:18] mlankhorst: :) [10:18] alf_: hm if you use the native platform allocator for allocating buffers, what do you use for allocating the main window for nested? [10:19] mlankhorst: the host mir allocates that and sends us the buffer (host mir uses platform_drm) [10:19] yeah where's the code for importing that? [10:26] mlankhorst: in mesa mir_advance_colour_buffer() [10:27] mlankhorst: it uses the prime_fd from the buffer package [10:27] mlankhorst: i.e. the host mir essentially sends the nested mir the prime fd for the "main window" surface, and nested mir passes that to mesa [10:29] alf_: yeah but if the nested mir has no clients, does anything clear the contents of the bo? [10:33] mlankhorst: yes, it is made current, and glClear() is called [10:33] mlankhorst: prime_fd -> EGLSurface -> make_current -> glClear() [10:34] mlankhorst: (at least this is what should be happening) [11:11] can I somehow enable the spam from mir? [11:11] jibel: I am checking the Mir Testing Notes document for bugs to look into... is bug 1237900 still private? [11:11] Error: Launchpad bug 1237900 could not be found [11:12] jibel: or is it a typo? [11:12] jibel: It's the last bug in Image 90:20131010:20131010 list === hikiko is now known as hikiko|lunch [11:36] alf_, it is public now but invalid [11:53] racarr: alf_: any news on the crashers front? [11:53] Saviq: ^^ (unity8 crashes in particular i think) [12:01] asac: Most of the crashes caused by the interaction with Mir have been fixed in the latest image [12:02] we still see unity8 crashing http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/91:20131010.1:20131010/4658/webbrowser-app-autopilot/ [12:03] this doesnt happen with SF [12:03] just run webbrowser autopilot [12:04] asac: that seems like https://bugs.launchpad.net/ubuntu/+source/platform-api/+bug/1233988, which is in progress from what I can see [12:04] Ubuntu bug 1233988 in platform-api (Ubuntu) "With Mir enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Confirmed] [12:04] can someone tell me where Mir gets the VSYNC info from ? [12:05] alf_: there is maliit and unity8 crash [12:05] alf_: you say that unity8 crash goes away if maliit doesnt crash? [12:05] bleh stupid thing, glClear being ignored;S [12:05] alf_: _usr_bin_unity8.32011.crash [12:05] asac: I am not saying anything :) [12:05] hehe [12:05] * ogra_ is fiddling with bug 1234743 and moving the VSYNC event from a uevent to a sysfs node makes Mir choke while surfaceflinger still starts [12:05] bug 1234743 in linux (Ubuntu) "omapfb module floods system with udev events on samsung galaxy nexus" [Undecided,Incomplete] https://launchpad.net/bugs/1234743 [12:05] well, you said its in progress most likely... but that smells like the maliit fix [12:05] not the unity8 [12:05] alf_: the unity8 goes away on SF as well [12:06] i wouls suggest embracing that as a crash that is caused by MIR interactions === alan_g is now known as alan_g|lunch [12:07] oh you've got to be kidding me [12:09] asac: not how I diplomatically said that *most* of the crashes... have been fixed ;) [12:09] asac: s/not/note/ [12:09] right [12:09] are you on this one? [12:09] asac: I am now [12:09] any leads/hopes? [12:09] nice :) [12:19] mlankhorst: ? [12:25] nah was hoping for a more logical explanation, meh [12:26] I'll try without radeon, and use intel, at least it has dri2 support. :P === hikiko|lunch is now known as hikiko === alan_g|lunch is now known as alan_g [13:00] alf_: but that code was working with android right? [13:00] mlankhorst: yes [13:46] alf_: only thing i found so far is that linuxvirtualterminal should probably not be created in nested, meh [14:07] tvoss: What's the problem in maliit with bug 1233988? I have found a problem in platform-api related to this, too... [14:07] bug 1233988 in maliit-framework (Ubuntu) "With Mir enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Fix committed] https://launchpad.net/bugs/1233988 [14:07] lool: ^^ [14:11] alf_: tvoss is exploring the theory that because we've not linked the Mir client library against pthreads maliit blows up. (I don't know if the theory has been tested yet) [14:14] alan_g, issue is solved, it wasn't that in the end [14:14] alan_g, but: -pthread is still a good idea [14:15] tvoss: then what was it? [14:16] alan_g, maliit trying to access mir, without mir running :) [14:16] alan_g, working on a fix to the platform api [14:16] alan_g, it should handle that situation more graceful [14:17] tvoss: "mir running" == there's a Mir connection? [14:18] tvoss: lool: alan_g: see my latest comment and MP in https://launchpad.net/bugs/1233988 [14:18] Ubuntu bug 1233988 in platform-api (Ubuntu) "With Mir enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,In progress] [14:21] alf_: meh I'll try what happens if I always enable gbm, ran out of other ideas :P [14:21] alf_: tvoss I see. But Mir is also behaving badly - it ought to fail operations, not crash. (One reason for returning an "Error" connection is that it can provide sensible error mode behaviour) [14:22] alan_g: agreed [14:22] alan_g, true. I won't find time to fix that part, though === alan_g is now known as alan_g|tea === pete-woods is now known as pete-woods-away [14:31] alf_: ah excellent, if I force the gbm path to be always taken it corrupts too, that makes it a lot easier to debug.. [14:32] http://paste.debian.net/55230/ [14:33] to the best of my knowledge, it should behave identically right? === ricmm_ is now known as ricmm === alan_g|tea is now known as alan_g [14:57] mlankhorst: when you have some time please check https://code.launchpad.net/~hikiko/mir/mir.fix-in-session-leader/+merge/190353 (also see my comment there) [14:58] alf_: did your crash investigation give reason for hope :)? [15:01] asac: got caught up in https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1233988, wanted to fix the strange crash to ensure it's not involved somehow with the ap failures/maliit [15:01] Ubuntu bug 1233988 in platform-api (Ubuntu) "With Mir enabled: maliit-server crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,In progress] [15:01] asac: so no direct progress there yet [15:06] good mirning [15:06] alf_, I replied just now [15:18] racarr: mornin' [15:29] alf_: looking [15:31] alf_: platform-api change to detect whether connection is truly good seems a good idea [15:32] alf_: but I'd rather not confirm the exact semantics of the functions you're calling etc. [15:32] alf_: would someone else review this? then we can add this to landing plan [15:33] trying out new image :) [15:34] racarr: want to review https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378 ? :) [15:34] alf_, did you remove the anon namespace in the header file? :) [15:35] alf_: only somewhat happy :p [15:37] alf_: +1 [15:37] racarr: thanks [15:37] image seems really good === pete-woods-away is now known as pete-woods [15:37] I'd really like to fix the [15:37] screen unblank buffer [15:37] bla [15:38] actually now [15:38] tvoss: no, why? [15:38] any luck on unity8 crashers? :) [15:38] lol [15:38] asac: Autopilot you mean? [15:39] unity8 crashes [15:39] during autopilot its easy to reproduce yes [15:39] just run webbrowser AP [15:39] and it will crash [15:39] 5 out of 6 times [15:39] ok I guess I can work on autopilot failures today [15:40] alf_, an anonymous namespace in a header file is usually a bad idea [15:40] racarr: note that its not really autopilot failures... its just the best and easiest to reproduce crashers we have right now :) [15:40] we see loads of crashers that are hard to reproduce in QA [15:40] so we can start here and hopefully the world will improve :) [15:41] asac: :D [15:41] anyway. let me know ifyou need something [15:41] those are real crashers ... we dont start unity with special instrumentation flags or anythig [15:41] if we run application autopilots [15:42] thanks! [15:42] tvoss: sure, "why" == is it related to the 1233988 problem in some way? [15:43] alf_, nope [15:43] racarr: btw, keep in mind that running the tests one by one seems to work just fine, which give a hint to what the problem is... [15:43] tvoss: ok :) [15:44] alf_: you talk about webbrowser? [15:44] there are two things: [15:44] a) webbrowser tests fail and make unity super slow after they finish [15:44] racarr: didn't top approve? [15:44] b) webbrowser tests crash unity8 more or less relliably [15:44] asac: I...lost the bug that someone put autopilot instructions in. Is there a summary somewhere? [15:44] ah right, two reviews I guess [15:45] alf_: so once that's top approved ping me to get it in PPA for testing [15:45] lool: Hmm no someone could top approve I guess [15:45] racarr: https://wiki.ubuntu.com/Touch/Testing#Testing_your_Ubuntu_Touch_Code_before_submission [15:45] give that a shot [15:45] racarr: for running AP tests run 'phablet-click-test-setup' to download all the test cases [15:45] 'phablet-test-run '...e.g. unity8 [15:45] to run tests: [15:45] racarr: apt-get install webbrowser-app-autopilot, autopilot run [15:45] a) touch /userdata/.writable_image [15:45] alf_: dont do that [15:45] b) reboot [15:45] tvoss: Want to double sanity check the papi branch and top approve? [15:45] c) unlock screen [15:45] alf_: use the isntructions above [15:45] then run: [15:45] ./phablet-test-run -p webbrowser-app-autopilot webbrowser_app [15:46] or for unity8: [15:46] racarr, feel free [15:46] ./phablet-test-run -n -p unity8-autopilot unity8 [15:46] otherwise we will argue until we are blue about not seeing the same things [15:46] asac: why not? [15:46] alf_: use the phablet-test-run interface [15:46] alf_: doesnt matter... just strictly follow the instructionms [15:46] alf_: so that we all do the same thing [15:46] alf_: people dont get it right and do stuff to their device [15:46] *parsing* XD thanks all [15:46] and then claim the tests succeed and move on [15:46] make sure to reboot after the unity8 tests ... never run an app test after unity [15:47] and i have to argue for 2 days with them until they finally see that they didnt do it the same way [15:47] lool: please refer to these isntructions: https://wiki.ubuntu.com/Touch/Testing#Testing_your_Ubuntu_Touch_Code_before_submission [15:47] racarr: what do you need top approved ? [15:47] so we start consolidating it at one place [15:47] kgunn: https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378 I did it though [15:48] lool: can we get a CI run & landing on https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378 [15:49] kdub, ping [15:50] hello [15:50] Saviq: just to make sure we don't have people running round duplicating effort.... racarr is going to look into crashes associated with webbrowser AP tests [15:50] shout if someones already working [15:51] tvoss, going to try to shift waiting to the compositor side, should make unity wait less [15:51] kgunn: autolanding actually -- ci ran [15:51] kdub, sounds good, had the same idea. [15:51] tvoss, i'll let you know once i've tested it... just getting my phone all put together [15:51] kgunn: was waiting for the top approve :-) [15:51] kdub, I will grab a quick bite and be back after that [15:52] argh I don't see why this should give different results.. [15:52] lool: so we are back to normal everywhere ? (no more manual merges) [15:52] kgunn, tvoss, racarr, maliit loops on unity8 exit with https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1238107 [15:52] Ubuntu bug 1238107 in maliit-framework (Ubuntu) "maliit-server crashed with SIGSEGV in poll()" [Undecided,New] [15:52] kgunn: running [15:52] tvoss, I saw the copy_on_client DisplayConfiguration somewhere before [15:52] tvoss, today, that is [15:53] kgunn: Only on some projects; Francis sent a list; I dont know for yours, but you sometimes have to wait 15mn for a run, so pinging might still be useful when urgent [15:53] ack [15:53] asac: I've updated the AP instructions with my own additions for other testsuites and for Click instructions [15:53] Saviq, something went out of scope too early [15:54] Saviq, racarr the DisplayConfiguration is NULL [15:55] tvoss, I expect unity8 hanging at the same time to be very much related, correct? [15:55] Saviq: copy_on_client problem, essentially means that the connection to the server failed for some reason (no server, connection rejected), and platform-api wasn't handling this well, see https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-somewhat/+merge/190378 [15:55] alf_, yay, so that's fixed [15:55] alf_, I knew I saw that somewhere [15:55] Does mthis looks like [15:55] ... [15:55] what alf said [15:55] alf_, racarr yes, it does [15:55] the mutex is null which can only happen if the mirconnection pointer [15:56] yay, sorted [15:56] is invalid [15:56] Saviq, not entirely sure, could be [15:56] * Saviq pushes unity8's crash on exit [15:56] lool: yeah. all this know how should be somewhere in phablet-tools i believe [15:56] lool: would be great if phablet-test-run unity8-autopilot would just do the rigth thing [15:56] :) [15:57] Saviq: note, that's this only explains crashes for new connection attempts. If you see this for an existing connection then it's something else. [15:59] alf_, ah, that's on unity8 exit [15:59] alf_, so unity8 + maliit were connected, but unity8 was shutting down, pushed maliit over the edge into spinning, unity8 stuck [16:01] So what is expected to happen with the webbrowser ap tests? [16:01] I dont see a unity8 crash [16:02] but eventually the tests themselves crash... File "/usr/lib/python2.7/socket.py", line 303, in flush [16:02] self._sock.sendall(view[write_offset:write_offset+buffer_size]) [16:02] error: [Errno 32] Broken pipe [16:03] asac, ^ [16:03] though it seems like they are still running lol because stuff is still going on on my phone [16:03] racarr: what device are you on? [16:03] tvoss, that looks like a Qt bug https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1238116 [16:03] Ubuntu bug 1238116 in unity8 (Ubuntu) "unity8 crashed with SIGSEGV in QIcon::~QIcon()" [Undecided,New] [16:03] asac: mako [16:04] tvoss, unity8 crashes shutting down on Mir [16:04] Saviq, hang on [16:04] tvoss, hanging [16:04] racarr: so not sure. you might be struck by something flaki :) [16:04] lol [16:05] so sometimes MTP is funny and takes over adb and you disconnect [16:05] in those cases, just reboot and try again [16:05] it doesnt happen all of the times :) ... wait until you have MTP seen mounted i guess [16:05] mm [16:06] going to try unity8 next... [16:06] I have to run soon though, one more dental filling :( (they couldn't quit finish last time) [16:06] ill be back before too long though [16:06] alf_: I think your issues with this are addressed? https://code.launchpad.net/~robertcarr/mir/socket-messenger-race/+merge/187647 [16:09] tvoss: I tested adding a rm to unity8 upstart job; then unity8 crashed and when I used it again, the keyboard would show up when entering an input field, but its window would disappear each type I type letter [16:09] tvoss: so I think it was still using the old socket [16:10] lool, do you have both pre start and post stop? [16:12] Saviq, looking at it, need to debug [16:12] Saviq, what did you do? [16:12] Saviq, gut feeling tells me: qt [16:13] tvoss: no [16:13] tvoss: also didn't check whether maliit indeed restarted [16:13] tvoss, that's just unity8 exiting [16:13] tvoss: I'm running out of time for today [16:13] tvoss, 100% reproducible [16:13] got unity8 autopilot running at least. um [16:13] lool, sure, no problem ... got your current pushed to a branch? [16:13]