On Thu, 07 Feb 2013, Amul Shah wrote: > Andreas/Yaroslav, > Thanks to Luis, I setup a pbuilder environment and built GT.M. There > are a few lintian warnings and some package naming oddities that I > am unsure about. How do I grab the build log, aside from using tee?
spoiled me uses git-buildpackage (could be called with --pbuilder option) and that generates a nice .log for me > I say package naming oddity, because the generated deb is named > fis-gtm-6.0-001_6.0-001-1_amd64.deb, where I expected to see a deb > named fis-gtm_6.0-001-1_amd64.deb. per our discussion at kitware some time ago -- we agreed to have versioned binary package (i.e. version in the name) to signal that per se you can't just upgrade fis-gtm to a new major.minor version to still access previous DB -- it needs to be migrated. And that is why it is better to be able to co-install 2 (or more) versions at the same time. I do not remember though having -001 revision in there, and would have expected fis-gtm-6.0_6.0-001-1_amd64.deb, but I could be wrong. > I can't find the lintian warnings in pbuidler's output, but I did see them in > debuild's output. This is what I see in debuild: > W: fis-gtm source: changelog-should-mention-nmu > W: fis-gtm source: source-nmu-has-incorrect-version-number 6.0-001-1 are you listed in Maintainers/Uploaders as well (with identical name in the last changelog entry signature)? > W: fis-gtm-6.0-001: setuid-binary usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshr > 4755 root/root > W: fis-gtm-6.0-001: non-standard-dir-perm > usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/ 0500 != 0755 > W: fis-gtm-6.0-001: setuid-binary > usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr 4500 root/root > W: fis-gtm-6.0-001: executable-is-not-world-readable > usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr 4500 I think we had discussion on those "security" measures -- would need to look in emails to rehears what was our conclusion ;) > I'm not sure what nmu is. http://wiki.debian.org/NonMaintainerUpload > The flagged permissions for gtmsecshr are > what we require and check for. Do I need to suppress those warnings? probably > These are the warnings that I see in pbuilder's output: > dpkg-shlibdeps: warning: > debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/plugin/libgtmcrypt.so > contains an unresolvable reference to symbol gtm_free: it's probably > a plugin > dpkg-shlibdeps: warning: 6 other similar warnings have been skipped (use -v > to see them all) > dpkg-shlibdeps: warning: package could avoid a useless dependency if and it is a plugin, so might rely on the main process to have the namespace loaded for it.,.. so should be safe to ignore (not sure if there is a way to suppress) > debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/ftok > debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_server > debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/lke > debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/mumps > debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/mupip > debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_gnp_server > debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_pkdisp > debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/dse > debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/libgtmshr.so > debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_shmclean > debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtmsecshrdir/gtmsecshr > debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/gtcm_play > were not linked against libncurses.so.5 (they use none of the > library's symbols) > dpkg-shlibdeps: warning: package could avoid a useless dependency if > debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/plugin/libgtmcrypt.so > was not linked against libgpg-error.so.0 (it uses none of the > library's symbols) > gtm_free is provided by > debian/fis-gtm-6.0-001/usr/lib/fis-gtm/V6.0-001_x86_64/libgtmshr.so. if those statements are correct -- you might like to adjust your CMake* files ... but that is not critical really > Do I need to suppress this warning? I will look into whether or not > we can avoid the dependency for libncurses and ligpg-error. probably it is not that you need to avoid dependency -- it is just that you are linking against them where needed and not. You might like (not sure if tollerable ;) ) use -DCMAKE_SHARED_LINKER_FLAGS="-Wl,--as-needed" -DCMAKE_EXE_LINKER_FLAGS="-Wl,--as-needed" ? > What are the next steps? let's decide on versioning and above NMU false-positives. And I guess Andreas' blessing ;) -- Yaroslav O. Halchenko http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130207172123.gq8...@onerussian.com
