Bug#546989: libboost1.40-dev: insufficient -dev package dependencies
Package: libboost1.40-dev Version: 1.40.0-1 Severity: normal Hi, /usr/include/boost/parameter/aux_/maybe.hpp includes boost/python/detail/referent_storage.hpp which is not pulled by the package dependencies. Andreas -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (800, 'stable'), (700, 'testing'), (600, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-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 Versions of packages libboost1.40-dev depends on: ii libc6 2.9-25 GNU C Library: Shared libraries ii libgcc1 1:4.4.1-4 GCC support library ii libicu42 4.2.1-3International Components for Unico ii libstdc++64.4.1-4The GNU Standard C++ Library v3 ii libstdc++6-4.2-dev [libstdc++ 4.2.4-6The GNU Standard C++ Library v3 (d ii libstdc++6-4.3-dev [libstdc++ 4.3.4-2The GNU Standard C++ Library v3 (d ii libstdc++6-4.4-dev [libstdc++ 4.4.1-4The GNU Standard C++ Library v3 (d libboost1.40-dev recommends no packages. Versions of packages libboost1.40-dev suggests: pn default-jdk none (no description available) ii docbook-xml 4.5-6 standard XML documentation system, pn docbook-xsl none (no description available) ii doxygen 1.6.1-1Documentation system for C, C++, J pn fop none (no description available) ii libboost-date-time1.40-dev1.40.0-1 set of date-time libraries based o ii libboost-filesystem1.40-dev 1.40.0-1 filesystem operations (portable pa ii libboost-graph1.40-dev1.40.0-1 generic graph components and algor ii libboost-iostreams1.40-dev1.40.0-1 Boost.Iostreams Library developmen pn libboost-math1.40-dev none (no description available) pn libboost-mpi1.40-dev none (no description available) pn libboost-program-options1.40- none (no description available) pn libboost-python1.40-dev none (no description available) ii libboost-regex1.40-dev1.40.0-1 regular expression library for C++ ii libboost-serialization1.40-de 1.40.0-1 serialization library for C++ pn libboost-signals1.40-dev none (no description available) ii libboost-system1.40-dev 1.40.0-1 Operating system (e.g. diagnostics ii libboost-test1.40-dev 1.40.0-1 components for writing and executi ii libboost-thread1.40-dev 1.40.0-1 portable C++ multi-threading pn libboost-wave1.40-dev none (no description available) pn libboost1.40-doc none (no description available) ii xsltproc 1.1.24-2 XSLT command line processor -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546215: /etc/modprobe.d/nvidia-kernel-nkc belongs to nvidia-kernel-common
reassign 546215 nvidia-kernel-common thanks /etc/modprobe.d/nvidia-kernel-nkc is not part of any package built from the source package nvidia-graphics-drivers. $ dpkg -S /etc/modprobe.d/nvidia-kernel-nkc nvidia-kernel-common: /etc/modprobe.d/nvidia-kernel-nkc Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496220: changing to ITP
Marco Nenciarini wrote: Andreas, are you still interested to help in maintaining it? Yes, I'm still here to help! Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496220: libapache2-mod-xsendfile_0.9-0.0anbe1.diff.gz
Hi Marco, here is my mod_xsendfile .diff.gz to be used with http://tn123.ath.cx/mod_xsendfile/mod_xsendfile-0.9.tar.gz Packaging was updated today for latest debhelper, Standards-Version, Maintainer. Andreas libapache2-mod-xsendfile_0.9-0.0anbe1.diff.gz Description: GNU Zip compressed data
Bug#555644: libc6: fails to update from 2.10 -- incorrect invoke-rc.d call in postinst script
Package: libc6
Version: 2.10.1-6
Severity: serious
Hi,
when updating a sid/amd64 chroot (on a lenny(+older squeeze kernel)/amd64 host),
libc6 fails to update properly.
Last previous update was performed on Oct 12, no problems at that time.
This time, libc6 was going to be updated from 2.9-27 to 2.10.1-6 and
configuration fails with:
(since I didn't keep the original error message
and it was way to messed up by a lot of packages failing with
unconfigured libc6, I can still reproduce the problem by manually
reinstalling libc6)
# dpkg -i /var/cache/apt/archives/libc6_2.10.1-6_amd64.deb
(Reading database ... 28139 files and directories currently installed.)
Preparing to replace libc6 2.10.1-6 (using .../libc6_2.10.1-6_amd64.deb) ...
Unpacking replacement libc6 ...
Setting up libc6 (2.10.1-6) ...
Checking for services that may need to be restarted...
Checking init scripts...
invoke-rc.d: unknown initscript, /etc/init.d/-query not found.
dpkg: error processing libc6 (--install):
subprocess installed post-installation script returned error exit status 100
Errors were encountered while processing:
libc6
One reason for this are some incorrect calls to invoke-rc.d:
# grep -query /var/lib/dpkg/info/*
/var/lib/dpkg/info/libc6.postinst: invoke-rc.d -query
${service} start ; status=$?
/var/lib/dpkg/info/libc6.preinst: invoke-rc.d -query
${service} start ; status=$?
This should have been --query.
Surprisingly this update worked on another machine with a similar chroot
without problems, that chroot was updated once more inbetween and
yesterdays update was only from libc6 2.10.1-1 to 2.10.1-6.
If I manually fix the spelling of --query in the postinst script and try
to configure libc6, new errors occur:
# dpkg --configure libc6
Setting up libc6 (2.10.1-6) ...
Checking for services that may need to be restarted...
Checking init scripts...
dpkg: error processing libc6 (--configure):
subprocess installed post-installation script returned error exit status 105
Errors were encountered while processing:
libc6
Error 105 seems to be a return value from invoke-rc.d --query,
probably misinterpreted as a failure by set -e.
Andreas
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (600, 'unstable'), (600, 'testing'), (600, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.29-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages libc6 depends on:
ii libc-bin 2.10.1-6 GNU C Library: Binaries
ii libgcc1 1:4.4.1-6 GCC support library
libc6 recommends no packages.
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy
pn glibc-doc none (no description available)
pn locales none (no description available)
-- debconf information:
glibc/restart-services:
glibc/disable-screensaver:
glibc/upgrade: true
glibc/restart-failed:
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549626: [pkg-nvidia-devel] Bug#547248: ITP: libvdpau -- Video Decode and Presentation API for Unix
Andres Mejia wrote:
One concern I have is with the trace library, libvdpau_trace.so. If this
library is not going to supply any versioning, than this library should reside
in a subdirectory in /usr/lib. For example, we could follow the same scheme
adopted by pulseaudio, have the trace library installed in
/usr/lib/vdpau-0.2/modules.
As I understand it, both libvdpau_trace.so and libvdpau_$VENDOR.so (with
$VENDOR = nvidia for now) are plugins, dlopen()ed from libvdpau.so.1
(and have no proper versioning like most plugins).
So if the wrapper can be patched to search in a subdirectory of /usr/lib
(and /usr/lib32 or /usr/lib64 where appropriate) both the trace library
and the vendor implementation can be moved out of /usr/lib{,32,64}
For the subdirectory something like just /usr/lib/vdpau or
/usr/lib/vdpau-$PLUGINABI might be a better choice, as the interface
(version number) of the vdpau wrapper might evolve while staying plugin
compatible (using some kind of capability interface).
Or /usr/lib/vdpau for the vendor implementation, /usr/lib/libvdpau1 for
the trace library/plugin (which will always match the wrapper library
because they are supplied by the same package, so no ABI issues at all
involving the trace library)
If the library is to be ABI compatible across different revisions, than
versioning info should be added to the library instead.
BTW, what about building a lib32vdpau1 package on amd64, too? This will
be needed by libvdpau*-nvidia-ia32. Or are there chances to get
libvdpau1 into ia32-libs(-whatever) in time?
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545700: valgrind: new upstream release 3.5.0
Package: valgrind
Version: 1:3.4.1-1
Severity: normal
Hi,
a new version of valgrind was released on 19 Aug 2009.
Building an updated package for my own use I noticed the following
packaging issues:
* the patch '01_pcm-ioctl' does no longer apply and I did not look into
whether is had been applied upstream
* a refreshed version of patch '02_version' is attached
* the ACKNOWLEDGEMENTS file is gone and needs to be removed from
debian/docs
* I attach a debian/watch file, too
Andreas
-- System Information:
Debian Release: squeeze/sid
APT prefers stable
APT policy: (800, 'stable'), (700, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-1-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
Versions of packages valgrind depends on:
ii libc6 2.9-25 GNU C Library: Shared libraries
Versions of packages valgrind recommends:
ii gdb 6.8.50.20090628-3+b1 The GNU Debugger
Versions of packages valgrind suggests:
pn alleyoop none (no description available)
ii kcachegrind 4:3.5.9-2 visualisation tool for valgrind pr
ii libc6-dbg 2.9-25 GNU C Library: detached debugging
-- no debconf information
version=3
http://valgrind.org/downloads/ valgrind-(.*).tar.bz2
#! /bin/sh -e
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Appends Debian to package version
[ -f debian/patches/00patch-opts ] . debian/patches/00patch-opts
patch_opts=${patch_opts:--f --no-backup-if-mismatch}
if [ $# -ne 1 ]; then
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
fi
case $1 in
-patch) patch $patch_opts -p1 $0;;
-unpatch) patch $patch_opts -p1 -R $0;;
*)
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1;;
esac
exit 0
@DPATCH@
diff -urNad valgrind-3.5.0~/configure valgrind-3.5.0/configure
--- valgrind-3.5.0~/configure 2009-09-08 16:05:53.0 +0200
+++ valgrind-3.5.0/configure 2009-09-08 16:08:36.218503435 +0200
@@ -269,9 +269,9 @@
# Identity of this package.
PACKAGE_NAME='Valgrind'
PACKAGE_TARNAME='valgrind'
-PACKAGE_VERSION='3.5.0'
-PACKAGE_STRING='Valgrind 3.5.0'
-PACKAGE_BUGREPORT='valgrind-us...@lists.sourceforge.net'
+PACKAGE_VERSION='3.5.0-Debian'
+PACKAGE_STRING='Valgrind 3.5.0 Debian'
+PACKAGE_BUGREPORT='valgrind-us...@lists.sourceforge.net | valgr...@packages.debian.org'
ac_unique_file=coregrind/m_main.c
# Factoring default headers for most tests.
@@ -1660,7 +1660,7 @@
# Define the identity of the package.
PACKAGE='valgrind'
- VERSION='3.5.0'
+ VERSION='3.5.0-Debian'
cat confdefs.h _ACEOF
@@ -4203,7 +4203,7 @@
echo $ECHO_N checking for a supported OS... $ECHO_C 6
-DEFAULT_SUPP=
+DEFAULT_SUPP=debian.supp
case ${host_os} in
*linux*)
Bug#550240: netbase: invoke-rc.d networking restart terminates DHCP connections but does not restart them
Package: netbase Version: 4.37 Severity: normal Hi, I just noticed that invoke-rc.d networking restart does terminate DHCP connections but does not restart them. Fortunately the machine was in the next room :-) /etc/network/interfaces (as generated by Debian-installer): # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet dhcp /etc/init.d/networking calls ifdown -a which works on all configured interfaces and afterwards calls ifup -a which only works on interfaces marked auto, not allow-hotplug Andreas -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (600, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-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 Versions of packages netbase depends on: ii lsb-base 3.2-23 Linux Standard Base 3.2 init scrip Versions of packages netbase recommends: ii ifupdown 0.6.9high level tools to configure netw netbase suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533195: nvidia-glx: outdated references in README.Debian
Package: nvidia-glx Version: 185.18.14-1 Severity: minor Hi, there are some outdated references in nvidia-glx.README.Debian: OLD: /usr/share/doc/nvidia-glx/README.gz NEW: /usr/share/doc/nvidia-glx/README.txt.gz OLD: Appendix F: CONFIGURING AGP is an important section. NEW: Chapter 12. Configuring AGP ... Andreas -- Package-specific info: uname -r: Linux calzone 2.6.29-2-amd64 #1 SMP Sun May 17 17:15:47 UTC 2009 x86_64 GNU/Linux /proc/version: Linux version 2.6.29-2-amd64 (Debian 2.6.29-5) (wa...@debian.org) (gcc version 4.3.3 (Debian 4.3.3-10) ) #1 SMP Sun May 17 17:15:47 UTC 2009 /proc/driver/nvidia/version: 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 140M (rev a1) -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (800, 'stable'), (700, 'testing'), (600, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages nvidia-glx depends on: ii libc6 2.9-12 GNU C Library: Shared libraries ii libgl1-mesa-glx [libgl1 7.0.3-7 A free implementation of the OpenG ii libx11-62:1.2.1-1X11 client-side library ii libxext62:1.0.4-1X11 miscellaneous extension librar ii nvidia-kernel-2.6.29-2- 185.18.14+0anbe0 NVIDIA binary kernel module for Li ii x11-common 1:7.3+18 X Window System (X.Org) infrastruc nvidia-glx recommends no packages. Versions of packages nvidia-glx suggests: pn nvidia-kernel-source none (no description available) ii nvidia-settings 180.22-1 Tool of configuring the NVIDIA gra -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533217: [patch] suggest 'm-a clean nvidia' before aborting if old files breaking the build are found in the build directory
tag 533217 +patch thanks Hi, build breakage by not cleaning before the new build is caused by the following chain of events: * an old makefile (lowercase m) exists from older versions of the source * m-a runs the clean target from this makefile (which gets preferred by make over the new Makefile (capital M) shipped) * this clean target removes the Makefile * build bombs A simple workaround (patch attached) is to check for the presence of a 'makefile' in the binary-modules target and print an error message suggesting 'm-a clean nvidia' and abort if it was found. At this point there is no way to recover by e.g. removing the 'makefile' because the 'Makefile' is already gone. This should help all people running into this problem again and again. Andreas Index: debian.binary/rules === --- debian.binary/rules (revision 733) +++ debian.binary/rules (working copy) @@ -32,6 +32,12 @@ dh_prep +ifneq (,$(wildcard makefile)) + @echo ERROR: unclean build directory from older version found, please clean first: + @echo module-assistant clean nvidia + @exit 1 +endif + # Build the modules $(MAKE) -f Makefile.nvidia patches.h $(MAKE) -C . LINUXDIR=$(KSRC) KVERREL=$(KVERS)
Bug#533279: nvidia-kernel-source: s
Package: nvidia-kernel-source Version: 185.18.14-1 Severity: normal Tags: patch Hi, there are two copies of the same nv-kernel.o in nvidia-kernel-source (amd64), the *.o.i386 variant is actually a copy of the *.o.x86_64: file /usr/src/modules/nvidia-kernel/*.o.* /usr/src/modules/nvidia-kernel/nv-kernel.o.i386: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped /usr/src/modules/nvidia-kernel/nv-kernel.o.x86_64: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped The attached patch for debian/rules fixes this. Andreas -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (800, 'stable'), (600, 'unstable'), (130, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Index: debian/rules === --- debian/rules (revision 671) +++ debian/rules (revision 672) @@ -129,8 +129,9 @@ rm $(CURDIR)/debian/temp/modules/nvidia-kernel/makefile # We want both 32 and 64 bit versions of nv-kernel.o - cp $(CURDIR)/$(dirname_x86_64)/usr/src/nv/nv-kernel.o $(CURDIR)/debian/temp/modules/nvidia-kernel/nv-kernel.o.x86_64 - mv $(CURDIR)/debian/temp/modules/nvidia-kernel/nv-kernel.o $(CURDIR)/debian/temp/modules/nvidia-kernel/nv-kernel.o.i386 + cp $(CURDIR)/$(dirname_x86)/usr/src/nv/nv-kernel.o $(CURDIR)/debian/temp/modules/nvidia-kernel/nv-kernel.o.i386 + cp $(CURDIR)/$(dirname_x86_64)/usr/src/nv/nv-kernel.o $(CURDIR)/debian/temp/modules/nvidia-kernel/nv-kernel.o.x86_64 + rm -f $(CURDIR)/debian/temp/modules/nvidia-kernel/nv-kernel.o # and then make Makefile.kbuild actually use our names sed -i -e 's/nv-kernel.o$$/nv-kernel.o$$(NVARCH)/' $(CURDIR)/debian/temp/modules/nvidia-kernel/Makefile.kbuild
Bug#533394: bugzilla3: overly restrictive permissions in /usr/share
Package: bugzilla3 Version: 3.2.0.1-1 Severity: normal Hi, bugzilla has some overly restrictive permissions (0750 root:www-data) set on /usr/share/bugzilla3/lib /usr/share/perl5/Bugzilla This produces not needed errors on find /usr/share ... and also required me to use the --no-verify option to reportbug because reportbug otherwise stalled during the check. Andreas -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (800, 'stable'), (700, 'testing'), (600, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages bugzilla3 depends on: ii apache2-mpm-prefork [h 2.2.11-5 Apache HTTP Server - traditional n ii dbconfig-common1.8.41common framework for packaging dat ii debconf1.5.26Debian configuration management sy ii libappconfig-perl 1.56-2Perl module for configuration file ii libcgi-pm-perl 3.43-1Simple Common Gateway Interface Cl ii libdbd-mysql-perl 4.011-1 A Perl5 database interface to the ii libemail-mime-modifier 1.444-1 module to modify Email::MIME objec ii libemail-send-perl 2.194-1 Simply Sending Email ii libtemplate-perl 2.19-1.1lenny1.1 template processing system written ii libtimedate-perl 1.1600-9 Time and date functions for Perl ii mysql-client-5.0 [mysq 5.0.51a-24+lenny1 MySQL database client binaries ii patch 2.5.9-5 Apply a diff file to an original ii perl-modules [libcgi-p 5.10.0-22 Core Perl modules ii postfix [mail-transpor 2.5.5-1.1 High-performance mail transport ag ii ucf3.0018Update Configuration File: preserv Versions of packages bugzilla3 recommends: ii libchart-perl 2.4.1-5 Chart Library for Perl ii libxml-parser-perl 2.36-1.1+b1 Perl module for parsing XML files ii mysql-server5.0.51a-24+lenny1MySQL database server (metapackage ii mysql-server-5.0 [m 5.0.51a-24+lenny1MySQL database server binaries ii perlmagick 7:6.3.7.9.dfsg2-1+b1 Perl interface to the libMagick gr Versions of packages bugzilla3 suggests: ii bugzilla3-doc3.2.0.1-1 comprehensive guide to Bugzilla ii graphviz 2.20.2-3+b2 rich set of graph drawing tools ii libgd-gd2-perl 1:2.39-2Perl module wrapper for libgd - gd ii libgd-graph-perl 1.44-3 Graph Plotting Module for Perl 5 ii libgd-text-perl 0.86-5 Text utilities for use with GD ii libhtml-parser-perl 3.60-1 collection of modules that parse H pn libhtml-scrubber-perlnone (no description available) ii libmailtools-perl2.04-1 Manipulate email in perl programs ii libmime-tools-perl 5.427-2 Perl5 modules for MIME-compliant m pn libnet-ldap-perl none (no description available) ii libsoap-lite-perl0.710.08-2 Client and server side SOAP implem ii libwww-perl 5.826-1 WWW client/server library for Perl ii libxml-twig-perl 1:3.32-3Perl module for processing huge XM -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533395: reportbug: package verification stalls on not readable directories (files?)
Package: reportbug Version: 4.4 Severity: normal Hi, reportbug blocks infinitely if it encounters unreadable directories (files?) during package verification. One example is the bugzilla3 (3.2.0.1-1) package which has some directories in /usr/share with permissions 0750, owner root:www-data (e.g. /usr/share/bugzilla3/lib) that I as normal user can't access and I had to use the --no-verify option to report that as bug #533394. Andreas -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (800, 'stable'), (700, 'testing'), (600, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages reportbug depends on: ii apt 0.7.21 Advanced front-end for dpkg ii python2.5.4-2An interactive high-level object-o ii python-reportbug 4.4Python modules for interacting wit reportbug recommends no packages. Versions of packages reportbug suggests: ii debconf-utils1.5.26 debconf utilities ii debsums 2.0.44 verification of installed package pn dlocate none (no description available) ii file 5.03-1 Determines file type using magic ii gnupg1.4.9-4 GNU privacy guard - a free PGP rep ii postfix [mail-transport-agen 2.5.5-1.1 High-performance mail transport ag ii python-gnome2-extras 2.19.1-3.1 Extra Python bindings for the GNOM ii python-gtk2 2.12.1-6Python bindings for the GTK+ widge pn python-urwid none (no description available) ii python-vte 1:0.16.14-4 Python bindings for the VTE widget -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519792: symlink shuffling for libvdpau
reopen 519792 thanks Hi, the new libvdpau packages are missing some symbolic links (they seem to be created by ldconfig, but should be included in the package anyway): nvidia-libvdpau: /usr/lib/libvdpau_nvidia.so - libvdpau_nvidia.so.185.18.14 /usr/lib/libvdpau_trace.so - libvdpau_trace.so.185.18.14 (the wrapper library dlopens libvdpau_*.so) nvidia-libvdpau-ia32: similarily The libvdpau.so symlink should go to the -dev package (and point to libvdpau.so.1). (I just verified that mplayer (from mplayer-dmo source) does dlopen libvdpau.so.1 not libvdpau.so .) Updated control files / templates are attached. I also attach lintian-override templates for the nvidia-libvdpau* packages. Andreas emul/ia32-linux/usr/lib/libvdpau.so.#VERSION# emul/ia32-linux/usr/lib/libvdpau.so.1 emul/ia32-linux/usr/lib/libvdpau_nvidia.so.#VERSION# emul/ia32-linux/usr/lib/libvdpau_nvidia.so emul/ia32-linux/usr/lib/libvdpau_trace.so.#VERSION# emul/ia32-linux/usr/lib/libvdpau_trace.so usr/lib/libvdpau.so.#VERSION# usr/lib/libvdpau.so.1 usr/lib/libvdpau_nvidia.so.#VERSION#usr/lib/libvdpau_nvidia.so usr/lib/libvdpau_trace.so.#VERSION# usr/lib/libvdpau_trace.so nvidia-libvdpau: shlib-without-PT_GNU_STACK-section usr/lib/libvdpau.so.#VERSION# nvidia-libvdpau: shlib-without-PT_GNU_STACK-section usr/lib/libvdpau_nvidia.so.#VERSION# nvidia-libvdpau: shlib-without-PT_GNU_STACK-section usr/lib/libvdpau_trace.so.#VERSION# nvidia-libvdpau: shlib-with-non-pic-code usr/lib/libvdpau_nvidia.so.#VERSION# nvidia-libvdpau: binary-has-unneeded-section ./usr/lib/libvdpau.so.#VERSION# .comment nvidia-libvdpau: binary-has-unneeded-section ./usr/lib/libvdpau_nvidia.so.#VERSION# .comment nvidia-libvdpau: binary-has-unneeded-section ./usr/lib/libvdpau_nvidia.so.#VERSION# .note nvidia-libvdpau: binary-has-unneeded-section ./usr/lib/libvdpau_trace.so.#VERSION# .comment # libvdpau.so.1 does dlopen(libvdpau_*.so) nvidia-libvdpau: non-dev-pkg-with-shlib-symlink usr/lib/libvdpau_nvidia.so.#VERSION# usr/lib/libvdpau_nvidia.so nvidia-libvdpau: non-dev-pkg-with-shlib-symlink usr/lib/libvdpau_trace.so.#VERSION# usr/lib/libvdpau_trace.so usr/lib/libvdpau.so.1 usr/lib/libvdpau.so nvidia-libvdpau-ia32: shlib-without-PT_GNU_STACK-section emul/ia32-linux/usr/lib/libvdpau.so.#VERSION# nvidia-libvdpau-ia32: shlib-without-PT_GNU_STACK-section emul/ia32-linux/usr/lib/libvdpau_nvidia.so.#VERSION# nvidia-libvdpau-ia32: shlib-without-PT_GNU_STACK-section emul/ia32-linux/usr/lib/libvdpau_trace.so.#VERSION# nvidia-libvdpau-ia32: shlib-with-non-pic-code emul/ia32-linux/usr/lib/libvdpau_nvidia.so.#VERSION# nvidia-libvdpau-ia32: binary-has-unneeded-section ./emul/ia32-linux/usr/lib/libvdpau.so.#VERSION# .comment nvidia-libvdpau-ia32: binary-has-unneeded-section ./emul/ia32-linux/usr/lib/libvdpau_nvidia.so.#VERSION# .comment nvidia-libvdpau-ia32: binary-has-unneeded-section ./emul/ia32-linux/usr/lib/libvdpau_nvidia.so.#VERSION# .note nvidia-libvdpau-ia32: binary-has-unneeded-section ./emul/ia32-linux/usr/lib/libvdpau_trace.so.#VERSION# .comment # libvdpau.so.1 does dlopen(libvdpau_*.so) nvidia-libvdpau-ia32: non-dev-pkg-with-shlib-symlink emul/ia32-linux/usr/lib/libvdpau_nvidia.so.#VERSION# emul/ia32-linux/usr/lib/libvdpau_nvidia.so nvidia-libvdpau-ia32: non-dev-pkg-with-shlib-symlink emul/ia32-linux/usr/lib/libvdpau_trace.so.#VERSION# emul/ia32-linux/usr/lib/libvdpau_trace.so nvidia-libvdpau: binary-has-unneeded-section ./usr/lib/libvdpau.so.#VERSION# .comment nvidia-libvdpau: binary-has-unneeded-section ./usr/lib/libvdpau_nvidia.so.#VERSION# .comment nvidia-libvdpau: binary-has-unneeded-section ./usr/lib/libvdpau_trace.so.#VERSION# .comment # libvdpau.so.1 does dlopen(libvdpau_*.so) nvidia-libvdpau: non-dev-pkg-with-shlib-symlink usr/lib/libvdpau_nvidia.so.#VERSION# usr/lib/libvdpau_nvidia.so nvidia-libvdpau: non-dev-pkg-with-shlib-symlink usr/lib/libvdpau_trace.so.#VERSION# usr/lib/libvdpau_trace.so
Bug#533395: reportbug: package verification stalls on not readable directories (files?)
Sandro Tosi wrote: On Wed, Jun 17, 2009 at 09:20, Andreas Beckmanndeb...@abeckmann.de wrote: Package: reportbug Version: 4.4 Severity: normal Hi, reportbug blocks infinitely if it encounters unreadable directories (files?) during package verification. do you mean just after Verifying package integrity... exactly: $ reportbug bugzilla3 Detected character set: UTF-8 Please change your locale if this is incorrect. Using 'Andreas Beckmann deb...@abeckmann.de' as your from address. Getting status for bugzilla3... Verifying package integrity... ^C^C^C^C^C^C^C^C^C^CTerminated Ctrl-C does not work, I have to kill it. If so, it's a bug in debsums, since we relay on it for package verification step. Please confirm and I'll reassign this but to debsums (or you can do it yourself :) There is no debsums (or other) process started by reportbug around, file descriptors as listed by lsof before killing reportbug: reportbug 8478 andreas0u CHR 136,8 0t0 11 /dev/pts/8 reportbug 8478 andreas1u CHR 136,8 0t0 11 /dev/pts/8 reportbug 8478 andreas2u CHR 136,8 0t0 11 /dev/pts/8 reportbug 8478 andreas3r FIFO0,6 0t0 45379437 pipe reportbug 8478 andreas4w FIFO0,6 0t0 45379437 pipe reportbug 8478 andreas5w FIFO0,6 0t013461 pipe reportbug 8478 andreas7r FIFO0,6 0t0 45378635 pipe reportbug 8478 andreas 10r FIFO0,6 0t0 50619776 pipe reportbug 8478 andreas 11u unix 0x88009d06b380 0t0 50619774 socket reportbug 8478 andreas 12w FIFO0,6 0t0 50619776 pipe I can't verify the problem using debsums: debsums -s bugzilla3 lists a lot of (Permission denied) errors and exists with error code 2. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519792: symbols files for libvdpau
Hi, I'm attaching symbols files for the new libvdpau packages. nvidia-libvdpau-ia32.symbols can be generated dynamically with the following target in debian/rules (don't forget to add it to AUTOGEN): debian/nvidia-libvdpau-ia32.symbols: debian/nvidia-libvdpau.symbols.i386 sed 's/nvidia-libvdpau/nvidia-libvdpau-ia32/g' $ $@ This will probably supersede nvidia-libvdpau.shlibs Andreas libvdpau.so.1 nvidia-libvdpau #MINVER# nv_vdpau_wrapper...@base 180.06 pnv_vdpau_wrapper...@base 180.06 vdp_device_create_...@base 180.06 libvdpau_nvidia.so nvidia-libvdpau #MINVER# mk...@base 180.06 s...@base 180.06 vdp_imp_device_create_...@base 180.06 libvdpau_trace.so nvidia-libvdpau #MINVER# nv_vdpau_trace...@base 180.06 _z40_vdp_cap_init_planes_adapt_surface_videojpjs...@base 180.06 _z41_vdp_cap_init_planes_adapt_surface_bitmapjpjs...@base 180.06 _z41_vdp_cap_init_planes_adapt_surface_outputjpjs...@base 180.06 pnv_vdpau_trace...@base 180.06 vdp_trace_device_create_...@base 180.06 vdp_trace_set_backend_han...@base 180.06 libvdpau.so.1 nvidia-libvdpau #MINVER# nv_vdpau_wrapper...@base 180.06 pnv_vdpau_wrapper...@base 180.06 vdp_device_create_...@base 180.06 libvdpau_nvidia.so nvidia-libvdpau #MINVER# vdp_imp_device_create_...@base 180.06 libvdpau_trace.so nvidia-libvdpau #MINVER# nv_vdpau_trace...@base 180.06 _z40_vdp_cap_init_planes_adapt_surface_videojpjs...@base 180.06 _z41_vdp_cap_init_planes_adapt_surface_bitmapjpjs...@base 180.06 _z41_vdp_cap_init_planes_adapt_surface_outputjpjs...@base 180.06 pnv_vdpau_trace...@base 180.06 vdp_trace_device_create_...@base 180.06 vdp_trace_set_backend_han...@base 180.06
Bug#533217: nvidia-kernel-source should recommend module-assistant instead of kernel-package
Hi, since module-assistant is currently the only way to build the binary module from the source package, module-assistant should be recommended by nvidia-kernel-source instead of kernel-package. Also the dependency on dpatch no longer seems to be neccessary. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533515: nvidia-graphics-drivers: shlibs cleanup
Package: nvidia-graphics-drivers
Version: 185.18.14-1
Severity: normal
Tags: patch
Hi,
here comes a patch that does some cleanup on the
nvidia-graphics-drivers shlibs handling and some related changes.
There are some changes I already mentioned in other bug reports, but the
overlap should be fairly small.
Short summary:
* use dh_lintian, updated overrides
* no more hardcoded library dependencies, everything is generated
* more consistency between all packages
Detailed list of changes:
* debian/control.in[source]
Build-Depends: debhelper (= 6.0.7~)
bumped, for dh_lintian
Build-Depends: libc6-dev-i386 [amd64], ia32-libs [amd64]
added, these were missing
* debian/control.in[some packages]
- add Section: non-free/libs, Section: non-free/libdevel
- drop hardcoded library dependencies
- add ${misc:Depends}
* debian/control.in[nvidia-glx]
Provides: libgl1
added, since we provide an alternative version of this library
theoretically libgl1-mesa-glx should be uninstallable if nvidia-glx
is installed
Provides: xserver-xorg-video-2
added, this was removed in 177.80-2 and never restored
* debian/control.in[nvidia-libvdpau{,-ia32}]
Depends: x11-common
removed, not needed
Suggests: nvidia-settings
removed, not needed
Recommends: nvidia-kernel-#VERSION#
added (and only recommend it, so the package is installable in
chroots that don't have a kernel installed)
Suggests: nvidia-kernel-source (= #VERSION#)
added (for consistency)
* debian/control.in[nvidia-kernel-source]
Recommends: kernel-package (= 8.082)
replaced with ...
Recommends: module-assistant
... this (see #533217)
* debian/nvidia-glx-dev.links.in
- removed comment which resulted in invalid symlink being packged
* debian/nvidia-glx-ia32.links.in
- add a libGLcore.so.1 symlink, drop *.so symlinks
* debian/nvidia-glx.shlibs
- xlibmesa-gl is now libgl1-mesa-glx
- nothing but our libGL.so.x.y depends on libGLcore,
so no libgl1-mesa-glx | libgl1 is needed there
* debian/nvidia-glx-ia32.shlibs
- added (based on debian/nvidia-glx.shlibs), there was none before
- eventually this would be a theoretically better entry for libGL:
libGL 1 ia32-libs | libgl1-ia32
* debian/nvidia-glx-ia32.lintian-overrides.in,
debian/nvidia-glx.lintian-overrides.amd64.in,
debian/nvidia-glx.lintian-overrides.i386.in,
debian/nvidia-glx.override.in, debian/nvidia-glx-ia32.override.in
- renamed for dh_lintian usage, split because different overrides are
needed for i386 and amd64, updated
* debian/nvidia-libvdpau-dev.links,
debian/nvidia-libvdpau-ia32.links.in, debian/nvidia-libvdpau.links.in
- see #519792
- eventually some more Replaces entries are still needed for
nvidia-libvdpau-dev
* debian/rules
- use dh_lintian
- some files were renamed
- drop dh_shlibdeps hacks, options, workarounds -- this now works
out-of-the-box :-)
Andreas
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (800, 'testing'), (800, 'stable'), (600, 'unstable'), (130,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.28-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
diff -Naur orig/debian/control.in mine/debian/control.in
--- orig/debian/control.in 2009-06-11 22:40:00.575038000 +0200
+++ mine/debian/control.in 2009-06-18 11:10:59.540580642 +0200
@@ -5,13 +5,12 @@
Uploaders: Randall Donald rdon...@debian.org
XS-Vcs-Svn: svn://svn.debian.org/svn/pkg-nvidia/packages/nvidia-graphics-drivers
XS-Vcs-Browser: http://svn.debian.org/wsvn/pkg-nvidia/packages/nvidia-graphics-drivers
-Build-Depends: debhelper ( 4.0.0), sed ( 3.0), libxext6, bzip2
+Build-Depends: debhelper (= 6.0.7~), sed ( 3.0), libxext6, bzip2, libc6-dev-i386 [amd64], ia32-libs [amd64]
Standards-Version: 3.6.2
-
Package: nvidia-glx-ia32
Architecture: amd64
-Depends: nvidia-kernel-#VERSION#, ia32-libs, ${shlibs:Depends}
+Depends: nvidia-kernel-#VERSION#, ${shlibs:Depends}, ${misc:Depends}
Suggests: nvidia-settings, nvidia-kernel-source (= #VERSION#)
Conflicts: nvidia-glx-src
Replaces: nvidia-glx-src
@@ -29,9 +28,10 @@
Package: nvidia-glx
Architecture: i386 amd64
-Depends: nvidia-kernel-#VERSION#, x11-common (= 1:7.0.0), ${shlibs:Depends}
+Depends: nvidia-kernel-#VERSION#, x11-common (= 1:7.0.0), ${shlibs:Depends}, ${misc:Depends}
Suggests: nvidia-settings, nvidia-kernel-source (= #VERSION#)
Conflicts: nvidia-glx-src, nvidia-glx-dev ( 1.0.8774-5)
+Provides: libgl1, xserver-xorg-video-2
Replaces: nvidia-glx-src
Description: NVIDIA binary Xorg driver
These binary drivers provide optimized hardware
@@ -47,10 +47,10 @@
See /usr/share/doc/nvidia-glx/README.txt.gz for a complete list
of supported GPUs and PCIIDs
.
-
+
Package: nvidia-glx-dev
Architecture: i386 amd64
-Depends: nvidia-glx (= #VERSION#)
+Depends: nvidia-glx (= #VERSION#), ${misc:Depends}
Provides: libgl-dev
Conflicts:
Bug#533518: nvidia-graphics-drivers: improved handling of generated files
Package: nvidia-graphics-drivers
Version: 185.18.14-1
Severity: normal
Tags: patch
Hi,
here comes a patch that improves handling of generated files:
* do not regenerate debian/control during build (using code inspired by
and stolen from linux-support)
* no longer ship generated files in the source package, they are
regenerated during build anyway
* no more messsing around with debian.binary/changelog
After applying the patch, the following changes have to be made:
* rename debian/control.in to debian/control.gen.in
* remove all generated files (also from svn repository)
except debian/control (removing everything that's missing after
running debian/rules clean should be fine)
* there is a new generated file debian/control.md5sum (generated and
updated during debian/rules clean) that needs to be added to the svn
repository
debian/rules clean will now regenerate debian/control and
debian/control.md5sum (if neccessary) and the build will bomb if
debian/control{,.md5sum} is not up-to-date
Andreas
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (800, 'testing'), (800, 'stable'), (600, 'unstable'), (130,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.28-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Index: debian/rules
===
--- debian/rules (revision 758)
+++ debian/rules (working copy)
@@ -27,14 +27,15 @@
dirname_x86:=$(shell sh debian/upstream_info DIRNAME_X86)
dirname_x86_64:=$(shell sh debian/upstream_info DIRNAME_X86_64)
-AUTOGEN=debian/nvidia-kernel-source.README.Debian debian/control \
+AUTOGEN=debian/nvidia-kernel-source.README.Debian \
debian/copyright debian/nvidia-glx.links debian/nvidia-glx-dev.links \
debian/nvidia-libvdpau.links debian/nvidia-libvdpau-ia32.links \
debian/nvidia-glx.override debian/nvidia-glx.docs debian/nvidia-glx.examples \
debian/nvidia-libvdpau.docs \
debian/nvidia-glx.postrm debian/nvidia-glx.init \
debian/nvidia-glx-ia32.override debian/nvidia-glx-ia32.links \
-debian/nvidia-kernel-source.docs debian/nvidia-glx-dev.preinst
+debian/nvidia-kernel-source.docs debian/nvidia-glx-dev.preinst \
+debian.binary/changelog
@@ -51,12 +52,12 @@
INSTALL_PROGRAM += -s
endif
-version-change: version-clean $(AUTOGEN) clean
+version-change: version-clean debian/control $(AUTOGEN) clean
configure: configure-stamp
.PHONY: configure-stamp
-configure-stamp: version-clean $(AUTOGEN)
+configure-stamp: version-clean debian/control $(AUTOGEN)
dh_testdir
# extract both so we can fetch the kernel object code for both arches
./${filename_x86} --extract-only
@@ -71,11 +72,11 @@
# done; \
fi
- sed 's/^nvidia-graphics-drivers/nvidia-kernel/g' debian/changelog debian.binary/changelog
+ touch configure-stamp
+debian.binary/changelog: debian/changelog
+ sed 's/^nvidia-graphics-drivers/nvidia-kernel/g' $ $@
- touch configure-stamp
-
.PHONY: build
build: configure-stamp build-stamp
@@ -87,7 +88,7 @@
build-kernel:
.PHONY: build-kernel-stamp
-build-kernel-stamp:
+build-kernel-stamp: debian.binary/changelog
dh_testroot
dh_testdir
@@ -133,7 +134,7 @@
touch build-kernel-stamp
.PHONY: clean
-clean:
+clean: version-clean
dh_testdir
dh_testroot
rm -f build-stamp build-kernel-stamp configure-stamp
@@ -142,7 +143,10 @@
rm -fr $(dirname_x86) $(dirname_x86_64) nvidia-kernel.tar.bz2
rm -fr debian/temp
+ $(MAKE) -f debian/rules debian/control
+ rm -f debian/control.gen
+
.PHONY: install
install: build-stamp build-kernel-stamp
dh_testdir
@@ -308,6 +312,35 @@
$ $@
+__BINNMU := $(shell dpkg-parsechangelog | sed -ne 's,^Version: .*+b\(.*\)$$,\1,p')
+
+CONTROL_FILES += debian/changelog debian/control.gen.in debian/rules debian/upstream_info
+debian/control: $(CONTROL_FILES)
+ifeq ($(wildcard debian/control.md5sum),)
+ $(MAKE) -f debian/rules debian/control-real
+else ifeq ($(__BINNMU),)
+ md5sum --check debian/control.md5sum --status || \
+ $(MAKE) -f debian/rules debian/control-real
+else
+ grep -v debian/changelog debian/control.md5sum | md5sum --check - --status || \
+ $(MAKE) -f debian/rules debian/control-real
+endif
+
+debian/control-real: $(CONTROL_FILES)
+ rm -f debian/control.gen
+ $(MAKE) -f debian/rules debian/control.gen
+ mv debian/control.gen debian/control
+ md5sum debian/control $^ debian/control.md5sum
+ @echo
+ @echo This target is made to fail intentionally, to make sure
+ @echo that it is NEVER run during the automated build. Please
+ @echo ignore the following error, the debian/control file has
+ @echo been generated SUCCESSFULLY.
+ @echo
+ exit 1
+
+
+
# Build architecture dependant packages using the common target.
.PHONY: binary-arch
binary-arch: build-stamp build-kernel-stamp install
@@ -318,5 +351,11 @@
.PHONY: version-clean
version-clean:
- rm -f ${AUTOGEN} || true
-
Bug#534936: pbuilder-buildpackage reinstalls fakeroot and breaks the build environment that way
Package: pbuilder Version: 0.188 Severity: normal Hi Junichi, fakeroot in testing is currently broken (in respect to libc6-dev-i386 because of the /emul/ia32-linux/ transition in unstable), so I manually downgraded it to the working version from stable in my squeeze builder after the last update. Unfortunately pbuilder-buildpackage installs fakeroot after satisfying the build dependencies causing an update of the already installed version and breaking everything else (if libc6-dev-i386 installed). If the reinstallation could be skipped if the package is already present everything should work out fine. fakeroot gets added to the EXTRAPACKAGES list at the beginning of /usr/lib/pbuilder/pbuilder-buildpackage. For now I will block the bad version in /etc/apt/preferences: Package: fakeroot Pin: release stable Pin-Priority: 501 Unfortunately the following intuitive solution does not work (#454080): Package: fakeroot Pin: version 1.12.4 Pin-Priority: -1 Andreas -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (800, 'stable'), (600, 'unstable'), (130, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages pbuilder depends on: ii coreutils 7.4-2The GNU core utilities ii debconf [debconf-2.0] 1.5.26 Debian configuration management sy ii debianutils 3.1.3Miscellaneous utilities specific t ii debootstrap 1.0.10lenny1 Bootstrap a basic Debian system ii wget1.11.4-2 retrieves files from the web Versions of packages pbuilder recommends: ii devscripts2.10.50scripts to make the life of a Debi ii fakeroot 1.12.2 Gives a fake root environment ii sudo 1.7.0-1Provide limited super user privile Versions of packages pbuilder suggests: ii cowdancer 0.56 Copy-on-write directory tree utili ii gdebi 0.3.11debian1+nmu1 Simple tool to install deb files pn pbuilder-uml none (no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534938: inconsistent naming of lintian tags
Package: lintian Version: 2.2.12 Severity: normal Hi, there is inconsistent naming used for several lintian tags, e.g. shared-lib-without-dependency-information shlib-with-non-pic-code Probably only one prefix (shlib or shared-lib) should be used. Andreas -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (800, 'stable'), (600, 'unstable'), (130, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lintian depends on: ii binutils 2.19.1-1 The GNU assembler, linker and bina ii diffstat 1.47-1produces graph of changes introduc ii dpkg-dev 1.15.2Debian package development tools ii file 5.03-1Determines file type using magic ii gettext0.17-6GNU Internationalization utilities ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libapt-pkg-perl0.1.23Perl interface to libapt-pkg ii libdigest-sha-perl 5.47-1Perl extension for SHA-1/224/256/3 ii libipc-run-perl0.82-1Perl module for running processes ii libparse-debianchangel 1.1.1-2 parse Debian changelogs and output ii libtimedate-perl 1.1600-9 Time and date functions for Perl ii liburi-perl1.37+dfsg-1 Manipulates and accesses URI strin ii man-db 2.5.5-2 on-line manual pager ii perl [libdigest-sha-pe 5.10.0-23 Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarchnone (no description available) pn libtext-template-perl none (no description available) ii man-db2.5.5-2on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534940: lintian: inconsistent reporting of affected files
Package: lintian Version: 2.2.12 Severity: normal Hi, the way affected files are reported by linitian is inconsistent, some tags report them with a leading './', others don't. E.g. shared-lib-without-dependency-information ./usr/lib/libfoo.so.1.2.3 shlib-with-non-pic-code usr/lib/libfoo.so.1.2.3 Probably only one form should be used and the ./ prefix is not needed IMO. Andreas -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (800, 'stable'), (600, 'unstable'), (130, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lintian depends on: ii binutils 2.19.1-1 The GNU assembler, linker and bina ii diffstat 1.47-1produces graph of changes introduc ii dpkg-dev 1.15.2Debian package development tools ii file 5.03-1Determines file type using magic ii gettext0.17-6GNU Internationalization utilities ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libapt-pkg-perl0.1.23Perl interface to libapt-pkg ii libdigest-sha-perl 5.47-1Perl extension for SHA-1/224/256/3 ii libipc-run-perl0.82-1Perl module for running processes ii libparse-debianchangel 1.1.1-2 parse Debian changelogs and output ii libtimedate-perl 1.1600-9 Time and date functions for Perl ii liburi-perl1.37+dfsg-1 Manipulates and accesses URI strin ii man-db 2.5.5-2 on-line manual pager ii perl [libdigest-sha-pe 5.10.0-23 Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarchnone (no description available) pn libtext-template-perl none (no description available) ii man-db2.5.5-2on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534942: diversion-for-unknown-file: false positives if output redirection is used
Package: lintian Version: 2.2.12 Severity: normal Hi, the diversion-for-unknown-file check produces false positives if output redirection is used in the dpkg-divert invokation: nvidia-glx: diversion-for-unknown-file usr/lib/libGL.so.1.2/dev/null preinst:89 for the following command: dpkg-divert --add --rename --package nvidia-glx --divert /usr/lib/nvidia/libGL.so.1.2.xlibmesa /usr/lib/libGL.so.1.2 /dev/null Andreas -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (800, 'stable'), (600, 'unstable'), (130, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lintian depends on: ii binutils 2.19.1-1 The GNU assembler, linker and bina ii diffstat 1.47-1produces graph of changes introduc ii dpkg-dev 1.15.2Debian package development tools ii file 5.03-1Determines file type using magic ii gettext0.17-6GNU Internationalization utilities ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libapt-pkg-perl0.1.23Perl interface to libapt-pkg ii libdigest-sha-perl 5.47-1Perl extension for SHA-1/224/256/3 ii libipc-run-perl0.82-1Perl module for running processes ii libparse-debianchangel 1.1.1-2 parse Debian changelogs and output ii libtimedate-perl 1.1600-9 Time and date functions for Perl ii liburi-perl1.37+dfsg-1 Manipulates and accesses URI strin ii man-db 2.5.5-2 on-line manual pager ii perl [libdigest-sha-pe 5.10.0-23 Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarchnone (no description available) pn libtext-template-perl none (no description available) ii man-db2.5.5-2on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534979: ia32-apt-get: installation fails if sources.list is missing because sources.list.d/ is in use
Package: ia32-apt-get Version: 18 Severity: normal Hi, installation fails with the following error: Setting up ia32-apt-get (18) ... Converting for architecture amd64: sources.list /usr/share/ia32-apt-get/parse-sources.list: line 60: /etc/apt/sources.list: No such file or directory dpkg: error processing ia32-apt-get (--configure): subprocess installed post-installation script returned error exit status 1 I actually don't have a sources.list file because everything is configured in sources.list.d/. Looking at the other bug reports, this failure is probably a good thing because my system is not messed up by modifying/destroying my sources.list. Andreas -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (800, 'stable'), (600, 'unstable'), (130, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534873: [patch] emul/ia32-linux transition
-glx-ia32 --divert \
- /emul/ia32-linux/usr/lib/nvidia/libGL.so.1.2.ia32-libs \
- /emul/ia32-linux/usr/lib/libGL.so.1.2 /dev/null
- dpkg-divert --remove --rename --package nvidia-glx-ia32 --divert \
- /emul/ia32-linux/usr/lib/nvidia/libGL.so.ia32-libs \
- /emul/ia32-linux/usr/lib/libGL.so /dev/null
+ test -d /usr/lib32/nvidia \
+ rmdir /usr/lib32/nvidia || true;
- test -d /emul/ia32-linux/usr/lib/nvidia \
- rmdir /emul/ia32-linux/usr/lib/nvidia || true;
-
- ldconfig
-
;;
-
+
upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
+;;
-
-;;
-
*)
echo postrm called with unknown argument \`$1' 2
exit 0
-
+;;
esac
@@ -62,3 +52,5 @@
# generated by other debhelper scripts.
#DEBHELPER#
+
+exit 0
Index: debian/changelog
===
--- debian/changelog (.../anbe-10-0-cleanup-autogenerated-files) (revision 788)
+++ debian/changelog (.../anbe-20-1-emul-ia32-transition) (revision 788)
@@ -2,8 +2,10 @@
* Non-maintainer upload.
* do not ship generated files in the source package
+ * /emul/ia32-linux/usr/lib to /usr/lib32 transition (closes: 534873)
+ * cleanup /emul/ia32-linux/usr/lib/tls/libnvidia-tls.so.1
- -- Andreas Beckmann deb...@abeckmann.de Sun, 28 Jun 2009 16:55:38 +0200
+ -- Andreas Beckmann deb...@abeckmann.de Sun, 28 Jun 2009 19:40:22 +0200
nvidia-graphics-drivers (185.18.14-1) unstable; urgency=low
Index: debian/rules
===
--- debian/rules (.../anbe-10-0-cleanup-autogenerated-files) (revision 788)
+++ debian/rules (.../anbe-20-1-emul-ia32-transition) (revision 788)
@@ -231,21 +231,21 @@
if [ $(DEB_BUILD_ARCH) = amd64 ] ; then \
install $(dirname)/usr/lib32/libGLcore.so.${version} \
- $(CURDIR)/debian/nvidia-glx-ia32/emul/ia32-linux/usr/lib ; \
+ $(CURDIR)/debian/nvidia-glx-ia32/usr/lib32 ; \
install $(dirname)/usr/lib32/libGL.so.${version} \
- $(CURDIR)/debian/nvidia-glx-ia32/emul/ia32-linux/usr/lib ; \
+ $(CURDIR)/debian/nvidia-glx-ia32/usr/lib32 ; \
install $(dirname)/usr/lib32/libcuda.so.${version} \
- $(CURDIR)/debian/nvidia-glx-ia32/emul/ia32-linux/usr/lib ; \
+ $(CURDIR)/debian/nvidia-glx-ia32/usr/lib32 ; \
install $(dirname)/usr/lib32/libvdpau.so.${version} \
- $(CURDIR)/debian/nvidia-libvdpau-ia32/emul/ia32-linux/usr/lib ; \
+ $(CURDIR)/debian/nvidia-libvdpau-ia32/usr/lib32 ; \
install $(dirname)/usr/lib32/libvdpau_nvidia.so.${version} \
- $(CURDIR)/debian/nvidia-libvdpau-ia32/emul/ia32-linux/usr/lib ; \
+ $(CURDIR)/debian/nvidia-libvdpau-ia32/usr/lib32 ; \
install $(dirname)/usr/lib32/libvdpau_trace.so.${version} \
- $(CURDIR)/debian/nvidia-libvdpau-ia32/emul/ia32-linux/usr/lib ; \
+ $(CURDIR)/debian/nvidia-libvdpau-ia32/usr/lib32 ; \
install $(dirname)/usr/lib32/libnvidia-tls.so.${version} \
- $(CURDIR)/debian/nvidia-glx-ia32/emul/ia32-linux/usr/lib ; \
+ $(CURDIR)/debian/nvidia-glx-ia32/usr/lib32 ; \
install $(dirname)/usr/lib32/tls/libnvidia-tls.so.${version} \
- $(CURDIR)/debian/nvidia-glx-ia32/emul/ia32-linux/usr/lib/tls ; \
+ $(CURDIR)/debian/nvidia-glx-ia32/usr/lib32/tls ; \
fi
install -m 755 $(dirname)/usr/bin/nvidia-bug-report.sh $(CURDIR)/debian/nvidia-glx/usr/bin/
Index: debian/nvidia-libvdpau-ia32.links.in
===
--- debian/nvidia-libvdpau-ia32.links.in (.../anbe-10-0-cleanup-autogenerated-files) (revision 788)
+++ debian/nvidia-libvdpau-ia32.links.in (.../anbe-20-1-emul-ia32-transition) (revision 788)
@@ -1 +1 @@
-emul/ia32-linux/usr/lib/libvdpau.so.#VERSION# emul/ia32-linux/usr/lib/libvdpau.so
+usr/lib32/libvdpau.so.#VERSION# usr/lib32/libvdpau.so
Index: debian/nvidia-libvdpau-ia32.dirs
===
--- debian/nvidia-libvdpau-ia32.dirs (.../anbe-10-0-cleanup-autogenerated-files) (revision 788)
+++ debian/nvidia-libvdpau-ia32.dirs (.../anbe-20-1-emul-ia32-transition) (revision 788)
@@ -1 +1 @@
-emul/ia32-linux/usr/lib
+usr/lib32
Bug#535268: pbuilder: option to replace /dev/random with /dev/urandom inside build environment
Package: pbuilder Version: 0.188 Severity: wishlist Hi Junichi, what about an option to replace /dev/random with /dev/urandom inside the chroot? Installation of ia32-apt-get (current sid) during package build every time drains /dev/random and blocks until enough new random bits can be collected. For creating some temporary gpg keys/keyrings/whatever, the use of /dev/urandom should be sufficient. Are there any uses of pbuilder that might need a good /dev/random device? What about a new setting for pbuilder to replace /dev/random by a symlink to /dev/urandom a) never (as it is now, probably should be the default) b) during build c) always (also during login/execute --save-after, create/update, ...) == DEVURANDOMASDEVRANDOM=never|build|always Once a setting of 'always' was used in a session that was saved (--save-after, update, create) that change might be permanent and not automatically undone by setting 'never' or 'build'. Andreas -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (800, 'stable'), (600, 'unstable'), (130, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages pbuilder depends on: ii coreutils 7.4-2The GNU core utilities ii debconf [debconf-2.0] 1.5.26 Debian configuration management sy ii debianutils 3.1.3Miscellaneous utilities specific t ii debootstrap 1.0.10lenny1 Bootstrap a basic Debian system ii wget1.11.4-2 retrieves files from the web Versions of packages pbuilder recommends: ii devscripts2.10.52scripts to make the life of a Debi ii fakeroot 1.12.2 Gives a fake root environment ii sudo 1.7.0-1Provide limited super user privile Versions of packages pbuilder suggests: ii cowdancer 0.56 Copy-on-write directory tree utili ii gdebi 0.3.11debian1+nmu1 Simple tool to install deb files pn pbuilder-uml none (no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535274: /usr/share/ia32-apt-get/.gnupg should probably be moved to /etc
Package: ia32-apt-get Version: 18 Severity: normal Hi, ia32-apt-get creates /usr/share/ia32-apt-get/.gnupg with its keyrings etc. The contents should probably be moved to /etc/ia32-apt-get/. Running gpg --homedir /etc/ia32-apt-get ... should make gpg search the keyrings in /etc/ia32-apt-get/ (without .gnupg appended), no more changing $HOME needed to fool gpg. Removal of the package also leaves the empty directories /usr/share/ia32-apt-get/dists/transitional/ and /usr/share/ia32-apt-get/dists/ behind (they are removed during purge). postrm should probably try to rmdir these (and /usr/share/ia32-apt-get) after it did some cleanup in there during the remove step. Thinking again, if there are custom signatures created in /usr/share/ia32-apt-get, shouldn't this be moved to /var? Andreas -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (800, 'stable'), (600, 'unstable'), (130, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535277: pbuilder: ia32-apt-get (amd64) introduces changes to /var/cache/apt/archives/
Package: pbuilder Version: 0.188 Severity: normal Hi Junichi, ia32-apt-get introduces changes to the /var/cache/apt/archives/ layout by introducing /var/cache/apt/$ARCH/archives/ for amd64 and i386. I'm not sure how this will affect operation of pbuilder. Nor have I tried to use ia32-apt-get and see how it actually goes. On the other hand I'm happily using a single /var/cache/apt/archives/ shared between my main system (amd64) and several amd64 and i386 pbuilders for sid, squeeze, lenny (via BINDMOUNTS=/var/cache/apt/archives) and an i386 schroot environment. The cache is just never cleaned :-) So there might be no need for separate caches in ia32-apt-get at all. Andreas -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (800, 'stable'), (600, 'unstable'), (130, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages pbuilder depends on: ii coreutils 7.4-2The GNU core utilities ii debconf [debconf-2.0] 1.5.26 Debian configuration management sy ii debianutils 3.1.3Miscellaneous utilities specific t ii debootstrap 1.0.10lenny1 Bootstrap a basic Debian system ii wget1.11.4-2 retrieves files from the web Versions of packages pbuilder recommends: ii devscripts2.10.52scripts to make the life of a Debi ii fakeroot 1.12.2 Gives a fake root environment ii sudo 1.7.0-1Provide limited super user privile Versions of packages pbuilder suggests: ii cowdancer 0.56 Copy-on-write directory tree utili ii gdebi 0.3.11debian1+nmu1 Simple tool to install deb files pn pbuilder-uml none (no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535425: ia32-libs-tools/create[-all] failures
Package: ia32-libs-tools Version: 20 Severity: normal Hi Goswin, many thanks for this nice toolkit! /usr/lib/ia32-libs-tools/createi[-all] fails to do its job. I managed to track some problems down to 1. /usr/lib/ia32-libs-tools/fetch calls 'apt-get update' but fails. Running apt-get update manually works fine. I didn't look into details of this problem, just removed that line from .../fetch Is it really neccessary to call apt-get update from fetch (and every time? Wouldn't it be OK to fail during fetching packages if the lists are not up-to-date as it would happen with apt-get install? The user should just remember to run update first or live with the consequences otherwise. 2. fetching the binary/source package fails if there is more than one version available, e.g. because sources.list contains stable, testing, unstable, ... with appropriate priorities set in the preferences file, e.g. # /usr/lib/ia32-libs-tools/create bzip2 Fetching source bzip2 1.0.5-3 for bzip2 Fetching source bzip2 1.0.5-2 for bzip2 Fetching source bzip2 1.0.5-1 for bzip2 Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to find a source package for bzip2 Fetching source failed Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Get:1 http://ftp.debian.org unstable/main bzip2 1.0.5-3 [46.5kB] Fetched 46.5kB in 0s (679kB/s) All sources and packages fetched, all versions match. Enjoy. dpkg-source: error: cannot open *dsc: No such file or directory So let's try some other common syntax to select a specific variant: # /usr/lib/ia32-libs-tools/create -t testing bzip2 E: Command line option 't' [from -t] is not known. ... # /usr/lib/ia32-libs-tools/create bzip2/testing W: Unable to locate package bzip2/testing E: No packages found Reading package lists... Done Building dependency tree Reading state information... Done E: Must specify at least one package to fetch source for Fetching source failed Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Get:1 http://debian.ae.cs.uni-frankfurt.de testing/main bzip2 1.0.5-2 [45.5kB] Fetched 45.5kB in 0s (0B/s) bzip2/testing_*_i386.deb missing # /usr/lib/ia32-libs-tools/create bzip2=1.0.5-2 W: Unable to locate package bzip2=1.0.5-2 E: No packages found Reading package lists... Done Building dependency tree Reading state information... Done E: Must specify at least one package to fetch source for Fetching source failed Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Get:1 http://debian.ae.cs.uni-frankfurt.de testing/main bzip2 1.0.5-2 [45.5kB] Fetched 45.5kB in 0s (0B/s) bzip2=1.0.5-2_*_i386.deb missing Seems to work a little bit, depending on how the parameter is passed to other programs. The naming of 'create-all' and 'create' is inconsistent to what they do: 'create-all' creates new packages (no parameters, processes a list) 'create' requires a parameter (the package to work on) but only does a preparating step, not the package build. There is a script missing that builds converted packages for the command line parameter(s) together with a changes file so that all this can be uploaded to a local repository. Andreas -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (800, 'stable'), (600, 'unstable'), (130, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535430: ia32-apt-get: only convert *.list from /etc/apt/sources.list.d/
Package: ia32-apt-get Version: 20 Severity: normal Hi Goswin, there is no need to convert any file from /etc/apt/sources.list.d/ that does not match *.list as only this pattern is recognized by apt-get. Backups, disabled stuff, ... don't need to be touched. Andreas -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (800, 'stable'), (600, 'unstable'), (130, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618695: nvidia-kernel-source: Artifacts with 260.19.44 driver
You may want to try the 270.30-1 beta driver which should arrive in experimental soon. Eventually nvidia already fixed these artifacts. Otherwise the nvidia-bug-report.log.gz for both versions should be sent to nvidia, see http://www.nvnews.net/vbulletin/showthread.php?t=46678 Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619129: nvidia-kernel-dkms: black screen when start kdm after upgrading to a 260.19.44-1
On Monday, 21. March 2011 15:38:30 Pere Nubiola i Radigales wrote: Version: 260.19.44-1 after upgrading the system, when kdm start a black screen without the nvidia log apears. No error in /var/log/Xorg.o.log Did you check the kdm log? Is the problem reproducible with gdm/gdm3/xdm/...? You may want to try the 270.30-1 beta driver which should arrive in experimental soon. Eventually nvidia already fixed this problem. Otherwise the nvidia-bug-report.log.gz for both driver versions should be sent to nvidia, see http://www.nvnews.net/vbulletin/showthread.php?t=46678 Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613534: Seems to be rather a bug in nvidia, not the kernel
On Monday, 21. March 2011 09:11:43 Andreas Beckmann wrote: Please retry with 260.19.44 which is now in unstable and can be compiled for 2.6.38-rcX, too You may want to try the 270.30-1 beta driver which should arrive in experimental soon. Eventually nvidia already fixed this problem. Otherwise the nvidia-bug-report.log.gz for both driver versions should be sent to nvidia, see http://www.nvnews.net/vbulletin/showthread.php?t=46678 On Tuesday, 15. February 2011 15:13:31 Andrei POPESCU wrote: The ThinkVantage button is not producing any reaction at all in xev. This worked fine until now, including on 2.6.36-trunk-amd64. Any other things to try that might help you? Please test the new driver releases with both current (2.6.38, from unstable) and older kernels (2.6.32 from squeeze and any versions inbetween you still have installed). Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620327: Package: nvidia-kernel-dkms 260.19.44-1
Please uninstall nvidia-kernel-2.6.32-5-686 (and the other nvidia-kernel-* packages can be removed as well). Thanks. Andreas The actual bug seems to be that the prebuilt module /lib/modules/`uname -r`/nvidia/nvidia.ko takes precedence over the dkms module /lib/modules/`uname -r`/updates/dkms/nvidia.ko I need to verify this and see if anything can be improved in that setting. On 2011-04-01 07:52, Alexandr Bravo wrote: Package: nvidia-kernel-dkms 260.19.44-1 In testing distribution after last update package nvidia-kernel-dkms 260.19.44-1 produces NVIDIA kernel module with wrong version number inside. As a result Xorg can't start with nvidia because old kernel module version 195.* mismatches with version 260.* of other packages. ii nvidia-kernel-2.6.30-1-686 185.18.36-2+2.6.30-6 NVIDIA binary kernel module for Linux 2.6.30-1-686 ii nvidia-kernel-2.6.32-5-686 195.36.31+2+4+2.6.32-24 NVIDIA binary kernel module for Linux 2.6.32-5-686 ii nvidia-kernel-2.6.32-trunk-686 190.53-1+2.6.32-5NVIDIA binary kernel module for Linux 2.6.32-trunk-686 ii nvidia-kernel-common 20110213+1 NVIDIA binary kernel module support files ii nvidia-kernel-dkms 260.19.44-1 NVIDIA binary kernel module DKMS source ii nvidia-kernel-source 260.19.44-1 NVIDIA binary kernel module source # modinfo /lib/modules/`uname -r`/updates/dkms/nvidia.ko filename: /lib/modules/2.6.32-5-686/updates/dkms/nvidia.ko alias: char-major-195-* ... Looks like this string is not ok: alias: char-major-195-* I guess it should be 260 there. No. It's just a coincidence that an old upstream version (195.36.31) matches the device major number (which is the same for all driver releases). Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620327: Package: nvidia-kernel-dkms 260.19.44-1
On 2011-04-01 13:07, Alexandr Bravo wrote: Hello Andreas, Thanks, but it doesn't help: Well, what's the actual error message you get? Without this I can only guess ... Did you reboot? Unload the old module? The dmesg output while loading the module is interesting es well as the error in Xorg.0.log find /lib/modules -name nvidia.ko -ls Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630537: dh-make: use debhelper 8 by default
Package: dh-make Version: 0.58 Severity: normal Hi, dh_make creates new packages with a debhelper dependency of 7.something and sets compat level to 7. As the current stable distribution ships with debhelper 8, this compat level should be used by default. Andreas -- System Information: Debian Release: 6.0.1 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 Versions of packages dh-make depends on: ii debhelper 8.1.6 helper programs for debian/rules ii dpkg-dev 1.16.0.3 Debian package development tools ii make 3.81-8 An utility for Directing compilati ii perl 5.12.3-7 Larry Wall's Practical Extraction dh-make recommends no packages. Versions of packages dh-make suggests: ii build-essential 11.5 Informational list of build-essent -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629518: Preliminary AMD APP SDK Packaging
On 2011-06-10 16:21, Tomasz Rybak wrote: Dnia 2011-06-08, śro o godzinie 18:15 +0200, Andreas Beckmann pisze: I have prepared and use local packages for the AMD APP SDK and offer to package this for Debian once someone confirmed that it can be put into non-free. Can you put packaging information (i.e. debian/ directory) on some repository? I would like to try to build packages myself and test building PyOpenCL with them. Vcs-Svn: svn://svn.debian.org/svn/pkg-nvidia/packages/amd-app-sdk/trunk Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-nvidia/packages/amd-app-sdk/ Have fun! Comments welcome. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629823: xterm and nvidia
On 2011-06-13 12:04, Stefano Callegari wrote: I have tried more terminal: aterm, eterm and mrxvt. All have the same problem like xterm. So is it a kde4 problem, maybe kwin? Have you tried creating a new user and trying again as that user, so that all KDE user settings get freshly initialized? Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630225: [nvidia-installer-cleanup] Does not install correctly, though nvidia works!
On 2011-06-12 15:32, David Baron wrote: The nvidia-alternatives package, superseded by this one, yields the following error on installation of nvidia-glx: You didn't post the error message why nvidia-installer-cleanup didn't configure properly. Without nvidia-installer-cleanup being configured successfully, all the other packages can't be configured. Try dpkg-reconfigure nvidia-installer-cleanup Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630527: Missing diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1
Please use Xorg and MESA from unstable for now. I'm working on upgrading the diversions. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630527: Missing diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1
On 2011-06-15 17:30, Andreas Beckmann wrote: Please use Xorg and MESA from unstable for now. I'm working on upgrading the diversions. Oops, I meant testing, not unstable. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630565: After update meas to 7.10.2-4 (from 7.10.2-3), Nvidia driver seems not work
Please use Xorg and MESA from testing, not unstable for now. I'm working on upgrading the diversions. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630579: nvidia-glx: glx cannot be utilised
On 2011-06-15 13:34, Sophoklis Goumas wrote: Following a recent dist-upgrade glx does not get utilised. Please use Xorg and MESA from testing, not unstable for now. I'm working on upgrading the diversions. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625877: Problems of using the beta driver, as I use the nvidia-kernel-dkms
On 2011-06-15 21:02, M. wrote: and compositing is not working on KDE, saying that it cannot enable the OpenGL renderer. All the nvidia packages are in the 275.09.04 version: I have a suspicion that the mesa packages are the ones giving trouble: dpkg -l | grep mesa ii libgl1-mesa-dri 7.10.2-4 free implementation of the OpenGL API -- DRI modules Multiarch issue. Working on it Downgrade Xorg and MESA to the version in testing. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629518: Preliminary AMD APP SDK Packaging
On 2011-06-16 10:05, Tomasz Rybak wrote: Thanks. I was able to build it offline (only 64-bit versions, as I did not have 32-bit libraries installed). Currently amd-app-sdk-dev does not build. Will it be just meta-package depending on all AMD APP-related packages? I'm not yet sure what to put into this package ... lintian complains about: W: amd-libopencl1: package-name-doesnt-match-sonames libOpenCL1 I hope some vendor would release a free version of these libraries - like nvidia did with libvdpau1. It's just a generic wrapper, not an implentation. At the same time I was not able to install amd-libopencl1: Translation - both nvidia-libopencl1 and amd-libopencl1 provide libopencl1 and as nvidia-libopencl1 is properly installed dpkg will not install amd-libopencl1. libopencl1 is just a generic loader and can use any implementation (the icd packages). But thanks to having /usr/lib/libamdocl64.so in amd-opencl-icd python-pyopencl was able to detect and use OpenCL implementations from both NVIDIA and AMD. So current situation makes sense and works for my packages. Unfortunately nvidia and amd implementations are not identical (symbol versioning etc.) and the amd one seems to work a bit better with amd than nvidia-libopencl1. nvidia icd seems to work the same with both implemntations. (the oclinfo program from amd crashed at some point with nvidia-libopencl1) By current situation I mean nvidia-opencl-icd providing opencl-icd and depending on nvidia-libopencl1, and amd-opencl-icd providing opencl-icd and containing AMD OpenCL implementation. As long as I can install more than one ICD and all of them work I am content. That was the idea behind OpenCL and my packaging. Would it make sense to have similar meta-package for opencl-dev? This way if I have NVIDIA hardware I install nvidia-opencl-dev (providing, say, opencl-dev), and if I have AMD/ATI hardware I install amd-opencl-dev (or amd-app-sdk) which also can provide opencl-dev meta-package. May be a good idea. But finally we would need some shlibs magic to map the dependency on vendor-libopencl1 to libopencl1. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625877: Problems of using the beta driver, as I use the nvidia-kernel-dkms
On 2011-06-16 14:47, M. wrote: Thanks. I was just finishing writing a bug report against libgl1-mesa-dri. I think that I'm going to send it. Don't. There are enough duplicates of this already. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630579: nvidia-glx: glx cannot be utilised
On 2011-06-16 02:00, Tony Houghton wrote: Is there a workaround we can do in the meantime, eg changing symlinks? Downgrade Xorg and MESA to the version in testing (i.e. before multiarch MESA). Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630710: please add Breaks: libgl1-nvidia-alternatives (= 275.09.07-1)
Package: libgl1-mesa-glx Version: 7.10.2-4 Severity: normal Hi KiBi, could you add Breaks: libgl1-nvidia-alternatives (= 275.09.07-1) to libgl1-mesa-glx? (Best before the multiarch change moves to testing). The multiarch move of MESA breaks current diversion handling (many bugreports). I'm 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630775: libgl1-nvidia-glx: Does not provide libgl1 and breaks libgl1-mesa-glx
On 2011-06-17 11:11, Ben Klein wrote: libgl1-nvidia-glx = 275.09.07-1 has a breaks clause for libgl1-mesa-glx = 7.10.2-4. The current version of this package in sid is 7.10.3-1, and there is no earlier version accessible in the repository. To compound this problem, libgl1-nvidia-glx does not provide libgl1, so libgl1-mesa-glx cannot be removed in favour of libgl1-nvidia-glx for non-free nvidia driver users. Please use MESA from testing. We are working on updating the diversion handling for multiarch support. On 2011-06-16 17:19, Mario Palomo wrote: This is working for me: # apt-get install libgl1-mesa-dev=7.10.2-3 libgl1-mesa-dri=7.10.2-3 libgl1-mesa-glx=7.10.2-3 libglu1-mesa=7.10.2-3 libglu1-mesa-dev=7.10.2-3 mesa-common-dev=7.10.2-3 Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630775: libgl1-nvidia-glx: Does not provide libgl1 and breaks libgl1-mesa-glx
On 2011-06-17 11:53, Ben Klein wrote: Will libgl1-nvidia-glx be made to provide libgl1? I read on the nvidia-glx bugs that there is an argument against it. No, this will cause more trouble than it solves. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630836: module-assistant: missing linux-3.0 support
Package: module-assistant
Version: 0.11.3
Severity: normal
Hi KiBi,
m-a is not fully working with linux-3.0:
* KDREV detection is not working properly because
sub get_kpackage() does not check for something greater than 2.* and
falls back to the old 'kernel' prefix.
I would add
return linux if (($_[0] =~ /^(\d+)\.(\d+)/) ($1 = 3));
(do not expect that the version will have 3 number parts forever)
* In sub setvars() $ENV{KDREV} should be deleted if $KDREV is not
defined, otherwise you end up with an old value of KDREV (which is set
if you build for a large list of kernels) which finally produces funny
named things like
nvidia-kernel-3.0.0-rc2-amd64_275.09.07-1+2.6.26-26lenny2_amd64.deb
Andreas
-- System Information:
Debian Release: 6.0.1
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
Versions of packages module-assistant depends on:
ii bzip21.0.5-6 high-quality block-sorting file co
ii libtext-wrapi18n-perl0.06-7 internationalized substitute of Te
ii perl 5.12.3-7+b1 Larry Wall's Practical Extraction
Versions of packages module-assistant recommends:
ii liblocale-gettext-perl1.05-6+b1 Using libc functions for internati
Versions of packages module-assistant suggests:
ii build-essential 11.5 Informational list of build-essent
ii dialog1.1-20100428-1 Displays user-friendly dialog boxe
ii whiptail 0.52.11-1 Displays user-friendly dialog boxe
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630850: nvidia-glx: Unacceptable upload to Sid breaks KDE 4.6.3 install
On 2011-06-18 03:11, Marc J. Driftmeyer wrote: The upgrade to nvidia-glx and latest in Sid is broken resulting in the following: Well, that already looks much better than yesterday. Today you noticed in the package manager that something is amiss. Yesterday you could install all the stuff and then glx from nvidia was no longer working. Keep MESA from testing, or install it again. On 2011-06-16 17:19, Mario Palomo wrote to #630579: This is working for me: # apt-get install libgl1-mesa-dev=7.10.2-3 libgl1-mesa-dri=7.10.2-3 libgl1-mesa-glx=7.10.2-3 libglu1-mesa=7.10.2-3 libglu1-mesa-dev=7.10.2-3 mesa-common-dev=7.10.2-3 Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630225: [nvidia-installer-cleanup] Does not install correctly, though nvidia works!
On 2011-06-15 20:55, David Baron wrote: On Wednesday 13 Sivan 5771 11:18:53 Andreas Beckmann wrote: Try dpkg-reconfigure nvidia-installer-cleanup Andreas Did this OK. Did not change anything. Reinstall nvidia-installer-cleanup and post the error message this installation produces. There must be some error as the package does not configure properly. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630225: [nvidia-installer-cleanup] Does not install correctly, though nvidia works!
On 2011-06-18 21:26, David Baron wrote: On Saturday 16 Sivan 5771 06:28:50 Andreas Beckmann wrote: On 2011-06-15 20:55, David Baron wrote: On Wednesday 13 Sivan 5771 11:18:53 Andreas Beckmann wrote: Try dpkg-reconfigure nvidia-installer-cleanup Andreas Did this OK. Did not change anything. Reinstall nvidia-installer-cleanup and post the error message this installation produces. There must be some error as the package does not configure properly. Andreas This is it: Setting up nvidia-installer-cleanup (20110515+1) ... Setting up libglx-nvidia-alternatives (270.41.19-1) ... ERROR: /usr/lib/xorg/modules/extensions/libglx.so does exist even if it is diverted. Aborting. That's the culprit. Your system is somehow broken ... there are files that werent expected to exist ... So .. the cleanup does install. The libglx-nvidia-alternatives problem is still thee. Note that I synlinksed the extensions/libglx.so myself Undo ... and retry --it has no effect, It does - breaks libglx-nvidia-alternatives however, some programs look for something there to know that opengl is available! This is NOT what caused the original error which is what ends this report. If all the packages are installed properly, in the end you will have something in /usr/lib/xorg/modules/extensions/libglx.so So ... two things here: 1. Something does need to be in /usr/lib/xorg/modules/extensions/libglx.so whether or not diverted, dummy or for real. Otherwise, flightgear, for example, will not run! It will be once all the packages have been configured. 2. There is a problem in the libglx-nvidia-alternatives script preventing its configuration. As I posted, nothing is set up for libglx.so but that it apparently does not matter, that the libGL1 setup seems to take care of this. Your system is broken in a way unknown to libglx-nvidia-alternatives, so it gives up and lets you fix it. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630857: [nvidia-kernel-legacy-96xx-dkms] Package will not build - returns errors
On 2011-06-18 21:27, David Castor wrote: Thanks. Yes, I have tried this. This will build, but I get an error during boot - nvidia module fails to load when gdm starts and there is no X display. Is there anything useful in the logfiles (Xorg, gdm, messages, ...) ? Can you ssh into the machine? Is this the gdm insufficient timeout issue (although I havent heard about this in the 96xx legacy drivers) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521699 If you find out something more about your issue, please open a new bug report. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630940: nvidia-kernel-legacy-96xx-dkms: X server fails to start using nvidia-legacy-96xx-dkms from sid
On 2011-06-19 02:41, David Castor wrote: Package: nvidia-kernel-legacy-96xx-dkms Version: 96.43.19-1 Installed nvidia legacy 96xx kernel from sid and downgraded to squeeze Xorg files as recommended. nvidia module built with no errors. But X server does not start and log shows errors related to nvidia module. Linux jasper 2.6.38-2-686 #1 SMP Sun May 8 14:49:45 UTC 2011 i686 GNU/Linux Google is your friend :-) Looks like https://bugzilla.redhat.com/show_bug.cgi?id=484682 which suggests several kernel command line parameters to try. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625877: Problems of using the beta driver, as I use the nvidia-kernel-dkms
On 2011-06-19 15:58, M. wrote: I have a suggestion to prevent this deluge of bug reports against libgl1-mesa-dri, and this kind of changes in general: it would be lovely to receive the possible breaks _before_ updating the package, If this problem had been known in advance, appropriate Breaks: against NVIDIA and FGLRX drivers would have been added to the MESA packages. They have been added in the meantime and now your package manager will throw a lot of errors when you try to update the problematic packages. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630225: [nvidia-installer-cleanup] Does not install correctly, though nvidia works!
retitle 630225 [nvidia-installer-cleanup] does not handle local diversions of libglx.so reopen 630225 tags 630225 + wontfix thanks On 2011-06-19 14:36, David Baron wrote: (So why did not the installation script offer to remove that local diversion? Because I never encountered such a thing. And if I can't see that this happens regularily I'm not going to write extra code for this anomaly. Anyone going from Nvidia's installer to ours is likely to have put in this diversion. Otherwise, every time xorg-core is upgraded, one needs to reinstall the glx library. So it would not hurt to include in the script. Indeed, this might be considered a (lower priority) bug on the installer. Reopening and retitling the bug report while marking it as wontfix until a number of other users has the same problem. Or someone sends a patch. Eventually a fix should go into the updated diversion handling instead, see the glx-alternatives source package. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613534: Fwd: Re: Bug#613534: Seems to be rather a bug in nvidia, not the kernel
Original Message Subject: Re: Bug#613534: Seems to be rather a bug in nvidia, not the kernel Date: Mon, 20 Jun 2011 10:24:12 +0300 From: Andrei POPESCU andreimpope...@gmail.com To: Andreas Beckmann deb...@abeckmann.de On Mi, 15 iun 11, 02:57:59, Andreas Beckmann wrote: On 2011-06-14 09:54, Andrei POPESCU wrote: On Mi, 08 iun 11, 19:19:59, Andreas Beckmann wrote: Here you go. Should work with the other nvidia packages in stable, Sorry, my stable install is i386 and I switched the sid install as well. Try this, Thanks, I was able to install 195 on stable. Bug is still there, which seems to show that nvidia doesn't cope with a change in the kernel introduced somewhere between 2.6.26 and 2.6.27. I'll try to report this to Nvidia when I have the time. Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631174: libvdpau1: multiarch support needed
Package: libvdpau1 Version: 0.4.1-2 Severity: normal In order to convert the nvidia-graphics-driver package to multiarch, we need a multiarch enabled libvdpau1 with the following change: adjust the search path for implementations to look in both /usr/lib/triplet/vdpau and /usr/lib/vdpau/. Please keep the lib32vdpau1 package unmodified around for now (but libvdpau1 could get a Conflicts: lib32vdpau1 [i386]) Thanks Andreas -- System Information: Debian Release: 6.0.1 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 Versions of packages libvdpau1 depends on: ii libc6 2.13-4 Embedded GNU C Library: Shared lib ii libgcc1 1:4.6.0-10 GCC support library ii libstdc++64.6.0-10 The GNU Standard C++ Library v3 ii libx11-6 2:1.3.3-4 X11 client-side library ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar libvdpau1 recommends no packages. Versions of packages libvdpau1 suggests: ii nvidia-vdpau-driver [vdpau-d 275.09.07-1 NVIDIA vdpau driver ii nvidia-vdpau-driver-ia32 [vd 195.36.31-6 NVIDIA vdpau 32-bit driver -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630775: temporary workaround for unstable
On 2011-06-22 03:02, Nick Orlov wrote: Anyway - as a temporary workaround for unstable I ended up creating empty metapackage 'libg1-fake' which depends on libgl1-nvidia-glx and provides libgl1. This allowed to remove conflicting libgl1-mesa-glx and put system back to a consistent state. Why didn't you just downgrade libgl1-mesa-glx (and other mesa packages) to the version from testing? Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628437: Antw.: Bug#628437: Display freezes after ksplash screen is finished
On 2011-06-22 23:32, Andreas Feldner wrote: Hi, been there, done that. You used 275.09.07-1 from unstable? No change whatsoever :-( Tried downgrading to stable, which involves downgrading X and kernel as well - this works! So its not a coincidence of a hardware defect... If you are still running stable and want to try again (eventually with a later driver version), test in this order and check after each change: * upgrading driver to latest version * upgrading kernel (requires newer driver to compile the module) * upgrading Xorg * upgrading KDE Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631496: glx-alternative-nvidia: Unable to setup alternatives -- duplicate slave link /usr/lib/i386-linux-gnu/libGL.so.1
On 2011-06-24 13:35, James Vega wrote: + update-alternatives --install /usr/lib/glx glx /usr/lib/nvidia 100 --slave /usr/lib/i386-linux-gnu/libGL.so.1 glx--libGL.so.1-i386-linux-gnu /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 --slave /usr/lib/i386-linux-gnu/libnvidia-cfg.so.1 glx--libnvidia-cfg.so.1-i386-linux-gnu /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1 --slave /usr/lib/i386-linux-gnu/libXvMCNVIDIA.so.1 glx--libXvMCNVIDIA.so.1-i386-linux-gnu /usr/lib/i386-linux-gnu/nvidia/libXvMCNVIDIA.so.1 --slave /usr/lib/i386-linux-gnu/libXvMCNVIDIA_dynamic.so.1 glx--libXvMCNVIDIA_dynamic.so.1-i386-linux-gnu /usr/lib/i386-linux-gnu/nvidia/libXvMCNVIDIA_dynamic.so.1 --slave /usr/lib/xorg/modules/extensions/libglx.so glx--libglx.so /usr/lib/nvidia/libglx.so --slave /usr/lib/xorg/modules/drivers/nvidia_drv.so glx--nvidia_drv.so /usr/lib/nvidia/nvidia_drv.so --slave /usr/bin/nvidia-bug-report.sh glx--nvidia-bug-report.sh /usr/lib/nvidia/nvidia-bug-report.sh update-alternatives: error: /var/lib/dpkg/alternatives/glx corrupt: duplicate slave link /usr/lib/i386-linux-gnu/libGL.so.1 dpkg: error processing glx-alternative-nvidia (--configure): subprocess installed post-installation script returned error exit status 2 Errors were encountered while processing: glx-alternative-nvidia The command looks fine. Did your /var run full? Whats the contents of /var/lib/dpkg/alternatives/glx ? Are there any strange symbolic links at the location of the slave sources/targets? ls -la /etc/alternatives/nvidia* ls -la /etc/alternatives/glx* ls -la /usr/lib/*-linux-gnu/libGL.* ls -la /usr/lib/*-linux-gnu/nvidia Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631547: update-alternatives: corrupting the alternative database with duplicate slave links
Package: dpkg
Version: 1.15.8.10 1.16.0.3
Severity: important
File: /usr/bin/update-alternatives
Tags: squeeze sid
I just managed to corrupt the alternatives database using the
update-alternatives command, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631496
The following small script does the job reproducible:
= corrupt-alternatives.sh =
#!/bin/sh
#set -e
set -x
master=${1:-master}
touch /tmp/lo /tmp/hi /tmp/slave1 /tmp/slave2
update-alternatives --install /tmp/$master $master /tmp/lo 1 --slave
/tmp/$master-slave slave1 /tmp/slave1
update-alternatives --install /tmp/$master $master /tmp/hi 2 --slave
/tmp/$master-slave slave2 /tmp/slave2
update-alternatives --display $master
update-alternatives --remove $master /tmp/lo
update-alternatives --remove $master /tmp/hi
update-alternatives --display $master
update-alternatives --remove-all $master
update-alternatives --display $master
==
# ./corrupt-alternatives.sh test1
+ master=test1
+ touch /tmp/lo /tmp/hi /tmp/slave1 /tmp/slave2
+ update-alternatives --install /tmp/test1 test1 /tmp/lo 1 --slave
/tmp/test1-slave slave1 /tmp/slave1
update-alternatives: using /tmp/lo to provide /tmp/test1 (test1) in auto mode.
+ update-alternatives --install /tmp/test1 test1 /tmp/hi 2 --slave
/tmp/test1-slave slave2 /tmp/slave2
update-alternatives: using /tmp/hi to provide /tmp/test1 (test1) in auto mode.
+ update-alternatives --display test1
update-alternatives: error: /var/lib/dpkg/alternatives/test1 corrupt: duplicate
slave link /tmp/test1-slave
+ update-alternatives --remove test1 /tmp/lo
update-alternatives: error: /var/lib/dpkg/alternatives/test1 corrupt: duplicate
slave link /tmp/test1-slave
+ update-alternatives --remove test1 /tmp/hi
update-alternatives: error: /var/lib/dpkg/alternatives/test1 corrupt: duplicate
slave link /tmp/test1-slave
+ update-alternatives --display test1
update-alternatives: error: /var/lib/dpkg/alternatives/test1 corrupt: duplicate
slave link /tmp/test1-slave
+ update-alternatives --remove-all test1
update-alternatives: error: /var/lib/dpkg/alternatives/test1 corrupt: duplicate
slave link /tmp/test1-slave
+ update-alternatives --display test1
update-alternatives: error: /var/lib/dpkg/alternatives/test1 corrupt: duplicate
slave link /tmp/test1-slave
The problem is that the duplicate slave is inserted into the database
without proper checking and any further operation on this alternative
fails. The database it not recoverable by
'update-alternatives --remove-all broken-alternative'
The problem is reproducible in sid and squeeze, but not in lenny (which
had the perl implementation of update-alternatives) - the duplicate is
detected before inserting it into the database.
Andreas
-- System Information:
Debian Release: 6.0.1
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
Versions of packages dpkg depends on:
ii coreutils 8.5-1GNU core utilities
ii libbz2-1.0 1.0.5-6 high-quality block-sorting file co
ii libc6 2.13-7 Embedded GNU C Library: Shared lib
ii libselinux1 2.0.96-1 SELinux runtime shared libraries
ii xz-utils5.0.0-2 XZ-format compression utilities
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
dpkg recommends no packages.
Versions of packages dpkg suggests:
ii apt 0.8.10.3 Advanced front-end for dpkg
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631496: same here
On 2011-06-24 18:40, Adam Borowski wrote: Contents of my /var/lib/dpkg/alternatives/glx: Thanks! dpkg / updates-alternatives bug #631547 filed. Let me see how I can clean this up in glx-alternatives ... Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631555: Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file
On 2011-06-24 22:11, jida...@jidanni.org wrote: Latest iceweasel messages: Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory Can't find symbol 'glXBindTexImageEXT' Please provide version details about your NVIDIA setup: libvdpau1 nvidia-vdpau-driver nvidia-glx libgl1-nvidia-glx Have you tried mplayer with vdpau? Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631496: Manually fixing duplicate slave link
On 2011-06-25 09:59, Martin Ketzer wrote: Got the same problem here. Suggestions how to repair this? Delete /var/lib/dpkg/alternatives/glx /etc/alternatives/glx and run dpkg --configure --pending or better reinstall glx-alternative-mesa glx-alternative-nvidia Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622399: nvidia-glx: nvidia blob 206.19.44-1 Draws some gnome-buttons incorrectly
On 2011-04-12 20:44, Hugo A. M. Torres wrote: Package: nvidia-glx Version: 260.19.44-1 The nvidia binary drivers seem to draw some buttons in gnome incorrectly. Could someone of you try the 270.30 beta drivers (packages are in experimental) and see if they fix the problem? Thanks Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613798: nvidia-kernel-dkms: build fails with 2.6.38-rc kernels
On Saturday, 19. March 2011 20:22:19 Andy Wettstein wrote: Package: nvidia-kernel-dkms Version: 260.19.44-1 Followup-For: Bug #613798 This still doesn't build correctly on 2.6.38. There is an included file What kernel are you using? It works for me using the Debian 2.6.38-2 packages. that no longer exists. In nv-linux.h this line should be commented: #include linux/smp_lock.h http://www.nvnews.net/vbulletin/showthread.php?t=160714 -- Package-specific info: uname -a: Linux bob 2.6.38-0.slh.5-aptosid-amd64 #1 SMP PREEMPT Sat Mar 19 00:10:17 UTC 2011 x86_64 GNU/Linux Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622888: lintian: multi-arch libraries with arch-dependent overrides
Package: lintian Version: 2.5.0~rc2 Severity: normal Hi, I just came across a possible problem with multi-arch support of libraries that have arch-dependent overrides. I do not mean overrides that simply differ in the triplet, that is covered in bug #617991: lintian overrides should support more precise pattern matching. The more interesting case is a package that has actually different overrides per arch and therefore can't be covered by better wildcard matching. For example the libgl1-nvidia-glx package has the following (and some more) overrides on i386: # The NVIDIA license does not allow any form of modification. libgl1-nvidia-glx: binary-has-unneeded-section libgl1-nvidia-glx: shared-lib-without-dependency-information libgl1-nvidia-glx: shlib-with-non-pic-code libgl1-nvidia-glx: shlib-without-PT_GNU_STACK-section libgl1-nvidia-glx: spelling-error-in-binary and on amd64: # The NVIDIA license does not allow any form of modification. libgl1-nvidia-glx: binary-has-unneeded-section libgl1-nvidia-glx: shared-lib-without-dependency-information libgl1-nvidia-glx: shlib-with-executable-stack libgl1-nvidia-glx: spelling-error-in-binary Installing different overrides files in different architectures of a Multi-Arch: same package will cause a file conflict on /usr/share/lintian/overrides/package as described in http://wiki.debian.org/Multiarch/Implementation Note that any files in /usr/share or /etc must be byte-for-byte identical across architectures, otherwise file conflicts will result! ... Installing a superset of the overrides on all architectures will cause unused-override warnings (which could be overridden ...). I see the follwing possible solutions, but there are probably more and better ones: 1. allow installation of overrides in /usr/share/lintian/overrides/package:arch (using the multi-arch selection syntax for dpkg and friends) or /usr/share/lintian/overrides/package.arch (but that allows for file conflicts between packages foobar and foobar.i386) or whatever suffix dpkg will use to distinguish files from same package, different arch in /var/lib/dpkg/info. This could be done automatically by dh_lintian when encountering a debian/[package.]lintian-overrides.arch file for a Multi-Arch: same package in debian/compat level 9. Lintian needs to be changed to prefer overrides/package:arch over overrides/package. A package providing more than one file in /usr/share/lintian/overrides/ is malformed. 2. add :arch suffix to the overrides as in libgl1-nvidia-glx:i386: shlib-with-non-pic-code libgl1-nvidia-glx:amd64: shlib-with-executable-stack libgl1-nvidia-glx: spelling-error-in-binary and ignore override entries for foreign architectures. The :arch suffix may not be used for Arch: all packages. A disadvantage I see here is that it is not easy to exclude an override for just one architecture, one has to enumerate all other archs and add the override for them. This could be solved by 3.: 3. add architecture selection similar to dpkg as in libgl1-nvidia-glx [i386]: shlib-with-non-pic-code libgl1-nvidia-glx [!i386]: shlib-with-executable-stack libgl1-nvidia-glx [amd64, i386]: spelling-error-in-binary Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620426: External display no longer recognised on X startup
On 2011-04-01 22:35, Anselm Lingnau wrote: Package: nvidia-glx Version: 260.19.44-1 Could you first retry with 270.30-1 which is available in experimental? I use an HP Elitebook 8440p laptop with the HP docking station. An HP w2207h LCD display is attached to the DVI output of the docking station. I use a minimal xorg.conf as per the package README.Debian file. When the laptop is booted in the docked state, the GRUB and Linux boot messages appear on the external LCD but X (when it starts) is displayed on the laptop's own screen. Until very recently it used to be the case that X also used the external LCD by default. It is possible to redirect the X display manually from the laptop screen to the external LCD once a session is running, using the Nvidia control panel, but this is a major inconvenience. When the laptop is not docked and not connected to the external display, everything works fine. Could this be related to changes in X? You are running Xorg from unstable. As Xorg 1.9 does not work with the 195.xx driver you probably updated X and NVIDIA at the same time, making the problem harder to debug. If the 270.xx driver does not fix the problem, could you switch back to Xorg from squeeze (the newer NVIDIA drivers work there, too) to make sure this is actually a problem in the NVIDIA driver? Please test Xorg 1.7 with 270.xx, 260.xx and 195.xx drivers. Thanks Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619129: black screen when start kdm after upgrading to a 260.19.44-1
On 2011-03-24 09:38, Pere Nubiola Radigales wrote: I am downloded the 270.30-1 version from the experimental and have the same problem. The problem occurs also whit xdm and gdm. I am changed the driver with the vesa driver and it runs. Does the problem occur in the [kgx]dm login screen or when the user session is started? If it happens when starting the user session, create a new user so that all user configuration is reinitialized. How does xorg.conf look like? Please try a minimal one as described in README.Debian in the nvidia-glx package. If all this does not help, try downgrading Xorg to the version in squeeze (xserver-xorg-core 1.7 etc.) The newer NVIDIA drivers do work there. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615193: xserver-xorg-core: der server bricht in verbindung mit xdm und nouveau zusammen
On Saturday, 26. February 2011 12:22:21 Cyril Brulebois wrote: Erst habe ich das ganze System neu ohne grafische Oberfläche installiert. Dann habe ich den xorg installiert. Darauf habe ich xdm und fluxbox installiert. Nach einem Neustart habe ich mich über xdm angemeldet und es erschien erwartungsgemäß fluxbox. Nach ein paar Minuten rührte sich jedoch nicht mehr der Mauszeiger. Kurz darauf versagte die Tastatur. Und es erschien ein schwarzer Bildschirm mit der Aufzählung aller geladenen Bibliotheken. Von nouveau bis zu gtk. Danach musste ich den Computer über die Einschaltaste neustarten. Das Spiel habe ich dann noch 4 mal versucht. und im abschließenden Teil xdm und nouveau deinstalliert. You seem to be talking about nouveau, but your logs are about nvidia. Nothing I can do here, but reassign the bug there. Please try the new nvidia driver packages 260.19.44-1 from unstable and report if the problem persists. Thanks Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617286: base: ctrl+alt+F# doesn't work/physical screen freezes, mouse and keyboard irresponsive
On Tuesday, 8. March 2011 01:07:14 dl wrote: I attached the required files. additionally, i should point out that I did not get the nvidia driver from the debian repositoire, so maybe my bug report might not interest you. (I did not know that the bug was related to the graphical card driver). NVIDIA-Linux-x86_64-260.19.29.run was what i used to first get the driver working and the instructions I found in the internet (which were basically, use the right version of the gcc compiler -- I attached them as well). I did so because last year I had no success in getting the nvidia card working properly using debian packages. A new driver release (260.19.44) is available as packages in unstable. Please first run 'nvidia-installer --uninstall' to revert all changes done by the installation you did with NVIDIA-Linux-x86_64-260.19.29.run. If the problem persists, you should report this directly to NVIDIA, following their instructions: http://www.nvnews.net/vbulletin/showthread.php?t=46678 I suppose i have to run that script again and recompile things, or could you point out the right way of doing it: what debian packages i should use that would not break with upgrades? nvidia-glx and nvidia-kernel-dkms should pull everything you need. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618443: gtk2-engines-oxygen: Eclipse make X crash with that theme
On Tuesday, 15. March 2011 14:54:04 Julien Cristau wrote: reassign 618443 nvidia-glx kthxbye An X crash is an X bug, reassigning to the driver. What version of the nvidia driver were you using? Please retry with the driver 260.19.44-1 packages just uploaded to unstable. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618695: nvidia-kernel-source: Artifacts with 260.19.44 driver
tags 618695 + upstream moreinfo thanks On 2011-03-17 18:37, Daniel Franganillo wrote: The recent upgrade to nvidia driver 260.19.44 resulted in lots of artifacts on my Gnome Desktop. Hi Daniel, this seems to be a bug in the binary driver, so we can't do anything about it. You may want to report it directly to NVIDIA, following their bug reporting instructions: http://www.nvnews.net/vbulletin/showthread.php?t=46678 If you report it to NVIDIA, please drop a note here with the URL. Thanks Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618695: nvidia-kernel-source: Artifacts with 260.19.44 driver
tags 618695 - upstream thanks On 2011-03-18 10:54, Daniel Franganillo wrote: Its not a bug in the binary blob. The same machine with an ArchLinux Installation (same driver, same card, same xorg version) works fine (no artifacts). How can I give more information about this bug? * create a completely new user and test with that account. You may have some broken configuration in your home. Or did you use the same home for ArchLinux? * try different window managers, different themes, default settings, ... * try different icewaesel version, disabling all plugins, ... Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613534: Seems to be rather a bug in nvidia, not the kernel
found 613536 260.19.36 tags 613536 + moreinfo upstream thanks On Sunday, 20. March 2011 22:51:13 Andrei Popescu wrote: Further experiments show that this bug happens only with nvidia and kernel 2.6.37 or newer, it does not happen with nouveau. I tried to test on squeeze (older Xorg), but the kernel module won't compile on 2.6.38 from unstable. Please retry with 260.19.44 which is now in unstable and can be compiled for 2.6.38-rcX, too If the problem persists, please report this bug to nvidia, following their bug reporting guidelines: http://www.nvnews.net/vbulletin/showthread.php?t=46678 and post a note here that (and where) it has been forwarded. Thanks Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613534: Seems to be rather a bug in nvidia, not the kernel
# uups, copied wrong bug number from previous poster notfound 613536 260.19.36 tags 613536 - moreinfo upstream found 613534 260.19.36 tags 613534 + moreinfo upstream thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613534: Seems to be rather a bug in nvidia, not the kernel
On 2011-03-23 13:40, Andreas Beckmann wrote: On Monday, 21. March 2011 09:11:43 Andreas Beckmann wrote: Please retry with 260.19.44 which is now in unstable and can be compiled for 2.6.38-rcX, too You may want to try the 270.30-1 beta driver which should arrive in experimental soon. Eventually nvidia already fixed this problem. 270.41.06-1 is now available in unstable. The module builds on 2.6.32 (squeeze), 2.6.38 (testing/unstable), 2.6.39-rcX (experimental). Just make sure you don't have binutils-gold installed, there is currently an issue when building the kernel module with -gold. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626399: libgl1-nvidia-alternatives-ia32: does not install
On 2011-05-11 18:45, rainer wrote:
Package: libgl1-nvidia-alternatives-ia32
Version: 270.41.06-1
Severity: important
the package does not install, looks like it depends on something that isnt
there... eg /usr/lib32/libGL.so.1
in /usr/lib32/ ls | grep libGL returns:
libGL.so.185.18.36
libGL.so.190.42
libGLU.so.1
libGLU.so.1.3.070701
libGLcore.so.1
libGLcore.so.185.18.36
libGLcore.so.190.42
Your system is partly broken by having used the nvidia installer in the
past. I've been working around a set of common cases, but not yours, yet.
To fix your system without waiting for a fixed upload do the following:
* delete /usr/lib32/nvidia/diversions/libGL.so.1
* reinstall libgl1-nvidia-alternatives-ia32
* reinstall ia32-libs
* finish your upgrades
Afterwards please use reportbug to provide additional information (and
run the script that collects information again):
reportbug -N 626399
and select 'x'
I want to see what is left over from nvidia installer afterwards.
Also provide me the output of
ls -la /usr/lib{,32}/lib{GL,*nvidia,cuda}*
here the complete output of the install attempt:
Thanks for the log. I see what happened. I just need to copy some
additional sanity checking code from libgl1-nvidia-alternatives to
libgl1-nvidia-alternatives-ia32 to automatically fix this on installation.
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619129: black screen when start kdm after upgrading to a 260.19.44-1
On 2011-05-09 18:10, Andreas Beckmann wrote: On 2011-03-24 09:38, Pere Nubiola Radigales wrote: I am downloded the 270.30-1 version from the experimental and have the same problem. What about 270.41.06-1 which is availble in unstable? In case you have binutils-gold installed, remove this package and rebuild the kernel module, e.g. by upgrading or reinstalling nvidia-kernel-dkms after binutils-gold was removed. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623701: nvidia-glx: GPU idle temperature ~10C higher than normal
Please leave the bug Cc:ed. In fact, I have found this issue exists with the 256 driver as well. Will I be able to install the 195 driver under Wheezy? No. The 195xx driver does not support Xorg 1.9 which is currently in testing. You could try testing/wheezy with Xorg and NVIDIA driver from stable/squeeze. Andreas On 2011-05-12 23:17, Steve Clark wrote: On Mon, 09 May 2011 18:23:32 +0200 Andreas Beckmann deb...@abeckmann.de wrote: On 2011-04-22 12:56, Steve wrote: Package: nvidia-glx Version: 260.19.44-1 This has been reported to nVidia. Do you have an URL where progress could be followed? Unfortunately, they have not replied. I'm using a Dell Precision M90 with a GeForce Go 7950GTX. Using any driver versions 260 and upwards causes the GPU idle temperature to increase by ~10C. This happens on both Squeeze and Wheezy. I am able to use the Have you tested the 270.41.06-1 driver which is now available in unstable? Yes, with the same result. Due to this issue, I have reverted back to Squeeze. The same applies there too, and only the 195 driver is usable. Above that, right up to 270, gives an increase in temperature. 256.53 driver in Squeeze without a problem, but I cannot install it in Wheezy due to a compile error. That could eventually be fixed by using the patches from a newer driver version ... In fact, I have found this issue exists with the 256 driver as well. Will I be able to install the 195 driver under Wheezy? Could you please consider downgrading the driver to version 256 in Wheezy until this issue has been resolved by nVidia. No. Newer driver releases usually add support for new cards, and that's a feature needed by many users. Fair comment. Steve -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#613534: Seems to be rather a bug in nvidia, not the kernel
On 2011-05-12 21:54, Andrei Popescu wrote: I tested 270.41.06-1 with all the kernels I have installed: $ dpkg -l linux-image-2.6.* | grep ^ii ii linux-image-2.6.32-5-amd642.6.32-31 Linux 2.6.32 for 64-bit PCs ii linux-image-2.6.36-trunk-amd642.6.36-1~experimental.1 Linux 2.6.36 for 64-bit PCs ii linux-image-2.6.37-2-amd642.6.37-2 Linux 2.6.37 for 64-bit PCs ii linux-image-2.6.38-1-amd642.6.38-1 Linux 2.6.38 for 64-bit PCs ii linux-image-2.6.38-2-amd642.6.38-5 Linux 2.6.38 for 64-bit PCs With 2.6.36 it works, with 2.6.37 it doesn't. Anything else I can test? Does this mean up to 2.6.36 all is fine, 2.6.37 and later fails? What Xorg version are you using? There are three currently available: 1.7 (stable), 1.9 (testing), 1.10 (unstable). Does switching to a different Xorg version change anything? How does your /etc/X11/xorg.conf look like? Have you tried a minimal one as described in /usr/share/doc/nvidia-glx/README.Debian.gz ? 2.6.39-rcX would be interesting, too. Have you searched the nvidia forum whether someone has reported something similar? If none of these possibilities brings a solution, you should report this directly to nvidia, following their instructions here: http://www.nvnews.net/vbulletin/showthread.php?t=46678 Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626587: lintian: negated arch-specific overrides don't work
Package: lintian
Version: 2.5.0
Severity: normal
Tags: patch
Hi,
thanks for implementing arch-specific overrides. Due to a small logic
error, the negated ones do not work. This patch for Tags.pm fixes that
behaviour:
# missing wildcard checks and sanity checking archs $arch
if ($negated) {
-$found = 1 if !$found;
-} else {
-$found = 0 if $found;
+$found = $found ? 0 : 1;
}
Andreas
-- System Information:
Debian Release: 6.0.1
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
Versions of packages lintian depends on:
ii binutils 2.21.0.20110327-3 The GNU assembler, linker and bina
ii diffstat 1.54-1produces graph of changes introduc
ii dpkg-dev 1.16.0.3 Debian package development tools
ii file 5.04-5Determines file type using magic
ii gettext0.18.1.1-3GNU Internationalization utilities
ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf
ii libapt-pkg-perl0.1.24+b1 Perl interface to libapt-pkg
ii libclass-accessor-perl 0.34-1Perl module that automatically gen
ii libdigest-sha-perl 5.48-1Perl extension for SHA-1/224/256/3
ii libemail-valid-perl0.184-1 Perl module for checking the valid
ii libipc-run-perl0.89-1Perl module for running processes
ii libparse-debianchangel 1.1.1-2.1 parse Debian changelogs and output
ii libtimedate-perl 1.2000-1 collection of modules to manipulat
ii liburi-perl1.54-2module to manipulate and access UR
ii locales2.11.2-10 Embedded GNU C Library: National L
ii man-db 2.5.7-8 on-line manual pager
ii perl [libdigest-sha-pe 5.10.1-20 Larry Wall's Practical Extraction
ii unzip 6.0-4 De-archiver for .zip files
lintian recommends no packages.
Versions of packages lintian suggests:
ii binutils-multiarch 2.21.0.20110327-3 Binary utilities that support mult
ii libhtml-parser-perl3.66-1collection of modules that parse H
ii libtext-template-perl 1.45-2Text::Template perl module
ii man-db 2.5.7-8 on-line manual pager
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/share/lintian/lib/Lintian/Tags.pm (from lintian
package)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626667: [nvidia-glx-legacy-96xx] uninstallable in unstable
On 2011-05-14 09:28, Filipus Klutiero wrote: Package: nvidia-glx-legacy-96xx Version: 96.43.19-1 Version 96xx has not been updated for X.org server 1.10, which could Correct. Nvidia has not yet updated this legacy driver. Nothing we can do here. Or do you have any other information that 96.43.19 already works with Xorg 1.10? Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626653: nvidia-kernel-common: freeze because of /dev/nvidia0 without nvidia
On 2011-05-14 02:40, sergio wrote: I have debian installed on usb hdd, so it is possible to boot it on many computers. And I have many video drivers installed on it. Do you use the nvidia driver on some machine? Otherwise just uninstall it ... Your setup is very special. You will need to reconfigure several things depending on whether nvidia gpu is available or not, e.g. /etc/X11/xorg.conf, the libGL.so.1 selection, ... /etc/init.d/nvidia-kernel from nvidia-kernel-common creates /dev/nvidia0 and /dev/nvidiactl on every boot, even I don't have nvidia card. And on each access Please have a look in /etc/default/nvidia-kernel, you can disable creating the device there. to /dev/nvidia0 udev tries to load nvidia module and computers freezes for several seconds. flashplugin-nonfree tries to do something with /dev/nvidia0 several times at start and computer freezes for about half a minute. Feel free to provide a patch for /etc/default/nvidia-kernel that checks whether nvidia video hardware is installed and skips device creation if it can be safely said that no such hardware is available. Do not assume lspci etc. are installed everywhere, so fall back to device creation if you can't properly check for the device. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#375179: /#394945: libxnvctrl and sensors-applet
Has there been any progress on these very old bugs? On Wednesday, 12. December 2007 12:01:25 Alex Murray wrote: The difference is that if hddtemp is not installed, the hddtemp module simply fails to run the hddtemp program. But if libXNVCtrl is not installed, the whole program will fail to load because of the missing shared library (assuming that libXNVCtrl even is a shared library... back when it was included in nvidia-settings it was only shipped as a static library). But libNVCtrl could be packaged separately (as it is GPL2) and sensors-applet could depend on it, then sensors-applet would load fine and it could all work as I described previously. There is now a separate libxnvctrl-dev package (in contrib) containing the headers and a static library - this stuff was not really suited to the nvidia-settings package. In case there are more things missing (more headers, another library, ... there might be some additional code available in the nvidia-settings source package), please let me know. If you need a shared library, a patch would be welcome, I never looked into the creation of shared libraries. I think we decided in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=434887 that that way to fix this is to make the various sensors-applet modules into DSOs that can be dlopen'd ... This has happened inbetween ... so someone needs to write a nvidia module for sensors-applet which needs to go into contrib ... On Tuesday, 24. October 2006 02:56:29 Sam Morris wrote: retitle -1 sensors-applet: libXNVCtrl can't read sensors of certain graphics cards So, it seems that libXNVCtrl can't read the sensors on our cards. I'm not sure about how best to contact upstream (NVIDIA) about this. Could you retry with the latest version of nvidia-settings (and libxnvctrl-dev) available in unstable? And if this does not work, try to look here: http://www.nvnews.net/vbulletin/showthread.php?t=46678 Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620526: Removal of nvidia-graphics-drivers-legacy-71xx
On 2011-05-16 19:22, Russ Allbery wrote: Andreas Beckmann deb...@abeckmann.de writes: I would prefer to replace it with some transitional packages that, well, transition to ... a debconf note describing the situation. The current packages are not installable due to the Xorg conflict and so eventually were ignored by some people. That way they never got the cleanup process ran ... having some ancient files (buggy init scripts) remaining on their systems that could cause trouble in the future. That's an even better idea. Okay, I'll not do anything for the time being until we get a chance to do that. ... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#447517: nvidia-settings: Overclocking Auto Detect never available
Hi Mikael, On Sunday, 21. October 2007 22:39:05 Mikael Åkersund wrote: Package: nvidia-settings Version: 1.0+20070502-1 After some major system upgrades (switching RAM sticks, motherboard, PSU, graphic cards and xservers) I found that nvidia-settings no longer could auto-detect the optimal overclocking frequencies. The Auto Detect button would always be greyed out even though I had enabled Coolbits in Xorg.conf In case you still have that machine (or a similar one), does the current version of nvidia-settings in unstable (270.41.06-1) still show this behavior? Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558785: nvidia-settings: Detect Displayes doesn't update Display Configuration pane if external display is changed
On Monday, 30. November 2009 15:47:42 Chris AtLee wrote: Package: nvidia-settings Version: 185.18.31-1 Could you retry this with the current version of nvidia-settings (270.41.06-1)? Thanks Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#303662: nvidia-settings: Shows PCI bus as AGP
Hi David, On Friday, 8. April 2005 01:25:00 David Liontooth wrote: Package: nvidia-settings Version: 1.0+3-1 I run x-windows off an nVidia PCI card, but nvidia-settings claims it's AGP. It also sees the OS as Linux x86 when it's really GNU/Linux amd64. You probably don't have that system any longer. But just in case you do, could you try the current version of nvidia-settings (270.41.06-1) there and see if this was fixed inbetween? Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532320: nvidia-settings: Restoring settings automatically
Hi Tony, hi Ivan, just in case NVIDIA changed something, could you try the current version of nvidia-settings (270.41.06-1) from unstable? On Monday, 8. June 2009 15:34:02 Tony Houghton wrote: Package: nvidia-settings Version: 180.22-1 The man page explains how to use .xinitrc to automatically run nvidia-settings --load-config-only when X starts. AFAIK gdm etc don't use .xinitrc for a standard GNOME Session, KDE Session etc so that advice won't work for many people. Besides improving the documentation I think it would be a good idea to add an XDG autostart entry for nvidia-settings so inexperienced users don't have the bother of editing scripts or using the likes of gnome-session-manager. AFAICT running nvidia-settings --load-config-only in the absence of a .nvidia-settings-rc or even the NVidia driver merely fails silently, so I don't think this idea poses a danger for non-NVidia users. Patches would be welcome, both for documentation and for autostart scripts. On Saturday, 14. May 2011 01:33:08 Ivan Baldo wrote: Hello. This seems the right thing to do, if the user puts a special setting in the nvidia-settings program then it expects that setting to remain for the next reboot and not to have to load the program to apply the setting again. I use all default settings but anyway... Thanks for looking this. Have a nice day!!! At least there could be a button Save these settings as defaults or whatever. (I must admit, I'm packaging this, but I'm not actively using it) Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626653: nvidia-kernel-common: freeze because of /dev/nvidia0 without nvidia
On 2011-05-15 23:43, sergio wrote: On 05/14/2011 01:44 PM, Andreas Beckmann wrote: Your setup is very special. You will need to reconfigure several things depending on whether nvidia gpu is available or not, e.g. /etc/X11/xorg.conf, the libGL.so.1 selection, ... xorg automatically depends video card and uses corresponding driver. I don't have any problems with libGL. xorg does not automatically use the nvidia driver without setting this in /etc/X11/xorg.conf. Or did you find a way to do so? In that case we would like to learn this. An xorg.conf with Driver=nvidia breaks on other systems. Please check Xorg.0.log on the nvidia machine to see which driver you are really using. nvidia has its own accelerated libGL.so.1 library which replaces the system one which is from mesa. There is also a custom libglx.so Xorg module which replaces the one from X.org. Of course these need the nvidia driver to be functional. While it is now possible to configure the libGL.so.1 and libglx.so via alternatives, there is nothing that does autodetection and selects the optimal setup for the current system. Please send me the output of update-alternatives --display libGL.so.1 nvidia doesn't use kms, but I quite shure, that xorg loads nvidia driver (if nvidia card presents), not udev by accessing /dev/nvidia0 or /dev/nvidiactl, anyway xorg loads modules for non kms drivers. In case the device nodes are missing in /dev, does Xorg really load the kernel module? Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627119: nvidia-glx ext are loaded but compiz/kde-effects causes Xserver freeze
On 2011-05-17 21:43, Marcin Woźny wrote: Package: nvidia-glx Version: 270.41.06-1 Severity: important after last (3-4 days ago) wheezy update (nvidia drivers, libc etc) there a not to forget Xorg 1.9 - 1.10 problem that makes login to system with enabled compiz or kde-kwin effect imposible (Xserver freeze). i've got enabled nvidia extensions (that's why kde's trying to turn on kwin- effects) log below. My graphic card's geforce 7300LE An interesting test would be to downgrade Xorg to 1.9 (old packages can be found on http://snapshot.debian.org/) and test again in this setup to see if the problem is related to the Xorg upgrade (this does not mean it's a bug in Xorg 1.10 - could be just bad interaction between nvidia and Xorg 1.10). If that does not solve the problem, downgrading the driver (260.xx was previously in testing/wheezy) would be the next step, which hopefully should restore the working setup. Anyway, there is not much we can do about this, the problem needs to be reported to nvidia directly. To do this, follow the instructions here: http://www.nvnews.net/vbulletin/showthread.php?t=46678 Please post an URL to a forum thread you created (or an existing one describing exactly the same problem where you might provide more information). That way we can follow progress and have a pointer for other useres that may encounter the same problem. In case you test downgrading to do some regression tests you should run nvidia-bug-report.sh in each configuration and collect the generated output files, as the difference between the setups might give some clues. Different configurations already mean the current setup without effects (if I understood you correctly, this is working) and with effects, when it's crashing. Thanks. Andreas PS: if you have binutils-gold installed, remove this package and reinstall nvidia-kernel-dkms afterwards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602936: gnuplot: wxt terminal deadlocks on loss of X11 connection
retitle 602936 gnuplot: wxt terminal deadlocks on loss of X11 connection tags 602936 - fixed-upstream + upstream forwarded 602936 https://sourceforge.net/tracker/?func=detailaid=3303816group_id=2055atid=102055 thanks I investigated this problem again, bisected gnuplot, opened a new upstream bug and constructed a new testcase that more clearly demonstrates what's happening: plot x print use xkill to terminate the plot window, then press return pause -1 print closing window set term wxt close print window closed $ gnuplot ../test2.gnuplot use xkill to terminate the window, then press return unknown: Fatal IO error 0 (Success) on X server localhost:10.0. closing window ^C^Z [1]+ Stopped gnuplot ../test2.gnuplot $ kill %1 More details can be found in upstream bug report. This problem has not been fixed in current 4.4.x release or CVS. It is not present in 4.2.x Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627119: nvidia-glx ext are loaded but compiz/kde-effects causes Xserver freeze
tags 627119 - moreinfo forwarded 627119 http://www.nvnews.net/vbulletin/showthread.php?t=160115 thanks Hi Marcin, thanks for testing several combinations. Now it seems pretty clear that the problem is independent from the Xorg version and according to the forum thread it may be related to GeForce 7300 GPUs. Now we can only hope for a new upstream release fixing this issue. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628788: debian-maintainers: Please add Andreas Beckmann as a Debian Maintainer
Package: debian-maintainers Severity: normal Hi, please add my attached key to the Debian Maintainers keyring. Thanks. Andreas -- System Information: Debian Release: 6.0.1 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 Comment: Add Andreas Beckmann deb...@abeckmann.de as a Debian Maintainer Date: Wed, 01 Jun 2011 13:01:07 +0200 Action: import Recommended-By: Russ Allbery r...@debian.org Agreement: http://lists.debian.org/debian-newmaint/2011/06/msg2.html Advocates: http://lists.debian.org/debian-newmaint/2011/06/msg0.html Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.10 (GNU/Linux) mQINBE1tPDwBEACzk8UxmjC8lhLkk24G/wDAfTRFqKuGUzmxd5dFE/LCUZdfyGr+ 68BL+0yt0Rd+Ir6zHrzOTv3VjxROG2w5HMmsXfAoMmZexLsJP8qqeQEYb7ErM2He 28z2wPMlJbCBJwNlPBFnWZLNcUJii29zQW0aJfoR6MaEcktI3bP4L1Q4OUfuAR08 13zaYvIGuXoSNk9yTs4rvTjeMftMVFOV9xkn8+XOR3U5z8w9FkXSiYY+MTU8M3fI NuWVOAuPDFMkeudxDsGPErVKkdxGwM05UC/0+MLXSzlSDvSkhERVCHvKJJAb+kQ8 KVJgeJ8IT9yQU0W49zVzhDcjv2qIR1DeJltpbIgsEYEqJyGbFenP5GqgTTqbxmRh 96s5sUxhdHffzohQvu3gFjNyHF1h6Bg8csSN+jMstTCXT2bOOGKuUc0QgjZrAXvu YRYRksQW6usVf5hDEob0Xx30c+gC+ujfPiCYAYbefnT9J2+OZ6OmnUG2YAVOanlA 8RBk7Aji4m+Y5rjb4n4bG+pq59D9lJBCX6B6L3tvwbwr5/t5vTGyZqyqSgxqd7W+ Wx0stkDf/7kJ/NU6NHAKIo53AvTomj6UowrCZ+ZV5pegYFMKmXr4+8ZgqMUdT22H zL9S+rBRnLBjkYp6pkJ9m0WwetHM85P697G5euR8wF3U3tonm6BirfwiYQARAQAB tCZBbmRyZWFzIEJlY2ttYW5uIDxkZWJpYW5AYWJlY2ttYW5uLmRlPokCNwQTAQgA IQUCTW08PAIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRBfsz+TWentCC/A EACDn+7JZf0SOJjXYL4PIGABH7GjKAr/Qo1aVQJFc97Fdwg2H7qkcHtETDwdjOTG Lz3XaP2F/S2P3DVt7kLO8zMCn4GxPlHSVzOQq5h7GeAU7u06mgsGs93PavGuZv7y nZAjxttlzq3HxE1dPq4Qty1VlLKTVPMVAmt6xC4g+PW2/A2KCE8Z6QSVbtnif76D EADsd66Mh+XuMx7CxGJmxDY0PXwW1YVtx777/Ax36ROkZ/NKBHhLJZxpSQMBOU7V rl2uTkiQ1OxsLE6wZwPpuzG4vCCXpnW8EMD8ZTjTkQdb4/dtst2uhDMJfUtM7cTR 1LOPqTppD2Uk75OzVd4krrfffuAeFn1dP46tlYTDxJ4D+vM3kDHe0DdHOzk6NTrT xaOQ5/ECsEoEMo+s6ZuHQp/L2mqybrIUn2HBhEcIA+qYpvqGm6YpG7M4ZF9kKFEW S/T+n7GAztyklHEAWafPs/K5eZfOkqL9iTacF5uMfnrbe/cMr9oDfIwBNV6ginY/ oOSl5xpiJFT0+zmPwhgeG4ZOLjawyK46QRbCQv9Gg2E6Pf9MeX2hhAfOrq5/Pxj2 i/9e9i+KE+1Xu1VUtbXNZUYKOoJCf0+fNjDEzFnQUWk44Akk4rwol3tWyHNY10pI xrrUi4v9yZOmQSclYOEBygOAcxWBH429/YUnOo7C3PMWg4hGBBARCAAGBQJNbUAa AAoJELCG9xB+vBpdskgAnjikxdazpeCdKSFzgZJgOK/Cq3zRAKC0daVvZPVKEAMY n35FSaG2R/9tZYhGBBARCAAGBQJN5WHwAAoJELUCLrWC6mU+cu4An3QNXTCWnlrn eV4JfjGKIAwCqVmAAKCN9psVwiTiD5u2PsiT1oshZxFoibkCDQRNbT1VARAAl66G scQM+9qp39yu1Ofqoq0TlEmBM33h6M/K5zWBpld8ajkPPPADsASjU0CXombxTuZY vY1ps1HjV+5peceqk+D8w1cRvNtYviylI0Gv65+VUSlZ8bcxZ3yj/HlZiT1zpJ/8 ZnB0uIoHNzDmff0wMbplUaC1z89J75335WQxAXnNxBgve064Iz1ON2U5PVlHyK8Q 0NH2A9xFp3J5n55Im7XWokOKdzxIwJ3YQ5Fnqf/j4uCSQ86gD99sTVKzCZWkA4lH ge0bJueMpChz2gU3YvR2y576IOMZH+8PMwc9XTcGqNXxzkOz2tw1lnYiSCB0bx5K O1/uCcywI6CdhkbcLvlETepYd6qI/AKJQ0/3LY3X6pqzQBX6Nfzq8NeRrbZs4wOg Rfngu1vqb1fFK5qnog8XNE+R/kqg928Z77vEHWRs83ACPIMsU+zLxdJJqtvcR2Ss i5CLv28SJrLBbor+MRIP3yySAP7uoPK9sJHgMQDWWn/3GwjHFws9upXvvey6SBFD OfGAJVDQCAQNvPw7Nnl8xJ221Oa70GJ69mA50XJrcHmdmBJ3Yf4k9nmSJRh8ERsQ jYvFh9yuKrG7WzkRiIhVlbtLCs7tCKbK4VmWgeKo/MtP5Vp/yLaSk0mqsNJxwKPJ BPkLZT13ATuDHVhc3M8Q9PCLbL7QPlKuB5K5kxcAEQEAAYkCHwQYAQgACQUCTW09 VQIbDAAKCRBfsz+TWentCBK7D/9dTWXXEMgGAwgW++rN6uVixcxjBda9jwfS5fae b+ONenPLMEtRF1YWpxrjoxrKAMn7TDJH9hcXjpyuaS3VIToYRdIBBv6kgayJfs7W Dm61mRRqcNDcgk1axc0CSCbywl1TOxcyacBSjiTWcREh0wEO45Us+HBliuJz42Cl irI4qCFqxeom+s0b7kBHPsvh3f7r6d0LP0vRFoLJukFi29ZCtg8Ri2cXEBOTjdok 9gUTeST7WdEOcOy7W2RzTEKgjHn9dej02TLyCLRVikNp8ltipG06oMUHL/LWNQ2C EZilCf+dq1jQ29tdv9Ts+oDr9KE0Vf7ATZfmWKb6b4OeXOAQ9TjitCPguQIBGW54 Ef9qE+mAHRnOPp3Ak8bUMohNrp3ZFpVTZOJOO/U4EkLGKaykL8PUnqzyarFv3JeT kKZ4jUWFCulKogkOKHzA+CCr/AAQIuUbkl0aJ7KXL2f39iqNbN9f36/XeY5PwwaR I3zZaq5BmQtB0WsZhjsOBxk6vnXw0IKVTzpuZSocu4CXL4aLWkKBs7q0YoYY4CSE f6IiiCgGWpME6rMc/HzM7bM3B+Cc+pfNOx+kWXkNfk0+4rr0DQu9IZGMpk1dve0T y9a25VNZSDfEnuTaR8ST1OXkEtoqZLwrThVD0yUz8DlEicxIi6S8PXMpQF2KrlbW A8sLTw== =/QSP -END PGP PUBLIC KEY BLOCK-
Bug#629418: nvidia-glx: PowerMizer doesn't detect change in power source
On 2011-06-06 16:16, Diggory Hardy wrote: Package: nvidia-glx Version: 270.41.19-1 Severity: normal I have set up nvidia's PowerMizer to use different profiles on mains and battery power as documented at http://tutanhamon.com.a/technovodstvo/NVIDIA-UNIX-driver/ , however incorrect URL according to nvidia-settings the laptop is always on mains power, even when it's actually running off the battery: $ nvidia-settings -q GPUPowerSource -t 0 I get the same result on my laptop using 270.41.06 driver and several versions of nvidia-settings. But I never looked at this before, so I can't say whether this was working with older releases. Eventually a driver problem. I noticed that OpenSUSE running on the same laptop detects the power source correctly, so might this have something to do withpackaging? I don't think so. But as the nvidia-settings package is built from free source code, you might want to try the binary built by nvidia. Download the driver *.run file from ftp://download.nvidia.com/XFree86/Linux-x86_64/ to a temporary directory and run it with the --extract-only command line option so that it does not start the installer. The nvidia-settings binary can be found in the root of the tree that is being extracted. Switch to that directory and run ./nvidia-settings -q GPUPowerSource -t Looks like I have 260.19.44 installed on openSUSE and 270.41.19 on this debian system. Downgrading to 260.xx does not work due to missing support for Xorg 1.10, but eventually you could try the newer driver from experimental (275.xx) and see if this was fixed. A quick search in the NVIDIA forum found the following threads: http://www.nvnews.net/vbulletin/showthread.php?t=133555 http://www.nvnews.net/vbulletin/showthread.php?t=136245 Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629203: nvidia-glx: gnome-shell corruption after suspend/resume
On 2011-06-04 15:54, Tony Houghton wrote: Package: nvidia-glx Version: 275.09-1 Please retry with 275.09.04-1. This is said to fix some KDE issues, but eventually it helps in your case, too. If it does not help, please check the NVIDIA forums for a matching report and add additional information there or create a new report. The NVIDIA bug reporting instructions can be found here: http://www.nvnews.net/vbulletin/showthread.php?t=46678 Please post the URL to an existing or new thread here, so that we may follow progress. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
