09:11 daniels: emersion: ?!
09:19 emersion: > Bug in Mailman version 2.1.29
09:19 emersion: > We're sorry, we hit a bug!
09:19 emersion: https://lists.freedesktop.org/mailman/admindb/dri-devel
11:52 daniels: emersion: looks like IPv6 was unhappy again, so lists were getting blocked on making outbound captcha-verification requests which were failing, and then it was timing out trying to take the lock
12:16 __tim: would mails that have to be pushed through via mailman admindb have been dropped ?
12:39 jrayhawk: daniels: what's going on with culpepper?
13:30 MrCooper: emersion daniels: FWIW, a post I sent to the amd-gfx & dri-devel lists over 2h ago hasn't come back from either list yet
13:34 alatiera: bentiss is it possible to gather the "what images are used" stats myself or can it only be done by an admin?
13:34 daniels: MrCooper: judging by https://lists.freedesktop.org/archives/amd-gfx/2025-February/date.html#start it hasn't even arrived
13:35 alatiera: also curious which pipelines are the ones that ref images from 2021, something is off there
13:35 alatiera: wonder if we have runaway schedule pipelines or some bot doing weird stuff
13:35 bentiss: alatiera: long story short, no, you need access to the db
13:36 bentiss: and for images referencing 2021 it's likely to be old pipeline ran a long time ago
13:36 alatiera: oh so the stats are not for pipelines run in the last month or so then
13:36 bentiss: alatiera: see https://gitlab.freedesktop.org/mesa/mesa/-/issues/12654#note_2794029 for an explanation of the numbers
13:36 bentiss: yep
13:38 MrCooper: daniels: didn't get any bounces either
13:40 MrCooper: hmm, guess it could be an issue with my outgoing SMTP server though
13:40 emersion: i can check postfix logs later
13:45 alatiera: looking at the gitlab registry cleanup rules they are not very helpful
13:45 alatiera: is there any project that makes use of them, cause I am curious how if so
13:46 bentiss: alatiera: it's a dead end. The cleanup rules might or might not work depending on when the container repository was created. I ǘe seen them working in new repos, but not on old ones
13:46 alatiera: while we can keep the last 5-10 tags per image, that doesn't account for stable branches where we might bump the tag in main more frequently and push the stable ones to pruned
13:46 __tim: mails seem to be coming through again now
13:47 __tim: alatiera, please don't assume that images on older stable branches can "just be rebuilt if needed", that is not the case from experience
13:47 __tim: even less so on windows
13:47 alatiera: bentiss yea what I am thinking about is the following: currently in gst we suff images with -$active-branch and thush we could have a gitlab job that removes the old when we push a new one
13:47 alatiera: however
13:48 __tim: (if people have MRs on top of old commits that's their problem of course and just need to rebase then)
13:48 alatiera: that requites that no othr project makes use of the iamge
13:48 alatiera: __tim yea kept images for branches
13:48 bentiss: alatiera: I'll be running a cron job that does cleanup which has the labels information. So we can think at a smart labelling that we can implement there and get automatic purging
13:48 alatiera: __tim actually there are a bunch of projects using our windows images, aren't they
13:49 alatiera: the annoying part is that gitlab has no global search
13:49 MrCooper: my outgoing SMTP server seems to work fine for another destination
13:50 alatiera: bentiss not sure we can encode that into labels
13:50 bentiss: alatiera: in https://gitlab.freedesktop.org/mesa/mesa/-/issues/12654 I emitted the idea of a new REST API that would provide "global" or at least per user API listing
13:51 bentiss: should be trivial enough to check the JWT token and then build up a json SQL query
13:52 __tim: alatiera, hrm, yeah, but well, they'll just have to update or learn how to roll their own I guess
13:52 MrCooper: daniels emersion: now it came back, thanks for whatever you did :)
13:53 alatiera: __tim I am more worried that I broke some of them right now
13:53 alatiera: very likely
13:53 alatiera:runs a github gloabl search
13:53 bentiss: alatiera: I don't think there are other users of the windows image on gitlab.fd.o
13:54 bentiss: for github, I would hope they copy the image on a different registry
13:54 alatiera: bentiss https://gitlab.freedesktop.org/cairo/cairo/-/blob/master/.gitlab-ci.yml#L24
13:54 alatiera: I don't care about github, but its what has a global search of the mirrors!
13:54 bentiss: heh, OK :)
13:55 alatiera: this specific image that cairo uses is still there thankfully
13:55 alatiera: but there are a couple other places iirc that coped it
13:55 bentiss: alatiera: # TODO: should probably get its own image at some point instead of reusing the GStreamer one
13:55 __tim: alatiera: https://paste.debian.net/1354450/
13:55 bentiss: yeah, well, now is the time to start :)
13:57 daniels: MrCooper: as if by magic!
13:57 daniels: (it looks like Mailman froze a bunch of incoming mail when it was struggling with lock contention)
13:58 alatiera: __tim reuploading those tags
13:58 alatiera: found also fontconfig is using it
13:58 bentiss: DragoonAethis: https://gitlab.freedesktop.org/drm/igt-gpu-tools/container_registry has a lot of tags... is this expected, and should this be cleaned up a bit?
13:58 alatiera: all of them have the same TODO 😆
14:01 bentiss: TBH, the thing that scares me the most is that on average we get an increase of 0.1TB of storage per day these past few days I started looking at the number
14:02 alatiera: jesus
14:10 alatiera: __tim images for libvpx, libffi and gperf are going to be missing
14:10 alatiera: rest are retagged
14:11 bentiss: gperf I can retag
14:12 bentiss: (t-rapp/gstreamer/amd64/windows:2023-03-20.0-main still has it)
14:13 bentiss: vpx I don't have the tag around in the registry
14:13 alatiera: its fine
14:14 alatiera: realistically these projects can also disable the job until they update
14:15 bentiss: libffi I don't have it either, but it haven't been updated in a while :/
14:21 alatiera: libffi is on a 1809 tag, I don't think we even have runners for that anymore
14:26 alatiera: ffi is green with the new image
16:02 Venemo: good afternoon
16:02 Venemo: I would like to report a crash in the CI script: https://pastebin.com/raw/FAFCC5VZ
16:16 Venemo: it seems that running the script repeatedly eventually makes it succeed
17:33 mahkoh: ssh.gitlab.freedesktop.org seems to be using a self-signed certificate
17:42 bentiss: mahkoh: ssh.gitlab.freedesktop.org should only be used for ssh, not http
18:04 mahkoh: I think the official gitlab plugin in JetBrains IDEs automatically tries to access the gitlab rest APIs by infering their URL from the git remote URLs.
18:06 mahkoh: Previously the gitlab web interface advertised the remote urls as git@gitlab.freedesktop.org. For some reason, this seems to have changed to git@ssh.gitlab.freedesktop.org recently.
18:06 mahkoh: If you go to any repository and then click on the blue Code button you can see it.
18:07 bentiss: mahkoh: yeah, the intent is to make use of a CDN in the near future, but CDN dislike SSH, so we need a separate NDS entry for ssh
18:07 bentiss: *DNS
18:08 bentiss: mahkoh: for now, you can rewrite your repo url to drop the 'ssh.' part and it'll work, until the CDN gets deployed
18:10 dwfreed: you could probably specify separate pull and push URLs, and it'd probably use the pull URL ?
18:14 mahkoh: That seems to work
23:38 emersion: okay, i've got the redirections working
23:38 emersion: https://lists.freedesktop.org/postorius/
23:38 emersion: wasn't really that hard
23:38 emersion: i think i just need to fixup GitLab SSO and then we should be good to go
23:39 emersion: probably sed some remaining kara.fdo in the config files as well
23:39 emersion: and then start migrating one non-critical mailing list and see how it goes
23:39 emersion: i've also set up https://lore.freedesktop.org/testbed/
23:40 emersion: with a mailman3 plugin to glue them together