[00:17] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2740](https://github.com/MirServer/mir/pull/2740): Make accidentally closing a mir::Fd a compile error
[05:41] -GitHub[m]:#mir-server- **[MirServer/mir]** RAOF opened [pull request #2743](https://github.com/MirServer/mir/pull/2743): Drop server/graphics/gl_extensions_base.cpp; it's dead code
[07:02] -GitHub[m]:#mir-server- **[MirServer/mir]** RAOF opened [pull request #2744](https://github.com/MirServer/mir/pull/2744): Add core mmap-backed SHM handling... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/37ff0fa892ba672d520749e3d82e1633740a9160>)
[08:04] <Saviq> Morn'
[09:07] <alan_g[m]> Morning!
[09:14] <alan_g[m]> Saviq you mentioned you had some logic for automating updates to branches when main changes? Where is it so I can plagiarise?
[09:16] <Saviq> alan_g here: https://github.com/MirServer/ubuntu-frame-vnc/blob/main/.github/workflows/edge.yml - it's quite trivial, but does the trick
[09:16] <Saviq> If you're thinking about iot-example-graphical-snap branches, it should be a simple rebase.
[09:16] <Saviq> Whether you want it to be atomic (fail all branches in case one fails e.g. due to conflicts) is something to decide
[09:20] <alan_g[m]> Actually, this morning I was thinking of ubuntu-frame/mir-build-snap
[09:20] <alan_g[m]> (And that too should be a rebase)
[09:20] <alan_g[m]> Thanks
[09:21] <Saviq> Was thinking the same yesterday :)
[09:21] <Saviq> Could be a composite action… but not sure it's worth the indirection
[09:22] <Saviq> We could move GIT_{AUTHOR,COMMITTER}_{NAME,EMAIL} to the org environment
[09:22] <Saviq> So it doesn't have to be explicit
[09:24] <Saviq> Hmm or maybe we could not, there isn't a global environment, just secrets
[09:24] <alan_g[m]> Maybe I should let you ponder a while?
[09:24] <Saviq> Makes a bit more reason to have a shared action in e.g. MirServer/actions
[09:26] <Saviq> It would save maybe 20 lines in the workflow… will toss a coin…
[09:27] <alan_g[m]> I've simply rebased manually. You are still having design ideas
[09:41] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths edited [issue #2742](https://github.com/MirServer/mir/issues/2742): [clang] we should rework unqualified call to std::move and std::forward
[09:42] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths edited [issue #2742](https://github.com/MirServer/mir/issues/2742): [clang] we should rework unqualified call to std::move and std::forward
[09:46] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq edited [pull request #2741](https://github.com/MirServer/mir/pull/2741): ci: fix working with jammy in GitHub Actions
[09:59] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq assigned  to [pull request #2744](https://github.com/MirServer/mir/pull/2744): Add core mmap-backed SHM handling
[10:07] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq closed [pull request #2645](https://github.com/MirServer/mir/pull/2645): platform/buffer_from_wl_shm: Handle clients immediately destroying the buffer
[10:42]  * Saviq sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/7b65453d9ce23bd6cb6eb4cdc32ff1c727fd8a28
[10:44] <alan_g[m]> I assume "PRs welcome" 🤷
[11:56] <Saviq> Looks like we're a bit lenient on -W in Frame… Also CMake's default should be much more strict :P
[12:37] <alan_g[m]> You're welcome to fix
[12:51] <alan_g[m]> Hey, did we need egmde fixed for 22.04?
[12:52] <Saviq> We didn't, in theory, but I wanted the least changes to Mir CI for base: core22 - if we replace egmde with something else in there, fine
[12:54] <alan_g[m]> OK. Maybe someone will find time to do a miriway snap recipe before too long
[15:16] <Saviq> alan_g having worked through some of the core22 changes needed I'm starting to think we need to make "how do you _use_ the graphics-core22 interface" a part of the spec. Copy the hooks and wrappers? Make them a part? Extension?
[15:16] <Saviq> I know I've been against an extension for long, but now I'm not sure if it isn't the least bad…
[15:20] <alan_g[m]> I put references in to the examples as I didn't want to open that debate yet. But you know I have wanted to try the extension approach for a while. (Not that it is all good, but none of the approaches we've tried are either)
[15:27] <alan_g[m]> BTW you were discussing the CI failures with Chris when I joined. Do you know why the shm handling fails lxd:ubuntu-22.04:spread/build/sbuild:ubuntu_armhf?
[15:29] <Saviq> Yeah that test should be disabled on QEMU, it crashes there. And that disabling is what isn't working
[15:30] <Saviq> I.e. the define you suggested wasn't a good name any more
[15:31] <alan_g[m]> Are you blaming the name?!
[15:40] <Saviq> I'll look into it
[17:01] <Saviq> I didn't get far… wild guess is that ptest does not respect test_exclusion_filter
[17:02] <alan_g[m]> I'm hoping it will be fixed by Monday 😀
[17:03] <Saviq> Good night all o/
[18:01] <alan_g[m]> Good weekend all!
[21:54] <sophie-w> grayson-g: how did you fix your clang headers problem? I think I might be getting the same thing