Source: xserver-xorg-video-ivtvdev
Version: 1.1.2-2
Severity: serious
Tags: ftbfs sid trixie
Justification: fails to build from source (but built successfully in the past)
Hi,
xserver-xorg-video-ivtvdev started to FTBFS when GCC 14 was made the
default compiler:
Making all in src
make[3]: Enteri
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 i
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
-DDISTRIBUTION_CONTACT=\"https://salsa.debia
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 SPV_INTE
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
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
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 botto
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 oth
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
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
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.
>F
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 symlinks:
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
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&suite=uns
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 wo
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: Nvidia-In
; urgency=medium
+
+ * Non-maintainer upload.
+ * Rebuild for stretch.
+
+ -- Andreas Beckmann 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 → libxkbcommon-dev
+(closes
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 vir
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
reas
>From 3e268f4e30daf6fc78ba93f0ed134103da40006d Mon Sep 17 00:00:00 2001
From: Andreas Beckmann
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 ++
debian/ru
Sep 17 00:00:00 2001
From: Andreas Beckmann
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/changelog b/debian/changelog
in
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 src:
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 an
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
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
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):
https://www.debian.org/doc/debian-polic
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:
/usr/s
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] ha
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
make
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
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.
>>
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
${DEB_HO
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 t
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-*
On 2014-11-16 09:13, Janusz S. Bien wrote:
> Quote/Cytat - Andreas Beckmann (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 package
On 2014-11-15 21:53, Janusz S. Bien wrote:
> Quote/Cytat - Andreas Beckmann (sob, 15 lis 2014,
>> /usr/share/bug/libgl1-nvidia-glx/script 3>nvidia.log
>
> Enclosed.
Thanks. Does not look like something is broken (except for having the
nvidia packages installed manually on a sy
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)
P
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 UN
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 tr
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
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
upstrea
@@ -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 Sun, 18 Aug 2013 10:50:28 +0200
+
mesa (9.1.6-2) unstable; urgen
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 glx-divers
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: http://lists.debian.o
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 a
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 ne
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
>
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 work
Beckmann
Resent-To: debian-bugs-d...@lists.debian.org
Resent-CC: 640...@bugs.debian.org,
pkg-nvidia-de...@lists.alioth.debian.org, Debian Release Team
Date: Wed, 26 Sep 2012 14:06:33 +0200
From: Andreas Beckmann
Reply-To: Andreas Beckmann , 688...@bugs.debian.org
To: Debian Bug Tracking System
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: http://lists.debian
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 u
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)
/us
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 maintai
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 imp
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 --> xorg-video-
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
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
---
debian
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
---
debian/libgl1-mesa
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
>commit aee32cbeae3e76bab261fc02fa5e608b71360439
>Author: Cyril Brulebois
>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
.git/gbp.conf so tha
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 UNSU
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 xorg-
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 handl
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
http://lists.x.org/archives/xorg-d
32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=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
Date: Mon, 5 Sep 2011 12:28:14 +0200
Subject: [PATCH] build for multiarch
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
...
>
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 pr
ing 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:
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"
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
[adding pkg-fglrx-devel@ to the discussion]
On 2011-07-22 21:12, Cyril Brulebois wrote:
> Julien Cristau (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 countless bug
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.
Unfort
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 alternative
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 m
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 crea
[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* (r
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 we
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
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
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)
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.s
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 bot
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 Xorg
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.c
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 t
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 +, ... 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 "X
86 matches
Mail list logo
