| Saviq | Good morn' o/ | 07:29 |
|---|---|---|
| RAOF | Aloha! | 07:32 |
| 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:22 |
| 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:25 |
| Saviq | *#2927, and IIUC that's the A random extra fix PR while in the code piece, separate from the logind problem | 08:34 |
| alan_g[m] | * Re the logind thing: I see #2924 & #2927 that are related. Is either ready to review/merge? Or are they superceeded by this analysis? | 08:39 |
| 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:01 |
| RAOF | (alternatively: we could decide to have the mainloop always run, and then #2924 could instead drop a bunch of code) | 09:05 |
| * RAOF notes that this wasn't enough to hand off 😉 | 09:06 | |
| 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:08 |
| 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:15 |
| 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:19 |
| 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:27 |
| 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:29 |
| alan_g[m] | Is trying to maintain the FdStore the source of our "gone" woes? | 09:30 |
| RAOF | No, actually. It wouldn't help there. | 09:31 |
| RAOF | It would make the surrounding code nicer, but the fundamental problem is our AcquireDevice/ReleaseDevice-without-running-eventloop thing | 09:32 |
| Saviq | PSA: GitHub's infra (AKA Azure) is on hiatus right now, so all our CI is on fire | 12:20 |
| alan_g[m] | Just when I thought I could get stuff reviewed and landed | 13:21 |
| Saviq | It looks better now, actually | 13:22 |
| 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:09 |
| Saviq | Just need to get to a state where the timeout's correct | 16:11 |
| alan_g[m] | OK, will do some more of that... | 16:12 |
| Saviq | Maybe it's just configured wrong, I'll monitor things | 16:12 |
| 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:17 |
| 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:39 |
| Saviq | So the problem was actually the GH infrastructure issues still | 16:40 |
| 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:46 |
| 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:49 |
| 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 | 16:51 |
| Saviq | Me:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/6cd05965e68331dd93ce290f0481731cc8c8f2ad>) | 17:03 |
| 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 | 17:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!