[12:28] <Saviq> guys, was mir 0.12 accepted into vivid after all?
[12:38] <anpok_> Saviq: no idea, didnt pay much attention yesterday.. saw some discussions
[12:38] <anpok_> alf_, alan_g: shouldnt libmirserver hide the graphics platform api/abi?
[12:39] <alan_g> What do you mean by "hide"?
[12:40] <anpok_> well it might be enough to have no access to it through mir::Server
[12:41] <anpok_> while looking at the module_type_detection code, and christophers suggestion to make it support an older ABI of mir_server_platform_graphics
[12:41] <anpok_> i thought that this is pointless since shells can for examples access Diplay and DisplayBuffer and related classes directly
[12:43] <anpok_> hm ok we could still provide have a wrapper around an older version of .. e.g. mir::graphics::Display
[12:44]  * alan_g has no idea what you want to achieve
[12:46] <alan_g> the pltaform lib provides the symbols, how can the server lib "hide" them?
[12:46] <anpok_> sorry I was mixing stuff above
[12:47] <anpok_> I am not concerned about our graphics platform entry points
[12:48] <anpok_> more about the object structure it exposes through the mir::graphics::Platform interface
[12:50] <anpok_> alan_g: last night I tried to provide a newer mir with the same MIR_GRAPHICS_PLATFORM symbols, but incompatible changes in it
[12:52] <anpok_> which failed because for example Display is different now, and qtmir needs to access..
[12:53] <alan_g> So what you're suggesting is that libmirserver-dev shouldn't depend on libmirplatform-dev
[12:54] <alan_g> Sounds reasonable
[12:55] <anpok_> it would at least limit the problem to a mir internal one
[12:55] <anpok_> problem of supporting multiple graphics platform versions
[12:56] <anpok_> not sure if I make much sense today.. really need more sleep today
[12:57] <alan_g> Actually, it wouldn't be "mir internal" once we try to support 3rd party platforms
=== alan_g is now known as alan_g|lunch
[13:26] <Saviq> kgunn, hey, do you know if mir 0.12 got accepted to vivid after all? http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-007
=== alan_g|lunch is now known as alan_g
[14:10] <kgunn> Saviq: yo, it appears it's migrating ? it was only 1 bug fix for deadlock issue so it was a good one....why do you ask?
[14:11] <Saviq> kgunn, just I wasn't sure 0.12 was getting in due to FF
[14:11] <kgunn> Saviq: ah, yes...it was on purpose
[15:26] <camako> Saviq, @mir 0.12, yeah it got accepted, the process wasn't any different than before (at least so far, it's still in proposed)
[15:28] <Saviq> camako, yeah, I can see that, and am wondering why it's taking so long...
[15:28] <Saviq> mir-client-platform-mesa-dev/amd64 unsatisfiable Depends: mir-client-platform-mesa (= 0.12.0+15.04.20150224.1-0ubuntu1)
[15:29] <Saviq> camako, ok, that thing's not gonna migrate
[15:29] <Saviq> since there's no mir-client-platform-mesa any more, it's ...-mesa1
[15:30] <attente_> hi, i'm trying to run a qt app under mir, but it seems to use some features that are unsupported by the qpa, specifically QQuickWidget, window masks, and propagateSizeHints()
[15:30] <Saviq> attente_, greyback_'s been working on enabling all of that recently
[15:31] <Saviq> it's not yet all integrated, but I imagine you can get some pointers from him, or an ETA at least
[15:31] <attente_> Saviq: oh awesome
[15:32] <attente_> greyback_: hi, any idea when ^ will be available?
[15:34] <Saviq> AlbertA, ↑↑ you aware Mir is blocked in proposed?
[15:34] <camako> kdub ^^
[15:34] <Saviq> because ...mesa-dev deps on not-existing -mesa
[15:34] <AlbertA> camako: ^ kdub ^
[15:36] <camako> Actually, wasn't it alf_ that made that change ^
[15:36] <AlbertA> camako: we need to fix it in devel too
[15:37] <camako> sure
[15:38] <alf_> camako: AlbertA: want me to fix it?
[15:39] <camako> alf, yes please
[15:39] <kdub> and then what do we do?
[15:39] <camako> alf_, ... on both branches
[15:40] <alf_> camako: lp:mir , lp:mir/ubuntu?
[15:40] <camako> kdub, rebuild everything, do sanity, release
[15:40] <AlbertA> alf_: in 0.12 branch and lp:mir
[15:40] <greyback_> attente_: am adding such abilities when we notice they're needed. If you could add bugs for those features, then I'll consider them noticed and work on them
[15:40] <camako> alf_, yeah what AlbertA said
[15:42] <greyback_> attente_: but yes the plan is to enable all the QPA features that QWidget based apps rely on. I was working on enabling all the qtbase5-examples first
[15:42] <camako> Saviq, are you anywhere close to landing silo 19?
[15:44] <Saviq> camako, I'll need to wait for yours anyway, since otherwise I'd overwrite qtmir and you'd have to rebuild and.... meh
[15:44] <camako> Saviq, yeah that's why I was asking... Thanks
[15:44] <camako> kdub ^
[15:46] <attente_> greyback_: sure, thanks
[15:47] <greyback_> attente_: is it an app I can try, or something private?
[15:49] <attente_> greyback_: it's a bit of an unusual case. i've ported fcitx-qimpanel to qt 5 which provides the input method widget for cjk text input
[15:49] <attente_> i have a branch here: https://github.com/attente/fcitx-qimpanel
[15:50] <attente_> i'll file a bug though with the requirements
[15:51] <greyback_> attente_: please do. Mir's needs better support for input methods so it may take time. But definitely please log bugs as it'll show us where to start
[15:57] <alf_> camako: AlbertA: https://code.launchpad.net/~afrantzis/mir/fix-mir-client-platform-dev-deps/+merge/251281
[15:57] <alf_> camako: AlbertA: If we are OK with the change, I will push it directly to mir/0.12 also
[15:59] <camako> alf, shouldn't it now depend on -mesa2?
[15:59] <AlbertA> alf_: isn't it customary to have the headers depend on the library the headers are for? I mean in debian parlance?
[15:59] <camako> alf, note that 0.12 is behind (-mesa1)
[16:00] <AlbertA> alf_: I see all other mir dev packages follow that convention
[16:01] <alf_> camako: AlbertA: mir-client-platform-mesa is not a library, it's a plugin for Mir
[16:01] <AlbertA> alf_: ahh true
[16:01] <alf_> camako: AlbertA: i.e. 3rd parties are not going to ever use mir-client-platform-mesa directly
[16:08] <tedg> dednick, So as part of the trusted session loosing focus thing, was there API added for that to Mir?
[16:08] <tedg> dednick, i.e., do we need to implement another callback there?
[16:24] <dednick> tedg: not sure about the losing of focus. that part of the whole https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1352251 thing?
[16:25] <ubot5> Launchpad bug 1352251 in unity8 (Ubuntu RTM) "Reverse trust prompt hosting" [High,Triaged]
[16:31] <tedg> That's more confusing.
[16:32] <tedg> Saviq, You're going to have explain your comment there, what's the broker?
[16:32] <tedg> Something to broker the pid of the dash?
[16:33] <tedg> Is there a case of scope data being displayed by more than one pid?
=== dandrader is now known as dandrader|lunch
[17:05] <alan_g> alf_: did you break my build? "The following packages have unmet dependencies: mir-client-platform-mesa-dev"  https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/4424/console
[17:06] <mlankhorst> alan_g: that -dev package needs to depend on mir-client-platform-mesa2 :P
[17:08] <alan_g> mlankhorst: I think alf_ was changing the test script to detect packaging errors. My build got caught.
[17:08] <mlankhorst> ah
[17:33] <alf_> alan_g: yes, and https://code.launchpad.net/~afrantzis/mir/fix-mir-client-platform-dev-deps/+merge/251281 fixes it again
=== dandrader|lunch is now known as dandrader
[17:37] <alan_g> alf_: I vote for pushing that directly to trunk and not waiting for autolanding
[17:49] <camako> @pushing directly to trunk, +1
=== alan_g is now known as alan_g|EOD
[19:56] <tallnerd1985> Hi everyone
=== dandrader is now known as dandrader|afk