[07:50] <duflu> abi-check says we removed a function from MIR_CLIENT_DETAIL_9 ... that's OK right?
[07:53] <duflu> alan_g ^
[07:54] <alan_g> duflu: yes(ish)
[07:55] <RAOF> I would also say yes.
[07:55] <duflu> It's an ABI but not as public
[07:55] <alan_g> It won't break clients, the things it would break are distributed at the same time
[07:55] <duflu> Indeed
[07:56] <duflu> Just looks bad for our tooling as even after I fixed some minor problems 'make abi-check' fails due to it
[07:56] <duflu> So you can't tell if other failures lurk after it
[07:56]  * alan_g would like to reorg the code - but that would break ABIs
[07:58]  * RAOF is happy to break any ABI that isn't the client ABI.
[07:59] <alan_g> MirAL brings a new hope of a stable server-side ABI (but that includes getting mircommon stable)
[07:59] <duflu> I would like to say it's too late in the week to think about that but I am presently looking at it
[07:59] <RAOF> Re-exporting symbols is a thing, right?
[08:00] <RAOF> Hm.
[08:00] <alan_g> Hmm that is a thought
[08:00] <duflu> RAOF: Definitely, in theory. Just need to know how with our tools
[08:01] <RAOF> Actually, *why* can't we just include mircommon statically into mirclient?
[08:01] <duflu> Because it's a waste of space. Also the break already happened anyway
[08:01] <RAOF> I mean, we could *remove* libmircommon as a thing.
[08:01] <alan_g> Because it is used by platform modules, the mirserver and mircommon
[08:01] <RAOF> It's a trivial waste of space, and it simplifies our lives.
[08:02] <alan_g> ODR rule
[08:02] <duflu> RAOF: That solves the symbol version problems sure. But not header changes... ODR
[08:02] <RAOF> alan_g: The ODR rule doesn't apply here, though?
[08:02] <alan_g> Why not?
[08:02] <duflu> Common sense by some other name then. Database normalization (?!
[08:02] <duflu> )
[08:03] <RAOF> Because there are no C++ objects in the interface between mirclient and mirserver/mirplatforms?
[08:04] <duflu> libmirprotobuf is C++ but a different lib
[08:04] <RAOF> I mean, it's not an ODR violation if glib internally has a class called mir::Dispatchable but it's not exported in the symbol table and never appears in the interfaces.
[08:04] <duflu> Don't worry about it. We all know a fix is possible at the binary level. Just need to work out the high level syntax
[08:04] <RAOF> (If that *is* an ODR violation then that's another area where C++ is insane)
[08:05] <RAOF> (This might require getting rid of mirclientdetail, which exists, from memory, purely for the benefit of acceptance tests?)
[08:05] <alan_g> I think also for the debug extension rubbish
[08:06] <RAOF> Yeah, I'm happy to fold that in.
[08:06] <RAOF> We'll have an *actual* extension mechanism *someday*.
[08:06] <alan_g> One day we'll work out exactly what we need in what libraries and declare version 1
[08:07] <duflu> I actually wanted to look at a version "25" but that idea fell flat when I realized mirserver is already higher :(
[08:07] <duflu> How did we get here?
[08:07] <alan_g> good intentions
[08:08] <alan_g> Good session for the sprint?
[08:10] <duflu> alan_g: Sounds like a session we've had (multiple times?) before
[08:10] <duflu> Not sure I want to go through that again
[08:10] <RAOF> This seems like a different session?
[08:11] <RAOF> “How can we make it so that mirclient (a) exports no C++ symbols and (b) is standalone”?
[08:11] <RAOF> I don't think we've asked that before.
[08:11] <duflu> I thought we kind of had tests for it?
[08:11] <duflu> Or similar...
[08:11] <alan_g> And (c) how do we make a stable server ABI?
[08:11] <duflu> Making sure it doesn't re-export mircommon
[08:12] <alan_g> The stuff MirAL actually uses from mircommon actually should be stable
[08:12] <duflu> You can use anyone else's API/ABIs in your headers if they are version < 3. Otherwise (if they are ours) then maybe not
[08:13] <alan_g> To make 3rd-party platforms viable they need a stable ABI from mircommon
[08:13] <alan_g> To make 3rd-party server viable they need a stable ABI from mircommon + miral
[08:13] <duflu> We break libmirplatform often too
[08:13] <alan_g> Yep, all part of the big question
[08:14] <duflu> BTW, I just logged some relevant bugs
[08:14] <alan_g> I think we're now at a point where it is feasible, and getting important enough
[08:14] <RAOF> An alternative: we ask legal to get the appropriate verbiage to make it clear that loadable platform modules *aren't* covered by the GPL, and then not expect them to link to mircommon.
[08:15] <alan_g> mircommon provides stuff like "Rectangles" that we should be able to make stable
[08:15] <RAOF> Absolutely.
[08:15] <RAOF> Which is why having modules expect the server to supply those symbols is perfectly sensible :)
[08:16] <RAOF> Actually, if mirclient stops linking with mircommon then we lose the pressure for mircommon to be the things common to client and server.
[08:16] <duflu> BTW I've tried some experiments intentionally breaking things. Turns out a full wildcard * does not break existing symbols, but a partial one like ReadableFd does.
[08:17] <RAOF> Which would make stripping out all the bits which *aren't* super-stable easier.
[08:17] <duflu> I would also like to build one libmir* of everything with all symbols for testing, and then strip the private bits. No more object libs
[08:17] <alan_g> I don't see a problem with linking to mircommon + mirplatform - we "just" need to ensure they only publish stable stuff.
[08:18] <RAOF> Yeah, that's right.
[08:18] <duflu> Remind me why mirplatform exists?
[08:18] <RAOF> One of the current problems is that mircommon is that stable stuff, *plus* the bits shared between server and client that we actively change.
[08:19] <alan_g> To define the interface between server and platform
[08:19] <alan_g> (in an LGPL library)
[08:19] <duflu> alan_g: Remember we have the graphics and input ABIs which are different to mirplatform
[08:19] <alan_g> Follows from long discussions with legal
[08:20] <duflu> Oh. Too lawyerish for a Friday
[08:20] <RAOF> Yeah; again, an alternative would be an explicit grant of “no, your modules don't need to be GPL”
[08:20] <alan_g> Yeah, we'll not solve it here
[08:21] <alan_g> One of the current problems is that mircommon is that stable stuff, *plus* the bits shared between server and client *and platform* that we actively change.
[08:23] <RAOF> And one of the problems there is that I fully expect us to change the *platform ABI* reasonably frequently.
[08:23] <duflu> Another reason why I would prefer our namespaces followed the library names... so you could also find #include "mir/common/*"
[08:23] <RAOF> (For example: I don't think there's *ever* been an Xorg release that didn't change the graphics ABI)
[08:23] <alan_g> I think we now have enough platforms to shake out the right abstractions
[08:23] <duflu> RAOF: Xorg has the benefit of less frequent releases
[08:24] <duflu> Slightly
[08:24] <RAOF> duflu: Yes. I absolutely don't expect us to be bumping our platform ABI every release. But once a year seems perfectly plausible.
[08:24] <RAOF> Now, our platforms are doing an easier job for us than Xorg's platforms, but still.
[08:24] <duflu> RAOF: A separate stable trunk to save up those breaks?
[08:25] <RAOF> Support >1 ABI.
[08:25] <duflu> Or that
[08:25] <RAOF> We've got it all set up so that we can (reasonably easily) do that!
[08:25]  * RAOF EOD. For the moment.
[08:25] <duflu> Or dinner
[08:39] <duflu> alan_g: A bug that exists in mir_proving_server can't be MirAL can it?
[08:39] <duflu> Or can it
[08:39] <alan_g> They could have the same bug
[08:40] <alan_g> But MirAL code isn't in proving_server
[08:41] <duflu> Indeed
[08:42] <duflu> So bug invalid for MirAL
[13:05] <alf_> Saviq: greyback: Hi! How do apps tell unity8/qtmir that they want to keep the display on? Is it done through QT?
[13:22] <greyback> alf_: not through Qt itself, I think people use the dbus api that powerd offers to keep the display on
[13:23] <alf_> greyback: ok, how is losing focus handled?
[13:23] <greyback> alf_: I *think* we trust the application to be good
[13:23] <greyback> I'd need to look into it
[13:23] <greyback> going off old memories here
[13:25] <alf_> greyback: thanks, this came up again because I am working on the snap interface for keeping the screen on, and wasn't sure if things had changed.
[13:26] <greyback> no changes afaik
[13:27] <alf_> greyback: Ideally, as discussed in the past such requests should be sent to Unity8, and then unity8 can decide what to do depending on form factor, focus etc
[13:27] <greyback> alf_: correct
[13:27] <greyback> but nothing has happened on that front
[13:28] <alf_> greyback: yeah, I will update the snap iface to work with what's currently in place and we can revisit the topic (perhaps in the sprint)
[14:51] <alan_g> bschaefer: as my pointer confinement guru - could you check the miral integration? https://code.launchpad.net/~alan-griffiths/miral/confine_pointer/+merge/306635
[14:52] <bschaefer> alan_g, yes!
[14:53] <bschaefer> looks nice
[14:54] <bschaefer> the only thing /me trying to remember if you'll need to specifically do something on a window creation spec for confinement
[14:54] <bschaefer> alan_g, also how come you have to do the #if?
[14:55] <alan_g> miral presents the same API/ABI on xenial as on yakkety
[14:55] <alan_g> But xenial is on Mir-0.22
[14:55] <bschaefer> o dang /me hopes it wont become an #if nightmere :|
[14:55] <bschaefer> nightmare*
[14:56] <bschaefer> alan_g, without actually testing it looks good to me (have you tried out the example?)
[14:56]  * alan_g is only supporting LTS, Yakkety, and lp:mir
[14:57] <alan_g> bschaefer: not yet
[14:57]  * alan_g remembers not knowing what the example should do
[14:57] <bschaefer> alan_g, i can re-compile and test it out after the standup
[14:57] <bschaefer> alan_g, i made a mir demo :) (mir_demo_client_pointer_confinement)
[14:58] <alan_g> I remember not knowing what to expect from that
[14:59] <bschaefer> alan_g, o .. right well you should be able to move the red square for ever when pointer confinement is on
[14:59] <bschaefer> when its off your cursor will go our of the screen boundary
[15:01] <alan_g> I need something more recent that 0.24 don't I?
[15:03] <bschaefer> alan_g, yeah there are some changes in 0.25 that fixed some pointer confinement issues
[15:03] <bschaefer> mainly with WM stuff
[15:03] <bschaefer> moving/resizing etf
[15:03] <bschaefer> etc*
[15:04] <alan_g> I mean for the demo
[15:04] <bschaefer> alan_g, hmm i thought the demo was in 0.24 but i only have trunk mir branch /me checks
[15:05] <alan_g> bschaefer: could you try it then - miral builds much faster
[15:06] <bschaefer> alan_g, yeah i must have been compiling a chunk of mir not miral when i mention it the other day (took less then a min for miral)
[15:06] <bschaefer> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/examples/pointer_confinement.c
[15:06] <bschaefer> alan_g, but yeah ill test after standup
[15:43] <alan_g> bschaefer: well, it seems to do something
[15:43] <bschaefer> alan_g, haha thats good (was answering an OSK)
[15:43] <bschaefer> alan_g, theres hot keys to disable pointer confinement
[15:43] <bschaefer> p i think
[15:44] <alan_g> Yes, I had to read the code. and "F" to toggle fullscreen (What happened to F11?)
[15:44] <bschaefer> alan_g, umm me breaking the standard :)
[15:45] <alan_g> Yes, you ignore "close the window" too
[15:45] <alan_g> ;)
[15:46] <bschaefer> haha
[15:46] <bschaefer> i thought i put q back in
[15:46] <bschaefer> or tried to filter those events through...
[15:46] <bschaefer> (do the underlying handle event)
[15:47]  * bschaefer compiling now
[15:48] <bschaefer> alan_g, umm invalid free / next
[15:48]  * bschaefer checks things
[15:49] <bschaefer> huh using 0.24 but i tihnk i compiled against 0.25 for some reason
[15:50] <alan_g> I mean mir_event_type_close_surface
[15:50] <bschaefer> alan_g, o ... that would have been something to use
[15:50] <alan_g> It's only an example, but...
[15:51] <bschaefer> yeah i like examples to be just as good as our code
[15:51] <bschaefer> (mainly people look at examples to write their code)
[15:54] <bschaefer_> that was strange..
[15:55] <alan_g> ldconfig?
[15:56]  * bschaefer_ doesnt understand joke
[15:56] <bschaefer_> alan_g, i hit that mirshell session next thing
[15:57] <bschaefer_> (possibly) where input didnt work but went to a tty to attempt to step through it and once i hit the tty hot keys my machine just stopped
[15:58] <alan_g> bschaefer_: that's an evil bug.
[15:58] <bschaefer_> yeah... im trying to get you more info
[15:58] <bschaefer_> alan_g, i seem to hit it only using the x11 platform
[15:59] <alan_g> then possibly one for camako
[15:59] <bschaefer_> possibly just need more info before i can really poke anyone :(
[15:59] <bschaefer_> a way to reproduce would be nice :)
[16:00] <alan_g> yes, might mir-trunk related - which I don't use be default
[16:00] <bschaefer> alan_g, very true i use trunk mir
[16:00] <bschaefer> could be an ABI issue as well?
[16:00] <bschaefer> no
[16:00] <bschaefer> that would cause a crash...
[16:00] <alan_g> *probably*
[16:00] <bschaefer> i suppose if it ... somehow ABI match the bytes to a different function...
[16:01] <bschaefer> haha that would be funny...
[16:18] <anpok_> i think thats because the x11 platform tries to grab the keyboard?
[16:20] <alan_g> probably need to ssh in from another computer
[16:22] <bschaefer> alan_g, i was lucky to get into a tty for that current backtrace we have... but it froze this last time
[16:22] <bschaefer> anpok_, could be, the strange thing all mouse events work fine
[16:23] <bschaefer> (it just almost feels like the mir shell keeps grabbing focus ... ie keyboard grab?)
[16:56] <alan_g> bschaefer: http://voices.canonical.com/alan.griffiths/2016/09/23/debugging-mir-servertoolkit-interactions/
[16:57] <bschaefer> alan_g, sweet thanks i will be using this!
[16:57] <bschaefer> for more debugging info for reports
[16:58]  * bschaefer will be sure to include logs for reports as well
[16:58] <alan_g> :)