[01:56] <robert_ancell> Has anything changed with how to run Mir demo servers? I'm running sudo mir_demo_server ; chown me.me /run/usr/1000/mir_socket ; mir_demo_client_basic -m /run/user/1000/mir_socket and getting "Failed to connect to server `/run/user/1000/mir_socket': No such file or directory"
[01:56] <robert_ancell> /run/usr/1000/mir_socket definitely exists
[01:57] <duflu> robert_ancell: Not that I'm aware of. Everything should work as before..
[01:57] <robert_ancell> duflu, any debugging tips?
[01:58] <robert_ancell> The client/server seem otherwise happy
[02:06] <robert_ancell> aha, strace suggest the failure is actually to open /usr/lib/x86_64-linux-gnu/mir/client-platform/
[02:09] <duflu> robert_ancell: Try installing mir-graphics-drivers-desktop
[02:10] <duflu> I think there's a bug for that but it's also arguably a feature
[02:10] <robert_ancell> duflu, yeah, I'm looking at the Mir code so see how the error text could be clearer
[02:10] <duflu> I agree, our lack of useful error messages is an issue. There are one or two bugs for that.
[02:10] <robert_ancell> The issue is there's more than one thing that might not exist, so the error text needs to be clear
[02:11] <robert_ancell> ugh, I give up trawling the frontend code. Bug it is.
[02:13] <duflu> robert_ancell: A new bug is fine. Although I remember it was logged recently somewhere and ended up being won't fix/can't fix because you can't automatically determine the best driver package to have installed. We do however have: https://bugs.launchpad.net/mir/+bug/1381398
[02:14] <robert_ancell> yeah, they're the server side messages.
[02:14] <robert_ancell> The client side should be easier to fix
[02:14] <robert_ancell> bug 1473268
[02:23] <duflu> robert_ancell: Wait, what?! If your server is already running you must have graphics drivers installed...
[02:23] <duflu> You must have installed a working mir-platform-* to get the server driver but be missing the client driver package
[02:24] <robert_ancell> duflu, I had mir-platform-graphics-mesa2 installed but not mir-client-platform-mesa2
[02:24] <duflu> robert_ancell: Yeah OK, no problem.
[02:24] <duflu> robert_ancell: At last discussion this was labelled "not an issue" as our desktop-next metapackage has the required deps
[02:24] <duflu> But we can do better
[02:25] <robert_ancell> It would be fine if the error message actually indicated the mismatch
[02:25] <duflu> robert_ancell: Totally agree. Should be a simple enhancement
[02:28] <duflu> robert_ancell: Also I have had thoughts that "driver" should be a single package, not separate client/server.
[02:28] <duflu> Even a single binary
[02:28] <robert_ancell> Yeah, it would be nicer to have one package though I guess there are potential small gains in splitting?
[02:29] <duflu> robert_ancell: We can keep two binaries and still have a single package. But also code reuse (and hence total system memory used) might be reduced by a single binary
[02:30] <duflu> -reuse +duplication
[02:35] <duflu> robert_ancell: Incidentally, this week I was focussing on "bugs that users can actually see"
[03:34] <robert_ancell> duflu, do you know of an issue running mir_demo_server on wily and it crashing when a client connects with "*** stack smashing detected ***"?
[03:36] <duflu> robert_ancell: I am aware of only one stack smashable issue. That is apparently fixed in 0.13.3 and later - https://bugs.launchpad.net/mir/+bug/1465883
[03:37] <duflu> robert_ancell: Obviously first check if it's the client rather than Mir doing the smashing
[03:37] <robert_ancell> the message is on the servers stderr
[03:37] <robert_ancell> ah, I have a 0.14.0 version of libmirprotobuf it seems
[03:38] <duflu> robert_ancell: From memory you need the fix in libmirclient and libmirserver packages (0.13.3 and later)
[03:38] <duflu> Not libmirprotobuf, despite that being closely related
[03:39] <robert_ancell> duflu, I downgraded and that fixed it, thanks!
[03:39] <robert_ancell> btw fingerpaint is fun with a 10 fingers :)
[03:39] <duflu> robert_ancell: That's a worry if 0.14 caused issues
[03:39] <duflu> Yay, fingerpaint
[03:40] <robert_ancell> Should libmirclient8 0.13.3+15.10.20150617-0ubuntu1 with with libmirprotobuf0 0.14.0+15.10.20150701-0ubuntu1?
[03:41] <duflu> robert_ancell: I think so. But there might be bugs we're not aware of
[03:42] <duflu> If you can install them simultaneously then that's theoretically a supported combination. But not a guarantee that they will talk to each other (you might have multiple versions of a package installed too)
[04:18] <robert_ancell> RAOF, with DRI3 do you create a Pixmap then use DRI3BufferFromPixmap or do you create the buffer using some direct call to the driver and then use DRI3PixmapFromBuffer?
[04:27] <duflu> robert_ancell: He's on holiday for a week now
[04:27] <robert_ancell> ah
[04:27] <duflu> Although reading email on the go
[04:27] <duflu> sometimes
[10:02] <UukGoblin> hi :-)
[10:02] <UukGoblin> is there a way to run applications written for X11 under Mir?
[10:21] <anpok_> yes
[10:21] <anpok_> in wily the new package is called xmir .. on vivid it was xserver-xorg-xmir
[10:22] <anpok_> you bascially launch xmir with -mirSocket /path-to-your-mir-socket/ (i.e. /run/3201/mir_socket) and assign a display id and launch the x-application with that DISPLAY
[10:23] <anpok_> UukGoblin: depending on the mir shell in use you might need additional steps.. I believe for unity8 you need to append a --desktop-file-hint <path-to-a-desktop-file> if in doubt ask in #ubuntu-unity
[11:08] <UukGoblin> cool, thanks :-)
[16:22] <kgunn> alf_: i'm assumign the system setting for "lock screen timout" does not alter or change the dimming timer?
[16:22] <kgunn> (it's currently conflating lock with screen blank i think)
[16:23] <kgunn> so for 1 minute.... 50 bright, 10 sec dim
[16:23] <alf_> kgunn: the dimming timout is set to power-off timout - 10s
[16:23] <kgunn> ah...so fixed
[16:24] <alf_> kgunn: (by other components, we are not forcing it, our API is set_timeouts(dim, poweroff)
[16:26] <kgunn> alf_: for your ques 6 i think scenario 1 makes the most sense to me at least
[16:34] <alf_> kgunn: note: there was mistake in the description of (6) (fixed now), the initial trigger is a power key event
[16:34] <kgunn> sure
[19:54]  * kdub figures out how to tease apart BufferQueue
[20:05] <camako> \o/