[05:38] <duflu> alf__: If you're hacking Mesa, probably best to check you really have the latest branch. I know anpok_ has made fixes to our Mesa patch still waiting for release
[05:39] <duflu> I assume its all in git somewhere and you guys know this, but just in case
[07:58] <alf__> duflu: Thanks, I will sync with anpok
[07:58] <duflu> alf__: In other news unity8 (for utopic at least) is much faster today
[07:58] <duflu> .. if you update fully
[08:05] <alf__> duflu: great, can't wait to try
[08:07] <duflu> The update is only in utopic though. Not rtm
[08:07] <alf__> duflu: not even rtm-proposed?
[08:09] <duflu> Not sure.
[08:23] <alan_g> dednick: would you re-review https://code.launchpad.net/~alan-griffiths/mir/fix-1377968/+merge/237287? Thanks
[09:18] <duflu> Why does consuming one frame per vsync yield 120FPS?
[09:18] <duflu> Who is consuming my frames?
[09:20] <anpok_> maybe that is your refresh rate?
[09:22] <duflu> anpok_: I wish
[09:24] <alan_g> Silly question #1: have you counted the number of times you consume on "vsync"?
[09:25] <dednick> alan_g: approved.
[09:25] <alan_g> dednick: thanks.
[15:21] <alan_g> kdub_: this work for you? https://code.launchpad.net/~alan-griffiths/mir/fix-libmircommon-symbols/+merge/237255
[15:21] <kdub_> alan_g, yep
[15:23] <alan_g> :)
[16:43] <qengho> Hey all. In the toolkit, what might cause  mir_connect_sync("/tmp/mir_socket", "appname")  to hang (for at least 10 seconds)?
[16:43] <qengho> MIR_SOCKET=/tmp/mir_socket mir_demo_client_multiwin   # works
[16:45] <alan_g> qengho: having the server stopped in the debugger?
[16:46] <qengho> alan_g: :)  Right. Anything else?  Only client has a debugger attached, sometimes, here.
[16:47] <qengho> ...and the other client works.
[16:47] <alan_g> what sever are you using?
[16:47] <alan_g> *server
[16:48] <qengho> mir_demo_server_basic
[16:49] <alan_g> you are running all clients from the same user?
[16:51] <qengho> alan_g: yes, same user.  Server is sudo-ed, and socket set to writable.  One mundane user used to run demo client and my own.
[16:51] <alan_g> That server doesn't care what the client is, so if there are differences then they are between the clients
[16:54] <alan_g> You could try setting the server  mir_connect_sync report and/or the msg-processor-report to log and see if the connect attempt is detected
[17:56] <racarr> greyback:
[17:56] <racarr> Err...whoops lol
[17:56] <racarr> greyback: Anyway....re: the extra build deps...Ithink they are either needed or we have to disable building qtmir-desktop on armhf
[17:56] <racarr> via other mechanisms...
[17:56] <racarr> was qtmir-desktop being built on armhf before?
[17:57] <racarr> it seems like it...
[17:59] <racarr> it looks like it was
[17:59] <racarr> I dont understand though
[17:59] <racarr> there is no opengl build dep
[17:59] <racarr> in lp:qtmir as it stands...
[17:59] <racarr> I also dont understand how mir uses a build dep on libgles-mesa but doesnt get
[17:59] <racarr> a runtime dep from ${shlib:Depends}
[17:59] <racarr> but
[17:59] <racarr> qtmir does whenaddingthe buld dep