ChanServ changed the topic of #freedesktop to: https://www.freedesktop.org infrastructure and online services || for questions about freedesktop.org projects, please see each project's contact || for discussions about specifications, please use https://gitlab.freedesktop.org/xdg or xdg@lists.freedesktop.org
MrCooper_ has joined #freedesktop
MrCooper has quit [Ping timeout: 480 seconds]
<whot>
maybe I missed something in the backlog, but is the runner-gating.sh script supposed to be enforcing? because right now it isnt
<__tim>
I think it was disabled again for the night
<whot>
ah, ok, thanks
<whot>
*facepalm* it's in a git repo, I can just look up the commits. and yes, it got re-disabled on purpose
Haaninjo has quit [Quit: Ex-Chat]
Haaninjo has joined #freedesktop
MrCooper has joined #freedesktop
co1umbarius has joined #freedesktop
MrCooper_ has quit [Ping timeout: 480 seconds]
columbarius has quit [Ping timeout: 480 seconds]
co1umbarius has quit [Remote host closed the connection]
co1umbarius has joined #freedesktop
<Venemo>
how can I check the queue of MRs that the marge bot currently has?
chipxxx has joined #freedesktop
jarthur has quit [Ping timeout: 480 seconds]
jarthur has joined #freedesktop
Leopold__ has joined #freedesktop
Leopold___ has quit [Ping timeout: 480 seconds]
snuckls_ has joined #freedesktop
miracolix has quit [Ping timeout: 480 seconds]
ximion has quit [Quit: Detached from the Matrix]
BlkPoohba has quit []
rsjw has quit [Quit: rsjw]
Leopold__ has quit [Remote host closed the connection]
<bentiss>
anholt: yep, looks like that guy came back
<bentiss>
or it's simply dead. I can't even reboot it from the equinix console
<bentiss>
mupuf: that guy "First Name Last Name", it's the one who asked here credentials yesterday "rsjw". I asked him/her to specifically use the template, so I won't bother with him and just let him go away
<mupuf>
bentiss: I see
<mupuf>
indeed, the guy went out of his way to remove the issue
<bentiss>
mupuf: but at least we don't appear to be the bad guys here with your answer. So...
<bentiss>
well, m3l-16 is dead I think. It doesn't even respond to reboot or rescue from the equinix console. I'll just respawn a new one (and test my cloud-init modifications)
dcbaker has quit [Quit: Bridge terminating on SIGTERM]
Wallbraker has quit [Quit: Bridge terminating on SIGTERM]
gkiagia has quit [Quit: Bridge terminating on SIGTERM]
DavidHeidelberg[m] has quit [Quit: Bridge terminating on SIGTERM]
twopubsolar[m] has quit [Quit: Bridge terminating on SIGTERM]
nirbheek has quit [Quit: Bridge terminating on SIGTERM]
bstrie[m] has quit [Quit: Bridge terminating on SIGTERM]
bendlas[m] has quit [Quit: Bridge terminating on SIGTERM]
ewlsh[m] has quit [Quit: Bridge terminating on SIGTERM]
muhlinux[m] has quit [Quit: Bridge terminating on SIGTERM]
razze[m] has quit [Quit: Bridge terminating on SIGTERM]
gnfzdz[m] has quit [Quit: Bridge terminating on SIGTERM]
aenderboy[m] has quit [Quit: Bridge terminating on SIGTERM]
tintou has quit [Quit: Bridge terminating on SIGTERM]
Trevinho has quit []
swick[m] has quit [Quit: Bridge terminating on SIGTERM]
tinywrkb has quit [Quit: Bridge terminating on SIGTERM]
pitsch[m] has quit []
ylatuya[m] has quit [Quit: Bridge terminating on SIGTERM]
dylan-m[m] has quit [Quit: Bridge terminating on SIGTERM]
cassidy[m] has quit [Quit: Bridge terminating on SIGTERM]
pv has quit []
jenatali has quit [Quit: Bridge terminating on SIGTERM]
mitTengiz[m] has quit []
ttancos[m] has quit []
heftig has quit [Quit: Bridge terminating on SIGTERM]
marcel203s[m] has quit [Quit: Bridge terminating on SIGTERM]
scorpion2185[m]1 has quit []
nielsdg has quit [Quit: Bridge terminating on SIGTERM]
unrznbl[m] has quit [Quit: Bridge terminating on SIGTERM]
Soroush has quit [Quit: Bridge terminating on SIGTERM]
inpursuitofsilence[m] has quit [Quit: Bridge terminating on SIGTERM]
alatiera_afk[m] has quit [Quit: Bridge terminating on SIGTERM]
therickestrick001[m] has quit []
sergi has quit [Quit: Bridge terminating on SIGTERM]
Hazematman has quit [Quit: Bridge terminating on SIGTERM]
sewn has quit [Quit: Bridge terminating on SIGTERM]
tomeu has quit [Quit: Bridge terminating on SIGTERM]
dabrain34[m] has quit [Write error: connection closed]
zeenix[m] has quit [Write error: connection closed]
nazarewk[m] has quit [Write error: connection closed]
chrysn[m]1 has quit [Write error: connection closed]
gallo[m] has quit [Write error: connection closed]
siddh has quit [Write error: connection closed]
halfline[m] has quit [Write error: connection closed]
kusma has quit [Write error: connection closed]
m5zs7k_ has quit [Max SendQ exceeded]
Mark[m]1 has quit [Write error: connection closed]
<bentiss>
\o/ the generate-cloud-init script is working fine. I did not mess up yesterday :)
<ofourdan>
quick question, I asked i none of the MR, but I gues I might as well ask here - The gitlab-ci chnage to enable detached MR pipelines, we need to cherry pick the change in all ctable branches as well, otherwise the backport MRs will have their CI fail, right?
<ofourdan>
(sorry too many typos!)
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #freedesktop
<MrCooper>
ofourdan: presumably, yes
<bentiss>
ofourdan: yes, but it was slightly too disruptive, so I am looking into another solution.
<ofourdan>
so I shouldn't fiel the backport MR?
<bentiss>
ofourdan: conceptually the same (a script will allow or not), but maybe more robust
<bentiss>
ofourdan: still foggy, so I can't really tell you a definite answer
<bentiss>
basically, we have 2 options: one is register all legit users in a special group, all legit users mean all of those who are in an actual project as reporter at least
<bentiss>
the other is to better detect MR through environment variables and allow them there
<MrCooper>
the latter would still allow abuse via MRs, wouldn't it?
<bentiss>
MrCooper: yes and no. It depoends on the implementation and the restrictions we put in place :)
<bentiss>
MrCooper: TBH, I already know that there is a gigantic hole in that process. But I won't tell it ther, just because I do not want to have people just cherry-picking the solution
<bentiss>
so... what is interesting, is that with the CI_JOB_TOKEN, I can retrieve the https://gitlab.freedesktop.org/api/v4/job information, which has a lot of interesting things ;)
danvet has joined #freedesktop
gallo7753 has quit [Remote host closed the connection]
gallo7753 has joined #freedesktop
ximion has quit [Quit: Detached from the Matrix]
agd5f_ has joined #freedesktop
kbingham has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
mvlad has joined #freedesktop
MajorBiscuit has joined #freedesktop
agd5f has joined #freedesktop
agd5f_ has quit [Ping timeout: 480 seconds]
strk has joined #freedesktop
<strk>
hello there, thanks for what you guys are doing with the free desktops !!
<strk>
I've a question about icons... how do I tell which directories are scanned for icons ?
<strk>
I'm using an application which doesn't seem to recognize the name of an icon but I have it in many places: https://termbin.com/6ugr
AbleBacon has quit [Read error: Connection reset by peer]
<eric_engestrom>
strk: see /topic, this channel is about the infrastructure on freedesktop.org
<eric_engestrom>
strk: I don't know where you should go to ask about icons though; good luck :)
<ofourdan>
maybe on the xdg mailing list (<xdg@lists.freedesktop.org>)?
<strk>
is there no xdg room that you know ?
<strk>
(chat room)
<ofourdan>
or maybe try to get in touch the the app devs of that particular application which fails to load the icon?
vbenes has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
<bentiss>
Finally! Well, it's not a solution, but I managed to understand why gstreamer projects are different than mesa in respect to the merge pipelines:
<bentiss>
but on gstreamer, developers/maintainers can not push on protected branches, only marge can...
<bentiss>
dabrain34[m]: yes, it's normal, it is temporary disabled, too disruptive for regular projects
<dabrain34[m]>
ok
<dabrain34[m]>
but i'm not sure if I should add the snippet: workflow: rules: - if: $CI_PIPELINE_SOURCE == 'merge_request_event' - if: $CI_PIPELINE_SOURCE == 'push' to my project then
<bentiss>
dabrain34[m]: for now, it's not necessary, I'm still trying to understand if I can do something better
<bentiss>
dabrain34[m]: so hold on a little
<dabrain34[m]>
ok thanks for confirming
<bentiss>
please :)
<mupuf>
bentiss: right!
<mupuf>
good find!
<bentiss>
mupuf: so after testing, it turns out that gstreamer also protects '*' which is the problem
<mupuf>
well, the fix would be easy then: remove * from the protected branches and use social rules to enforce not creating branches there
<bentiss>
mupuf (or anyone else, really): can I borrow a little bit of your time and prepare a project based on https://github.com/moparisthebest/static-curl/ which would build both curl *and* jq for aarch64 and x86_64
<bentiss>
mupuf: yes, or change the regex to something that doesn't break this
<bentiss>
regarding jq, I can officially download for x86, but not arm. And if I have this I can protect the script against kiddies overwriting the variables
<mupuf>
bentiss: sure
<mupuf>
let me create a pipeline in the bot repo
<bentiss>
mupuf: thanks!
Trevinho[m] has joined #freedesktop
Wallbraker has joined #freedesktop
alatiera_afk[m] has joined #freedesktop
aenderboy[m] has joined #freedesktop
anomalous_creator[m] has joined #freedesktop
bendlas[m] has joined #freedesktop
bstrie[m] has joined #freedesktop
cassidy[m] has joined #freedesktop
chrysn[m]1 has joined #freedesktop
cmeissl[m] has joined #freedesktop
dabrain34[m]1 has joined #freedesktop
dcbaker has joined #freedesktop
dylan-m[m] has joined #freedesktop
ewlsh[m] has joined #freedesktop
gallo[m] has joined #freedesktop
gkiagia has joined #freedesktop
gnfzdz[m] has joined #freedesktop
halfline[m] has joined #freedesktop
hasebastian[m] has joined #freedesktop
Hazematman has joined #freedesktop
heftig has joined #freedesktop
inpursuitofsilence[m] has joined #freedesktop
jenatali has joined #freedesktop
jjardon[m] has joined #freedesktop
kusma has joined #freedesktop
mairacanal[m] has joined #freedesktop
marcel203s[m] has joined #freedesktop
Mark[m] has joined #freedesktop
muhlinux[m] has joined #freedesktop
nazarewk[m] has joined #freedesktop
nielsdg has joined #freedesktop
nirbheek_ has joined #freedesktop
DavidHeidelberg[m] has joined #freedesktop
pitsch[m] has joined #freedesktop
pv has joined #freedesktop
razze[m] has joined #freedesktop
scorpion2185[m]1 has joined #freedesktop
sewn has joined #freedesktop
siddh has joined #freedesktop
sergi has joined #freedesktop
Sumera[m] has joined #freedesktop
swick[m] has joined #freedesktop
Nova[m] has joined #freedesktop
therickestrick001[m] has joined #freedesktop
tintou has joined #freedesktop
tinywrkb has joined #freedesktop
underpantsgnome[m] has joined #freedesktop
tomeu has joined #freedesktop
ttancos[m] has joined #freedesktop
twopubsolar[m] has joined #freedesktop
mitTengiz[m] has joined #freedesktop
Soroush has joined #freedesktop
unrznbl[m] has joined #freedesktop
MatrixTravelerbot[m]1 has joined #freedesktop
ylatuya[m] has joined #freedesktop
zeenix[m] has joined #freedesktop
zredshift[m] has joined #freedesktop
miracolix has joined #freedesktop
<bentiss>
Alright. Once I get jq for aarch64, I'll be able to iron out the gating script (without changing the protected branch settings): using the job token I can retrieve reliable data like commit, type of pipeline, and then I'll be able to check that the CI_MERGE_REQUEST_PROJECT_ID variable has not been tempered with, by checking if the job's commit is present in the target tree...
snuckls_ has quit [Ping timeout: 480 seconds]
<mupuf>
bentiss: do we have a local copy of alpine:latest?
<mupuf>
or a proxy to docker.io?
bionade24 has quit [Remote host closed the connection]
<mupuf>
bentiss: can I remove the duplicate packages?
Leopold_ has joined #freedesktop
<mupuf>
or did you already start using them?
<bentiss>
mupuf: many thanks!
<bentiss>
no, I haven't pulled them
<bentiss>
but even if it's going to be a one off, everytime we respin a runner, so we can safely kill them at will
<mupuf>
excellent
<bentiss>
mupuf: just FYI, now, all jobs will have an available curl/jq at /host/bin, in case you hate wget ;)
<mupuf>
lol
<mupuf>
I would rather not depend on anything coming from the runner's host ;)
<bentiss>
heh :)
<mupuf>
crossing fingers that jq will work nicely
<mupuf>
it doesn't pass its test suite when when built statically
<bentiss>
should be easy enough to test
<bentiss>
oh...
* mupuf
added a simple test as part of the build process
<bentiss>
well, I am not doing a lot of fancy stuff with it, just fetching fields in json
<mupuf>
yeah, exactly, shoud be fine
<jenatali>
bentiss: alatiera: Are you planning to apply this policy to the Windows runners too?
<mupuf>
I used the commands they recommend for building static binaries
<bentiss>
jenatali: I don't have any sort of control over the windows runners, so it's up to you and Collabora to enforce it I guess
<jenatali>
Ack. So it's up to Collabora then I guess
* mupuf
hopes the static binary jobs won't get built every single time an MR comes to this repo
mohamexiety has joined #freedesktop
<bentiss>
mupuf: it's deployed on all runners I control. Now I'm trying to implement the new script
<mupuf>
yeepee!
<alatiera>
windows is more fucked up, cause one of the runners is a shell executor
<bentiss>
alatiera: would it make sense to register the windows runners only in the few project they are required?
<bentiss>
like gstreamer and mesa?
alpernebbi has quit [Ping timeout: 480 seconds]
<alatiera>
I think so
<alatiera>
although with the pre-clone hook we might be good
<alatiera>
but I haven't managed to get around it yet
<ndufresne>
Won't that break pre-merge CI all over the place ? "Starting 2023-03-14, or before if we see a spike in the attacks, only pipelines running in a known, official project will be run on the shared runners we manage at freedesktop.org. Jobs for projects in personal namespaces will not be able to leverage shared runners."
<ndufresne>
ah, I think its the working that is very confusing
<ndufresne>
So if the CI is part of a Merge request (that everyone see) it will run for everyone ?
<ndufresne>
* the wording)
<bentiss>
ndufresne: that's the plan yes
<bentiss>
ndufresne: yesterday it broke pre-merge for gstreamer, and I found out why today, so making more tests
<ndufresne>
ah, that's the thing that update the docs I suppose
<ndufresne>
made a patch to add myself, but when I came to write the commit, I didn't figure-out why I'd need to be an exception, maybe I'll abstain ...
<ndufresne>
(specially that I usually use a private runner when I want to mess around CI script without affecting anyone)
MrCooper has joined #freedesktop
<bentiss>
ndufresne: honestly, there are no reasons for not adding yourself to the list, and that's the pain point: because of a handlful of persons, we have to put restrictions on anybody :(
<ndufresne>
its not like we didn't know this would ever happen, from day one we knew it was easy to use the runners for non-coding related tasks, so I'm not upset, glad we could avoid it for so long of course
<ndufresne>
its just illustrate how the majority of the crypto users are anarchist that don't care about others
<bentiss>
yeah. It's actually surprising we had such a long ride without much trouble TBH :)
* alatiera
hasn't manage to catch up on the backlog from yday yet 😆
<cassidy[m]>
how can I still use shared runners despite not being (yet) in this users list?
<jenatali>
Venemo: From that screenshot, only 2 of the 5 issues were WSL-specific... IMO I don't see the point of such a label
<alyssa>
bentiss: " 14:17 <bentiss> ndufresne: honestly, there are no reasons for not adding yourself to the list, and that's the pain point: because of a handlful of persons, we have to put restrictions on anybody :( "
<alyssa>
I've given this a bit more thought since yesterday
<alyssa>
Here's the thing... I can't articulate a single *good* reason to not have a public list of authorized gitlab usernames
<Venemo>
jenatali: can you respond to the issue and close?
<alyssa>
bentiss: and for every complaint about that list, I hear a dozen complaints about CI not working well
<alyssa>
which makes me very much inclined to say we should do the public username allowlist approach anyway, even though somebody somewhere didn't like it for some reason
<alyssa>
(If there is an *actual* good reason that someone can articulate on why we absolutely cannot have this list public, then please tell me, either here or in a private message. But I'm really struggling to come up with one.)
ximion has quit [Quit: Detached from the Matrix]
<bentiss>
alyssa: Agree :)
<alyssa>
bentiss: Great. Who do I need to convince to make this happen then? ;)
<bentiss>
but meanwhile we can try to make the CI work as close as possible than previously while that list is set in place
<alyssa>
Yeah, obviously it couldn't be effective until N weeks after we decide we're doing it, to get all the names in place
<bentiss>
alyssa: how do you envision fomring that list? opt-in like today? or mass import?
<alyssa>
Not sure yet.
<Venemo>
what is wrong with opt-in?
<alyssa>
Venemo: Pain in everyone's ass
<bentiss>
just takes time :)
<Venemo>
for example, I don't see why I would need my name on that list
<alyssa>
Venemo: so you can check CI manually (possibly a subset of jobs) for a draft MR that's not ready to go to merge
<bentiss>
what would be nice actually was if every project/group creates an issue to gather the list with a @all, and then submit *one* mr for the entire project
<Venemo>
I usually just click on the play button on my MRs, which should be fine right? or I push directly to the valve ci which should also be fine because it's already restricted
<alyssa>
Venemo: right, this list is "the list of people authorized to click play buttons on their MRs"
<Venemo>
ah
<jenatali>
Or more specifically the list of people who can click play before creating a MR
<Venemo>
I see...
<jenatali>
(If I understand correctly anyway)
<jenatali>
As long as you have developer permissions, the MR pipeline that's created should be able to be played. If you don't, a developer will have to create one for you
<alyssa>
Venemo: DM'd the reason
<Venemo>
got it
<Venemo>
so because I have the developer role already, my name doesn't need to be on a list right? or would this be restricted even further?
<alyssa>
right, so
<alyssa>
bentiss: The easiest answer is a mass import of anyone with develper roles on project namespace projects
<jenatali>
The developer role ensures that MR pipelines work. If you want fork pipelines to work (without creating a MR) then you need to be on this list
<alyssa>
which I think should get 99% of what we want
<bentiss>
Venemo: I can not get the list of the members of a group without authentication, so I need to create a specifc list with the users. So you'll need to be added to that list manually at some point
<Venemo>
then I got two suggestions: either put everyone who currently has the developer role to the list, or just see who submitted at least 10 patches in the past 6 months and add them to the list
<alyssa>
the former should be straightforwardish with the gitlab api (and authentication)
<bentiss>
alyssa: agree, but I don't want to be placed on the spot because I did a mass import of a public list os users, and one of them is not happy that the logs will show it forever
<alyssa>
bentiss: great, then send me the list and I'll MR it and take the blame :~P
<alyssa>
(am I being facetious? I don't even know myself!)
<bentiss>
heh
<ndufresne>
alyssa: for me opt-in / creating an MR does not sound painful at all, just to be encouraging here, i only use manual branch CI for CI dev, which I've been away from for some times in now, hence no urgency
* bentiss
likes his idea better actually: rely on project/group maintainers to build that list
<ndufresne>
In GST, we quickly try and promote contributors into a role, so that works well for us
<ndufresne>
(add more names to the autocompletion too, though I wish that was global sometimes)
<alyssa>
bentiss: that'd probably be ok too :)
<alyssa>
particularly if you could supply project/group maintainers a script to dump out the usernames for contributors in their org
<alyssa>
(There are a /lot/ for mesa.)
<ndufresne>
Would that mean we want to keep synching it, as we may remove/add roles
<alyssa>
ndufresne: I'm less worried about that. Removing roles doesn't mean removing permissions, unless the reason for removing the permissions was, yknow, someone running a cryptominer or something
<alyssa>
Adding roles, I guess people can MR themselves later, I'm more worried about not regressing anybody's workflow for the initial rollout
<bentiss>
ndufresne: I think the problem is more of a jump start. I trust anybody added to that list by a maintainer would not be a cryptominer
<bentiss>
and once you get new contributors, then you can ask them to add themself to the list
<bentiss>
alyssa: should be easier done through the gitlab python module though (it handles pagination)
<__tim>
I wonder if we could/should create a list of people in the gating script CI with a script api token that has the necessary permissions to query group membership (then that's not needed at the time the script runs), not sure if that would buy is anything
<bentiss>
I have just uploaded my new version of the script. It's not enforced, again, but it should allow to check if the policy would prevent the pipelines. If it actually stops a pipeline, please ping me
<alyssa>
__tim: that's exactly what we're discussing, afaiu
<__tim>
ah sorry, only skimmed the backlog
<bentiss>
__tim: no worries.
<bentiss>
FWIW, I haven't tried today the ci-ok group solution we were discussing yesterday, because I am still unsure how I can provide a token that would allow just to retrieve the members of the group
<bentiss>
I would have loved for the CI_JOB_TOKEN to allow that, but it's not the case :(
MajorBiscuit has quit [Ping timeout: 480 seconds]
<jenatali>
alatiera: I'd really like to get Mesa Windows CI turned back on ASAP. The Windows build has already been broken in the few days it's been disabled
<jenatali>
daniels: ^^
<alatiera>
I turned one of the shared runners back on, think yday or the day before
<alatiera>
its not the permanent solution, haven't yet looked at porting the pre-clone script to powershell or what extra we might need
<alatiera>
but it should be working as before for now
<jenatali>
As before, but only at half capacity?
<jenatali>
Not sure if that's enough to feel comfortable turning CI back on
<__tim>
for a long time we only had a single windows runner
<__tim>
the second one was added mostly for redundancy
<jenatali>
Alright, fair enough
<jenatali>
Guess once we fix the build we can turn it back on
<alatiera>
let's see how it goes with one runner for now
<alatiera>
the whole issue is that if anything goes wrong again with the attacker I'd rather have to look only one of them rather than both
<alatiera>
as well as giving them less resources to mine
<jenatali>
Ack, makes sense
<__tim>
now would probably also be a good opportunity to check that there's no more projects using the old 1809 windows runner
<__tim>
so we can ditch that one
<alatiera>
I think the only I saw last time was gfx-ci-box/mesa but can't find what pipeline or branch was it
alyssa has left #freedesktop [#freedesktop]
DodoGTA has left #freedesktop [#freedesktop]
DodoGTA has joined #freedesktop
agd5f has joined #freedesktop
alanc has quit [Remote host closed the connection]
alanc has joined #freedesktop
agd5f_ has quit [Ping timeout: 480 seconds]
mohamexiety has quit []
mvlad has quit [Remote host closed the connection]
Haaninjo has joined #freedesktop
vkareh has quit [Quit: WeeChat 3.6]
DodoGTA has left #freedesktop [#freedesktop]
DodoGTA has joined #freedesktop
mohamexiety has joined #freedesktop
<bentiss>
actually, thinking about the group solution more, this might be easier than the one I got today: I "just" have to create an instance wide protected variable with a group token of the ci-ok group, and unsure I unset it before entering the script phase (not tested)
<bentiss>
and with groups, I can invite other groups, meaning that giving CI rights is just adding someone to an existing group
<bentiss>
and then I just drop all of the MR requirements. If a drive by contributor passes, someone with CI privileges just need to run the pipeline