Common Rpmlint issues

This is a collection of information on dealing with rpmlint. Note that if you are confused by an rpmlint warning, the first thing you should do is pass the "-i" option to rpmlint so that it provides additional explanatory text. The information provided here is 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.

description-line-too-long

Your description lines exceed 79 characters. This is not considered good style.

• Split your description across multiple lines, ensuring that each line does not exceed 79 characters.

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.

no-binary

E: foo-package no-binary

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

Solution:- Then you can add to SPEC file BuildArchitectures: noarch

no-default-runlevel

no-default-runlevel

Solution:- The default runlevel isn't specified in the init script. You need to add a line like the following one in the header of the init script:

2345 are the default runlevels. When installed, the package will be started on runlevel 2, 3, 4 and 5, and stopped for 1 and 6. 04 and 70 are starting order and stopping order. See InitscriptHowto for more information.

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

• Consider passing (or patching) link flags to the build process such as '-Wl,-soname,<SONAME>' where <SONAME> is the appropriate soname to use. Be careful not to add an soname to conventional binaries. To see examples of how sonames are used, you can view the DT_SONAME field of libraries, using the following:

shlib-with-non-pic-code

Indicates that a shared library contains non Position Independent Code. Non PIC code in shared libraries can cause problems with software such as SELinux, which will refuse to load them. This is often caused by the libraries being compiled without the -fPIC option or being statically linked with non-PIC code.

• Ensure the libraries are being compiled with the -fPIC option. See man page GCC(1).
• Libraries being compiled against allegro, might be linked with liballeg_unsharable.a. This may be caused by the build process calling allegro-config --libs which contains '-lalleg_unsharable' in the output. This can be fixed by patching the build process to strip '-lalleg_unsharable' from the output using sed. See man page SED(1).

standard-dir-owned-by-package

E: foo-package standard-dir-owned-by-package /usr/share

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.

Solution:- You should not make Systems standard directory's to belong to your package.

summary-ended-with-dot

The summary field in the spec file, ends in a period '.' character. This is not considered good style.

• Simply remove the trailing period from the summary field.

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

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 <LF>, whilst Windows and DOS use both a Carriage Return and Line Feed <CRLF>.

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

sed -i 's/\r//' <file_to_strip>

non-conffile-in-etc

W: foo-package non-conffile-in-etc /etc/xdg/menus/applications-merged/foo-package.menu

A non-executable file in your package is being installed in /etc, but is not a configuration file. All non-executable files in /etc should be configuration files. Mark the file as %config in the spec file.

incoherent-version-in-changelog

W: foo-package incoherent-version-in-changelog 0.6.1-1 0.6.1-1..fc6

Your last entry in %changelog contains a version that is not coherent with the current version of your package.

Solution:- Check Last entry under changelog section for version and release tags in SPEC file.

script-without-shebang

E: foo-package script-without-shellbang /var/www/foo-package/plugins/foo.php

This executable text file does not contain a shebang, thus it cannot be properly executed. Often this is a sign of spurious executable bits for a non-script file, but can also be a case of a missing shebang. To fix this error, find out which case of the above it is, and either remove the executable bits or add the shebang.

Solution:- You forgot to unset executable bits on files reported by this error. Or you can add shebang.

wrong-script-end-of-line-encoding

E: foo-package wrong-script-end-of-line-encoding /var/www/foo-package/plugins/foo.php

This script has wrong end-of-line encoding, usually caused by creation or modification on a non-Unix system. It will prevent its execution.

Solution:- Create files on Linux only. Don't create files on non-Unix environment and add it in package.

version-control-internal-file

E: foo-package version-control-internal-file /var/www/foo-package/CVS/Entries

You have included file(s) internally used by a version control system in the package. Move these files out of the package and rebuild it.

Solution:- CVS directories and anything under them should just be deleted.

zero-length

E: foo-package zero-length /var/www/foo-package/foo.js

Solution:- These shouldn't be included unless they're required for something. Trick here to remove all zero length files.

non-standard-group

W: foo-package non-standard-group Networking/Other

The group specified in your spec file is not valid. To find a valid group, please refer to the distribution + RPM documentation.

Solution:- On F8, Check /usr/share/doc/rpm-4.4.2.2/GROUPS for valid group names.

invalid-license

W: foo-package invalid-license GNU General Public License (GPL)

The value of the License tag was not recognized. Solution:- Check http://fedoraproject.org/wiki/Packaging/LicensingGuidelines and http://fedoraproject.org/wiki/Licensing

non-coherent-filename

W: foo-package non-coherent-filename foo-package-0.99-0.Fedora.src.rpm

The file which contains the package should be named <NAME>-<VERSION>-<RELEASE>.<ARCH>.rpm.

Solution:- Your package name must be of form <NAME>-<VERSION>-<RELEASE>.<ARCH>.rpm

strange-permission

W: foo-package strange-permission foo-package.spec 0744

A file that you listed to include in your package has strange permissions. Usually, a file should have 0644 permissions.

Solution:- Change permissions on SPEC file.

hardcoded-library-path

E: foo-package hardcoded-library-path in %{buildroot}/usr/lib/menu/

A library path is hardcoded to one of the following paths: /lib, /usr/lib. It should be replaced by something like /%{_lib} or %{_libdir}.

Solution:- Don't hardcode path in SPEC rather use macros .

incoherent-init-script-name

incoherent-init-script-name

Solution:- The init script name should be the same as the package name in lower case.

incorrect-locale-el

E: incorrect-locale-el /usr/share/locale/gr/LC_MESSAGES/foo.mo

Solution:- The Greek Translations has changed from el to gr. The package maintainer should notify upstream or patch it.

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)

Solution:- To avoid this new warning about the provide of . During the RP build process the

If there is a provide during the RPM build process like "Provides: _objects.so()(64bit) _pack.so()(64bit)". The warning can be fixed with the following snippet.

%global _use_internal_dependency_generator 0
%global __find_provides %{_rpmconfigdir}/find-provides | grep -v -e '_objects.so|_pack.so'
%global __find_requires %{_rpmconfigdir}/find-requires | grep -v -e '_objects.so|_pack.so'

or an other solution

%global _use_internal_dependency_generator 0
%global __find_provides    %{_rpmconfigdir}/find-provides | grep -v %{srcname}
%global __find_requires    %{_rpmconfigdir}/find-requires | grep -v %{srcname}

More details can be found on the following thread http://lists.fedoraproject.org/pipermail/python-devel/2010-June/000260.html. Be aware this solution is only a temporary approach and may be replaced in the future.

More Information on Rpmlint

You can directly see files installed by package rpmlint under [[file:///usr/share/rpmlint rpmlint] . There you will find various python files for different types of package checking e.g.

File Name		Purpose
AbstractCheck.py	Abstract class to hold all the derived classes.
BinariesCheck.py	check binary files in a binary rpm package.
Config.py		handle configuration options. To be used from config files.
DistributionCheck.py	check the Distribution specificities in a binary rpm package.
DocFilesCheck.py        doc file depnedency check.
FHSCheck.py		check FHS conformity.
FilesCheck.py 		test various aspects on files: locations, owner, groups.
Filter.py 		filter the output of rpmlint to allow exceptions.
I18NCheck.py 		checks i18n bugs.
InitScriptCheck.py      check init scripts (files in /etc/rc.d/init.d)
LSBCheck.py             LSB non compliance checks
MenuCheck.py            Menu related checking.
MenuXDGCheck.py         check xdg file format violation.
NamingPolicyCheck.py    Check package names according to their content.
PamCheck.py             Apply pam policy.
Pkg.py 			provide an API to handle a rpm package either by accessing.
PostCheck.py            Check post/pre scripts.
rpmlint.py 		main entry point: process options, load the checks and run.
SignatureCheck.py 	check the presence of a PGP signature.
SourceCheck.py 		verify source package correctness.
SpecCheck.py 		check the spec file of a source rpm.
TagsCheck.py 		Check a package to see if some rpm tags are present.
ZipCheck.py 		Verify Zip/Jar file correctness.

Links

For more information on rpmlint project look at Rpmlint RT