Development/Packaging/Problems

From Mandriva Community Wiki

Jump to: navigation, search
Packaging problems

Contents


[edit] build errors

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

The libtoolize macro is part of the %configure macro (check with 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 --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.

[edit] Binaries have a strange i586-mandrake-linux- prefix!

add --program-prefix= (notice there is nothing after the equal sign) to the %configure call;

alternatively, add transform="" to the %makeinstall call.

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

[edit] Libraries don't have the "so" (libfoo.0.0.0 instead of libfoo.so.0.0.0)

This is related to libtool too.

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

[edit] 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

[edit] 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/libglib-2.0.so /usr/lib/libXext.so ... -Wl,--no-undefined -o .libs/libkeymouselistener.so
.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.

[edit] 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.

[edit] build warnings

[edit] overlinking

To reduce overlinking, rpm can display some warnings alike:

Warning: unused libraries in /usr/bin/xdm: /usr/lib/libXext.so.6 /usr/lib/libXt.so.6 /usr/lib/libSM.so.6 /usr/lib/libXpm.so.4 /usr/lib/libxcb-xlib.so.0 /usr/lib/libxcb.so.1

Check overlinking to understand how to fix.

[edit] underlinking

To reduce underlinking, rpm can display some warnings alike:

Warning: undefined symbols in /usr/lib/libgmodule-1.2.so.0.0.10: g_free g_thread_functions_for_glib_use g_threads_got_initialized ...

Check underlinking to understand how to fix.

[edit] check errors

[edit] Rpmlint errors

[edit] script-without-shebang

FIXME

[edit] no-signature

The package was not signed with a gpg key. You need to use 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.

[edit] binary-or-shlib-defines-rpath

'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: gcc test.o -o test -Wl,--rpath.

If the program uses ./configure, you can probably add --disable-rpath (verify with ./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 chrpath -d on the given file at the end of %build. If you do so, do not forget to add a BuildRequires2: chrpath to your spec.

[edit] configure-without-libdir-spec

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

[edit] explicit-lib-dependency

Don't include dependencies like "Requires: libdvdread3" in your spec file. Library dependencies are managed automatically, so if your program is linked against libdvdread.so.3, 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".

[edit] invalid-directory-reference

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

[edit] lib-package-without-%mklibname

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.

[edit] no-prereq-on

Example error: no-prereq-on rpm-helper

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

[edit] prereq-use

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

[edit] no-signature

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

[edit] Rpmlint Warnings

[edit] spurious-executable-perm

FIXME

[edit] dangling-relative-symlink

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

[edit] invalid-packager

The packager tag is incorrect. It needs to be the same as the option Packager. By default, rpmlint uses a regexp: '@mandrakesoft.com|@linux-mandrake.com|@mandrake.org|https?://qa.mandrakesoft.com|http://www.mandrakeexpert.com', found in TagsCheck.py ( 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.

[edit] incoherent-init-script-name

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

[edit] 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:

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

[edit] postin-without-ghost-file-creation

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

[edit] Upload errors

[edit] You have not built your package with the changes from the previous package

[edit] 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}
Retrieved from "http://wiki.mandriva.com/en/Development/Packaging/Problems"
Personal tools