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 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/c..., 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 <https://chat.almalinux.org/almalinux/messages/@jonathan>
_______________________________________________ Devel mailing list --devel@lists.almalinux.org To unsubscribe send an email todevel-leave@lists.almalinux.org
-- Time-Indexed Linux Infrastructure. Deterministic. Defensible.