[08:31] <robin-hero_> Hey all, I bought a SlimPort-HDMI adapter last week, but I can't charge my phone and connect it to an external display at the same time: I've already filled a bug: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1519235
[08:32] <ubot5`> Ubuntu bug 1519235 in mir (Ubuntu) "Nexus 4 - HDMI-Slimport adapter can't charge the phone and display the screen at the same time." [Undecided,Confirmed]
[08:32] <robin-hero_> If I remember correctly, it works with Android, but not with Ubuntu
[08:58] <anpok_> hm it works for me
[09:00] <anpok_> robin-hero_: the one I use looks more like this one http://www.amazon.com/Yakamoz-Slimport-Adapter-Cable-Lovely/dp/B00H8QIUZG/ref=sr_1_81?ie=UTF8&qid=1449046804&sr=8-81&keywords=slimport
[09:33] <white_duck> wohoo mir 0.19
[09:33] <robin-hero_> anpok_, Hmm, I need to relfash Android to test again, If it wouldn't work well with that it it a hardware problem with the adapter.
[17:18] <alan_g> AlbertA: thanks for picking up the ubsanitizer work, I've been meaning to get around to that but getting distracted..since April :(
[17:21] <AlbertA> alan_g: no problem, I didn't even know it existed until you mentioned it yesterday :)
[17:22] <AlbertA> alan_g: no other major reports other that those two bugs I have MPs for... the rest are issues with gmock or a gcc ubsan bug  complaining about non-capture lambdas
[17:23] <alan_g> If you'd been at the ACCU conference last year you couldn't have missed it. ;)
[17:23] <alan_g> Well, the last conference (which was this year)
[17:25] <alan_g> @"issues with gmock" - surprising, I know google are big users of ubsan
[17:31] <AlbertA> alan_g: apparently fixed in their trunk: https://groups.google.com/forum/#!msg/googlemock/cHSPZfcIwSc/sYAzFl2DCQAJ
[17:31] <AlbertA> I get various reports of "/usr/include/gmock/gmock-spec-builders.h:1530:60: runtime error: member call on null pointer of type 'const struct ResultHolder'"
[17:32] <alan_g> AlbertA: I guess we're too late to get an update in vivid. :(
[17:32] <alan_g> *into
[17:37] <alan_g> AlbertA: just checking, your bug 1522105 isn't a different manifestation of bug 1514884 is it? (Fix landed recently.)
[17:37] <ubot5`> bug 1522105 in Mir "NestedServer.display_configuration_reset_when_application_exits segfaults" [Medium,New] https://launchpad.net/bugs/1522105
[17:37] <ubot5`> bug 1514884 in Mir "There's something racy in NestedServer.display_orientation_changes_are_forwarded_to_host" [Medium,Fix committed] https://launchpad.net/bugs/1514884
[17:38] <AlbertA> alan_g: probably a different cause now... I tried the tip of lp:mir
[17:39] <alan_g> OK, just sounded possible as it could have been an affected case.
[17:40] <AlbertA> alan_g: looks like surface stack is sending a null surface pointer to the observers
[17:40] <AlbertA> based on the GDB backtrace
[17:41] <alan_g> I see. If you don't get to it I'll have a look in the morning.
[17:45] <AlbertA> oh yeah.. SurfaceStack::add_observer drops/reacquires the lock as it loops over the existing surfaces...so that needs fixing
[17:51] <alan_g> Oh, that looks painful.
[17:54] <AlbertA> alan_g: yep... the good ol' callback problem...
[17:55]  * alan_g decided to end the day before getting too interested in solving that one.
[17:57] <alan_g|EOD> (it doesn't work)
[18:00] <alan_g|EOD> AlbertA: could it be as simple as copying "surfaces" under lock and looping over the copy?
[18:01]  * alan_g|EOD => really EOD
[18:01] <AlbertA> alan_g|EOD: it could but then the observer calls could be out of order: like receiving surface_removed before surface_exists
[18:02] <AlbertA> which would be odd
[19:19] <kdub> arm64 vs amd64 makes me go crosseyed
[22:23] <Saviq> kgunn, tracked down to line 95 in http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/platforms/mirserver/surfaceobserver.cpp#L95
[22:23] <Saviq> meaning we're getting a nullptr as cursor, and not expecting it
[22:25] <Saviq> folks, should SurfaceObserver::cursor_image_set_to deal with null pointers? is it expected that we're getting it? see bug #1522117
[22:27] <kgunn> anpok: ^
[22:34] <shiznix> is Wily Mesa supposed to build with Wily Mir, or is this a WIP?
[22:38] <anpok> Saviq: not expected.. i thought AlbertA working on something similar, but looking through the logs he was after something different
[22:38] <Saviq> oh so we actually uncovered a mir bug?
[22:39] <AlbertA> Saviq: maybe it's this? https://code.launchpad.net/~albaguirre/mir/fix-1521795/+merge/279218
[22:40] <Saviq> AlbertA, definitely sounds related
[22:43] <shiznix> encountered pkgconfig problem where mesa-11.0.2-1ubuntu4 can't find 'mir-client-platform-mesa-dev' as this was renamed to 'mir-client-platform-mesa' in mir-0.17.0+15.10.20151008.2-0ubuntu1
[22:44] <shiznix> but once this small typo is smoothed over, mesa fails to build -> http://webcache.googleusercontent.com/search?q=cache:jmRbpw2aKBQJ:pastebin.com/G7pLiWRT+&cd=2&hl=en&ct=clnk&gl=au&client=ubuntu
[22:45] <shiznix> not my pastebin, but exactly the same build error
[22:45] <shiznix> and somewhat reassuring that i'm not the only one :D
[22:46] <shiznix> apologies for the noise if they're not intended to build together yet
[23:01] <RAOF> shiznix: They are expected to build together; which versions are you building, though?
[23:01] <RAOF> Ah, mesa 11.0.2 vs mir 0.17?
[23:54] <shiznix> RAOF: yes :)