[01:05] Hm. [01:05] Is the_global_event_sink really unused?L [02:36] * RAOF once again wishes for a pervasive signals/slots mechanism in Mir. === chihchun_afk is now known as chihchun === duflu_ is now known as duflu === c74d is now known as c74d3a4 === c74d3a4 is now known as c74d === mibofra is now known as Guest75658 [06:32] RAOF: hm signal and slot with an explicit mentioning of the dispatcher the caller will be executed with === tvoss|afk is now known as tvoss [06:35] anpok_, easiest if the respective connection maintains the dispatcher [06:42] I guess you could add the latter :) === chihchun is now known as chihchun_afk [07:38] duflu: Why did you push the revert in r2759? [07:39] RAOF: Because it removed the bit that actually detected the regression. Also I have a much smaller and simpler solution (now proposed) [07:39] The test you reverted does indeed catch the regression. [07:39] It tested that the regression behaviour did not occur. [07:40] RAOF: OK, well if you found a new way to detect it, I'm sorry. Although you did the same to me. Objectively though, a better version is now proposed === chihchun_afk is now known as chihchun [07:40] I proposed my solution in your merge proposal. [07:40] My test was also written when the bug still existed and failed prior to it being fixed. So I assume that's what you mean too [07:41] Right. I tested my test by reverting your fix, and it does indeed fail. [07:41] I disagree that your test is better; doesn't your test deadlock on failure? [07:41] RAOF: No..? [07:41] Oh it might have hung [07:42] * RAOF will also note that my version of the test went in after 3 approvals + CI. [07:42] Right. [07:42] My version fails rather than hanging :) [07:42] RAOF: Mine also got reviewed :) [07:42] Your revert? [07:43] RAOF: Yes, the version I reverted to was approved. [07:43] No need to argue. Not important. I'll redo it [07:43] hm alan_g i tried you gcc-5 fix branch.. [07:44] demo server is working .. not sure why every attempt to start a server fails on ci [07:44] hey there [07:44] anpok_: yes? [07:44] what's the status of the new mir stucked in proposed in wily? [07:44] seb128: there was one obvious abi bump missing [07:45] seb128: but it did not fis the issue.. so I also bumped the server graphics platform abi [07:45] anpok_: nor I (yet) - I'm going to try reproducing [07:45] s/fis/fix [07:45] so it's fix commited now? more rebuilds needed? [07:45] let me know if you need with uploads or such [07:45] seb128: rebuilding silo 4 now.. I walso wanted to include a gcc-5 fix [07:46] but there is an odd ci failure.. [07:46] k [07:46] which one? [07:46] the test runner fails to start mirserver - https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/5979/console [07:47] k, no idea about that ... [07:49] anpok_: If you don't need to, please keep out gcc-5 support. There's always risk [07:49] And this late in the game we don't need more [07:50] anpok_: please don't add anything that isn't needed. There will be another release along soon [08:00] RAOF: Sorry, your test is restored [08:01] duflu: Ta. I was mostly just surprised to see the revert without MP. [08:01] anpok_: From a first look at the failure I suspect that loading (and rejecting) the 0.13 platforms in a g++-5 build drags in a second copy of boost RTTI, You shouldn't delay 0.14 on getting that resolved. [08:01] RAOF: It happens. Nobody yet has uncleanly reverted something. We're pretty good at it [08:02] Also, we have "append-only" set. So "uncommit" is disallowed, for our own protection [08:03] alan_g: I think the head of lp:mir/0.14 (from a few minutes ago) might fix your issue [08:04] ci is using vivid+o makos or wily makos? [08:04] anpok_: V+O [08:05] It shouldn't matter if your ABIs are right, should it? [08:05] -> whats the right solution for that failure: https://ci-train.ubuntu.com/job/ubuntu-landing-004-1-build/275/console [08:06] anpok_: Merge lp:mir/ubuntu back to lp:mir/0.14? [08:06] but there is no changelog entry yet [08:06] Ah, that old problem [08:06] anpok_: Then download it :) [08:06] and add it to mir/0.14 and add another one? [08:07] anpok_: Yep.... https://launchpad.net/ubuntu/+source/mir [08:07] Distro needs a continuous timeline. You shouldn't pretend the first attempt didn't happen [08:13] Debs are messy. Can we have something new now? [08:13] :) [08:15] Urgh! What the hell is happening here: http://s-jenkins.ubuntu-ci:8080/job/mir-clang-ts-wily-amd64-build/69/console ? [08:16] VPN says no [08:16] I can't reproduce that locally; *my* threadsanitiser make test works. [08:17] tsan with clang presumably? [08:17] Indeed. [08:17] Or is the "clang" a misnomer in the task? [08:18] Also.. for some value of "wily" [08:18] Well, my wily is up to date as of today; the builder should be too (as it's pulling from the archive) [08:18] For some value of "today" [08:19] :) [08:20] I suspect that it's got to do with the fork() involved in the death-tests. [08:21] Because at least one of the failures is talking about the main thread of ClientLibraryErrorsDeathTest_createing_surface_on_garbage_connection_is_fatal racing with the RPC thread created by ApplicationNotRespondingDetection_responding_client_is_not_marked_as_unresponsive === chihchun is now known as chihchun_afk [08:22] (And now that typo has crossed my threshold of annoyance ☺) === chihchun_afk is now known as chihchun [09:01] anpok_: You're familiar with the vagaries of ThreadSanitizer, right? [09:02] not really [09:03] I even fail to look up vagaries in the dictionary [09:04] :) [09:16] RAOF: but you can try treating me like a rubber duck - whats wrong? [09:18] ThreadSanitiser complains about an RPC thread started from ApplicationNotResponding's acceptance test racing with mir_connect_sync from ClientLibraryErrorsDeathTest. [09:20] From a heap block allocated from the ANRDetection test. [09:20] And the ANR detection tests start after the ClientLibraryErrorsDeathTests have already finished. === chihchun is now known as chihchun_afk [09:21] So I'm suspicious that the problem is actually that the fork() in the death tests is confusing ThreadSanitizer. === chihchun_afk is now known as chihchun [09:37] anpok_: alf_ hangout? [09:38] alan_g: coming [09:39] now === alan_g is now known as alan_g|lunch === chihchun is now known as chihchun_afk === alan_g|lunch is now known as alan_g === Guest75658 is now known as mibofra [12:53] RAOF, poke about subscribing mir-team to abi-compliance-checker === chihchun_afk is now known as chihchun [13:03] mterry: Subscribed as of a couple of hours ago. [13:04] * mterry hugs RAOF [13:04] Sorry about the delay. [13:04] * RAOF was on holiday last week, too. === chihchun is now known as chihchun_afk [14:45] camako: with mir-on-x I ought to be able to see clients in a desktop window. Right? [14:47] alan_g: the server in a x-window [14:48] I see an X window (and titlebars painted in the server) but nothing from the client [14:48] alan_g, is it an intel gpu? [14:49] camako: yes [14:49] alan_g, try a non egl client [14:49] intel's gpu has support problems for the extension I am using [14:49] for egl clients only though [14:49] camako: Ah! multiwin works [14:50] \o/ [14:50] alan_g, egl clients work but do not render.. you can try eglplasma and hit 'q'.. it'll quit fine. [14:51] Confirmed [14:52] Is mouse input supposed to work? [14:55] nah, it is unity8 ... its all gestures (you need to know the secret handshake to log in) :) [14:57] alan_g: no, mouse is not supported yet [15:29] Morning! [16:10] racarr: o/ [16:13] kgunn: Howdy :) === alan_g is now known as alan_g|EOD [17:39] kdub: Can you rereview client-specifie-dinput-regions when you get a chance I had to repropose it with a dependency [17:39] (symbols.map stuff) [17:39] no code changes [17:39] sure [17:43] kdub: Same thing for relative-pointer-events...had to resubmit without prereq :) [17:43] thanks === mibofra is now known as Guest63318 === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss === Guest63318 is now known as mibofra === chihchun_afk is now known as chihchun