Hi Francesco,
See the other thread to Jonathan for more details.
If I install RPM
https://repo.almalinux.org/almalinux/8.10/extras/x86_64/kickstart/Packages/… which
is the only version of the package in the 8.10 folder, the repo file it
installs contains a section [centos-advanced-virtualization] which has a
URL that does not exist.
There are a significant number of RPM files like this.
Ben S
On 4/3/26 2:53 PM, Francesco Di Nucci via Devel wrote:
> Hi,
>
> for the links that point to centos.org consider that packages related
> to EOL versions are moved to vault.centos.org (for example see
> https://vault.centos.org/8.5.2111/storage/x86_64/ for some of the
> repos that gave you issues like Gluster 6). If that's not enough
> consider asking on CentOS mailing lists.
>
> For AlmaLinux repositories have a look at vault.almalinux.org and
> nvidia.repo.almalinux.org
>
> Cheers
>
> Francesco
>
--
Time-Indexed Linux Infrastructure. Deterministic. Defensible.
Hi Jonathan,
My apologies if this report format was unclear. I've laid out the
report format below so it hopefully makes more sense.
In the first example, the RPM
"*centos-release-advanced-virtualization-1.0-4.el8.noarch.rpm*" contains
yum.repos.d files with repos that reference address that, in our
testing, did not resolve or download correctly.
Specifically, repo section [centos-advanced-virtualization] has a
mirrorlist URL:
http://mirrorlist.centos.org/?release=$avstream&arch=$basearch&repo=virt-$a…
...which we interpreted to a literal URL:
http://mirrorlist.centos.org/?release=$avstream&arch=x86_64&repo=virt-$avdir
... and this did not resolve. I do not know what $avdir was intended to
reference, but we have deferred identifying it because the domain
mirrorlist.centos.org does not have a DNS entry. The majority of these
unresolvable URLs are at mirrorlist.centos.org, but there are others
that aren't. (EG: [almalinux-nvidia-debuginfo])
Thanks,
Ben S
PS Format: (Sections repeat based on indenting, think: python)
File: (path to RPM containing the failed .repo file/section)
Failures: (Number of failed attempts to access URL, can be duplicative)
[Title of Repo Section containing the failed URL]
failures: (Number of failed attempts to access URL from subscan,
usually (always?) matches prev)
URL as specified in repo section
URL of previous line as interpreted based on original RPM context
Failures: (number of failed attempts within the attempt record,
should be one)
Status: (Internal error code designation) (http response
code, EG: 404)
/path/to/saved/file/if/saved
On 4/3/26 6:13 AM, Jonathan Wright via Devel wrote:
> Hi Benjamin,
>
> I don't understand what you're getting at exactly, or what represents
> a "failure".
>
> I checked the first RPM in your output, which maps to
> https://repo.almalinux.org/almalinux/8.10/extras/x86_64/kickstart/Packages/…,
> which works just fine and doesn't throw any errors. What's the issue
> here?
>
> On Thu, Apr 2, 2026 at 10:16 AM Retrogrid Tech via Devel
> <devel(a)lists.almalinux.org> wrote:
>
> Hello everyone,
>
> We have identified a significant number of non-functioning-repo
> RPMs and
> need to know which of these are intentionally non-functional so we
> can
> map them correctly in our archive rather than propagating broken repo
> definitions to enrolled systems.
>
> A simple "intentional" / "defect" next to each in the attached
> list/report would be fully adequate.
>
> The attached report summary should make it straightforward either to
> classify these as intentional or to address them as defects.
>
>
> Thanks,
>
> Benjamin Smith
>
> PS: Apologies if this is not the correct place to report this -
> Please
> direct me to the most appropriate channel if this is not it.
>
> For context, we're establishing a temporal mirror of the Enterprise
> Linux universe - something like a "Wayback Machine" for Linux OS. For
> completeness, this historical archive includes the results of
> metalink
> and mirrorlist queries but many of these do not
> resolve._______________________________________________
> Devel mailing list -- devel(a)lists.almalinux.org
> To unsubscribe send an email to devel-leave(a)lists.almalinux.org
>
>
>
> --
> Jonathan Wright
> AlmaLinux OS Foundation
> Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>
>
> _______________________________________________
> Devel mailing list --devel(a)lists.almalinux.org
> To unsubscribe send an email todevel-leave(a)lists.almalinux.org
--
Time-Indexed Linux Infrastructure. Deterministic. Defensible.
Hi Benjamin,
I don't understand what you're getting at exactly, or what represents a
"failure".
I checked the first RPM in your output, which maps to
https://repo.almalinux.org/almalinux/8.10/extras/x86_64/kickstart/Packages/…,
which works just fine and doesn't throw any errors. What's the issue here?
On Thu, Apr 2, 2026 at 10:16 AM Retrogrid Tech via Devel <
devel(a)lists.almalinux.org> wrote:
> Hello everyone,
>
> We have identified a significant number of non-functioning-repo RPMs and
> need to know which of these are intentionally non-functional so we can
> map them correctly in our archive rather than propagating broken repo
> definitions to enrolled systems.
>
> A simple "intentional" / "defect" next to each in the attached
> list/report would be fully adequate.
>
> The attached report summary should make it straightforward either to
> classify these as intentional or to address them as defects.
>
>
> Thanks,
>
> Benjamin Smith
>
> PS: Apologies if this is not the correct place to report this - Please
> direct me to the most appropriate channel if this is not it.
>
> For context, we're establishing a temporal mirror of the Enterprise
> Linux universe - something like a "Wayback Machine" for Linux OS. For
> completeness, this historical archive includes the results of metalink
> and mirrorlist queries but many of these do not
> resolve._______________________________________________
> Devel mailing list -- devel(a)lists.almalinux.org
> To unsubscribe send an email to devel-leave(a)lists.almalinux.org
>
--
Jonathan Wright
AlmaLinux OS Foundation
Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>
Hi,
for the links that point to centos.org consider that packages related to
EOL versions are moved to vault.centos.org (for example see
https://vault.centos.org/8.5.2111/storage/x86_64/ for some of the repos
that gave you issues like Gluster 6). If that's not enough consider
asking on CentOS mailing lists.
For AlmaLinux repositories have a look at vault.almalinux.org and
nvidia.repo.almalinux.org
Cheers
Francesco
--
Francesco Di Nucci
System Administrator
Compute & Networking Service, INFN Naples
Email: francesco.dinucci(a)na.infn.it
On 2026-04-02 17:16, Retrogrid Tech via Devel wrote:
> Hello everyone,
>
> We have identified a significant number of non-functioning-repo RPMs
> and need to know which of these are intentionally non-functional so we
> can map them correctly in our archive rather than propagating broken
> repo definitions to enrolled systems.
>
> A simple "intentional" / "defect" next to each in the attached
> list/report would be fully adequate.
>
> The attached report summary should make it straightforward either to
> classify these as intentional or to address them as defects.
>
>
> Thanks,
>
> Benjamin Smith
>
> PS: Apologies if this is not the correct place to report this - Please
> direct me to the most appropriate channel if this is not it.
>
> For context, we're establishing a temporal mirror of the Enterprise
> Linux universe - something like a "Wayback Machine" for Linux OS. For
> completeness, this historical archive includes the results of metalink
> and mirrorlist queries but many of these do not resolve.
>
> _______________________________________________
> Devel mailing list -- devel(a)lists.almalinux.org
> To unsubscribe send an email to devel-leave(a)lists.almalinux.org
