[00:54] <RAOF> Uuuuuh.
[00:54] <RAOF> Why is `origin/main` failing a bunch of tests on my machine today?
[01:41] <RAOF> Ra raw!
[01:42] <RAOF> Because I'm building with clang, and apparently something we do generates code that fails under clang.
[01:59] <RAOF> Oh, no!
[02:00] <RAOF> Even better! The tests only work if built with ld.bfd.
[02:00] <RAOF> `ld.gold` fails to build (apparently `mir/common/symbols.map` confuses its parser).
[02:01] <RAOF> Both `ld.lld` and `ld.mold` build, but then the tests fail 🤷‍♀️
[02:03] <RAOF> Are other people not building with one of the faster linkers?
[02:03] <sophie-w> I use ldd, I'm pretty sure
[02:03] <RAOF> `mold` is a *full order of magnitude* faster than `ld.bfd` for a link-only build (6s rather than 60s).
[02:04] <sophie-w> But I don't generally run all the tests
[02:07] <RAOF> Huh!
[02:07] <RAOF> So, the difference is in symbol resolution.
[02:08] <RAOF> `mold` and `lld` will both resolve `glCreateShader` and friends in `mir_acceptance_tests` to our GL stubs.
[02:08] <RAOF> `ld.bfd` resolves them in `libGLESv2.so`.
[02:10] <RAOF> So when `the_screen_shooter()` transitively calls `glCreateShader`, that aborts the tests when built with `mold` or `lld`, but raises an exception when built with `ld.bfd` which gets silently eaten.
[02:11] <RAOF> (I mean, it gets logged with `severity::Error`, but that's silently eaten by the acceptance tests)
[02:29] -GitHub[m]:#mir-server- **[MirServer/mir]** RAOF opened [issue #2452](https://github.com/MirServer/mir/issues/2452): Using non-`ld` linker results in broken tests... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/be55e25138e8f6b47e00748490de8e71743bb4fd)
[08:06] -GitHub[m]:#mir-server- **[MirServer/mir]** RAOF opened [pull request #2453](https://github.com/MirServer/mir/pull/2453): mtf: Add mmap() interposer
[08:06] -GitHub[m]:#mir-server-  
[08:06] -GitHub[m]:#mir-server- > The new Platform API tests need to add the ability of `MockDRM` to intercept `mmap()` calls. Take the existing `open()` interceptor, file off the serial numbers, and use it for `mmap()`, too.
[11:06] <Saviq> alan_g hey, so, back to the performance tests… digging more into extracting renderers and resolutions… when running `Hosted*` under mir-kiosk / ubuntu-frame, that's actually 3 servers… `{mir-kiosk|ubuntu-frame}(mir_demo_server(mtf::AsyncServerRunner(test)))`
[11:08] <alan_g[m]> > alan_g hey, so, back to the performance tests… digging more into extracting renderers and resolutions… when running `Hosted*` under mir-kiosk / ubuntu-frame, that's actually 3 servers… `{mir-kiosk|ubuntu-frame}(mir_demo_server(mtf::AsyncServerRunner(test)))`
[11:08] <alan_g[m]> Yes
[11:09] <Saviq> Any pointers on how to extract GL renderer and display mode from mtf::AsyncServerRunner?
[11:10] <Saviq> I will parse logs for the outermost server, but for the test-driven servers I wanted to put those values into the result xml
[11:14] <alan_g[m]> AsyncServerRunner does recognise `--logging`, but I don't know if we pass it
[11:15] <Saviq> We do, yeah, but then that just ends up on stderr
[11:17] <alan_g[m]> So the problem is that Frame and AsyncServerRunner outputs are interleaved on stdout/err?
[11:22] <Saviq> No, outermost server logs are separate, but ASR's logs are interleaved with gtest output on std*
[11:23] <Saviq> I suppose I can just monitor all of stderr in search for `GL renderer` and `Current mode:`
[11:48] <alan_g[m]> In other news, I added "Documentation: https://discourse.ubuntu.com/t/ubuntu-frame-osk-documentation/27568" to https://snapcraft.io/ubuntu-frame-osk. (I didn't find a better documentation link)
[15:17] <Saviq> grayson-g there's also `weston-simple-touch` that may be easier to work through. But. You don't actually have a touch screen, do you?
[15:17] <grayson-g[m]> Saviq: Besides my phone, I don't believe I have a touch screen in here.
[15:24] <Saviq> alan_g got any pointers re: emulation of touch events?
[15:35] <alan_g[m]> > alan_g got any pointers re: emulation of touch events?
[15:35] <alan_g[m]> Sorry, no. What's the problem?
[15:36] <grayson-g[m]> > <@alan_g:matrix.org> > alan_g got any pointers re: emulation of touch events?
[15:36] <grayson-g[m]> > 
[15:36] <grayson-g[m]> > Sorry, no. What's the problem?
[15:36] <grayson-g[m]> This is regarding testing of this PR https://github.com/MirServer/mir/pull/2299
[15:36] <grayson-g[m]>  * This is regarding testing of this PR https://github.com/MirServer/mir/pull/2299 [Edit: I know it is incomplete, but if I need some way to test a working solution]
[15:37] <alan_g[m]> > This is regarding testing of this PR https://github.com/MirServer/mir/pull/2299
[15:37] <alan_g[m]> You'd need a driver that misbehaves in the way described to test that IRL. Better to extract the logic and write a unit test
[15:38] <grayson-g[m]> > <@alan_g:matrix.org> > This is regarding testing of this PR https://github.com/MirServer/mir/pull/2299
[15:38] <grayson-g[m]> > 
[15:38] <grayson-g[m]> > You'd need a driver that misbehaves in the way described to test that IRL. Better to extract the logic and write a unit test
[15:38] <grayson-g[m]> Makes sense
[15:43] <alan_g[m]> grayson-g[m]: That, in part is what's blocked it all this time. We don't see the problem, and the new logic isn't tested. (And, I think, both old and new logic handle "garbage in" badly)
[15:57] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2453](https://github.com/MirServer/mir/pull/2453): mtf: Add mmap() interposer
[16:08] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths opened [issue #2454](https://github.com/MirServer/mir/issues/2454): Core dump after using OSK with Chromium... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/0f5a27188c3b87f25f8fa0f083599cc142cd153d)
[16:43] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths assigned AlanGriffiths to [issue #2454](https://github.com/MirServer/mir/issues/2454): Core dump after using OSK with Chromium
[16:43] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths added bug to [issue #2454](https://github.com/MirServer/mir/issues/2454): Core dump after using OSK with Chromium
[16:49] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths opened [pull request #2455](https://github.com/MirServer/mir/pull/2455): Don't use delete in application logic... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/5c0bbafd6be8e872611207e4175b9b9cbfc11292)
[16:50] -GitHub[m]:#mir-server- **[MirServer/mir]** AlanGriffiths requested a review from graysonguarino for [pull request #2455](https://github.com/MirServer/mir/pull/2455): Don't use delete in application logic
[17:32] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] closed [issue #2454](https://github.com/MirServer/mir/issues/2454): Core dump after using OSK with Chromium
[17:32] -GitHub[m]:#mir-server- **[MirServer/mir]** bors[bot] merged [pull request #2455](https://github.com/MirServer/mir/pull/2455): Don't use delete in application logic
[23:15] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww opened [issue #2456](https://github.com/MirServer/mir/issues/2456): X11 platform display configuration racy
[23:15] -GitHub[m]:#mir-server-  
[23:15] -GitHub[m]:#mir-server- > We should only be making changes to `DisplayBuffer`, `gl::RenderTarget`, etc in `Display::configure()`, since references are held by the compositor and used on the compositor thread, but we make changes immediately when we notice them from X11 events.
[23:18] -GitHub[m]:#mir-server- **[MirServer/mir]** wmww opened [issue #2457](https://github.com/MirServer/mir/issues/2457): Wayland platform display configuration racy
[23:18] -GitHub[m]:#mir-server-  
[23:18] -GitHub[m]:#mir-server- > Like #2456, we should only be making changes to displays in `Display::configure()`. This one is potentially worse because if an underlying `wl_output` disappears we will destroy the display buffer, but it may continue to be rendered on, resulting in a use-after-free.
[23:46] <RAOF> <Saviq> "alan_g got any pointers re..." <- grayson-g:  If you need a set of real touch events to work from, I can provide a umockdev recording that will generate a seemingly-real touch stream.
[23:46] <grayson-g[m]> RAOF: This would be helpful!
[23:48] <RAOF> RAOF: The thought occurs that the *reporter* of that bug might be able to generate a trace of the broken driver's events!
[23:49] <RAOF> I think there might also be an existing trace of a touch stream in `test_data`?