02:15 <sam_> bwidawsk: yikes

02:16 <sam_> bwidawsk: this feels really fubar'd

02:16 <sam_> bwidawsk: does this thing run on the same HW or does it get allocated to diff. nodes? almost wonder if it's bad rma or something

02:16 <sam_> bwidawsk: fwiw arch's toolchain maintenance isn't always ideal

02:17 <sam_> i'm a bit biased in what i'd recommend (gentoo, can help if anyone does want to do it for CI), but alpine edge at least tends to be up to date, and at least debian/ubuntu is well tested but it's harder to get newer toolchains

07:31 <daniels> sam_: different nodes which do builds all day every day for other fd.o projects without failing …

07:32 <daniels> like if compiling things predictably failed as a general rule, it would not be possible to merge any code into Mesa

10:21 <DavidHeidelberg[m]> alanc: another DNS issue https://gitlab.freedesktop.org/mesa/mesa/-/jobs/45239493 on FDO

10:21 <DavidHeidelberg[m]> (most failed twice, since we use retry: 1)

10:53 <daniels> hooray for dns

16:16 <bwidawsk> sam_, daniels: Sure, it's easy to blame arch, but what are the odds that both GCC and LLVM fail, in different ways?

16:16 <bwidawsk> non-zero for sure, but... smells a bit fishy

16:16 <bwidawsk> I always seem to get the same runner for whatever reason

16:17 <bwidawsk> Runner: #3258 (R-7hYixjK) fdo-equinix-arm-9

16:17 <bwidawsk> just for poops and laughs, is there a way to get a different arm runner?

16:26 <daniels> no, there's no way to force runner assignment, but like ... it's run several hundred jobs for a few projects in the last 24h, all of which have succeeded apart from ~5 which failed due to DNS flaking out and a bunch of legitimate 'your code is not well-formed' compilation errors ... and sudbury for which 100% of the jobs have failed

16:26 <daniels> so you'd expect 'the machine is fucked and we can't compile anything' to be a bit less choosy in what it took out

16:32 <eric_engestrom> any objection to moving the drivers files rules out of `.gitlab-ci/test-source-dep.yml` ?

16:32 <eric_engestrom> (it's a bit more involved than https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24090 so I want to make sure there's no objection first)

16:33 <eric_engestrom> * out of that file and into their respective src/**/gitlab-ci.yml

19:01 <sam_> bwidawsk: I'm pointing it out as there's historically been various toolchain issues, but see what daniels said. It's either HW or it's not. And it sounds like it ain't. :)

19:01 <sam_> daniels: thanks, that's what I don't get really

19:01 <sam_> it seems super unlikely it's just hitting this one thing

19:02 <sam_> but I agree it's bizarre that both gcc and clang fail when compiling the same project like this. are you using some persistent ccache or something, maybe?

20:02 <DavidHeidelberg[m]> eric_engestrom: but... but.. the name of the file implies it's there :P

20:03 <eric_engestrom> yeah, I'm not sure what to name this file after I'm done ^^

20:45 <eric_engestrom> DavidHeidelberg[m]: I went ahead with moving the driver files rules to the drivers src/*/ci/gitlab-ci.yml: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24099

20:46 <DavidHeidelberg[m]> eric_engestrom: haha, I don't want to review that :D

20:46 <DavidHeidelberg[m]> but could work

20:46 <eric_engestrom> :P

20:48 <eric_engestrom> the first half of the MR is cleanups to use the !reference macro instead of yaml anchors, the second half is straight moving lines (ie. no changes, use `--color-moved` to simplify reviewing) into the respective driver yml