RPM build deviation analysis tools. rpminspect looks at the output of an RPM build (e.g., the output of a Koji build) and examines the contents of the build artifacts to report:
-
Policy compliance
-
Changes from a previous build to the current build
-
General correctness and best practices
rpminspect is the frontend tool, and librpminspect provides the inspection engine and inspections. The program is configured through the a configuration file and runtime data is provided by a vendor-specific rpminspect-data package. The rpminspect-data-generic package in this source tree provides a template for constructing the vendor-specific data package.
For each merge and pull request, rpminspect is built and tested in the following environments:
| Platform | Release | Status |
|---|---|---|
| Fedora Linux | rawhide stable |
 |
| CentOS | Stream 9 |
 |
| Ubuntu Linux | stable |  |
| Debian GNU/Linux | testing stable |
 |
| OpenSUSE Linux | Leap |  |
| Arch Linux | stable |  |
| Gentoo Linux | stable |  |
| Alpine Linux | stable |  |
| AlmaLinux | 8 9 |
 |
| Mageia Linux | stable |  |
| Oracle Linux | 8 |  |
| FreeBSD | 13.x |  |
The latest documentation is available at https://rpminspect.readthedocs.io/
The documentation is regenerated each time there is a push or pull request merged in to the master branch.
rpminspect expects its input to either be local RPM packages or a Koji build. Koji produces certain types of builds that are not supported by rpminspect. Right now, the following input types are supported:
-
Local RPM packages (source or binary)
-
Koji builds (i.e., an SRPM run with 'rpmbuild -ba' on all specified architectures)
See https://pagure.io/koji for more information on Koji.
If comparing local RPM packages, rpminspect assumes the before and after specifications are peers whereas for a Koji build, rpminspect matches peer packages (e.g., in the gcc package, gcc-gfortran in the before build is peered with gcc-gfortran in the after build).
Developers, QE, release engineers, and system administrators who regularly build RPMs for use in some environments or products.
From an individual user standpoint, rpminspect is a command-line tool you can use as a linter of sorts. rpminspect reports, and that's it. rpminspect can output information in JSON format, which makes it easier to integrate with automated workflows or web frontends.
The reporting uses certain classifications for different things found, but it up to the end-user to determine what to do with that information. If used with an external build tool, the JSON data may be more useful as you can construct decision making around those results.
A typical Linux system with a toolchain for building C software using meson and ninja, plus the following libraries:
| Dependency | Required | Notes | License |
|---|---|---|---|
| json-c | ✔️ | MIT | |
| xmlrpc-c | ✔️ | BSD-3-Clause and MIT | |
| libxml-2.0 | ✔️ | MIT | |
| rpm | ✔️ | GPL-2.0-or-later | |
| libarchive | ✔️ | BSD-2-Clause and BSD-3-Clause | |
| elfutils | ✔️ | libelf | LGPL-3.0-or-later |
| kmod | Linux only | GPL-2.0-or-later | |
| zlib | ✔️ | Zlib and BSL-1.0 | |
| mandoc | ✔️ | libmandoc.a | ISC |
| libyaml | ✔️ | MIT | |
| file | ✔️ | BSD-2-Clause | |
| OpenSSL | ✔️ | OpenSSL | |
| libcap | Linux only | BSD-3-Clause | |
| ICU | ✔️ | ICU | |
| curl | ✔️ | MIT | |
| ClamAV | ✔️ | GPL-2.0-only | |
| gettext | .po to .mo | GPL-3.0-or-later | |
| libannocheck | GPL-3.0-or-later | ||
| cdson | ✔️ | MPL-2.0 | |
| libtoml | ✔️ | BSD-3-Clause |
Additionally, the unit test suite requires the following packages:
| Dependency | License |
|---|---|
| CUnit | LGPL-2.0-or-later |
| Python 3 | Python-2.0 |
| rpmfluff | GPL-2.0-only |
Most distributions include the above projects in prebuilt and packaged form. If those are available, you should use those packages.
In addition to the libraries that will be linked in to librpminspect, there are a number of userspace programs used:
/usr/bin/desktop-file-validate [optional]
/usr/bin/msgunfmt
/usr/bin/abidiff [optional]
/usr/bin/kmidiff [optional]
/usr/bin/udevadm [optional]
The provided spec file template uses the Fedora locations for these files, but in the program, they must be on the runtime system. Different inspections use these tools at runtime. Most distributions include the above tools. If they are available, you should use those packages.
In Fedora, for example, you can run the following to install these programs:
yum install desktop-file-utils gettext libabigail /usr/bin/annocheck
The 'shellsyntax' inspection uses the actual shell programs listed in the shells setting in the rpminspect configuration file. Since this can vary by system, you should make sure they are available in the system PATH. Or you can just not use the shellsyntax inspection. The spec file for rpminspect includes weak dependencies on the default list of shells:
yum install dash ksh zsh tcsh rc bash
An even easier option is to use the developer setup method described in the next section.
If you are planning on contributing to rpminspect, you should use the developer setup target in the Makefile to make sure you have the required packages installed:
make instreqs
This target will install all BuildRequires, Requires, and Suggests dependencies from the spec file template, but also the additional test suite requirements listed in the files in the osdeps/ subdirectory.
If you are working on a distribution other than Fedora/RHEL/CentOS, then have a look at the rpminspect.spec.in template for the packages listed as Requires, BuildRequires, and Suggests. These usually have similar names on other distributions. If you have instructions for setting up a development and runtime environment on another distribution, please send a pull request with the information.
If you got the source from a released tarball or from cloned from git, you can do this:
meson setup build
ninja -C build
You can get verbose build output with "ninja -C build -v".
For more information on meson and ninja, see these sites:
https://mesonbuild.com/
https://ninja-build.org/
Follow the steps for 'Building' above and then:
meson test -C build
You can get verbose build output with:
meson test -C build -v
The verbose mode is useful when tests fail because you can see the debugging information dumps and other output.
Follow the steps for 'Building' above. Install pip and virtualenv for Python.
To prepare a virtual environment for testing simple run:
virtualenv -p python3.8 my_test_env
. my_test_env/bin/activate
pip-3 install meson ninja rpm-py-installer rpmfluff setuptools
export RPMINSPECT=$PWD/build/src/rpminspect
export RPMINSPECT_YAML=$PWD/data/generic.yaml
export RPMINSPECT_TEST_DATA_PATH=$PWD/test/data
To run all tests, execute the command: python3 -Bm unittest discover -v test/
To run a specific test suite, execute: python3 -Bm unittest discover -v test/ test_emptyrpm.py
The 'make release' command creates a new release. The command handles the version number change, tests, git tag, and repo push. Release entries on GitHub are created manually. The signed archive is attached manually to the release entry.
The 'make koji' command submits official builds for Fedora and EPEL.
Make sure you have installed the program and corresponding data file collection. Fedora users can use yum:
yum install rpminspect rpminspect-data-fedora
The first package is the actual program. The rpminspect-data-fedora package delivers data files used by the various inspections performed by rpminspect. It also delivers the rpminspect configuration file. Have a look at this file and make sure it works for your environment. The idea is to support per-vendor data packages efficiently. For example, if CentOS needs different settings, it should provide a rpminspect-data-centos package.
Ideally, the configuration file should not need changing. If you do find mistakes, please file an issue or send a pull request to the project:
https://github.com/rpminspect/rpminspect-data-fedora
The aim should be the vendor-specific data packages providing everything a developer needs to run rpminspect locally for that product successfully.
rpminspect runs from the command line. The inputs must be local RPM packages, a Koji build specification (NVR), a Koji module specification, or a locally cached Koji build output (regular build or module). For inputs originating from Koji, rpminspect talks to Koji and download the build artifacts. For repeated runs, you may want to cache a remote build locally to avoid downloading it with each run.
Remember that you will need the corresponding vendor data package for rpminspect in addition to the rpminspect program. For Fedora, you will need to install 'rpminspect-data-fedora'. You can then invoke rpminspect using the 'rpminspect-fedora' script or 'rpminspect -c /usr/share/rpminspect/fedora.yaml'.
Here is a simple invocation using tmux as an example:
$ rpminspect-fedora -v tmux-2.9a-2.fc31 tmux-2.9a-3.fc31
This just runs with verbose mode enabled and compares tmux-2.9a-2.fc31 to tmux-2.9a-3.fc31. rpminspect downloads the packages for these builds and runs the inspections.
If you want to keep temporary files created during the run, pass -k. rpminspect tells you where those files are when it finishes.
You can list available inspections with the -l option:
$ rpminspect-fedora -l
Say you only want to run the license inspection on the builds above:
$ rpminspect-fedora -v -k -T license tmux-2.9a-2.fc31 tmux-2.9a-3.fc31
Now let's say you want to run the license and manpage inspections:
$ rpminspect-fedora -v -k -T license,manpage tmux-2.9a-2.fc31 tmux-2.9a-3.fc31
And lastly, what if you want to run all inspections except the license one:
$ rpminspect-fedora -v -k -E license tmux-2.9a-2.fc31 tmux-2.9a-3.fc31
What about specify a locally cached build? First, let's start by caching the builds we have been using:
$ mkdir ~/builds
$ rpminspect-fedora -v -w ~/builds -f tmux-2.9a-2.fc31
$ rpminspect-fedora -v -w ~/builds -f tmux-2.9a-3.fc31
Now let's run all the inspections but specify the locally cached builds:
$ rpminspect-fedora -v ~/builds/tmux-2.9a-2.fc31 ~/builds/tmux-2.9a-3.fc31
Easy. Again, these locally cached builds must look like what rpminspect would download from koji. Hence using rpminspect first to download it.
rpminspect can also run inspections on local RPM packages. Similar to Koji inputs, you may specify a single RPM or two RPMs to compare. For example:
$ rpminspect-fedora -v ~/rpmbuild/RPMS/x86_64/tmux-2.9a-2.fc31.x86_64.rpm
Or:
$ cd ~/rpmbuild/RPMS/x86_64
$ rpminspect-fedora -v tmux-2.9a-2.fc31.x86_64.rpm tmux-2.9a-3.fc31.x86_64.rpm
All of the other command-line options that apply to Koji tests work for local RPM packages.
For more information, see the man page for rpminspect(1). And see the --help output for information on command-line option syntax.
Patches are welcome, as are bug reports. There is a lot to do in this project. Some things to keep in mind:
-
Please follow the existing coding style in files you modify. Things like variable and function naming, spacing, and indentation. I want to avoid wildly varying coding styles throughout the tree.
-
New inspections in librpminspect need to be in the form of an inspect_NAME.c file with a driver added to the main struct. You may add static and non-static support functions to your inspect_NAME.c file and expose those as part of the librpminspect API. If the support functions are generic enough, feel free to start a new source file.
-
Test cases or updates to existing test cases need to accompany patches and new code submissions.
-
Use the standard C library whenever possible. Code using glib, libbsd or any other type of generic utility library is going to be reviewed and likely rejected until it is modified to use the standard C library.
-
That said, inspections should make use of available libraries for performing their work. When given the option between a library and forking and executing a program, please use the library.
-
Alternative libraries intended to replace a build requirement are ok so long as meson.build and meson_options.txt are modified to conditionalize the choices. For example:
-Djson_lib=other_json_libIf this requires modification in the code, try to minimize the use of cpp macros.
-
See the TODO file for a current list of things that need work.
The program (src/), the test suite (test/), and various developer tools in this source tree are available under the GNU General Public License version 3 or, at your option, any later version.
The librpminspect library (include/ and lib/) is available under the GNU Lesser General Public License version 3 or, at your option, any later version.
The data files (data/) are licensed under the Creative Commons Attribution 4.0 International Public License.
Some source files in the project carry Apache License 2.0 licenses or BSD licenses. Both of these cases are allowed under the GPLv3 and LGPLv3. The combined work is licensed as described in the previous paragraph.
Copyright statements are in the boilerplates of each source file.