[02:38] Mir 0.8.0 is now tagged and released. [02:38] Mir 0.9 already underway :) [07:17] ah [07:17] the issue i had yesterday .. [07:19] i cannot connect clients to nested servers if the nested server is not running on the current vt [07:19] while i can do that for none nested servers [07:28] anpok_, yay [07:29] anpok_: Hey were you expecting i915 to work in that latest Mesa? My i945 doesn't [07:29] ... still [07:39] no not yet [07:50] duflu: 10.3.1 is all i can say .. it was review about three weeks after i posted that patch.. [07:50] *reviewed [07:55] anpok_: OK, I was confused. Looks like Ubuntu's getting Mesa fixes in non-chronological order [07:55] Maybe not [07:56] hm the last update was a fix of mir egl platform [07:58] anpok_: Yes, which is much newer than your i915 fix :) [09:09] alf__: @a-simpler-server-setup any thoughts on L257? [09:09] alan_g: looking [09:10] alan_g: Better to throw IMO [09:11] OK [09:33] alan_g: anpok_: duflu: RAOF: We have three test utility classes doing the same thing(WaitCondition, WaitObject, Signal). I am going to keep one of them. Please vote on which *name* you prefer (I will keep the WaitObject/Signal (same thing) implementation in any case). [09:33] alf__: Event ;) [09:33] or something [09:35] alf__: Well we don't have predicates like real conditions do, so not WaitCondition. Not WaitObject because "object" is too general a word for a class name. And not "Signal" because signal is a verb -- a method name really. [09:35] Need a new name I think [09:36] * alan_g goes to look what they actually do... [09:36] I was joking about Event, but maybe it's a good idea. Not sure and am not about to review the classes in detail [09:38] duflu: alan_g: Actually perhaps we should just get rid of all the classes and use std::future [09:39] alf__: I believe C++ should provide everything we need, one way or the other [09:39] Not std::future though. That's an ugly one [09:43] alf__: Tell you what; I will close my eyes for now because too many opinions always slow us down [09:43] alf__: have you seen mt::Signal? [09:43] And I have work to try and finish before too long [09:44] Sorry, thinko [09:45] mt::Barrier is similar too. [10:19] alf__: I think there are three relevant idioms "latch", "barrier" and "future". WaitCondition, WaitObject & Signal all look like latches to me. [10:24] This doesn't describe a wait_for(time-out) function, but seems sane: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3666.html [10:48] alan_g: It could be that I am not familiar with the term 'latch' in this context, but I don't find it to be a very intuitive name for a mechanism providing inter-thread notification. When I see 'latch' I think 'flip-flop', for which the emphasis is on state storage rather than notification. [10:49] alf__: ak [10:56] * alan_g rediscovers the joy of pre-processor macros [11:08] alan_g: can I pick your brain on a linker rpath issue I'm having? [11:08] greyback: sure, but I'm no expert [11:10] alan_g: here's my notes: https://docs.google.com/document/d/1d0Djaz0T9OXJVK1wNToj4eYIgkd2N-68T-p7EPZYZJo/edit - the problem is mentioned there [11:12] greyback: paraphrasing: you can set the rpath either for in-tree or for installed but have trouble handling both? [11:12] alan_g: essentially yes [11:13] alan_g: I had expected that the rpath specified in the executable would take precedence over those in the linked libraries, but it appears not [11:14] I know CMake relinks stuff it installs, so maybe you can use that mechanism [11:14] * alan_g knoes even less about cmake [11:14] qmake doesn't - yet another reason to use racarr's cmake work asap [11:14] but that is good to know about cmake - soundsl ike it would fix this problem for me [11:15] I've spent too long fighting qmake over this, so think most sensible option is indeed cmake [11:16] ok, that's a good enough solution for me, thanks alan_g [11:16] greyback: yw === MacSlow is now known as MacSlow|lunch [12:10] alan_g: about that mir_connection_create_prompt_session_sync() not failing if the initiator is not a valid PID, is it on the radar? Do you have a bug for it? === dandrader is now known as dandrader|afk [12:33] mardy: lp:1377968 [12:38] alan_g: oh, that was quick! Thanks! :-) === dandrader|afk is now known as dandrader === MacSlow|lunch is now known as MacSlow === mpt_ is now known as mpt === dandrader_ is now known as dandrader|lunch === alan_g is now known as alan_g|EOD [17:42] https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1365673 kgunn can we bump the priority of this bug to critical? [17:42] Ubuntu bug 1365673 in unity8 (Ubuntu) "/usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene:6:qt_message_fatal:QMessageLogger::fatal:UbuntuClientIntegration::UbuntuClientIntegration:UbuntuMirClientIntegrationPlugin::create:loadIntegration" [High,Triaged] [17:42] kgunn: it's a top crasher every day === dandrader__ is now known as dandrader [17:43] kgunn: we thought that fixing 20141008.1 would fix the issue but it did not [17:43] oops [17:44] kgunn: we thought that fixing bug #1368101 would fix the issue but it did not [17:44] bug 1368101 in qtmir (Ubuntu) "Stopped apps don't restart when launched from another app" [Critical,Fix committed] https://launchpad.net/bugs/1368101 [18:05] robotfuel: per pmcgowan & jfunk in managers channel they want to address the OOM killer issues first [18:06] kgunn: ok is there a bug number for that? so I can ask for the bug to be critical instead of high when that is fixed? [18:11] robotfuel: according to pat & asac they don't have one yet, gonna log one [18:11] i'll let you know when i know === dandrader_ is now known as dandrader|afk === dandrader|afk is now known as dandrader [22:52] alf__: I (unsurprisingly, as I chose the name originally ☺) vote Signal. Unlike duflu, I'm aware of signal, the noun :)