[04:16] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2477](https://github.com/MirServer/mir/pull/2477): Tidy up eglstream probe
[06:57] <Saviq> yawn
[07:19]  * RAOF unplugs keyboard to plug something else in, and then wonders for a good minute why the mouse is working but not <alt>+<tab>.
[07:35] <Saviq> Hmm. So we [have this](https://github.com/MirServer/mir-kiosk/blob/5b4d3b8bafc62cdc9fcdb57c3ac17882d8fdace2/.github/workflows/snap.yml#L24) in `mir-kiosk`'s CI:
[07:35] <Saviq> ```
[07:35] <Saviq> sed -i 's@rev-list --count@rev-parse --short@' snap/snapcraft.yaml
[07:35] <Saviq> ```
[07:36] <Saviq> Which results in:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/211a4d2a725c8256d79d829288b9ecf76fe40793)
[07:36] <Saviq> So non-CI snaps have just the number of commits, CI ones have a SHA.
[07:37] <Saviq> It's not consistent (other snaps don't have this in CI, making it ambiguous, so wrong)
[07:38] <Saviq> But now I wonder we should just have the SHA all the time?
[07:46] <RAOF> SHA is generally more git-ty.
[07:47]  * RAOF , personally, would like git to admit to the reality that there is a mainline of development and so you can totally construct a useful monotone-increasing revision number, but that fight was lost like a decade ago.
[07:51] <Saviq> Well, doing what mir-kiosk does today is, roughly, that. We decide that numbers are good enough for mainline, but not for anything else.
[07:52] <Saviq> My biggest irk is that there's no easy way of going back from a number to a commit (which is I suppose what you're referring to)
[07:52] <RAOF> Right.
[07:54] <Saviq> I kinda like it anyway. Clearly shows which is "stable" and which is not
[07:55] <Saviq> And can probably find a one-liner to go back
[07:58]  * Saviq feels like a review of CI is next in line after release process…
[07:58] <Saviq> Actions, bors, versions strings…
[07:59] <RAOF> :)
[08:00] <Saviq> At least now all snaps will be built through a common GH action. When all those merge, that is.
[08:01] <Saviq> Is this broken for me or for everyone? https://mir-server.io/ubuntu-frame/
[08:07] <Saviq> OK just me.
[08:27] <Saviq> sunweaver hey, I'm told you built .symbols files for all the Mir packages, could you please point me at where I could grab those?
[08:27] <Saviq> Ideally we'd like to integrate all your packaging changes into Mir proper
[08:33] <RAOF> Saviq: They'll be in salsa git.
[08:33] <RAOF> Saviq: `debcheckout mir` should get you a git checkout of Mir from salsa; you'd be after the... `master` branch from salsa, I think.
[08:34] <Saviq> Right, but that's for 1.8 only IIUC?
[08:35] <Saviq> https://salsa.debian.org/mir-server-team/mir
[08:36] <Saviq> A starting point for sure
[08:36] <RAOF> Ah, yeah. I don't know whether they've done a set for 2.0
[08:36] <RAOF> <sophie-w> "@[RAOF (he/his)] all the mutable..." <- Hm. I've had a quick look at doing this, and it seems like it might be valuable as I've already picked up like 4 threading bugs.
[08:38] <RAOF> ...5.
[08:50] <RAOF> <RAOF> "...5." <- Wow. There's a lot of `basic_surface.cpp`, isn't there. Dinner time!
[08:57] <Saviq> Good weekend o/
[12:06] <Saviq> So looking into abigail (for ABI stability reasons) there are two options:
[12:06] <Saviq> 1. we compare deb packages (so probably grab the ones from Ubuntu devel) against what we build in CI
[12:06] <Saviq> 2. we check in an XML representation and compare that against the .so we build
[12:07] <Saviq> 1. has the advantage that we don't need to maintain much of anything, as long as the packages we produce don't break ABI, the previous packages are the status quo. But it does tie us to deb packages
[12:28] -GitHub[m]:#mir-server- **[MirServer/mir]** Saviq marked [pull request #2473](https://github.com/MirServer/mir/pull/2473): ci: add armhf builds as ready for review
[15:17] <Saviq> A'ight, good weekend all o./
[17:41] <sunweaver> Saviq: RAOF: Marius has been working on 2.8.x for Debian, but I am unsure if he has done the .symbol files stuff.
[17:42] <sunweaver> Also note, that those .symbols files are auto-generated.
[17:42] <sunweaver> https://qt-kde-team.pages.debian.net/symbolfiles.html
[17:42] <sunweaver> and also half-auto-maintained...
[23:03]  * sophie-w sent a code block: https://libera.ems.host/_matrix/media/r0/download/libera.chat/4d1e5a3c54b77dc13f0f8b3e6ab87c0eb472a6de
[23:49] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww opened [pull request #2481](https://github.com/MirServer/mir/pull/2481): Refactor scene and surface change notification classes
[23:49] -GitHub[m]:#mir-server-  
[23:49] -GitHub[m]:#mir-server- > For presumably historical reasons, we previously had `LegacySceneChangeNotification`, which used either `LegacySurfaceChangeNotification` or `NonLegacySurfaceChangeNotification` depending on how it was constructed. Production code only used the non-legacy path, and the non-legacy one inherited from the legacy one. This PR consolidates the surface observers into a single class, and drops the legacy prefix from both surface and scene
[23:49] -GitHub[m]:#mir-server- observers. It should not have any impact on behavior.