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: