[00:59] <RAOF> <alan_g[m]> "Interesting. That implies Mir'..." <- This *might* be a `zwp_linux_dmabuf`-exposed bug, then? That's the most obvious candidate for how a new *sever* mesa could result in client-visible changes.
[08:10] <alan_g[m]> <RAOF> "This *might* be a `zwp_linux_dma..." <- Did you also read the discussion in the bug report?
[09:07] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2511](https://github.com/MirServer/mir/pull/2511): Clean up legacy feature checks
[10:01] <alan_g[m]> Saviq, this looks like an explanation: https://github.com/MirServer/mir-kiosk-kodi/issues/32#issuecomment-1192402735
[10:03] <alan_g[m]> Something in the Kodi client is abusing the wl_drm protocol, and the server side got stricter
[10:03] <Saviq> Ok so a Kodi ~bug (not unexpectedly)?
[10:03] <Saviq> That.
[10:03] <alan_g[m]> Interestingly though, it is fixed in the 22.04 archive
[10:04] <alan_g[m]> And the snap pulls Kodi from upstream
[10:04] <Saviq> Probably some intermediate lib
[10:05] <Saviq> A candidate for `graphics-core22` potentially 
[10:13] <alan_g[m]> Probably not: I tried building mir-kiosk-kodi without the upstream PPA and that also fails
[10:17] <alan_g[m]> Sounds like we need a 20.0 track for mesa-core20, and then promote 21.2 to stable
[10:18] <alan_g[m]> *21.0
[10:18] <Saviq> Uhh. I'd rather find a working Kodi? You say the one from the archive does work?
[10:19] <alan_g[m]> The one from 22.04 works, the snap build from 20.04 archive (without upstream) doesn't
[10:20] <Saviq> Right, which is why I said it's a candidate for graphics-core22, so we pull in Kodi from the archive
[10:20] <alan_g[m]> Actually, "works" only in this context. Plugins like "iPlayer" (useful in UK) don't install
[10:21] <Saviq> Meh.
[10:22] <alan_g[m]> Currently, I don't think we are ready for graphics-core22
[10:24] <alan_g[m]> I'm more concerned that if we promote 21.2 to stable "something out there" will also fail. mir-kiosk-kodi isn't important to me (except as a testing ground)
[10:29] <Saviq> Right. Would be interesting to know what exactly breaks it? Like, it's probably not Kodi itself, but a dependency, and we could maybe work out a fix
[10:33] <alan_g[m]> Yeah. So far as I know wl_drm is internal to mesa, so libegl is likely what actually makes the call the question is why. How much time should we spend spelunking in Kodi?
[10:34] <Saviq> I more thought that the spelunking in Kodi would hopefully yield a solution to anything else failing out there
[10:34] <alan_g[m]> OK, I have an hour or two this week
[10:35] <Saviq> And by "a fix" I meant a built of newer $lib (libegl, maybe)
[10:35] <Saviq> *build
[10:36] <alan_g[m]> Or just revert the libegl change to allow spurious `authenticate` calls?
[11:01] <Saviq> But that we'd need to revert in Mesa?
[11:24] <alan_g[m]> Well, it looks like Kodi is calling drmAuthMagic() directly: https://github.com/xbmc/xbmc/blob/master/xbmc/windowing/gbm/drm/DRMUtils.cpp (I've not established if that's the interesting call but...)
[11:31] <Saviq> But… that's when running sans compositor I think?
[11:33] <Saviq> The wayland windowing system (https://github.com/xbmc/xbmc/tree/master/xbmc/windowing/wayland/) has no direct DRM calls I can find…
[11:36] <Saviq> These are the only two references in there: https://github.com/xbmc/xbmc/blob/ed4003583e54aa3699430e2830a5dd97ffb634d6/xbmc/windowing/wayland/WinSystemWaylandEGLContextGLES.cpp#L47-L48
[12:51] <alan_g[m]> So, probably somewhere like libwayland-egl...
[13:01] -GitHub[m]:#mir-server- **[MirServer/ubuntu-frame]** AlanGriffiths edited [issue #77](https://github.com/MirServer/ubuntu-frame/issues/77): If aa_getpeercon() fails then ubuntu-frame-* client snaps don't work with default configuration
[13:01] -GitHub[m]:#mir-server- **[MirServer/ubuntu-frame]** AlanGriffiths added enhancement and removed question from [issue #77](https://github.com/MirServer/ubuntu-frame/issues/77): If aa_getpeercon() fails then ubuntu-frame-* client snaps don't work with default configuration
[13:03] -GitHub[m]:#mir-server- **[MirServer/ubuntu-frame]** AlanGriffiths edited [issue #77](https://github.com/MirServer/ubuntu-frame/issues/77): If aa_getpeercon() fails then ubuntu-frame-* client snaps don't work with default configuration
[13:16] <Saviq> alan_g I'm actually eyeing libva-wayland, as this error happens at a stage where normally libva backends are probed
[13:17] <Saviq> And that would also explain why Kodi is the first time we're seeing this
[13:18] <alan_g[m]> That sounds very plausible
[13:27] <alan_g[m]> https://bugs.launchpad.net/ubuntu/+source/libva/+bug/1961484
[13:30] <alan_g[m]> And that has a PPA to try...
[13:41] <alan_g[m]> ...and adding ppa:wsnipex/vaapi to the snap fixes things
[14:39] <alan_g[m]> Saviq mir-kiosk-kodi fix available: edge/pr33
[14:42] <Saviq> :ack:ed
[14:42] <Saviq> So re: mesa-core20, we should do a call for testing referencing this issue I think
[14:43] <alan_g[m]> Agreed
[14:43] <Saviq> As for updating it… I'd imagine we would only get security updates from now on, on which we would get notified by the store?
[14:44] <Saviq> Alternatively I could tweak the snaps workflow in GH to monitor
[14:44] <alan_g[m]> I think mesa gets hwe updates too
[14:44] <Saviq> Right, that's what hit us this time, wasn't it
[14:46] <alan_g[m]> Agreed. (And that the update broke libva in archive)
[14:51] <Saviq> I could work out a mir-kiosk-kodi test in the lab triggered on mesa-core20
[14:54] <alan_g[m]> That would be good. I'll write a CfT once the rebuilds are done (and aim to promote Monday week)
[15:10] <alan_g[m]> I just realised that I'm assuming you're OK with pushing the kodi update to stable this aftermoon
[15:14] <Saviq> Totally, yes, have tested
[20:54] <sophie-w> A while ago I talked with RAOF (he/they) about the possibility of automating symbol generation (both symbols.map and debian/*.symbols) from code annotations. At the time we considered using libclang, and it seemed rather impractical. Recently, I realized we were already doing a similar thing with doxygen for miral, and I've been prototyping a more complete version of that. Hope to have a prototype up soon.
[23:09] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww drafted [pull request #2517](https://github.com/MirServer/mir/pull/2517): Auto generate symbols map
[23:09] -GitHub[m]:#mir-server-  
[23:09] -GitHub[m]:#mir-server- > WIP attempt to auto-generate symbols.map and debian/*.symbols files based on doxygen data. Only file it tries to generate so far is miral/symbols.map, and that isn't complete enough to work yet.
[23:11] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww drafted [pull request #2518](https://github.com/MirServer/mir/pull/2518): Add tools/scan_symbols.py script
[23:11] -GitHub[m]:#mir-server-  
[23:11] -GitHub[m]:#mir-server- > Given the path to a .so file, this script will compare the symbols in the library with the symbols in the debian symbols file and show the symbols only present in one or the other. Not perfect, but makes manually editing symbols easier.
[23:11] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww marked [pull request #2518](https://github.com/MirServer/mir/pull/2518): Add tools/scan_symbols.py script as ready for review