[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#639560: symbol changes

* Philipp Kern <pkern@debian.org>, 2011-08-28, 10:52:
The package FTBFS'es on mips, powerpc, s390, sparc and the inofficial ports s390x and powerpcspe because of changes in the symbol set wrt the symbols file:

Hmm, symbols file was added in 0.7-5, even though it isn't mentioned in the changelog.

- spifhash_jenkinsLE@Base 0.7
+#MISSING: 0.7-5# spifhash_jenkinsLE@Base 0.7

Looking at the source code spifhash_jenkinsLE is only defined on little-endian systems.

+ spiftool_regexp_match@Base 0.7-5
+ spiftool_regexp_match_r@Base 0.7-5

These two OTOH are defined everywhere and I don't understand why they weren't included in the symbols file. Even lintian loudly complains:

E: libast2: symbols-file-contains-current-version-with-debian-revision on symbol spiftool_regexp_match@Base and 1 others
N: N: Debian revisions should be stripped from versions in symbols files. Not
N:    doing so leads to dependencies unsatisfiable by backports (1.0-1~bpo <<
N:    1.0-1 while 1.0-1~bpo >= 1.0). If the debian revision can't be stripped
N:    because the symbol really appeared between two specific Debian
N:    revisions, you should postfix the version with a single "~" (example:
N:    1.0-3~ if the symbol appeared in 1.0-3).
N: N: This problem normally means that the symbols were added automatically by
N:    dpkg-gensymbols. dpkg-gensymbols uses the full version number for the
N:    dependency associated to any new symbol that it detects. The maintainer
N:    must update the debian/<package>.symbols file by adding the new symbols
N:    with the corresponding upstream version.
N: N: Severity: important, Certainty: certain N: N: Check: shared-libs, Type: binary, udeb N:
Jakub Wilk

Reply to: