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
Kayden has joined #freedesktop
nephyrin has quit [Quit: ... besides, it was hot]
Kayden has quit [Quit: Leaving]
Kayden has joined #freedesktop
scrumplex_ has joined #freedesktop
scrumplex has quit [Ping timeout: 480 seconds]
nephyrin has joined #freedesktop
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #freedesktop
snetry has joined #freedesktop
guludo has quit [Ping timeout: 480 seconds]
sentry has quit [Ping timeout: 480 seconds]
Consolatis has quit [Ping timeout: 480 seconds]
Consolatis has joined #freedesktop
georgc has joined #freedesktop
gchini has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: Leaving]
Kayden has joined #freedesktop
Caterpillar has quit [Read error: Connection reset by peer]
<mupuf>
I hope you don't mind I pushed directly to a branch on the repo rather than forking it
<mupuf>
It goes without saying, this is completely untested O:-)
Guest14666 has quit []
xelxebar has joined #freedesktop
xelxebar is now known as Guest15461
Guest15461 is now known as xelxebar
mceier has joined #freedesktop
swatish2 has quit [Ping timeout: 480 seconds]
jsa1 has joined #freedesktop
___nick___ has joined #freedesktop
___nick___ has quit []
swatish2 has joined #freedesktop
sima has joined #freedesktop
tzimmermann has joined #freedesktop
<bentiss>
mupuf: thanks. I've deployed it, it should be good now
<mupuf>
bentiss: thanks! Giving it a try
<bentiss>
__tim: yeah, it looks like the same issues we were having when I first enabled fastly. However, this time I have the same timeouts. I'm afraid it's because it's using compute and they have some restrictions on how long a connection can be
<mupuf>
bentiss: looks good all around, thanks!
<bentiss>
\o/
<bentiss>
thank you!
<mupuf>
my pleasure, new skill unlocked... ish :D
<bentiss>
yeah, congrats!
<bentiss>
FWIW, once we get https://github.com/TecharoHQ/anubis/issues/468 fixed, deployment of that compute will be much easier as for now it relies on a very dirty hack on my laptop for rust-jwt-simple to accept anubis cookie
<bentiss>
so others will be able to deploy it
<DemiMarie>
Where do I report the missing SPF/DKIM/DMARC on members.x.org?
<DemiMarie>
Iām pretty sure that is either a DNS configuration problem or a mail server misconfiguration.
<DemiMarie>
Also, what is the right place for someone to announce they are hiring a graphics developer?
<bentiss>
re dns/spf/dmarc: that would be daniels or emersion ^^ (maybe they'll want an issue on gitlab.fd.o, don't know)
ximion1 has quit [Remote host closed the connection]
<emersion>
DemiMarie: i've noticed but had no time yet to fix it
jsa1 has quit [Ping timeout: 480 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
<MrCooper>
karolherbst: oddly, I don't remember ever seeing the anubis portal for any significant amount of time with Firefox on this machine; I wonder if it might be due to using the official Firefox flatpak, I noticed before that can be significantly faster than distro builds
<karolherbst>
possibly
<karolherbst>
I should check that out
<karolherbst>
_huh_
<karolherbst>
that is indeed fasater
<karolherbst>
ehh it's also faster on non flatpak firefox
<karolherbst>
guess the difficulty is now lower or an update got deployed or anything
<karolherbst>
or random other reasons.. mhhh
<karolherbst>
I wonder...
<karolherbst>
mhh no idea
atticf has quit [Remote host closed the connection]
atticf has joined #freedesktop
<mupuf>
karolherbst: was your laptop's battery close to being dead when you first experienced the slow behaviour?
<karolherbst>
no
<karolherbst>
it's not like the calc speed was shown as being any higher, I think the problem to solve was just esaier
<MrCooper>
maybe I just didn't hit the slow case by luck then
Kayden has quit [Quit: networkbork]
Kayden has joined #freedesktop
jsa1 has joined #freedesktop
<__tim>
bentiss, so I'm pretty sure it's either fastly or anubis that's causing the issues with the large artifact uploads, because if I bypass fastly on the runner it works just fine
<__tim>
bentiss, re. what you said, i'm not sure where that leaves us. We currently can't get any MRs in, and we have a GStreamer hackfest next week. Perhaps we can disable Anubis again until there's a solution that works for us as well? Or can you add some runner IPs to a exemption list?
<MrCooper>
if bypassing fastly helps, doesn't that indicate a fastly issue rather than anubis though?
<__tim>
maybe, I'm not sure where/how things are deployed
<__tim>
but it started failing right after anubis was enabled afaik
<bentiss>
__tim: sorry I'm off today as well. Bypassing anubis and fastly on the runners seems like the best option
<bentiss>
(that's what I'm doing on the fdo htz runner as well, for different reasons)
<mupuf>
bentiss: no need to answer before monday, but if we wanted to do the same, we would use ssh.gitlab.freedesktop.org instead of gitlab.freedesktop.org? Or is there another DNS entry?
<bentiss>
MrCooper_: the problem is indeed in fastly, but because I'm using a compute deployment instead of a VCL like previously. Not sure why, but the compute seems to still be around while the body is not finished transferring, and there is a hard limit of 2 minutes
<bentiss>
mupuf: ssh.gitlab.fd.o is fine, but you need to add an overwrite in the gitlab-runner config (or a /etc/hosts). I haven't done any enforcing on that endpoint, so it should be working
<__tim>
bentiss, I'm not sure if I can bypass on the macos/windows runners (windows more likely, macos unsure how to do that right now)
<bentiss>
the only problem is that's a manual step needed to be done on all runners :(
<bentiss>
__tim: the macos runner is running docker?
<__tim>
no, it's a VM thing using tart or something
<__tim>
sure, something to try (though I had not much success doing that inside the docker on linux, but maybe that's because I didn't find how to clear the cache properly)
<bentiss>
for docker on linux, you need to add an exception in the gitlab-runner config
<__tim>
yes, I've done that, and that works
<bentiss>
a solution could be that we (fdo) host a dedicated dns server which overwrites the IP of gitlab.fd.o so it's configured once in case we need to change IP, but not today :)
<__tim>
I'll poke at it some more, thanks
<bentiss>
sorry
<bentiss>
but anubis had a nice impact on bots (I don't see any in the logs now). I'm not sure how I can trust the numbers reported by fastly, but they seem much better as well
<__tim>
not sure I understand why it can't just be switched off again until we have a solution that works for everyone :)
<__tim>
it's not like gitlab was unusable three days ago
jsa2 has joined #freedesktop
<bentiss>
TL;DR: I need to fix the VCL config because there were too many caches issues. And the VCL config is just a mess to work with
<bentiss>
so switching back means me spending a couple of hours doing that
<__tim>
ouch, alright :)
<bentiss>
and if you add those overwrites to the gst runners, then we can do whatever we want on fastly, and you are not impacted
<bentiss>
meaning we can change some of the timeouts to be better
<__tim>
ack
<bentiss>
anyway, going AFK again
jsa1 has quit [Ping timeout: 480 seconds]
<__tim>
Thanks for your help
MrCooper_ is now known as MrCooper
<xe>
__tim: would it be possible for you to get a gitlab runner to hit an arbitrary URL for me so I can improve a bloom filter?
<__tim>
you mean just run curl or wget on an url you give me?
fomys_ has quit []
krastevm has joined #freedesktop
xe has quit [Quit: WeeChat 4.6.2]
martink has quit [Read error: Connection reset by peer]
<gallo[m]>
fwiw, updates are slower than usual since the mesa-performance-tracking scheduled pipelines stopped working after a recent GitLab upgrade. We're tracking the issue here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13057. For now, updates are being done manually
<karolherbst>
bentiss: accounts sign ups seem to be down a bit as well
<karolherbst>
maybe we could even get rid of spam detection with that? would be nice
Traneptora has joined #freedesktop
AbleBacon has joined #freedesktop
<jasuarez>
gallo: thanks! Maybe we should add that to Mesa documentation?
swatish2 has joined #freedesktop
pzanoni has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #freedesktop
swatish2 has quit [Ping timeout: 480 seconds]
haaninjo has joined #freedesktop
Kayden has quit [Quit: away]
todi has quit []
jsa1 has joined #freedesktop
jsa1 has quit [Ping timeout: 480 seconds]
andy-turner has quit []
AbleBacon has quit [Read error: Connection reset by peer]