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
jarthur has quit [Ping timeout: 480 seconds]
reillybrogan_ has joined #freedesktop
reillybrogan has quit [Ping timeout: 480 seconds]
ximion has quit []
Rainer_Bielefeld has joined #freedesktop
pohly has joined #freedesktop
<pohly>
How often do mails get added to the archive of a lists.freedesktop.org list? I sent my first email to syncevolution@lists.freedesktop.org yesterday and it's not in the archive yet. I know that it was handled by the mailing list because I got a copy back.
K`den has joined #freedesktop
Kayden has quit [Read error: Connection reset by peer]
K`den is now known as Kayden
alanc has quit [Remote host closed the connection]
alanc has joined #freedesktop
chaim has joined #freedesktop
xiaolin has joined #freedesktop
xiaolin has left #freedesktop [#freedesktop]
xiaolin has joined #freedesktop
xiaolin has left #freedesktop [#freedesktop]
MajorBiscuit has joined #freedesktop
MajorBiscuit has quit []
MajorBiscuit has joined #freedesktop
tanty has quit []
tanty has joined #freedesktop
pjakobsson_ is now known as pjakobsson
<whot>
pohly: usually it's within a few minutes, but sometimes *something* needs a kick to wake up again
MajorBiscuit has quit [Quit: WeeChat 3.5]
MajorBiscuit has joined #freedesktop
ybogdano has quit [Read error: Connection reset by peer]
danvet has joined #freedesktop
___nick___ has joined #freedesktop
AbleBacon has quit [Read error: Connection reset by peer]
AbleBacon has joined #freedesktop
<pohly>
So "someone" needs to kick "something" to get it unstuck ;-}
<emersion>
not sure how that impacts emails sent by you
<emersion>
oh no
<emersion>
it's just a "permission denied" error
<emersion>
ah, probably because the mbox didn't exist before i imported it
<emersion>
pohly: can you try again?
<mupuf>
What is the policy to add a blog to planet.fd.o? I got contacted by a community (https://flusp.ime.usp.br/) who are apparently mentoring 3 GSoCs this year and would like the students to blog there rather than their own blogs. Is that acceptable? I read every article on the planet, so I can definitely remove them if it doesn't pan out, but I want to make sure this is acceptable
<emersion>
is there a way to filter planet.fd.o by tag/category maybe?
<mupuf>
I don't think so
<emersion>
or maybe they can provide separate feeds?
<mupuf>
yeah, that's what I have done for my blog.
<mupuf>
I guess the difficulty for them is that they would like to share their tutorials there too... although not sure how it would react to changes
<mupuf>
I'll ask them
___nick___ has quit [Ping timeout: 480 seconds]
___nick___ has joined #freedesktop
___nick___ has quit [Read error: Connection reset by peer]
___nick___ has joined #freedesktop
Rainer_Bielefeld has quit [Remote host closed the connection]
AbleBacon has quit [Read error: Connection reset by peer]
ximion has joined #freedesktop
<emersion>
known gitlab outage?
<emersion>
getting 502s
<bentiss>
gitlab's postgresql disk is almost full, I guess that's why we are having issues :(
<alatiera>
bentiss re spam/ad accounts, gnome has the same issue, worth asking how they deal with it
<alatiera>
also snippet spam
<bentiss>
actually, one node is not ready, investigating
<danvet>
bentiss, I was thinking of removing owner membership from your account group, but I guess account groups are very special
<danvet>
unless it's just the ui that disallows access to that
<danvet>
I thought of that since for projects you put into your own space you can edit members
<bentiss>
danvet: that seems weird and probably not possible to do :/
<danvet>
bentiss, yeah, but could have blocked creating forks and stuff :-)
<bentiss>
danvet: we can (IIRC) disable new users to create projects
<danvet>
bentiss, yeah something like that?
<bentiss>
so *maybe* that's what you want
<danvet>
and then give them that permission once they're added (at any level) to some real project
<danvet>
but that's still quite a barrier
<bentiss>
but it's going to be a pain to contribute outside of creating issues
<danvet>
bentiss, well just tossing ideas out there really
<danvet>
bentiss, yup :-(
<bentiss>
danvet:and I really appreciate
* bentiss
likes his idea better of adding an exxtra step in each runners with an allow list of users
<danvet>
bentiss, but the "block CI" thing also has a bit that problem
<danvet>
it's slightly better since you can create projects and MR and all that at least
<bentiss>
danvet: no, because any contributor can restat the pipeline of the new MR, and it will pass the "who started that job"
<danvet>
bentiss, oh
<bentiss>
restart
<danvet>
bentiss, could you then also use that as a signal to add the users to the general allowlist?
<danvet>
since I'm also worried that anything which needs fd.o admin time will simply not scale
<__tim>
the Xiph folks don't allow users to create forks by default, you have to ask for it to have that enabled (which is tedious though, I don't know if that would scale for something like fdo which has much bigger/busier projects)
<bentiss>
danvet: IMO, if you have a valid user, project maintainers add the user as a reporter in the project and we automatically allow pipelines for this project on this user
<bentiss>
__tim: exactl;y, I pretty much rather rely on an extract of the db where users added to an official group/project are allowed to create pipelines
<__tim>
I'm not sure how that would work though, we have lots of drive-by MR contributors which I definitely don't want to add to the gstreamer group/project
<bentiss>
__tim: then in that case their CI fails, you review that there is no change in the gitlab-ci, and you re-run the pipeline. The job will be started by a developer in the project and will pass the initial check
<__tim>
right
<bentiss>
*or* we could simple prevent CI runs in projects not in a group
<__tim>
might be workable, but it will increase maintainer work load a lot
<__tim>
currently in our setup we have the case where one job/sub-pipeline that builds stuff for macos/ios/android etc doesn't work out of the box for external contributors and they complain about that already :)
<bentiss>
that's the problem of being too nice from the beginning with users, they learn to appreciate caviar :)
<__tim>
but maybe it's easier / more understandable if the entire CI doesn't work for them
<danvet>
I guess the big problem is generating the users.txt file to make sure it's as painfree as possible
MajorBiscuit has quit [Ping timeout: 480 seconds]
<bentiss>
well, currently looking at improving the script to check if the user that run the CI is in the group already or not
<bentiss>
basically: if not VIP, but run is a MR, and target project is in a group, and user who started is part of the project (developer+), then valid
<bentiss>
that should cover most of the cases
<bentiss>
hmm... I need a token for that :(
thaytan has quit [Ping timeout: 480 seconds]
thaytan has joined #freedesktop
<bentiss>
ohhh, I get it for free, because CI_PROJECT_ROOT_NAMESPACE is the target project group when using MR pipelines
jarthur has joined #freedesktop
pohly has quit [Quit: Leaving.]
<danvet>
bentiss, might get a bit tricky for multiple nesting levels
<danvet>
or do you have a query that already gives you the aggregate/effective membership?
<danvet>
that would also allow stuff like adding an entire other group to a project at reporter level
<danvet>
which we're already doing
<danvet>
like add all @mesa to drm and stuff like that
<danvet>
I think with that this check should cover most cases indeed, and easy to fix the usual cross-project collaborations
Rainer_Bielefeld has quit [Ping timeout: 480 seconds]
ximion has joined #freedesktop
<bentiss>
danvet: basically my point is: if a project is part of a group, any group, then it's valid freedesktop. This is because regular users can not create groups
<bentiss>
so any group we have has been veted by the org
<bentiss>
and if you have a project within a group or subgroup, the variable CI_PROJECT_ROOT_NAMESPACE will reflect the initial group
<bentiss>
so IMO we are safe. We need to tell people to use MR pipelines or get added to the VIP list
<danvet>
bentiss, yeah that part I fully agree
<danvet>
I was thinking someone who usually does drm work does a mesa PR
<danvet>
but isn't mesa member in any shape
<danvet>
so you could just add drm groups as reporters or so
<bentiss>
I don't have to check on the members themself, just the target project of the MR
<danvet>
kinda like cross-inheritance, instead of only the hierarchical access right inheritence
<danvet>
bentiss, hm but wont this open up abuse by doing a mesa MR, and then completely replacing everything with the crypto miner backdoor?
<danvet>
or I'm confused
<bentiss>
it will not prevent somebody to open an MR and change the .gitlab-ci to introduce an 'ssh' job, but it will have way more visibility
<bentiss>
danvet: exactly, this is possible, but at least the project maintainers will see the problem
<danvet>
bentiss, ah that might be a reasonable middle ground
<bentiss>
right now, they create private repos in the hope that nobody will see them (with their actual name I must say)
<danvet>
and should be pretty simple to check indeed
<danvet>
and I guess if there's too much abuse, we can try to be a bit stricter
<bentiss>
yeah
* bentiss
has 2 kids to put in bed, bbl
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ocrete9 has quit []
ocrete has joined #freedesktop
<bentiss>
regarding the user who created https://gitlab.freedesktop.org/drm/amd/-/issues/2045, which was reported for abuse, I am tempted to ban him so the username gets reserved and noone gets to take it back
<bentiss>
I mean, you have to be an admin to see the email address, and it's even worse than the username and full name
<bentiss>
anybody has any good argument for me not to do that?
<bentiss>
oh, well, it's done
<bentiss>
if anmy admin is against my decision, we can unban him (I am pretty sure it's a him)
___nick___ has quit []
___nick___ has joined #freedesktop
___nick___ has quit []
___nick___ has joined #freedesktop
<Lyude>
bentiss: fine by me. also, had an idea for the interim
<Lyude>
Could we make it so that account requests only come in after an account has verified their email?
<Lyude>
i've noticed the vast majority of the spam accounts don't have verified emails
Haaninjo has joined #freedesktop
___nick___ has quit [Ping timeout: 480 seconds]
<bentiss>
Lyude: I don't see an option to do that. But it would have been interesting, indeed
<bentiss>
but OTOH, I should be able to run a script that deletes all account which haven't verified their email address within 24h (or so)
Rainer_Bielefeld_away has joined #freedesktop
pohly has joined #freedesktop
Rainer_Bielefeld_away has quit []
Consolatis has joined #freedesktop
pohly has quit []
<bentiss>
Lyude: we do enforce email verification, so basically: Email.where(confirmed_at: nil).count => 186 (and 48651 confirmed emails)
karolherbst has quit [Quit: Konversation terminated!]
<Consolatis>
Small question regarding gitlab.fdo: when editing an issue multiple times i got presented a google captcha. Could the spam protection (I assume that was the reason for the captcha) be configured to not trigger at all when a contributor of a project edits its own issue for that same project?
karolherbst has joined #freedesktop
<Consolatis>
The likelihood of a contributor spamming via an issue in the same project seems pretty slim to me. I preferred not to make an exception in uMatrix to allow google so I simply left a typo in the issue as result
karolherbst has quit []
karolherbst has joined #freedesktop
<bentiss>
Lyude, danvet, daniels, robclark : suddenly we have a lot more of banned people on gitlab, has any of you started to play with the ban?
<Lyude>
bentiss: yes.
<bentiss>
(or is it my scripts that should not auto-ban)
<Lyude>
i went through all of the account requests that were pending, a lot of them were pretty easy to figure out
<Lyude>
(i've been googling folks to see if they are actually developers or not, which has been. a bit painful lol)
<bentiss>
oh, OK
<bentiss>
but FWIW, I have a script that filters out peole if they have "casino, shop", etc... in their username, so we should not have to do it by hand
<Lyude>
gotcha, can we get one to delete all account requests that don't get verified within 1 or 2 days (and maybe not send account requests for unconfirmed accounts?)
<Lyude>
dunno if the last one is possible or not
<bentiss>
nope, the last one is not possible
<bentiss>
for the first request, maybe, but I'll need to adapt the script