[03:41] <duflu> RAOF: When I sleep the phone clients correctly scale down to 10Hz. Do we have sleep/resume messages yet?
[03:42] <duflu> ... because obviously clients should be told to sleep properly
[03:42] <RAOF> I believe so?
[03:43] <duflu> RAOF: I don't see any Mir*Event
[03:44] <duflu> Oh hang on
[03:45] <duflu> No, can't see it
[03:51] <duflu> RAOF: Were we planning on utilizing any GL error codes?
[03:51] <RAOF> No
[03:51] <duflu> Or does that require Khronos changes/blessing?
[03:51] <RAOF> We could absolutely do it, but I think we ended up deciding that it's not an EGL thing.
[03:52] <duflu> OK. What I do remember is that argument being complex enough I don't want to remember it right now
[04:57] <RAOF> Man, this is going to provoke conflicts with _everything_
[05:16] <RAOF> Oh, _arse_
[05:16] <RAOF> We can't hide anything.
[05:19] <RAOF> Because we expect (server) clients to subclass DefaultConfiguration, which means they need to be able to resolve everything that DefaultConfiguration includes.
[05:39] <RAOF> Hm.
[05:39] <RAOF> Doesn't that make much of the headers in src/ implicitly ABI?
[05:40] <RAOF> (The _best form_ of ABI)
[07:12] <duflu> RAOF: Hey it looks like Android-input drops/deduplicates events when we're not keeping up
[07:12] <duflu> That's good... we don't have to do anything
[07:12] <RAOF> Huzzah!
[07:15] <RAOF> Sweet. So, I very nearly have a libmirclient with an ABI equal to the ABI we expect to expose..
[07:42] <alf_> RAOF: @break-out-rpc-transport, so ancillary socket data are queued separately from normal socket data?
[07:42] <RAOF> alf_: Correct.
[07:42] <RAOF> It's all very complicated.
[07:43] <RAOF> If you sendmsg(300 bytes, 1 fd), send(300 bytes) and recvmsg(600 bytes, <some fds>, MSG_WAITALL) your recvmsg will read 300 bytes and 1 fd.
[07:43] <RAOF> If you sendmsg(300 bytes, 1 fd), send(300 bytes) and then recv(301 bytes), you'll (a) receive 301 bytes, and (b) never be able to get at that fd.
[07:44] <RAOF> For added annoyance, if you recvmsg(300 bytes, <some fds>, MSG_WAITALL) *and get interrupted* you'll receive some data < 300 bytes and an fd, and your next recvmsg will receive the fd again.
[07:45] <RAOF> That seems likely to be a bug, though.
[07:48] <alf_> RAOF: What about MSG_TRUNC ? Is this when we sendmsg(300,2) and recvmsg(300,1) ?
[07:48] <RAOF> MSG_CTRUNC, yeah.
[07:49] <RAOF> Well, as long as you haven't run into CMSG_SPACE aliasing :)
[07:51] <alf_> RAOF: (trying to understand how queuing ancillary data works), if we sendmsg(300,1) and recv(299) is the fd lost?
[07:52] <RAOF> I don't think so, no.
[07:52] <alf_> RAOF: or do we need to move on reading to a subsequent message for the fds to be discarded
[07:52] <RAOF> We need to move on to reading a subsequent message.
[07:53] <RAOF> I don't think there's a test for that behaviour in the unit tests, though.
[07:54] <alf_> RAOF: I wonder how the fd-data association is maintained since we are using a stream socket, so no strict message boundaries
[07:55] <RAOF> alf_: There are message boundaries in the kernel.
[07:55] <alf_> RAOF: true
[07:55] <RAOF> Internally it's got a bunch of skbs, and SOCK_STREAM just reads on to the next one when the current one's done.
[08:01] <alan_g> RAOF: I don't need to keep you late, but if you have time to help with packaging...
[08:01] <RAOF> alan_g: Just commenting now :)
[08:09] <RAOF> alan_g: Oh, and other than the CI failure bit, the packaging seems fine.
[08:09] <alan_g> RAOF: thanks for looking.
[08:14] <RAOF> alan_g: By the way, I've stripped all those symbols out of libmirclient locally by way of symbol visibility; we could probably do the same for libmirplatform..
[08:15] <alan_g> RAOF: but what about client code that needs the symbols?
[08:15] <alf_> RAOF: how does that work with testing (where we may need access to some of the internal symbols)?
[08:15] <RAOF> alf_: I build a couple of things twice.
[08:16] <RAOF> alan_g: What client code would need those symbols?
[08:18] <alan_g> RAOF: Hmm. I was assuming that as the headers were published they were already needed in our public API
[08:18] <RAOF> Right, but not from libmirclient.so
[08:19] <alan_g> And we do use them in examples of "how to use Mir"
[08:20] <RAOF> But, again, not from libmirclient.so
[08:20] <RAOF> These symbols aren't being hidden from libmirserver.so, but we were *also* exporting them from libmirclient.so.
[08:23] <alan_g> Hmm. So we could put them all into libmirplatform (and export then) and also put the ones used into libmirclient that it uses (internally). That could avoid the new lib
[08:24] <alan_g> Could we also remove mircommon-dev from libmirclient-dev?
[08:24] <RAOF> Possibly?
[08:24] <RAOF> EOD for me today though, sorry.
[08:25] <RAOF> I'll push the branch
[08:25] <RAOF> You're looking for lp:~raof/mir/symbols-file. It's still a little WIP.
[08:29] <alan_g> RAOF: ak
[08:31] <alf_> RAOF: scenario sendmsg(300, 1) sendmsg(300,1) recvmsg(300, 0) recvmsg(0, $Y) Y == ?
[08:33] <alf_> RAOF: i.e. if we ask for Y=1 fd will we get MSG_CTRUNC, or do we need to read at least one more byte to get into the next msg in order to get access to the second message's fd?
[08:33] <alf_> RAOF: I guess we need to experiment
[13:19] <alan_g> mterry: After emailing you I removed the "Conficts:" to see if CI would then work.
[13:19] <mterry> alan_g, ah ok
[13:21] <alan_g> AFACS the build script is using dpkg directly. BUt I don't know much about it
[13:44] <alf_> anpok: You mentioned something about showing the previous frame instead of current?
[14:00] <alan_g> mterry: I need advice. Removing "Conficts:" seems to satisfy CI (but is probably lying), and some documentation suggests "Break:" as a possible alternative.
[14:04] <mterry> alan_g, yeah...  Breaks is I think generally recommended over Conflicts except in some cases I can't remember. But the documentation I was looking at used Conflicts so I recommended that on to you
[14:04] <mterry> I'm honestly not super clear on the difference
[14:05] <alan_g> mterry: how bad is it to have neither?
[14:06] <mterry> alan_g, if they share files, it is bad but I don't quite know in which circumstances it will break
[14:07] <mterry> alan_g, one of those things I've never gone against recommendations for :)
[14:08] <alan_g> I'll try "Breaks" and see if CI breaks. If it works I know what to do. If it fails... I'll consult another expert (RAOF)
[14:19] <anpok> alf_: yes
[14:19] <anpok> it was best to notice inside the pin entry dialog
[14:20] <anpok> I had a devel-proposed image + qt comp silo, removed the silo then upgraded
[14:20] <anpok> i mean I upgraded the image..
[14:21] <anpok> and it was easy to reproduce in the pin entry
[14:21] <anpok> after another round of flashing devel-proposed the issue is gone
[14:43] <camako> mterry, once upon a time you asked for nested lifecycle event support :
[14:43] <camako> https://code.launchpad.net/~cemil-azizoglu/mir/nested_lifecycle_events/+merge/224426
[14:54] <kgunn> in a galaxy far far away
[15:36] <tedg> dednick, So I thought when we were talking with mdeslaur that we wanted the second socket AND a list of people to connect.
[15:36] <tedg> The second socket takes care of the connection restriction aspect.
[15:36] <tedg> But we still want to know who is connecting and if they're someone we expect.
[15:37] <tedg> That being said, that was my understanding, if mdeslaur is willing to sign off on not having the list, I'm happy not having to make it. :-)
[15:37] <mdeslaur> there's not way of validating the list
[15:37] <mdeslaur> we assume whatever is connecting there is trusted
[15:38] <dednick> tedg: ^ yeah. no point if you can get around it...
[15:38] <mdeslaur> tyhicks could confirm
[15:41] <tedg> K
[15:41] <tedg> It seems a bit odd to me.
[15:42] <tedg> I guess in the future we'll restrict that socket to only being able to make trusted prompt sessions.
[16:06] <racarr__> Morning