[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 ?
On Wed, Sep 24, 2025 at 8:48 AM Fabian Arrotin arrfab@centos.org wrote:
[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 ?
Well, it's not like we're going to be able to do anything with any debug reports for EL8 today, so I'm fine with dropping them.
(NB: people may want to run debuggers / profilers on software for reasons other than reporting bugs to a distro that's no longer interested. They may want to learn how something works or improve it for themselves.)
On Wed, Sep 24, 2025 at 12:19 PM fche--- via devel devel@lists.centos.org wrote:
(NB: people may want to run debuggers / profilers on software for reasons other than reporting bugs to a distro that's no longer interested. They may want to learn how something works or improve it for themselves.)
That's what the debuginfo packages are for. It's not like they have no options.
Hi -
(NB: people may want to run debuggers / profilers on software for
reasons other than reporting bugs to a distro that's no longer interested. They may want to learn how something works or improve it for themselves.)
That's what the debuginfo packages are for. It's not like they have no options.
Sure, and those packages are what debuginfod.centos.org serves (as needed). It just makes it automatic instead of hunting around the vault or whereever the rhel8 debuginfo/source may still be available to the public from other servers.
- FChE
Seems like something that can and should be killed off at this point.
On Wed, Sep 24, 2025 at 7:48 AM Fabian Arrotin arrfab@centos.org wrote:
[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]
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
Retiring and reclaiming the space makes the most sense.
Amy
*Amy Marrich*
She/Her/Hers
Principal Technical Marketing Manager - Cloud Platforms
Red Hat, Inc https://www.redhat.com/
amy@redhat.com
Mobile: 954-818-0514
Slack: amarrich
IRC: spotz
On Wed, Sep 24, 2025 at 7:51 AM Fabian Arrotin arrfab@centos.org wrote:
[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]
devel mailing list -- devel@lists.centos.org To unsubscribe send an email to devel-leave@lists.centos.org
-
Amy Marrich -
Fabian Arrotin -
fche＠redhat.com -
Frank Ch. Eigler
-
Jonathan Wright -
Neal Gompa -
zhihuilyu