Common Rpmlint issues

This is a collection of information on dealing with rpmlint. Note that the first thing you should do is use the -e option to rpmlint so that it provides additional explanatory text. For example:

rpmlint -e description-line-too-long

description-line-too-long:
Your description lines must not exceed 80 characters. If a line is exceeding
this number, cut it to fit in two lines.

The information provided here is not exhaustive. It covers some scenarios for which quick fixes are known. It is also not a "fix-all" for every scenario and should be carefully considered within the context of building your RPM. Some rpmlint warning should not be fixed for some packages, for example warnings about non-standard groups or users, or about setuid executables may be perfectly right for some packages. You can see descriptions of various rpmlint issues in the files installed by package rpmlint under /usr/lib/python3.12/site-packages/rpmlint/descriptions/.

For more information on rpmlint project look at Rpmlint GitHub Project.

debuginfo-without-sources

rpmlint -e debuginfo-without-sources provides a good overall picture. See also Compiler Flags. To fix, make sure that debugging symbols are created and that they not are stripped so they are available for rpmbuild post-processing.

file-not-utf8

Indicates that the text encoding of the specified file, usually a documentation file, is not in UTF8.

  • Usually fixed by running iconv on the uncompressed file before installation. See man page ICONV(1). For example, to recode a file named AUTHORS encoded in latin-1, you can use:

iconv -f iso8859-1 -t utf-8 AUTHORS > AUTHORS.conv && mv -f AUTHORS.conv AUTHORS

or check the sample at the Perl packaging tips page and generic tricks page.

hardcoded-library-path

  • Don’t hardcode path in SPEC. Use macros instead.

incorrect-fsf-address

  • In all cases, upstream should be informed about this. This is the only requirement with respect to this error.

The license file, usually COPYING, must not be patched for legal reasons. Other files can be patched if deemed suitable.

incoherent-version-in-changelog

invalid-license

The value of the License tag was not recognized.

invalid-soname

The handling of this error depends on ld.so’s load path (the "linker path") and whether it refers to a private or public library.

The linker path is %{_libdir} + any path listed in /etc/ld.so.conf or in a file in /etc/ld.so.conf.d.

Public libraries are libs expected to be used by other packages. Other libraries e.g., plugins and functionality internal to the package are private.

We have four cases:

  • The library is public. Inform upstream about the issue and propose that they add or fix versioning, possibly by sending a patch. Don’t apply the patch until it’s merged upstream to avoid upgrade problems.

  • The library is stored outside the linker path. In this case the error can be ignored.

  • The library is private and stored in a directory included in the linker path. If possible, move the library to another directory outside the linker path. This might require patching build scripts.

  • The library is private, stored in a directory included in the linker path and can’t be moved. Here, the library must have a name unlikely to clash with other libraries. Consider filtering the Provides: to make sure the private library isn’t visible.

The standard way to move a private library is to create a new directory under %{_libdir} e.g., /usr/lib/myapp. Don’t list it in /etc/ld.so.conf files! Instead, use a rpath to let the application locate the library.

See also:

no-binary

The package should be of the noarch architecture because it doesn’t contain any binaries.

  • Add BuildArch: noarch to the SPEC file

no-documentation

Indicates that rpmlint could find no files marked as %doc. There are several instances where this is acceptable:

  • The package really has no documentation. This is rare and in general quite a bad idea; every package should have some sort of documentation and should at least have the text of their license. However, some packages have internal help systems.

  • All of the documentation was included in a -doc subpackage. This would be rare as most packages should have some license text, a changelog or other information that is better placed in the main package instead of a -doc subpackage.

  • This is a subpackage and the relevant documentation was included in the main package. This often happens with the -devel subpackage, but you should at least double check to ensure that any of the package’s documentation which is intended for developers is included in the -devel subpackage.

no-soname

Indicates that the specified shared library does not have an soname (DT_SONAME ELF field). If an executable is linked with a shared object which has a DT_SONAME field, when the executable is run the dynamic linker will attempt to load the shared object specified by the DT_SONAME field rather than the using the file name given to the linker. See man page LD(1).

See also:

private-shared-object-provides

W: python-dulwich.x86_64: W: private-shared-object-provides /usr/lib64/python2.6/site-packages/dulwich/_objects.so _objects.so()(64bit)

script-without-shebang

  • You forgot to unset executable bits on files reported by this error. See also: add shebang.

spurious-executable-perm

Indicates that a file has the executable bit set while it probably should not.

  • Unset the executable bit, for example chmod -x README.md in the %install section of your spec file.

standard-dir-owned-by-package

This package owns a directory that is part of the standard hierarchy, which can lead to default directory permissions or ownerships being changed to something non-standard.

  • You should not make Systems standard directory’s to belong to your package.

unstripped-binary-or-object

  • Make sure binaries are executable.

unused-direct-shlib-dependency

A binary is linked against a library but doesn’t actually call any of the functions in it. This often happens when linking against a library which uses pkgconfig; the pkgconfig file cannot know which specific functions your binary may need to call, so it tells you to link against all of the possibilities.

One fix for packages which use libtool is to put this in your %build section after the %configure call:

sed -i -e 's! -shared ! -Wl,--as-needed\0!g' libtool

Another fix for packages which use %cmake is to put this before call %cmake:

export CXXFLAGS="%{optflags} -Wl,--as-needed"

wrong-file-end-of-line-encoding

The file has incorrect end-of-line encoding, usually caused by creation or modification on a non-Unix system. It could prevent the file from being displayed correctly in certain circumstances. UNIX and Linux use the Line-Feed character , whilst Windows and DOS use both a Carriage Return and Line Feed .

  • Strip the Carriage Returns by using perl or sed, using dos2unix is not necessary. See man page SED(1)

perl -i -pe 's/\r\n/\n/gs'
sed -i 's/\r$//'

Want to help? Learn how to contribute to Fedora Docs ›