[07:26] -GitHub[m]:#mir-server- **[MirServer/mir]** RAOF removed no-merge from [pull request #2645](https://github.com/MirServer/mir/pull/2645): platform/buffer_from_wl_shm: Handle clients immediately destroying the buffer
[08:21] <Saviq> 'ullo
[09:11] <Saviq> Looking at the state of Wine on Wayland, I think I'm just going to go through XWayland for this as a first approach
[09:16] <Saviq> Just not sure yet what to do with extensions: [gnome-3-28], doubt there's that much that Wine requires of GTK
[09:26] <Saviq> alan_g re: the inotify race, so it got created but didn't get the right permissions yet? I wonder if we should just go with a `timeout 60 sh -c "until [ -O "$SOCKET" ]; do sleep 1; done"`… the inotify approach has bit us enough times and we're really not wasting much resources there…
[09:27] <Saviq> Otherwise a `[ -e "$1" ] ||` before the inotifywait, but that could lead to a tight loop if the socket never becomes readable
[09:28] <Saviq> And IMO we should not wait indefinitely, ever. Let systemd do its thing.
[09:37] <alan_g[m]> I suspect Wine will work with just the pixbuf stuff setup
[09:38] <Saviq> alan_g[m]: Yeah I'll start from ~merging the GTK3-mastermind and the x11 examples and see if I can strip it down
[09:39] <alan_g[m]> I don't think we should be spin-waiting on the wayland socket in the normal course of things. We don't need processes continually waking to sleep
[09:40] <alan_g[m]> I need to check how libwayland-client reacts if the socket exists but can't (yet) be opened
[09:41] <alan_g[m]> Changing the loop condition to -e would be a simple fix
[09:41] <Saviq> Well, sure. But for the daemon, systemd has a way to handle that, I almost think we should exit with error after some time trying to open the socket, and let systemd restart if it thinks it right
[09:42] <Saviq> We always thought of socket activation, that would be ideal, really.
[09:42] <alan_g[m]> It would. But somebody needs to make that a thing
[15:32] <Saviq> alan_g so in the X11 example, couldn't we do without the nested Mir server?
[15:33] <alan_g[m]> That's what provides window management
[15:34] <Saviq> ACK, OK
[15:37] <alan_g[m]> I did that as an improvement over prior art (manually setting up Xwayland and configuring matchbox based on the X-props of the application)
[15:38] <Saviq> Yeah got it, better this way.
[18:12] <Saviq> G'night o/