[09:31] <alan_g> alf_: is this right? https://code.launchpad.net/~alan-griffiths/mir/suppress-tests-for-armhf/+merge/204620
[09:32] <alf_> alan_g: looks good
[09:33] <alan_g> alf_: thanks
[09:35] <alf_> alan_g: perhaps, though, we should apply this to devel first and merge that?
[09:35] <alf_> alan_g: too late, doesn't matter :)
[09:36] <alan_g> alf_: I'd rather do a reverse merge after the trunk gets tagged
[09:36] <alf_> alan_g: ok
[09:37]  * alan_g thinks we should not be landing two months changes in one lump (but who listens?)
[09:42] <alan_g> didrocks: I trust your changelog concerns are addressed? https://code.launchpad.net/~mir-team/mir/trunk-0.1.4/+merge/201707
[10:04] <didrocks> alan_g: swimming over the diff, it looks good to me
[10:06] <alan_g> didrocks: surely a 32k diff is no cause for concern. ;^/
[10:07] <didrocks> alan_g: well, that's your process, if things can't land, we are going to revert your 32k of diff
[10:07] <didrocks> you pick your risk
[10:08] <alan_g> didrocks: kgunn already made that decision.
[10:08] <didrocks> yeah, so no need to argue on that more :)
[10:10] <alan_g> Is it ok to top-approve now? (Or are there other steps needed in the latest process?)
[10:10] <didrocks> alan_g: kgunn is the lander, he will handle that, so no top-approve (well, top-approve won't do anything anyway)
[10:11]  * alan_g washes hands
[12:11] <alf_> alan_g: have you tried cross compiling recently?
[12:11] <alan_g> alf_: can you suggest a cleaner approach to https://code.launchpad.net/~alan-griffiths/mir/refactoring-so-SwitchingBundle-can-control-completion-of-client_acquire/+merge/204244
[12:12] <alan_g> alf_: no - can to though
[12:12] <alan_g> *do
[12:12] <alan_g> (Was probably friday I did it last)
[12:13] <alf_> alan_g: I am getting http://paste.ubuntu.com/6872683/
[12:15] <alan_g> Tried zapping the "partial chroot"?
[12:16] <alf_> alan_g: no, just the build dir (while updating the chroot), will try from scratch
[12:16] <alan_g> Hmm " #error This file was generated by an older version of protoc which is"...
[12:18] <alf_> alan_g: you need to update the host protobuf libraries and protobuf-compiler package
[12:18] <alan_g> alf_: ack
[12:21] <alf_> alan_g: @switching bundle, I like the proposed approach, perhaps with the change that Kevin proposed to swap_client_buffers()
[12:22] <alf_> alan_g: i.e., returning the buffer in the callback
[12:24] <alan_g> thanks. Was thinking along those lines - but not feeling convinced it was the best of all possible solutions
[12:26]  * alan_g isn't convinced by the name "submit_produced_buffer_and_notify_on_available_buffer" though
[12:28] <alf_> alan_g: the other approach is to move to a push model for surface buffers, but that's more radical and needs further discussion
[12:29] <alan_g> alf_: quite
[12:29] <alan_g> BBL
[12:29] <alf_> alan_g: cross-build ok from scratch, thanks
[13:51] <dandrader> alan_g, trying to make unity8 do custom RPC over mir_socket, following test_protobuf.cpp example
[13:52] <alan_g> dandrader: yes?
[13:52] <dandrader> alan_g, I need to include mir/frontend/template_protobuf_message_processor.h
[13:52] <dandrader> alan_g, but that header, on its part, includes mir_protobuf_wire.pb.h
[13:52] <dandrader> alan_g, which is not exported by mir
[13:54] <alan_g> dandrader: you're right. That needs to be fixed.
[13:54] <alan_g> Want to log a bug? I'll get to it today
[13:54] <dandrader> alan_g, sure
[13:59] <alan_g> thanks
[14:01] <dandrader> alan_g, https://bugs.launchpad.net/mir/+bug/1276162
[15:46] <alf_> mlankhorst: Hi! I think I have found a bug in Mesa, could you take a look?
[15:46] <mlankhorst> I guess
[15:49] <alf_> mlankhorst: So, the problem is that when unbinding a context, the driver unbind function is not called when there are no bound surfaces, but this break when we have a surfaceless context
[15:50] <mlankhorst> is this a bug in gallium only or is i915 affected?
[15:51] <alf_> mlankhorst: it's in dri_utils, a tentative fix is http://paste.ubuntu.com/6873664/ . Just that look plausible?
[15:52] <alf_> s/Just/Does/
[15:54] <mlankhorst> I really can't say
[15:55] <alf_> mlankhorst: np, thanks
[15:55] <mlankhorst> it seems like it's not called on purpose there
[15:57] <mlankhorst> so I don't know, put it on the mesa-dev list I guess
[15:57] <mlankhorst> or write a test
[15:58] <alf_> mlankhorst: will do thanks
[16:02] <Saviq> kdub, hey, could you maybe answer asac's question in "Landing team 31.01.2014" on ubuntu-phone ("How can we ensure that display is ready before trying to start?")?
[16:02] <kdub> Saviq, i'll take a look
[16:02] <Saviq> kdub, thanks
[17:12] <dandrader> alan_g, so mir wire protocol has no concept of services. only functions, right?
[17:12] <alan_g> dandrader: correct
[17:12] <dandrader> alan_g, meaning that you can map a wire protocol function to any protobuf service you like, right?
[17:12] <alan_g> dandrader: correct
[17:13] <dandrader> ok
[17:16] <kdub> was there a problem with protobuf?
[17:20] <alan_g> kdub: bug 1276162
[17:22] <kdub> alan_g, what i'm seeing looks more like a version mismatch of protobuf on my setup
[17:22] <kdub> upgrading everything and hopefully that works
[17:23] <alan_g> kdub: yeah, theny just pushed protobuf8 in
[17:23] <alan_g> &they
[17:24] <alan_g> Sorry, thought you were joining the conversation, not starting a new one
[17:30] <kdub> alan_g, np, upgrading things seemed to fix what i was seeing
[17:36] <alan_g> kdub: is this to your liking now? https://code.launchpad.net/~alan-griffiths/mir/refactoring-so-SwitchingBundle-can-control-completion-of-client_acquire/+merge/204244
[17:37] <kdub> looking
[18:00] <alan_g> kdub: thanks
[23:17] <ali1234> i just read about SDL Mir backend
[23:17] <ali1234> don't most 3D games use GLX? how does that work then?
[23:20] <bschaefer> ali1234, when it comes to a game that uses GLX, the mir video backend returns an opengl context (through egl) which allows most games to work
[23:20] <ali1234> i'm a game developer... how will i know if my game can work this way?
[23:20] <bschaefer> i've tested this out in SDL 1.2 (which I have a branch for)
[23:20] <ali1234> i use SDL2 and ogre3d
[23:20] <bschaefer> then things should just work :)
[23:21] <bschaefer> to test, you would have to set up the mir server
[23:21] <ali1234> i compile my own version of ogre and sdl...
[23:21] <bschaefer> and run it on it directly
[23:21] <bschaefer> i've not tested ogre out but if it depends on X11 it will not work
[23:22] <bschaefer> depends on it directly
[23:22] <ali1234> well it depends on it for building
[23:22] <ali1234> but i use SDL to open a window and get a GL context
[23:22] <bschaefer> the GL context you get from SDL (if you are running it through mir) will be opengl
[23:23] <bschaefer> ali1234, ive gotten games such as extremetuxracer
[23:23] <bschaefer> working through mir
[23:23] <bschaefer> (only in sdl 1.2, which is not patched for mir, but my own branch)
[23:23] <bschaefer> which depends on  |Depends: libgl1-mesa-glx
[23:24] <bschaefer> so I would assume any games written in SDL2, should work with the same dependencies
[23:26] <ali1234> i literally just open a window with SDL2 and then tell ogre to render into it... there is zero X11 specific code in my stuff, which also runs on windows
[23:26] <bschaefer> the problem i see though, is ogre has a hard depend on :   Depends: libx11-6
[23:26] <ali1234> yes
[23:26] <bschaefer> at lease im seeing that here: apt-cache depends libogre-1.8.0
[23:26] <ali1234> ogre has it's own window management functions, but i do not use them
[23:26] <bschaefer> which will not allow it to work :(
[23:26] <bschaefer> o
[23:26] <bschaefer> well
[23:27] <ali1234> so it should work as long as the libraries are around and it just won't use them... i guess?
[23:27] <ali1234> also i could patch the X11 stuff out of ogre, maybe
[23:27] <bschaefer> well if they are around, and there are functions calls that attempt to connect with the XServer it'll fail
[23:27] <ali1234> wondering if it's worth it...
[23:28] <ali1234> luckily all this stuff is BSD licensed :)
[23:28] <ali1234> or was it MIT, i forget
[23:29] <bschaefer> well the lease you could do is run down where ogre calls any x11 functions
[23:30] <bschaefer> you would hope that if you are using SDL2 to get the context (and set up the native handling) that ogre would leave all that alone
[23:30] <bschaefer> and let SDL2 handle that
[23:30] <bschaefer> if thats the case it'll work just fine
[23:30] <ali1234> CMake/Packages/FindOpenGLES.cmake:    # On Unix OpenGL most certainly always requires X11.
[23:30] <ali1234> :(
[23:31] <bschaefer> :(, thats one assumption that has caused a lot of pain
[23:32] <ali1234> on a related note, the oculus rift devkit relies on X11 and Xinerama as well
[23:32] <bschaefer> to bad they just don't all build a layer ontop of SDL2 and leave all the native window handling to it...
[23:33] <ali1234> well ogre is a lot older than SDL2... SDL1 has no windowing support
[23:33] <bschaefer> right
[23:33] <bschaefer> i forgot how new SDL2 really is :)