| duflu | bschaefer: SDL demos working better now? | 02:52 |
|---|---|---|
| bschaefer | duflu, been digging into other issues with it atm :( | 02:53 |
| bschaefer | duflu, hopefully soon! | 02:53 |
| 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:55 |
| RAOF | Not as far as I'm aware? | 05:56 |
| 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 | 05:59 |
| duflu | I already verified the only diff to development-branch was the changelog | 06:00 |
| duflu | So low risk | 06:00 |
| Saviq | duflu, stuff's in trunks now | 07:06 |
| 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:07 |
| Saviq | duflu, well, it only migrated 2h ago | 07:08 |
| Saviq | and there was no one to push the button, is all | 07:08 |
| duflu | Saviq: Cool. Everything is *clean* again | 07:10 |
| Saviq | duflu, kk | 07:10 |
| alan_g | greyback: do you have an opinion on https://code.launchpad.net/~alan-griffiths/mir/spike-shell-namespace/+merge/216332? | 08:49 |
| 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. | 08:51 |
| 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:07 |
| duflu | Anyone got bright ideas not already mentioned in: https://bugs.launchpad.net/mir/+bug/1293944 ? | 09:17 |
| ubot5 | Ubuntu bug 1293944 in Mir "Mir deb packages with versioned names cannot be installed simultaneously any more" [Medium,Triaged] | 09:17 |
| duflu | That's really a bug that's not solved until multiple releases are out... | 09:17 |
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| racarr__ | Morning | 13:55 |
| mterry | kgunn, is there not an open bug about Mir and deleting its stale sockets before using them? | 13:59 |
| kgunn | mterry: there is | 14:00 |
| mterry | couldn't find one searching for 'socket' | 14:00 |
| 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:01 |
| kgunn | alf_: ^ we should address this with the core log upload/exception right ? | 14:02 |
| 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:03 |
| alan_g | mterry: there's a closed one | 14:04 |
| 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:08 |
| 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:09 |
| * alan_g has to go look | 14:10 | |
| alan_g | mterry: it was fixed at -r 1560 on development-branch. Which is in 0.1.9 (according to lp:1285215) | 14:14 |
| mterry | alan_g, ah. Well I will reflash and retry then. I love when things are fixed right before I ask about them! :) | 14:15 |
| alan_g | You're lucky - I'm of the opinion that if you "kill -9" you're responsible for cleaning up the mess. | 14:16 |
| 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:17 |
| mterry | kgunn, it's available from devel-proposed now | 14:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| kgunn | alan_g: yeah...for some reason i thot we hadn't addressed the abort case, i just got lost :) | 14:25 |
| alan_g | kgunn: you're thinking of bug 1235159 (fixed in 0.0.15) | 14:26 |
| ubot5 | bug 1235159 in mir (Ubuntu) "Mir fails to start if there's a stale socket" [Medium,Fix released] https://launchpad.net/bugs/1235159 | 14:26 |
| 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:39 |
| dednick | alan_g: thanks, i'll take a look | 14:40 |
| alan_g | kgunn: "dirty and unpleasant" | 14:40 |
| mterry | alan_g, kgunn: yay, socket reusing seems perfect | 14:41 |
| === alan_g is now known as alan_g|tea | ||
| kgunn | mterry: thanks for that validation! | 14:41 |
| 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:45 |
| 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:46 |
| === alan_g|tea is now known as alan_g | ||
| 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:48 |
| 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:49 |
| 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:51 |
| mterry | alan_g, agreed | 14:52 |
| mterry | camako, also welcome! :) | 14:52 |
| 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:53 |
| 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:54 |
| camako | mterry, got it.. So in a bare bones scenario a nested server needs to get lifecycle events from the system server | 14:55 |
| 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:56 |
| 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:57 |
| 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! :) | 14:58 |
| 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:00 |
| 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:01 |
| 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:02 |
| mterry | alan_g, if this is sufficient, you don't care about the mirserver connection exposing? | 15:03 |
| === chihchun_afk is now known as chihchun | ||
| 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:04 |
| 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:05 |
| fginther | greyback, apologies for the delay in getting those devel branches added. | 15:23 |
| racarr__ | Do you guysn want to opaquify client library structs | 15:27 |
| 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:28 | |
| 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:29 |
| 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:30 |
| 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:31 |
| greyback | fginther: no worries | 15:32 |
| 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:36 |
| racarr__ | kgunn: :D | 15:37 |
| 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:38 |
| 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:39 |
| === josharenson is now known as josharenson|bike | ||
| 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:57 |
| fginther | greyback, I'm ready to enable the jobs, but just wanted you to know there might be some failures initially | 15:58 |
| greyback | fginther: that's ok, that failure is expected | 16:37 |
| === alan_g is now known as alan_g|EOD | ||
| 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! | 16:38 |
| racarr__ | kgunn: I just realized opaquify clients | 17:41 |
| racarr__ | may be something else lol | 17:41 |
| racarr__ | i.e. make clients opaque | 17:41 |
| racarr__ | nvm | 17:42 |
| racarr__ | read on launchpad | 17:42 |
| === slvn_ is now known as slvn|away | ||
| === josharenson|bike is now known as josharenson | ||
| racarr__ | Lunch! | 19:05 |
| racarr__ | Back | 19:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!