Problems and issues with packaging

From Wiki [en] OpenMandriva
Revision as of 22:50, 19 February 2014 by TPG (Talk | contribs) (import)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Packaging problems

build errors

unrecognized option --tag=CXX' Try libtool --help' for more information

The libtoolize macro is part of the %configure macro (check with [me@mandrivapc]$ rpm --eval %configure ), and because there is a version mismatch, things will break. Mandriva Linux uses libtool-1.4, while KDE uses libtool-1.5 (or 1.4a?). Version 1.4 doesn't understand [me@mandrivapc]$ --tag=CXX', so it breaks.

On top of your specfile, you can define this:

%define __libtoolize    /bin/true

When you add this define, libtoolize won't be run, and all should go well.

Binaries have a strange i586-mandrake-linux- prefix!

add [me@mandrivapc]$ --program-prefix= (notice there is nothing after the equal sign) to the %configure call;

alternatively, add [me@mandrivapc]$ transform="" to the %makeinstall call.

You can also try to use autoconf2.5, with %configure2.5x

Libraries don't have the "so" (libfoo.0.0.0 instead of

This is related to libtool too.

%define __libtoolize    /bin/true
will solve this issue.

No X display available

Some packages require the availability of an X display during the package build. If no interaction is needed, this can be solved with Xvfb: just add
BuildRequires: x11-server-xvfb
and run the command with xvfb-run, e.g.
xvfb-run make check

undefined reference to `xxx'

Since May 2008, packages are built with ld flag --no-undefined to prevent underlinking shared libraries.

gcc -shared foo.o -ldl /usr/lib/ /usr/lib/ ... -Wl,--no-undefined -o .libs/
.libs/keymouselistener.o: In function `parse_line':
.../gdm-2.20.6/gui/modules/keymouselistener.c:410: undefined reference to `XKeysymToKeycode'
collect2: ld returned 1 exit status

Check underlinking to understand how to fix.

Missing %files for subpackage xxx

Since June 2008, subpackage xxx with no %files xxx raises a fatal error. It helps to detect dead subpackages, or typos in .spec file.

It also occurs in valid spec files, when "%files xxx" appears inside a %if %ccc ... %endif. The fix is to put the whole %package xxx section inside a %if %ccc ... %endif.

format not a string literal and no format arguments

Since December 2008, things like printf(error_message) instead of printf("%s", error_message) are detected by [me@mandrivapc]$ -Werror=format-security which is used by default. The reason for this error is described on the following Wikipedia page: format string attack

Example of error:

fud.c:72: error: format not a string literal and no format arguments

simple fixes

The fix can be something like:

-      printf(xkblayouttext);
+      printf("%s", xkblayouttext);
-      syslog(LOG_ERR, error_message(r));
+      syslog(LOG_ERR, "%s", error_message(r));
-   snprintf(id_resp_command, MAXIDVALUELEN, *argv);
+   snprintf(id_resp_command, MAXIDVALUELEN, "%s", *argv);

(another example: nautilus fix)

C++ code

Beware of C++ objects:

  QCString msgText = substitute(outputFormat, "$file", fileSubst) + '\n';
  fprintf(warnFile, msgText);

simply doing fprintf(warnFile, "%s", msgText) would introduce a crash, as warned by gcc:

message.cpp:150: warning: cannot pass objects of non-POD type 'class QCString' through '...'; call will abort at runtime
message.cpp:150: warning: format '%s' expects type 'char*', but argument 3 has type 'int'

You must explicitly cast to (const char *):

fprintf(warnFile, "%s", (const char *) msgText);

or simpler:

fputs(msgText, warnFile);

code doing % escaping by hand

Beware of weird code like (from doxygen):

  QCString msgText = substitute(substitute(outputFormat, "$file", fileSubst),
                                "%", "%%") + '\n';
  fprintf(warnFile, msgText);

Doing fputs(msgText, warnFile) modifies the program's behaviour since % will be displayed %% since % is escaped in msgText. The correct fix is to also get rid of the %s escaping:

  QCString msgText = substitute(outputFormat, "$file", fileSubst) + '\n';
  fputs(msgText, warnFile);

but you can also disable the warning (see below) and keep the code unchanged, since the code is valid (even if ugly).

disabling this warning

If the code is valid, you can disable the check using %define Werror_cflags %nil

The use of [me@mandrivapc]$ -Werror=format-security is inpired by Debian Hardening and Ubuntu CompilerFlags which use [me@mandrivapc]$ -Wformat-security to detect such issues. But warnings are not enough (especially since Mandriva does not keep build logs), so Mandriva chose to enforce it by making such warnings fatal.

error: possibly undefined macro: AM_ACLOCAL_INCLUDE

Fix is to replace AM_ACLOCAL_INCLUDE call in or with ACLOCAL_AMFLAGS variable in For example, if has AM_ACLOCAL_INCLUDE(macros), remove it and add this to


conflicting types for `getline'

A file includes /usr/include/stdio.h but at the same time defines a local getline function. Fix is to rename the local getline, e.g. 'parseline'. You may do this automatically with this command:

perl -pi -e 's|getline|parseline|' path/to/src/*.c

build warnings


To reduce overlinking, rpm can display some warnings alike:

Warning: unused libraries in /usr/bin/xdm: /usr/lib/ /usr/lib/ /usr/lib/ /usr/lib/ /usr/lib/ /usr/lib/

Check overlinking to understand how to fix.


To reduce underlinking, rpm can display some warnings alike:

Warning: undefined symbols in /usr/lib/ g_free g_thread_functions_for_glib_use g_threads_got_initialized ...

Check underlinking to understand how to fix.

rpm loop warnings

LOOP warnings from tsort relations

warning: LOOP:
warning: removing libdrakx-net-0.94-1.1.noarch "Requires: /usr/share/locale/fr/LC_MESSAGES" from tsort relations.
warning: removing harddrake-13.52-1.i586 "Requires: drakxtools-curses = 13.52-1" from tsort relations.
warning: removing drakxtools-curses-13.52-1.i586 "Requires(hint): drakx-net-text" from tsort relations.
warning: removing drakx-net-text-0.94-1.1.noarch "Requires: libdrakx-net = 0.94" from tsort relations.
  • What is a Tsort relation?

The set of ordered dependencies, before rpm installation, so if rpm installation order is not correct, this may result in broken installations, it is important to prevent these erros in order to have a more robust installation system.

  • How to solve the error?

Remove unnecessary circular dependencies when encountered.

Often the loops may be harmless, but sometimes they might cause packages to be installed in the wrong order, ie. like one package requiring a specific user for ownership of directories which are created by another package, or maybe running a script requiring a file from another package that due to dependency loop gets installed only after the script is attempted to run..

  • In practical, how to solve this?

Edit the spec file of the application to remove unnecessary circular dependencies.

If not possible, add the dependency detection to this bug report in bugzilla or create a new bug linking to it.

check errors

Rpmlint errors


This executable text file does not contain a shebang (#!/bin/sh), 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 by looking at the top of the file, and either remove the executable bits or add the shebang.

Add sh shebang: [me@mandrivapc]$ sed -i -e '1d;2i#!/bin/sh'

Add Perl shebang: [me@mandrivapc]$ sed -i -e '1d;2i#!/usr/bin/perl'

Add Python shebang: [me@mandrivapc]$ sed -i -e '1d;2i#!/usr/bin/python'


The package was not signed with a gpg key. You need to use [me@mandrivapc]$ rpm --sign package.rpm after having built it. This is not a problem if you plan to send the rpm to contribs or another packaging project, as they usually resign the package with the project key. You can ignore it in rpmlint config.


'The binary or shared library defines the PATH'. Usually this is a bad thing because it hard codes the path to search libraries and so it makes it difficult to move libraries around. Most likely you will find a Makefile with a line like: [me@mandrivapc]$ gcc test.o -o test -Wl,--rpath.

If the program uses [me@mandrivapc]$ ./configure, you can probably add [me@mandrivapc]$ --disable-rpath (verify with [me@mandrivapc]$ ./configure --help to see if the option is available).

You can look at the Debian wiki for more information.

If you can not change that easily, you can use [me@mandrivapc]$ chrpath -d on the given file at the end of %build. If you do so, do not forget to add a [me@mandrivapc]$ BuildRequires2: chrpath to your spec.


This usually happens when you don't use the %configure or %configure2_5x macro to call the [me@mandrivapc]$ configure script. They run [me@mandrivapc]$ configure with predefined default options, so the files get installed in the right location. You can ignore the error if the sources contain a [me@mandrivapc]$ configure script that wasn't generated by autoconf.


Don't include dependencies like "Requires: libdvdread3" in your spec file. Library dependencies are managed automatically, so if your program is linked against, the libdvdread3 package will be an automatic dependency. Also, this isn't portable to architectures like amd64, where the package is named lib64dvdread3. If you really need a library dependency, e.g. to force the upgrade to a new version, use the virtual name provided by that package, in this example "Requires: libdvdread".


Don't include files in /tmp or /home in your package.


If you split out library packages, you should use the %mklibname macro to generate the name of the library package. Further information on the usage of %mklibname are in the library policy section.


Example error: no-prereq-on rpm-helper

Solution: Add "Requires(pre): rpm-helper", "Requires(preun): rpm-helper" as needed to the package.


Example error: prereq-use rpm-helper

Solution: prereq-use is no longer used, you should use Requires(stage) instead with stage in {pre,post,preun,postun}. For example: Requires(post): rpm-helper


Packages get signed during upload process, so just ignore this or add [me@mandrivapc]$ addFilter("E: .* no-signature") into your ~/.rpmlintrc.

Rpmlint Warnings



From an unexperienced packager :

It can happen for example for doc files (README, COPYING, etc...) that have executable permissions in the source tarball. To solve this you have to fix the permissions, for example in the %build section.


The relative symbolic link points nowhere. If you are sure the pointed file will be there (e.g. you require the package containing it) you can safely ignore this. Else, just fix it :-)


The packager tag is incorrect. It needs to be the same as the option Packager. By default, rpmlint uses a regexp: '|||https?://|', found in ( search DEFAULT_PACKAGER ). This is not a problem if you send your package to contribs, as the packager tags should be replaced when the package is rebuilt, unless you added it in the spec files.


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


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:

# chkconfig: 2345 04 70

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 Initscript Howto for more information.


You tagged a file with %ghost but did not create it in %postin nor in %prein

Upload errors

You have not built your package with the changes from the previous package

debug packages

Debug packages are built per default in Cooker, but sometimes this won't apply so you need a way to switch it off, you have to add these two lines in the spec file to disable debug packages:

%define _enable_debug_packages %{nil}
%define debug_package          %{nil}