=== duflu_ is now known as duflu
[04:53] <RAOF> Well, that failure makes *absolutely no sense*
[04:54] <RAOF> ~thread() is dying in if (joinable) std::terminate().
[04:54] <RAOF> But ~thread() is being called after a destructor which has called thread.join();
[04:55] <duflu> RAOF: That means it's been deleted twice, usually. Valgrind should tell where
[04:56] <duflu> Whee, my merge proposals have now been up for review long enough to get conflicts from other things landing :S
[05:00] <RAOF> Huh. MirSocketRpcChannel apparently leaks fds.
[05:17] <RAOF> Oh, wtf? The leak appears in TestClientInput, but if I pass --gtest_filter=TestClientInput\* then it *doesn't* show up?
[05:32] <RAOF> For those playing at home, a stack depth of 24 is insufficient to catch this error :/
[05:35] <RAOF> Did my *monitor* just reboot?
[05:35] <RAOF> ?!
[07:30] <Mirv> RAOF: it needs to do that after it receives a newer version of the surveillance software
[07:31] <Mirv> they're working on updating the monitor's kernel while it's running, though
[07:31] <Mirv> so it should be completely transparent to you soon enough!
[10:04] <duflu> alan_g: You win :) https://bugs.launchpad.net/mir/+bug/1284554
[10:04] <ubot5> Ubuntu bug 1284554 in Mir "[regression] mir_demo_server_shell: All clients start fullscreen by default" [Medium,Triaged]
[10:06] <alan_g> I though I'd won something nice. :(
[10:07] <duflu> Sorry.
[10:07] <alf_> duflu: alan_g: anpok_:
[10:07] <alf_> duflu: alan_g: anpok_:
[10:07]  * alf_ curses fingers
[10:08] <anpok_> yes?
[10:08] <alf_> duflu: alan_g: anpok_: @ https://bugs.launchpad.net/mir/+bug/1192908, are you ok with removing the dependency that libegl1-mesa-dev has on libmirclient-dev (see last comment)
[10:08] <ubot5> Ubuntu bug 1192908 in mesa (Ubuntu) "Mir/Mesa packaging have a dependency cycle so neither can build" [Medium,Triaged]
[10:09] <duflu> alf_: I'm OK with removing any dependencies possible. Keep in mind though that bug is about source package dependencies (not binary), isn't it?
[10:10] <alf_> duflu: it resolves at least a part of the dependency problem, i.e., currently when mir builds it indirectly depends on the existing libmirclient-dev
[10:11] <duflu> alf_: I suspect the original fix is now gone too. Might be best to do the work in another bug given that one has a branch and Fix Released.
[10:27] <alan_g> alf_: I'm begging to feel that there's a low-level project & package missing.
[10:28] <anpok_> alf_: mesa only needs to load a library and plays with a struct with some callback functions.. that implement the egl platform?
[10:31] <alf_> alan_g: so to solve the greater build dependency cycle, we would either need to have multiple source packages for mir, or move our EGL definitions in Mesa, or have a third independet source package they both depend on
[10:33] <alan_g> alf_: yes. I'm not sure it is the right trade-off, but it is worth considering
[10:34] <alf_> anpok_: all the egl backends are built in Mesa's libegl
[10:35] <alf_> alan_g: anpok_: Anyway, I am not sure it's urgent, and there is the workaround mentioned by Daniel "You might be able to work around the problem by building Mir against vanilla Mesa (which does not depend on Mir)"
[10:36] <alan_g> I'd say it is a discussion for next cycle
[11:28] <alf_> alan_g: are you looking into https://bugs.launchpad.net/mir/+bug/1284161 ? If not, I can take a look.
[11:28] <ubot5> Ubuntu bug 1284161 in Mir "nested mir_standalone_render_surfaces hangs" [High,Triaged]
[11:30] <alan_g> alf_: OK, I hadn't quite got back to that
[11:30] <alf_> alan_g: ok
[11:47] <alan_g> alf_: it is probably something different, but FYI https://bugs.launchpad.net/mir/+bug/1284597
[11:47] <ubot5> Ubuntu bug 1284597 in Mir "nested render_surfaces fails on N4 " [Undecided,New]
[11:51] <alf_> alan_g: I can't reproduce the problem on laptop with i965. Both --launch-client and running the render_surfaces manually works for me :/
[11:53] <alan_g> alf_: Interesting
[11:58] <alan_g> I was running it on desktop. But that's also intel
[11:58]  * alan_g get laptop out
[12:02] <anpok_>  "" is a helpful shader compilation error message
[12:09] <alf_> anpok_: it's in invisible ink!
[12:11] <anpok_> i guess the color value of invisible ink is an implementation defined value in the ES spec
[12:24] <alan_g> alf_: works on my laptop too.
[12:24]  * alan_g wonders what the important difference is.
[12:25] <alf_> alan_g: my laptop is a bit behind on updates, let me see if updating makes a difference
[12:25] <alan_g> alf_: mine isn't
[12:26]  * alan_g wonders if it is as stupid as number of monitors
[12:27] <alf_> alan_g: certainly worth a try
[12:31] <alan_g> rats. Plugging in a monitor hung the laptop
[12:33] <alan_g> alf_: works with two monitors on the laptop
[12:51] <alan_g> alf_: does this (my desktop) suggest anything? https://pastebin.canonical.com/105514/
[12:53] <alf_> alan_g: nothing seems out of place
[12:54] <alan_g> I guess you can't do much more to investigate
[12:59] <alan_g> alf_: have you noticed that every MP is now failing: https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/
[13:03] <alf_> alan_g: yes
[13:03] <alan_g> Do you know what happened?
[13:04]  * alan_g notices time
=== alan_g is now known as alan_g|lunch
[13:26] <alf_> alan_g|lunch: seems that we have a new libc version 2.19 and it breaks things
[13:48] <alf_> alan_g|lunch: or rather valgrind needs to be updated to support 2.19 (and produce the correct default suppression files)
[13:49] <alf_> kgunn: ^^
=== alan_g|lunch is now known as alan_g
[14:12] <alf_> alan_g: kgunn: https://bugs.launchpad.net/mir/+bug/1284653
[14:12] <ubot5> Ubuntu bug 1284653 in valgrind (Ubuntu) "valgrind packages ouf of sync with current glibc version (2.19)" [Undecided,New]
[14:12] <kgunn> alf_: ack
[14:13] <kgunn> i guess that's our problem to solve ? ....no real tools team per se :-/
[14:13] <alf_> alan_g: kgunn: although valgrind being out of sync only explains the spurious memory errors, I am not sure about the test failures themselves
[14:14] <alan_g> alf_: thanks
[14:15] <kgunn> Saviq: hey...just wondering, so alf_ found new libc "changed something" that effects our valgrind runs...could that be a source of spurious issues on unity AP tests ?
[14:16] <Saviq> kgunn, if they can cause SIGSEGV on startup...
[14:16] <Saviq> kgunn, our issue seems to be android-size - i.e. I can't get any symbols out of it for the life of me
[14:18] <kgunn> hmm...libc, android...does smell a little fishy
[14:18] <kgunn> potentially
[14:19] <kgunn> i guess its only an issue for reference structures between libc/ubuntu side vs bionic/android side
[14:23] <kgunn> but then that would be a 100%
[14:24] <Saviq> kgunn, yeah, ours is some race
[14:24] <Saviq> crashing on startup maybe 5% of the time
[14:29] <Saviq> kgunn, but well, glibc shouldn't be causing that, IIUC, 'cause we'd had symbols for that ubuntu-side
[14:30] <kgunn> right
[14:30] <kgunn> sounds more like potentially android bin changes
[14:30] <kgunn> Saviq: cause all this is happening on 4.4.2 android right ?
[14:30] <Saviq> kgunn, yes
=== pete-woods is now known as pete-woods-lunch
[14:37] <alan_g> alf_: (@1284597) why would glCreateShader() return 0 and then glGetError() return 0?
[14:42] <alf_> alan_g: perhaps there is no current GL context?
[14:42] <alf_> alan_g: (check with eglGetCurrentContext())
[14:48] <alan_g> alf_: it returns 0 => you guessed right
[14:48] <alan_g> thanks
[14:49] <alf_> alan_g: yw
=== dandrader is now known as dandrader|afk
[15:37] <alan_g> alf_, anpok : (@1284597) I'm trying to decide whether the problem is that mt::ImageRenderer::ImageRenderer() assumes there's a GL context or that there is no GL context in nested mode. Do you have an opinion?
=== alan_g is now known as alan_g|tea
[15:42] <anpok> The former I believe..
[15:44] <anpok> On android driver stacks we might be able to acchieve not needing a gl context on non-nested sessions too..
[15:45] <alf_> alan_g|tea: anpok: Assuming an active GL context is a leftover from when we didn't have the Display::create_gl_context(). Whoever needs access to the shared context can now get one.
[15:46] <anpok> get one where?
[15:46] <alf_> anpok: I mean by calling Display::create_gl_context()
[15:47] <anpok> oh.. too simple
=== alan_g|tea is now known as alan_g
[15:49] <alf_> alan_g: although, it's strange that in the nested case we don't have a context. NestedDisplay makes a context current when being constructed
[15:51] <alan_g> alf_: it does seem strange. But it seems to be the case
[15:52] <alan_g> I'm happy to add the call though - as it makes sense anyway
=== dandrader|afk is now known as dandrader
[15:59] <anpok> https://bugs.launchpad.net/mir/+bug/1268819
[15:59] <ubot5> Ubuntu bug 1268819 in Mir "MirMotionEvent lacks local coordinates. Reports only screen coordinates." [High,Triaged]
[16:00] <anpok> shall we MirMotionEvent contain both, screen coordinates and local surface coordinates?
[16:00] <anpok> or just the latter...
[16:12] <alan_g> anpok: most (all?) clients should only care about local co-ordinates
[16:17] <anpok> within MirMotionEvent there is for evey point float x, and float raw_x - is that meant to be local vs screen co-ordidnates?
=== pete-woods-lunch is now known as pete-woods
[16:22] <alan_g> They *should* be local. Not sure why there are two of them - the distinction probably originates in the android input stack.
[16:23] <anpok> ah because of android
[16:23] <anpok> and for them raw means not transformed by the offset
[16:25] <anpok> but with orientation being a float value too now.. hmm. the code needs more changes.
=== dandrader is now known as dandrader|lunch
=== dandrader|lunch is now known as dandrader
=== veebers_ is now known as veebers
[21:08] <mterry> Who knows a bunch about Mir + Qt keyboard focus?
[21:08] <mterry> er, key focus I guess.  Like volume up/down
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== bregma_ is now known as bregma
[22:10] <kgunn> mterry: i bet dandrader might
[22:11] <kgunn> alternatively racarr_
[22:11] <dandrader> I recall I did something related to it a long time ago
[22:11] <mterry> :)
[22:12] <RAOF> :)
[22:12] <mterry> My problem is that when using a split greeter, only the user session receives volume presses.  The greeter session does not
[22:12] <mterry> I was curious how such input is routed between Mir sessions
[22:14] <dandrader> no idea
[22:15] <RAOF> mterry: Is the greeter session focussed?
[22:15] <RAOF> ‘split greeter’ implies use of unity-system-compositor, yes?
[22:16] <RAOF> u-s-c should be sending input only to whatever it thinks is focused, which should be either just the greeter or just the user session.
[22:17] <mterry> RAOF, hmm, it is on top because of depth...  Let me see how the version of USC I'm using handles focus
[22:18] <RAOF> Last time I checked (which was some time ago, with the desktop u-s-c) you needed to explicitly switch session focus. This might have changed, though.
[22:20] <mterry> RAOF, aha...  yes.  OK, so the_focus_controller() handles keyboard focus, that makes sense.  And the branch I'm using looks to have a bug around that when using two sessions.  Thanks!  I had forgot about the FocusController
[22:20] <RAOF> Hurray for memory!
[22:50] <mterry> RAOF, just to confirm, yeah, that was it.  Weird set_focus_to behavior in my branch.  Thanks man
[22:51] <RAOF> Bitchn'