[01:32] <duflu> Oh, utopic got 0.7.0 already. Nice.
[01:32] <duflu> camako: !
[03:08] <RAOF> SIGHUP? Really?
[03:20] <duflu> RAOF: Well, it was better than SIGTERM (which we had previously). Next step: Someone propose some nice error returns instead
[03:21] <duflu> Although that's possibly a client API change
[03:21] <RAOF> Clients can already handle that.
[03:21]  * RAOF actually quite liked SIGTERM
[03:21] <RAOF> I don't think it _is_ better than SIGTERM, although SIGPIPE is probably the best choice of a bad bunch.
[03:22] <duflu> RAOF: Yeah I tried SIGPIPE, and for weird reasons it interacted with the socket code causing strange unreproducible test failures
[03:22] <duflu> But feel free to continue to improve/change it
[03:23] <RAOF> What was wrong with sigterm, anyway?
[03:23] <RAOF> SIGHUP _means_ something.
[03:23]  * RAOF lunches.
[03:23] <duflu> RAOF: Per the description: http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/1881
[03:24] <duflu> Apps need to distinguish between expected/desired and unscheduled/unexpected shutdowns
[03:34] <RAOF> Then they can hook up a lifecycle callback and get disconnected results.
[05:51] <duflu> RAOF: OK. I'm not familiar with "lifecycle" stuff. It must have crept in when I wasn't looking. Although you still need a default behaviour too...
[05:52] <duflu> Which is at least now not spinning or crashing. That's an improvement :)
[05:52] <RAOF> Right; the default behaviour we had was SIGTERM, which seems reasonable to me; if not that, then SIGPIPE because that's what you get from everyone else (X11 & Wayland, particularly).
[05:53] <duflu> RAOF: During the code review I think we all preferred SIGPIPE. If you can change it and figure out why it was causing weird CI failures then go ahead
[07:46] <RAOF> alf_: UsingStubClientPlatform *doesn't* stub out the client platform, though.
[07:51] <alf_> RAOF: how so?
[07:52]  * alf_ reads code again
[07:52] <RAOF> alf_: I've expounded on the MP.
[07:52] <RAOF> But basically, prev_api->connect() is not going to call StubMirConnectionAPI's configuration().
[07:53] <RAOF> It's going to call DefaultMirConnectionAPI's configuration()
[07:56] <alf_> RAOF: oh, you are right... completely inheritance fail there :)
[08:04] <RAOF> Well, that's a nice change of pace.
[08:04] <RAOF> The non-android CI bits fail. :(
[08:49] <anpok_> i need an opinion on checking for egl extensions
[08:52] <alf_> anpok_: ?
[08:52] <anpok_> currently we throw when mesa_drm_image is not available
[08:52] <anpok_> but we do not use the API provided by that extension
[08:54] <anpok_> i came across a driver that does not suppor the api of that extension.. yet mir works
[08:54] <anpok_> so I changed that to egl_khr_image_pixmap
[08:54] <anpok_> but on some configurations that extension is not advertised either..
[08:55] <anpok_> while it works..
[08:56] <anpok_> in theory mesa_drm_image is a good indication since it requires the image loader dri extension to be available
[08:56] <anpok_> which we need internally inside the mesa mir platform..
[08:57] <anpok_> i kind of alternate between checking for those extension above but warning only vs dropping the extension check entirely
[08:59] <anpok_> oh i could also find and fix all driver setup combinations that might falsly claim that the extensions do not work
[09:14] <alf_> anpok_: well, ideally we should fix the drivers and remove the mesa_drm_image check from mir
[09:15] <alf_> anpok_: which drivers have such an issue?
[09:16] <anpok_> missing mesa_drm_image is with kms-swrast
[09:17] <anpok_> the other extension - I have not investigated it happens with intel drivers but never looked exactly when and how
[09:19] <alf_> anpok_: I would say we drop the mesa_drm_image extension check, keep the egl_khr_image_pixmap check
[09:19] <alf_> anpok_: and look at what's wrong (if anything) with the intel drivers
[09:37] <Saviq> guys, is it possible that new Mir played bad with keyboard input on the device (as in evdev, not vkb)
[09:38] <alf_> Saviq: everything is possible (not sure how likely, though), what problem are you seeing?
[09:49] <Saviq> alf_, verifying now, but no autopilot key strokes reach the text entry
[09:49] <Saviq> alf_, flashed 217 now so will know in a moment
[09:56] <Saviq> that worked, /me upgrades
[09:56] <alf_> Saviq: worked => no keyboard problem?
[09:56] <Saviq> alf_, yeah
[09:57] <alf_> Saviq: ok, good :)
[09:57] <Saviq> alf_, well, not good, yet, upgrading to new Mir now ;)
[10:08]  * alf_ can't recreate any of the non-android CI failures we are seeing, going to update system to see if that helps
[10:08] <alf_> RAOF: ^^ any luck with these?
[10:22] <Saviq> alf_, ok, you guys are off the hook, something weird's happening on our packages
[10:22] <alf_> Saviq: ack
=== no_mu is now known as Nothing_Much
=== bregma_ is now known as bregma
=== willcooke is now known as willcooke|meetin
=== willcooke|meetin is now known as willcooke
=== desrt|pdx is now known as desrt
=== dandrader is now known as dandrader|afk
=== willcooke_ is now known as willcooke
=== LockeAnarchist- is now known as LockeAnarchist
=== dandrader|afk is now known as dandrader
[16:31] <racarr> Morning!
[16:55] <kdub> hello racarr welcome back
[17:01] <racarr> kdub: Thanks! ... feels a little strange to be at a computer! Reading email is kind of comforting though. How goes settling in michigan?
[17:01] <racarr> How goes Mir? Is it done yet...;)
[17:01] <kdub> pretty good, moved in and all
[17:03] <racarr> Yay
[17:46] <racarr> </catches up on email>
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== dandrader is now known as dandrader|afk
=== LockeAnarchist- is now known as LockeAnarchist
=== dandrader|afk is now known as dandrader