[10:41] <anpok_> alan_g: hm if we copy the wrapper instead of linking it the gdb symptoms would be gone
[10:43] <alan_g> anpok_: I don't understand
[10:45] <alan_g> alf_: small update, still happy? https://code.launchpad.net/~alan-griffiths/mir/improved-Rectangles/+merge/247161
[10:46] <anpok_> hm we talked about the wrapper causing troubles.. i.e. with gdb.. hmm on monday?
[10:48] <alf_> alan_g: looks good
[10:49] <alan_g> anpok_: surely the wrapper needs to be linked to execute
[10:50] <anpok_> i mean that gdb does not cope with mir_what_ever beging a symbolic link to ./wrapper
[10:50] <anpok_> when you try to restart for example..
[11:04]  * alan_g understands now
[11:30] <alan_g> anpok_: alf_ either of you want to review this (otherwise I'll TA) https://code.launchpad.net/~albaguirre/mir/dialogs_and_tooltips/+merge/246655
[11:32] <alf_> alan_g: feel free to TA
[11:34] <alan_g> done
[13:58] <alf_> kdub: Hi! I was looking into mir_native_buffer.h and noticed we have a special case there for Android. Can we remove that special case by making Android serialize its data into a BufferPackage ?
[13:58] <alf_> kdub: (background: I am working on making the Mir core more platform agnostic)
[14:00] <kdub> alf_, which is the android-specific part?
[14:01] <alf_> kdub: #ifdef ANDROID typedef struct ANativeWindowBuffer MirNativeBuffer;
[14:03] <kdub> alf_, ah, yes, well I dunno
[14:04] <kdub> I mean, I guess we can convert ANativeWindowBuffer to a MirBufferPackage, but its tricky, mostly because ANativeWindowBuffer has a refcounting system
[14:08] <kdub> alf_, remembering a bit more... for android, we're given a native window interface, for mesa, we had to define one ourselves
[14:09] <kdub> like, the only place I see that struct needed is in the client API is in common/mir_toolkit/mesa/native_display.h
[14:09] <alf_> kdub: which struct are you referring to?
[14:10] <kdub> MirBufferPackage
[14:10] <alf_> kdub: (btw, a branch that's up for review move mesa/native_display.h out of common/)
[14:11]  * kdub will look
[14:11] <kdub> okay, that branch seems a good idea
[14:12] <kdub> (lp:~afrantzis/mir/remove-mesa-specific-code-from-mircommon)
[14:13] <kdub> and it makes sense to me that MirBufferPackage ends up in mir-client-platform-mesa-dev
[14:14] <alf_> kdub: I see MirBufferPackage used throughout the client code (MirSurface, ClientBufferDepository etc)
[14:14] <kdub> alf_, right, it was mostly for convenience
[14:15] <kdub> because, MirBufferPackage is the analogue to ANativeWindowBuffer
[14:16] <kdub> so, I see a distinction in that MirBufferPackage is something we have to define for the mesa eglNativeWindow
[14:16] <kdub> and its also what we happen to be using internally from convenience
[14:17] <alf_> kdub: Wasn't the point that MirBufferPackage would be a platform-independent container of buffer information interchange between server and client?
[14:17] <alf_> kdub: the platform independent parts being the data[] and fd[] arrays
[14:18] <alf_> kdub: which only the client/server platforms would know how to read
[14:21] <kdub> alf_, I suppose, but I've always thought of MirBufferPackage as more of the mesa-analogue to ANativeWindowBuffer
[14:23]  * kdub rethinks from the perspective that MirBufferPackage is the platform-agnostic type, and mesa eglnative types just happen to use it 
[14:25] <kdub> I guess though that means that the mir_native_buffer.h header should be shipped in that new mesa package, but be used internally in the server code
[14:29] <kdub> and... coming back to the original question :) I think serializing it for the purposes of the client code is okay for now
[14:30] <kdub> with the caveat that, mir_surface_get_current_buffer() is a public mesa-specific function I guess
[14:31] <alf_> kdub: I wonder if this could be changed to be a "platform operation" instead.
[14:32] <kdub> yeah, that would be good
[14:32] <kdub> and then getting the buffer for the mesa egl would just be a platform operation