Created 7 days ago
Maintained by decathorpe
fedora repository health checks and reports
Members 1
Fabio Valentini committed a day ago

fedora health check

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.


To generate the reports yourself, you will need the following dependencies:

  • dnf-utils (for the repoclosure command)
  • fedora-repos (for generating the stable and updates-testing reports)
  • fedora-repos-rawhide (for generating the rawhide report)
  • python3 >= 3.5 (for subprocess::run and typing)
  • python3-argcomplete (optional, for tab completion on the script)
  • python3-CommonMark (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)

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

The 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. This can have one of the following reasons:

  • dnf repoclosure does not fully (or correctly) support boolean / rich dependencies (such as (foo and bar), (foo or bar), (foo with bar) or (foo if bar)).
  • The package in question is architecture-specific and isn't present in the x86_64 repositories (for example, the special OpenJDK builds for 32-bit ARM targets).

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 simple list can also be extended to cover regexes instead of only exactly matching strings, or to provide different values not only per architecture, but also per release.


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 the LICENSE file -- whichever is applicable where you are.