[12:44] <alan_g> dednick: this might well affect you - https://code.launchpad.net/~alan-griffiths/miral/fix-initialization-order/+merge/318353 (I can't see how this ever worked)
[16:45] <tjaalton> bregma: hi, I still need this patch to build the xserver, maybe you have glamor disabled on your build? http://pastebin.com/YpDyBkqP
[16:48] <bregma> tjaalton, I just slap my refreshed patch into your git packaging branch and submit to a zesty pbuilder to build, but I don't believe I have -proposed in my pbuilder environment, maybe that's the difference?
[16:49] <tjaalton> bregma: no that's not required
[16:50] <tjaalton> ah
[16:50] <tjaalton> well
[16:50] <tjaalton> if you use the packaging branch then you get this patch :)
[16:50] <tjaalton> but it doesn't build without
[16:51] <tjaalton> "xmir-fixes.diff"
[16:58] <bregma> tjaalton, I can import that patch upstream if you prefer
[17:03] <tjaalton> bregma: yep, please
[17:04] <tjaalton> had it separate since 1.18 :)
[17:09] <bregma> tjaalton, OK, give me a little while to verify
[17:11] <tjaalton> you can check with the packaging branch, it's uptodate now
[17:45] <mterry> Hello!  Can I get some help with some odd unity8/mir behavior I'm seeing that's interrupting some snappy work?  Let me lay out scenario...
[17:45] <mterry> I'm trying to make the unity8 snap use the mir-libs snap
[17:45] <mterry> And so I'm pointing it at the server-platform bits there
[17:46] <mterry> But Mir is trying to load library from system...
[17:46] <mterry> Here's a pastebin where I've printed out each dlopen as we intercept it in some ld-preload trickery we have
[17:46] <mterry> http://pastebin.ubuntu.com/24079316/
[17:46] <mterry> AlbertA: ^ ?
[17:46] <mterry> You can see it finds the server platform in mir-libs
[17:47] <mterry> But later on it tries to load from system, gets shunted into snap by our ld-preload hacks, and then isn't found
[17:48] <mterry> It's loading the client platform just fine thoug
[17:50] <alan_g> mterry: that sounds like something that Saviq was asking about. So: you're trying to connect to a host server (USC) that's using drivers from system?
[17:50] <mterry> alan_g: yes -- and that is a ticking time bomb, but I would expect it to work in this case, where the versions match
[17:50] <Saviq> bug #1665123
[17:51] <alan_g> mterry: agreed, this isn't a supported scenario.
[17:52] <Saviq> mterry, is /snap/unity8-session/x7/usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-mesa-kms.so.12 there? should it be there?
[17:52] <mterry> Saviq: it's not there in this testing snap I'm making where I'm trying to use mir-libs instead
[17:52] <mterry> Saviq: I had thought that bug was just about version mismatch, but now I see it dives deeper
[17:53] <mterry> alan_g: ... well Mir team won't support a snap that doesn't use mir-libs.  But now the Mir team won't support a unity8 that does?
[17:54] <alan_g> mterry: there are *a lot* of unanswered questions about how we can support Mir on snaps.
[17:55] <Saviq> mterry, MIR_SERVER_PLATFORM_PATH doesn't help?
[17:55] <alan_g> So: Mir team can't support snaps (yet)
[17:55] <alan_g> Saviq: no
[17:55] <mterry> alan_g: understood...  but but we've had several meetings where the Mir team said mir-libs was the answer
[17:55] <mterry> Sounds like the guidance is that the Personal team is blocked on Mir team
[17:55] <alan_g> mterry: Mir team says "both server and client should use mir-libs" - but that's not what USC is doing.
[17:56] <mterry> I mean, not *blocked* blocked.  We can run something on the screen, I'll just stop using mir-libs
[17:57] <mterry> alan_g: there was talk of Mir team providing an implicit :mir-libs interface on Ubuntu 16.04 that pointed at USC libraries to solve this
[17:57] <Saviq> yeah, we need more meets like that, it doesn't seem to be the answer AFAICT... there's just too much ABI dependencies there still
[17:57] <mterry> alan_g: that way same guidance (use mir-libs interface) would work in all places
[17:57] <mterry> But I had hoped in mean time, we could use it as long as versions matched
[17:57] <mterry> Sounds like I'll avoid it for now until it works better
[17:58] <alan_g> mterry: well... I don't think nesting will work that way either.
[17:58] <alan_g> We have plans that resolve a lot of these issues. But not in the 0.26 series.
[17:59]  * alan_g knows that doesn't help you now
[18:00] <mterry> Yeah, this is disappointing after fighting with the Mir team to avoid the long-term problems of mir-libs, but settling on it because it was the only solution that seemed to work in short term.  But now it doesn't even help with the short term problems.  So...
[18:01] <alan_g> mterry: the way we get nested working is https://trello.com/c/TzcWYzxM/498-remove-guest-platforms
[18:01] <mterry> I don't have access to that, but no biggie, understood there's work in progress
[18:02] <mterry> Hopefully mir-libs will eventually solve our middle-term problems
[18:03] <alan_g> IMO it is the least painful option, but far from ideal.
[18:03] <alan_g> And not pain free
[18:09] <AlbertA> mterry: so this is unity8 snap on top of classic?
[18:09] <AlbertA> with usc started by classic?
[18:10] <mterry> AlbertA: unity8 snap on top of 16.04 yes, with deb-based USC
[18:10] <mterry> i.e. the only currently supported way to run unity8 snap
[18:12] <mterry> Hmm, I can use a symlink trick to solve this in short term...
[18:13] <AlbertA> mterry: so, isn't this the issue in your particular example?
[18:13] <AlbertA> "MIKE dlopen /usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-mesa-kms.so.12 -> /snap/unity8-session/x7/usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-mesa-kms.so.12"
[18:14] <AlbertA> maybe the shim preload should redirect mir libs as well...
[18:14] <mterry> AlbertA: yeah I'll just set up a symlink in our snap to point at mir-libs version -- that can get us working in short temr
[18:14] <AlbertA> right
[18:14] <mterry> AlbertA: symlink will do same.  I'd prefer to avoid adding more code to our preload
[18:14] <mterry> Trying to drop that hack  :)
[18:14] <AlbertA> mterry: yep
[18:39] <bregma> tjaalton, merged in that patch, build-tested and verified on zesty
[18:40] <tjaalton> bregma: great, thanks