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-maintain...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
