Package: nvidia-graphics-drivers
Version: 1.0.8774-7
Severity: wishlist
Hi,
to start with, that doesn't affect any packages currently shipped by debian,
thus the
chosen severity.
But I think it was introduced as a sort of glitch in r104 of
svn://[EMAIL PROTECTED]/svn/pkg-nvidia/packages/nvidia-graphics-drivers/tags/1.0.8774-6/debian/nvidia-glx.init.in
At least I can see no reason for taking up the trouble of generating
nvidia-glx.init
by "debian/rules change-version" if one has to keep track of the upstream
version
changes in two independent places. (On a side note: the mechanism should also be
consistent, so either use the variable $VERSION in l.87 or get rid of it
entirely and
let all occurrences be literally generated in the same way)
The reasoning for that stems from the following sequence of my, however
ill-advised,
actions, which ultimately led to an segfaulting X server.
As I keep preaching to others to not use the nvidia-installer thingy but to do
things
the debian way, I wanted to build me a local package of their newest beta 9626.
apt-get sourcing nvidia-graphics-drivers, I got this new version, which looked
reasonable close to the ones I misused previously. After changing
debian/upstream_info, cleaning up, etc. (but not really in-depth checking *g*)
I got
my nice new packages. But installing those (thus invoking
/etc/init.d/nvidia-glx)
left me with the following situation:
$ ls -l /usr/lib/tls/*
ls: /usr/lib/tls/*: No such file or directory
$ ls -l /usr/lib/libnvidia-tls.so.1*
lrwxrwxrwx 1 root root 25 2006-10-17 17:07 /usr/lib/libnvidia-tls.so.1 ->
libnvidia-tls.so.1.0.9626
-rw-r--r-- 1 root root 3016 2006-10-17 11:54 /usr/lib/libnvidia-tls.so.1.0.9626
$ ldd /usr/lib/xorg/modules/extensions/libglx.so
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x00002b5af6175000)
libnvidia-tls.so.1 => /usr/lib/libnvidia-tls.so.1 (0x00002b5af6aa9000)
libc.so.6 => /lib/libc.so.6 (0x00002b5af6baa000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
which should apparently be (more or less):
$ ls -l /usr/lib/tls/*
lrwxrwxrwx 1 root root 25 2006-10-17 17:07 /usr/lib/tls/libnvidia-tls.so.1 ->
libnvidia-tls.so.1.0.9626
lrwxrwxrwx 1 root root 41 2006-10-17 17:07 /usr/lib/tls/libnvidia-tls.so.1.0.9626
-> /usr/lib/nvidia/libnvidia-tls.so.1.0.9626
$ ls -l /usr/lib/libnvidia-tls.so.1*
lrwxrwxrwx 1 root root 25 2006-10-17 17:07 /usr/lib/libnvidia-tls.so.1 ->
libnvidia-tls.so.1.0.9626
-rw-r--r-- 1 root root 3016 2006-10-17 11:54 /usr/lib/libnvidia-tls.so.1.0.9626
$ ldd /usr/lib/xorg/modules/extensions/libglx.so
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x00002ab3f1405000)
libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1
(0x00002ab3f1d39000)
libc.so.6 => /lib/libc.so.6 (0x00002ab3f1e3a000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
Somehow the nvidia binary stuff does only accept this latter setup, as an
invocation
of startx (more or less normal xorg.conf for nvidia cards) does work now, while
the
former one leads to a segfault with the following in /var/log/Xorg.0.log:
[...]
(II) NVIDIA(0): Screen initialization complete
(==) RandR enabled
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XC-APPGROUP
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension XFree86-Bigfont
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
(II) Initializing built-in extension XEVIE
(II) Initializing extension GLX
Backtrace:
0: /usr/bin/X(xf86SigHandler+0x6d) [0x48c45d]
1: /lib/libc.so.6 [0x2b9893934110]
2: /usr/bin/X(xf86nameCompare+0x8d) [0x4a4c3d]
3: /usr/bin/X(InitInput+0x103) [0x45ea23]
4: /usr/bin/X(main+0x337) [0x430e57]
5: /lib/libc.so.6(__libc_start_main+0xda) [0x2b98939214ca]
6: /usr/bin/X(FontFileCompleteXLFD+0x9a) [0x43026a]
Fatal server error:
Caught signal 11. Server aborting
Please forgive me for that lengthy rambling, but as I was puzzled at first and
some
search engine didn't really dig up sensible information, so I wanted to put
that on
the record.
Best regards
Klaus Hoercher
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-wb-a
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
