Bug#881789: libglvnd: missing libGLX_indirect.so, breaks GLX with remote X server
Package: libglx0
Version: 1.0.0-1
Severity: important
Dear Maintainer,
I'm running testing on a headless system, and a recent change to use
libglxvnd has stopped GLX from working when displayed to a remote
machine. This was working fine before the migration to use glvnd for
libGL/libGLX.
e.g. running glxinfo fails with the following error:
$ glxinfo
name of display: localhost:11.0
Error: couldn't find RGB GLX visual or fbconfig
strace'ing glxinfo shows it trying to load libGLX_indirect.so.0 and
failing:
$ strace -etrace=open glxinfo
open("/lib/x86_64-linux-gnu/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
open("/lib/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file
or directory)
open("/usr/lib/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such
file or directory)
Adding a symlink from libGLX_mesa.so.0 to libGLX_indrect.so.0 makes
things work:
$ sudo ln -s /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
/usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0
$ glxinfo | head
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
name of display: localhost:11.0
display: localhost:11 screen: 0
direct rendering: No (If you want to find out why, try setting
LIBGL_DEBUG=verbose)
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info,
GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample,
GLX_SGIX_fbconfig
Looking at the source for glvnd and reading some NVIDIA documentation,
it seems like glvnd is trying to fallback to a generic libGLX_indirect
library if vendor-specific library doesn't exist or GLX_EXT_glvnd is not
present on the remote X server (this is my situation).
However, I can't find libGLX_indirect.so.0 provided by any Debian
packages. It seems like either libglvnd or mesa should provide a symlink
from libGLX_indirect.so.0 to a default GL implementation for these
situations.
I'd provide a patch but I'm not sure what package should be taking care
of this
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages libglx0:amd64 depends on:
ii libc6 2.24-17
ii libglvnd0 1.0.0-1
ii libglx-mesa0 [libglx-vendor] 17.2.4-1+b1
ii libx11-6 2:1.6.4-3
ii libxext6 2:1.3.3-1+b2
libglx0:amd64 recommends no packages.
libglx0:amd64 suggests no packages.
-- no debconf information
Bug#881566: python-acoustid: incompatible/broken on Python 3 (fix available upstream)
Package: python3-acoustid Version: 1.1.2-2 Severity: important Dear Maintainer, The current version of python-acoustid doesn't work with Python 3. Specifically the submit() function to submit fingerprints is broken: https://github.com/beetbox/pyacoustid/pull/33 There is a fix available upstream in the 1.1.5 release. Could you please update the Debian packaging to include this fix? Thanks, James -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages python3-acoustid depends on: ii libchromaprint11.4.2-1 ii python33.6.3-2 pn python3-audioread ii python3-requests 2.18.1-1 python3-acoustid recommends no packages. python3-acoustid suggests no packages. -- no debconf information
Bug#881565: python-acoustid: incompatible with python3 (fix availble upstream)
Package: python-acoustid Version: 1.1.2-2 Severity: important Dear Maintainer, The current version of python-acoustid doesn't work with Python 3. Specifically the submit() function to submit fingerprints is broken: https://github.com/beetbox/pyacoustid/pull/33 There is a fix available upstream in the 1.1.5 release. Could you please update the Debian packaging to include this fix? Thanks, James -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages python3-acoustid depends on: ii libchromaprint11.4.2-1 ii python33.6.3-2 pn python3-audioread ii python3-requests 2.18.1-1 python3-acoustid recommends no packages. python3-acoustid suggests no packages. -- no debconf information
Bug#845937: tiny-initramfs: init binary crashes on 4.8.x kernels - need to rebuild against newer dietlibc
Package: tiny-initramfs Version: 0.1-2 Severity: critical Recent Debian kernels (4.8.x) have disabled support for legacy vsyscall emulation. changelog entry from kernel packages: * [amd64] Enable LEGACY_VSYSCALL_NONE instead of LEGACY_VSYSCALL_EMULATE. This breaks (e)glibc 2.13 and earlier, and can be reverted using the kernel parameter: vsyscall=emulate This causes problems with tiny-initramfs as the init binary is linked against an old version of dietlibc which uses the vsyscall for accessing the kernel gettimeofday functions. This manifests as the init process being killed when it attempts to access the vsyscall interface which renders the system unbootable. dietlibc 0.33 adds changes to use the kernel vDSO instead of the legacy vsyscall interface. I have tested rebuilding tiny-initramfs against the latest dietlibc in Debian (0.34~cvs20160606-3) and the rebuilt init binary works successfully on 4.8.x kernels. Setting severity to critical as this renders systems using tiny-initramfs unbootable when the upgraded kernel package is installed. It would be great to get an updated tiny-initramfs package rebuilt against the latest dietlibc. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages tiny-initramfs depends on: ii tiny-initramfs-core 0.1-2 tiny-initramfs recommends no packages. tiny-initramfs suggests no packages. -- no debconf information
Bug#414647:
Any update on this bug? Sorry to hassle you about it - I'm sure you're on top of it - but the bug has been pending for almost a month and version 2.9 of Nagios is out now. Thanks, James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
