[07:29] <Saviq> Good morn' o/
[07:32] <RAOF> Aloha!
[08:22] <RAOF> Ok. What's been goin' down…... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/f39d83f7c72a64618fff9d07aa2cda50207a0a5c>)
[08:22] <RAOF>  * Ok. What's been goin' down…... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/1f209a4909dca185fe33154fbec32e812fa9d6b1>)
[08:25] <alan_g[m]> Re the logind thing: I see #2924 & #2947 that are related. Is either ready to review/merge? Or are they superceeded by this analysis?
[08:34] <Saviq> *#2927, and IIUC that's the A random extra fix PR while in the code piece, separate from the logind problem
[08:39] <alan_g[m]> * Re the logind thing: I see #2924 &amp; #2927 that are related. Is either ready to review/merge? Or are they superceeded by this analysis?
[09:01] <RAOF> [#2924](https://github.com/MirServer/mir/pull/2924/files) should be extended to do the “ignore the `gone`s from before start” thing; the other one is independent.
[09:05] <RAOF> (alternatively: we could decide to have the mainloop always run, and then #2924 could instead drop a bunch of code)
[09:06]  * RAOF notes that this wasn't enough to hand off 😉
[09:08] <alan_g[m]> Let's not repeat a discussion happening elsewhere. Running the mainloop during "init" phase would definitely break stuff
[09:08] <RAOF> It almost certainly would, yes 
[09:15] <RAOF> Hmmmmm. You might be able to get around that by using a different mainloop for logind during startup, but then the handover would be fraught.
[09:19] <Saviq> RAOF (he/they) you did mention at some point that there's a different API we could talk to… libinput (?)… to. Would that matter?
[09:27] <RAOF> <Saviq> "RAOF (he/they) you did mention..." <- Yes; we use the `libinput_path` API, where we are responsible for adding and removing devices to the libinput context.
[09:27] <RAOF> There's also the `libinput_udev` API, where libinput handles device discovery itself.
[09:27] <RAOF> The reason why we use the path API is that (in both cases) libinput uses an us-provided interface to `open` and ` close` device FDs. That interface is synchronous, and supplying those FDs requires a round-trip to logind.
[09:27] <RAOF> With the path API we can acquire the FD from logind ahead of time, and stash it in the `FdStore` before adding the device to libinput.
[09:29] <RAOF> A proposed (by me) API addition to libinput would be to have the interface we provide to libinput be asynchronous. That API doesn't exist, but has in-principle support from the maintainers.
[09:30] <alan_g[m]> Is trying to maintain the FdStore the source of our "gone" woes?
[09:31] <RAOF> No, actually. It wouldn't help there.
[09:32] <RAOF> It would make the surrounding code nicer, but the fundamental problem is our AcquireDevice/ReleaseDevice-without-running-eventloop thing
[12:20] <Saviq> PSA: GitHub's infra (AKA Azure) is on hiatus right now, so all our CI is on fire
[13:21] <alan_g[m]> Just when I thought I could get stuff reviewed and landed
[13:22] <Saviq> It looks better now, actually
[16:09] <alan_g[m]> Do we have a better answer for "removed this pull request from the merge queue due to no response for status checks" than bumping the timeout and hoping?
[16:11] <Saviq> Just need to get to a state where the timeout's correct
[16:12] <alan_g[m]> OK, will do some more of that...
[16:12] <Saviq> Maybe it's just configured wrong, I'll monitor things
[16:17] <alan_g[m]> Take this example: https://github.com/MirServer/mesa-core22/pull/4
[16:17] <alan_g[m]> I've bumped the timeout (to 60min), but still failing
[16:39] <Saviq> You can see what happened with the job here:
[16:39] <Saviq> https://github.com/MirServer/mesa-core22/actions?query=event%3Amerge_group
[16:40] <Saviq> So the problem was actually the GH infrastructure issues still
[16:46] <alan_g[m]> OK, then I'll leave it be until tomorrow
[16:46] <Saviq> But GH misreported as "no response" on at least one of the runs
[16:49] <Saviq> Actually maybe didn't misreport, the run did take an hour:
[16:49] <Saviq> https://github.com/MirServer/mesa-core22/actions/runs/4980921597
[16:51] <alan_g[m]> Today:
[16:51] <alan_g[m]>   o Read through the discussion of input device bringup and proposed https://github.com/MirServer/mir/pull/2928
[16:51] <alan_g[m]>   o Reviewed https://github.com/MirServer/mesa-core22/pull/5
[16:51] <alan_g[m]>   o Reviewed ♾️ PRs around the merge integration
[17:03] <Saviq> Me:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/6cd05965e68331dd93ce290f0481731cc8c8f2ad>)
[17:05] <Saviq> FWIW one thing I don't get is why it's [running multiple merge groups](https://github.com/MirServer/mesa-core22/actions/workflows/snap.yml?query=event%3Amerge_group) (actually, single PRs, not grouped) in parallel… We may want to configure things differently.
[17:05] <Saviq> But that's tomorrow. The runs at least look like they're completing now