[07:05] <Saviq> Morn'
[07:52] <alan_g[m]> <insert time of your day>!
[07:53] <Saviq> ?
[07:53] <alan_g[m]> s/</\</, s/>!/\>!/
[09:33] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths opened [pull request #2546](https://github.com/MirServer/mir/pull/2546): [miral] Tidy up event filtering API... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/c6a75662377ac97a1112e1e926c5f526c414bbd6)
[10:24] <alan_g[m]> Saviq want to review and merge a suggestion? IMO we can then land the v8 stuff: https://github.com/MirServer/mir/pull/2508#discussion_r943319792
[10:26] <Saviq> Sure
[10:43] <alan_g[m]> Oh, and this ought to be easy: https://github.com/MirServer/mir/pull/2545 (failure on Debian SID is "not us")
[10:53] <Saviq> alan_g why is it legacy? mirclient, or got fixed in the mean time?
[10:53] <Saviq> And if it wasn't fixed, we'd see failures in CI?
[10:54] <alan_g[m]> Was workaround for a race using mirclient
[11:23] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2545](https://github.com/MirServer/mir/pull/2545): Delete obsolete workaround
[11:58] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2508](https://github.com/MirServer/mir/pull/2508): Bump wl_seat to v8 and implement hi-res scrolling
[11:58] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] closed [issue #2499](https://github.com/MirServer/mir/issues/2499): Upgrade to wl_seat v7
[13:52] <alan_g[m]> I got MultiThreadedCompositor to crash locally, which gives a chance of finding a cause for its flakiness. \o/
[14:15] <alan_g[m]> Why does it need to be so hard to find out why I don't have a core file. I remember when it was just there waiting to be looked at. Now I havwe to track down a log entry: `ERROR: apport (pid 1189810) Thu Aug 11 15:05:00 2022: host pid 1189741 crashed in a separate mount namespace, ignoring`
[14:15] <alan_g[m]> (Naturally, it works perfectly under a debugger)
[14:27] <alan_g[m]> This is what makes software such fun! It crashes reasonably often when run from the CLion snap. But then apport eats my core. Run from the terminal it isn't crashing.
[14:28] <alan_g[m]> Who decided I wanted apport anyway...
[14:35] <Saviq> Does it not drop it in `/var/crash`?
[14:36] <alan_g[m]> It did not. I finally got it to crash outside a namespace and it landed in `/var/lib/apport/coredump/`
[14:38] <alan_g[m]> What I really want is "Please, before I cleanup the process would you like me to attach gdb and download symbols for any dependencies"?
[14:39] <Saviq> Something going that direction was recently presented at one of the sprints
[14:40] <alan_g[m]> Something like that was in Fedora when I was testing Mir there a few years ago
[14:40] <Saviq> Will try and find a reference
[14:41] <alan_g[m]> I don't want a reference (I saw it too), I want it an hour ago
[14:41] <Saviq> https://wiki.debian.org/Debuginfod anyway
[15:01] <Saviq> sophie I rebuilt Mir in the armhf environment with ccache, so it should behave better now. Using `-j4` is likely to help as well
[15:03] <sophie-w> Nice, I have some suspicions as to what's going wrong, but it's really weird that main also seems to be broken in that container.
[16:12] <sophie-w> Update: changing the name of our mmap wrapper (so real mmap is used instead) fixes the failing tests. It's definitely something to do with that.
[16:14] <alan_g[m]> In the past, things like that have turned out to signatures being different on different targets
[16:18] <Saviq> Good evening all o/
[16:28] <sophie-w> This looks suspiciously similar, however when I print `dlInfo.dli_fname` I get `/lib/arm-linux-gnueabihf/libc.so.6` (which seems correct), so maybe that's not the problem. https://optumsoft.com/dangers-of-using-dlsym-with-rtld_next/
[16:35] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths opened [issue #2547](https://github.com/MirServer/mir/issues/2547): MultiThreadedCompositor.when_compositor_thread_fails_start_reports_error is flaky... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/bd8bfb7c511f0171021bb34aea49a50dc9ca5d30)
[16:35] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths assigned AlanGriffiths to [issue #2547](https://github.com/MirServer/mir/issues/2547): MultiThreadedCompositor.when_compositor_thread_fails_start_reports_error is flaky
[16:49] -GitHub[m]:#mir-server- **[MirServer/ubuntu-frame]** graysonguarino marked [pull request #80](https://github.com/MirServer/ubuntu-frame/pull/80): Add crash reporter as ready for review
[17:01] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths drafted [pull request #2548](https://github.com/MirServer/mir/pull/2548): Don't destroy CompositingFunctors that are not ready 
[17:01] -GitHub[m]:#mir-server-  
[17:01] -GitHub[m]:#mir-server- > Fixes: #2547
 "**[MirServer/ubuntu-frame..." <- Regarding this, I'm not *totally* sure if `draw()`ing in `CrashReporter::Self::draw_on_diag_update()` is wise. I am writing to the buffer from two different threads, but it `draw()`s under a lock, so that isn't a problem, right?
[17:17] <grayson-g[m]> > <@github:maunium.net> **[MirServer/ubuntu-frame]** graysonguarino marked [pull request #80](https://github.com/MirServer/ubuntu-frame/pull/80): Add crash reporter as ready for review
[17:17] <grayson-g[m]>  * Regarding this, I'm not _totally_ sure if `draw()`ing in `CrashReporter::Self::draw_on_diag_update()` is wise. I am writing to the buffer from two different threads, but it `draw()`s under a lock, so that isn't a problem, right? It's worked properly in all my testing, but I'm not sure if this could become an issue.
[18:12] <grayson-g[m]> Moving that back to a draft because I wasn't thinking about the snap when I tested and I got a snap-related bug (plus I screwed up the merge).
[20:51] -GitHub[m]:#mir-server- **[MirServer/ubuntu-frame]** graysonguarino marked [pull request #80](https://github.com/MirServer/ubuntu-frame/pull/80): Add crash reporter as ready for review