N: Using profile debian/main. N: Starting on group hpx/1.3.0-1 N: Unpacking packages in group hpx/1.3.0-1 N: ---- N: Processing changes file hpx (version 1.3.0-1, arch source amd64) ... N: ---- N: Processing source package hpx (version 1.3.0-1, arch source) ... I: hpx source: out-of-date-standards-version 4.2.1 (released 2018-08-25) (current is 4.3.0) N: N: The source package refers to a Standards-Version older than the one that N: was current at the time the package was created (according to the N: timestamp of the latest debian/changelog entry). Please consider N: updating the package to current Policy and setting this control field N: appropriately. N: N: If the package is already compliant with the current standards, you N: don't have to re-upload the package just to adjust the Standards-Version N: control field. However, please remember to update this field next time N: you upload the package. N: N: See /usr/share/doc/debian-policy/upgrading-checklist.txt.gz in the N: debian-policy package for a summary of changes in newer versions of N: Policy. N: N: Refer to N: https://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt for N: details. N: N: Severity: wishlist, Certainty: certain N: N: Check: standards-version, Type: source N: I: hpx source: testsuite-autopkgtest-missing N: N: This package does not declare a test suite. N: N: Having a test suite aids with automated quality assurance of the archive N: outside of your package. For example, if your package has a test suite N: it is possible to re-run that test suite when any of your package's N: dependencies have a new version and check whether that update causes N: problems for your package. N: N: In addition, since May 2018 these tests now influence migration from N: unstable to testing: N: N: https://lists.debian.org/debian-devel-announce/2018/05/msg00001.html N: N: Please add a debian/tests/control file to your package to declare a N: testsuite, but please make sure to only add autopkgtests if they provide N: meaningful coverage of your package. N: N: Refer to https://ci.debian.net/doc/ for details. N: N: Severity: wishlist, Certainty: certain N: N: Check: testsuite, Type: source N: N: ---- N: Processing buildinfo package hpx (version 1.3.0-1, arch amd64 source) ... N: ---- N: Processing binary package libhpx1 (version 1.3.0-1, arch amd64) ... E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/hpx/libio_counters.so.1.3.0 /usr/lib/x86_64-linux-gnu/openmpi/lib N: N: The binary or shared library sets RPATH or RUNPATH. This overrides the N: normal library search path, possibly interfering with local policy and N: causing problems for multilib, among other issues. N: N: The only time a binary or shared library in a Debian package should set N: RPATH or RUNPATH is if it is linked to private shared libraries in the N: same package. In that case, place those private shared libraries in N: /usr/lib/. 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/RUNPATH 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 https://wiki.debian.org/RpathIssue for details. N: N: Severity: serious, Certainty: possible N: N: Check: binaries, Type: binary, udeb N: E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/hpx/libio_counters.so.1.3.0 /usr/lib/x86_64-linux-gnu E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/hpx/libmemory.so.1.3.0 /usr/lib/x86_64-linux-gnu E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/hpx/libmemory.so.1.3.0 /usr/lib/x86_64-linux-gnu/openmpi/lib I: libhpx1: spelling-error-in-binary usr/lib/x86_64-linux-gnu/hpx/libpapi_counters.so.1.3.0 avilable available N: N: Lintian found a spelling error in the given binary. Lintian has a list N: of common misspellings that it looks for. It does not have a dictionary N: like a spelling checker does. N: N: If the string containing the spelling error is translated with the help N: of gettext or a similar tool, please fix the error in the translations N: as well as the English text to avoid making the translations fuzzy. With N: gettext, for example, this means you should also fix the spelling N: mistake in the corresponding msgids in the *.po files. N: N: You can often find the word in the source code by running: N: N: grep -rw N: N: This tag may produce false positives for words that contain non-ASCII N: characters due to limitations in strings. N: N: Severity: minor, Certainty: wild-guess N: N: Check: binaries, Type: binary, udeb N: E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/hpx/libpapi_counters.so.1.3.0 /usr/lib/x86_64-linux-gnu E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/hpx/libpapi_counters.so.1.3.0 /usr/lib/x86_64-linux-gnu/openmpi/lib E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/hpx/libparcel_coalescing.so.1.3.0 /usr/lib/x86_64-linux-gnu/openmpi/lib E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/hpx/libparcel_coalescing.so.1.3.0 /usr/lib/x86_64-linux-gnu E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libcomponent_storage.so.1.3.0 /usr/lib/x86_64-linux-gnu E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libcomponent_storage.so.1.3.0 /usr/lib/x86_64-linux-gnu/openmpi/lib I: libhpx1: spelling-error-in-binary usr/lib/x86_64-linux-gnu/libhpx.so.1.3.0 ment meant E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libhpx.so.1.3.0 /usr/lib/x86_64-linux-gnu E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libhpx.so.1.3.0 /usr/lib/x86_64-linux-gnu/openmpi/lib E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libiostreams.so.1.3.0 /usr/lib/x86_64-linux-gnu/openmpi/lib E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libiostreams.so.1.3.0 /usr/lib/x86_64-linux-gnu E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libpartitioned_vector.so.1.3.0 /usr/lib/x86_64-linux-gnu/openmpi/lib E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libpartitioned_vector.so.1.3.0 /usr/lib/x86_64-linux-gnu E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libprocess.so.1.3.0 /usr/lib/x86_64-linux-gnu E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libprocess.so.1.3.0 /usr/lib/x86_64-linux-gnu/openmpi/lib E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libunordered.so.1.3.0 /usr/lib/x86_64-linux-gnu E: libhpx1: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/libunordered.so.1.3.0 /usr/lib/x86_64-linux-gnu/openmpi/lib I: libhpx1: using-first-person-in-description line 4: we N: N: You should avoid the use of first person ("I will do this..." or "We N: recommend..."). The computer is not a person and the description does N: not speak for the maintainer or maintainers. Instead, use a more neutral N: construction and try to rephrase into factual statements about the N: package. N: N: For example, rather than saying "I don't recommend this package if you N: are short on memory," say something like "this package is not suitable N: for low-memory systems." N: N: Severity: minor, Certainty: possible N: N: Check: description, Type: binary, udeb N: W: libhpx1: spelling-error-in-description allow to allow one to 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: N: Check: description, Type: binary, udeb N: E: libhpx1: pkg-config-bad-directive usr/lib/x86_64-linux-gnu/pkgconfig/hpx_component.pc -fPIC N: N: The pkg-config file contains a wrong directive. N: N: The following file includes a wrong directive. This could lead to FTBFS N: or leak private compile flags to another package. N: N: Severity: serious, Certainty: possible N: N: Check: files, Type: binary, udeb N: E: libhpx1: pkg-config-bad-directive usr/lib/x86_64-linux-gnu/pkgconfig/hpx_component_debug.pc -fPIC W: libhpx1: binary-without-manpage usr/bin/hpxcxx 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: N: Check: manpages, Type: binary N: W: libhpx1: binary-without-manpage usr/bin/hpxrun I: libhpx1: depends-on-python2-and-python3 Depends: python, [..], python3 N: N: The specified package has a relation to both the Python 2 and Python 3 N: interpreters. It may be that the package has only been partially N: migrated to Python 3 from Python 2.x. N: N: Please check the contents and/or dependencies of this package. N: N: Severity: minor, Certainty: possible N: N: Check: python, Type: source, binary N: W: libhpx1: multi-arch-same-package-calls-pycompile postinst:6 N: N: This Multi-Arch: same package uses pycompile or py3compile in the N: specified maintainer script. N: N: py{,3}compile are tools used to byte-compile Python source files. It is N: typically run on installation of Debian packages that ship Python N: modules. However, they do not support installing several architectures N: of the same package and this is not Multi-Arch: safe. N: N: If the contents of the package is not architecture dependent, it should N: usually be made binary-all. N: N: If the contents of the package is architecture dependent, it should N: usually get a dependency on the Python interpreter for the same N: architecture. This is a dependency in the form of python3, not an N: architecture-qualified dependency such as python3:any (which can be N: fulfilled by the Python interpreter for any architecture). N: N: If a dependency on the Python interpreter for the same architecture N: exists (usually generated by dh-python), the Multi-Arch: same has no N: effect and should be dropped. N: N: Refer to the pycompile(1) manual page, the py3compile(1) manual page, N: and https://bugs.debian.org/812228 for details. N: N: Severity: normal, Certainty: possible N: N: Check: scripts, Type: binary N: W: libhpx1: non-dev-pkg-with-shlib-symlink usr/lib/x86_64-linux-gnu/libunordered.so.1.3.0 usr/lib/x86_64-linux-gnu/libunordered.so N: N: Although this package is not a "-dev" package, it installs a N: "libsomething.so" symbolic link referencing the corresponding shared N: library. When the link doesn't include the version number, it is used by N: the linker when other programs are built against this shared library. N: N: Shared libraries are supposed to place such symbolic links in their N: respective "-dev" packages, so it is a bug to include it with the main N: library package. N: N: However, if this is a small package which includes the runtime and the N: development libraries, this is not a bug. In the latter case, please N: override this warning. N: N: Refer to Debian Policy Manual section 8.4 (Development files) for N: details. N: N: Severity: normal, Certainty: possible N: N: Check: shared-libs, Type: binary, udeb N: W: libhpx1: non-dev-pkg-with-shlib-symlink usr/lib/x86_64-linux-gnu/libpartitioned_vector.so.1.3.0 usr/lib/x86_64-linux-gnu/libpartitioned_vector.so W: libhpx1: non-dev-pkg-with-shlib-symlink usr/lib/x86_64-linux-gnu/libprocess.so.1.3.0 usr/lib/x86_64-linux-gnu/libprocess.so W: libhpx1: non-dev-pkg-with-shlib-symlink usr/lib/x86_64-linux-gnu/libiostreams.so.1.3.0 usr/lib/x86_64-linux-gnu/libiostreams.so W: libhpx1: non-dev-pkg-with-shlib-symlink usr/lib/x86_64-linux-gnu/libcomponent_storage.so.1.3.0 usr/lib/x86_64-linux-gnu/libcomponent_storage.so W: libhpx1: non-dev-pkg-with-shlib-symlink usr/lib/x86_64-linux-gnu/libhpx.so.1.3.0 usr/lib/x86_64-linux-gnu/libhpx.so I: libhpx1: no-symbols-control-file usr/lib/x86_64-linux-gnu/libunordered.so.1.3.0 N: N: Although the package includes a shared library, the package does not N: have a symbols control file. N: N: dpkg can use symbols files in order to generate more accurate library N: dependencies for applications, based on the symbols from the library N: that are actually used by the application. N: N: Refer to the dpkg-gensymbols(1) manual page and N: https://wiki.debian.org/UsingSymbolsFiles for details. N: N: Severity: wishlist, Certainty: certain N: N: Check: shared-libs, Type: binary, udeb N: I: libhpx1: no-symbols-control-file usr/lib/x86_64-linux-gnu/libpartitioned_vector.so.1.3.0 I: libhpx1: no-symbols-control-file usr/lib/x86_64-linux-gnu/libprocess.so.1.3.0 I: libhpx1: no-symbols-control-file usr/lib/x86_64-linux-gnu/libiostreams.so.1.3.0 I: libhpx1: no-symbols-control-file usr/lib/x86_64-linux-gnu/libcomponent_storage.so.1.3.0 I: libhpx1: no-symbols-control-file usr/lib/x86_64-linux-gnu/libhpx.so.1.3.0 W: libhpx1: pkg-config-references-unknown-shared-library usr/lib/x86_64-linux-gnu/pkgconfig/hpx_application.pc -latomic (line 15) N: N: The specified pkg-config(1) file references a shared object via, for N: example, Libs: -lfoo but this package appears to not ship the associated N: "libfoo.so" shared library. N: N: This will result in a linker error and was likely caused by a missing N: installation step. N: N: Please ensure that your package ships the corresponding libfoo.so shared N: object file. N: N: Refer to the pkg-config(1) manual page and N: https://bugs.debian.org/919180 for details. N: N: Severity: normal, Certainty: possible N: N: Check: shared-libs, Type: binary, udeb N: W: libhpx1: pkg-config-references-unknown-shared-library usr/lib/x86_64-linux-gnu/pkgconfig/hpx_application_debug.pc -latomic (line 15) W: libhpx1: pkg-config-references-unknown-shared-library usr/lib/x86_64-linux-gnu/pkgconfig/hpx_component.pc -latomic (line 15) W: libhpx1: pkg-config-references-unknown-shared-library usr/lib/x86_64-linux-gnu/pkgconfig/hpx_component_debug.pc -latomic (line 15) N: ---- N: Processing binary package libhpx-dev (version 1.3.0-1, arch amd64) ... I: libhpx-dev: using-first-person-in-description line 4: we W: libhpx-dev: spelling-error-in-description allow to allow one to I: libhpx-dev: wrong-section-according-to-package-name libhpx-dev => libdevel N: N: This package has a name suggesting that it belongs to a section other N: than the one it is currently categorized in. N: N: Severity: wishlist, Certainty: possible N: N: Check: fields, Type: binary, udeb, source N: N: ---- N: Processing binary package libhpx1-dbgsym (version 1.3.0-1, arch amd64) ... N: Finished processing group hpx/1.3.0-1