Bug#1069405: x11-apps: FTBFS on arm64: configure: error: Package requirements (x11-xcb xcb-present >= 1.9 xcb-xfixes xcb-damage) were not met

Followup-For: Bug #1069405 Control: retitle -1 x11-apps: FTBFS with libxcb 1.17: Package requirements (x11-xcb xcb-present >= 1.9 xcb-xfixes xcb-damage) were not met Control: block -1 with 1069408 This happens on all architectures and is probably caused by the missing libxcb-dri3-dev dependency

Bug#1067012: renderdoc: FTBFS with glslang 14: fatal error: glslang/Include/Types.h: No such file or directory

Source: renderdoc Version: 1.27+dfsg-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) renderdoc FTBFS with glslang 14 in sid due to a missing header: [184/311] /usr/bin/c++ -DAMD_EXTENSIONS

Bug#1065551: spirv-headers: please update to commit b73e168ca5e123dcf3dea8a34b19a5130f421ae1 or later

Source: spirv-headers Version: 1.6.1+1.3.275.0-1 Severity: wishlist Hi, spirv-llvm-translator upstream just had in its llvm_release_180 branch a commit (d970c9126c033ebcbb7187bc705eae2e54726b74) pushed that bumps the header dependency to b73e168ca5e123dcf3dea8a34b19a5130f421ae1 for using

Bug#1053796: spirv-headers: please update to sdk-1.3.261.0 or later

Package: spirv-headers Version: 1.6.1+1.3.250.0-1 Severity: serious Hi, please update spirv-headers to a newer release. For creating src:spirv-llvm-translator-17 we need at least commit 9b527c0fb60124936d0906d44803bec51a0200fb aka sdk-1.3.261.0~10^2~1 Thanks Andreas

Bug#1040056: [Pkg-opencl-devel] Bug#1040056: spirv-tools breaks spirv-llvm-translator-15 autopkgtest: exactly one input file must be specified.

Does this issue affect spirv-llvm-translator-16, too? I tried to trigger the corresponding tests (which succeeded), but I'm not sure if it really tested the correct setup. Andreas

Bug#970556: vulkan-validationlayers-dev: ships /usr/include/xxhash.h already provided by libxxhash-dev

Package: vulkan-validationlayers-dev Version: 1.2.148.0-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files. >From the attached log (scroll to the

Bug#970134: libweston-9-dev: missing (unversioned) Breaks+Replaces: libweston-8-dev

Package: libweston-9-dev Version: 9.0.0-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite

Bug#943664: xserver-xorg-video-radeon 19.1 (ppc64) crash at startup: undefined symbol: exaGetPixmapDriverPrivate

Control: severity -1 important On Sun, 27 Oct 2019 16:59:23 +0100 "Ralf P." wrote: > Package: xserver-xorg-video-radeon > Version: 1:19.0.1-1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > >on the ppc64 architecture the package Downgrading the severity

Bug#947392: mesa-common-dev: missing Depends: libgl-dev (>= 1.3)

Package: mesa-common-dev Version: 19.3.0~rc6-1 Severity: serious mesa-common-dev needs to depend on libgl-dev after the headers were moved. The missing headers cause e.g. a FTBFS in pycuda. Andreas

Bug#929526: xfonts-scalable: fails to install in lenny/i386: fmt: invalid width: `63482'

Package: xfonts-scalable Version: 1:1.0.0-6 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed to install. As per definition of the release team this makes the package too buggy for a release, thus the severity.

Bug#926857: mesa-vdpau-drivers: broken symlink: /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_gallium.so -> libvdpau_gallium.so.1.0.0

Package: mesa-vdpau-drivers Version: 18.3.6-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink. >From the attached log (scroll to the bottom...): 0m23.0s ERROR: FAIL: Broken

Bug#903929: libglx-mesa0: please add Breaks: glx-diversions (<< 0.8.4~)

Package: libglx-mesa0 Version: 18.1.4-1 Severity: normal Hi, please add a Breaks: glx-diversions (<< 0.8.4~) to libglx-mesa0. The older versions did not handle libGLX_indirect.so.0 which could lead to the nvidia driver removing the libGLX_indirect.so.0 symlink. Thanks Andreas

Bug#896602: libglvnd: FTBFS on many architectures

Source: libglvnd Version: 1.0.0+git20180308-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Hi, the snapshot uploaded to sid FTBFS on many architectures where it previously built. https://buildd.debian.org/status/package.php?p=libglvnd=unstable

Bug#884717: libgl1: consider using a version that is higher than 1.2.0 for the libGL.so.1.0.0 filename

Control: tag -1 fixed-upstream On 2018-01-25 17:22, Timo Aaltonen wrote: >> Also give me a notice before uploading such a change s.t. I can adjust >> glx-diversions accordingly and you can bump the Breaks against the >> glx-diversions versions not knowing about the new filename. >> >> It may be

Bug#884717: libgl1: consider using a version that is higher than 1.2.0 for the libGL.so.1.0.0 filename

Package: libgl1 Version: 1.0.0-1 Severity: normal Hi, if the system got messed up by some proprietary installer, it may be well possible that some cruft libGL.so.1.X.Y outside the control of dpkg is left on the system and takes precedence over libGL.so.1.0.0 Like in #879041: libglvnd0:

Bug#872874: libxkbcommon-x11-dev: Missing depends on libxkbcommon-dev

; urgency=medium + + * Non-maintainer upload. + * Rebuild for stretch. + + -- Andreas Beckmann <a...@debian.org> Mon, 27 Nov 2017 17:50:43 +0100 + +libxkbcommon (0.7.1-2) unstable; urgency=medium + + * Remove Cyril from Uploaders. + * Add missing dependency libxkbcommon-x11-dev → libxkbcomm

Bug#882682: libglvnd: make symbols files generate versioned dependencies

Source: libglvnd Version: 1.0.0-1 Severity: wishlist Hi, I'd like to see all the .symbols files in libglvnd generating versioned dependencies. That will be achieved by setting all the symbol versions to something higher than 0. This would mean: * dependencies are no longer satisfiable by the

Bug#879041: libglvnd0: Nvidia-Installer 384.90: "An incomplete installation of libglvnd was found."

On Wed, 18 Oct 2017 19:07:41 +0200 Dirk Lehmann wrote: > During installing the Nvidia Geforce driver version 384.90 the > following error occurs: Please use the 384.xx nvidia-graphics-drivers packages from experimental. Andreas

Bug#876084: [libglvnd-dev] Can't upgrade libglvnd-dev anymore

rom 3e268f4e30daf6fc78ba93f0ed134103da40006d Mon Sep 17 00:00:00 2001 From: Andreas Beckmann <a...@debian.org> Date: Sat, 25 Nov 2017 16:02:17 + Subject: [PATCH 3/4] bug-control: report whether the proprietary nvidia driver is installed --- debian/bug-control | 1 + debian/changelog | 2 +

Bug#870445: libglvnd: FTBFS on non-Linux: u_execmem_free undefined

Sep 17 00:00:00 2001 From: Andreas Beckmann <a...@debian.org> Date: Sat, 25 Nov 2017 15:00:32 + Subject: [PATCH 1/2] use source format 3.0 (quilt) --- debian/changelog | 6 ++ debian/source/format | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/debian/ch

Bug#876100: fixed in nvidia-graphics-drivers 375.82-4

On 20.09.2017 20:39, Jiri Palecek wrote: >>     * Prevent mixing libgl1-nvidia-glx with libgl1-nvidia-glvnd-glx. >>     * Use versioned Provides/Breaks/Replaces on the packages also >> built from >>   src:libglvnd s.t. they cannot be satisfied by virtual packages >> provided >>   from

Bug#876100: libglvnd-dev: libglvnd-dev not coinstallable with nvidia packages

On 18.09.2017 15:03, Jiri Palecek wrote: > libglvnd depends on many OpenGL related packages like libgl1, specified > by concrete version. This means those dependencies can't be satisfied > with virtual packages, ie. nvidia packages providing libgl1. However, > those nvidia packages conflict with

Bug#870686: libglvnd: not ready for testing, yet

Source: libglvnd Version: 0.2.999+git20170802-2 Severity: serious Since the mesa packaging hasn't switched to glvnd, yet, there are file conflicts between several packages from src:mesa and src:libglvnd. So let's keep libglvnd out of testing until this transition progresses. Andreas

Bug#859929: x11-common: unowned files after upgrade from jessie to stretch and purge: /etc/X11/Xwrapper.config

On 2017-04-23 11:45, Julien Cristau wrote: > On Tue, Apr 11, 2017 at 22:20:59 -0400, G. Branden Robinson wrote: > >> At 2017-04-09T13:34:44+0200, Andreas Beckmann wrote: >>> 1m37.2s INFO: Warning: Package purging left files on system: >>> /etc/X11/Xwrapper.confi

Bug#859929: x11-common: unowned files after upgrade from jessie to stretch and purge: /etc/X11/Xwrapper.config

Package: x11-common Version: 1:7.7+18 Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package left unowned files on the system after purge, which is a violation of policy 6.8 (or 10.8):

Bug#858469: xorg-docs: broken symlink: /usr/share/X11/doc -> ../doc/xorg-docs/docs

Package: xorg-docs Version: 1:1.7.1-1 Severity: normal User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships (or creates) a broken symlink. >From the attached log (scroll to the bottom...): 0m25.2s ERROR: FAIL: Broken symlinks:

Bug#610693: Processed: reassign 446207 to src:tracker, reassign 610693 to src:xserver-xorg-video-openchrome ...

On 2016-07-24 10:33, Julien Cristau wrote: > On Sat, Jul 23, 2016 at 21:45:11 +, Debian Bug Tracking System wrote: > >>> reassign 610693 src:xserver-xorg-video-openchrome 1:0.2.904+svn842-2 >> Bug #610693 [xserver-xorg-video-via] xserver-xorg-video-via: >> KM400/KN400/P4M800 [S3 UniChrome]

Bug#814631: xserver-xorg-video-siliconmotion: FTBFS: src/smi.h:224:5: error: unknown type name 'IOADDRESS'

Source: xserver-xorg-video-siliconmotion Version: 1:1.7.8-1 Severity: serious Hi, xserver-xorg-video-siliconmotion FTBFS in sid/amd64 (and probably other architectures as well), might be incompatible with recent Xorg Xserver: [...] dh_auto_build -O--builddirectory=build/ make -j1

Bug#594269: Please reenable PCI_TXT_IDS_DIR for third-party drivers

Followup-For: Bug #594269 nvidia now implemented a different way to automatically integrate with Xorg via DRM (without needing an xorg.conf specifying a specific Driver), so this feature request is no longer relevant from my side. Andreas

Re: [Pkg-opencl-devel] New libclc snapshot

On 2015-09-03 14:57, Timo Aaltonen wrote: > On 02.09.2015 20:35, Andreas Boll wrote: >> Hi all, >> >> for mesa-opencl-icd we need a newer libclc snapshot which is >> compatible with LLVM-3.7, since we are upgrading mesa from LLVM-3.5 to >> 3.7. >> I'm volunteering to prepare such a new snapshot.

Bug#792223: mesa-utils: looking for a way to have glxinfo (end friends) installed for both amd64 and i386 at the same time

Package: mesa-utils Version: 8.2.0-1 Severity: wishlist For debugging 32-bit GL issues on a amd64 host it may be useful to have access to glxinfo for amd64 and for i386 at the same time. One possible solution could be to ship the binaries renamed to ${glxbinary}-${DEB_HOST_MULTIARCH} (or

Bug#769191: Bug#769072: , #769191, #770588: nvidia-opencl-icd breaking non-nvidia systems

On 2014-11-24 22:47, Rebecca N. Palmer wrote: First of all, many thanks for analyzing the problem and keeping track of the many duplicates! (Should we merge these bugs? Also, #767803 looks like another instance of this, though it doesn't have the apt log to confirm it yet) and perhaps move

Bug#769191: Bug#769072: #769191: nvidia-opencl-icd breaking non-nvidia systems

On 2014-11-23 00:30, Rebecca N. Palmer wrote: I think the trigger is nvidia-opencl-icd adding a new dependency on libcuda1 (changelog: Add libcuda1 dependency to libraries that seem to be capable of doing dlopen(libcuda.so) or dlopen(libcuda.so.1).), which pulls in the rest of nvidia-* as

Re: Bug#769072: gnome-shell: GNOME Shell crashing with Oh no, something went wrong

On 2014-11-16 09:13, Janusz S. Bien wrote: Quote/Cytat - Andreas Beckmann a...@debian.org (nie, 16 lis 2014, (I would guess neither nvidia-driver nor xserver-xorg-video-nvidia). I was right :-) Although some of them has been installed manually, for the first time the nvidia packages just

Re: Bug#769072: gnome-shell: GNOME Shell crashing with Oh no, something went wrong

On 2014-11-15 14:13, Julien Cristau wrote: Looks like nvidia took over libGL but not the server-side libglx.so. That can't possibly work; can the nvidia packages not do that? It should ... (not diverting, but placing its libglx.so in the front of the search path, controlled by alternatives)

Re: Bug#769072: gnome-shell: GNOME Shell crashing with Oh no, something went wrong

On 2014-11-15 21:53, Janusz S. Bien wrote: Quote/Cytat - Andreas Beckmann a...@debian.org (sob, 15 lis 2014, /usr/share/bug/libgl1-nvidia-glx/script 3nvidia.log Enclosed. Thanks. Does not look like something is broken (except for having the nvidia packages installed manually on a system

Bug#765967: [libvdpau1] mpeg 1 video are decoded too bad

On 2014-10-19 21:36, Vincent Bernat wrote: Nope, its string OpenGL/VAAPI/libswscale backend for VDPAU. I suppose that G3DVL means Gallium 3D Video L(ayer). So, this is more likely mesa-vdpau-drivers. OK, I'll add a bug-script to libvdpau1 to list available drivers ... Andreas -- To

Re: [Pkg-fglrx-devel] Heads up: xorg-server 1.15 soon in sid

On 2014-01-28 23:39, Julien Cristau wrote: On the closed drivers front, I assume nvidia's non-legacy driver will be fine, and fglrx will lag by a few weeks/months as usual? I just uploaded fglrx-driver 14.1~beta to sid that adds support for Xserver 1.15, so that one should be OK, too. (The

Re: Heads up: xorg-server 1.15 soon in sid

On 2014-01-28 23:39, Julien Cristau wrote: On the closed drivers front, I assume nvidia's non-legacy driver will be fine, This time nvidia was quick: all (legacy) drivers currently in jessie already support 1.15. and fglrx will lag by a few weeks/months as usual? Probably ... What is the X

Re: heads up: xserver 1.14 to unstable

On 2013-09-17 21:27, Julien Cristau wrote: I notice that fglrx-driver, fglrx-legacy-driver and nvidia-graphics-drivers-legacy-96xx in sid don't declare support for the new ABI. Is there a newer version of those? nvidia-graphics-drivers-legacy-96xx probably won't see any updates from upstream,

Bug#720069: libgl1-mesa-glx: add Breaks: glx-diversions ( 0.4)

Package: libgl1-mesa-glx Version: 9.1.6-3 Severity: normal Tags: patch Hi, please add a Breaks: glx-diversions ( 0.4) to libgl1-mesa-glx to ensure clean upgrades from MESA 8 to MESA 9 if the proprietary drivers are being used. MESA 9 ships libGL.so.1.2.0 which needs to be diverted by

Bug#720069: [PATCH] libgl1-mesa-glx needs Breaks: glx-diversions ( 0.4)

@@ -1,3 +1,10 @@ +mesa (9.1.6-3) UNRELEASED; urgency=low + + * libgl1-mesa-glx: Add Breaks: glx-diversions ( 0.4) because the old +versions were not aware of libGL.so.1.2.0. (Closes: #720069) + + -- Andreas Beckmann a...@debian.org Sun, 18 Aug 2013 10:50:28 +0200 + mesa (9.1.6-2) unstable

Bug#720026: libxfont-dev: arch-dependent file in Multi-Arch: same package

Package: libxfont-dev Version: 1:1.4.6-1 Severity: important User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch libxfont-dev is marked as Multi-Arch: same, but the following file is architecture-dependent: /usr/share/doc/libxfont-dev/fontlib.html An example diff between i386

Bug#720026: libxfont-dev: arch-dependent file in Multi-Arch: same package

There is also usr/lib/debug/usr/lib/libXfont.so.1.4.1 in libxfont1-dbg which is different on all architectures. Andreas -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:

Bug#706114: xfonts-utils: insufficient zlib1g dependency

On 2013-04-25 10:39, Guillem Jover wrote: On Wed, 2013-04-24 at 22:06:55 -0400, Michael Gilbert wrote: So the dependencies are correct. The only problem is due to gsfonts-x11 postinst's script calling: update-fonts-dir → mkfontdir → mkfontscale While the new xfonts-utils package

Bug#640499: libxvmc: please add multiarch support

On 2012-12-07 00:43, Carlos Alberto Lopez Perez wrote: MultiArch support is a release goal, and the fix for this bug is clearly not invasive nor big: $ curl -s 'http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=0001-build-for-multiarch.patch;att=1;bug=640499' | diffstat 5

Bug#640499: libxvmc: please add multiarch support

On 2012-10-15 21:13, Hussain AlMutawa wrote: Hi, Just reporting. I am using the proprietary nvidia driver on debian sid. Androids Emulator requires the 32 bit version of openGL. Which can not be installed because of this bug. use the nvidia driver packages from unstable which has a

Bug#640499: Bug#688861: freeze exception: libxvmc/1.0.7-1.1 - adding a libxvmc1-i386:i386 package

In case anyone is interested in a .dsc: http://mentors.debian.net/debian/pool/main/libx/libxvmc/libxvmc_1.0.7-1.1.dsc Andreas -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:

Bug#640499: Fwd: Bug#688861: freeze exception: libxvmc/1.0.7-1.1 - adding a libxvmc1-i386:i386 package

Beckmann deb...@abeckmann.de Resent-To: debian-bugs-d...@lists.debian.org Resent-CC: 640...@bugs.debian.org, pkg-nvidia-de...@lists.alioth.debian.org, Debian Release Team debian-rele...@lists.debian.org Date: Wed, 26 Sep 2012 14:06:33 +0200 From: Andreas Beckmann deb...@abeckmann.de Reply-To: Andreas

Bug#640499: libxvmc: please add multiarch support

On Tuesday, 14. August 2012 11:35:21 Ralf Jung wrote: As it turned out, the conffile issue is actually a bug in dpkg [1]. In theory (and once dpkg is fixed), it is perfectly fine to have a conffile in an MA: same package, as long as the content is the same for all architectures. Have the

Bug#682939: xfonts-utils, xfonts-encodings, debhelper: installing xfonts-tipa removes /usr/share/fonts/X11/encodings/encodings.dir

Package: xfonts-utils,xfonts-encodings,debhelper Severity: important User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed the xfonts-tipa packages removes /usr/share/fonts/X11/encodings/encodings.dir which is owned by xfonts-encodings. xfonts-tipa

Bug#682939: xfonts-utils, xfonts-encodings, debhelper: installing xfonts-tipa removes /usr/share/fonts/X11/encodings/encodings.dir

On 2012-07-27 13:22, Daniele Tricoli wrote: piuparts seems to be ok now (logfile attached). You can't rerun the test with the released piuparts, only with the version from git. But it's easy to test without piuparts: install the package in a clean minimal chroot (e.g. pbuilder, cowbuilder)

Bug#674563: mesa: install libGL.so* into $libdir/mesa, add links to $libdir

Source: mesa Version: 7.11.2-1 Severity: wishlist Tags: patch Hi, this is in response to a thread started here: http://lists.debian.org/debian-x/2011/07/msg00292.html and later continued here: http://lists.debian.org/debian-x/2011/10/msg00137.html In order to simplify managing alternative GL

video drivers in experimental that depend on outdated video-abi 11

Hi, there are two xorg video drivers in experimental that were built against video-abi versions older than 11: xserver-xorg-video-v4l -- xorg-video-abi-8.0 this package was removed from unstable in #612191, but the copy in experimental was probably missed xserver-xorg-video-r128 --

Re: New X stack backport?

On 2012-01-12 12:27, Cyril Brulebois wrote: I'm still not too sure whether to replace the backported X stack entirely or whether to publish a squeeze-backports repository on my own website with source + binaries for i386 and amd64, so that people can try 1.10 from squeeze-backports, or 1.11

[PATCH] install libEGL* and libGLES* into $libdir/mesa

alternative from NVIDIA exists). The links in $libdir will be managed by update-alternatives later on and therefore it is necessary to move the real files (lib*.so.[12].*) out of $libdir, otherwise ldconfig will happily modify the lib*.so.[12] SONAME links. Signed-off-by: Andreas Beckmann deb

README.source and documentation updates (was: Re: mesa: Changes to 'debian-unstable')

commit aee32cbeae3e76bab261fc02fa5e608b71360439 Author: Cyril Brulebois k...@debian.org Date: Sat Sep 24 20:32:27 2011 +0200 Document the symlink dance in README.source. Thanks! This was giving me a headache previously. Eventually this can be extended by an example how to set up

Re: [RFC] proposal for reorganizing the MESA libraries to simplify replacing them with vendor implementations

Hi all, let's pick up this discussion again. On 2011-07-25 19:03, Julien Cristau wrote: On Mon, Jul 25, 2011 at 18:57:17 +0200, Andreas Beckmann wrote: What is the correct approach to do alternatives of libraries in Multi-Arch: yes packages? * a separate alternative for each architecture

[PATCH] install libGL.so* into $libdir/mesa, add links to $libdir

and AMD exist). The links in $libdir will be managed by update-alternatives later on and therefore it is necessary to move the real file (libGL.so.1.*) out of $libdir, otherwise ldconfig will happily modify the libGL.so.1 SONAME link. Signed-off-by: Andreas Beckmann deb...@abeckmann.de

Bug#641344: rendering errors and crashes with nvidia driver and xserver 1.11 due to wrong symbols in libwfb.so

On 2011-09-20 14:20, Cyril Brulebois wrote: Thanks for the tests, folks. We're waiting for the patch to get merged upstream before uploading a fixed package. No need to report more xserver 1.11.1 is out: http://cgit.freedesktop.org/xorg/xserver/log/?h=server-1.11-branch Andreas -- To

Bug#641344: Bug#641413: X crashes

On 2011-09-16 13:47, Martin Stigge wrote: Hm, as Tony in #641344 points out, the desktop reacts quite slowly in certain situations with 1.11.0, e.g., switching tabs in pidgin or similar. Downgraded X to 1.10.4 again where this is not the case. That is an independent issue and should be handled

Bug#641344: rendering errors and crashes with nvidia driver and xserver 1.11 due to wrong symbols in libwfb.so

subscribe 641344 retitle 641344 rendering errors and crashes with nvidia driver and xserver 1.11 due to wrong symbols in libwfb.so reassign 641413 xserver-xorg-core unblock 641413 by 641344 forcemerge 641344 641413 severity 641344 grave thanks I verified that the attached patch works with

Re: Bug#641344: [nvidia-glx] Graphics errors after upgrading to xserver with abi 11

reassign 641344 xserver-xorg-core 2:1.11.0-1 tag 641344 - moreinfo + patch affects 641344 src:nvidia-graphics-drivers xserver-xorg-video-nvidia retitle 641344 rendering errors with nvidia driver and xserver 1.11 due to wrong symbols in libwfb.so forwarded 641344

Bug#640499: libxvmc: please add multiarch support

=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash From 072c13c64562eafeff15b2c684fa056c3353d592 Mon Sep 17 00:00:00 2001 From: Andreas Beckmann deb...@abeckmann.de Date: Mon, 5 Sep 2011 12:28:14 +0200 Subject: [PATCH] build for multiarch --- debian/changelog |1 + debian

Re: Xorg module searchpath override directory

to the source code and my tests, the linux subdirectory is always searched first for modules and therefore suitable to install override modules. Andreas On 2011-08-10 23:08, Andreas Beckmann wrote: On 2011-07-25 19:03, Julien Cristau wrote: On Mon, Jul 25, 2011 at 18:57:17 +0200, Andreas Beckmann wrote

Bug#638965: xserver-xorg-core: add override directory that is prepended to the module search path

Package: xserver-xorg-core Version: 2:1.7.7-13 Severity: wishlist Hi, as this was discussed on the mailing list before, see e.g. [1] http://lists.debian.org/debian-x/2011/08/msg00157.html [2] http://lists.debian.org/debian-x/2011/08/msg00364.html there is need for an override directory that is

Re: Xorg module searchpath override directory

On 2011-08-23 11:33, Julien Cristau wrote: On Tue, Aug 23, 2011 at 11:32:22 +0200, Andreas Beckmann wrote: Are there any objections to installing the alternative slave link for vendor implemntations of libglx.so as /usr/lib/xorg/modules/linux/libglx.so ... I'd prefer an explicit override

Xorg module searchpath override directory (was: Re: [RFC] proposal for reorganizing the MESA libraries to simplify replacing them with vendor implementations)

On 2011-07-25 19:03, Julien Cristau wrote: On Mon, Jul 25, 2011 at 18:57:17 +0200, Andreas Beckmann wrote: libGL.so.1 is not the only file to be diverted, libglx.so is being replaced by the vendors drivers, too. Or is there some way of search path magic that would allow to place the higher

Re: [RFC] proposal for reorganizing the MESA libraries to simplify replacing them with vendor implementations

On 2011-08-04 11:22, Michel Dänzer wrote: On Mon, 2011-07-25 at 19:03 +0200, Julien Cristau wrote: On Mon, Jul 25, 2011 at 18:57:17 +0200, Andreas Beckmann wrote: libGL.so.1 is not the only file to be diverted, libglx.so is being replaced by the vendors drivers, too. Or is there some way

Re: [RFC] proposal for reorganizing the MESA libraries to simplify replacing them with vendor implementations

[adding pkg-fglrx-devel@ to the discussion] On 2011-07-22 21:12, Cyril Brulebois wrote: Julien Cristau jcris...@debian.org (22/07/2011): So in principle I dislike the idea of making the mesa packages messier to make the closed driver packages' life easier. One thing that's been a source of

[RFC] proposal for reorganizing the MESA libraries to simplify replacing them with vendor implementations

Hi, currently there are multiple vendor implementations for libGL.so.1/libglx.so and soon there will be vendor implementations for libEGL.so.1/libGLES*.so.*, too. The GL part is currently being handled by diversions and alternatives, and the upcoming EGL part is planning to do this similar.

Re: xorg configuration for the non-free nvidia driver

On 2011-07-11 19:33, Julien Cristau wrote: I very much dislike the idea of using alternatives for configuration files. I understand the concerns regarding alternatives and configuration files, especially if update-alternatives is buggy when it comes to files sitting in the place of alternatives

Re: xorg configuration for the non-free nvidia driver

On 2011-07-08 20:19, Julien Cristau wrote: On Fri, Jul 8, 2011 at 10:47:50 +0200, Andreas Beckmann wrote: since the proprietary nvidia driver does not work with Xorg autoconfiguration, an xorg.conf is needed to enable it. I'm planning to use debconf for creating a xorg.conf.d snippet

Re: xorg configuration for the non-free nvidia driver

On 2011-07-11 18:26, Russ Allbery wrote: Combining configuration files with slave alternatives makes me nervous. I'm not sure what would happen if the system administrator broke the symlink (via an editor action, for example) while the alternatives system still thinks that it's active; we

xorg configuration for the non-free nvidia driver

[resending to debian-x@ instead of just kibi@] Dear X Team, since the proprietary nvidia driver does not work with Xorg autoconfiguration, an xorg.conf is needed to enable it. I'm planning to use debconf for creating a xorg.conf.d snippet on the first installation of xserver-xorg-video-nvidia*

Bug#632886: libgl1-mesa-swx11: drop Conflicts: nvidia-glx

Package: libgl1-mesa-swx11 Version: 7.10.3-3 Severity: wishlist Hi KiBi, libgl1-mesa-swx11 currently has a Conflicts: nvidia-glx entry. While this is correct it's not nearly sufficient (the nvidia-glx package has been split and reorganized, there are legacy packages, too, and there is fglrx as

Bug#630710: please add Breaks: libgl1-nvidia-alternatives (= 275.09.07-1)

Package: libgl1-mesa-glx Version: 7.10.2-4 Severity: normal Hi KiBi, could you add Breaks: libgl1-nvidia-alternatives (= 275.09.07-1) to libgl1-mesa-glx? (Best before the multiarch change moves to testing). The multiarch move of MESA breaks current diversion handling (many bugreports). I'm

Bug#629823: xterm and nvidia

On 2011-06-13 12:04, Stefano Callegari wrote: I have tried more terminal: aterm, eterm and mrxvt. All have the same problem like xterm. So is it a kde4 problem, maybe kwin? Have you tried creating a new user and trying again as that user, so that all KDE user settings get freshly initialized?

Re: Bug#629823: xterm and nvidia

reassign 629823 xterm 270-1 retitle 629823 can't un-maximize xterm thanks On 2011-06-09 11:47, Stefano Callegari wrote: ... So when konsole is ok and xterm no, I thought that miss something for xterm on new relase of nvidia driver. But today I have tried with more settings (theme, border)

Re: Diversions

On 2011-02-16 18:53, Cyril Brulebois wrote: Hi guys, could you please tell us which files you divert in (all of) your nvidia packages? I'd like to get those reported in the bug script, so either file lists or patterns would be appreciated. We divert /usr/lib/libGL.so* /usr/lib32/libGL.so*

Re: Bug#610021/#610022: fglrx-glx fails to install in parallel with nvidia-glx

On Sunday, 16. January 2011 20:24:17 Patrick Matthäi wrote: Am 16.01.2011 14:49, schrieb Ronny Standtke: reopen 610022 Sorry, not possible This is not true, it is definitely possible. Several parties have already developed solutions for this problem, see the following both messages of

Autoconfiguring third-party Xorg drivers

tags 586502 - patch clone 586502 -1 retitle -1 Please reenable PCI_TXT_IDS_DIR for third-party drivers submitter -1 ! severity -1 wishlist reassign -1 xserver-xorg-core 2:1.7.7-4 thanks Dear Debian X Strike Force, please reenable the PCI_TXT_IDS_DIR feature of Xorg. Even if it is not used by

Bug#466526: xorg starts with an oversized xrandr screen

Hi Brice, Brice Goglin wrote: Andreas Beckmann wrote: Package: xorg Version: 1:7.3+10 Severity: normal Hi, if xorg detects a second monitor connected, it starts up with a virtual screen larger than what I set in xorg.conf. (X700, laptop 1680x1050 right-of flat panel @ vga port 1600x1200

Bug#466526: more on oversized xrandr screen

When I increase the size of the virtual screen to 3360x1200, it uses this size at startup (as before, but it's no longer 'oversized') and there is no distorted image at the left and right border. There were probably 80 pixel overlapping at both sides before. Andreas -- To UNSUBSCRIBE, email

Bug#460269: xkb-data: layout=us + variant=nodeadkeys breaks Ctrl+F1 ...

Package: xkb-data Version: 1.0~cvs.20070916-1 Severity: normal Hi, when I recently switched the x keyboard config from layout=de to layout=us, this broke Ctrl+F1, ... i.e. switching to the ttys which didn't react at all. I checked a bit further and found this to be caused by the Option