From 359b1d42f91d6543110395925eb09859cb208af7 Mon Sep 17 00:00:00 2001 From: Ankur Sinha (Ankur Sinha Gmail) Date: Feb 07 2024 13:44:41 +0000 Subject: [PATCH 1/5] feat: migrate common rpmlint tricks --- diff --git a/modules/ROOT/pages/CommonRpmlintIssues.adoc b/modules/ROOT/pages/CommonRpmlintIssues.adoc new file mode 100644 index 0000000..d9844af --- /dev/null +++ b/modules/ROOT/pages/CommonRpmlintIssues.adoc @@ -0,0 +1,513 @@ += 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 "-e" 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. + +[[dangling_relative_symlink]] +== dangling-relative-symlink + +Package contains a symlink to another file, and finally in the generated +RPM the symlink points nowhere. e.g. README is symlink of README.rst in +upstream VCS repo, and the author forgot to include README.rst in the +released tarball, in this way you use `%doc README` in order to try +including a README file but actually it's just a symlink. If your +package contains both symlink and actual files, this can be safelly +ignored, otherwise please fix. + +[[debuginfo_without_sources]] +== debuginfo-without-sources + +`rpmlint -I debuginfo-without-sources` provides a good overall picture. +See also xref:packaging-guidelines::index.adoc[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. + +[[description_line_too_long]] +== 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]] +== 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 link:https://fedoraproject.org/wiki/Perl/Tips#file-not-utf8[Perl] +packaging tips page and +link:https://fedoraproject.org/wiki/Packaging_tricks#Convert_encoding_to_UTF-8[generic tricks] page. + +[[hardcoded_library_path]] +== 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}`. + +* Don't hardcode path in SPEC rather use xref:packaging-guidelines::RPMMacros.adoc[macros]. + +[[incoherent_init_script_name]] +== incoherent-init-script-name + +.... +incoherent-init-script-name +.... + +* The init script name should be the same as the package name in lower case. + +[[incorrect_fsf_address]] +== 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. The updated GPL +2.0 license (the usual case) with correct address is at +http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt[GPL-2.0.txt] + +[[incorrect_locale_el]] +== incorrect-locale-el + +.... +E: incorrect-locale-el /usr/share/locale/gr/LC_MESSAGES/foo.mo +.... + +* The Greek Translations has changed from el to gr. The package +maintainer should notify upstream or patch it. + +[[incoherent_logrotate_file]] +== incoherent-logrotate-file + +.... +incoherent-logrotate-file +.... + +* The log file or directory name should be the same as the +package name in lower case. + +[[incoherent_version_in_changelog]] +== 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. + +* Check Last entry under changelog section for version and +release tags in SPEC file. For example: + +.... +* Fri Jul 15 2022 - user@email.com - 2.20.0-1 +- Rebuild RPM with the latest binary version +.... + +[[invalid_license]] +== invalid-license + +.... +W: foo-package invalid-license GNU General Public License (GPL) +.... + +The value of the License tag was not recognized. + +* Check xref:packaging-guidelines::LicensingGuidelines.adoc[Licensing guidelines] + +[[invalid_soname]] +== 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: + +* link:#no_soname[no-soname] +* http://lists.fedoraproject.org/pipermail/devel/2012-April/166104.html[thread on fedora-devel] + +[[no_binary]] +== no-binary + +.... +E: foo-package 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_default_runlevel]] +== no-default-runlevel + +.... +no-default-runlevel +.... + +* 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]] +== 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]] +== 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 the relevant packaging guidelines at xref:packaging-guidelines::index.adoc#_downstream_so_name_versioning[Downstream soname versioning] for information on +dealing with this. + +See also: + +* link:#invalid_soname[invalid-soname] + +[[non_coherent_filename]] +== 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 `--..rpm`. + +* Your package name must be of form `--..rpm` + +[[non_conffile_in_etc]] +== 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. + +[[non_standard_group]] +== 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. + +* On F8, Check /usr/share/doc/rpm-4.4.2.2/GROUPS for valid +group names. + +[[pem_certificate]] +== pem-certificate + +.... +W: pem-certificate /usr/lib/python2.7/site-packages/libturpial/certs/cacert.pem +.... + +The certs files must be in `/etc/pki/` + +See: link:https://fedoraproject.org/wiki/PackagingDrafts/Certificates[PackagingDrafts/Certificates] + +[[private_shared_object_provides]] +== 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) +.... + +Many times this can be solved by following the procedure listed on +xref:packaging-guidelines::AutoProvidesAndRequiresFiltering.adoc[Packaging guidelines:AutoProvidesAndRequiresFiltering]. +There used to be limitations on filtering as described in +link:http://www.redhat.com/archives/fedora-packaging/2009-June/msg00031.html[this +post]. However, these limitations are not valid any more +(link:http://lists.fedoraproject.org/pipermail/devel/2012-June/169174.html[thread], +link:https://fedorahosted.org/fpc/ticket/189[FPC bug]). + +Older methods of filtering out private shared objects are deprecated and +should be replaced with the macros from the Guidelines as time permits. + +[[script_without_shebang]] +== 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. + +* You forgot to unset executable bits on files reported by this +error. Or you can +link:https://fedoraproject.org/wiki/Packaging_tricks#Add_shebang[add shebang]. + +[[shlib_with_non_pic_code]] +== 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)*. + +[[spurious_executable_perm]] +== spurious-executable-perm + +.... +E: foo-package spurious-executable-perm /usr/share/doc/package/README.md +.... + +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]] +== 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. + +* You should not make Systems standard directory's to belong to +your package. + +[[strange_permission]] +== 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. + +* Change permissions in Spec file, i.e. `chmod 644 %{SOURCE0}` + +[[summary_ended_with_dot]] +== 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. + +[[unstripped_binary_or_object]] +== unstripped-binary-or-object + +.... +W: unstripped-binary-or-object /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/do_mysql/do_mysql.so +.... + +* Make sure binaries are executable. + +[[unused_direct_shlib_dependency]] +== 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" +.... + +[[version_control_internal_file]] +== 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. + +* CVS directories and anything under them should just be +deleted. + +[[wrong_file_end_of_line_encoding]] +== 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 sed, using dos2unix is not +necessary. See man page *SED(1)* + +* `perl -i -pe 's/\r\n/\n/gs' ` +* `sed -i 's/\r$//' ` +* `sed -i 's/\r//' ` (this is inaccurate and may kill '`\r`'s that do +not precede a '`\n`'.) + +[[wrong_script_end_of_line_encoding]] +== 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. + +* Create files on Linux only. Don't create files on non-Unix +environment and add it in package. + +[[zero_length]] +== zero-length + +.... +E: foo-package zero-length /var/www/foo-package/foo.js +.... + +* These shouldn't be included unless they're required for +something. +link:https://fedoraproject.org/wiki/Packaging_Tricks#Zero_length_files[Trick here to +remove all zero length files]. + +[[more_information_on_rpmlint]] +== More Information on Rpmlint + +You can directly see files installed by package rpmlint under +`/usr/share/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 +link:https://github.com/rpm-software-management/rpmlint[Rpmlint GitHub +Project] From 22bd8ff628d326ec7dc00d006e42de11ee8cd411 Mon Sep 17 00:00:00 2001 From: Ankur Sinha (Ankur Sinha Gmail) Date: Feb 07 2024 13:44:41 +0000 Subject: [PATCH 2/5] feat: add rpmlint tricks to nav --- diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 93bedb6..faf0474 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -35,3 +35,5 @@ * xref:Upstream_Release_Monitoring.adoc[Upstream Release Monitoring] * xref:Utilities.adoc[Package Maintenance Utilities] + +* xref:CommonRpmlintIssues.adoc[Common Rpmlint issues] From 9585e402f1bb26350e2d1e97b22d7cc7b715689d Mon Sep 17 00:00:00 2001 From: Ankur Sinha (Ankur Sinha Gmail) Date: Feb 07 2024 13:44:41 +0000 Subject: [PATCH 3/5] chore(rpmlint-issues): correct spelling --- diff --git a/modules/ROOT/pages/CommonRpmlintIssues.adoc b/modules/ROOT/pages/CommonRpmlintIssues.adoc index d9844af..3cd1ba9 100644 --- a/modules/ROOT/pages/CommonRpmlintIssues.adoc +++ b/modules/ROOT/pages/CommonRpmlintIssues.adoc @@ -17,7 +17,7 @@ RPM the symlink points nowhere. e.g. README is symlink of README.rst in upstream VCS repo, and the author forgot to include README.rst in the released tarball, in this way you use `%doc README` in order to try including a README file but actually it's just a symlink. If your -package contains both symlink and actual files, this can be safelly +package contains both symlink and actual files, this can be safely ignored, otherwise please fix. [[debuginfo_without_sources]] From cf1d5519045918c466244b9a2568a6593c10911b Mon Sep 17 00:00:00 2001 From: Ankur Sinha (Ankur Sinha Gmail) Date: Feb 07 2024 13:44:41 +0000 Subject: [PATCH 4/5] feat(rpmlint-issues): remove ones that are simply duplications of rpmlint descriptions --- diff --git a/modules/ROOT/pages/CommonRpmlintIssues.adoc b/modules/ROOT/pages/CommonRpmlintIssues.adoc index 3cd1ba9..cda768a 100644 --- a/modules/ROOT/pages/CommonRpmlintIssues.adoc +++ b/modules/ROOT/pages/CommonRpmlintIssues.adoc @@ -1,42 +1,40 @@ = 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 "-e" 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. - -[[dangling_relative_symlink]] -== dangling-relative-symlink - -Package contains a symlink to another file, and finally in the generated -RPM the symlink points nowhere. e.g. README is symlink of README.rst in -upstream VCS repo, and the author forgot to include README.rst in the -released tarball, in this way you use `%doc README` in order to try -including a README file but actually it's just a symlink. If your -package contains both symlink and actual files, this can be safely -ignored, otherwise please fix. +the first thing you should do is use the `-e` option to rpmlint so that it +provides additional explanatory text. For example: + +[source,bash] +---- +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 +link:https://github.com/rpm-software-management/rpmlint[Rpmlint GitHub Project]. [[debuginfo_without_sources]] == debuginfo-without-sources -`rpmlint -I debuginfo-without-sources` provides a good overall picture. +`rpmlint -e debuginfo-without-sources` provides a good overall picture. See also xref:packaging-guidelines::index.adoc[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. -[[description_line_too_long]] -== 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]] == file-not-utf8 @@ -47,9 +45,10 @@ documentation file, is not in UTF8. installation. See man page *ICONV(1)*. For example, to recode a file named AUTHORS encoded in latin-1, you can use: -.... +[source,bash] +---- iconv -f iso8859-1 -t utf-8 AUTHORS > AUTHORS.conv && mv -f AUTHORS.conv AUTHORS -.... +---- or check the sample at the link:https://fedoraproject.org/wiki/Perl/Tips#file-not-utf8[Perl] packaging tips page and @@ -58,24 +57,8 @@ link:https://fedoraproject.org/wiki/Packaging_tricks#Convert_encoding_to_UTF-8[g [[hardcoded_library_path]] == 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}`. - * Don't hardcode path in SPEC rather use xref:packaging-guidelines::RPMMacros.adoc[macros]. -[[incoherent_init_script_name]] -== incoherent-init-script-name - -.... -incoherent-init-script-name -.... - -* The init script name should be the same as the package name in lower case. [[incorrect_fsf_address]] == incorrect-fsf-address @@ -84,55 +67,17 @@ incoherent-init-script-name 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. The updated GPL -2.0 license (the usual case) with correct address is at -http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt[GPL-2.0.txt] - -[[incorrect_locale_el]] -== incorrect-locale-el - -.... -E: incorrect-locale-el /usr/share/locale/gr/LC_MESSAGES/foo.mo -.... +reasons. Other files can be patched if deemed suitable. -* The Greek Translations has changed from el to gr. The package -maintainer should notify upstream or patch it. - -[[incoherent_logrotate_file]] -== incoherent-logrotate-file - -.... -incoherent-logrotate-file -.... - -* The log file or directory name should be the same as the -package name in lower case. [[incoherent_version_in_changelog]] == 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. - -* Check Last entry under changelog section for version and -release tags in SPEC file. For example: - -.... -* Fri Jul 15 2022 - user@email.com - 2.20.0-1 -- Rebuild RPM with the latest binary version -.... +* Check the changelog entries. See also: xref:packaging-guidelines::manual-changelog.adoc[manual changelog guidelines] in the Packaging Guidelines. [[invalid_license]] == invalid-license -.... -W: foo-package invalid-license GNU General Public License (GPL) -.... - The value of the License tag was not recognized. * Check xref:packaging-guidelines::LicensingGuidelines.adoc[Licensing guidelines] @@ -178,30 +123,15 @@ See also: [[no_binary]] == no-binary -.... +---- E: foo-package 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_default_runlevel]] -== no-default-runlevel - -.... -no-default-runlevel -.... - -* 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]] == no-documentation @@ -240,111 +170,26 @@ See also: * link:#invalid_soname[invalid-soname] -[[non_coherent_filename]] -== 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 `--..rpm`. - -* Your package name must be of form `--..rpm` - -[[non_conffile_in_etc]] -== 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. - -[[non_standard_group]] -== 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. - -* On F8, Check /usr/share/doc/rpm-4.4.2.2/GROUPS for valid -group names. - -[[pem_certificate]] -== pem-certificate - -.... -W: pem-certificate /usr/lib/python2.7/site-packages/libturpial/certs/cacert.pem -.... - -The certs files must be in `/etc/pki/` - -See: link:https://fedoraproject.org/wiki/PackagingDrafts/Certificates[PackagingDrafts/Certificates] - [[private_shared_object_provides]] == 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) -.... +---- -Many times this can be solved by following the procedure listed on +* Many times this can be solved by following the procedure listed on xref:packaging-guidelines::AutoProvidesAndRequiresFiltering.adoc[Packaging guidelines:AutoProvidesAndRequiresFiltering]. -There used to be limitations on filtering as described in -link:http://www.redhat.com/archives/fedora-packaging/2009-June/msg00031.html[this -post]. However, these limitations are not valid any more -(link:http://lists.fedoraproject.org/pipermail/devel/2012-June/169174.html[thread], -link:https://fedorahosted.org/fpc/ticket/189[FPC bug]). - -Older methods of filtering out private shared objects are deprecated and -should be replaced with the macros from the Guidelines as time permits. [[script_without_shebang]] == 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. - * You forgot to unset executable bits on files reported by this -error. Or you can +error. See also: link:https://fedoraproject.org/wiki/Packaging_tricks#Add_shebang[add shebang]. -[[shlib_with_non_pic_code]] -== 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)*. - [[spurious_executable_perm]] == spurious-executable-perm -.... -E: foo-package spurious-executable-perm /usr/share/doc/package/README.md -.... - Indicates that a file has the executable bit set while it probably should not. @@ -354,10 +199,6 @@ the `%install` section of your spec file. [[standard_dir_owned_by_package]] == 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. @@ -365,33 +206,9 @@ changed to something non-standard. * You should not make Systems standard directory's to belong to your package. -[[strange_permission]] -== 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. - -* Change permissions in Spec file, i.e. `chmod 644 %{SOURCE0}` - -[[summary_ended_with_dot]] -== 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. - [[unstripped_binary_or_object]] == unstripped-binary-or-object -.... -W: unstripped-binary-or-object /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/do_mysql/do_mysql.so -.... - * Make sure binaries are executable. [[unused_direct_shlib_dependency]] @@ -406,29 +223,18 @@ all of the possibilities. One fix for packages which use libtool is to put this in your %build section after the `%configure` call: -.... +[source,bash] +---- 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`: -.... +[source,bash] +---- export CXXFLAGS="%{optflags} -Wl,--as-needed" -.... - -[[version_control_internal_file]] -== 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. - -* CVS directories and anything under them should just be -deleted. +---- [[wrong_file_end_of_line_encoding]] == wrong-file-end-of-line-encoding @@ -444,70 +250,3 @@ necessary. See man page *SED(1)* * `perl -i -pe 's/\r\n/\n/gs' ` * `sed -i 's/\r$//' ` -* `sed -i 's/\r//' ` (this is inaccurate and may kill '`\r`'s that do -not precede a '`\n`'.) - -[[wrong_script_end_of_line_encoding]] -== 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. - -* Create files on Linux only. Don't create files on non-Unix -environment and add it in package. - -[[zero_length]] -== zero-length - -.... -E: foo-package zero-length /var/www/foo-package/foo.js -.... - -* These shouldn't be included unless they're required for -something. -link:https://fedoraproject.org/wiki/Packaging_Tricks#Zero_length_files[Trick here to -remove all zero length files]. - -[[more_information_on_rpmlint]] -== More Information on Rpmlint - -You can directly see files installed by package rpmlint under -`/usr/share/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 -link:https://github.com/rpm-software-management/rpmlint[Rpmlint GitHub -Project] From 586f18f89095ea3b823964707aa5983804c5c33c Mon Sep 17 00:00:00 2001 From: Ankur Sinha (Ankur Sinha Gmail) Date: Feb 07 2024 13:44:41 +0000 Subject: [PATCH 5/5] feat(rpmlint-issues): cosmetic: break sentences into individual lines etc. --- diff --git a/modules/ROOT/pages/CommonRpmlintIssues.adoc b/modules/ROOT/pages/CommonRpmlintIssues.adoc index cda768a..c954960 100644 --- a/modules/ROOT/pages/CommonRpmlintIssues.adoc +++ b/modules/ROOT/pages/CommonRpmlintIssues.adoc @@ -1,8 +1,8 @@ = 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: +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: [source,bash] ---- @@ -14,13 +14,10 @@ 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. - +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/`. @@ -31,19 +28,16 @@ link:https://github.com/rpm-software-management/rpmlint[Rpmlint GitHub Project]. == debuginfo-without-sources `rpmlint -e debuginfo-without-sources` provides a good overall picture. -See also xref:packaging-guidelines::index.adoc[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. +See also xref:packaging-guidelines::index.adoc[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]] == file-not-utf8 -Indicates that the text encoding of the specified file, usually a -documentation file, is not in 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: +* 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: [source,bash] ---- @@ -57,7 +51,8 @@ link:https://fedoraproject.org/wiki/Packaging_tricks#Convert_encoding_to_UTF-8[g [[hardcoded_library_path]] == hardcoded-library-path -* Don't hardcode path in SPEC rather use xref:packaging-guidelines::RPMMacros.adoc[macros]. +* Don't hardcode path in SPEC. + Use xref:packaging-guidelines::RPMMacros.adoc[macros] instead. [[incorrect_fsf_address]] @@ -66,8 +61,8 @@ link:https://fedoraproject.org/wiki/Packaging_tricks#Convert_encoding_to_UTF-8[g * 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. +The license file, usually COPYING, must *not* be patched for legal reasons. +Other files can be patched if deemed suitable. [[incoherent_version_in_changelog]] @@ -91,29 +86,26 @@ 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. +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. +* 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: @@ -123,12 +115,7 @@ See also: [[no_binary]] == no-binary ----- -E: foo-package no-binary ----- - -The package should be of the noarch architecture because it doesn't -contain any binaries. +The package should be of the noarch architecture because it doesn't contain any binaries. * Add `BuildArch: noarch` to the SPEC file @@ -139,32 +126,22 @@ contain any binaries. 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. +* 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]] == 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)*. +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 the relevant packaging guidelines at xref:packaging-guidelines::index.adoc#_downstream_so_name_versioning[Downstream soname versioning] for information on -dealing with this. +* See the relevant packaging guidelines at xref:packaging-guidelines::index.adoc#_downstream_so_name_versioning[Downstream soname versioning] for information on dealing with this. See also: @@ -183,15 +160,13 @@ xref:packaging-guidelines::AutoProvidesAndRequiresFiltering.adoc[Packaging guide [[script_without_shebang]] == script-without-shebang -* You forgot to unset executable bits on files reported by this -error. See also: -link:https://fedoraproject.org/wiki/Packaging_tricks#Add_shebang[add shebang]. +* You forgot to unset executable bits on files reported by this error. + See also: link:https://fedoraproject.org/wiki/Packaging_tricks#Add_shebang[add shebang]. [[spurious_executable_perm]] == spurious-executable-perm -Indicates that a file has the executable bit set while it probably -should not. +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. @@ -203,8 +178,7 @@ 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. +* You should not make Systems standard directory's to belong to your package. [[unstripped_binary_or_object]] == unstripped-binary-or-object @@ -214,13 +188,10 @@ your package. [[unused_direct_shlib_dependency]] == 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. +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 +One fix for packages which use libtool is to put this in your `%build` section after the `%configure` call: [source,bash] @@ -239,14 +210,19 @@ export CXXFLAGS="%{optflags} -Wl,--as-needed" [[wrong_file_end_of_line_encoding]] == 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 . +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 sed, using dos2unix is not +* 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$//' ` +[source, bash] +---- +perl -i -pe 's/\r\n/\n/gs' +---- + +[source, bash] +---- +sed -i 's/\r$//' +----