09:17 <ofourdan> hi, I made a mistake, I pressed the [Rebase without pipeline] button in https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/56, the CI didn;t run and now gitlab remove the [Merge] button - Clicking [Run pipeline] fails, so I tried to force push to Emil's branch (in the hope that it would trigger a pipeline) but that does nothing - How can I fix this?

09:18 <ofourdan> (all that in good faith, I thought not runnign the pipeline for a simple doc issue would save some energy somewhere!)

09:19 <__tim> you could "git commit --amend" and then git push, that will make it look like it changed

09:20 <__tim> maybe running a pipeline manually also works

09:20 <ofourdan> how can I trigger a pipeline manually?

09:21 <__tim> you go to the 'Pipelines' tab and then click 'run pipeline'

09:22 <ofourdan> If I click [Run pipeline] there is a cryptic error message stating that "An error has occured trying to run a new pipeline for this merge request"

09:22 <__tim> you probably need to also resolve open discussions before a merge is possible

09:22 <__tim> maybe you need developer permissions for that, not sure, sorry :)

09:22 <ofourdan> I am manintainer

09:22 <__tim> ah, then I don't know

09:23 <daniels> alanc: gitlab themselves have some quite good docs?

09:23 <ofourdan> thanks for trying to help anyway!

09:24 <daniels> ofourdan: so you can create a new pipeline for a given ref through the CI tab, but then it will just be created for the ref rather than as an MR pipeline

09:24 <daniels> at a guess, you'd probably have to rebase yourself (with --no-ff) and push

09:25 <ofourdan> yeah, I think I'll have to push indeed

09:25 <ofourdan> but taht creates a merge commit

09:28 <ofourdan> (so ftr, that [Rebase without pipeline] button is a little troublemaker, I'll try to remember to never use it again :) )

09:32 <daniels> if you don't want a merge commit, go to settings -> general -> merge request settings, and change to ff rather than merge

09:35 <ofourdan> that's fine, there are merge commits in the past

09:36 <ofourdan> I merged it manually

09:36 <ofourdan> I mean pushed

10:53 <MrCooper> ofourdan: seems like a bug that GitLab offers the "Rebase without pipeline" button for projects which require the CI pipeline to pass before merging

11:16 <ofourdan> indeed

12:48 <ofourdan> /usr/libexec/gstreamer-1.0/gst-plugin-scanner -l /usr/bin/gnome-shell

12:48 <ofourdan> oops!

12:48 <ofourdan> (sorry… paste gone wrong)

14:08 <airlied> karolherbst: https://paste.centos.org/view/raw/32cf9daa

14:21 <karolherbst> airlied: it's a meson bug

14:21 <karolherbst> read the readme

14:21 <karolherbst> basically you have to set -Drust_std=2021 yourself

14:22 <karolherbst> it works alright if you initially configure the project :(

14:22 <karolherbst> dcbaker: btw.. any progress on https://github.com/mesonbuild/meson/issues/10664 ?

14:23 <karolherbst> it's not even a rust specific meson bug

15:21 <tintou> Hi there, is there any issue with the Windows runner, a job https://gitlab.freedesktop.org/mesa/mesa/-/jobs/28195536 has been queued more than an hour (and made the Marge pipeline timeout)

15:28 <__tim> one of the two windows runners is being updated

15:29 <__tim> and thus temporarily out of service :)

15:41 <Arsen> windows runners, interesting; how does licensing them work?

15:41 <Arsen> that's what was preventing me setting up some windows runners of my own (the idea I had is to provision a up-to-date snapshot weekly and then boot from the snapshots for running actual jobs, which further complicates it)

15:42 <daniels> Arsen: for the shared runners, Microsoft sponsors our licenses

15:43 <Arsen> ah, fair

15:43 <__tim> These are running docker on Windows fwiw

15:43 <Arsen> docker can run windows?

15:43 <alatiera> both runners are online again, backlog should drop

15:44 <alatiera> Arsen for better or worse

15:44 <Arsen> I didn't know that, interesting

15:50 <daniels> alatiera: thanks!

15:50 <daniels> alatiera: I don't know what your schedule is like, but use is definitely lightest in European morning, peaking a bit after lunch, sustained through to dinner time, then dropping off until about midnight

15:50 <daniels> so if you can do updates around European breakfast, that's by far the least invasive

15:51 <alatiera> daniels yea that's what I usually aim for, did all the rest of the runners on saturday

15:52 <alatiera> I queued a disk trim that took way longer than expected

15:54 <daniels> fair enough :)