[02:52] <duflu> bschaefer: SDL demos working better now?
[02:53] <bschaefer> duflu, been digging into other issues with it atm :(
[02:53] <bschaefer> duflu, hopefully soon!
[05:55] <duflu> RAOF: Did the packaging branch change in utopic?... https://code.launchpad.net/~mir-team/mir/trunk-0.1.9/+merge/217290/comments/518614
[05:56] <RAOF> Not as far as I'm aware?
[05:59] <RAOF> duflu: https://code.launchpad.net/~ps-jenkins/mir/utopic-proposed
[05:59] <RAOF> Looks like jenkins isn't landing such things to lp:mir?
[05:59] <duflu> Bah, I'll land it anyway
[05:59] <duflu> Since landing nothing or anything else would make us inconsistent
[06:00] <duflu> I already verified the only diff to development-branch was the changelog
[06:00] <duflu> So low risk
[07:06] <Saviq> duflu, stuff's in trunks now
[07:07] <Saviq> duflu, that step (pushing to trunk) needs to be explicitly triggered after packages migrated to release
[07:07] <duflu> Saviq: Oh wow. Something that happened 17 hours ago just showed up
[07:07] <duflu> OK
[07:08] <Saviq> duflu, well, it only migrated 2h ago
[07:08] <Saviq> and there was no one to push the button, is all
[07:10] <duflu> Saviq: Cool. Everything is *clean* again
[07:10] <Saviq> duflu, kk
[08:49] <alan_g> greyback: do you have an opinion on https://code.launchpad.net/~alan-griffiths/mir/spike-shell-namespace/+merge/216332?
[08:51] <greyback> alan_g: I've kept my silence mainly as I don't have a strong opinion. It would indeed be an improvement on today's situation.
[09:07] <alan_g> alf_: FYI we've a CI issue to bug ChrisGagnon about when he surfaces: https://launchpad.net/~chris.gagnon/+archive/mir-demo-tester/+packages says 'mir-demo-tester' is only available for trusty under chrisgagnon's ppas
[09:07] <duflu> Ah good. I was about to mention...
[09:17] <duflu> Anyone got bright ideas not already mentioned in: https://bugs.launchpad.net/mir/+bug/1293944  ?
[09:17] <duflu> That's really a bug that's not solved until multiple releases are out...
[13:55] <racarr__> Morning
[13:59] <mterry> kgunn, is there not an open bug about Mir and deleting its stale sockets before using them?
[14:00] <kgunn> mterry: there is
[14:00] <mterry> couldn't find one searching for 'socket'
[14:01] <kgunn> mterry: actually...there was a fix for cleaning up sockets on a nice shut down....
[14:01] <kgunn> which landed
[14:01] <kgunn> there is another bug
[14:01] <kgunn> for aborted mirs leaving stale socket
[14:01] <kgunn> lemme dig
[14:02] <kgunn> alf_: ^ we should address this with the core log upload/exception right ?
[14:03] <alan_g> kgunn: isn't alf_ on a public holiday?
[14:03] <kgunn> :) dang it...yes
[14:03] <kgunn> i forgot...almost everyone is off today and tomorrow
[14:03] <kgunn> in europe
[14:03]  * alan_g feels left out
[14:03] <kgunn> :)
[14:04] <alan_g> mterry: there's a closed one
[14:08] <mterry> alan_g, huh.  I would think stale sockets from crashes still are of interest.  Can't we just do whatever fuser does to tell if it's stale or not and delete if so?
[14:09] <alan_g> mterry: we do
[14:09] <mterry> alan_g, ah nice...  I was testing yesterday and kill -9 left a socket that USC couldn't handle
[14:09] <mterry> alan_g, did that land in latest Mir or is that a bug?
[14:10]  * alan_g has to go look
[14:14] <alan_g> mterry: it was fixed at -r 1560 on development-branch. Which is in 0.1.9 (according to lp:1285215)
[14:15] <mterry> alan_g, ah.  Well I will reflash and retry then.  I love when things are fixed right before I ask about them!  :)
[14:16] <alan_g> You're lucky - I'm of the opinion that if you "kill -9" you're responsible for cleaning up the mess.
[14:17] <kgunn> mterry: robru's email indicated that the latest mir landing 0.1.9 will appear in image#7 which should be later today
[14:20] <mterry> kgunn, it's available from devel-proposed now
[14:21] <kgunn> mterry: ok, i could not find a bug covering the abort stale socket...so if you still hit that, definitely file a bug
[14:21] <mterry> kgunn, alan_g is claiming it's fixed?  I'm testing now
[14:22] <alan_g> kgunn: mterry the bug is 1285215
[14:22] <mterry> alan_g, well, kill -9 isn't that different from a crash eh?
[14:23] <alan_g> mterry: it is - we can (and do) process SIGABRT, SIGSEGV etc
[14:23] <mterry> alan_g, ah cool
[14:23] <alan_g> SIGKILL is special - we can't intercept it in a handler
[14:24] <mterry> alan_g, yup.  But you're saying that the fix handles even that case?
[14:24] <mterry> (by cleaning up on startup?)
[14:24] <kgunn> ah...it was fix-released...
[14:24] <alan_g> Yes. in 0,1,9 which will appear in image#7
[14:25] <kgunn> alan_g: yeah...for some reason i thot we hadn't addressed the abort case, i just got lost :)
[14:26] <alan_g> kgunn: you're thinking of bug 1235159 (fixed in 0.0.15)
[14:39] <alan_g> dednick: in case you think I've forgotten about you... I've a branch that allocates an FD server-side and passes it out to the client here: lp:~alan-griffiths/mir/spike-passing-out-client-fds/ - the code's still a bit manky and probably not immediately useful to you. But it is progress.
[14:39]  * kgunn goes to look up "manky"
[14:39] <dednick> alan_g: ah. i was meaning to ask you about it :)
[14:40] <dednick> alan_g: thanks, i'll take a look
[14:40] <alan_g> kgunn: "dirty and unpleasant"
[14:41] <mterry> alan_g, kgunn: yay, socket reusing seems perfect
[14:41] <kgunn> mterry: thanks for that validation!
[14:45] <camako> mterry, I'm the lucky owner of the enhancement request you've made abt lifecycle event callbacks in a nested config. Can you help me understand the scenario in a bit more detail?
[14:46] <mterry> camako, sure
[14:46] <mterry> camako, and hi!  Not sure I've met you before?
[14:46] <camako> mterry, hi.. No I don't think we've met.. I'm new to the mir team
[14:48] <mterry> camako, so the use case is this: I have a greeter for the phone.  Design wants the greeter to show a little animation when the greeter shows up (both on boot and on screen-on).  The unity-system-compositor (USC) already tries to send its child sessions (greeter & unity8) lifecycle events on screen on/off.  So I thought "OK, I'll listen to that"
[14:48] <mterry> camako, but turns out that nested mirservers don't get those events
[14:49] <mterry> camako, because while mirclient has an API for registering callbacks (in the MirConnection class)
[14:49] <mterry> camako, mirserver can't get access to a MirConnection pointer.  I believe the intention is that it could get one via HostConnection
[14:49] <mterry> camako, but HostConnection is never actually defined in the public headers
[14:51] <camako> mterry, so unity8 is running a nested server right?
[14:51] <mterry> camako, (the reason it needs to be public is because those callbacks are registered in platform-api, so if platform-api can't see them, it can't register the callbacks)
[14:51]  * alan_g has to have a closer look at the "in process" client support. I really should be the same API as "out of process" clients have.
[14:51] <alan_g> *It
[14:51] <mterry> camako, unity8 is yeah.  As is the greeter (I'm working on the set of branches that deals with splitting the greeter out of the unity8 executable and into its own process)
[14:52] <mterry> alan_g, agreed
[14:52] <mterry> camako, also welcome!  :)
[14:53] <camako> mterry, so as things currently stand you have both unity8 and greeter in the same process.. Is greeter a (mir) client of unity8 (mir nested server)?
[14:53] <camako> mterry, sure..
[14:54] <mterry> camako, today on image #7, greeter and unity8 are part of the same process, part of the same code base.  In my branches, to land at a nebulous future date, greeter and unity8 are two processes, but basically both running the same code, just different qml.  So they'll still both be nested server clients of USC
[14:55] <camako> mterry, got it.. So in a bare bones scenario a nested server needs to get lifecycle events from the system server
[14:56] <camako> is my understanding right?
[14:56] <mterry> camako, that would be nice yeah.  The API exists in Mir to send them out, but nested clients of the USC can't register their own callbacks to hear the signals
[14:57] <alan_g> mterry: I don't know if it helps in the architecture you have but...
[14:57] <camako> mterry, ok thanks that helps... Let me read some code, and I'll ping you if I have more questions...
[14:57] <alan_g> You can use the normal "out of process" client API in the same process as a server (we have a bunch of tests that do this) simply by getting a socket from the server and connecting over it.
[14:58] <mterry> alan_g, would that be a second connection to the server or would I then be acting as a "standalone" mir server and a separate mir client?
[14:58] <mterry> camako, sure, sounds good!  :)
[15:00] <alan_g> mterry: You're already spinning up a server right? But you're connecting my some "internal" mechanism I've not looked into.
[15:00] <alan_g> If instead you connect over a socket then you have the "client" API
[15:01] <alan_g> You just call mir_connect("fd:/$fd_number")
[15:01] <mterry> alan_g, well I think we are connecting via an existing socket.  But mirserver doesn't really expose that fact when in nested mode, yeah.  So you're thinking that I could simultaneously do a mir_connect?
[15:01] <mterry> right
[15:02] <mterry> alan_g, OK...  That might unblock me at least.  I can try.  But the bug still stands that I'd have to do such a workaround
[15:02] <alan_g> mterry: this is an "instead" of, not "as well as" idea
[15:02] <mterry> alan_g, whaddya mean?
[15:03] <mterry> alan_g, if this is sufficient, you don't care about the mirserver connection exposing?
[15:04] <alan_g> mterry: I don't know (never dug into) the "internal client" code. But if you don't mind being an "external client" in the same process instead you can use the above approach.
[15:05] <mterry> alan_g, right. I may do that as a short term fix to unblock me.  But I was just saying above that ideally mirserver would just work for this case
[15:23] <fginther> greyback, apologies for the delay in getting those devel branches added.
[15:27] <racarr__> Do you guysn want to opaquify client library structs
[15:28] <racarr__> I started thinking about child surfaces which would require changing surface parameters
[15:28] <alan_g> racarr__: it is on the "TODO" list
[15:28] <racarr__> and I made the cursor configuration an opaque struct (seems likely to break otherwise with addition of rgba data etc)
[15:28] <racarr__> and u m
[15:28] <racarr__> it just seems like a good time to do it
[15:28]  * alan_g waits for kgunn to point to the right blueprint
[15:29] <racarr__> We can first: Add getters/setters, second: port downstreams three: opaquify structs
[15:29] <racarr__> so not much churn for other people
[15:29] <alan_g> Agreed. (that's the "stable intermediate forms" pattern.)
[15:30] <racarr__> Ok I will just submit an MP when I have time unless someone else gets to it first.
[15:30] <racarr__> I thought it had come up in the past but couldnt quite remember
[15:30] <alan_g> LOL
[15:31] <alan_g> It has - we discussed it in December/London
[15:31] <racarr__> Mm
[15:31] <alan_g> We just haven't got to it yet
[15:32] <greyback> fginther: no worries
[15:36] <kgunn> racarr__: you now own "opaquify clients"
[15:36] <kgunn> https://blueprints.launchpad.net/ubuntu/+spec/client-1410-mir-converged
[15:36] <kgunn> alan_g: btw, had a note to myself to ask...are we done with "better and proper update notifications for surfaces" after all the surface rework ?
[15:37] <racarr__> kgunn: :D
[15:38] <alan_g> kgunn: I guess we are. At least it's done on the surface side. (But we're not making use of it on the compositor side - yet.)
[15:39] <kgunn> that was my understanding as well...there, but yet to be harnessed
[15:39] <alan_g> I think greyback may have started using it
[15:57] <fginther> greyback, while testing I found that the platform-api/devel build fails http://s-jenkins.ubuntu-ci:8080/job/platform-api-devel-utopic-amd64-ci/2/console
[15:58] <fginther> greyback, I'm ready to enable the jobs, but just wanted you to know there might be some failures initially
[16:37] <greyback> fginther: that's ok, that failure is expected
[16:38] <fginther> greyback, ok, I'll proceed with deploying the jobs. Please ping the ci channel if you find strange failures after the switch
[16:38] <greyback> fginther: excellent, thank you for doing it!
[17:41] <racarr__> kgunn: I just realized opaquify clients
[17:41] <racarr__> may be something else lol
[17:41] <racarr__> i.e. make clients opaque
[17:42] <racarr__> nvm
[17:42] <racarr__> read on launchpad
[19:05] <racarr__> Lunch!
[19:40] <racarr__> Back