Bug#664700: libva1: please search dri module in /usr/lib/{triplet/, }dri
Hi Andreas On 2012-03-20 01:38:29, Andreas Beckmann wrote: Package: libva1 Version: 1.0.15-4 Severity: normal Hi, please use a search path for the DRI modules that contains both /usr/lib/triplet/dri /usr/lib/dri While we can (hopefully) fix the Debian packages to ship the files in the multiarch locations, the multiarch move breaks any third-party (probably proprietary) software/installer/... that is not multiarch aware. Therefore plugins should be searched in both locations. So far the following problems have been reported: xvba-va: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664487 fglrx + vainfo: $ vainfo libva: VA-API version 0.32.0 Xlib: extension XFree86-DRI missing on display :0. libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/fglrx_drv_video.so libva: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit I'm not sure if I can move dri/fglrx_drv_video.so around - it is loaded from the fglrx driver (a non-free blob) using the hardcoded path /usr/lib/dri ... (and the last time I tried to use symlinks (although in a different context) the fglrx blob used lstat() and complained about world writable files ...) I'm currently going through some old bug reports and stumbled upon this one. I'm wondering if there's still something left to do here. All the DRI modules seem to be in the multi arch path nowadays and #664487 has been fixed two years ago. Since there doesn't appear to be a bug present anymore I'm leaning towards closing the bug. What do you think? Cheers -- Sebastian Ramacher signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#664700: libva1: please search dri module in /usr/lib/{triplet/, }dri
Package: vainfo
Version: 1.0.15-4
Followup-For: Bug #664700
I came across the same problem, The first multiarch patch for this
package let libva search in the right place
here is a patch to restore that functionality (but not search in the
non-multiarch paths as well)
in the source look for LIBVA_DRIVERS_PATH
-- System Information:
Debian Release: wheezy/sid
APT prefers precise-updates
APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500,
'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-24-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages vainfo depends on:
ii libc62.15-0ubuntu10
ii libva-x11-1 1.1.0.pre1~git20120417.aa8d1ca-ppa4~precise
ii libva1 1.1.0.pre1~git20120417.aa8d1ca-ppa4~precise
ii libx11-6 2:1.4.99.1-0ubuntu2
From 8778fb25143b48c8d85abc4e3f87b509b366fcc8 Mon Sep 17 00:00:00 2001
From: Shawn Landden shawnland...@gmail.com
Date: Thu, 17 May 2012 18:55:52 -0700
Subject: [PATCH] fix vainfo for multiarch
commit 2298fb2d8926984cab6195284459a56601987c62
[Use dh_auto_configure to pass in default+extra configure options.]
broke vainfo's ability to find the xvba driver, we need the default internal
LIBVA_DRIVER_PATH, which gets set by $libdir, to be multiarch
---
debian/rules |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/debian/rules b/debian/rules
index 8abd759..2fe4590 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,7 @@
#!/usr/bin/make -f
+include /usr/share/dpkg/architecture.mk
+
%:
dh $@ --parallel --with autoreconf
@@ -9,7 +11,9 @@ override_dh_makeshlibs:
dh_makeshlibs -plibva1 -V 'libva1 ( 1.0.15~)'
override_dh_auto_configure:
- dh_auto_configure -- --disable-silent-rules
+ dh_auto_configure -- --disable-silent-rules \
+ --prefix=/usr \
+ --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
get-orig-source:
$(dir $_)libva-get-orig-source
--
1.7.9.5
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#664700: libva1: please search dri module in /usr/lib/{triplet/, }dri
Hi Andres,
you need to Cc: the bug submitter if you expect answers.
For libvdpau please see
debian/patches/vdpau-module-searchpath.patch
where I sanitized the searching to look in \${ORIGIN}/vdpau/,
$libdir/vdpau/, /usr/lib/vdpau/.
dlopen() does the right thing, i.e. won't load a mismatching
library (e.g. 32bit into a 64bit programm).
Andreas
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#664700: libva1: please search dri module in /usr/lib/{triplet/, }dri
On Tue, Mar 27, 2012 at 4:53 PM, Andreas Beckmann deb...@abeckmann.de wrote:
Hi Andres,
you need to Cc: the bug submitter if you expect answers.
For libvdpau please see
debian/patches/vdpau-module-searchpath.patch
where I sanitized the searching to look in \${ORIGIN}/vdpau/,
$libdir/vdpau/, /usr/lib/vdpau/.
dlopen() does the right thing, i.e. won't load a mismatching
library (e.g. 32bit into a 64bit programm).
Andreas
I would feel more comfortable if this were forwarded upstream. You may
want to forward a patch to them yourself. Right now, this isn't in my
list of priorities.
--
~ Andres
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#664700: libva1: please search dri module in /usr/lib/{triplet/, }dri
On Mon, Mar 19, 2012 at 9:55 PM, Andres Mejia amejia...@gmail.com wrote: On Mon, Mar 19, 2012 at 8:38 PM, Andreas Beckmann deb...@abeckmann.de wrote: Package: libva1 Version: 1.0.15-4 Severity: normal Hi, please use a search path for the DRI modules that contains both /usr/lib/triplet/dri /usr/lib/dri While we can (hopefully) fix the Debian packages to ship the files in the multiarch locations, the multiarch move breaks any third-party (probably proprietary) software/installer/... that is not multiarch aware. Therefore plugins should be searched in both locations. So far the following problems have been reported: xvba-va: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664487 fglrx + vainfo: $ vainfo libva: VA-API version 0.32.0 Xlib: extension XFree86-DRI missing on display :0. libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/fglrx_drv_video.so libva: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit I'm not sure if I can move dri/fglrx_drv_video.so around - it is loaded from the fglrx driver (a non-free blob) using the hardcoded path /usr/lib/dri ... (and the last time I tried to use symlinks (although in a different context) the fglrx blob used lstat() and complained about world writable files ...) Andreas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers I don't believe modules should be allowed to load from /usr/lib/dri in a multiarch library. Suppose the amd64 library package is loaded into an i386 machine, and the module is i386 and installed in /usr/lib/dri. This configuration may cause breakage. I'm afraid the module has to be fixed, even if it's a proprietary module. -- ~ Andres I looked into this some more. NVIDIA's vdpau driver doesn't show a problem with the modules being installed in /usr/lib/x86_64-linux-gnu/vdpau. vainfo is working fine for me (after fixing some issues with the vdpau-va-driver which I just uploaded). $ vainfo libva: VA-API version 0.32.0 Xlib: extension XFree86-DRI missing on display :0. libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so libva: va_openDriver() returns 0 vainfo: VA-API version: 0.32 (libva 1.0.15) vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.3 vainfo: Supported profile and entrypoints VAProfileMPEG2Simple: VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointVLD VAProfileH264High : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main: VAEntrypointVLD VAProfileVC1Advanced: VAEntrypointVLD Also, I checked the code that sets the module directory for both libvdpau and libva. Only one path is set for both libraries and it is based off of $libdir variable from their build systems. With multiarch, each library sets the module path to /usr/lib/triplet/*. With this information, I believe the fglrx driver should be fixed. -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#664700: libva1: please search dri module in /usr/lib/{triplet/, }dri
Package: libva1 Version: 1.0.15-4 Severity: normal Hi, please use a search path for the DRI modules that contains both /usr/lib/triplet/dri /usr/lib/dri While we can (hopefully) fix the Debian packages to ship the files in the multiarch locations, the multiarch move breaks any third-party (probably proprietary) software/installer/... that is not multiarch aware. Therefore plugins should be searched in both locations. So far the following problems have been reported: xvba-va: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664487 fglrx + vainfo: $ vainfo libva: VA-API version 0.32.0 Xlib: extension XFree86-DRI missing on display :0. libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/fglrx_drv_video.so libva: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit I'm not sure if I can move dri/fglrx_drv_video.so around - it is loaded from the fglrx driver (a non-free blob) using the hardcoded path /usr/lib/dri ... (and the last time I tried to use symlinks (although in a different context) the fglrx blob used lstat() and complained about world writable files ...) Andreas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#664700: libva1: please search dri module in /usr/lib/{triplet/, }dri
On Mon, Mar 19, 2012 at 8:38 PM, Andreas Beckmann deb...@abeckmann.de wrote: Package: libva1 Version: 1.0.15-4 Severity: normal Hi, please use a search path for the DRI modules that contains both /usr/lib/triplet/dri /usr/lib/dri While we can (hopefully) fix the Debian packages to ship the files in the multiarch locations, the multiarch move breaks any third-party (probably proprietary) software/installer/... that is not multiarch aware. Therefore plugins should be searched in both locations. So far the following problems have been reported: xvba-va: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664487 fglrx + vainfo: $ vainfo libva: VA-API version 0.32.0 Xlib: extension XFree86-DRI missing on display :0. libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/fglrx_drv_video.so libva: va_openDriver() returns -1 vaInitialize failed with error code -1 (unknown libva error),exit I'm not sure if I can move dri/fglrx_drv_video.so around - it is loaded from the fglrx driver (a non-free blob) using the hardcoded path /usr/lib/dri ... (and the last time I tried to use symlinks (although in a different context) the fglrx blob used lstat() and complained about world writable files ...) Andreas ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers I don't believe modules should be allowed to load from /usr/lib/dri in a multiarch library. Suppose the amd64 library package is loaded into an i386 machine, and the module is i386 and installed in /usr/lib/dri. This configuration may cause breakage. I'm afraid the module has to be fixed, even if it's a proprietary module. -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
