12:04 <DavidHeidelberg[m]> alatiera: gst-htz-1-windows is not in good shape :( https://gitlab.freedesktop.org/mesa/mesa/-/jobs/47174854 no connection to docker

12:07 <__tim> might want to configure those jobs to automatically re-try on system failure :)

12:20 <DavidHeidelberg[m]> we have :P

12:22 <__tim> ah, hum :)

12:22 <__tim> in our case I usually see the 'retrying' in the log

12:25 <__tim> anyway other jobs are running fine, so maybe it'll sort itself out :)

14:06 <alatiera> DavidHeidelberg[m] I've restarted the runner couple days ago, but there isn't much we can do for docker shitting itself anyway

14:13 <tintou> It seems that the Marge of virglrenderer is broken, can someone restart her?

14:15 <tintou> ah it is in fact probably a corner case of marge that I'm hitting here

15:22 <dabrain34[m]1> hello, any issue reported on windows runner recently ? this one is really slow https://gitlab.freedesktop.org/dabrain34/GstPipelineStudio/-/jobs/47183536

15:23 <__tim> yes, only one runner is online at the moment, and it's under a bit of pressure

15:23 <__tim> but the second one should come back online realsoonnow

15:23 <__tim> (like right now-ish)

15:23 <dabrain34[m]1> ok

15:23 <dabrain34[m]1> I can stop the job and come back later then

15:24 <dabrain34[m]1> its not mandatory ...

15:24 <dabrain34[m]1> thanks __tim

15:32 <alatiera> second runner should be up again

15:32 <alatiera> and with faster and more storage

15:35 <daniels> tintou: needs (much) more detail

15:36 <daniels> but looking at random MRs, I assume you pushed something which was already current to HEAD and already had the Part-of bit in it, so marge never pushed a rebase, so the pipeline never triggered because it was created by your user

15:37 <daniels> the workaround for that is to strip Part-of when you push a branch

15:41 <alatiera> btw for that there's a config option now, but that means marge always makes a new pipeline regardless if it doesn't need a rebase

15:45 <daniels> is there?

15:45 <alatiera> y --guarantee-final-pipeline

15:46 <alatiera> https://gitlab.com/marge-org/marge-bot/ is the new upstream

15:46 <alatiera> I also see a lot of images 2022-10-20-upgrade-zlib--2023-06-24-agility-711 with different shas/ids

15:47 <daniels> yeah I know, see discussion above; that shouldn't happen for new forks, but was because the registry was out of date

15:47 <daniels> as for marge-bot, we are using that fork; I'd just missed that --guarantee-final-pipeline now actually triggered the pipeline, rather than adding a comment saying 'jenkins retry' (the old behaviour)

15:47 <alatiera> hmm shouldn't the old forks upload the upstream sha on new pipelines too?

15:48 <alatiera> heh yea

15:48 <alatiera> that jenkis thing was fun

15:48 <alatiera> someone fixed ti couple months ago

15:48 <koike> hmm, maybe this new option can solve this case https://gitlab.com/marge-org/marge-bot/-/issues/388

15:49 <alatiera> that's usually a symptom of having both branch and merge request pipelines

16:09 <tintou> daniels: Yes that was exactly the issue

16:32 <zmike> anyone know what's going on with the windows job here? https://gitlab.freedesktop.org/mesa/piglit/-/pipelines/958597 it's been like 3 hours

16:35 <alatiera> zmike it just finished

16:37 <zmike> ofc right after I look and see it hasn't started 🤕

16:38 <__tim> :D

16:38 <daniels> it apparently took 57m to complete, which is extremely not normal

16:39 <zmike> it was queued for 3+ hours also

16:39 <zmike> which is possibly not normal

16:41 <daniels> it says only queued for 13min, but I take your point

16:41 <daniels> alatiera: ooi, looking at https://gitlab.freedesktop.org/jyelloz/gstreamer/-/jobs/47193293 ... is there anything in there which actually keeps it to using the right number of CPU cores, rather than using them all?

16:42 <daniels> afaict it's just calling ninja -C build, and possibly DoSing the machine for everyone else

16:42 <daniels> which would probably explain a fair bit about why Mesa jobs sometimes take 10min and sometimes 2h

16:42 <zmike> you can see how many times the MR timed out

16:42 <alatiera> I don't recall, but you are probably right

16:42 <zmike> I assigned it a long time ago

16:42 <alatiera> this was tocuhed recently might have gone mising

16:43 <alatiera> daniels seen this befroe? https://gitlab.freedesktop.org/seungha.yang/gstreamer/-/jobs/47194030

16:44 <alatiera> just checked the marge acc doesn't have 2fa

16:44 <daniels> 2fa ... ?

16:45 <alatiera> ERROR: Job failed: failed to pull image "registry.freedesktop.org/seungha.yang/gstreamer/amd64/windows:2023-08-10.0-main" with specified policies [always]: unauthorized: HTTP Basic: Access denied. The provided password or token is incorrect or your account has 2FA enabled and you must use a personal access token instead of a password. See

16:45 <alatiera> https://gitlab.freedesktop.org/help/user/profile/account/two_factor_authentication#troubleshooting (manager.go:237:142s)

16:45 <daniels> anyway no I haven't seen that - well only on non-public repos which this isn't

16:46 <daniels> I can imagine a 401 rather than a 404 if the image didn't exist

16:46 <alatiera> I have no clue how gitlab-runner would be like failing the tttp autho

16:46 <alatiera> I checked the image does exist

16:46 <alatiera> daniels will look into the ninja issue once gst5 is online again

16:46 <daniels> yeah, that's super weird

16:46 <daniels> thanks!