Bug#1078229: xserver-xorg-video-ivtvdev: FTBFS with GCC 14: error: assignment ... from incompatible pointer type ...

[Andreas Beckmann]

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]: Entering directory '/build/xserver-xorg-video-ivtvdev-1.1.2/build/src'
/bin/bash ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../../src -I..-I/usr/include/xorg -fvisibility=hidden 
-I/usr/include/pixman-1 -I/usr/include/X11/dri -I/usr/include/libdrm   -g -O2 
-c -o ivtv.lo ../../src/ivtv.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -I/usr/include/xorg 
-fvisibility=hidden -I/usr/include/pixman-1 -I/usr/include/X11/dri 
-I/usr/include/libdrm -g -O2 -c ../../src/ivtv.c  -fPIC -DPIC -o .libs/ivtv.o
../../src/ivtv.c: In function 'IVTVDevProbe':
../../src/ivtv.c:350:13: warning: assignment discards 'const' qualifier from 
pointer target type [-Wdiscarded-qualifiers]
  350 | dev = xf86FindOptionValue(devSections[i]->options, "fbdev");
  | ^
../../src/ivtv.c:373:26: error: assignment to 'ModeStatus (*)(struct 
_ScrnInfoRec *, struct _DisplayModeRec *, Bool,  int)' {aka 'ModeStatus 
(*)(struct _ScrnInfoRec *, struct _DisplayModeRec *, int,  int)'} from 
incompatible pointer type 'int (*)(int,  struct _DisplayModeRec *, Bool,  int)' 
{aka 'int (*)(int,  struct _DisplayModeRec *, int,  int)'} 
[-Wincompatible-pointer-types]
  373 | pScrn->ValidMode = ivtvHWValidMode;
  |  ^
../../src/ivtv.c: In function 'IVTVDevPreInit':
../../src/ivtv.c:423:13: warning: passing argument 3 of 'ivtvHWInit' discards 
'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
  423 | xf86FindOptionValue(devPtr->pEnt->device->options, 
"fbdev")))
  | ^~~
In file included from ../../src/ivtv.c:36:
../../src/ivtv_hw.h:65:70: note: expected 'char *' but argument is of type 
'const char *'
   65 | Bool ivtvHWInit(ScrnInfoPtr pScrn, struct pci_device *PciInfo, char 
*device);
  |
~~^~
make[3]: *** [Makefile:338: ivtv.lo] Error 1
make[3]: Leaving directory '/build/xserver-xorg-video-ivtvdev-1.1.2/build/src'


Andreas


xserver-xorg-video-ivtvdev_1.1.2-2.log.gz
Description: application/gzip

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

[Andreas Beckmann]

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 in libxcb-present-dev. (#1069408)

Andreas

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

[Andreas Beckmann]

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.debian.org/xorg-team/app/renderdoc\; 
-DDISTRIBUTION_NAME=\"Debian\" -DDISTRIBUTION_VERSION=\"1.27+dfsg-1\" 
-DNV_EXTENSIONS -DRELEASE -DRENDERDOC_EXPORTS -DRENDERDOC_PLATFORM_LINUX
 -DRENDERDOC_STABLE_BUILD=1 -DRENDERDOC_SUPPORT_EGL -DRENDERDOC_SUPPORT_GL 
-DRENDERDOC_SUPPORT_GLES -DRENDERDOC_SUPPORT_VULKAN 
-DRENDERDOC_VULKAN_JSON_SUFFIX="" -DRENDERDOC_WINDOWING_XCB 
-DRENDERDOC_WINDOWING_XLIB -DRENDERDOC_X86_PROC_FAMILY=1 -I/build/rende
rdoc-1.27+dfsg/renderdoc -I/build/renderdoc-1.27+dfsg/renderdoc/3rdparty -g -O2 
-ffile-prefix-map=/build/renderdoc-1.27+dfsg=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wdate-time -D_FORTIFY_SOURCE=2 
-std=c++11 -fno-strict-aliasing -fvisibility=hidden -fvisibility-inlines-hidden 
-Wall -Wextra -Wno-unused-variable -Wno-unused-parameter -Wno-unused-result 
-Wno-type-limits -Wno-missing-field-initializers -Wno-unknown-pragmas 
-Wno-reorder -Wno-unused-but-set
-variable -Wno-maybe-uninitialized -Wno-class-memaccess 
-Wimplicit-fallthrough=2 -Wno-unused-value -O3 -DNDEBUG -fPIC -MD -MT 
renderdoc/driver/shaders/spirv/CMakeFiles/rdoc_spirv.dir/glslang_compile.cpp.o 
-MF renderdoc/driver/shaders/spirv/CMakeFiles/rdoc_sp
irv.dir/glslang_compile.cpp.o.d -o 
renderdoc/driver/shaders/spirv/CMakeFiles/rdoc_spirv.dir/glslang_compile.cpp.o 
-c /build/renderdoc-1.27+dfsg/renderdoc/driver/shaders/spirv/glslang_compile.cpp
FAILED: 
renderdoc/driver/shaders/spirv/CMakeFiles/rdoc_spirv.dir/glslang_compile.cpp.o 
/usr/bin/c++ -DAMD_EXTENSIONS 
-DDISTRIBUTION_CONTACT=\"https://salsa.debian.org/xorg-team/app/renderdoc\; 
-DDISTRIBUTION_NAME=\"Debian\" -DDISTRIBUTION_VERSION=\"1.27+dfsg-1\" 
-DNV_EXTENSIONS -DRELEASE -DRENDERDOC_EXPORTS -DRENDERDOC_PLATFORM_LINUX 
-DRENDERD
OC_STABLE_BUILD=1 -DRENDERDOC_SUPPORT_EGL -DRENDERDOC_SUPPORT_GL 
-DRENDERDOC_SUPPORT_GLES -DRENDERDOC_SUPPORT_VULKAN 
-DRENDERDOC_VULKAN_JSON_SUFFIX="" -DRENDERDOC_WINDOWING_XCB 
-DRENDERDOC_WINDOWING_XLIB -DRENDERDOC_X86_PROC_FAMILY=1 
-I/build/renderdoc-1.27+
dfsg/renderdoc -I/build/renderdoc-1.27+dfsg/renderdoc/3rdparty -g -O2 
-ffile-prefix-map=/build/renderdoc-1.27+dfsg=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11
 -fno-strict-aliasing -fvisibility=hidden -fvisibility-inlines-hidden -Wall 
-Wextra -Wno-unused-variable -Wno-unused-parameter -Wno-unused-result 
-Wno-type-limits -Wno-missing-field-initializers -Wno-unknown-pragmas 
-Wno-reorder -Wno-unused-but-set-variable 
-Wno-maybe-uninitialized -Wno-class-memaccess -Wimplicit-fallthrough=2 
-Wno-unused-value -O3 -DNDEBUG -fPIC -MD -MT 
renderdoc/driver/shaders/spirv/CMakeFiles/rdoc_spirv.dir/glslang_compile.cpp.o 
-MF renderdoc/driver/shaders/spirv/CMakeFiles/rdoc_spirv.dir/gl
slang_compile.cpp.o.d -o 
renderdoc/driver/shaders/spirv/CMakeFiles/rdoc_spirv.dir/glslang_compile.cpp.o 
-c /build/renderdoc-1.27+dfsg/renderdoc/driver/shaders/spirv/glslang_compile.cpp
/build/renderdoc-1.27+dfsg/renderdoc/driver/shaders/spirv/glslang_compile.cpp:32:10:
 fatal error: glslang/Include/Types.h: No such file or directory
   32 | #include "glslang/Include/Types.h"
  |  ^
compilation terminated.

Andreas

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

[Andreas Beckmann]

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_INTEL_maximum_registers. This will be part of the 18.0.0
release soon and in order to package that we need some newer
spirv-headers packaged, too.
AFAICS there is no new spirv-headers tag yet that includes this commit.

Thanks

Andreas

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

[Andreas Beckmann]

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.

[Andreas Beckmann]

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

[Andreas Beckmann]

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 bottom...):

  Preparing to unpack .../vulkan-validationlayers-dev_1.2.148.0-1_amd64.deb ...
  Unpacking vulkan-validationlayers-dev:amd64 (1.2.148.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/vulkan-validationlayers-dev_1.2.148.0-1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/include/xxhash.h', which is also in package 
libxxhash-dev:amd64 0.8.0-1
  Errors were encountered while processing:
   /var/cache/apt/archives/vulkan-validationlayers-dev_1.2.148.0-1_amd64.deb


cheers,

Andreas


libxxhash-dev=0.8.0-1_vulkan-validationlayers-dev=1.2.148.0-1.log.gz
Description: application/gzip

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

[Andreas Beckmann]

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 other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libweston-9-dev_9.0.0-1_amd64.deb ...
  Unpacking libweston-9-dev (9.0.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libweston-9-dev_9.0.0-1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/weston/libexec_weston.so', 
which is also in package libweston-8-dev 8.0.0-1
  Errors were encountered while processing:
   /var/cache/apt/archives/libweston-9-dev_9.0.0-1_amd64.deb

Since libweston-8-dev is gone, the Breaks+Replaces can be unversioned.


cheers,

Andreas


libweston-8-dev=8.0.0-1_libweston-9-dev=9.0.0-1.log.gz
Description: application/gzip

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

[Andreas Beckmann]

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 for a Debian ports architecture.


Andreas

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

[Andreas Beckmann]

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'

[Andreas Beckmann]

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.

>From the attached log (scroll to the bottom...):

  Setting up xfonts-scalable (1:1.0.0-6) ...
  fmt: invalid width: `63482'
  fmt: invalid width: `63482'
  fmt: invalid width: `63482'
  dpkg: error processing xfonts-scalable (--configure):
   subprocess post-installation script returned error exit status 1
  Errors were encountered while processing:
   xfonts-scalable

It installs fine in squeeze/i386 with the version from squeeze.


cheers,

Andreas


xfonts-scalable_1:1.0.0-6.log.gz
Description: application/gzip

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

[Andreas Beckmann]

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:
  /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_gallium.so -> 
libvdpau_gallium.so.1.0.0 (mesa-vdpau-drivers:amd64)


cheers,

Andreas


mesa-vdpau-drivers_18.3.6-1.log.gz
Description: application/gzip

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

[Andreas Beckmann]

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

[Andreas Beckmann]

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


Andreas

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

[Andreas Beckmann]

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 worthwile suggesting such a rename to upstream, too.
> 
> Correction, it should go upstream _first_.

Upstream will bump all the filename versions to prevent accidently
mixing libglvnd and mesa libraries ...

https://github.com/NVIDIA/libglvnd/commit/212861e5e73927ec267244f5fc3040bb9b701c47

Please bump the Breaks against glx-diversions to (<< 0.8.3~) (I just
uploaded 0.8.3 to sid).


Thanks

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

[Andreas Beckmann]

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-Installer 384.90: "An incomplete
installation of libglvnd was found." where an old copy of the MESA
libGL.so.1.2.0 was left and was still ebing used.

ldconfig will give precedence to the file with the highest filename
version as the target of the SONAME link libGL.so.1. So unfortunately
libGL.so.1.0.0 will always be the loser.

Renaming libGL.so.1.0.0 (or just adding a symlink with a higher version
to it) would circumvent these bugs by giving precedence to the libglvnd
libGL.so.1.

The following filenames have been in use in the past and present:

libgl1: /usr/lib/x86_64-linux-gnu/libGL.so.1.0.0
libgl1-fglrx-glx: /usr/lib/x86_64-linux-gnu/fglrx/fglrx-libGL.so.1.2
libgl1-fglrx-legacy-glx: /usr/lib/x86_64-linux-gnu/fglrx/fglrx-libGL.so.1.2
libgl1-glvnd-nvidia-glx: /usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1.0.0
libgl1-mesa-glx: /usr/lib/x86_64-linux-gnu/libGL.so.1.2
libgl1-mesa-glx: /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0
libgl1-mesa-swx11: /usr/lib/x86_64-linux-gnu/libGL.so.1.5.08005
libgl1-mesa-swx11: /usr/lib/x86_64-linux-gnu/libGL.so.1.6.0


I would suggest to add a symlink
libGL.so.1.7.0 -> libGL.so.1.0.0
That also means to adjust the SONAME link to
libGL.so.1 -> libGL.so.1.7.0
to ship the link like it would be created by ldconfig, otherwise it may
trigger errors in some library symlink validation test in piuparts.

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 worthwile suggesting such a rename to upstream, too.


Andreas

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

[Andreas Beckmann]

Followup-For: Bug #872874

Fixed in stretch with the attached patch.


Andreas
diff -u libxkbcommon-0.7.1/debian/changelog libxkbcommon-0.7.1/debian/changelog
--- libxkbcommon-0.7.1/debian/changelog
+++ libxkbcommon-0.7.1/debian/changelog
@@ -1,3 +1,18 @@
+libxkbcommon (0.7.1-2~deb9u1) stretch; 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 → libxkbcommon-dev
+(closes: #872874).
+
+ -- Julien Cristau <jcris...@debian.org>  Sat, 16 Sep 2017 13:40:36 +0200
+
 libxkbcommon (0.7.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -u libxkbcommon-0.7.1/debian/control libxkbcommon-0.7.1/debian/control
--- libxkbcommon-0.7.1/debian/control
+++ libxkbcommon-0.7.1/debian/control
@@ -2,7 +2,7 @@
 Section: x11
 Priority: optional
 Maintainer: Debian X Strike Force <debian-x@lists.debian.org>
-Uploaders: Cyril Brulebois <k...@debian.org>, Michael Stapelberg 
<stapelb...@debian.org>
+Uploaders: Michael Stapelberg <stapelb...@debian.org>
 Build-Depends:
  debhelper (>= 10),
  quilt,
@@ -94,6 +94,7 @@
 Pre-Depends: ${misc:Pre-Depends}
 Depends:
  libxkbcommon-x11-0 (= ${binary:Version}),
+ libxkbcommon-dev (= ${binary:Version}),
  libxcb1-dev,
  libxcb-xkb-dev,
  ${shlibs:Depends},

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

[Andreas Beckmann]

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 virtual packages from
  src:mesa (<< 17) (a package built on buster won't be installable on
  stretch)
* it would simplify my work matching src:libglvnd package versions with
  src:nvidia-graphics-drivers packages, should I ever consider providing
  libglvnd package names again (since I could provide a version that is
  *less* than any src:libglvnd version, which doesn't work if the
  dependency other packages having on e.g. libgl1 is unversioned)


If you agree, I can prepare a patch.


Andreas

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

[Andreas Beckmann]

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

[Andreas Beckmann]

Followup-For: Bug #876084

This bug could be related to several similar ones against
nvidia-graphics-drivers recently, finally fixed with 375.82-8 ...

I suggest to add a bug-control file to automatically record this fact in
case of bug reports. libgl1-nvidia-glx-any is a virtual package that is
provided by src:nvidia-graphics-drivers for several years already.

And there is another little patch switching to dh_missing ...

The --builddirectory=build/ is a bit unfortunate, since it clashes with
'dh build' in case someone manually runs it twice - which I obviously did :-)


Andreas
>From 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 ++
 debian/rules   | 3 +++
 3 files changed, 6 insertions(+)
 create mode 100644 debian/bug-control

diff --git a/debian/bug-control b/debian/bug-control
new file mode 100644
index 000..584c4f9
--- /dev/null
+++ b/debian/bug-control
@@ -0,0 +1 @@
+package-status: libgl1-nvidia-glx-any
diff --git a/debian/changelog b/debian/changelog
index 76f7e56..a721dfc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,8 @@ libglvnd (1.0.0-2) UNRELEASED; urgency=medium
   * Use source format 3.0 (quilt).
   * kfreebsd-hurd.patch: New, fix FTBFS on kFreeBSD and Hurd.
 (Closes: #870445)
+  * Add bug-control file to report whether the proprietary nvidia driver is
+installed.
 
  -- Andreas Beckmann <a...@debian.org>  Sat, 25 Nov 2017 14:59:46 +
 
diff --git a/debian/rules b/debian/rules
index 4f302d8..e3df5b3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,6 +17,9 @@ override_dh_auto_test:
 override_dh_makeshlibs:
dh_makeshlibs -a -- -c4
 
+override_dh_bugfiles:
+   dh_bugfiles -A
+
 %:
dh $@ --builddirectory=build/
 
-- 
2.5.1

>From 2b6d0c464c7c346babcb0bb20d38a238b6d51dfc Mon Sep 17 00:00:00 2001
From: Andreas Beckmann <a...@debian.org>
Date: Sat, 25 Nov 2017 16:05:28 +
Subject: [PATCH 4/4] switch to dh_missing --fail-missing

---
 debian/changelog | 1 +
 debian/rules | 6 --
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index a721dfc..df4ac1f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,7 @@ libglvnd (1.0.0-2) UNRELEASED; urgency=medium
 (Closes: #870445)
   * Add bug-control file to report whether the proprietary nvidia driver is
 installed.
+  * Switch to dh_missing --fail-missing.
 
  -- Andreas Beckmann <a...@debian.org>  Sat, 25 Nov 2017 14:59:46 +
 
diff --git a/debian/rules b/debian/rules
index e3df5b3..e35daf7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,13 +3,15 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-override_dh_install:
+override_dh_auto_install:
+   dh_auto_install
find debian/tmp -name '*.la' -delete
 
# drop GLESv1
rm -f debian/tmp/usr/lib/*/libGLESv1*
 
-   dh_install --fail-missing
+override_dh_missing:
+   dh_missing --fail-missing
 
 # needs X
 override_dh_auto_test:
-- 
2.5.1

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

[Andreas Beckmann]

Followup-For: Bug #870445
Control: tag -1 patch

Hi,

attached are two patches to fix this FTBFS.
Build-tested on falla and exodar.

The git repository is missing the pristine-tar commit for 1.0.0 and all
the upstream version tags.


Andreas
>From 09a59c852e307c7e4d6770fa137975dab93ce9fe Mon 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/changelog b/debian/changelog
index 207a54a..ded1623 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+libglvnd (1.0.0-2) UNRELEASED; urgency=medium
+
+  * Use source format 3.0 (quilt).
+
+ -- Andreas Beckmann <a...@debian.org>  Sat, 25 Nov 2017 14:59:46 +
+
 libglvnd (1.0.0-1) unstable; urgency=high
 
   [ Andreas Boll ]
diff --git a/debian/source/format b/debian/source/format
index d3827e7..163aaf8 100644
--- a/debian/source/format
+++ b/debian/source/format
@@ -1 +1 @@
-1.0
+3.0 (quilt)
-- 
2.1.4

>From b48012726befb68920af1cbe4fc3beb0bc6afab2 Mon Sep 17 00:00:00 2001
From: Andreas Beckmann <a...@debian.org>
Date: Sat, 25 Nov 2017 15:10:20 +
Subject: [PATCH 2/2] fix FTBFS on kFreeBSD and Hurd

---
 debian/changelog   |  2 ++
 debian/patches/kfreebsd-hurd.patch | 14 ++
 debian/patches/series  |  1 +
 3 files changed, 17 insertions(+)
 create mode 100644 debian/patches/kfreebsd-hurd.patch
 create mode 100644 debian/patches/series

diff --git a/debian/changelog b/debian/changelog
index ded1623..76f7e56 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,8 @@
 libglvnd (1.0.0-2) UNRELEASED; urgency=medium
 
   * Use source format 3.0 (quilt).
+  * kfreebsd-hurd.patch: New, fix FTBFS on kFreeBSD and Hurd.
+(Closes: #870445)
 
  -- Andreas Beckmann <a...@debian.org>  Sat, 25 Nov 2017 14:59:46 +
 
diff --git a/debian/patches/kfreebsd-hurd.patch 
b/debian/patches/kfreebsd-hurd.patch
new file mode 100644
index 000..c504e51
--- /dev/null
+++ b/debian/patches/kfreebsd-hurd.patch
@@ -0,0 +1,14 @@
+Author: Andreas Beckmann <a...@debian.org>
+Description: fix FTBFS on kFreeBSD and Hurd
+
+--- a/src/GLdispatch/vnd-glapi/u_execmem.c
 b/src/GLdispatch/vnd-glapi/u_execmem.c
+@@ -68,7 +68,7 @@ static unsigned char *exec_mem = NULL;
+ static unsigned char *write_mem = NULL;
+ 
+ 
+-#if defined(__linux__) || defined(__OpenBSD__) || defined(_NetBSD__) || 
defined(__sun) || defined(__HAIKU__)
++#if defined(__linux__) || defined(__OpenBSD__) || defined(_NetBSD__) || 
defined(__sun) || defined(__HAIKU__) || defined(__FreeBSD_kernel__) || 
defined(__GNU__)
+ 
+ #include 
+ #include 
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..1dfcb87
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+kfreebsd-hurd.patch
-- 
2.1.4

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

[Andreas Beckmann]

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:mesa (<< 17).  (Closes: #875683, #876100)
> I don't understand. How does this solve issue 876100? The problem was
> that nvidia wasn't coinstallable with eg. libegl1-mesa-dev in its
> current version, and it is still so. Could you explain?


I just tried again in a minimal sid chroot and didn't encounter any problems:

# apt-get install --install-recommends nvidia-driver
[...]
(successfully installed)

# apt-get install libglvnd-dev
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  libglvnd-core-dev
The following NEW packages will be installed:
  libglvnd-core-dev libglvnd-dev
0 upgraded, 2 newly installed, 0 to remove and 10 not upgraded.
Need to get 0 B/16.3 kB of archives.
After this operation, 80.9 kB of additional disk space will be used.
Do you want to continue? [Y/n]  
[...]
(successfully installed)

# ls -lad $(dpkg -L libglvnd-dev)
ls: cannot access 'diverted': No such file or directory
ls: cannot access 'by': No such file or directory
ls: cannot access 'glx-diversions': No such file or directory
ls: cannot access 'to:': No such file or directory
ls: cannot access 'diverted': No such file or directory
ls: cannot access 'by': No such file or directory
ls: cannot access 'glx-diversions': No such file or directory
ls: cannot access 'to:': No such file or directory
ls: cannot access 'diverted': No such file or directory
ls: cannot access 'by': No such file or directory
ls: cannot access 'glx-diversions': No such file or directory
ls: cannot access 'to:': No such file or directory
drwxr-xr-x  22 root root  440 Sep 20 22:51 /.
drwxr-xr-x  10 root root  200 Mar 25  2013 /usr
drwxr-xr-x  40 root root  880 Sep 20 22:54 /usr/lib
lrwxrwxrwx   1 root root   15 Sep 12 07:32 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so -> libEGL.so.1.0.0
lrwxrwxrwx   1 root root   14 Sep 12 07:32 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so -> libGL.so.1.0.0
lrwxrwxrwx   1 root root   18 Sep 12 07:32 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so -> libGLESv2.so.2.0.0
drwxr-xr-x  26 root root 9300 Sep 20 22:56 /usr/lib/x86_64-linux-gnu
lrwxrwxrwx   1 root root   49 Sep 20 22:56 /usr/lib/x86_64-linux-gnu/libEGL.so 
-> /etc/alternatives/glx--libEGL.so-x86_64-linux-gnu
lrwxrwxrwx   1 root root   48 Sep 20 22:56 /usr/lib/x86_64-linux-gnu/libGL.so 
-> /etc/alternatives/glx--libGL.so-x86_64-linux-gnu
lrwxrwxrwx   1 root root   52 Sep 20 22:56 
/usr/lib/x86_64-linux-gnu/libGLESv2.so -> 
/etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu
lrwxrwxrwx   1 root root   15 Sep 12 07:32 /usr/lib/x86_64-linux-gnu/libGLX.so 
-> libGLX.so.0.0.0
lrwxrwxrwx   1 root root   22 Sep 12 07:32 
/usr/lib/x86_64-linux-gnu/libGLdispatch.so -> libGLdispatch.so.0.0.0
lrwxrwxrwx   1 root root   18 Sep 12 07:32 
/usr/lib/x86_64-linux-gnu/libOpenGL.so -> libOpenGL.so.0.0.0
drwxr-xr-x  79 root root 1580 Sep 20 22:54 /usr/share
drwxr-xr-x 397 root root 8640 Sep 20 22:56 /usr/share/doc
drwxr-xr-x   2 root root   80 Sep 20 22:56 /usr/share/doc/libglvnd-dev
-rw-r--r--   1 root root  914 Sep 12 07:32 
/usr/share/doc/libglvnd-dev/changelog.Debian.gz
-rw-r--r--   1 root root 4697 Sep 12 07:32 /usr/share/doc/libglvnd-dev/copyright

# apt-get install libegl1-mesa-dev
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  libdrm-dev libpthread-stubs0-dev libwayland-bin libwayland-dev libx11-dev 
libx11-xcb-dev libxau-dev libxcb-dri2-0-dev libxcb-dri3-dev libxcb-glx0-dev 
libxcb-present-dev libxcb-randr0 libxcb-randr0-dev libxcb-render0-dev
  libxcb-shape0 libxcb-shape0-dev libxcb-sync-dev libxcb-xfixes0-dev 
libxcb1-dev libxdamage-dev libxdmcp-dev libxext-dev libxfixes-dev 
libxshmfence-dev libxxf86vm-dev x11proto-core-dev x11proto-damage-dev 
x11proto-dri2-dev
  x11proto-fixes-dev x11proto-gl-dev x11proto-input-dev x11proto-kb-dev 
x11proto-xext-dev x11proto-xf86vidmode-dev xorg-sgml-doctools xtrans-dev
Suggested packages:
  libxcb-doc libxext-doc
Recommended packages:
  libx11-doc
The following NEW packages will be installed:
  libdrm-dev libegl1-mesa-dev libpthread-stubs0-dev libwayland-bin 
libwayland-dev libx11-dev libx11-xcb-dev libxau-dev libxcb-dri2-0-dev 
libxcb-dri3-dev libxcb-glx0-dev libxcb-present-dev libxcb-randr0 
libxcb-randr0-dev
  libxcb-render0-dev libxcb-shape0 libxcb-shape0-dev libxcb-sync-dev 
libxcb-xfixes0-dev libxcb1-dev libxdamage-dev libxdmcp-dev libxext-dev 
libxfixes-dev libxshmfence-dev libxxf86vm-dev x11proto-core-dev 
x11proto-damage-dev
  x11proto-dri2-dev x11proto-fixes-dev x11proto-gl-dev x11proto-input-dev 
x11proto-kb-dev 

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

[Andreas Beckmann]

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 any other packages providing those
> names, particularly libgl1 et al. provided by libglvnd.

First we have to sort out coexistence of the libglvnd runtime side of
nvidia ...


Andreas

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

[Andreas Beckmann]

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

[Andreas Beckmann]

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.config   not owned
>>
>> It appears the old Xwrapper was killed off at some point.
>>
>> The patch should be trivial enough that I can do it.  This would also
>> serve as an exercise of branden-guest's permissions on alioth.
>>
>> Any objection?
>>
> The wrapper was moved to the xserver-xorg-legacy package, and I'm a bit

which is not installed by default during the upgrade ...

> worried removing the configuration file in the x11-common maintainer
> scripts would break that transition.

Given that this is a complicated case ... I'm going to add the file to
the ignore list built into piuparts.


Andreas

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

[Andreas Beckmann]

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-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

1m37.2s INFO: Warning: Package purging left files on system:
  /etc/X11/Xwrapper.config   not owned

This was observed after an upgrade from jessie to stretch.
Works fine in both jessie and stretch without upgrading between
releases.


cheers,

Andreas


x11-common_1:7.7+18.log.gz
Description: application/gzip

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

[Andreas Beckmann]

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/share/X11/doc -> ../doc/xorg-docs/docs


Maybe you wanted to target just ../doc/xorg-docs ?


cheers,

Andreas


xorg-docs_1:1.7.1-1.log.gz
Description: application/gzip

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

[Andreas Beckmann]

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] hangs KDE4 login
>> Warning: Unknown package 'xserver-xorg-video-via'
>> Bug reassigned from package 'xserver-xorg-video-via' to 
>> 'src:xserver-xorg-video-openchrome'.

>> No longer marked as found in versions 
>> xserver-xorg-video-openchrome/1:0.2.904+svn842-2.

The old "found" information referred to
src:xserver-xorg-video-openchrome, so reassigning it back to the source
package made sense to me. I assumed this was a transitional package in
the old days and the maintainers might know how to deal with this bug
properly.

>> Ignoring request to alter fixed versions of bug #610693 to the same values 
>> previously set
>> Bug #610693 [src:xserver-xorg-video-openchrome] xserver-xorg-video-via: 
>> KM400/KN400/P4M800 [S3 UniChrome] hangs KDE4 login
>> Marked as found in versions xserver-xorg-video-openchrome/1:0.2.904+svn842-2.
> 
> xserver-xorg-video-via and xserver-xorg-video-openchrome aren't the same
> thing, I fail to see how reassigning this makes sense?

Andreas

PS: the list of orphaned bugs (filed against "packages without
maintainers") left over from the removal of squeeze is now down from
over 1000 to below 100

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

[Andreas Beckmann]

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[1]: Entering directory 
'/build/xserver-xorg-video-siliconmotion-1.7.7/build'
make  all-recursive
make[2]: Entering directory 
'/build/xserver-xorg-video-siliconmotion-1.7.7/build'
Making all in src
make[3]: Entering directory 
'/build/xserver-xorg-video-siliconmotion-1.7.7/build/src'
/bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../../src -I..-fvisibility=hidden -I/usr/include/pixman-1 
-I/usr/include/libdrm -I/usr/include/xorg -I/usr/include/X11/dri -Wall 
-Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes 
-Wmissing-prototypes -Wnested-externs -Wbad-function-cast 
-Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized 
-Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls 
-Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main 
-Werror=missing-braces -Werror=sequence-point -Werror=return-type 
-Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address 
-Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing  
-g -O2 -c -o smi_501.lo ../../src/smi_501.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -fvisibility=hidden 
-I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/xorg 
-I/usr/include/X11/dri -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast 
-Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized 
-Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls 
-Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main 
-Werror=missing-braces -Werror=sequence-point -Werror=return-type 
-Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address 
-Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing -g 
-O2 -c ../../src/smi_501.c  -fPIC -DPIC -o .libs/smi_501.o
In file included from ../../src/smi.h:40:0,
 from ../../src/smi_501.c:33:
/usr/include/xorg/xf86PciInfo.h:50:2: warning: #warning "xf86PciInfo.h is 
deprecated.  For greater compatibility, drivers should include necessary PCI 
IDs locally rather than relying on this file from xorg-server." [-Wcpp]
 #warning "xf86PciInfo.h is deprecated.  For greater compatibility, drivers 
should include necessary PCI IDs locally rather than relying on this file from 
xorg-server."
  ^
In file included from ../../src/smi_501.c:33:0:
../../src/smi.h:224:5: error: unknown type name 'IOADDRESS'
 IOADDRESS  PIOBase; /* Base of I/O ports */
 ^
Makefile:521: recipe for target 'smi_501.lo' failed
make[3]: *** [smi_501.lo] Error 1
make[3]: Leaving directory 
'/build/xserver-xorg-video-siliconmotion-1.7.7/build/src'
Makefile:444: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/build/xserver-xorg-video-siliconmotion-1.7.7/build'
Makefile:376: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/build/xserver-xorg-video-siliconmotion-1.7.7/build'
dh_auto_build: make -j1 returned exit code 2
debian/rules:17: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


Andreas

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

[Andreas Beckmann]

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

[Andreas Beckmann]

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.
>> So here is my question:
>> Do you have for libclc a git repository for collaboration?
>> If not could you create one under the umbrella of pkg-opencl?

> I've put an updated package to
> 
> git://git.debian.org/git/users/tjaalton/libclc.git
> 
> feel free to use it as a base for the official update, and/or for the
> migration to git.

I imported the package history into git and rebased Timo's and Andreas'
changes on top of this, the repository is now available at

git+ssh://git.debian.org/git/pkg-opencl/libclc.git
git://anonscm.debian.org/pkg-opencl/libclc.git
https://anonscm.debian.org/cgit/pkg-opencl/libclc.git

and writable by the members of the pkg-opencl alioth project.


Andreas

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

[Andreas Beckmann]

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_HOST_MULTIARCH}-${glxbinary} as the GCC toolchain does),
maybe in a new binary package 'mesa-utils-bin' that is Multi-Arch:same,
and have mesa-utils ship ${glxbinary} -
${DEB_HOST_MULTIARCH}-${glxbinary} symlinks while depending on
mesa-utils-bin:native.


Andreas


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150712200415.14655.99124.report...@zam581.zam.kfa-juelich.de

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

[Andreas Beckmann]

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 the discussion to one of these bugs and trim the Cc
list a bit ...

If you merge them, please reassign them to src:nvidia-driver and add
Affects for the packages where they have been reported.

 * nvidia-kernel-dkms: Switch to Recommends: nvidia-driver | libcuda1
   to break the chain libcuda1 - nvidia-kernel-dkms - nvidia-driver.
 ...or drop this Recommends: entirely

That Recommends has been there since nvidia-kernel-dkms was added in
2010. I thinks its main purpose is for people that try to install the
wrong package (i.e. nvidia-kernel-dkms instead of nvidia-driver (or
nvidia-glx back then)) to get a working NVIDIA driver installation
(well, still needs some manual configuration, but debconf will tell you
that). I don't want to touch (as in remove) that right now.

 (IIRC circular Depends/Recommends
 are discouraged because they confuse apt's autoremover, though I can't
 find where I saw that).

I don't want to workaround bugs in unrelated packages

 Cutting the chain here (tested with apt-get install nvidia-libopencl1
 nvidia-driver-, the - after a package means remove/don't install)
 does still allow much of nvidia-* (including nvidia-kernel-dkms and
 glx-alternative-nvidia) to be installed, but that appears to be harmless

and you get the full set of lib*GL* diversions, too ... this and some
more are needed to allow switching between nvidia-opencl-icd and
nvidia$LEGACY-opencl-icd which will become available once I fork off
(and backport) nvidia-graphics-drivers-legacy-340xx after the jessie
release.

 without libgl1-nvidia-glx (at least on my Intel IvyBridge M GT2, both
 graphics and OpenCL continue to work after rebooting).

That would be a bug otherwise :-)

 Given that the error on loading nvidia-opencl-icd in a non-Nvidia system is
 
 modprobe: ERROR: could not insert 'nvidia_current': No such device
 
 it is plausible that nvidia-opencl-icd uses the nvidia kernel module
 (i.e. nvidia-kernel-dkms | nvidia-kernel-version) and as such _should_
 pull it in (whether or not it also needs libcuda1),

In wheezy all this OpenCL stuff was rather new and only proprietary
implementations were available ... as a result installing
nvidia-opencl-icd was harmless (due to lack of dependencies) but also
useless (due to lack of dependencies) unless you had nvidia-driver
installed, too. This I wanted to fix in jessie :-)

 while #768185
 suggests that nvidia-opencl-icd works without the graphics side (can
 someone check that?),

I'm pretty sure NVIDIA CUDA and OpenCL work in headless setups, i.e.
without X server running. They just need the kernel module to be loaded
(and the corresponding device to be created). (Contrary to AMD which
needs X to communicate with the GPU for doing OpenCL)

 making this the more correct place to cut the chain.

Andreas


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/547472c0.3030...@debian.org

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

[Andreas Beckmann]

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 libcuda1 Recommends:
 nvidia-kernel-dkms which Recommends: nvidia-driver.

Damn, ensuring that there are proper dependencies for all the NVIDIA
packages breaks (well, sort of breaks) the upgrade in case
nvidia-opencl-icd was installed in wheezy for no good reason ...

I've now prepared two changes in SVN (n-g-d branches/jessie):

nvidia-graphics-drivers (340.46-6) UNRELEASED; urgency=medium

  * nvidia-kernel-dkms: Switch to Recommends: nvidia-driver | libcuda1
to break the chain libcuda1 - nvidia-kernel-dkms - nvidia-driver.
  * nvidia-opencl-icd: Downgrade the Depends: libcuda1 to Suggests. This
should avoid pulling in too many NVIDIA packages on wheezy - jessie
upgrades of systems that have no NVIDIA hardware, but nvidia-opencl-icd
installed nevertheless.  (Closes: #769072, #770588, #769191)

In upgrade tests in minimal wheezy chroots with nvidia-opencl-icd
installed that seemed to work and did no longer pull nvidia-driver into
the system.

I don't know how seriously the missing libcuda1 breaks
nvidia-opencl-icd. I can see that this is being dlopen()ed, but at least
clinfo still reports something about the GPU. I don't have a better
testcase right now, suggestions welcome.

A more proper solution could be to rename nvidia-opencl-icd to e.g.
nvidia-icd and add an empty nvidia-opencl-icd package that only
Suggests: nvidia-icd. That would prevent inadvertent users of
nvidia-opencl-icd from getting anything new from the nvidia stack but
everyone who really wants to use nvidia-icd would have to install it
manually.
(but we could Recommend it from nvidia-opencl-dev
(src:nvidia-cuda-toolkit)).

Andreas


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/547141d9.9050...@debian.org

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

[Andreas Beckmann]

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 appeared after one of (dist?) upgrades. The
 first trace of them is from August:
 
 Mon, Aug  4 2014 16:15:15 +0200
 [INSTALL, DEPENDENCIES] nvidia-libopencl1:i386
 [INSTALL, DEPENDENCIES] nvidia-opencl-icd:i386

Something OpenCL related pulled these in - I think we have changed the
dependencies since then on the OpenCL parts globally to prevent pulling
in bits of the non-free drivers just for getting a libOpenCL.so.1 as
some dependency (you can manually select to install the proprietary
ones, though).

 Can I remove all of the packages listed above?

these and glx-diversions and glx-alternative-*, maybe some more :-)
If something needs a libopencl1, use ocl-icd-libopencl1 instead of the
nvidia one.

 I'm still intrigued by the message which I definitely seen on the
 console during an upgrade, which was definitely about a nvidia package
 and which is not present in /var/apt/log. The problem appeared
 immediately after this routine upgrade. Perhaps by my actions I made it
 worst, but the primary reason was (is?) somewhere in the system.

I don't think any of the debconf messages used by the nvidia driver
would have been displayed in your case.


Andreas


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54687871.2080...@debian.org

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

[Andreas Beckmann]

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)

Please send the output from the bug script from the nvidia packages

/usr/share/bug/libgl1-nvidia-glx/script 3nvidia.log


On Sat, 15 Nov 2014 08:01:51 +0100 Janusz S. Bien
jsb...@mimuw.edu.pl wrote:
 As I wrote already, there was a message during one of the upgrades  
 which I unfortunately ignored. Should it be still available somewhere  
 in the logs? I tried to find it, but unsuccesfully.

Try /var/log/apt/term.log*


Andreas


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5467b6dc.9050...@debian.org

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

[Andreas Beckmann]

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 that does not support
them). Which nvidia packages do you have installed?

dpkg -l | grep nvidia

(I would guess neither nvidia-driver nor xserver-xorg-video-nvidia).


To fix your system, either uninstall the nvidia packages (they are not
useful on your system anyway) or switch back to mesa:
  update-alternatives --config glx
and select mesa


I don't think I can express this with package relationships:

libgl1-nvidia-glx needs to be installed
  (1) together with xserver-xorg-video-nvidia (and xserver-xorg-core)
  (regular installation on a host)
  (2) OR without xserver-xorg-core (and xserver-xorg-video-nvidia)
  (i.e. libraries from a foreign architecture only or in a chroot
   without own xserver)
i.e. only the combination
  install libgl1-nvidia-glx:native
  install xserver-xorg-core:native
  no-install xserver-xorg-video-nvidia
should be forbidden.


Andreas


-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5467ef4d.2050...@debian.org

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

[Andreas Beckmann]

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 UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54441708.5030...@debian.org

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

[Andreas Beckmann]

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 tracker won't reflect this since the non-free drivers depend on an
OR-ed list of all supported server versions and therefore match the bad
expression, too.)


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.org/52fcd6be.7020...@debian.org

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

[Andreas Beckmann]

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 roadmap for jessie? Will we likely see another update?
Xserver 1.16 is planned for July [1]

[1] http://lists.x.org/archives/xorg-devel/2013-December/039739.html

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.org/52e86db8.9010...@debian.org

Re: heads up: xserver 1.14 to unstable

[Andreas Beckmann]

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, so we may need to phase it out for jessie

fglrx-driver in experimental has support for 1.14

fglrx-legacy-driver may or may not get an update from upstream


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.org/523ac196.3050...@debian.org

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

[Andreas Beckmann]

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-diversions, too.

Patch will follow.


Thanks


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.org/20130818084436.4050.54557.report...@cake.ae.cs.uni-frankfurt.de

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

[Andreas Beckmann]

the old glx-diversions versions are not fully aware of libGL.so.1.2.0
---
 debian/changelog |7 +++
 debian/control   |1 +
 2 files changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index f68dc77..9d03373 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -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; urgency=low
 
   * Don't run 'make -j' if DEB_BUILD_OPTIONS doesn't set parallel.  Oops.
diff --git a/debian/control b/debian/control
index c344e0c..4be6115 100644
--- a/debian/control
+++ b/debian/control
@@ -543,6 +543,7 @@ Provides: libgl1
 Breaks:
  libgl1-nvidia-alternatives (= 275.09.07-1),
  fglrx-glx ( 1:11-6-1),
+ glx-diversions ( 0.4),
 Pre-Depends: ${misc:Pre-Depends}
 Multi-Arch: same
 Description: free implementation of the OpenGL API -- GLX runtime
-- 
1.7.10.4


-- 
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.org/1376816258-10897-1-git-send-email-a...@debian.org

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

[Andreas Beckmann]

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 and amd64 is attached.


Cheers,

Andreasdiff -ur libxfont-dev_1.4.6-1_i386/usr/share/doc/libxfont-dev/fontlib.html 
libxfont-dev_1.4.6-1_amd64/usr/share/doc/libxfont-dev/fontlib.html
--- libxfont-dev_1.4.6-1_i386/usr/share/doc/libxfont-dev/fontlib.html   
2013-08-12 18:40:47.0 +0200
+++ libxfont-dev_1.4.6-1_amd64/usr/share/doc/libxfont-dev/fontlib.html  
2013-08-12 18:30:24.0 +0200
@@ -292,7 +292,7 @@
 }
 /style/headbodydiv class=articlediv class=titlepagedivdivh2 
class=titlea id=fontlib/a
The X Font Library
-  /h2/divdivdiv class=authorgroupdiv class=authorh3 
class=authorspan class=firstnameKeith/span span 
class=surnamePackard/span/h3div class=affiliationspan 
class=orgnameMIT X Consortiumbr //span/div/divdiv 
class=authorh3 class=authorspan class=firstnameDavid/span span 
class=surnameLemke/span/h3div class=affiliationspan 
class=orgnameNetwork Computing Devicesbr 
//span/div/div/div/divdivp class=releaseinfoX Version 11, 
Release 7.6/p/divdivp class=copyrightCopyright © 1993 Network 
Computing Devices/p/divdivdiv class=legalnoticea 
id=idp43674508/ap
+  /h2/divdivdiv class=authorgroupdiv class=authorh3 
class=authorspan class=firstnameKeith/span span 
class=surnamePackard/span/h3div class=affiliationspan 
class=orgnameMIT X Consortiumbr //span/div/divdiv 
class=authorh3 class=authorspan class=firstnameDavid/span span 
class=surnameLemke/span/h3div class=affiliationspan 
class=orgnameNetwork Computing Devicesbr 
//span/div/div/div/divdivp class=releaseinfoX Version 11, 
Release 7.6/p/divdivp class=copyrightCopyright © 1993 Network 
Computing Devices/p/divdivdiv class=legalnoticea 
id=idp52162720/ap
  Permission to use, copy, modify, distribute, and sell this
  software and its documentation for any purpose is hereby
  granted without fee, provided that the above copyright

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

[Andreas Beckmann]

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.org/520fe23a.10...@debian.org

Bug#706114: xfonts-utils: insufficient zlib1g dependency

[Andreas Beckmann]

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 has been unpacked, but not
 configured. This is either a problem in xfonts-utils's
 update-fonts-dir, or in debhelper's dh_installxfonts support inserting
 those snippets.

 In terms of getting this fixed quickly for wheezy, couldn't that be
 addressed with a Pre-Depends: xfonts-utils in gsfonts-x11?
 
 That would only solve the problem for gsfonts-x11, but not for
 anything else using dh_installxfonts. I think, to be safe the hack
 would need to be applied to xfonts-utils's dependencies, which is all

The reason for this suboptimal upgrade order is probably

Package: zlib1g
Breaks: ..., texlive-binaries ( 2009-12)

and instead of deconfiguring texlive-binaries apt delays installation of
the new zlib1g, breaking some unpacked and not yet configured packages.

 kinds of ugly, but at least should always work, at the cost of
 complicating the upgrade path.
 
 I guess the correct solution though, is to change update-fonts-* and
 any other script in xfonts-utils calling mkfont* from other maintainer
 scripts, to only run if xfonts-utils itself is configured or being
 configured, and calling these through xfonts-utils maintainer scripts
 too, so that if xfonts-utils and something else using it like gsfonts-x11
 are both unpacked on the same run, the actual update-fonts-* executions
 will be delayed until xfonts-utils is itself configured, at which point
 the scripts should be able to run. I don't think this would be much
 more difficult to prepare.

Sounds like a job for triggers (but there is currently a dpkg bug that
causes it to run triggers for packages that are not configured (or their
dependencies are not)

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.org/517926d1.9020...@debian.org

Bug#640499: libxvmc: please add multiarch support

[Andreas Beckmann]

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 files changed, 15 insertions(+), 8 deletions(-)
 
 Where is the problem? What prevents the release team allowing this upload for 
 Wheezy?

There is a solution that only involves changes to
nvidia-graphics-drivers, waiting for approval:

splitting libxvmcnvidia1 from libgl1-nvidia-glx:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688953

new upstream stable branch release
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688698


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.org/50c191e7.1010...@abeckmann.de

Bug#640499: libxvmc: please add multiarch support

[Andreas Beckmann]

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 workaround

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.org/507c6ea2.40...@abeckmann.de

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

[Andreas Beckmann]

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.org/5062facc.8070...@abeckmann.de

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

[Andreas Beckmann]

manually forwarding to #640499 as the BTS does not seem to handle
X-DebBugs-Cc: n@b.d.o properly

 Original Message 
Subject: Bug#688861: freeze exception: libxvmc/1.0.7-1.1 - adding a
libxvmc1-i386:i386 package
Resent-Date: Wed, 26 Sep 2012 12:09:06 +
Resent-From: Andreas 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 Beckmann deb...@abeckmann.de, 688...@bugs.debian.org
To: Debian Bug Tracking System sub...@bugs.debian.org

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please approve the following changes for package libxvmc

As we are not going to get libxvmc turned to multi-arch for wheezy (see
#640499) I'm now trying another approach with minimal changes to the
libxvmc package:

Can we add a new package

Package: libxvmc1-i386
Section: libs
Priority: extra
Architecture: i386
Multi-arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common
Description: X11 Video extension library (alternate i386 package)

that ships another copy of the libraries in /usr/lib/i386-linux-gnu/
To avoid installing libxvmc1-i386:i386 and libxvmc1:i386 at the same
time and have two copies of the same library available, I'm adding

Package: libxvmc1
Conflicts: libxvmc1-i386 [i386]

and to avoid picking up a dependency on libxvmc1-i386 by accident, its
shlibs file points to libxvmc1.

I added a lintian-overrides file, but that is not being installed as I
wanted to avoid changing anything in debian/rules.

Note that this new package does not ship the conffile as it is expected
to be only installed along libxvmc1:amd64 which comes with the conffile.
(This dependency can't be expressed by package relationships.)

This will keep the existing non-multiarch libxvmc1 unchanged, the build
system is untouched, nothing will start to use the alternate copy
package accidently. For libgl1-nvidia-glx:i386 to actually pick up this
alternate library, we need to add a shlibs.local file (in
nvidia-graphics-drivers) with

libXvMC 1 libxvmc1 | libxvmc1-i386 [i386]

I chose to add the extra package to the libxvmc source package as that
will avoid forking (and therefore code duplication) and getting libxvmc1
and libxvmc1-i386 out of sync. Even with a second copy in the a binary
package in the archive, there is no overhead in case a security update
for libxvmc should be neccessary.

Judging by the number of bug reports, it is really important for our
users to restore the ability to run 32-bit OpenGL applications on a
amd64 system and get accelleration by the non-free nvidia driver.
That was working in squeeze and will be considered as a serious
regression if this is not getting fixed in some way for wheezy.
See e.g. #685054, #686033, #676723, #688714

I'll be happy to assist getting a proper multi-arch libxvmc into jessie
and to clean up this temporary package that we need for wheezy.


Andreas

diffstat for libxvmc_1.0.7-1 libxvmc_1.0.7-1.1

 debian/libxvmc1-i386.install   |2 ++
 debian/libxvmc1-i386.lintian-overrides |4 
 debian/libxvmc1-i386.shlibs|2 ++
 libxvmc-1.0.7/debian/changelog |   12 
 libxvmc-1.0.7/debian/control   |   26 ++
 5 files changed, 46 insertions(+)

diff -u libxvmc-1.0.7/debian/control libxvmc-1.0.7/debian/control
--- libxvmc-1.0.7/debian/control
+++ libxvmc-1.0.7/debian/control
@@ -22,6 +22,7 @@
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common
+Conflicts: libxvmc1-i386 [i386]
 Description: X11 Video extension library
  libXvMC provides an X Window System client interface to the
  XVideo-MotionCompensation extension to the X protocol.
@@ -37,6 +38,31 @@
  This module can be found at
  git://anongit.freedesktop.org/git/xorg/lib/libXvMC
 
+Package: libxvmc1-i386
+Section: libs
+Priority: extra
+Architecture: i386
+Multi-arch: same
+Pre-Depends: ${misc:Pre-Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common
+Description: X11 Video extension library (alternate i386 package)
+ libXvMC provides an X Window System client interface to the
+ XVideo-MotionCompensation extension to the X protocol.
+ .
+ The XVideo-MotionCompensation extension allows for further accelerated drawing
+ of videos.  Video data may be sent at earlier stages of the decoding pipeline
+ than raw YUV data.  At the moment, driver support for XvMC is poor to
+ non-existent.
+ .
+ More information about X.Org can be found at:
+ URL:http://www.X.org
+ .
+ This module can be found at
+ git://anongit.freedesktop.org/git/xorg/lib/libXvMC

Bug#640499: libxvmc: please add multiarch support

[Andreas Beckmann]

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 upgrade and install paths paths of this scenario been tested? And the 
case of locally modified/removed config files?

I'll take libfoo as an example package that ships /etc/foo.conf

apt-get install libfoo:arch1
modify-or-delete /etc/foo.conf
apt-get install libfoo:arch2

# libfoo=1 is available
apt-get install libfoo:arch1=1 libfoo:arch2=1
modify-or-delete /etc/foo.conf
apt-get update # makes libfoo=2 available
# libfoo=2 comes with a modified foo.conf
apt-get dist-upgrade

# libfoo=1 is available
apt-get install libfoo:arch1=1 libfoo:arch2=1
apt-get update # makes libfoo=2 available
# libfoo=2 uses dpkg-maintscript-helper to get rid of foo.conf
apt-get dist-upgrade

Just curious ...

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.org/201208180109.11567.deb...@abeckmann.de

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

[Andreas Beckmann]

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 maintainer scripts are entirely debhelper generated, so the
xfonts-tipa package is not doing something wrong, this is part of the
postinst:
  # Automatically added by dh_installxfonts
  if which update-fonts-dir /dev/null 21; then
update-fonts-dir --x11r7-layout encodings;update-fonts-scale 
Type1;update-fonts-dir --x11r7-layout Type1
  fi
  # End automatically added section
Thereafter:
  debsums: missing file /usr/share/fonts/X11/encodings/encodings.dir (from 
xfonts-encodings package)

Is it correct that encodings.dir is shipped by xfonts-encodings?
Shouldn't that be generated by maintainer scripts? Otherwise the 
  update-fonts-dir --x11r7-layout encodings
will always modify shipped files.

Why does the encodings.dir file get deleted at all? That directory is
not empty ...

I'm assigning this bug to three packages that could possibly be at
fault:
* xfonts-utils - update-fonts-dir deletes encodings.dir, but dir is not
  empty
* xfonts-encodings - ships encodings.dir
* debhelper - could have generated a wrong call

Please analyze and reassign.

piuparts log from xfonts-tipa is attached.


Andreas


xfonts-tipa_2:1.3-17.log.gz
Description: GNU Zip compressed data

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

[Andreas Beckmann]

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)

/usr/share/fonts/X11/encodings/encodings.dir should not disappear, test with
  debsums xfonts-encodings


Andreas

PS: You probably want to do this, too:

bts reassign 682939 xfonts-tipa 2:1.3-17


-- 
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.org/50127cc9.2010...@abeckmann.de

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

[Andreas Beckmann]

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 implementations, I propose
to ship the MESA libraries in $libdir/mesa/ with symlinks to libGL.so.1
and libGL.so in $libdir/
This is a first start and helps to reduce the number of diversions
needed.
The next step would be the use of some alternatives system directly
in the MESA packages (that needs to be multi-arch aware). This will
remove the need for diversions at all, but needs more discussion ...

I also sent some patches to debian-x@ but never submitted a bug report,
so these patches for moving libGL* probably were forgotten:
http://lists.debian.org/debian-x/2011/10/msg00149.html (for GL)
http://lists.debian.org/debian-x/2011/10/msg00378.html (for EGL, GLES)

If anyone is interested, I'll update the patches for MESA 8.


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.org/20120525125648.32290.48480.report...@cake.ae.cs.uni-frankfurt.de

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

[Andreas Beckmann]

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-abi-10
the same version is in sid (except for the +exp? suffix) but had some
binNMUs inbetween

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.org/4f5d4fd3.8040...@abeckmann.de

Re: New X stack backport?

[Andreas Beckmann]

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 from my repository if that's
 not enough.

Maintaining the non-free graphics drivers (nvidia, nvidia-legacy-173xx,
nvidia-legacy-96xx, fglrx), I'd like to keep the old Xserver versions
available. The proprietary drivers are compatible with all old video-abi
versions, but it usually takes some time until they add support for new
Xserver releases (which bump the abi).

Right now Xserver 1.10 from squeeze-backports is needed for the
nvidia-legacy drivers in sid (upstream has not yet abandoned them, but
not yet made a release supporting 1.11 in wheezy/sid) and I'm
considering backporting the legacy drivers to squeeze-backports, too
(would e.g. add support for the backports kernel and we could point
users to a place where a working combination of Xorg + legacy driver is
available).

Current nvidia-glx in squeeze-backports, wheezy and sid work in 1.11,
but there may be issues that do not occur in 1.10.

fglrx now supports 1.11, but there still seem to be issues ...
(fglrx backport is ancient ... requiring Xserver from squeeze not backports)

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.org/4f0ef922.5060...@abeckmann.de

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

[Andreas Beckmann]

Install libEGL.so*, libGLESv1_CM.so*, and libGLESv2.so* into $libdir/mesa/
instead of $libdir/ and add symlinks for lib*.so and lib*.so.[12] (but not
lib*.so.[12].*) to $libdir.

This is a preparation for supporting alternative implementations of libEGL
and libGLES (currently only a non-free 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...@abeckmann.de

---
 debian/libegl1-mesa-dev.install.in  |2 +-
 debian/libegl1-mesa-dev.links.in|1 +
 debian/libegl1-mesa.install.in  |2 +-
 debian/libegl1-mesa.links.in|1 +
 debian/libgles1-mesa-dev.install.in |2 +-
 debian/libgles1-mesa-dev.links.in   |1 +
 debian/libgles1-mesa.install.in |2 +-
 debian/libgles1-mesa.links.in   |1 +
 debian/libgles2-mesa-dev.install.in |2 +-
 debian/libgles2-mesa-dev.links.in   |1 +
 debian/libgles2-mesa.install.in |2 +-
 debian/libgles2-mesa.links.in   |1 +
 12 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/debian/libegl1-mesa-dev.install.in 
b/debian/libegl1-mesa-dev.install.in
index 3f3094f..5a41338 100644
--- a/debian/libegl1-mesa-dev.install.in
+++ b/debian/libegl1-mesa-dev.install.in
@@ -1,4 +1,4 @@
-dri/usr/lib/${DEB_HOST_MULTIARCH}/libEGL.so usr/lib/${DEB_HOST_MULTIARCH}
+dri/usr/lib/${DEB_HOST_MULTIARCH}/libEGL.so usr/lib/${DEB_HOST_MULTIARCH}/mesa
 #dri/usr/lib/${DEB_HOST_MULTIARCH}/libwayland-egl.so 
usr/lib/${DEB_HOST_MULTIARCH}
 dri/usr/include/EGL usr/include
 dri/usr/include/KHR usr/include
diff --git a/debian/libegl1-mesa-dev.links.in b/debian/libegl1-mesa-dev.links.in
new file mode 100644
index 000..da31542
--- /dev/null
+++ b/debian/libegl1-mesa-dev.links.in
@@ -0,0 +1 @@
+usr/lib/${DEB_HOST_MULTIARCH}/mesa/libEGL.so 
usr/lib/${DEB_HOST_MULTIARCH}/libEGL.so
diff --git a/debian/libegl1-mesa.install.in b/debian/libegl1-mesa.install.in
index 57d1a21..f6ef698 100644
--- a/debian/libegl1-mesa.install.in
+++ b/debian/libegl1-mesa.install.in
@@ -1 +1 @@
-dri/usr/lib/${DEB_HOST_MULTIARCH}/libEGL.so.1* usr/lib/${DEB_HOST_MULTIARCH}
+dri/usr/lib/${DEB_HOST_MULTIARCH}/libEGL.so.1* 
usr/lib/${DEB_HOST_MULTIARCH}/mesa
diff --git a/debian/libegl1-mesa.links.in b/debian/libegl1-mesa.links.in
new file mode 100644
index 000..537e2c6
--- /dev/null
+++ b/debian/libegl1-mesa.links.in
@@ -0,0 +1 @@
+usr/lib/${DEB_HOST_MULTIARCH}/mesa/libEGL.so.1 
usr/lib/${DEB_HOST_MULTIARCH}/libEGL.so.1
diff --git a/debian/libgles1-mesa-dev.install.in 
b/debian/libgles1-mesa-dev.install.in
index 0485b23..df6458d 100644
--- a/debian/libgles1-mesa-dev.install.in
+++ b/debian/libgles1-mesa-dev.install.in
@@ -1,3 +1,3 @@
-dri/usr/lib/${DEB_HOST_MULTIARCH}/libGLESv1_CM.so usr/lib/${DEB_HOST_MULTIARCH}
+dri/usr/lib/${DEB_HOST_MULTIARCH}/libGLESv1_CM.so 
usr/lib/${DEB_HOST_MULTIARCH}/mesa
 dri/usr/include/GLES usr/include
 dri/usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/glesv1_cm.pc 
usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
diff --git a/debian/libgles1-mesa-dev.links.in 
b/debian/libgles1-mesa-dev.links.in
new file mode 100644
index 000..3d5288b
--- /dev/null
+++ b/debian/libgles1-mesa-dev.links.in
@@ -0,0 +1 @@
+usr/lib/${DEB_HOST_MULTIARCH}/mesa/libGLESv1_CM.so 
usr/lib/${DEB_HOST_MULTIARCH}/libGLESv1_CM.so
diff --git a/debian/libgles1-mesa.install.in b/debian/libgles1-mesa.install.in
index 143abd2..aa568d8 100644
--- a/debian/libgles1-mesa.install.in
+++ b/debian/libgles1-mesa.install.in
@@ -1 +1 @@
-dri/usr/lib/${DEB_HOST_MULTIARCH}/libGLESv1_CM.so.1* 
usr/lib/${DEB_HOST_MULTIARCH}
+dri/usr/lib/${DEB_HOST_MULTIARCH}/libGLESv1_CM.so.1* 
usr/lib/${DEB_HOST_MULTIARCH}/mesa
diff --git a/debian/libgles1-mesa.links.in b/debian/libgles1-mesa.links.in
new file mode 100644
index 000..f6b8d8a
--- /dev/null
+++ b/debian/libgles1-mesa.links.in
@@ -0,0 +1 @@
+usr/lib/${DEB_HOST_MULTIARCH}/mesa/libGLESv1_CM.so.1 
usr/lib/${DEB_HOST_MULTIARCH}/libGLESv1_CM.so.1
diff --git a/debian/libgles2-mesa-dev.install.in 
b/debian/libgles2-mesa-dev.install.in
index ae8fe70..eaae986 100644
--- a/debian/libgles2-mesa-dev.install.in
+++ b/debian/libgles2-mesa-dev.install.in
@@ -1,3 +1,3 @@
-dri/usr/lib/${DEB_HOST_MULTIARCH}/libGLESv2.so usr/lib/${DEB_HOST_MULTIARCH}
+dri/usr/lib/${DEB_HOST_MULTIARCH}/libGLESv2.so 
usr/lib/${DEB_HOST_MULTIARCH}/mesa
 dri/usr/include/GLES2 usr/include
 dri/usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/glesv2.pc 
usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
diff --git a/debian/libgles2-mesa-dev.links.in 
b/debian/libgles2-mesa-dev.links.in
new file mode 100644
index 000..328ade9
--- /dev/null
+++ b/debian/libgles2-mesa-dev.links.in
@@ -0,0 +1 @@
+usr/lib/${DEB_HOST_MULTIARCH}/mesa/libGLESv2.so 
usr/lib/${DEB_HOST_MULTIARCH}/libGLESv2.so
diff --git a/debian/libgles2-mesa.install.in b/debian/libgles2-mesa.install.in

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

[Andreas Beckmann]

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
.git/gbp.conf so that it does export the git tree and run the symlink
dance automatically? This works for me:

[git-buildpackage]
prebuild = find -type l | while read dest; do src=$(readlink -f $dest);
rm $dest; cp $src $dest; done
export-dir = ../build-area/
tarball-dir = ../tarballs/

Also it would be nice if README.source would have a link to
http://pkg-xorg.alioth.debian.org/
(and eventually other places with XSF packaging related information)
- this probably applies to all packages managed by XSF. Makes it easier
for non-XSF people to start hacking X properly :-)

Something I didn't find so far are instructions how you would like to
get patches submitted.

Some minor updates for http://wiki.debian.org/Xorg:
* wheezy has xserver-xorg-core 1.11
* In the Video Drivers section, can you add a link to
  http://wiki.debian.org/NvidiaGraphicsDrivers?
  (This page mainly talks about the non-free driver).


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.org/4e9c00c6.6030...@abeckmann.de

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

[Andreas Beckmann]

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 (allows weird mixed
 configurations)

This is probably the way to go since there may be many valid
combinations thanks to multiarch.
Eventually a new update-glx utility could be introduced that allows
easy configuration of sane combinations:
  update-glx --set nvidia
which would update the libGL.so.1 alternatives for i386 and amd64 (if
available)

 * one alternative (from an extra Multi-Arch: foreign package) that
 covers all arches as slaves links?

That's the way currently done by glx-alternatives - but it only covers
amd64 and i386, a generic extension will be difficult.

 * the Ubuntu approach of dropping something in ld.so.conf.d/ - would we
...
 Pretty please not messing with ld.so.conf.

OK, lets forget about this.


I'm about to send a patch for MESA which moves libGL.so* from $libdir to
$libdir/mesa/ and adds libGL.so and libGL.so.1 symlinks from $libdir to
the file in $libdir/mesa/.

This is a preparative step, the links in $libdir are to be replaced by
alternatives later on. For now, they will still be diverted by
glx-diversions. glx-alternative-mesa has already been updated to take
$libdir/mesa into account.

To effectively use diversions, the real files (libGL.so.1.*) need to be
moved out of $libdir, otherwise ldconfig may mess up the SONAME links.
With the current change it will already be possible to stop diverting
libGL.so.

I did not yet look into EGL, but I think it needs to be done similarily
there - move all libs that may get alternatives to $libdir/mesa/


Does XSF plan to backport MESA 7.11 to squeeze-backports? Is there a
planned timeframe? If my patch for the directory structure is accepted
and will go to squeeze-backports, too, it would significantly simplify
my plans for backporting nvidia-graphics-drivers.

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.org/4e9c1a11.7030...@abeckmann.de

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

[Andreas Beckmann]

Install libGL.so* into $libdir/mesa/ instead of $libdir/ and add symlinks
for libGL.so and libGL.so.1 (but not libGL.so.1.*) to $libdir.

This is a preparation for simplifying the usage (aka avoid diversions) of
alternative implementations of libGL (currently only non-free alternatives
from NVIDIA 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

---
 debian/libgl1-mesa-dev.install.in   |2 +-
 debian/libgl1-mesa-dev.links.in |1 +
 debian/libgl1-mesa-glx.install.in   |2 +-
 debian/libgl1-mesa-glx.links.in |1 +
 debian/libgl1-mesa-swx11-dev.install.in |2 +-
 debian/libgl1-mesa-swx11-dev.links.in   |1 +
 debian/libgl1-mesa-swx11.install.in |2 +-
 debian/libgl1-mesa-swx11.links.in   |1 +
 8 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/debian/libgl1-mesa-dev.install.in 
b/debian/libgl1-mesa-dev.install.in
index d915191..5521ac9 100644
--- a/debian/libgl1-mesa-dev.install.in
+++ b/debian/libgl1-mesa-dev.install.in
@@ -1,2 +1,2 @@
-usr/lib/${DEB_HOST_MULTIARCH}/libGL.so
+usr/lib/${DEB_HOST_MULTIARCH}/libGL.so 
usr/lib/${DEB_HOST_MULTIARCH}/mesa/
 usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/gl.pc
diff --git a/debian/libgl1-mesa-dev.links.in b/debian/libgl1-mesa-dev.links.in
new file mode 100644
index 000..3bedd3b
--- /dev/null
+++ b/debian/libgl1-mesa-dev.links.in
@@ -0,0 +1 @@
+usr/lib/${DEB_HOST_MULTIARCH}/mesa/libGL.so 
usr/lib/${DEB_HOST_MULTIARCH}/libGL.so
diff --git a/debian/libgl1-mesa-glx.install.in 
b/debian/libgl1-mesa-glx.install.in
index f5ffd7a..2f5e1ad 100644
--- a/debian/libgl1-mesa-glx.install.in
+++ b/debian/libgl1-mesa-glx.install.in
@@ -1 +1 @@
-dri/usr/lib/${DEB_HOST_MULTIARCH}/libGL.so.* usr/lib/${DEB_HOST_MULTIARCH}
+dri/usr/lib/${DEB_HOST_MULTIARCH}/libGL.so.* 
usr/lib/${DEB_HOST_MULTIARCH}/mesa/
diff --git a/debian/libgl1-mesa-glx.links.in b/debian/libgl1-mesa-glx.links.in
new file mode 100644
index 000..4cc810f
--- /dev/null
+++ b/debian/libgl1-mesa-glx.links.in
@@ -0,0 +1 @@
+usr/lib/${DEB_HOST_MULTIARCH}/mesa/libGL.so.1 
usr/lib/${DEB_HOST_MULTIARCH}/libGL.so.1
diff --git a/debian/libgl1-mesa-swx11-dev.install.in 
b/debian/libgl1-mesa-swx11-dev.install.in
index 8318ac8..73aef2a 100644
--- a/debian/libgl1-mesa-swx11-dev.install.in
+++ b/debian/libgl1-mesa-swx11-dev.install.in
@@ -1,2 +1,2 @@
 usr/lib/${DEB_HOST_MULTIARCH}/libGL.a
-usr/lib/${DEB_HOST_MULTIARCH}/libGL.so
+usr/lib/${DEB_HOST_MULTIARCH}/libGL.so usr/lib/${DEB_HOST_MULTIARCH}/mesa/
diff --git a/debian/libgl1-mesa-swx11-dev.links.in 
b/debian/libgl1-mesa-swx11-dev.links.in
new file mode 100644
index 000..3bedd3b
--- /dev/null
+++ b/debian/libgl1-mesa-swx11-dev.links.in
@@ -0,0 +1 @@
+usr/lib/${DEB_HOST_MULTIARCH}/mesa/libGL.so 
usr/lib/${DEB_HOST_MULTIARCH}/libGL.so
diff --git a/debian/libgl1-mesa-swx11.install.in 
b/debian/libgl1-mesa-swx11.install.in
index d333e7b..9d89c20 100644
--- a/debian/libgl1-mesa-swx11.install.in
+++ b/debian/libgl1-mesa-swx11.install.in
@@ -1 +1 @@
-usr/lib/${DEB_HOST_MULTIARCH}/libGL.so.*
+usr/lib/${DEB_HOST_MULTIARCH}/libGL.so.*   
usr/lib/${DEB_HOST_MULTIARCH}/mesa/
diff --git a/debian/libgl1-mesa-swx11.links.in 
b/debian/libgl1-mesa-swx11.links.in
new file mode 100644
index 000..4cc810f
--- /dev/null
+++ b/debian/libgl1-mesa-swx11.links.in
@@ -0,0 +1 @@
+usr/lib/${DEB_HOST_MULTIARCH}/mesa/libGL.so.1 
usr/lib/${DEB_HOST_MULTIARCH}/libGL.so.1
-- 
tg: (63e119d..) t/use-libdir-mesa (depends on: debian-unstable)


-- 
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.org/1318855656-23366-1-git-send-email-deb...@abeckmann.de

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

[Andreas Beckmann]

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 UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e7d89b9.2010...@abeckmann.de

Bug#641344: Bug#641413: X crashes

[Andreas Beckmann]

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 in a separate bug
report, but Nvidia already seems to investigate this:
http://www.nvnews.net/vbulletin/showthread.php?p=2479906#post2479906

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.org/4e734235.10...@abeckmann.de

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

[Andreas Beckmann]

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-xserver from git and
 the offending symbols are renamed, but I couldn't verify that it fixes
 the rendering errors as I cannot reproduce them.

I just got confirmation from three users (#641344, #641413) that the
patched libwfb.so fixes the issue.

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.org/4e73442d.2080...@abeckmann.de

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

[Andreas Beckmann]

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-devel/2011-September/025062.html
thanks

On 2011-09-12 20:25, Franz Schrober wrote:
 I have a lot of graphics errors after updating my system to the
 xserver with abi 11. It is hard to write the bug report because I
 cannot see many gui elements in kde 4. They look like the screen
 errors I got after using the nvidia driver 285 with the ignore abi
 option and the abi 11 xorg.

NVIDIA tracked this problem down to a bug in libwfb.so and provided a
patch:
http://www.nvnews.net/vbulletin/showthread.php?t=166025page=2
http://lists.x.org/archives/xorg-devel/2011-September/025062.html
http://lists.x.org/archives/xorg-devel/2011-September/025082.html

I verified that the attached patch works with xorg-xserver from git and
the offending symbols are renamed, but I couldn't verify that it fixes
the rendering errors as I cannot reproduce them.


Andreas


16-add-missing-libwfb-renames.diff
Description: application/pgp-keys

Bug#640499: libxvmc: please add multiarch support

[Andreas Beckmann]

Package: libxvmc
Version: 2:1.0.6-1
Severity: wishlist
Tags: patch

Please rebuild libxvmc with multiarch support.
Attached patch is modeled after the multiarch changes in libxv.
I'm not sure how to handle /etc/X11/XvMCConfig correctly, might have
to be moved to a separate package libxvmc-config?

Andreas

-- System Information:
Debian Release: 6.0.2
  APT prefers stable
  APT policy: (800, 'stable'), (700, 'testing'), (600, 'unstable'), (500, 
'stable-updates'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.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 deb...@abeckmann.de
Date: Mon, 5 Sep 2011 12:28:14 +0200
Subject: [PATCH] build for multiarch

---
 debian/changelog   |1 +
 debian/control |5 -
 debian/libxvmc-dev.install |   10 +-
 debian/libxvmc1.install|4 ++--
 debian/rules   |3 +++
 5 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 844e6e7..7b9e6c1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,7 @@ libxvmc (2:1.0.6-2) UNRELEASED; urgency=low
 
   * Rename the build directory to not include DEB_BUILD_GNU_TYPE for no
 good reason. Thanks, Colin Watson!
+  * Build for multiarch.
 
  -- Cyril Brulebois k...@debian.org  Mon, 04 Apr 2011 05:56:30 +0200
 
diff --git a/debian/control b/debian/control
index 7a1914d..9df60c2 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: optional
 Maintainer: Debian X Strike Force debian-x@lists.debian.org
 Uploaders: David Nusinow dnusi...@debian.org, Andres Salomon 
dilin...@debian.org, Drew Parsons dpars...@debian.org, Cyril Brulebois 
k...@debian.org
 Build-Depends:
- debhelper (= 5.0.0),
+ debhelper (= 8.1.3),
  libx11-dev (= 1:0.99.2),
  libxext-dev (= 1:0.99.1),
  x11proto-video-dev,
@@ -21,6 +21,8 @@ Vcs-Browser: http://git.debian.org/?p=pkg-xorg/lib/libxvmc.git
 Package: libxvmc1
 Section: libs
 Architecture: any
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}, x11-common
 Description: X11 Video extension library
  libXvMC provides an X Window System client interface to the
@@ -63,6 +65,7 @@ Description: X11 Video extension library (debug package)
 Package: libxvmc-dev
 Section: libdevel
 Architecture: any
+Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}, libxvmc1 (= ${binary:Version}), 
libx11-dev (= 2:1.0.0-1), libxext-dev (= 1:1.0.0-2), x11proto-video-dev, 
libxv-dev
 Conflicts: x11proto-video-dev ( 2.2+cvs.20050712-1)
 Replaces: x11proto-video-dev ( 2.2+cvs.20050712-1)
diff --git a/debian/libxvmc-dev.install b/debian/libxvmc-dev.install
index a8b1a8f..ce042b1 100644
--- a/debian/libxvmc-dev.install
+++ b/debian/libxvmc-dev.install
@@ -1,7 +1,7 @@
 usr/include/X11/*
-usr/lib/libXvMC.a
-usr/lib/libXvMC.so
-usr/lib/libXvMCW.a
-usr/lib/libXvMCW.so
-usr/lib/pkgconfig/xvmc.pc
+usr/lib/*/libXvMC.a
+usr/lib/*/libXvMC.so
+usr/lib/*/libXvMCW.a
+usr/lib/*/libXvMCW.so
+usr/lib/*/pkgconfig/xvmc.pc
 usr/share/doc/libXvMC/* usr/share/doc/libxvmc-dev
diff --git a/debian/libxvmc1.install b/debian/libxvmc1.install
index fe81455..71856ed 100644
--- a/debian/libxvmc1.install
+++ b/debian/libxvmc1.install
@@ -1,3 +1,3 @@
-usr/lib/libXvMC.so.1*
-usr/lib/libXvMCW.so.1*
+usr/lib/*/libXvMC.so.1*
+usr/lib/*/libXvMCW.so.1*
 etc/X11/XvMCConfig
diff --git a/debian/rules b/debian/rules
index 0b5ec6f..17b82d0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,6 +10,8 @@
 # set this to the name of the main shlib's binary package
 PACKAGE = libxvmc1
 
+DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+
 include debian/xsfbs/xsfbs.mk
 
 CFLAGS = -Wall -g
@@ -40,6 +42,7 @@ build-stamp:
mkdir -p build
cd build  \
../configure --prefix=/usr \
+--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
 --sysconfdir=/etc --mandir=\$${prefix}/share/man \
 --infodir=\$${prefix}/share/info $(confflags) \
 CFLAGS=$(CFLAGS) 
-- 
1.7.2.5

Re: Xorg module searchpath override directory

[Andreas Beckmann]

Hi all,

since I didn't get any feedback, yet, I'm asking again.

Are there any objections to installing the alternative slave link for
vendor implemntations of libglx.so as
  /usr/lib/xorg/modules/linux/libglx.so
and leave
  /usr/lib/xorg/modules/extensions/libglx.so
undiverted?
According 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:
 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 priority alternative
 in a different location where it would be picked up before
 /usr/lib/xorg/modules/extensions/libglx.so ? That would allow to avoid
 the diversion here. Something similar to /lib/modules/*/updates/ ...

 That shouldn't be too hard.
 
 I tried to look in the code (xorg-server (2:1.7.7-13)
 hw/xfree86/loader/* ; the experimental version does not differ much in
 that area) but didn't quite get how the search path is working.
 Therefore I added a bit debugging code to trace FindModuleInSubdir().
 Translating to pseudocode this now looks like
 
 modulepath=/usr/lib/xorg/modules
 for subdir in  input drivers multimedia extensions internal
 do
   search_recursive ${modulepath}/${subdir}/linux/
   search_recursive ${modulepath}/${subdir}/
 done
 
 So the order the directories are traversed and files are found depends
 on the raw order in the filesystem (opendir()), except for the linux
 subdir which is checked first.
 
 hw/xfree86/loader/loadmod.c has
 /* Standard set of module subdirectories to search, in order of
 preference */
 static const char *stdSubdirs[] = {
 ,
 input/,
 drivers/,
 multimedia/,
 extensions/,
 internal/,
 NULL
 };
 
 but since a recursive search is done on  first, the other directories
 in the list will be traversed (again and without hope of success) only
 if the first search was unsuccessful. So that order of preference is
 no more existant and the above pseudocode could be simplified to
 
 modulepath=/usr/lib/xorg/modules
 search_recursive ${modulepath}/linux/
 search_recursive ${modulepath}/
 
 
 Back to the original problem: replacing libglx.so with a vendor
 implementation without using diversions.
 I'd do the following:
 
 * leave /usr/lib/xorg/modules/extensions/libglx.so where it is
   (i.e. no longer divert it)
 * the proprietary drivers register their libglx.so replacement with the
   glx alternative which installs it as a slave link to
   /usr/lib/xorg/modules/linux/libglx.so
   so that it is picked up first and the original one is being ignored
 
 linux is acually OSDIR in the code and may have had a different
 intention, but it is the only deterministic place that is searched
 before extensions/libglx.so
 
 * no changes in Xorg needed regarding the search paths
 * works on both unstable and squeeze, so backports don't need special
   handling
 
 If this is OK, I'll implement and test it and also verify that Xorg
 works in the same way in testing/unstable/experimental.
 That way, the first of the ugly diversions could be removed. :-)
 
 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.org/4e5373a6.2070...@abeckmann.de

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

[Andreas Beckmann]

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 prepended to the module
search path.
In [1] I describe my analysis of the current search path system and in
[2] Julien says
I'd prefer an explicit override directory over abusing 'linux'.

An override directory could be used so that vendor implementations of a
module (e.g. libglx.so) can be installed installed in the override
directory and will be found before the native xorg module without having
to use dpkg-divert on the original module. Such a solution would simplify
using update-alternatives to enable/disable the vendor implementation
without installing/removing packages.

For the time being, /usr/lib/xorg/modules/linux/ could be abused for
that purpose.

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.org/20110823113812.26681.77327.reportbug@calzone.localnet

Re: Xorg module searchpath override directory

[Andreas Beckmann]

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 directory over abusing 'linux'.

OK, just opened wishlist bug #638965 against xserver-xorg-core.
http://bugs.debian.org/638965

Until this explicit override directory gets implemented and for
squeeze-backports (which needs newer versions of nvidia-graphics-drivers
for supporting newer GPUs), would you agree if I use modules/linux for now?
That way the first of the diversions can be eliminated and we can go
back to the other question How to reorganize the mesa packages to avoid
diversions when installing a vendor libGL.so.1.

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.org/4e53947c.2080...@abeckmann.de

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

[Andreas Beckmann]

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 priority alternative
 in a different location where it would be picked up before
 /usr/lib/xorg/modules/extensions/libglx.so ? That would allow to avoid
 the diversion here. Something similar to /lib/modules/*/updates/ ...

 That shouldn't be too hard.

I tried to look in the code (xorg-server (2:1.7.7-13)
hw/xfree86/loader/* ; the experimental version does not differ much in
that area) but didn't quite get how the search path is working.
Therefore I added a bit debugging code to trace FindModuleInSubdir().
Translating to pseudocode this now looks like

modulepath=/usr/lib/xorg/modules
for subdir in  input drivers multimedia extensions internal
do
search_recursive ${modulepath}/${subdir}/linux/
search_recursive ${modulepath}/${subdir}/
done

So the order the directories are traversed and files are found depends
on the raw order in the filesystem (opendir()), except for the linux
subdir which is checked first.

hw/xfree86/loader/loadmod.c has
/* Standard set of module subdirectories to search, in order of
preference */
static const char *stdSubdirs[] = {
,
input/,
drivers/,
multimedia/,
extensions/,
internal/,
NULL
};

but since a recursive search is done on  first, the other directories
in the list will be traversed (again and without hope of success) only
if the first search was unsuccessful. So that order of preference is
no more existant and the above pseudocode could be simplified to

modulepath=/usr/lib/xorg/modules
search_recursive ${modulepath}/linux/
search_recursive ${modulepath}/


Back to the original problem: replacing libglx.so with a vendor
implementation without using diversions.
I'd do the following:

* leave /usr/lib/xorg/modules/extensions/libglx.so where it is
  (i.e. no longer divert it)
* the proprietary drivers register their libglx.so replacement with the
  glx alternative which installs it as a slave link to
  /usr/lib/xorg/modules/linux/libglx.so
  so that it is picked up first and the original one is being ignored

linux is acually OSDIR in the code and may have had a different
intention, but it is the only deterministic place that is searched
before extensions/libglx.so

* no changes in Xorg needed regarding the search paths
* works on both unstable and squeeze, so backports don't need special
  handling

If this is OK, I'll implement and test it and also verify that Xorg
works in the same way in testing/unstable/experimental.
That way, the first of the ugly diversions could be removed. :-)

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.org/4e42f368.7030...@abeckmann.de

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

[Andreas Beckmann]

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 of search
 path magic that would allow to place the higher priority alternative
 in a different location where it would be picked up before
 /usr/lib/xorg/modules/extensions/libglx.so ? That would allow to avoid
 the diversion here. Something similar to /lib/modules/*/updates/ ...

 That shouldn't be too hard.
 
 But it would result in the non-standard libglx.so being picked up even
 when the standard GL(X) components are supposed to be used. So I think
 libglx.so would need to be handled by the alternative as well.

The idea is still to handle the non-standard libglx.so by an
alternative. This will be installed in the search path before the
standard libglx.so. So we can stop diverting the standard libglx.so
simplifying the whole process.

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.org/4e3a91ff.4080...@abeckmann.de

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

[Andreas Beckmann]

[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 countless bug in the current system is diversions, because
 they're evil, and people keep getting them wrong, and users don't
 understand/expect them, and all kinds of fun ensues.  If mesa were to
 not ship the /usr/lib/$arch/libGL.so.1 (and friends) symlink, but
 instead ship an alternative itself, would that be enough to put an end
 to the diversions?  Not that I think alternatives are ideal either, but
 if we're going to have to put up with something I'd rather it wasn't
 *both* alternatives and diversions.

 Not sure what other X people think.
 
 I'd rather avoid the mess of diversions *AND* alternatives indeed. If
 adding alternative support to mesa is the price to pay, I guess we could
 work something out.

OK, that is a different solution that should simplify this even more.

What is the correct approach to do alternatives of libraries in
Multi-Arch: yes packages?
* a separate alternative for each architecture (allows weird mixed
configurations)
* one alternative (from an extra Multi-Arch: foreign package) that
covers all arches as slaves links?
* the Ubuntu approach of dropping something in ld.so.conf.d/ - would we
need one file/one alternative per arch? (I didn't look in detail at the
Ubuntu packages, yet.) A gain handling config files with alternatives
... but this time config files that are not meant for user modification
(compared to my approach to handle xorg.conf or xorg.conf.d/nvidia.conf
with alternatives)

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 priority alternative
in a different location where it would be picked up before
/usr/lib/xorg/modules/extensions/libglx.so ? That would allow to avoid
the diversion here. Something similar to /lib/modules/*/updates/ ...

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.org/4e2da06d.1050...@abeckmann.de

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

[Andreas Beckmann]

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.
Unfortunately the diversions require quite some knowledge about the
files shipped by the MESA packages.
Therefore I suggest the following new layout to be used by the MESA
packages to simplify diversions and alternatives:

/usr/lib[/triplet]/mesa:
  libFOO.so.1.2.3
  libFOO.so.1 - libFOO.so.1.2.3
  libFOO.so - libFOO.so.1

/usr/lib[/triplet]:
  libFOO.so.1 - mesa/libFOO.so.1
  libFOO.so - mesa/libFOO.so

(for appropriate substitutions of FOO, .1$ , .1.2.3$)

Behind this are the following ideas:

* move the real file (libFOO.so.1.2.3) out of the scope of ldconfig
(which could mess up the SONAME link otherwise)
* simplify diverting the libraries: one only needs to know the SONAME
(libFOO.so.1) but not the real filename (libFOO.so.1.2.3) which is
allowed to change (e.g. libgl1-mesa-swx11 changes the filename with each
new upstream release, so it's currently not divertible)
* only one diversion per library is needed
(/usr/lib[/triplet]/libFOO.so.1) instead of three (libFOO.so.1.2.3,
libFOO.so.1, libFOO.so)
* the libFOO.so link is not affected by a diversion of libFOO.so.1 -
which aides the following behaviour: link with the free mesa library
when building the application, but use the accelerated vendor library
when running the application
* mesa can be provided as a more obvious alternative /usr/lib/mesa

I wouldn't limit the new approach to a few architectures (amd64 and i386
need it right now, armel will need it for EGL, soon), as we don't know
where vendors will provide custom implementations in the future.

I can create a patch for the mesa packages in case someone is interested.


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.org/4e285ddc.2000...@abeckmann.de

Re: xorg configuration for the non-free nvidia driver

[Andreas Beckmann]

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 targets (#633627).

So does anyone have a suggestion how to simplify the configuration of
nvidia-glx using a different approach? This would be interesting mainly
for new installations, not updates.

* libGL.so.1 and libglx.so need to be replaced by the proprietary
  versions. This is done automatically by diversions (package
  glx-diversions) and (slave) alternatives (package glx-alternative-
  nvidia) upon installation of nvidia-glx. Manual reconfiguration (e.g.
  switching back to MESA) is easy and does not require package removal:
update-alternatives --configure glx
* an xorg.conf (or xorg.conf.d/ snippet) has to be created because xorg
  autoconfiguration does not detect the proprietary drivers, so we
  need a 'Driver nvidia' line somewhere. Autoconfig of modes etc.
  usually works fine.
  The user should be able to add more directives to customize his
  configuration (e.g. by using nvidia-settings or nvidia-xconfig).
  An xorg.conf with 'Driver nvidia' breaks Xorg if the proprietary
  driver is not available, e.g. the glx alternative is set to mesa. So
  the configuration using the proprietary driver should be moved out of
  the way in that case.
  The new apporach should be easily adaptable for other proprietary
  drivers, e.g. fglrx.


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.org/4e1c3a65.5030...@abeckmann.de

Re: xorg configuration for the non-free nvidia driver

[Andreas Beckmann]

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 on the
 first installation of xserver-xorg-video-nvidia* (recently split from
 nvidia-glx*), unless something is already configured manually.
 I would place this file as /etc/X11/nvidia.conf and use the glx
 alternatives system to install a slave alternative
 /etc/X11/xorg.conf.d/nvidia.conf pointing to this file. That way
 switching to/from nvidia's libGL.so.* and libglx.so would also
 enable/disable the config file.
 If this approach works out well for nvidia, I'll propose fglrx to do the

 Do you have any objections regarding this approach?

 Yes.  I don't think xorg.conf.d should be used for non-InputClass
 configuration sections at this point.  See also
 https://bugs.freedesktop.org/show_bug.cgi?id=32430

In that case, would it be OK to just install a slave alternative
directly as /etc/X11/xorg.conf?
The /etc/X11/nvidia.conf would be created only if there was no xorg.conf
previously (and no xorg.conf.d/*.conf with a 'Driver .*' line) and the
slave link will be created only if nvidia.conf exists.
So this should not interfere with systems where an xorg.conf already exists.

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.org/4e1b1345.7000...@abeckmann.de

Re: xorg configuration for the non-free nvidia driver

[Andreas Beckmann]

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 might end up confusing the alternatives
 database.

Replacing the link with a file is save (at first):

update-alternatives: warning: not replacing
/etc/X11/xorg.conf.d/nvidia.conf with a link

but unfortunately switching to an alternative that does not have this
slave causes update-alternatives to delete the file.

I'm going to check tonight whether this is a regression from the dpkg in
lenny.


Replacing the link with a different link would probably be ignored by
the alternatives system, e.g. the custom link would be replaced by the
alternative link on next update.


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.org/4e1b32fd.9010...@abeckmann.de

xorg configuration for the non-free nvidia driver

[Andreas Beckmann]

[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* (recently split from
nvidia-glx*), unless something is already configured manually.
I would place this file as /etc/X11/nvidia.conf and use the glx
alternatives system to install a slave alternative
/etc/X11/xorg.conf.d/nvidia.conf pointing to this file. That way
switching to/from nvidia's libGL.so.* and libglx.so would also
enable/disable the config file.
If this approach works out well for nvidia, I'll propose fglrx to do the
same.

Do you have any objections regarding this approach?
Should I use some ordering prefix for the link installed in
/etc/X11/xorg.conf.d, e.g. 42_nvidia.conf or z42_nvidia.conf?
Should I use a different filename?

Why is /etc/X11/xorg.conf.d/ not shipped by e.g. x11-common?

Thanks.

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.org/4e16c436.4050...@abeckmann.de

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

[Andreas Beckmann]

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 well). With the recent diversions and alternatives changes
regarding multi-arch support, all diversion handling has been
concentrated in the glx-diversions package. All nvidia and fglrx
packages depend on this package (usually indirectly via a longer
dependency chain) and glx-diversions now also has proper conflicts with
libgl1-mesa-swx11 (which is not divertible since the library file name
changes with each new upstream version).
Once multiarch aware nvidia-graphics-drivers and glx-alternatives
packages enter testing, the users will have less possibilities to break
their glx :-)

Therefore I suggest you remove this conflict, so you don't have to track
current and future possible conflictors.

Andreas

-- System Information:
Debian Release: 6.0.2
  APT prefers stable
  APT policy: (800, 'stable'), (750, 'oldstable'), (700, 'testing'), (600, 
'unstable'), (500, 'stable-updates'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
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.org/20110706190243.32438.55654.reportbug@calzone.localnet

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

[Andreas Beckmann]

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 working on updates (but this will have to go through NEW),
but for now people could keep working nvidia systems
using the Xorg/MESA versions in testing.
275.09.07-1 is a new upstream release to be uploaded soon and will be
the last version without a multiarch mesa fix.

Thanks

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.org/20110616131209.29078.82260.report...@cake.ae.cs.uni-frankfurt.de

Bug#629823: xterm and nvidia

[Andreas Beckmann]

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?

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.org/4df8646b.2060...@abeckmann.de

Re: Bug#629823: xterm and nvidia

[Andreas Beckmann]

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) and I have the
 same results:
 
 - only with kde4 air-oxygen theme there are some artefacts;

This is eventually a separate issue and should be tracked in its own bug
report.

 - with all I can maximize xterm but I can't return to normal dimensions
   (80x25).
 
 I have tested the last above with 2 pc with kde4 and Sid: my with nvidia
 and one with intel GPU. 
 
 So I think isn't a nvidia bugs.

OK, retitling and reassigning back to xterm. Let's focus on this issue
and the non-nvidia setup for now.

 After maximized xterm, the relate button icon don't change to maximize.
 It seems that the window is only stretched to max dimensions instead
 maximized.
 
 Before I haven't noted that because I don't use these buttons in my kde4
 configuration, but in front the pc with intel GPU I have the surprise ;)

Please use reportbug to give followup info to this bug from the intel
machine, so that it can recollect system information there.

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.org/4df1cf2d.6030...@abeckmann.de

Re: Diversions

[Andreas Beckmann]

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*
/usr/lib/xorg/modules/extensions/libglx.so

In the nvidia-glx bug-script (in SVN) I use the following to list the
interesting stuff about the links, diversions and alternatives:

cat  EOF 3
OpenGL and NVIDIA library files installed:
`ls -la /etc/alternatives/*libGL* /usr/lib/libGL.* /usr/lib/libGLcore*
/usr/lib/libnvidia* /usr/lib32/libGL.* /usr/lib32/libGLcore*
/usr/lib32/libnvidia* 2/dev/null`

`ls -la /usr/lib/nvidia /usr/lib/nvidia/diversions /usr/lib32/nvidia
/usr/lib32/nvidia/diversions 2/dev/null`

Files from nvidia-installer:
`ls -la /usr/bin/nvidia-installer /usr/bin/nvidia-uninstall
/var/lib/nvidia 2/dev/null`

EOF

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.org/4d5c11d5.7090...@abeckmann.de

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

[Andreas Beckmann]

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
  the discussion on the Debian Live mailinglist mentioned in the initial
  bug report: http://lists.debian.org/debian-live/2011/01/msg00065.html
  http://lists.debian.org/debian-live/2011/01/msg00066.html

Let me describe how the new nvidia non-free packages work for squeeze:
(I implemented and tested these changes.)

There are three new packages libgl1-nvidia-alternatives, 
libgl1-nvidia-alternatives-ia32, libgl1-nvidia-alternatives-ia32 that do the 
diversions of OpenGL libraries (from libgl1-mesa-glx, ia32-libs, *-dev) and 
create alternatives of the diverted files. The diversions are created/removed 
by dpkg triggers whenever the diverted packages are (un-)installed.

The nvidia packages Depends: on the lib*-nvidia-alternatives package for the 
library they provide, install the new library in a private library 
directory (/usr/lib/nvidia) and add an alternative (with higher priority than 
the diverted library from mesa).

There are currently a lot of Conflicts defined to make sure only one of 
nvidia-graphics-drivers, nvidia-graphics-drivers-legacy-173xx or 
nvidia-graphics-drivers-legacy-96xx can be installed at a time. (legacy-71xx 
is no longer supported with current Xorg.) Most of these Conflicts should not 
be necessary since there are no more file name conflicts for the libraries.

There are file name conflicts for nvidia_drv.so (the Xorg driver module) 
libglx.so (the replaced Xorg module) and nvidia.ko (the kernel module which 
may exist for any number of distribution and custom kernels at the same time) 
and I currently have no solution how to solve these to allow installing both 
nvidia-graphics-drivers as well as one (or two) legacy versions at the same 
time. Could we rename them eventually? Alternatively (at least for the xorg 
modules) we could set up one more set of alternatives.

...

About configuring xorg for the nonfree drivers: There is a compile time option 
for Xorg that makes it read PCI ID lists from /usr/share/xserver-xorg/pci/ 
and auto-select drivers modules of corresponding file names if a matching 
device was found in the system. This flag was active for some tome in the 
Debian Xorg packages, but is no longer enabled. IIRC it was related to 
defining PCI_TXT_IDS_DIR.

The nvidia-glx* packages ship a nvidia.ids file in that directory (but it's 
not used by current xorg).


  So by installing fglrx it is also not possible to use
  another 3d accelerated gpu driver anymore.
 
  It is, you just need to use update-alternative.

And it does work for nvidia-glx :-)

 The xorg/mesa team has to play with us then. I also don't think, that
 using the alternative system is the right way, because:

 1) building against the fglrx libgl implementation is a bad idea

Agreed. Therefore nvidia-graphics-drivers* does not provide any libGL.so 
symlink. Instead the libgl1-nvidia-alternatives package diverts the libGL.so 
link provided by libgl1-mesa-dev and creates an alternative (via triggers) 
pointing to the diverted libGL.so - so at link time always the mesa opengl 
library will be used. For picking up the correct library at package build 
time, a shlibs file redirecting to libgl1-mesa-glx is being used.
(I.e. in short - no building/packaging of opengl programs without 
libgl1-mesa-dev installed).

 2) users may get strange problems/crashes, if they install different
 drivers (fglrx+free-drivers / nvidia+fglrx / nvidia+free drivers etc).

Packages and alternatives should cooperate and have safe defaults - and 
bug-scripts that list all possible breakers :-)

 3) It is no alternative, it is a diversion, because it is needed!

It is alternatives. The diversions are only needed until we can convince the 
mesa maintainers to ship their library in /usr/lib/mesa and install a primary 
alternative. (I haven't tried and I'm not sure if we really want to propose 
this).

 4) for fglrx it would just be a little step for live booting, fglrx
 still needs a xorg.conf with some options (like defaultdepth)

nvidia-glx currently needs the following minimal xorg.conf to be used (since 
there is no autodetection)

Section Device
Identifier GPU
Driver nvidia
EndSection

 I understand your position and it is a good idea to add fglrx to live
 cds, but I don't see any good solution (without ugly workarounds) to
 implement it, yet.

Something I can offer to the fglrx maintainers is to generalize the 
diversion/alternatives packages so that it supports fglrx, too. This should 
be not too difficult. But eventually we should rename the packages (something 
that contains xorg and non-free perhaps?) and move the location of the 
diversions to remove the references to nvidia.
I can also help getting the 

Autoconfiguring third-party Xorg drivers

[Andreas Beckmann]

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 itself, it would simplify automatic configuration of third
party drivers (the non-free nvidia driver in this case). Xorg does not
(and needs not to) know details about the existence of these drivers as
long as finding a matching PCI ID redirects it to the correct driver,
Currently an xorg.conf has to be created by the user because
autoconfiguration does not use the proprietary driver.

Or is there another solution to plug some driver into Xorg without
creating an xorg.conf?


Thanks.


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.org/4c747d11.5090...@abeckmann.de

Bug#466526: xorg starts with an oversized xrandr screen

[Andreas Beckmann]

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)

 Output of xrandr after startup, note that current is larger than maximum:
   
 
 Is it the same if you try to put the LVDS on the left on the VGA monitor?

No, in this case it seems to work fine.
But the original bug is still reproducible in the VGA-leftof-LVDS setup
with the latest xserver-xorg-video-ati from experimental.

 What if you remove the xorg.conf Right-Of stuff and just call xrandr?
 You never get the oversized screen right? (I just want to be sure that
 only the xorg.conf stuff is broken, and that runtime xrandr changes are ok).

It starts with an 1680x1200 screen (which does not fit on any of the
connected screens) and then I have no idea how I could trick xrandr to
invalid-resize the screen. Running xrandr gives a correct dual head
setup (provided there is a sufficient Screen/Display/Virtual setting,
e.g. '3280 1200', otherwise resizing fails with an explanatory error
message).

But there is a new bug:
If there is no LeftOf/RightOf setting in xorg.conf and I use xrandr to
setup one (or I use xrandr to switch the setting from xorg.conf to the
opposite layout) the following happens:
maximizing a window does not maximize it to the size of the current
subscreen (either LVDS or VGA-0) but to either
  total-width-of-virtual-screen x height-of-current-subscreen
i.e. spanning both subscreens (no LeftOf/RightOf in xorg.conf) or
  initial-dimensions-of-the-subscreen
i.e. does not look maximized (RightOf in xorg.conf switched to LeftOf
with xrandr)
Should I report this as a separate bug? I can make screenshots etc.

 Make sure you try the latest xserver-xorg-video-ati from experimental
 and xserver-xorg-core from unstable. If they don't help, I will forward
 this bug upstream.

Above tests were done with these versions:

ii  xserver-xorg-video-ati  1:6.8.1~git20080320.5e3b2128-1
ii  xserver-xorg-core   2:1.4.1~git20080131-2


Andreas

PS: something I didn't test: The LeftOf/RightOf setting in xorg.conf can
be done for both LVDS and VGA-0, I only tested it with VGA-0.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#466526: more on oversized xrandr screen

[Andreas Beckmann]

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 to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

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

[Andreas Beckmann]

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  XkbVariantnodeadkeys
which was left from the previous config. After removing this, switching
to the ttys worked again.


Andreas

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable'), (130, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.23-1-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]