[Request for Comments]
We recently got a zabbix alert about disk threshold usage on
https://debuginfod.centos.org service.
As a reminder (and for context), while all previous centos linux
releases had (for efficiency reasons) a split between .src.rpm (going to
https://vault.centos.org) and *debuginfo* rpm packages (consuming a lot
of bandwidth/disk space) going to http://debuginfo.centos.org , the plan
changed when Stream 8 (and so Stream 9 and 10 too) landed.
All packages were pushed out to mirror network, but not all variants
(multiple ones due to Stream nature) were kept online.
We were asked to provide a similar service to what Fedora was already
offering and so that's how https://debuginfod.centos.org/ came to life :
for people willing to debug pkgs, they can request "on the fly"
corresponding debuginfo files/packages (see website for simple instructions)
Now the question (and requests for comments) : We were still carrying on
that server all the Stream 8 debuginfo packages, while technically not
needed anymore (Stream 8 was removed from all mirrors when it went EOL
in May 2024) ...
But based on analysis done with Frank Eigler (maintaining the service
with us), we discovered that in fact a third of all requests for
debuginfod service are still about stream 8 (vs Stream 9 and 10)
The question is so : can we just delete (imho, yes !) these old .el8.
debuginfo packages (probably just analyzed in loop by AI scrapers these
days) and so :
- limit bandwidth needed for that machine
- reclaim some storage space (instead of increasing in loop the backend
disks)
Opinions, thoughts, comments ?
--
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]
When logging in to work on something this Sunday, I was presented this
banner on gitlab.com/CentOS :
```
Your Opensource subscription for CentOS will expire on 2025-10-13. If
you do not renew by 2025-10-13, you can't use merge approvals, code
quality, or any other paid features.
```
Can any member of the CentOS Board with contact at Gitlab ensure that
action is taken immediately and seriously to ensure not blocking any SIG
work happening now on Gitlab please ?
Happy to be involved to finally myself having a kind of PoC with Gitlab
(infra doesn't have any so far)
Kind Regards,
--
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]