Re: Ginkgo-CADx package - was: Install on ubuntu 10.04.2 or debian 6
Am Donnerstag, 26. Mai 2011, 09:31:19 schrieb Mathieu Malaterre:
See below
> 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.
>
Is this something upstream should take care of (which I have CCed) or is this
a packaging issue ?
Sebastian
Reply to: