The scripts and data provided by this repository have been superseded by a new, written-from-scratch implementation and server deployment that actually serves JSON responses via HTTP instead of writing and committing files to a git repo on pagure:
The default configuration and current overrides have been migrated from
fedora-health-check, except the
fxx+testing configuration, which I dropped,
because it's not really useful.
This repository contains a simple script to generate a repository health check for multiple fedora repositories, maps packages with broken dependencies to their primary maintainers, and generates reports in both human- and machine-readable formats (JSON, Markdown, and pre-rendered HTML).
If data from a previous run is present, it can also generate a "rich diff" in JSON format. This data could be used to notify package maintainers about new broken dependencies, but this is not yet implemented.
A list of currently reportes issues can be viewed here.
To generate the reports yourself, you will need the following dependencies:
fedora-repos(for generating the stable and updates-testing reports)
fedora-repos-rawhide(for generating the rawhide report)
python3 >= 3.5(for
python3-argcomplete(optional, for tab completion on the script)
python3-CommonMark(optional, for pre-rendering static HTML reports)
python3-jinja2(for rendering the Markdown reports)
python3-requests(for querying the pagure API on https://src.fedoraproject.org)
repoclosure.py python script can be used to generate and write out data
and reports for all fedora releases specified on the command line, or just
print (or write out) statistics for one specified release.
generate wrapper script is present for convenience, since it hard-codes
the currently used command line arguments for
repoclosure.py (for example,
it doesn't override the date, and passes all currently active fedora releases).
It is possible that the data (and reports) contains false-positives for "broken"
dependencies that are really satisfiable from the fedora repositories. In such
cases, these "false positives" can be added to the "overrides" list in the
overrides.json file if somebody can manually verify that the package
dependencies are actually satisfied.
If necessary, this override matching can be extended to use regular expressions for package names, but for now, it only supports a list of exact matches, nothing (the default), or anything.
There's also a bug in koji that results in
noarch packages with "unported dependencies" getting copied into repositories
for architectures that are explicitly disabled in the package's
ExclusiveArch. This results in un-installable packages
being present in architectures that have been explicitly disabled. :frowning:
Consider both the code and data in this repository to be released into the
Public Domain, or published under the terms of the Unlicense contained in
LICENSE file -- whichever is applicable where you are.