Re: Ginkgo-CADx package - was: Install on ubuntu 10.04.2 or debian 6
On Wed, May 25, 2011 at 10:39 PM, Andreas Tille <andreas@an3as.eu> wrote:
> I have not built the package - but packages with lintian *warnings* can
> be uploaded (and IMHO the rpath issue is only a warning, but I might be
> wrong). Could anybody post the output of "lintian -i" ?
i cannot update the svn today. So I'll post the output of lintian I
got the last time I tried:
$ ls
-rw-r--r-- 1 mathieu mathieu 1609 May 11 13:04
ginkgocadx_2.4.1.1-1_amd64.changes
$ lintian -i ginkgocadx_2.4.1.1-1_amd64.changes
W: ginkgocadx source: newer-standards-version 3.9.2 (current is 3.9.1)
N:
N: The source package refers to a Standards-Version which is newer than the
N: highest one lintian is programmed to check. If the source package is
N: correct, then please upgrade lintian to the newest version. (If there is
N: no newer lintian version, then please bug lintian-maint@debian.org to
N: make one.)
N:
N: Severity: normal, Certainty: certain
N:
W: ginkgocadx: spelling-error-in-description throught through
N:
N: Lintian found a spelling error in the package description. Lintian has a
N: list of common misspellings that it looks for. It does not have a
N: dictionary like a spelling checker does. It is particularly picky about
N: spelling and capitalization in package descriptions since they're very
N: visible to end users.
N:
N: Severity: minor, Certainty: certain
N:
W: ginkgocadx: new-package-should-close-itp-bug
N:
N: This package appears to be the first packaging of a new upstream
N: software package (there is only one changelog entry and the Debian
N: revision is 1), but it does not close any bugs. The initial upload of a
N: new package should close the corresponding ITP bug for that package.
N:
N: This warning can be ignored if the package is not intended for Debian or
N: if it is a split of an existing Debian package.
N:
N: Refer to Debian Developer's Reference section 5.1 (New packages) for
N: details.
N:
N: Severity: normal, Certainty: certain
N:
W: ginkgocadx: binary-without-manpage usr/bin/ginkgocadx
N:
N: Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games should
N: have a manual page
N:
N: Note that though the man program has the capability to check for several
N: program names in the NAMES section, each of these programs should have
N: its own manual page (a symbolic link to the appropriate manual page is
N: sufficient) because other manual page viewers such as xman or tkman
N: don't support this.
N:
N: If the name of the man page differs from the binary by case, man may be
N: able to find it anyway; however, it is still best practice to make the
N: case of the man page match the case of the binary.
N:
N: If the man pages are provided by another package on which this package
N: depends, lintian may not be able to determine that man pages are
N: available. In this case, after confirming that all binaries do have man
N: pages after this package and its dependencies are installed, please add
N: a lintian override.
N:
N: Refer to Debian Policy Manual section 12.1 (Manual pages) for details.
N:
N: Severity: normal, Certainty: possible
N:
W: ginkgocadx: postinst-has-useless-call-to-ldconfig
N:
N: The postinst script calls ldconfig even though no shared libraries are
N: installed in a directory controlled by the dynamic library loader.
N:
N: Refer to Debian Policy Manual section 8.1.1 (ldconfig) for details.
N:
N: Severity: minor, Certainty: certain
N:
W: ginkgocadx: postrm-has-useless-call-to-ldconfig
N:
N: The postrm script calls ldconfig even though no shared libraries are
N: installed in a directory controlled by the dynamic library loader.
N:
N: Refer to Debian Policy Manual section 8.1.1 (ldconfig) for details.
N:
N: Severity: minor, Certainty: certain
N:
E: ginkgocadx: binary-or-shlib-defines-rpath
usr/lib/ginkgocadx/Plugins/libvisualizator.so.2.4.1.1
/usr/lib/openmpi/lib
N:
N: The binary or shared library sets RPATH. This overrides the normal
N: library search path, possibly interfering with local policy and causing
N: problems for multilib, among other issues.
N:
N: The only time a binary or shared library in a Debian package should set
N: RPATH is if it is linked to private shared libraries in the same
N: package. In that case, place those private shared libraries in
N: /usr/lib/<package>. Libraries used by binaries in other packages should
N: be placed in /lib or /usr/lib as appropriate, with a proper SONAME, in
N: which case RPATH is unnecessary.
N:
N: To fix this problem, look for link lines like:
N: gcc test.o -o test -Wl,--rpath,/usr/local/lib
N: or
N: gcc test.o -o test -R/usr/local/lib
N: and remove the -Wl,--rpath or -R argument. You can also use the chrpath
N: utility to remove the RPATH.
N:
N: Refer to http://wiki.debian.org/RpathIssue for details.
N:
N: Severity: serious, Certainty: possible
N:
E: ginkgocadx: binary-or-shlib-defines-rpath
usr/lib/ginkgocadx/libCADxCore.so.2.4.1.1 /usr/lib/openmpi/lib
E: ginkgocadx: embedded-library
usr/lib/ginkgocadx/libCADxCore.so.2.4.1.1: sqlite
N:
N: The given ELF object appears to have been statically linked to a
N: library. Doing this is strongly discouraged due to the extra work needed
N: by the security team to fix all the extra embedded copies or trigger the
N: package rebuilds, as appropriate.
N:
N: If the package uses a modified version of the given library it is highly
N: recommended to coordinate with the library's maintainer to include the
N: changes on the system version of the library.
N:
N: Refer to Debian Policy Manual section 4.13 (Convenience copies of code)
N: for details.
N:
N: Severity: serious, Certainty: possible
N:
So in summary rpath is an Error.
HTH
--
Mathieu
Reply to: