07:24ofourdan: hey, sorry to be a pain, I can't pull from git@gitlab.freedesktop.org:xorg/xserver.git (but https works though), is that a known issue?
07:26psykose: needs to use ssh.gitlab.freedesktop.org
07:27ofourdan: thanks!
07:36MrCooper: FWIW, I recommend using HTTPS for fetching, performs better IME; can use SSH for pushing only via pushurl in .git/config
07:38emersion: sounds cumbersome to set up for each repo
07:46ofourdan: yep, could do that as well, but that would have hidden the problem for me until I needed to push, which is usually when I need to make a release, so better to fail now than when I need to do a release :)
07:50jadahl: Host gitlab.freedesktop.org
07:50jadahl: Hostname ssh.gitlab.freedesktop.org
07:50jadahl: in ~/.ssh/config might help
07:51ofourdan: that's a good idea!
08:27pq: Was there not a banner on gitlab.fdo to explain the ssh hostname change? Might have saved a lot of questions. :-)
12:46martink: heya, I'm in the process of reinstating vmware farm, and I notice something weird: apply-overlays section of the lava-ci job intermittently times out, and looking at the timeout tags -- those durations just minuscule. That's a first for me, did some job/section times get overhauled recently?
13:28daniels: martink: hm, how miniscule? we allow some minutes for this
13:29martink: daniels: it seems modules.tar gets downloaded repeatedly: https://gitlab.freedesktop.org/blu/mesa/-/jobs/74585286
13:31daniels: martink: I guess the reason it gets downloaded twice during the validate section is because HEAD is not supported from s3 anymore perhaps? this is where you really want to have nginx set up to do local caching
13:35martink: daniels: hmm, local nginx service is running on 80 and I have the latest docs/ci/uri-caching.conf.. let me see what else is missing
13:36daniels: mm, it did accelerate from 2MB/sec to 17MB/sec, but that still seems kind of crashingly slow?
13:39martink: daniels: 17MB/s does seem low. normally it would've be sitting in the min-20, up to 40MB/s.
13:47daniels: martink: I don't see the same 'using caching service' lines as in https://gitlab.freedesktop.org/mesa/mesa/-/jobs/74578262
13:47daniels: is it set with https://docs.lavasoftware.org/lava/proxy.html ?
14:08zmike: is it expected that trace jobs don't have dmesg logs?
14:08zmike: e.g., https://mesa.pages.freedesktop.org/-/mesa/-/jobs/74581538/artifacts/results/summary/results/trace@gl-zink-anv-adl@SirYouAreBeingHunted@sir-f750-v2.trace.html
14:14martink: daniels: my /etc/nginx/sites-available/fdo-cache is a bit custom, and also somewhat stale..
14:18martink: daniels: ok, it does definitely seem like a caching issue, thanks for the tips!
14:38daniels: martink: np!
14:38daniels: zmike: yeah, no dmesg would've been emitted whilst it curl'd a file and was disappointed about the formatting of the md5
14:38zmike: ah
21:41pinchartl: hmmmm... https://gitlab.freedesktop.org/camera/libcamera/-/pipelines/1405429 doesn't show the CI pipeline in firefox, but does in chrome
21:41pinchartl: "Uncaught SyntaxError: illegal character U+0003"
21:42pinchartl: when loading https://gitlab.freedesktop.org/assets/webpack/pages.projects.pipelines.show.244a732b.chunk.js
21:42pinchartl: which appears to be binary content when loaded in firefox
21:43pinchartl: downloading it with wget gives me the right contents
21:44pinchartl: and I don't see any compression http header
21:44pinchartl: is anyone experiencing the same issue ?
21:48pinchartl: the same file loads fine in private mode
21:51pinchartl: seems to be an issue with corrupted cache
21:51pinchartl: no idea why
21:51awm129: pinchartl: I'm not seeing this with my firefox. Your URL seems to load ok with chrome, firefox, and private ff on my machine
21:52dwfreed: works in curl with --compressed and without too
21:52pinchartl: thanks for checking
21:52pinchartl: deleting the cache entry for https://gitlab.freedesktop.org/assets/webpack/pages.projects.pipelines.show.244a732b.chunk.js in firefox fixed the issue
22:36awm129: I'm having trouble pushing (and pulling) from an xserver fork on gitlab.freedesktop.org. I was able to push a week ago. Has something perhaps changed in the last couple days that I missed?
22:40awm129: specifically, my ssh connection attempts to gitlab.freedesktop.org are timing out
22:42pinchartl: awm129: replace it with ssh.gitlab.freedesktop.org
22:44awm129: ah, that is likely it. I will update my remotes, thanks for the heads up!
22:47awm129: that was indeed the issue, thanks again
22:54__tim: jenatali, did you see my message re. the MS windows runner being down since last week? is there someone better to poke? :)
22:55jenatali: __tim: I've been out for the last week, but I think I'm the only one of us that hangs on IRC
22:56jenatali: "down" in this case meaning accepting jobs but failing, or just not even accepting jobs?
22:56__tim: no longer in contact with gitlab.fdo
22:56jenatali: Hm. That's... interesting
22:57jenatali: Did the configs have to change from the migration? Could be fallout from that?
22:57__tim: not that I'm aware, I don't think we had to change anything on our runners
22:58jenatali: I know immediately post migration, one of the Mesa jobs slowed down 10x, but daniels just added a tag to that job to not use our runner until we were able to diagnose
22:58__tim: (but it's well possible alatiera did it and I just don't remember)
23:00jenatali: Forwarded this to other folks who can look at the runner. I'm not fully back til tomorrow
23:01__tim: Thanks
23:02__tim: not superurgent, but would be nice to have it back ofc :)
23:03jenatali: Yep, agreed
23:04jenatali: We need to figure out monitoring on our side. This is what happens when devs take this on instead of devops
23:11alatiera[m]: I don’t think I have access to the mesa runner or the admin interface at all, if it’s paused it certainly wasn’t me
23:21__tim: alatiera[m], not what I meant, I meant if any of the configuration needed updating after the gitlab migration or not
23:26jenatali: __tim: "so the VM was not responding. I just restarted it. I will make sure the runner service is started"
23:27__tim: jenatali, thanks a lot for chasing :)
23:27__tim: seems to be back in business
23:28alatiera[m]: ah, no, nothing needed an update