=== duflu_ is now known as duflu
[04:17] <RAOF> Ah, bollocks.
[04:18] <RAOF> umockdev doesn't handle marking fds as readable, so poll/select/epoll etc don't.
[04:19] <RAOF> Which is why I'm not getting any events.
[06:46] <RAOF> HUZZAH!
[07:17] <duflu> w00t? Bah.
[08:24] <anpok> alf__: could you have a look at https://code.launchpad.net/~andreas-pokorny/mir/report-namespace/+merge/205577
[08:25] <alf__> anpok: sure, I have it in my list for this morning
[08:37] <duflu> alf__: Also https://bugs.launchpad.net/mir/+bug/1281938 ? :)
[08:42] <alf__> duflu: I wonder if calling glFinish() on the client has any effect (it shouldn't be needed since we are swapping the buffers, but...)
[08:42] <duflu> alf__: Yeah, haven't tried
[08:42] <duflu> Now checking the old SessionMediator
[08:50] <alf__> duflu: Also if this is not present on Android, it could indicate a problem with our Mesa mir egl
[08:50] <duflu> alf__: Yeah, I'm completely unfamiliar with that
[08:51] <duflu> Although we should have seen this bug sooner. Might have to try older Mesa
[09:10] <duflu> alf_: Put a huge delay in the client. And the server still shows an old frame immediately, much sooner than the client has posted the frame. Somehow the compositor thinks it's been given a frame before it has
[09:13] <alf__> duflu: strange
[09:14] <duflu> Which is weird, because just asking the server it shows it doesn't post until it gets a next_frame. Seems like perhaps the client is next_frame'ing prematurely
[09:16] <anpok> I believe mterry was looking into that topic last week
[09:16] <anpok> or is that bug ticket the result of that?
[09:27] <duflu> anpok: One is an enhancement request, the other is a bug :)
[09:28] <duflu> So they're still separate for now
[09:28] <duflu> alf__: Found the problem, but still don't understand the why. Mesa has decided that eglCreateWindowSurface will trigger a surface_advance_buffer immediately
[09:30] <alf__> duflu: hmm, sounds like an issue in our mesa mir egl layer
[09:30] <duflu> alf__: Yep. But I'm still surprised I never saw it before
[09:33] <alf__> duflu: so, looking at https://github.com/RAOF/mesa/blob/egl-platform-mir/src/egl/drivers/dri2/platform_mir.c , we do a mir_advance_colour_buffer() @ line 201 when creating the egl surface
[09:33] <alan_g> duflu: is that what is causing 1280842?
[09:33] <duflu> alf__: Excellent. Well if it's needed then we need to tell BasicSurface to ignore the first 2, not the first 1. Otherwise fix Mesa
[09:34] <duflu> alan_g: Looks possible. But I'd like to keep the enhancement request separate to the bug report
[09:35] <alan_g> duflu: sure - especially until it is proven
[09:35] <duflu> alan_g: I mean we wouldn't implement the enhancement if it's just a bug to fix
[09:36] <alan_g> ack
[09:38] <alf__> duflu: MirMesaEGLNativeSurface only has surface_advance_buffer)(MirMesaEGLNativeSurface* surface, 50                                    MirBufferPackage* buffer_package)
[09:38] <alf__> duflu: which means that the only way mesa can currently get the buffer package is to advance the buffer
[09:38] <duflu> alf__: Yeah I figured there was a reason. But still, buggy :)
[09:39] <alf__> duflu: so we need to fix that, so that that advancing and getting the buffer package are separate operations, like in the client api
[09:40] <alan_g> Or at least have it return the buffer it already has
[09:40] <alf__> alan_g: what do you mean?
[09:41] <anpok> at the first call of surface_advance_buffer let it behave like "get buffer package"?
[09:41] <alan_g> alf__: it is a bad solution - but the first call to surface_advance_buffer() could just return the current buffer
[09:44] <alf__> alan_g: well, I wouldn't want to use this as our final solution, but it makes a good quick test to validate our hypothesis
[09:45] <duflu> Yep, that seems to be how software surfaces work around it
[09:45] <alan_g> alf__: yep
[09:48] <duflu> On the other hand, I can't see how that's safe. It requires buffer_depository->current_buffer() which dereferences an empty front() value (end())
[09:48] <duflu> Oops, not end() but it should throw
[09:50] <alf__> duflu: when the surface is created, it sends a buffer to the client, so that should be saved in the depository. Do you mean something different?
[09:51] <duflu> Oh, I see. We do a dummy process_incoming_buffer on startup to ready the depository
[09:54] <alf__> duflu: it's not a dummy operation, there is a buffer there for real.
[09:54] <duflu> alf__: Semantics... Anyway I think I have a simple workaround for mirclient
[10:14] <duflu> Sigh. That's enough. Net zero bug progress. One found, one fixed.
[11:44] <alan_g> anpok: there are some merge conflicts to fix and then we can finally land: https://code.launchpad.net/~andreas-pokorny/mir/report-namespace/+merge/205577
=== pete-woods is now known as pete-woods-lunch
=== alan_g is now known as alan_g|lunch
=== dandrader is now known as dandrader|afk
=== alan_g|lunch is now known as alan_g
=== dandrader|afk is now known as dandrader
=== Trevinho_ is now known as Trevinho
=== pete-woods-lunch is now known as pete-woods
[15:09] <alf__> fginther: Hi! I want to try mir-mediumtests-trusty-touch/572 with a custom hook, is that possible? Basically, I want to enable valgrind on all architectures again for this build (i.e., remove the arch check in hook H15enable_testing), to see if everything works, before I push to trunk and amend H15enable_testing permanently.
[15:14] <fginther> alf__, that job specifically isn't, but the mir-team-mir-development-branch-trusty-$arch-ci can be. That should provide a sufficient test
[15:19] <alan_g> fginther: can we get the tests run on the clang CI build?
[15:20] <fginther> alan_g, this one ? https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1281591
[15:20] <ubot5> Launchpad bug 1281591 in Ubuntu CI Services "Mir build with clang doesn't run tests" [Undecided,New]
[15:20] <alan_g> fginther: yes
[15:22] <alf__> fginther: yes, that would be sufficient. What's the best way to achieve that? (e.g. add a temporary script that enables valgrind or perhaps temporarily amend H15enable_testing, or ...?)
[15:36] <fginther> alf__, go ahead and prepare it as an MP to pbuilderjenkins
[15:37] <alf__> fginther: ok, I will add a new script so I don't affect other builds until we are sure this is fixed
[15:44] <fginther> alan_g, i'll get back to you in a moment, in a meeting
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
[15:56] <dednick> getting the following error on mir 0.1.5
[15:56] <dednick> (process:13028): GLib-ERROR **: Creating pipes for GWakeup: Too many open files
[15:56] <dednick> anyone seen it before?
[15:57] <dednick> although i guess i'm not 100% sure it's mir that's causing it.
=== dandrader is now known as dandrader|lunch
=== cyphermox_ is now known as cyphermox
[17:03] <alf__> fginther: https://code.launchpad.net/~afrantzis/pbuilderjenkins/mir-enable-testing-temp/+merge/207252
=== bschaefer_ is now known as bschaefer
[17:03] <fginther> alf__, thanks, I have a plan to test this today after lunch
[17:04] <alf__> fginther: great, thanks
[17:12] <kdub> alf__, trying to remember, why did our mg::GLContext not have a swap_buffers() method? kinda forces us to use eglGetCurrent*()
[17:13] <kdub> trying to remember if that was intentional or not :)
[17:17] <rsalveti> alf__: hey, there's just one issue with mir trunk currently, that is not working nicely in nested mode
[17:17] <alf__> kdub: none of the mg::GLContext consumers (PixelBuffer,CompositingScreencast) need it
[17:17] <rsalveti> alf__: and not x86 specific, got the same crash on armhf as well
[17:18] <rsalveti> alf__: flashing latest on my n4 and will test that as well to see if I'm able to reproduce it
[17:18] <alf__> rsalveti: that's with the android platform or mesa?
[17:18] <rsalveti> alf__: android platform
[17:19] <rsalveti> alf__: http://paste.ubuntu.com/6957542/
[17:19] <rsalveti> this is with the armhf emulator
[17:20] <rsalveti> alf__: and with the x86 one: http://paste.ubuntu.com/6952522/
[17:20] <rsalveti> alf__: http://paste.ubuntu.com/6951930/
[17:20] <kdub> alf__, I have a place where it would be useful to android... debating putting swap_buffers() in mg::GLContext or making a mga::SwappingGLContext interface
[17:20] <rsalveti> alf__: in case you want to try the x86 emulator https://plus.google.com/+RicardoSalveti/posts/1u7HSYjF2He
[17:21] <rsalveti> to use nested mode, just install ubuntu-touch-session from the archive (downgrade the package)
[17:21] <rsalveti> as I had to disable it in a ppa for now, to get unity8 to work
[17:25] <alf__> rsalveti: ok, can you please file a bug about this?
[17:26] <rsalveti> alf__: sure
=== dandrader|lunch is now known as dandrader
[20:12] <rsalveti> alf__: bug 1282248
[20:12] <ubot5> bug 1282248 in Mir "Unity8 crashes when using latest mir/android backend with system-compositor" [Undecided,New] https://launchpad.net/bugs/1282248
[20:12] <rsalveti> kgunn: from the mir perspective, I guess this is the last remaining blocker for the x86 emulator
[20:13] <rsalveti> kgunn: also know that without fixing this issue, we can't land current mir/devel, as it also affects every device
[20:13] <rsalveti> just a heads up
=== dandrader is now known as dandrader|afk
[20:25] <kgunn> rsalveti: ack,thanks...i'll get someone on it
[20:26] <rsalveti> thanks
[22:49] <fginther> kgunn, can someone help me with https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1281591 ? I'm trying to figure out the correct build configuration to trigger running of the tests
[22:49] <ubot5> Launchpad bug 1281591 in Ubuntu CI Services "Mir build with clang doesn't run tests" [Undecided,New]
=== dandrader|afk is now known as dandrader
[23:08] <kgunn> racarr: can you help fginther ?
[23:10] <racarr> kgunn: fginther: Hi :)
[23:10] <racarr> so the default build options should enabe running the tests
[23:10] <racarr> so the way I thought it was set up was just the amd64 job runs ctest
[23:10] <racarr> and the clang job
[23:10] <racarr> omits it
[23:11] <racarr> RAOF: p.s. about my recent user data mp...I have this vague memory of you talking with Gerry
[23:11] <racarr> and agreeing that surface user data was reasonable XD
[23:11] <racarr> 1. Was that a dream.
[23:11] <racarr> 2. Do you remember the context?
[23:17] <fginther> racarr, thanks
[23:37] <fginther> racarr, thanks, it appears to be working: http://s-jenkins.ubuntu-ci:8080/job/mir-clang-trusty-amd64-build-fjg/5/console
[23:38] <RAOF> racarr: I don't recall that conversation with Gerry.
[23:38] <RAOF> racarr: When would this have been?
[23:38] <racarr> RAOF: Haha cest la vie
[23:38] <racarr> I think in london
[23:38] <RAOF> Ah.
[23:38] <racarr> dont worry about all I remember
[23:38] <racarr> is this image of you being like So some sort of user data...thats reasonable
[23:39] <racarr> :p
[23:39] <RAOF> I certainly discussed a bunch of things with Gerry, and I'm not generally opposed to user data thingies :)
[23:39] <racarr> just collecting thoughts