05:04 <bentiss> alatiera: cpus_ is a hint only IIRC, it doesn't enforce anything on the container

05:05 <bentiss> alatiera: allowed_services -> mupuf requested we re-enabled them last week. IIRC they are effectively denied because we are missing a packet in the podman installation

05:06 <bentiss> user and userns -> yeah, no. If we need to do anything, I'd go with a script like runner-gating.sh that checks for the uid and fails if it's root

05:06 <bentiss> too many moving targets

05:07 <bentiss> helper_image_flavor -> python is a no go, again, because the pre-build-script is executed in teh target container (so ci-fairy, alpine:latest, mesa:build-debian-ppc92, etc...) and you have no guarantees python is available there

05:08 <bentiss> cap_add -> haven't played with it but might be able to use user mode containers for virglrenderer, yes

10:29 <__tim> so the runner-gating.sh is executed in a container that's controlled by the user? That means I one could just build a container with a custom sh to bypass it?

10:50 <mupuf> __tim: yeah, I guess we should also ship busybox to run the script with

10:53 <__tim> I wonder if writing a small statically linked rust app would work too (would also work on windows then)

10:53 <__tim> but needs to be runner arch specific then I guess

11:22 <mupuf> __tim: yeah, that's what I was proposing, but it is more work

11:22 <mupuf> as for creating a script per arch... we already need to have per-arch static binaries for jq and wget

11:42 <tintou> Hi there, I wanted to report that I find the windows runners very slow these days

11:43 <__tim> there's currently only one runner up instead of two

12:06 <jenatali> I seem to keep getting unsubscribed from merge requests. I have an email that Marge pushed new changes, but I didn't get one about the result. And plenty of other MRs I've looked at and see the notifications box unchecked without me doing anything

13:34 <svuorela> hmm... I'm getting "Looks like you don't have enough privileges, please see ht..." for pipeline jobs run on MR's from my personal clone to the official repository where I have just been added as a guest. Have I misunderstood stuff or shouldn't it now work ? or are there some daily cronjobs involved here?

13:48 <alatiera> bentiss, daniels btw I've been running the gst runners non-priv so far and it doesn't seem anyone has complained

13:49 <alatiera> so maybe we could have a dedicated priv runner for the projects that need it and all the rest in non-priv

13:49 <alatiera> and tagged accordingly

13:50 <bentiss> svuorela: if you look into the groups tab of your profile (https://gitlab.freedesktop.org/users/svuorela/groups) you'll see that you don't have CI-OK, let me fix that

13:51 <bentiss> svuorela:should eb fixed

13:53 <bentiss> and not fixed because you got added to the repository itself, not the group :/

13:54 <bentiss> alatiera: yeah, IIRC most projects were fine, except for virglrenderer

13:55 <bentiss> with some crazy weird errors

13:55 <pq> Isn't it common to add people to projects directly instead of groups? I'd think it is less common for people to be added groups as they would gain access to all projects in the group.

13:56 <bentiss> pq: I know, but it's a gitlab bug that IIRC we have been chasing for a while at Red hat

13:56 <pq> ah

13:56 <bentiss> curl -s --header @/tmp/header.tmp https://gitlab.freedesktop.org/api/v4/groups/102611/members/all\?user_ids\=82673 | jq -> this returns null when it should return svuorela user

13:58 <bentiss> I was thinking that we could have a subgroup in those cases, just for the people we want to give CI rights. poppler/ci-ok in that case. And then in the main ci-ok, I import this group

14:01 <bentiss> pq: the whole group membershipo is bonkers on gitlab: from the user profile, a user may be part of ci-ok, because they are part of a subgroup/project invited by ci-ok, but from the rest API point of view, they are not.

14:01 <pq> >_<

14:02 <bentiss> and TBH, I think the rest API is correct, because if you have group A, subgroup A.B, it's not clear what inviting group A means. In term of privileges, you'd think that members of A/B have less privileges, so no (like the rest API), but the gitlab UI shows the other way

14:03 <bentiss> but still, relying on groups is better than relying on a list of individuals, so we'll figure it out

14:22 <svuorela> bentiss: so I should go back to the poppler people and get added the the poppler project group and not just the poppler poppler repository ?

14:36 <bentiss> svuorela: yes, that would be the best. If they feel incomfortable with that, you can tell them that they can create a poppler/ci-ok subgroup, add you to this group, and I'll invite this subgroup to the main ci-ok group

14:50 <svuorela> bentiss: will do.

14:50 <bentiss> thanks

14:56 <eric_engestrom> bentiss: something is not clear to me right now: will I, as a Developer member of mesa/mesa, still be able to run CI pipelines on branches in my eric/mesa fork without having created an MR?

14:58 <bentiss> eric_engestrom: curl -s --header @/tmp/header.tmp https://gitlab.freedesktop.org/api/v4/groups/102611/members/all\?user_ids\=1112 | jq '.[].id' -> 1112, so yes :)

14:58 <eric_engestrom> yeah that's ok, the part I'm not clear on is if this is only to allow MR pipelines (in the project namespace), or also on forks

14:59 <bentiss> eric_engestrom: that's because you are in https://gitlab.freedesktop.org/groups/mesa/-/group_members

14:59 <bentiss> eric_engestrom: once you are validated, you can run wherever you want

14:59 <eric_engestrom> ok

14:59 <eric_engestrom> thanks for the confirmation :)

14:59 <bentiss> the MR fallback is to allow people not part of a group but that can still push on a repo

14:59 <eric_engestrom> then for all the use cases I can think of, it's all good; thanks for the work!

15:00 <bentiss> great :)

15:45 <alanc> I wonder if we should be removing or otherwise marking as inactive members of our groups who are no longer contributing so we don't make their accounts targets for the cryptominers to hack next

15:46 <alanc> like there's several people in https://gitlab.freedesktop.org/groups/xorg/-/group_members who were setup during migration to gitlab but who have never logged into gitlab in the 5years since that

15:47 <alanc> (and at least one I know of who had logged in before, but can never login again)

16:11 <MrCooper> "can never again", as in they passed away?

16:17 <emersion> alanc: removing inactive members makes total sense to me

16:17 <emersion> the only reason why i don't do it too much is that i don't want to offend someone…

16:33 <alanc> MrCooper: sadly, yes

16:35 <MrCooper> sad news; maybe that account can be marked somehow such that it can't be used anymore, nor re-created by someone else

16:36 <alanc> yeah, if there's a way to "memorialize"/freeze an account, that would make sense

16:42 <bentiss> can't we lock an account?

16:44 <bentiss> apparently no. Though we can for sure remove the emails, so there will be no password retrieval possible

16:49 <eric_engestrom> https://gitlab.freedesktop.org/mesa/mesa/-/jobs/38265923 vkcts-navi21-valve got stuck while uploading the artifacts, but the interesting part for me is that it's getting a 100min timeout? isn't that way too high?

16:50 <eric_engestrom> for a test job I mean, for a container job a large timeout is normal

16:51 <eric_engestrom> mupuf: ^ since you probably have an opinion :]

16:55 <mupuf> eric_engestrom: right, we share a lot of timeouts between machines. The premerge jobs should likely have a muuuuch tighter timeout

16:56 <mupuf> bentiss, eric_engestrom, daniels: FYI, my wife and I are expecting a baby any time now. So if I stop answering, contact ana, hakzsam, or Venemo :)

16:57 <eric_engestrom> mupuf: ack, and congrats :D

16:58 <mupuf> thanks :)

17:50 <bentiss> mupuf: ack too, and congrats too :)

17:54 <jcristau> bentiss: https://docs.gitlab.com/ee/user/admin_area/moderate_users.html#block-a-user maybe?

17:55 <bentiss> jcristau: yeah. I was a bit hesitant with this because we are heavily using this to fight spam :)

17:56 <jcristau> makes sense