ChanServ changed the topic of #freedesktop to: infrastructure and online services || for questions about projects, please see each project's contact || for discussions about specifications, please use or
Leopold has quit [Ping timeout: 480 seconds]
danilo has joined #freedesktop
dakr has quit [Ping timeout: 480 seconds]
co1umbarius has joined #freedesktop
columbarius has quit [Ping timeout: 480 seconds]
columbarius has joined #freedesktop
co1umbarius has quit [Ping timeout: 480 seconds]
strugee has joined #freedesktop
strugee has quit [Quit: ZNC -]
strugee has joined #freedesktop
chipxxx has joined #freedesktop
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #freedesktop
chip_x has joined #freedesktop
chipxxx has quit [Ping timeout: 480 seconds]
chipxxx has joined #freedesktop
chip_x has quit [Ping timeout: 480 seconds]
chip_x has joined #freedesktop
chipxxx has quit [Ping timeout: 480 seconds]
<bentiss> alatiera: cpus_ is a hint only IIRC, it doesn't enforce anything on the container
<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
<bentiss> user and userns -> yeah, no. If we need to do anything, I'd go with a script like that checks for the uid and fails if it's root
<bentiss> too many moving targets
<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
<bentiss> cap_add -> haven't played with it but might be able to use user mode containers for virglrenderer, yes
danvet has joined #freedesktop
AbleBacon has quit [Read error: Connection reset by peer]
alanc has quit [Remote host closed the connection]
alanc has joined #freedesktop
thaller has joined #freedesktop
MajorBiscuit has joined #freedesktop
mvlad has joined #freedesktop
agd5f_ has joined #freedesktop
agd5f has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #freedesktop
hadess_ has quit []
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #freedesktop
MajorBiscuit has quit [Ping timeout: 480 seconds]
agd5f has joined #freedesktop
agd5f_ has quit [Ping timeout: 480 seconds]
damian_ has joined #freedesktop
damian has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #freedesktop
<__tim> so the 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?
<mupuf> __tim: yeah, I guess we should also ship busybox to run the script with
<__tim> I wonder if writing a small statically linked rust app would work too (would also work on windows then)
<__tim> but needs to be runner arch specific then I guess
hadess has joined #freedesktop
<mupuf> __tim: yeah, that's what I was proposing, but it is more work
<mupuf> as for creating a script per arch... we already need to have per-arch static binaries for jq and wget
<tintou> Hi there, I wanted to report that I find the windows runners very slow these days
<__tim> there's currently only one runner up instead of two
vkareh has joined #freedesktop
<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
thaller has quit [Ping timeout: 480 seconds]
<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?
<alatiera> bentiss, daniels btw I've been running the gst runners non-priv so far and it doesn't seem anyone has complained
<alatiera> so maybe we could have a dedicated priv runner for the projects that need it and all the rest in non-priv
<alatiera> and tagged accordingly
<bentiss> svuorela: if you look into the groups tab of your profile ( you'll see that you don't have CI-OK, let me fix that
<bentiss> svuorela:should eb fixed
<bentiss> and not fixed because you got added to the repository itself, not the group :/
MajorBiscuit has quit [Quit: WeeChat 3.6]
<bentiss> alatiera: yeah, IIRC most projects were fine, except for virglrenderer
<bentiss> with some crazy weird errors
<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.
<bentiss> pq: I know, but it's a gitlab bug that IIRC we have been chasing for a while at Red hat
<pq> ah
<bentiss> curl -s --header @/tmp/header.tmp\?user_ids\=82673 | jq -> this returns null when it should return svuorela user
<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
<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.
<pq> >_<
<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
<bentiss> but still, relying on groups is better than relying on a list of individuals, so we'll figure it out
<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 ?
<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
Haaninjo has joined #freedesktop
<svuorela> bentiss: will do.
<bentiss> thanks
<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?
<bentiss> eric_engestrom: curl -s --header @/tmp/header.tmp\?user_ids\=1112 | jq '.[].id' -> 1112, so yes :)
<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
<bentiss> eric_engestrom: that's because you are in
<bentiss> eric_engestrom: once you are validated, you can run wherever you want
<eric_engestrom> ok
<eric_engestrom> thanks for the confirmation :)
<bentiss> the MR fallback is to allow people not part of a group but that can still push on a repo
<eric_engestrom> then for all the use cases I can think of, it's all good; thanks for the work!
<bentiss> great :)
Haaninjo has quit [Quit: Ex-Chat]
jarthur has joined #freedesktop
<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
<alanc> like there's several people in who were setup during migration to gitlab but who have never logged into gitlab in the 5years since that
<alanc> (and at least one I know of who had logged in before, but can never login again)
rsjw has joined #freedesktop
<MrCooper> "can never again", as in they passed away?
<emersion> alanc: removing inactive members makes total sense to me
<emersion> the only reason why i don't do it too much is that i don't want to offend someone…
AbleBacon has joined #freedesktop
<alanc> MrCooper: sadly, yes
<MrCooper> sad news; maybe that account can be marked somehow such that it can't be used anymore, nor re-created by someone else
<alanc> yeah, if there's a way to "memorialize"/freeze an account, that would make sense
___nick___ has joined #freedesktop
<bentiss> can't we lock an account?
<bentiss> apparently no. Though we can for sure remove the emails, so there will be no password retrieval possible
<eric_engestrom> 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?
<eric_engestrom> for a test job I mean, for a container job a large timeout is normal
<eric_engestrom> mupuf: ^ since you probably have an opinion :]
<mupuf> eric_engestrom: right, we share a lot of timeouts between machines. The premerge jobs should likely have a muuuuch tighter timeout
<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 :)
feto_bastardo has quit [Quit: quit]
<eric_engestrom> mupuf: ack, and congrats :D
<mupuf> thanks :)
feto_bastardo has joined #freedesktop
rsjw has left #freedesktop [#freedesktop]
vyivel has quit [Remote host closed the connection]
vyivel has joined #freedesktop
hadess has quit [Quit: hadess]
<bentiss> mupuf: ack too, and congrats too :)
<bentiss> jcristau: yeah. I was a bit hesitant with this because we are heavily using this to fight spam :)
<jcristau> makes sense
mvlad has quit [Quit: Leaving]
mohamexiety has joined #freedesktop
danvet has quit [Ping timeout: 480 seconds]
vkareh has quit [Quit: WeeChat 3.6]
___nick___ has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]