00:15 <DavidHeidelberg[m]> haha, I thought so! Thanks daniels (btw. do we have some graphana view which can be used to deduct this?)

00:16 <daniels> not right now, no

00:21 <DavidHeidelberg[m]> last thing on my mind (for today), when I looking at GitLab runners connected to FDO, I see:  mesa-ci-aarch64-lava-baylibre, 2 or 3 years stalled runners as mesa-db410c-4, google-intel-kbl-gt2-nami-7 etc., maybe they could be wiped?

00:51 <robclark> we probably should spend some time figuring out what the deal is with some of the fd-farm runners.. I think there are some we've taken offline over the years without actually going back and looking at what the issue is.. but maybe just file issues and assign to respective farm owners and let them deal with it when they have bandwidth

09:11 <DavidHeidelberg[m]> for my 50 cents, I tried to ping people from Baylibre, but no response at all (with some enablement we dropped their very long time disabled job).

09:37 <eric_engestrom> daniels: re- "nothing ever changes on the runners" -> nothing changed in the repo either, so I'm not sure what that leaves as possible change?

09:41 <mupuf> bugs can take time to appear: caches rotting, ...

09:44 <eric_engestrom> could we pause 24 until we figure this out? it has prevented almost every MR from landing over the last day or two, unless babysitted to manually retry every job until they run on another runner (I've done that for a bunch of MRs but I can't keep doing that)

11:43 <mupuf> eric_engestrom: done

11:44 <daniels> eric_engestrom: I would much prefer to just nuke the test until it's figured out

11:55 <mupuf> daniels, eric_engestrom: if the test is indeed of limited interest, disabling the test is probably the best way forward

12:27 <daniels> cutting shared runner capacity by 1/3rd is not a good solution tbh

12:27 <daniels> we can try to spin up a new one, but given that it is isolated into a container environment, I'd be stunned if it didn't repeat itself

12:34 <mupuf> quite likely.

12:34 <mupuf> eric_engestrom: how about changing the job's git policy to clone?

12:50 <mupuf> eric_engestrom: let me know when a workaround is found in mesa, and I'll re-enable the runner

13:24 <MrCooper> per anholt's comment, the test seems somewhat questionable, so disabling just that one test for now might be a good solution

16:13 <anholt> MrCooper: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24755

16:13 <anholt> mupuf too I guess

16:14 <mupuf> anholt: thanks!

16:14 <mupuf> You have my A-b :)

19:22 <mupuf> daniels: I resumed the runner

23:26 <Zeroine> Hi, I hope I can ask this here. I'm using libdbus but when I call dbus_pending_call_steal_reply with my pending call it fails. Here's the source and the error https://bpa.st/FNRQ the error says the argument is incorrect but that function has a "DBusPendingCall *" parameter and I'm passing an argument "pending" which is defined as "DBusPendingCall *pending" so I don't get what the

23:26 <Zeroine> issue is.

23:27 <Zeroine> I know it's failing here https://dbus.freedesktop.org/doc/api/html/dbus-pending-call_8c_source.html#l00736 and _dbus_return_val_if_fail is a function from dbus-internals.h but it gets pretty hard to read in there