Bug#1036539: nbd-client: not working inside initrd due to unresolved library dependencies
Package: nbd-client Version: 1:3.21-1+deb11u1 Severity: important Tags: d-i X-Debbugs-Cc: tomas.wo...@gmail.com The nbd-client binary (/sbin/nbd-client), while working fine on the regular system, is not working inside initrd images (which have very limited set of libraries). During system startup, it is failing with: /sbin/nbd-client: error while loading shared libraries: libgnutls.so.30: cannot open shared object file: No such file or directory Currently the nbd-client used for building initrd images is copied the initramfs hook /usr/share/initramfs-tools/hooks/nbd which uses the regular /sbin/nbd-client, which has the following dependencies (the example is for i386, but, of course, similar for others): # ldd /sbin/nbd-client linux-gate.so.1 (0xb7f3f000) libgnutls.so.30 => /lib/i386-linux-gnu/libgnutls.so.30 (0xb7cf5000) libnl-genl-3.so.200 => /lib/i386-linux-gnu/libnl-genl-3.so.200 (0xb7cec000) libnl-3.so.200 => /lib/i386-linux-gnu/libnl-3.so.200 (0xb7cc7000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7adf000) libp11-kit.so.0 => /lib/i386-linux-gnu/libp11-kit.so.0 (0xb798a000) libidn2.so.0 => /lib/i386-linux-gnu/libidn2.so.0 (0xb7968000) libunistring.so.2 => /lib/i386-linux-gnu/libunistring.so.2 (0xb77e6000) libtasn1.so.6 => /lib/i386-linux-gnu/libtasn1.so.6 (0xb77cf000) libnettle.so.8 => /lib/i386-linux-gnu/libnettle.so.8 (0xb7784000) libhogweed.so.6 => /lib/i386-linux-gnu/libhogweed.so.6 (0xb773b000) libgmp.so.10 => /lib/i386-linux-gnu/libgmp.so.10 (0xb76ab000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7689000) /lib/ld-linux.so.2 (0xb7f41000) libffi.so.7 => /lib/i386-linux-gnu/libffi.so.7 (0xb767f000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7679000) which, as one can expect, are not met inside an initrd... Obviously, initrd images require a different binary to function properly. Currently such binary is not available in the deb package... Also, the one from installer's nbd-client udeb package, doesn't work either (it is missing libnl-genl-3). Personally, I resolved the problem by building a custom version of the nbd- client from sources, with possibly minimal dependencies: # ldd nbd-client linux-gate.so.1 (0xb7f6) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7d54000) /lib/ld-linux.so.2 (0xb7f62000) and changing the initramfs hook to use it.
Bug#995423: libyaml-cpp-dev: Incorrect include PATH in CMake configuration script.
Hello Gianfranco, On 10/27/21 10:13 AM, Gianfranco Costamagna wrote: Hello Tomasz On Wed, 20 Oct 2021 19:58:47 +0200 Tomasz Wolak wrote: [...] I have tried to build the source package 0.7.0 (https://packages.debian.org/experimental/libyaml-cpp-dev) for my Debian (bullseye), but unfortunately building the package fails with: https://buildd.debian.org/status/package.php?p=yaml-cpp=experimental 0.7.0+dfsg-5 should be buildable correctly, the package was broken due to missing symbols please give it another shot if possible :) Gianfranco Yes, the version 0.7.0+dfsg-5 builds on Bullseye and both pkg-config and CMake's find_package() return "" (an empty string) as include directory for yaml-cpp. The library's header files are under system's generic /usr/include ( /usr/include/yaml-cpp/ in this case) - so it seems correct to me as it is fine for compilation (as long as source files are using the relative path ). I was a bit confused though, as the software that I was building (RStudio, www.rstudio.com, the latest released version rstudio-2021.09.0-351) was still failing - because its CMake script checks if the include directory (provided in YAML_CPP_INCLUDE_DIR) exists... This seems to me a bad practice considering the above (no additional include paths may be needed for correct compilation). However, this varies also between different libraries - for some, the tools returns an absolute path to their subdirectory, eg. for uuid, pkg-config returns -I/usr/include/uuid; for SDL2 both pkg-config and CMake points to /usr/include/SDL2 etc.). In such case, RStudio developers' approach would be correct... Is there a (at least recommended) standard for this or each library goes its own way? (I suppose Debian does not enforce this, just follows the original). Anyway - 0.7.0 seems OK. (backported to Bullseye will fix the problem with CMake). Thank you. Tomasz
Bug#995423: libyaml-cpp-dev: Incorrect include PATH in CMake configuration script.
Hi Gianfranco,
Thanks for having a look at the issue.
On Thu, 14 Oct 2021 19:17:53 +0200 Gianfranco Costamagna
wrote:
> Hello Tomasz
> […]
> can you please check if 0.7.0 in debian/experimental fixes this issue?
> The cmake scripts have been reworked, and I can't see anymore the
variable not correctly evaluated.
>
> In case please let me know if the bug is fixed
>
> thanks
>
> Gianfranco
>
I have tried to build the source package 0.7.0
(https://packages.debian.org/experimental/libyaml-cpp-dev) for my Debian
(bullseye), but unfortunately building the package fails with:
nm --dynamic --defined-only build-shared/libyaml-cpp.so | awk '$2 ~ /W/
{ print " " $3 "@Base 0.7.0" } ' > debian/weak-symbols
dh_makeshlibs -VNone
dpkg-gensymbols: warning: some new symbols appeared in the symbols file:
see diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the
symbols file: see diff output below
dpkg-gensymbols: warning: debian/libyaml-cpp0.7/DEBIAN/symbols doesn't
match completely debian/libyaml-cpp0.7.symbols
[...]
dh_makeshlibs: error: failing due to earlier errors
make[1]: *** [debian/rules:62: override_dh_makeshlibs] Error 25
make[1]: Leaving directory '/home/debian/tmp/yaml-cpp-0.7.0+dfsg'
make: *** [debian/rules:71: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -i -b failed
It passes compilation and tests but fails on the
"Install the project..." part.
In consequence, I cannot see what would be in the built package to be
sure, but the configuration files for cmake seem to be generated. The
contents of the generated file
yaml-cpp-0.7.0+dfsg/build-shared/yaml-cpp-config.cmake
is as follows:
# - Config file for the yaml-cpp package
# It defines the following variables
# YAML_CPP_INCLUDE_DIR - include directory
# YAML_CPP_LIBRARIES- libraries to link against
# Compute paths
get_filename_component(YAML_CPP_CMAKE_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
set(YAML_CPP_INCLUDE_DIR "")
# Our library dependencies (contains definitions for IMPORTED targets)
include("${YAML_CPP_CMAKE_DIR}/yaml-cpp-targets.cmake")
# These are IMPORTED targets created by yaml-cpp-targets.cmake
set(YAML_CPP_LIBRARIES "")
so it does not seem correct (both include and libs settings are empty...).
I do not know the process of fixing bugs in Debian (ie. whether you
rather backport a newer version from testing/unstable or fix current
version), but at the moment it seems to me that it would be easier to
fix the current package (0.6.3) and just make it usable with cmake than
backporting 0.7.0 (which seems to have more complex issues when building
on bullseye).
Cheers,
Tomasz
Bug#995423: libyaml-cpp-dev: Incorrect include PATH in CMake configuration script.
Package: libyaml-cpp-dev Version: 0.6.3-9 Severity: normal X-Debbugs-Cc: tomas.wo...@gmail.com One of the package config files for CMake: /usr/lib/x86_64-linux-gnu/cmake/yaml-cpp/yaml-cpp-config.cmake contains an incorrect path to the library's header files: 'include' instead of '/usr/include/yaml-cpp'. I have managed to hot-fix this by correcting debian patches: 1. install-cmake-dev-files.patch - the line (for CMakeLists.txt): set(INCLUDE_INSTALL_ROOT_DIR include) was changed to: -set(INCLUDE_INSTALL_ROOT_DIR include) +set(INCLUDE_INSTALL_ROOT_DIR /usr/include) 2. fix-pkg-config.patch, where I changed the line: +set(YAML_CPP_INCLUDE_DIR "@INCLUDE_INSTALL_ROOT_DIR@") to the following: +set(YAML_CPP_INCLUDE_DIR "@INCLUDE_INSTALL_DIR@") After changing this, the rebuilt package contains the correct path to the header files (/usr/include/yaml-cpp) in its cmake configuration. (I am not sure if this is the best way for fixing this but it seems reasonable. It should be reviewed and tested, of course. I am not sure how to provide you a patch to a Debian patch... that's why such descriptive form). (Btw. version 0.6.3-10 seems to have the same problem). -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libyaml-cpp-dev depends on: ii libyaml-cpp0.6 0.6.3-9 libyaml-cpp-dev recommends no packages. libyaml-cpp-dev suggests no packages. -- no debconf information
Bug#971387: update-glx does not update libglx.so to NVIDIA's (340)
Package: update-glx Version: 1.0.0 Severity: normal Dear Maintainer, After a recent update of the system (Debian 10, stable), which included updates of *nvidia* and *glx* packages, the GLX interface stopped working - Xorg's log: -- [ 2439.150] Loading extension GLX (...) [ 2439.159] (EE) NVIDIA(0): Failed to initialize the GLX module; please check i n your X [ 2439.159] (EE) NVIDIA(0): log file that the GLX module has been loaded in you r X [ 2439.159] (EE) NVIDIA(0): server, and that the module is the NVIDIA GLX modul e. If [ 2439.159] (EE) NVIDIA(0): you continue to encounter problems, Please try [ 2439.159] (EE) NVIDIA(0): reinstalling the NVIDIA driver. - Reconfiguring using update-alternatives --config glx and setting as follows: # update-alternatives --config glx There are 3 choices for the alternative glx (providing /usr/lib/glx). SelectionPath Priority Status 0/usr/lib/nvidia 100 auto mode 1/usr/lib/mesa-diverted 5 manual mode * 2/usr/lib/nvidia 100 manual mode 3/usr/lib/nvidia/bumblebee 95manual mode did not help. Also, reconfiguring nvidia's drivers (which are set to /usr/lib/nvidia/legacy-340xx), made no change. I found out that the problem was with the library: /usr/lib/xorg/modules/extensions/libglx.so which is loaded by the Xorg server. My system has the following libglx libraries installed: # dpkg -S libglx.so xserver-xorg-core: /usr/lib/xorg/modules/extensions/libglx.so xserver-xorg-video-nvidia-legacy-340xx: /usr/lib/nvidia/legacy-340xx/libglx.so.340.108 xserver-xorg-video-nvidia-legacy-340xx: /usr/lib/nvidia/legacy-340xx/libglx.so and manual overwriting the /usr/lib/xorg/modules/extensions/libglx.so with /usr/lib/nvidia/legacy-340xx/libglx.so fixed the issue. As far as I know, these drivers (340) have no support from NVidia anymore, so I do not know whether it will be maintained for Debian, but maybe it is still worth to fix... One more thing - the problem existed also before (I fixed this on my box in the same way some months ago). Hope it helps. Regards, Tomasz -- Package-specific info: Diversions: diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.0.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.7.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.7.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLX_indirect.so.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLX_indirect.so.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.0.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.0.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to
