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