[00:02] robert_ancell: Yo! [00:02] RAOF, howdy [00:03] RAOF, regarding bug 1583624, do you know why a Mir session would be attempting to work out what VT it is on? [00:03] bug 1583624 in Light Display Manager "Mir cannot open a tty when started by lightdm" [Undecided,Incomplete] https://launchpad.net/bugs/1583624 [00:05] Hm. Because for some reason it's trying to run on bare KMS. [00:05] Is unity8 being passed the --host-socket option? [00:06] RAOF, not by LightDM [00:06] Well, something should be. [00:06] That was my guess, some change has made it think it's no longer running under u-s-c [00:07] Something needs to tell the greeter's Mir to connect to usc rather than try to drive the hardware. [00:07] LightDM sets MIR_SOCKET - is that no longer sufficient? [00:08] I don't think that was ever sufficient? [00:08] That's how Unity 8 sessions work... [00:09] LightDM picks a socket name, starts U-S-C with that then runs the sessions with MIR_SOCKET set (the greeter is just a special case of a session). [00:11] robert_ancell: Hah. https://bugs.launchpad.net/bugs/1290345 [00:11] Launchpad bug 1290345 in Mir "The server-side use of $MIR_SOCKET is confusing" [Medium,Fix released] [00:12] So, Mir 0.21 changed the behaviour to require MIR_SERVER_HOST_SOCKET (or, equivalently, passing --host-socket=). [00:13] That looks like it [00:14] So, I'm still confused. A Mir client reads MIR_SERVER_HOST_SOCKET for the parent Mir server to connect to? [00:15] And MIR_SOCKET is the "socket you should open for your children to connect to" [00:15] No; a Mir client (which uses mir_connect_sync(nullptr)) reads MIR_SOCKET. [00:16] But a shell (which is a Mir client in this case) reads MIR_SERVER_HOST_SOCKET? [00:16] For a Mir *server* it checks if MIR_SERVER_HOST_SOCKET is set (or, equivalently, --host-socket), and if so uses that host to nest under. [00:16] So it sounds like I just need to replace MIR_SOCKET with MIR_SERVER_HOST_SOCKET and it should still work. [00:17] I will however need to keep setting MIR_SOCKET for backwards compatibility [00:17] Yes. [00:17] Yay for API stability ;) [00:19] Of course, there's a good chance this will change again in the not-too-distant future :) [00:19] ahahahahah. *sigh* [00:19] RAOF, that change in 0.21 was just to remove the backwards compatibility right? [00:19] Yes. [00:20] Do you happen to know when the behaviour changed? I might just not bother keeping LightDM backwards compatible because it's too hard with Mir and practically it probably wont matter. [00:20] Hm, actually, I think that MIR_SERVER_HOST_SOCKET has *always* been the correct thing to do. [00:20] And we just automatically set MIR_SERVER_HOST_SOCKET if we found MIR_SOCKET was set. [00:21] So, just set MIR_SERVER_HOST_SOCKET, and I'll tell you if the nested-platform-becomes-an-actual-platform rework changes things :) [08:36] greyback: it finished compiling :D [08:44] tsdgeos: yay! [08:46] ltinkl: are you going to do https://code.launchpad.net/~aacid/unity8/fix_qinputdeviceinfo_leaks/+merge/295799 too or want lpotter to? [08:46] tsdgeos, yeah, I'd prefer someone else more knowledgeable of the code (lpotter or mzanetti) [08:46] oki [08:47] lpotter: if you're still around can you have a look at it? ↑ [08:50] ltinkl: how do you feel about https://code.launchpad.net/~aacid/unity8/fix_uninitialized_use/+merge/295805 ? [08:52] tsdgeos, the first 2 are obvious, the 3rd one... need some context, sec :) [14:05] tsdgeos, in silo 59, is there anything that would cause the CardTool tests to be slow? [14:05] yes [14:05] maybe [14:05] :D [14:05] i mean there was a branch that made things slower [14:05] but i thought i had fixed cardTool to be fast again [14:05] tsdgeos, we failed autopkg tests because qmluitests timed out. And running them manually, it seems slow [14:05] maybe i only made it on card [14:06] * tsdgeos tries to remember the name of the branch [14:06] E_TOO_MANY_BRANCHES [14:07] yes https://code.launchpad.net/~aacid/unity8/make_dash_test_more_stable/+merge/294127 [14:07] probably needs the same fix of tst_card on test_cardtool [14:07] let me have a look [14:09] there's only one such construct in cardTool [14:09] mterry: is it noticeably slower than trunk [14:09] ? [14:09] tsdgeos, I will test... but first I wanted to let the current run finish... it's been a long time. like 20 min at least [14:10] locally? [14:10] tsdgeos, yeah [14:10] that's bad :D [14:10] tsdgeos, lp:~ci-train-bot/unity8/unity8-ubuntu-yakkety-landing-059 for testing [14:16] tsdgeos, aha, the test finished :) [14:19] yeah it's another of those goddam parentless findChild [14:20] let me go over the test that have those and make sure they didn't get slow too [14:41] mterry: ok, pushed to the branch, should be better now [14:41] tsdgeos, oh thanks! [14:41] * mterry will rebuild