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
tales-aparecida63 has quit []
tales-aparecida has joined #freedesktop
Guest6535 has quit []
peelz has joined #freedesktop
peelz is now known as Guest6707
ChasingClouds has joined #freedesktop
ChasingClouds has quit []
robobub has quit []
<DavidHeidelberg[m]>
daniels: marge-bot; 1h 30min please :) (just failed few minute before finishing on zink-freedreno-a630-traces queued for too long - 51 minutes 46 seconds - but the Marge would pass if there would be like 1h 10 minutes)
<DavidHeidelberg[m]>
the default job has 1h limit, so that should be safe
agd5f has joined #freedesktop
agd5f_ has quit [Ping timeout: 480 seconds]
ximion has quit [Quit: Detached from the Matrix]
Leopold_ has quit []
Leopold_ has joined #freedesktop
jarthur has joined #freedesktop
AbleBacon has quit [Read error: Connection reset by peer]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #freedesktop
scrumplex_ has joined #freedesktop
danvet has joined #freedesktop
pjakobsson has joined #freedesktop
scrumplex has quit [Ping timeout: 480 seconds]
eroux has joined #freedesktop
mvlad has joined #freedesktop
<daniels>
DavidHeidelberg[m]: how long is the job timeout on a630-traces??
<daniels>
they should all be way lower than that tbh
<daniels>
this is what I asked you to check the other day before I assented to flipping on retry - if the job timeout is 1h, and we give marge 1.5h, then anything which pushes a job to DNF guarantees at least 90min in between marge processing requests ...
<DavidHeidelberg[m]>
daniels: Timeout: 1h (from project); exception are custom Valve jobs (not impacting Marge), freedreno/zink full runs (2h/1.5h not run by Marge),
<DavidHeidelberg[m]>
daniels: We can try go for 40 minutes; but still I think even with the risk of one MR running 1.5h time to time, it's still more beneficial than fail 5 minutes before finishing re-trying job, which invoke another +40 minutes for Marge run, so if we save two Marge reruns and invoke one timeout, we should still get good numbers
<MrCooper>
DavidHeidelberg[m]: the issue with bumping Marge's timeout is that if something goes wrong, more time is wasted with Marge idling
<MrCooper>
having to retry some pipelines might be the lesser evil
<DavidHeidelberg[m]>
MrCooper: I'm aware, but if we have two to three unnecessary retries a day, it cost more time than one marge timeout a day
<MrCooper>
more time for who/what?
<DavidHeidelberg[m]>
Marge blocked time
<MrCooper>
no other MR can be merged while Marge is idling to the timeout, whereas they can until the pipelines are retried
<DavidHeidelberg[m]>
But then you have another run for the same MR
<MrCooper>
which should be quick(er)
<MrCooper>
since the images already exist
<DavidHeidelberg[m]>
Right, but only should (not talkin about rootfs, but also high network utilization etc.)
<MrCooper>
pipelines which build new images are an exceptional case, Marge's timeout is tuned for the common case
<DavidHeidelberg[m]>
I'm talking about common case now. I added retry: 1 to the jobs, so when job fails once, jt fits the old 1h limit, but when it runs in retry mode, I think there could be some buffer (+30m?) to let the failed job finish
<daniels>
I guess it depends on the frequency of when jobs time out vs. when there's just too much contention
<daniels>
51min queued seems really broken though, and probably not something we need to optimise for?
<DavidHeidelberg[m]>
Sure sure. This shouldn't happen on daily basis (bit it happen time to time). One of things in TODO which should improve that is prioritizing the Marge in LAVA.
jarthur has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mupuf>
I would tend to agree with DavidHeidelberg[m] here. "CI took too long" is definitely a daily occurence
<DavidHeidelberg[m]>
in reality is enough to trigger timeout when someone test a job in their mesa fork and the device is scarce (2-3 devices available per 2 jobs)
<mupuf>
exactly :s
<mupuf>
and because of gitlab's UI, quite oftem developers just press the play button which tests their code on more than what would be necessary :s
* mupuf
would love if we could press play on a job, and let gitlab figure out all the dependencies to run this job
<DavidHeidelberg[m]>
mupuf: I should talk about ci_run_n_monitor more often, I love danielsreminding people the tool exist pretty often :))
<mupuf>
agreed, but honestly, this is not a fix. We need to fix the UI
<DavidHeidelberg[m]>
yup
<mupuf>
IMO, right now, the best we could do is for Marge to be a little smarter and wait for pending machines as long as they are busy running other jobs
<mupuf>
heck, I wouldn't mind if it ***cancelled*** that were not started yet before re-queuing them as a mean to increase its priority
<DavidHeidelberg[m]>
Our team already looking into Marge development :) so Marge will get smarter soon for sure
<mupuf>
sounds great!
<mupuf>
Who initially developed Marge? I thought this was Emma, but then I saw it on gnome's gitlab and that got me thinking
<eric_engestrom>
DavidHeidelberg[m]: FYI you were looking at an old issue; it was moved there and has had activity from gitlab's side 2 weeks ago, it seems they're finally looking into it: https://gitlab.com/gitlab-org/gitlab/-/issues/15059
<eric_engestrom>
(also, I agree with the comments saying this is a bug, not a feature request, as invitations are sent fine but get an error when accepted)
Leopold__ has joined #freedesktop
Leopold_ has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #freedesktop
vbenes has quit [Remote host closed the connection]
jcpvdm has joined #freedesktop
jcpvdm has quit [Remote host closed the connection]
pulsar12 has joined #freedesktop
<pulsar12>
hello, i would like to be verified on gitlab (my account is jcpvdm)
<bentiss>
(namely giving regular developer the ability to block external users by adding a simple label to an issue, and also provide an automatic way of validating users that should be smart enough to outsmart bots)
<bentiss>
I am currently working on the code itself (and being new to rust makes the whole thing slow), but I am planing to split the main.rs function today and add tests
<bentiss>
Right now, I'd like opinion from the crowd here about the 2 issues in this project, but if someone wants to help me on the rust side, that would be also very welcome
MrCooper has quit [Quit: Leaving]
MrCooper has joined #freedesktop
vkareh has joined #freedesktop
MajorBiscuit has quit [Ping timeout: 480 seconds]
jarthur has joined #freedesktop
mohamexiety has joined #freedesktop
ximion has joined #freedesktop
kj has quit [Quit: leaving]
mvlad has quit [Remote host closed the connection]
<mupuf>
Nice, thanks bentiss!
<mupuf>
Sounds like a cool project to learn Rust with!
<mupuf>
I like the fact that the policy is indeed extensible
<mohamexiety>
does anyone else experience weird connectivity problems with cloning any fdo repo? I keep getting 20 - 30 kb/s download speed only.
<mohamexiety>
sometimes I get proper full speed but it's very rare.. (my internet is fine, and cloning non-freedesktop repos works at full speed)
<mohamexiety>
I asked a few RADV devs I know and they don't have any issues but they're all European so I wonder if there's some sort of regional throttling?
AbleBacon has joined #freedesktop
<eric_engestrom>
bentiss: have there ever been any gitlab user reported that weren't spam?
<eric_engestrom>
it might be interesting to hook into the report api (if it exists) and auto-block any user that gets reported
<eric_engestrom>
since that's non-destructive and easy to unblock
<daniels>
eric_engestrom: oh yes
<daniels>
there have been some people who believe the CoC means you can't disagree with anyone, and some which are completely random (presumably from misc users just clicking around)
<bentiss>
eric_engestrom: as said above, it happened already,and the plan is to autoblock reported users yes
<daniels>
bentiss: how about making it autoblock only on reports which come from users who are members of at least one project that isn't in a user namespace?
<bentiss>
daniels: well, to be able to tag an issue with a label you need to be a member of the project, so that makes the condition redundant, no?
<bentiss>
and as for user namespace, I do not see a strong motivation to prevent them access to the bot, because I doubt the amount of regular members who open issues in random user namespace must be pretty low
<bentiss>
s/I doubt/I think
<daniels>
bentiss: ohhh yeah, I misunderstood, thanks
<bentiss>
that's the advantage of using tags :)
<bentiss>
compared to quick actions (even though we can implement those as well, but it'll require a little bit more logic, like the one to check who emitted the quick action)
<bentiss>
eric_engestrom: also I just double checked now, but I don't think gitlab provides a "report abuse" API. I guess it would be opening a bad can of worm
<eric_engestrom>
daniels: oh ok, so auto-block on report would get abused easily
<daniels>
bentiss: yeah, that I guess would have to be a Rails sidecar
<daniels>
eric_engestrom: if all our users were completely reasonable ...
<eric_engestrom>
althought perhaps we could autoblock once two different users have reported the same user?
<eric_engestrom>
(or some other arbitrary number >1)
Brocker has quit [Read error: Connection reset by peer]
vkareh has quit [Quit: WeeChat 3.6]
alanc has quit [Remote host closed the connection]
alanc has joined #freedesktop
Brocker has joined #freedesktop
alpernebbi has quit [Ping timeout: 480 seconds]
ybogdano has joined #freedesktop
pkira_ has joined #freedesktop
thaller_ has joined #freedesktop
__tim4 has joined #freedesktop
gallo7753 has joined #freedesktop
jkhsjdhjs_ has joined #freedesktop
pixelcluster_ has joined #freedesktop
vyivel_ has joined #freedesktop
emersion_ has joined #freedesktop
m5zs7k_ has joined #freedesktop
minus has joined #freedesktop
[Ristovski] has joined #freedesktop
glehmann_ has joined #freedesktop
ocrete7 has joined #freedesktop
glehmann_ has quit []
karolherbst_ has joined #freedesktop
damian has joined #freedesktop
spuc95091337 has joined #freedesktop
lynxis_ has joined #freedesktop
ds- has joined #freedesktop
ndufresne7 has joined #freedesktop
alatiera8 has joined #freedesktop
V_ has joined #freedesktop
pendingchaos_ has joined #freedesktop
glehmann_ has joined #freedesktop
iNKa has joined #freedesktop
gallo72 has joined #freedesktop
mooff has quit [Ping timeout: 480 seconds]
vyivel has quit [Ping timeout: 480 seconds]
karolherbst has quit [Read error: Connection reset by peer]
cazzacarna has quit [Remote host closed the connection]
damian_ has quit [Read error: Connection reset by peer]
cazzacarna has joined #freedesktop
vivia has quit [Remote host closed the connection]
ofourdan has quit [Remote host closed the connection]
mooff has joined #freedesktop
ofourdan has joined #freedesktop
JoshuaAs- has joined #freedesktop
ds` has quit [Read error: Connection reset by peer]
ds- is now known as ds`
egbert has quit [Read error: Connection reset by peer]
vivia has joined #freedesktop
egbert has joined #freedesktop
arekm has quit [Remote host closed the connection]
mairacanal0 has joined #freedesktop
arekm has joined #freedesktop
JoshuaAshton has quit [Read error: Connection reset by peer]
italove3 has joined #freedesktop
__tim has quit [Read error: Connection reset by peer]
ofourdan has quit [reticulum.oftc.net helix.oftc.net]
mooff has quit [reticulum.oftc.net helix.oftc.net]
cazzacarna has quit [reticulum.oftc.net helix.oftc.net]
Brocker has quit [reticulum.oftc.net helix.oftc.net]
Haaninjo has quit [reticulum.oftc.net helix.oftc.net]
pkira has quit [reticulum.oftc.net helix.oftc.net]
thaller has quit [reticulum.oftc.net helix.oftc.net]
pixelcluster has quit [reticulum.oftc.net helix.oftc.net]
minus_ has quit [reticulum.oftc.net helix.oftc.net]
ndufresne has quit [reticulum.oftc.net helix.oftc.net]
gallo7 has quit [reticulum.oftc.net helix.oftc.net]
gallo775 has quit [reticulum.oftc.net helix.oftc.net]
italove has quit [reticulum.oftc.net helix.oftc.net]
ocrete has quit [reticulum.oftc.net helix.oftc.net]
mairacanal has quit [reticulum.oftc.net helix.oftc.net]
V has quit [reticulum.oftc.net helix.oftc.net]
m5zs7k has quit [reticulum.oftc.net helix.oftc.net]
alatiera has quit [reticulum.oftc.net helix.oftc.net]
lynxis has quit [reticulum.oftc.net helix.oftc.net]
spuc9509133 has quit [reticulum.oftc.net helix.oftc.net]
i-garrison has quit [reticulum.oftc.net helix.oftc.net]
jkhsjdhjs has quit [reticulum.oftc.net helix.oftc.net]
emersion has quit [reticulum.oftc.net helix.oftc.net]
pendingchaos has quit [reticulum.oftc.net helix.oftc.net]
Ristovski has quit [reticulum.oftc.net helix.oftc.net]
glehmann has quit [reticulum.oftc.net helix.oftc.net]
ocrete7 is now known as ocrete
__tim4 is now known as __tim
Kayden has quit [Quit: -> office]
glehmann_ has quit []
glehmann has joined #freedesktop
italove3 is now known as italove
ofourdan has joined #freedesktop
mooff has joined #freedesktop
pixelcluster has joined #freedesktop
pkira has joined #freedesktop
cazzacarna has joined #freedesktop
Haaninjo has joined #freedesktop
ndufresne has joined #freedesktop
gallo7 has joined #freedesktop
gallo775 has joined #freedesktop
mairacanal has joined #freedesktop
V has joined #freedesktop
alatiera has joined #freedesktop
i-garrison has joined #freedesktop
jkhsjdhjs has joined #freedesktop
pendingchaos has joined #freedesktop
V has quit [Max SendQ exceeded]
pixelcluster has quit [Ping timeout: 484 seconds]
jkhsjdhjs has quit [Ping timeout: 499 seconds]
pkira has quit [Ping timeout: 484 seconds]
pendingchaos has quit [Ping timeout: 484 seconds]
gallo775 has quit [Ping timeout: 484 seconds]
gallo7 has quit [Ping timeout: 484 seconds]
alatiera has quit [Ping timeout: 484 seconds]
ndufresne has quit [Ping timeout: 484 seconds]
mairacanal has quit [Ping timeout: 484 seconds]
<bentiss>
eric_engestrom: I'd rather have an immediate block on the obvious pattern we see right now: external user, one issue, one spam -> blocked if reported once.
emersion_ has quit [Remote host closed the connection]
emersion has joined #freedesktop
<bentiss>
eric_engestrom: and if there are abuse, then we can probably restrict that block request to project level developers or above
<bentiss>
again, we will have traces, so worse case we can also have a list of users who can not block because they were not fair with the system previously