Bug#766833: RFS: fuzzylite/5.0+dfsg-1
* Johannes Schauer <j.schauer@email.de>, 2014-10-27, 13:59:
spellintian[0] says:
NEWS: overriden -> overridden
NEWS: allows to -> allows one to
README.md: overriden -> overridden
README.md: allows to -> allows one to
I take it spellintian is not packaged?
Nope. Maybe you^Wwe could talk Lintian maintainers to include it in
Lintian proper.
I think that the "allows to -> allows one to" are false positives.
FSVO false. :-P The original grammar is wonky, although the proposed
correction is not right either.
Could somebody with stronger English skills than me please correct the
following:
original: blabla..., which allows to be overridden.
Paraphrasing with slightly more context, it's:
... method foo was made virtual, which allows to be overridden
The following is probably wrong:
spellintian: blabla..., which allows one to be overridden.
Yeah, adding "one" doesn't work here. Maybe:
... method `static bar` was made `virtual foo::bar`, which allows it to be overridden
or
... method `static bar` was made `virtual foo::bar`, which allows overriding it
Perhaps s/it/the method/.
Would the following be correct:
proposal: blabla..., which is allowed to be overridden.
That doesn't sound right to me. But maybe it's just me; I only speak
en_PL.
The package FTBFS on i386:
| dh_makeshlibs -O--sourcedirectory=fuzzylite -O--parallel
| dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below
| dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below
| dpkg-gensymbols: warning: debian/libfuzzylite5.0/DEBIAN/symbols doesn't match completely debian/libfuzzylite5.0.symbols
| --- debian/libfuzzylite5.0.symbols (libfuzzylite5.0_5.0+dfsg-1_i386)
| +++ dpkg-gensymbolsZpgpN1 2014-10-27 11:08:49.650184817 +0000
| @@ -1377,7 +1377,8 @@
| _ZNK2fl9Trapezoid5cloneEv@Base 5.0
| _ZNK2fl9Trapezoid9classNameEv@Base 5.0
| _ZNKSt5ctypeIcE8do_widenEc@Base 5.0
| - _ZNKSt6vectorISsSaISsEE14_M_range_checkEm@Base 5.0
| + _ZNKSt6vectorISsSaISsEE14_M_range_checkEj@Base 5.0+dfsg-1
| +#MISSING: 5.0+dfsg-1# _ZNKSt6vectorISsSaISsEE14_M_range_checkEm@Base 5.0
| _ZNKSt8_Rb_treeISsSt4pairIKSsPFPN2fl11DefuzzifierEvEESt10_Select1stIS7_ESt4lessISsESaIS7_EE4findERS1_@Base 5.0
| _ZNKSt8_Rb_treeISsSt4pairIKSsPFPN2fl4TermEvEESt10_Select1stIS7_ESt4lessISsESaIS7_EE4findERS1_@Base 5.0
| _ZNKSt8_Rb_treeISsSt4pairIKSsPFPN2fl5HedgeEvEESt10_Select1stIS7_ESt4lessISsESaIS7_EE4findERS1_@Base 5.0
[SNIP - very long list of symbol differences. Full diff is attached.]
| dh_makeshlibs: failing due to earlier errors
This is very strange... why would the generated C++ symbols be
different on i386 compared to amd64?
Well, it's C++. What else than "strange" did you expect? ;-)
All the differences you see are caused by the fact that typedef's for
types like "size_t" vary with architecture. For example, "size_t" is a
typedef for "unsigned int" on i386, but it's a typedef for "unsigned
long" on amd64.
The dpkg-shlibdeps man page tells me that it is possible to have
architecture specific symbol files. But how can I possibly generate
symbols files for all architectures with each release of fuzzylite?
In the general case: upload the package, let the package FTBFS almost
everywhere, download the logs, and then try to make sense out of it? KDE
folks have even tools to automatize the two last steps:
http://www.eyrie.org/~eagle/journal/2012-01/008.html
Or you could maintain the symbols manually, which is doable but rather
tedious.
Is there a way to avoid this?
In the case of this particular package, all the symbols that vary with
architecture seems to cruft from STL template instantiations. So perhaps
the only thing that is needed is to replace all the std::* symbols with
a regexp that covers them all? I suppose something like this should work
(but it's 100% untested):
(c++|regex)"^(void )?std::" 0
And if not and if this is normal for a C++ library built with cmake,
It's absolutely normal for C++ libraries.
--
Jakub Wilk
Reply to: