Bug#941774: lintian: False positive for symbols-file-contains-current-version-with-debian-revision
Hi Ross, On Sat, Dec 21, 2019 at 8:17 PM Ross Vandegrift wrote: > > See "Note on eolian-generated > symbols" in README.source if you're curious. Thanks for sending this. It's an unusual way to export C symbols to C++ users. It offers users a C++ class structure without actually using C++. For future reference, this presentation is a good starting point: https://download.tizen.org/misc/media/conference2014/slides/tdc2014-core-object-model-eo-efl.pdf Kind regards Felix Lechner
Bug#941774: lintian: False positive for symbols-file-contains-current-version-with-debian-revision
Hi Felix, I forgot all about this, thanks for following up. On Sat, Dec 14, 2019 at 02:15:41PM -0800, Felix Lechner wrote: > $ fgrep -- -5 dir2/symbols > > _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPcEEvT_S7_St20forward_iterator_tag@Base > 1.21.1-5+b1 > > The symbol shows a Debian revision. Lintian is right. Aha - I was searching the symbols file from the source package. Now I see that the binary package's symbols file is not necessarily the same. Sorry for the mistake. > As a side note, I was surprised to find 188 additional Debian revisions: These are intentional (and have overrides). See "Note on eolian-generated symbols" in README.source if you're curious. > Finally, I am not sure why some symbols were decoded properly using > the appropriate pattern [1], while the offender is raw 'c++'. Did you > mix C and C++ symbols in the same shared library? Yes, by accident - libephysics uses a c++ library, and was leaking this c++ symbol. Looks like gcc8 -O2 inlined this function, while gcc9 doesn't until -O3. Ross
Bug#941774: lintian: False positive for symbols-file-contains-current-version-with-debian-revision
Hi Ross, On Sat, Oct 12, 2019 at 8:39 PM Ross Vandegrift wrote: > > I'm seeing a similar false positive: I do not. The symbols file in the control section of libephysics1_1.21.1-5+b1_amd64.deb contains the following line: $ fgrep -- -5 dir2/symbols _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPcEEvT_S7_St20forward_iterator_tag@Base 1.21.1-5+b1 The symbol shows a Debian revision. Lintian is right. The line furthermore matches Lintian's output: $ frontend/lintian --no-tag-display-limit ../bugs/symbols/libephysics1_1.21.1-5+b1_amd64.deb E: libephysics1: symbols-file-contains-current-version-with-debian-revision on symbol _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPcEEvT_S7_St20forward_iterator_tag@Base N: 1 tag overridden (1 warning) This is not a bug in Lintian (at least not anymore). I will close this bug after writing to Scott, as well. As a side note, I was surprised to find 188 additional Debian revisions: $ fgrep -- -0~eo dir2/symbols | head -5 ephysics_body_angular_movement_enable_get@Base 1.21.1-0~eo ephysics_body_angular_movement_enable_set@Base 1.21.1-0~eo ephysics_body_angular_velocity_get@Base 1.21.1-0~eo ephysics_body_angular_velocity_set@Base 1.21.1-0~eo ephysics_body_back_boundary_add@Base 1.21.1-0~eo $ fgrep -- -0~eo dir2/symbols | wc -l 188 Finally, I am not sure why some symbols were decoded properly using the appropriate pattern [1], while the offender is raw 'c++'. Did you mix C and C++ symbols in the same shared library? Kind regards Felix Lechner [1] https://wiki.debian.org/UsingSymbolsFiles
Bug#941774: lintian: False positive for symbols-file-contains-current-version-with-debian-revision
On Sat, Oct 05, 2019 at 02:30:30AM -0400, Scott Kitterman wrote: > (optional=templinst|arch=!amd64 !arm64 > !x32)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE0ERKNS0_14DeviceResponseILS2_0ENS0_7stick109GetStatus15ResponsePayload24status_translate_commandB5cxx11Ei@Base > 3.5 > > No dash anywhere. In fact, in only dashes in the entire symbols file > are in the first three lines of the file: I'm seeing a similar false positive: E: libephysics1: symbols-file-contains-current-version-with-debian-revision on symbol _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPcEEvT_S7_St20forward_iterator_tag@Base Though in my case, there's no such symbol in the symbols file. This is from a local run of lintian 2.25.0, this version of libephysics1 hasn't been uploaded yet. Ross
Bug#941774: lintian: False positive for symbols-file-contains-current-version-with-debian-revision
Package: lintian Version: 2.24.0 Severity: normal The current version of lintian on lintian.d.o generates false positives for this test. See https://lintian.debian.org/maintainer/sc...@kitterman.com.html#libnitrokey for an example. The line in the symbols file that's referenced for libnitrokey 3.5-1 is: (optional=templinst|arch=!amd64 !arm64 !x32)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE0ERKNS0_14DeviceResponseILS2_0ENS0_7stick109GetStatus15ResponsePayload24status_translate_commandB5cxx11Ei@Base 3.5 No dash anywhere. In fact, in only dashes in the entire symbols file are in the first three lines of the file: # SymbolsHelper-Confirmed: 3.5 alpha amd64 arm64 armel armhf hppa i386 ia64 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32 libnitrokey.so.3 libnitrokey3 #MINVER# * Build-Depends-Package: libnitrokey-dev This appears to be a regression from 2.15.0 as when I run lintian locally on a stable system, this error is not shown. This is superficially similar to #539066, but is a distinct problem not related to the upstream version number. Scott K
