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