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-$avdir

...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 

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/centos-release-advanced-virtualization-1.0-4.el8.noarch.rpm, 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@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@lists.almalinux.org
To unsubscribe send an email to devel-leave@lists.almalinux.org

--

Jonathan Wright
AlmaLinux OS Foundation

Mattermost: chat

_______________________________________________
Devel mailing list -- devel@lists.almalinux.org
To unsubscribe send an email to devel-leave@lists.almalinux.org

-- 
Time-Indexed Linux Infrastructure. Deterministic. Defensible.