Bug#332745: addkey called with bad index 256
Package: console-common Version: 0.7.54 New console-common package causes the following error during installation and during system boot. Setting up console-common (0.7.54) ... Installing new version of config file /etc/init.d/keymap.sh ... Looking for keymap to install: NONE loadkeys: /etc/console/boottime.kmap.gz:407: addkey called with bad index 256 * Problem when loading /etc/console/boottime.kmap.gz, use install-keymap -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332791: error: `PEM_F_DEF_CALLBACK' undeclared
Package: apache2 Version: 2.0.54-5 Severity: grave Apache2 no longer builds with new openssl-0.9.8 package. /var/local/apache2/apache2-2.0.54/build-tree/apache2/modules/ssl/ssl_engine_pphrase.c: In function `ssl_pphrase_Handle_CB': /var/local/apache2/apache2-2.0.54/build-tree/apache2/modules/ssl/ssl_engine_pphrase.c:684: error: `PEM_F_DEF_CALLBACK' undeclared (first use in this function) /var/local/apache2/apache2-2.0.54/build-tree/apache2/modules/ssl/ssl_engine_pphrase.c:684: error: (Each undeclared identifier is reported only once /var/local/apache2/apache2-2.0.54/build-tree/apache2/modules/ssl/ssl_engine_pphrase.c:684: error: for each function it appears in.) make[4]: *** [ssl_engine_pphrase.slo] Error 1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332791: Acknowledgement (error: `PEM_F_DEF_CALLBACK' undeclared )
Here is a patch to fix the problem: --- httpd-2.0.54.orig/modules/ssl/ssl_toolkit_compat.h 2005-02-04 12:21:18.0 -0800 +++ httpd-2.0.54/modules/ssl/ssl_toolkit_compat.h 2005-07-06 08:50:38.46875 -0700 @@ -24,6 +24,12 @@ #ifdef OPENSSL_VERSION_NUMBER +#if (OPENSSL_VERSION_NUMBER = 0x0090800fL) +#ifndef PEM_F_DEF_CALLBACK +#define PEM_F_DEF_CALLBACK PEM_F_PEM_DEF_CALLBACK +#endif +#endif + /* * rsa sslc uses incomplete types for most structures * so we macroize for OpenSSL those which cannot be dereferenced -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332874: udev conflicts with hotplug package
Hotplug is also necessary for loading external firmware and can not be replaced by udev. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333052: uhci_hcd unknown symbol errors
Package: udev Version: 0.070-3 Severity: important When using udev with linux kernel 2.6.14-rc3, I get the following error during system boot. Plug and Play ACPI support in the kernel is loading uhci_hcd just fine, but it appears udev is attempting to load it prior to ACPI causing the unknown symbol errors. If I add uhci_hcd to the udev blacklist file, then the errors go away and uhci_hcd loads fine via ACPI. I have all my usb kernel code compiled as modules. This error does not occur with the previous version of udev. A quick hack to fix the errors with the current version of udev is: --SNIP-- --- modprobe.d/blacklist.orig 2005-10-09 19:02:15.0 -0700 +++ modprobe.d/blacklist 2005-10-09 19:01:49.0 -0700 @@ -2,6 +2,9 @@ # the hotplug subsystem. It does not affect autoloading of modules by the # kernel. This file is provided by the udev package. +# dont load usb +blacklist uhci_hcd + # usbcore is loaded as a dependency, ignore it otherwise blacklist usbcore --SNIP-- Oct 9 04:55:44 sid kernel: parport0: PC-style at 0x378, irq 7 [PCSPP(,...)] Oct 9 04:55:44 sid kernel: Linux agpgart interface v0.101 (c) Dave Jones Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_pci_suspend Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_resume_root_hub Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_pci_probe Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_check_bandwidth Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_disabled Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_release_bandwidth Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_claim_bandwidth Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_pci_resume Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_giveback_urb Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_poll_rh_status Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_pci_remove Oct 9 04:55:44 sid kernel: usbcore: registered new driver usbfs Oct 9 04:55:44 sid kernel: usbcore: registered new driver hub Oct 9 04:55:44 sid kernel: nvidia: module license 'NVIDIA' taints kernel. Oct 9 04:55:44 sid kernel: ACPI: PCI Interrupt :01:00.0[A] - Link [LNKA] - GSI 11 (level, low) - IRQ 11 Oct 9 04:55:44 sid kernel: NVRM: loading NVIDIA Linux x86 NVIDIA Kernel Module 1.0-7676 Fri Jul 29 12:58:54 PDT 2005 Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_pci_suspend Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_resume_root_hub Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_pci_probe Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_check_bandwidth Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_disabled Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_release_bandwidth Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_claim_bandwidth Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_pci_resume Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_giveback_urb Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_poll_rh_status Oct 9 04:55:44 sid kernel: uhci_hcd: Unknown symbol usb_hcd_pci_remove Oct 9 04:55:44 sid kernel: USB Universal Host Controller Interface driver v2.3 Oct 9 04:55:44 sid kernel: ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 Oct 9 04:55:44 sid kernel: ACPI: PCI Interrupt :00:11.2[D] - Link [LNKD] - GSI 11 (level, low) - IRQ 11 Oct 9 04:55:44 sid kernel: uhci_hcd :00:11.2: UHCI Host Controller Oct 9 04:55:44 sid kernel: uhci_hcd :00:11.2: new USB bus registered, assigned bus number 1 Oct 9 04:55:44 sid kernel: uhci_hcd :00:11.2: irq 11, io base 0xd800 Oct 9 04:55:44 sid kernel: hub 1-0:1.0: USB hub found Oct 9 04:55:44 sid kernel: hub 1-0:1.0: 2 ports detected Oct 9 04:55:44 sid kernel: ACPI: PCI Interrupt :00:11.3[D] - Link [LNKD] - GSI 11 (level, low) - IRQ 11 Oct 9 04:55:44 sid kernel: uhci_hcd :00:11.3: UHCI Host Controller Oct 9 04:55:44 sid kernel: uhci_hcd :00:11.3: new USB bus registered, assigned bus number 2 Oct 9 04:55:44 sid kernel: uhci_hcd :00:11.3: irq 11, io base 0xdc00 Oct 9 04:55:44 sid kernel: hub 2-0:1.0: USB hub found Oct 9 04:55:44 sid kernel: hub 2-0:1.0: 2 ports detected Oct 9 04:55:44 sid kernel: ACPI: PCI Interrupt :00:11.4[D] - Link [LNKD] - GSI 11 (level, low) - IRQ 11 Oct 9 04:55:44 sid kernel: uhci_hcd :00:11.4: UHCI Host Controller Oct 9 04:55:44 sid kernel: uhci_hcd :00:11.4: new USB bus registered, assigned bus number 3 Oct 9 04:55:44 sid kernel: uhci_hcd :00:11.4: irq 11, io base 0xe000 Oct 9 04:55:44 sid kernel: hub 3-0:1.0: USB hub found Oct 9 04:55:44 sid kernel: hub 3-0:1.0: 2 ports detected Oct 9 04:55:44 sid kernel: snd_mpu401: Unknown symbol snd_mpu401_uart_new Oct 9 04:55:44 sid kernel: ACPI: PCI Interrupt :00:11.5[C] - Link [LNKC] - GSI 5 (level, low) - IRQ 5 Oct 9 04:55:44 sid kernel: PCI: Setting
Bug#333052: uhci_hcd unknown symbol errors
Marco d'Itri wrote: reassign 333052 linux-2.6 retitle 333052 race in the modules loader? thanks On Oct 10, C.Y.M [EMAIL PROTECTED] wrote: When using udev with linux kernel 2.6.14-rc3, I get the following error during system boot. Plug and Play ACPI support in the kernel is loading uhci_hcd just fine, but it appears udev is attempting to load it prior to ACPI causing the unknown symbol errors. This randomly happens for other modules too. Looks like some race is hit when you try to modprobe a lot of modules at the same time. (BTW, can you clarify how ACPI is related to autoloading hcds?) The Plug and Play ACPI kernel config option allows the kernel to autodetect built-in mainboard resources (including usb and parallel port). When I blacklist uhci_hcd in udev, the module is then loaded by the plug and play option. Best Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335455: subversion fails to build with libdb4.3-dev
Package: subversion Version: 1.2.3dfsg1-2 Severity: important Since default Apache2 installation has upgraded to 2.0.55-2, it now requires libdb4.3-dev (instead of libdb4.2-dev). This now causes a conflict when building subversion. checking for Apache module support via DSO through APXS... found at /usr/bin/apxs2 checking httpd version... recent enough checking for socket in -lsocket... no configure: WARNING: APR-UTIL may or may not be using the specified Berkeley DB at `/usr'. Using the Berkeley DB supplied by APR-UTIL. checking for availability of Berkeley DB... no configure: error: Berkeley DB 4.0.14 wasn't found. make: *** [debian/stamp-configure] Error 1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332745: Acknowledgement (addkey called with bad index 256)
Has anyone found a solution to this? Is it just user error? I have tried to update my keymap and nothing seems to fix the error during configuration and bootup after installing console-common. After the init.d script provided by console-common is executed on bootup, thats when I see this error message again (same error when configuring console-common). But, perhaps this bug should be moved to lib console, not console-common. There is definitely a problem within one of those console packages. Best Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332745: Acknowledgement (addkey called with bad index 256)
Thank you, I must have reinstalled the keymap incorrectly the first time. After doing install-keymap us, the error has gone away. I think this bug can be closed. Best Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336778: Broken links and diversion failures
Package: nvidia-glx-dev Version: 1.0.7676-1 Severity: important I have noticed two problems related to links being created and not created in the nvidia-glx-dev package. 1) When building an application that links to libGL.so, the diversion fails to initialize because there is no usr/lib/libGL.so link created with the new dev package. For example, VLC and Mplayer now fail to build. /var/local/vlc.cvs/vlc-trunk/debian/gcc-snapshot -Wsign-compare -Wall -pipe -o libopengl_plugin.so libopengl_plugin.a -L/usr/lib -shared -lpthread -fpic -fPIC -L/usr/X11R6/lib -lGL -lGLU -u vlc_entry__0_8_4 /usr/bin/ld: cannot find -lGL collect2: ld returned 1 exit status make[5]: *** [libopengl_plugin.so] Error 1 2) There is a broken link to the include files The solution to both these problems is the following attachment. Best Regards, diff -ru nvidia-graphics-drivers-1.0.7676.orig/debian/nvidia-glx-dev.links nvidia-graphics-drivers-1.0.7676/debian/nvidia-glx-dev.links --- nvidia-graphics-drivers-1.0.7676.orig/debian/nvidia-glx-dev.links 2005-11-01 05:05:59.0 -0800 +++ nvidia-graphics-drivers-1.0.7676/debian/nvidia-glx-dev.links 2005-11-01 04:30:58.0 -0800 @@ -1 +1,2 @@ -usr/share/nvidia/includes /usr/share/doc/nvidia-glx-dev/includes +usr/lib/libGL.so.1.0.7676 usr/lib/libGL.so +usr/share/nvidia/include /usr/share/doc/nvidia-glx-dev/include diff -ru nvidia-graphics-drivers-1.0.7676.orig/debian/nvidia-glx-dev.links.in nvidia-graphics-drivers-1.0.7676/debian/nvidia-glx-dev.links.in --- nvidia-graphics-drivers-1.0.7676.orig/debian/nvidia-glx-dev.links.in 2005-11-01 05:05:59.0 -0800 +++ nvidia-graphics-drivers-1.0.7676/debian/nvidia-glx-dev.links.in 2005-11-01 04:29:26.0 -0800 @@ -1 +1,2 @@ -usr/share/nvidia/includes /usr/share/doc/nvidia-glx-dev/includes +usr/lib/libGL.so.#VERSION# usr/lib/libGL.so +usr/share/nvidia/include /usr/share/doc/nvidia-glx-dev/include
Bug#386613: Udev fails to load DVB firmware
Package: udev Version: 0.100-1 Severity: important Udev is unable to find firmware (/lib/firmware/dvb-ttpci-01.fw). DVB Drivers fail to load because hotplug does not work. The previous version of udev works fine. BR. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398677: nvidia-glx fixups
Package: nvidia-glx-dev Version: 1.0.8776-1 There are a few minor bugs that should be cleaned up in the debian packaging scripts for nvidia. 1) nvidia-glx-dev.links and nvidia-glx-dev.links.in create malformed links because a # exists before the link name in the links file. Also, the second line in the file which creates a link to nvidia includes in incorrect. Both lines should be removed from nvidia-glx-dev.links(.in). 2) A diversion is created and referenced to /usr/lib/libGL.so.1.2 (but this link is never created in /usr/lib). 3) Incorrect links are created in /usr/lib/nvidia for libGL.so.xlibmesa, libGL.so.1.xlibmesa, and libGL.so.1.2.xlibmesa. Should all of these xlibmesa library links refer to /usr/lib/libGL.so? Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398677: nvidia-glx fixups
2) A diversion is created and referenced to /usr/lib/libGL.so.1.2 (but this link is never created in /usr/lib). I'm not sure what you are getting at here. /usr/lib/libGL.so.1.2 from libgl1-mesa-glx is diverted to /usr/lib/nvidia/libGL.so.1.2.xlibmesa which shows up if libgl1-mesa-glx is installed. What link in /usr/lib are you talking about? I'm sorry, I didnt understand the proper function of a diversion. So if a package tries to install one of the diverted files, it gets placed in /usr/lib/nvidia (with an xlibmesa extension). 3) Incorrect links are created in /usr/lib/nvidia for libGL.so.xlibmesa, libGL.so.1.xlibmesa, and libGL.so.1.2.xlibmesa. Should all of these xlibmesa library links refer to /usr/lib/libGL.so? No, these are diversions of symlinks, not properly functioning ones. So, the libraries in /usr/lib/nvidia are not really used, but kept to store the diverted file? I guess I got confused when I saw this in /usr/lib/nvidia: -rw-r--r-- 1 root root 425320 2006-10-13 03:55 libGL.so.1.2.xlibmesa lrwxrwxrwx 1 root root 19 2006-11-14 08:53 libGL.so.1.xlibmesa - /usr/lib/libGL.so.1 lrwxrwxrwx 1 root root 17 2006-11-14 17:24 libGL.so.xlibmesa - /usr/lib/libGL.so -rw-r--r-- 1 root root 493686 2006-10-16 19:23 libglx.so.xlibmesa -rw-r--r-- 1 root root 107396 2006-11-14 19:33 libnvidia-cfg.so.1.0.9742 -rw-r--r-- 1 root root 2324 2006-11-14 19:33 libnvidia-tls.so.1.0.9742 -rwxr-xr-x 1 root root 3220 2006-11-14 19:33 tls_test -rw-r--r-- 1 root root 3384 2006-11-14 19:33 tls_test_dso.so Note the links of libGL.so.*.xlibmesa. It didnt seem correct when I first glanced at it. Best Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398677: nvidia-glx fixups
So, the libraries in /usr/lib/nvidia are not really used, but kept to store the diverted file? I guess I got confused when I saw this in /usr/lib/nvidia: -rw-r--r-- 1 root root 425320 2006-10-13 03:55 libGL.so.1.2.xlibmesa lrwxrwxrwx 1 root root 19 2006-11-14 08:53 libGL.so.1.xlibmesa - /usr/lib/libGL.so.1 lrwxrwxrwx 1 root root 17 2006-11-14 17:24 libGL.so.xlibmesa - /usr/lib/libGL.so -rw-r--r-- 1 root root 493686 2006-10-16 19:23 libglx.so.xlibmesa -rw-r--r-- 1 root root 107396 2006-11-14 19:33 libnvidia-cfg.so.1.0.9742 -rw-r--r-- 1 root root 2324 2006-11-14 19:33 libnvidia-tls.so.1.0.9742 -rwxr-xr-x 1 root root 3220 2006-11-14 19:33 tls_test -rw-r--r-- 1 root root 3384 2006-11-14 19:33 tls_test_dso.so Note the links of libGL.so.*.xlibmesa. It didnt seem correct when I first glanced at it. Actually, this is what it looks like when I try to reinstall libgl1-mesa-glx (the nvidia-glx diversions cause this package to create a broken link in /usr/lib/nvidia). -rw-r--r-- 1 root root 425320 2006-10-13 03:55 libGL.so.1.2.xlibmesa lrwxrwxrwx 1 root root 12 2006-11-14 20:06 libGL.so.1.xlibmesa - libGL.so.1.2 -rw-r--r-- 1 root root 493686 2006-10-16 19:23 libglx.so.xlibmesa Best Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396384: [Patch] rules in debian.binary do not apply patches
Package: nvidia-kernel-source Version: 1.0.9625-2 Severity: important The paths are incorrect in the build rules when trying to apply the debian patches to the source code before building the nvidia-kernel module with make-kpkg. Also, the patches are not reversing properly when the rules cleans up. The attached patch fixes both problems. Best Regards. --- nvidia/debian.binary/rules.orig 2006-10-22 03:29:34.0 -0700 +++ nvidia/debian.binary/rules 2006-10-31 04:25:59.0 -0800 @@ -103,13 +103,13 @@ cd .. ; \ fi - if test -d $(CURDIR)/patches; \ + if test -d $(CURDIR)/debian/patches; \ then \ pwd; \ ls -al; \ -cd $(dirname)/usr/src/nv; \ -for i in $(CURDIR)/patches/*; \ - do patch -p3 $$i; \ +cd $(dirname); \ +for i in $(CURDIR)/debian/patches/*; \ + do patch -p3 -t $$i; \ done; \ fi
Bug#391795: nvidia-glx package conflicts with xorg 7.1
Package: nvidia-glx Version: 1.0.8774-3 Severity: important nvidia-glx package conflicts with xorg 7.1 because xorg now provides the virtual xserver-xorg-video package. A solution would be to remove xserver-xorg-video provides from the nvidia-glx package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391795: nvidia-glx package conflicts with xorg 7.1
Randall Donald wrote: On Sun, 2006-10-08 at 08:14 -0700, C.Y.M wrote: Package: nvidia-glx Version: 1.0.8774-3 Severity: important nvidia-glx package conflicts with xorg 7.1 because xorg now provides the virtual xserver-xorg-video package. A solution would be to remove xserver-xorg-video provides from the nvidia-glx package. Are you saying that they have gone back from xserver-xorg-video-1.0 to xserver-xorg-video again? Yes, the xserver-xorg-core package now also provides the virtual xserver-xorg-video package and its conflicting with nvidia-glx. Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391795: nvidia-glx package conflicts with xorg 7.1
Randall Donald wrote:
On Sun, 2006-10-08 at 12:02 -0700, C.Y.M wrote:
Randall Donald wrote:
On Sun, 2006-10-08 at 08:14 -0700, C.Y.M wrote:
Package: nvidia-glx
Version: 1.0.8774-3
Severity: important
nvidia-glx package conflicts with xorg 7.1 because xorg now provides the
virtual
xserver-xorg-video package. A solution would be to remove
xserver-xorg-video
provides from the nvidia-glx package.
Yes, the xserver-xorg-core package now also provides the virtual
xserver-xorg-video package and its conflicting with nvidia-glx.
What versions are you using?
From dpkg -s xserver-xorg-core
Version: 2:1.1.1-9
Replaces: xserver-xorg ( 6.8.2-38), xserver-xfree86 ( 1:7.0.0)
Provides: xserver
Depends: x11-common (= 1:7.0.0), libc6 (= 2.3.5-1), libfontenc1,
libxau6, libxdmcp6, libxfont1, zlib1g (= 1:1.2.1)
Recommends: xkb-data
Conflicts: xserver-xorg ( 6.8.2-38), xserver-xfree86 ( 1:7.0.0),
xserver-xorg-video
From dpkg -s nvidia-glx
Version: 1.0.8774-3
Provides: xserver-xorg-video-1.0
I don't see the conflict.
When I look at the control file for nvidia-glx 1.0.8774-3 , I see the following:
Package: nvidia-glx
Architecture: i386 amd64
Depends: nvidia-kernel-1.0.8762, x11-common (= 1:7.0.0), ${shlibs:Depends}
Suggests: nvidia-settings, nvidia-kernel-source (= 1.0.8762)
Conflicts: nvidia-glx-src
Provides: xserver-xorg-video
Replaces: nvidia-glx-src
Description: NVIDIA binary XFree86 4.x driver
I'm not sure where you are getting the xserver-xorg-video-1.0 from (because
the control file for nvidia-glx says xserver-xorg-video). But I do see the
problem now.. Its not that xserver-xorg-core is providing xserver-xorg-video,
it is because xserver-xorg-core conflicts with the virtual xserver-xorg-video
package provided by nvidia-glx.
BR.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391795: nvidia-glx package conflicts with xorg 7.1
When I look at the control file for nvidia-glx 1.0.8774-3 , I see the
following:
Package: nvidia-glx
Architecture: i386 amd64
Depends: nvidia-kernel-1.0.8762, x11-common (= 1:7.0.0), ${shlibs:Depends}
Suggests: nvidia-settings, nvidia-kernel-source (= 1.0.8762)
Conflicts: nvidia-glx-src
Provides: xserver-xorg-video
Replaces: nvidia-glx-src
Description: NVIDIA binary XFree86 4.x driver
I'm not sure where you are getting the xserver-xorg-video-1.0 from (because
the control file for nvidia-glx says xserver-xorg-video). But I do see the
problem now.. Its not that xserver-xorg-core is providing
xserver-xorg-video,
it is because xserver-xorg-core conflicts with the virtual xserver-xorg-video
package provided by nvidia-glx.
I just re-downloaded the source code to be sure and discovered that the problem
is that the control.in file is correct, but the control file is not. This
patch fixes the conflict with xorg 7.1:
--- nvidia-graphics-drivers-1.0.8774.orig/debian/control2006-10-09
06:31:35.0 -0700
+++ nvidia-graphics-drivers-1.0.8774/debian/control 2006-10-09
06:32:54.0 -0700
@@ -34,7 +34,7 @@
Depends: nvidia-kernel-1.0.8762, x11-common (= 1:7.0.0), ${shlibs:Depends}
Suggests: nvidia-settings, nvidia-kernel-source (= 1.0.8762)
Conflicts: nvidia-glx-src
-Provides: xserver-xorg-video
+Provides: xserver-xorg-video-1.0
Replaces: nvidia-glx-src
Description: NVIDIA binary XFree86 4.x driver
These XFree86 4.0 / Xorg binary drivers provide optimized hardware
Best Regards.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327570: Acknowledgement (missing /usr/bin/tput when rebooting)
This bug seems to have resurfaced with 2.86.ds1-33. Is this still a lsb-base issue? Any idea how to fix it again? Best Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327570: Acknowledgement (missing /usr/bin/tput when rebooting)
C.Y.M wrote: This bug seems to have resurfaced with 2.86.ds1-33. Is this still a lsb-base issue? Any idea how to fix it again? As a workaround to this bug, I have rebuilt the ncurses-bin package to place tput in /bin/tput instead of /usr/bin/tput. Unless there is a better suggestion? Best Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388386: [patch]
C.Y.M wrote:
This is a quick hack that solves the build problem with kernel 2.6.18. This
is
not a backwards compatible patch.
Apparently, The 2.6.18 stats callback parameters have changed from 2.6.17 so
that it takes a struct dentry* rather than a struct super_block.
Revised patch applied for 2.6.18.
Best Regards.
--- lufs/kernel/Linux/2.6/inode.c 2006-10-05 04:10:30.0 -0700
+++ lufs.new/kernel/Linux/2.6/inode.c 2006-10-05 04:07:27.0 -0700
@@ -53,7 +53,7 @@
static void lu_delete_inode(struct inode*);
static void lu_put_super(struct super_block*);
-static int lu_statfs(struct super_block*, struct statfs*);
+static int lu_statfs(struct dentry*, struct statfs*);
static struct super_operations lu_sops = {
.drop_inode = generic_drop_inode,
@@ -383,7 +383,7 @@
return res;
}
-static int lu_statfs(struct super_block *sb, struct statfs *attr)
+static int lu_statfs(struct dentry * dentry, struct statfs *attr)
{
TRACE(in\n);
@@ -510,9 +510,9 @@
return -EINVAL;
}
-static struct super_block *lu_get_sb(struct file_system_type *fs_type, int flags, char *dev_name, void *data)
+static int lu_get_sb(struct file_system_type *fs_type, int flags, char *dev_name, void *data, struct vfsmount *mnt)
{
-return get_sb_nodev(fs_type, flags, data, lu_fill_super);
+return get_sb_nodev(fs_type, flags, data, lu_fill_super, mnt);
}
static struct file_system_type lu_fs_type = {
Bug#388386: [patch]
Eduard Bloch wrote: #include hallo.h * C.Y.M [Wed, Sep 20 2006, 07:33:55PM]: This is a quick hack that solves the build problem with kernel 2.6.18. This is not a backwards compatible patch. Stupid question: why do you need LUFS? I consider requesting its removal because almost everything has moved to FUSE or can be used with lufis, the fuse/lufs bridge. I wanted a way to mount ftp sites with autofs (which has scripts utilizing lufs). BR. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388386: build failure with 2.6.18 kernel release
Package: lufs-source Version: 0.9.7-8 Severity: important Build fails with kernel-2.6.18. /usr/src/modules/lufs/kernel/Linux/2.6/inode.c:62: warning: initialization from incompatible pointer type /usr/src/modules/lufs/kernel/Linux/2.6/inode.c:414:5: warning: KERNEL_VERSION_CODE is not defined /usr/src/modules/lufs/kernel/Linux/2.6/inode.c: In function `lu_get_sb': /usr/src/modules/lufs/kernel/Linux/2.6/inode.c:515: error: too few arguments to function `get_sb_nodev' /usr/src/modules/lufs/kernel/Linux/2.6/inode.c:515: warning: return makes pointer from integer without a cast /usr/src/modules/lufs/kernel/Linux/2.6/inode.c: At top level: /usr/src/modules/lufs/kernel/Linux/2.6/inode.c:521: warning: initialization from incompatible pointer type make[5]: *** [/usr/src/modules/lufs/kernel/Linux/2.6/inode.o] Error 1 make[4]: *** [_module_/usr/src/modules/lufs/kernel/Linux/2.6] Error 2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388389: cdfs files to build with 2.6.18 kernel release
Package: cdfs-src Version: 2.4.20.a+2.6.12-2 Severity: important Build fails with 2.6.18 kernel release. /usr/src/modules/cdfs/2.6/root.c:541: warning: initialization from incompatible pointer type /usr/src/modules/cdfs/2.6/root.c: In function `cdfs_get_sb': /usr/src/modules/cdfs/2.6/root.c:547: error: too few arguments to function `get_sb_bdev' /usr/src/modules/cdfs/2.6/root.c:547: warning: return makes pointer from integer without a cast /usr/src/modules/cdfs/2.6/root.c: At top level: /usr/src/modules/cdfs/2.6/root.c:553: warning: initialization from incompatible pointer type -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388388: cdfs files to build with 2.6.18 kernel release
Package: cdrs-src Version: 2.4.20.a+2.6.12-2 Severity: important Build fails with 2.6.18 kernel release. /usr/src/modules/cdfs/2.6/root.c:541: warning: initialization from incompatible pointer type /usr/src/modules/cdfs/2.6/root.c: In function `cdfs_get_sb': /usr/src/modules/cdfs/2.6/root.c:547: error: too few arguments to function `get_sb_bdev' /usr/src/modules/cdfs/2.6/root.c:547: warning: return makes pointer from integer without a cast /usr/src/modules/cdfs/2.6/root.c: At top level: /usr/src/modules/cdfs/2.6/root.c:553: warning: initialization from incompatible pointer type -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388389: [PATCH]
This is a patch that fixes the build problem with kernel 2.6.18. This is not a
backwards compatible patch.
Best Regards.
--- cdfs/2.6/root.c.orig 2006-09-20 18:15:33.0 -0700
+++ cdfs/2.6/root.c 2006-09-20 18:29:39.0 -0700
@@ -543,8 +543,8 @@
#ifdef OLD_KERNEL
static DECLARE_FSTYPE_DEV(cdfs_fs_type, FSNAME, cdfs_mount);
#else
-static struct super_block *cdfs_get_sb(struct file_system_type *fs_type, int flags, const char *dev_name, void *data) {
- return get_sb_bdev(fs_type, flags, dev_name, data, cdfs_fill_super);
+static struct super_block *cdfs_get_sb(struct file_system_type *fs_type, int flags, const char *dev_name, void *data, struct vfsmount *mnt) {
+ return get_sb_bdev(fs_type, flags, dev_name, data, cdfs_fill_super, mnt);
}
static struct file_system_type cdfs_fs_type = {
Bug#388386: [patch]
This is a quick hack that solves the build problem with kernel 2.6.18. This is
not a backwards compatible patch.
Thanks.
--- lufs/kernel/Linux/2.6/inode.c.orig 2006-09-20 18:31:59.0 -0700
+++ lufs/kernel/Linux/2.6/inode.c 2006-09-20 18:33:02.0 -0700
@@ -510,9 +510,9 @@
return -EINVAL;
}
-static struct super_block *lu_get_sb(struct file_system_type *fs_type, int flags, char *dev_name, void *data)
+static struct super_block *lu_get_sb(struct file_system_type *fs_type, int flags, char *dev_name, void *data, struct vfsmount *mnt)
{
-return get_sb_nodev(fs_type, flags, data, lu_fill_super);
+return get_sb_nodev(fs_type, flags, data, lu_fill_super, mnt);
}
static struct file_system_type lu_fs_type = {
Bug#294810: Apache will not start unless Apache-ssl is started first
Package: apache Version: 1.3.33-4 Description: My system has both apache and apache-ssl installed. I am unable to start and stop apache after upgrading from the previous version. When attempting to stop apache, a single thread still remains running and I have to manually kill it and the pid file in /var/run is not removed. But, if I start apache-ssl first, then I am able to start apache. There are no errors in the error.log. ii apache 1.3.33-4 versatile, high-performance HTTP server ii apache-common 1.3.33-4 support files for all Apache webservers ii apache-ssl 1.3.33-4 versatile, high-performance HTTP server with ii apache-utils 1.3.33-4 utility programs for webservers (transitiona ii apache2-utils 2.0.53-3 utility programs for webservers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294810: Acknowledgement (Apache will not start unless Apache-ssl is started first)
Some more information... I tried apt-get source apache and built the packages with fakeroot dpkg-buildpackge. Everything built fine. But, the same thing is happening. I tried to change the startup order so apache would start after apache-ssl on boot , but that did not help either. Oddly, once the computer restarts, I *can* log into the console and manually start the apache service (which works). Although, if I try to stop and start the apache service again once I manually start it, it does not start again. I must have a ghost in the machine because I just dont understand why it would start once manually and not start automatically at bootup. It seems to start on boot and there are no error messages, but the processes just dont exist. What could be wrong? Best Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294889: kernel-package locks up when building
Package: kernel-package Version: 8.120 Severity: critical Description: When attempting to build a new 2.6 kernel snapshot with this latest version of kernel-package, the build script just locks up. Test: Build kernel 2.6.11-rc3-bk8 with the following command: fakeroot make-kpkg --append-to-version=.021105.1 --added-modules=nvidia-kernel kernel-image modules-image -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294889: kernel-package locks up when building
Manoj Srivastava wrote: Hi, Can't reproduce this. Do you have any additional details? Like a log of where the lock up happened? manoj OK, it doesnt appear to be actually locking up now, sorry for the poor description. The first time I tried it, it just sat there for a few minutes and did nothing so I stopped it. Now I am getting the following error (note that If I reinstall the previous version of kernel-package that this error does not occur): /usr/bin/make -f /usr/share/kernel-package/rules real_stamp_clean make[1]: Entering directory `/usr/src/linux-2.6.11-rc3-bk8' test ! -f .config || cp -pf .config config.precious test -f Makefile \ /usr/bin/make ARCH=i386 distclean make[2]: Entering directory `/usr/src/linux-2.6.11-rc3-bk8' CLEAN .config make[2]: Leaving directory `/usr/src/linux-2.6.11-rc3-bk8' test ! -f config.precious || mv -f config.precious .config test ! -f stamp-patch || /usr/bin/make -f /usr/share/kernel-package/rules unpatch_now test -f stamp-building || test -f debian/official || rm -rf debian # work around idiocy in recent kernel versions test ! -e scripts/package/builddeb.dist || \ mv -f scripts/package/builddeb.dist scripts/package/builddeb test ! -e scripts/package/Makefile.dist || \ mv -f scripts/package/Makefile.dist scripts/package/Makefile rm -f modules/modversions.h modules/ksyms.ver debian/files conf.vars scripts/cramfs/cramfsck scripts/cramfs/mkcramfs applied_patches debian/buildinfo stamp-build stamp-configure stamp-source stamp-image stamp-headers stamp-src stamp-diff stamp-doc stamp-buildpackage stamp-libc-kheaders stamp-debian stamp-patch stamp-kernel-configure rm -rf debian/tmp-source debian/tmp-headers debian/tmp-image debian/tmp-doc make[1]: Leaving directory `/usr/src/linux-2.6.11-rc3-bk8' # work around idiocy in recent kernel versions test ! -e scripts/package/builddeb || \ mv -f scripts/package/builddeb scripts/package/builddeb.dist test ! -e scripts/package/Makefile || \ (mv -f scripts/package/Makefile scripts/package/Makefile.dist \ echo # Dummy filescripts/package/Makefile) test ! -f stamp-debian test ! -f debian/official \ rm -rf ./debian mkdir ./debian test ! -f stamp-debian \ ( test ! -f debian/official || test ! -f debian/control) \ sed -e 's/=V/2.6.11-rc3-bk8.021105.2/g'-e 's/=D/10.00.Custom/g' \ -e 's/=A/i386/g' -e 's/=SA//g' \ -e 's/=L/lilo (= 19.1) | grub, /g' -e 's/=I//g'\ -e 's/=CV/2.6/g' \ -e 's/=M/Unknown Kernel Package Maintainer [EMAIL PROTECTED]/g' \ -e 's/=ST/kernel/g' \ /usr/share/kernel-package/Control debian/control test ! -f stamp-debian test ! -f debian/official \ sed -e 's/=V/2.6.11-rc3-bk8.021105.2/g' -e 's/=D/10.00.Custom/g' \ -e 's/=A/i386/g' -e 's/=M/Unknown Kernel Package Maintainer [EMAIL PROTECTED]/g' \ -e 's/=ST/kernel/g' \ /usr/share/kernel-package/changelog debian/changelog test ! -f debian/rules\ install -p -m 755 /usr/share/kernel-package/rules debian/rules echo done stamp-debian make: *** No rule to make target `conf.vars', needed by `stamp-configure'. Stop. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295541: Autofs assumes all smb mounts do not require a user or password
Package: autofs
Version: 4.1.3+4.1.4beta2-1
Severity: important
Description: The new auto.smb script assumes that all smb mounts do not require
a user or password from the following code (-N switch). Is there an easy way of
changing it to something like this? I could not get this to work. Thanks.
if [ $key = some_netbios_name ]; then
$SMBCLIENT -g -U user%pass -L $key 2/dev/null| awk -v key=$key -v
opts=$opts -F'|' -- '
...
...
fi
--SNIP--
$SMBCLIENT -gNL $key 2/dev/null| awk -v key=$key -v opts=$opts -F'|' -- '
BEGIN { ORS=; first=1 }
/Disk/ { if (first) { print opts; first=0 }; print \\\n\t / $2,
:// key / $2 }
END { if (!first) print \n; else exit 1 }
'
--SNIP--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295727: sys-syslog no longer works as expected
Package: razor Version: 2.670-1 Severity: Important Description: Changing the logfile option in razor-agent.conf to sys-syslog no longer works as expected. logfile = sys-syslog Instead of the logs being written to the syslog (like they should be), they are written to Razor's user homedir and called sys-syslog. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295992: perl: (pam_unix) authentication failure
Package: libauthen-pam-perl Version: 0.14-1 Severity: Important Description: After installing libauthen-pam-perl, my system shows an authentication error every time the system is rebooted. Here is one of the failed error message lines from /var/log/auth.log when the system is booted. perl: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=root -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296010: webmin causing authentication errors (pam_unix) on startup
Package: webmin Version: 1.180-1 Severity: Important Description: After installing webmin, my system shows an authentication error every time webmin is restarted. Below is one of the failed error message lines from /var/log/auth.log when webmin is restarted. The webmin application seems to function properly, but it appears that the pam.d configuration is incorrect. My system is using shadowed passwords if that makes any difference. Thanks. --SNIP-- perl: (pam_unix) authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=root -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296481: Rule file cannot be found when viewing
Package: webmin-snort Version: 1.1-2 Severity: Important Description: When clicking on a link to view a rule, the following error is displayed. When selecting the disable/enable button, the interface works fine. It is only a problem with viewing the rule, therefore, $RULE_PATH is obviously set properly if the enable and disable part functions. --SNIP-- Rule file cannot be found (/etc/snort/$RULE_PATH/backdoor.rules) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298612: agp bridge data dpatch for 2.6.11-bk3+
Package: nvidia-kernel-source
Version: 1.0.6629+1-2
Severity: Important
Description: Patch for changes to agp_backend_acquire and agp_backend_release in
2.6.11-bk3+.
Best Regards,
#!/bin/sh -e
# Patch from accumulated from http://www.minion.de/files/1.0-6629/
if [ $# -lt 1 ]; then
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
fi
patch_opts=-f -N --no-backup-if-mismatch -p2
echo $1
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@
--- nvidia-kernel/nv/nv.c.orig 2005-03-08 11:33:00.0 -0800
+++ nvidia-kernel/nv/nv.c 2005-03-08 11:40:31.0 -0800
@@ -3011,7 +3011,6 @@
return status;
}
#elif defined(AGPGART)
-int error;
/*
* We can only safely use NvAGP when no backend has been
* registered with the AGPGART frontend. This condition
@@ -3020,9 +3019,11 @@
* Other return codes indicate that a backend is present
* and was either acquired, busy or else unavailable.
*/
-if ((error = agp_backend_acquire()) != -EINVAL)
+ nv_linux_state_t *nvl = NV_GET_NVL_FROM_NV_STATE(nv);
+ nvl-agp_bridge = agp_backend_acquire(nvl-dev);
+if (nvl-agp_bridge)
{
-if (!error) agp_backend_release();
+agp_backend_release(nvl-agp_bridge);
nv_printf(NV_DBG_WARNINGS,
NVRM: not using NVAGP, an AGPGART backend is
loaded!\n);
return status;
--- nvidia-kernel/nv/nv-linux.h.orig2005-03-08 11:37:41.0 -0800
+++ nvidia-kernel/nv/nv-linux.h 2005-03-08 11:40:31.0 -0800
@@ -930,6 +930,9 @@
/* lock for linux-specific alloc queue */
struct semaphore at_lock;
+
+ /* AGP bridge handle */
+ struct agp_bridge_data *agp_bridge;
} nv_linux_state_t;
--- nvidia-kernel/nv/os-agp.c.orig 2005-03-08 11:38:09.0 -0800
+++ nvidia-kernel/nv/os-agp.c 2005-03-08 11:40:31.0 -0800
@@ -60,23 +60,23 @@
#endif
#if defined(KERNEL_2_6)
-#define NV_AGPGART_BACKEND_ACQUIRE(o) agp_backend_acquire()
-#define NV_AGPGART_BACKEND_ENABLE(o,mode) agp_enable(mode)
-#define NV_AGPGART_BACKEND_RELEASE(o) agp_backend_release()
-#define NV_AGPGART_COPY_INFO(o,p) agp_copy_info(p)
-#define NV_AGPGART_ALLOCATE_MEMORY(o,count,type)
agp_allocate_memory(count,type)
-#define NV_AGPGART_FREE_MEMORY(o,p) agp_free_memory(p)
-#define NV_AGPGART_BIND_MEMORY(o,p,offset) agp_bind_memory(p,offset)
-#define NV_AGPGART_UNBIND_MEMORY(o,p) agp_unbind_memory(p)
+#define NV_AGPGART_BACKEND_ACQUIRE(nvl,o) ({ nvl-agp_bridge =
agp_backend_acquire(nvl-dev); !nvl-agp_bridge; })
+#define NV_AGPGART_BACKEND_ENABLE(nvl,o,mode) agp_enable(nvl-agp_bridge,mode)
+#define NV_AGPGART_BACKEND_RELEASE(nvl,o) agp_backend_release(nvl-agp_bridge)
+#define NV_AGPGART_COPY_INFO(nvl,o,p) agp_copy_info(nvl-agp_bridge,p)
+#define NV_AGPGART_ALLOCATE_MEMORY(nvl,o,count,type)
agp_allocate_memory(nvl-agp_bridge,count,type)
+#define NV_AGPGART_FREE_MEMORY(nvl,o,p) agp_free_memory(p)
+#define NV_AGPGART_BIND_MEMORY(nvl,o,p,offset) agp_bind_memory(p,offset)
+#define NV_AGPGART_UNBIND_MEMORY(nvl,o,p) agp_unbind_memory(p)
#elif defined(KERNEL_2_4)
-#define NV_AGPGART_BACKEND_ACQUIRE(o) ({ (o)-acquire(); 0; })
-#define NV_AGPGART_BACKEND_ENABLE(o,mode) (o)-enable(mode)
-#define NV_AGPGART_BACKEND_RELEASE(o) ((o)-release())
-#define NV_AGPGART_COPY_INFO(o,p) ({ (o)-copy_info(p); 0; })
-#define NV_AGPGART_ALLOCATE_MEMORY(o,count,type)
(o)-allocate_memory(count,type)
-#define NV_AGPGART_FREE_MEMORY(o,p) (o)-free_memory(p)
-#define NV_AGPGART_BIND_MEMORY(o,p,offset) (o)-bind_memory(p,offset)
-#define NV_AGPGART_UNBIND_MEMORY(o,p) (o)-unbind_memory(p)
+#define NV_AGPGART_BACKEND_ACQUIRE(nvl,o) ({ (o)-acquire(); 0; })
+#define NV_AGPGART_BACKEND_ENABLE(nvl,o,mode) (o)-enable(mode)
+#define NV_AGPGART_BACKEND_RELEASE(nvl,o) ((o)-release())
+#define NV_AGPGART_COPY_INFO(nvl,o,p) ({ (o)-copy_info(p); 0; })
+#define NV_AGPGART_ALLOCATE_MEMORY(nvl,o,count,type)
(o)-allocate_memory(count,type)
+#define NV_AGPGART_FREE_MEMORY(nvl,o,p) (o)-free_memory(p)
+#define NV_AGPGART_BIND_MEMORY(nvl,o,p,offset) (o)-bind_memory(p,offset)
+#define NV_AGPGART_UNBIND_MEMORY(nvl,o,p) (o)-unbind_memory(p)
#endif
#endif /* AGPGART */
@@ -96,6 +96,7 @@
U032 agp_fw;
void *bitmap;
U032 bitmap_size;
+ nv_linux_state_t *nvl = NV_GET_NVL_FROM_NV_STATE(nv);
memset( (void *) gart, 0, sizeof(agp_gart));
@@ -110,7 +111,7 @@
* the memory controller.
*/
-if (NV_AGPGART_BACKEND_ACQUIRE(drm_agp_p))
+if (NV_AGPGART_BACKEND_ACQUIRE(nvl,drm_agp_p))
{
nv_printf(NV_DBG_INFO, NVRM: AGPGART: no backend available\n);
goto bailout;
@@ -128,7 +129,7 @@
agp_fw = 1;
Bug#298612: Acknowledgement (agp bridge data dpatch for 2.6.11-bk3+)
Here is a better patch that includes the new dpatch (with some extra tabs
removed from the previous post), and the necessary changes to the debian/rules
and 00list files. It should apply cleanly to the current nvidia-kernel-sources
package.
Best Regards,
diff -ruN nvidia-kernel-orig/debian/patches/00list
nvidia-kernel/debian/patches/00list
--- nvidia-kernel-orig/debian/patches/00list2005-02-18 15:16:05.0
-0800
+++ nvidia-kernel/debian/patches/00list 2005-03-08 11:53:11.0 -0800
@@ -2,3 +2,4 @@
02_pcialias
03_pci_get_class
04_minion
+05_agp_bridge_data
diff -ruN nvidia-kernel-orig/debian/patches/05_agp_bridge_data
nvidia-kernel/debian/patches/05_agp_bridge_data
--- nvidia-kernel-orig/debian/patches/05_agp_bridge_data1969-12-31
16:00:00.0 -0800
+++ nvidia-kernel/debian/patches/05_agp_bridge_data 2005-03-08
11:52:27.0 -0800
@@ -0,0 +1,230 @@
+#!/bin/sh -e
+
+# Patch from accumulated from http://www.minion.de/files/1.0-6629/
+
+if [ $# -lt 1 ]; then
+echo 2 `basename $0`: script expects -patch|-unpatch as argument
+exit 1
+fi
+
+patch_opts=-f -N --no-backup-if-mismatch -p2
+
+echo $1
+
+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
+
[EMAIL PROTECTED]@
+
+--- nvidia-kernel/nv/nv.c.orig 2005-03-08 11:33:00.0 -0800
nvidia-kernel/nv/nv.c 2005-03-08 11:40:31.0 -0800
+@@ -3011,7 +3011,6 @@
+ return status;
+ }
+ #elif defined(AGPGART)
+-int error;
+ /*
+ * We can only safely use NvAGP when no backend has been
+ * registered with the AGPGART frontend. This condition
+@@ -3020,9 +3019,11 @@
+ * Other return codes indicate that a backend is present
+ * and was either acquired, busy or else unavailable.
+ */
+-if ((error = agp_backend_acquire()) != -EINVAL)
++nv_linux_state_t *nvl = NV_GET_NVL_FROM_NV_STATE(nv);
++nvl-agp_bridge = agp_backend_acquire(nvl-dev);
++if (nvl-agp_bridge)
+ {
+-if (!error) agp_backend_release();
++agp_backend_release(nvl-agp_bridge);
+ nv_printf(NV_DBG_WARNINGS,
+ NVRM: not using NVAGP, an AGPGART backend is
loaded!\n);
+ return status;
+--- nvidia-kernel/nv/nv-linux.h.orig 2005-03-08 11:37:41.0 -0800
nvidia-kernel/nv/nv-linux.h2005-03-08 11:40:31.0 -0800
+@@ -930,6 +930,9 @@
+
+ /* lock for linux-specific alloc queue */
+ struct semaphore at_lock;
++
++/* AGP bridge handle */
++struct agp_bridge_data *agp_bridge;
+ } nv_linux_state_t;
+
+
+--- nvidia-kernel/nv/os-agp.c.orig 2005-03-08 11:38:09.0 -0800
nvidia-kernel/nv/os-agp.c 2005-03-08 11:40:31.0 -0800
+@@ -60,23 +60,23 @@
+ #endif
+
+ #if defined(KERNEL_2_6)
+-#define NV_AGPGART_BACKEND_ACQUIRE(o) agp_backend_acquire()
+-#define NV_AGPGART_BACKEND_ENABLE(o,mode) agp_enable(mode)
+-#define NV_AGPGART_BACKEND_RELEASE(o) agp_backend_release()
+-#define NV_AGPGART_COPY_INFO(o,p) agp_copy_info(p)
+-#define NV_AGPGART_ALLOCATE_MEMORY(o,count,type)
agp_allocate_memory(count,type)
+-#define NV_AGPGART_FREE_MEMORY(o,p) agp_free_memory(p)
+-#define NV_AGPGART_BIND_MEMORY(o,p,offset) agp_bind_memory(p,offset)
+-#define NV_AGPGART_UNBIND_MEMORY(o,p) agp_unbind_memory(p)
++#define NV_AGPGART_BACKEND_ACQUIRE(nvl,o) ({ nvl-agp_bridge =
agp_backend_acquire(nvl-dev); !nvl-agp_bridge; })
++#define NV_AGPGART_BACKEND_ENABLE(nvl,o,mode) agp_enable(nvl-agp_bridge,mode)
++#define NV_AGPGART_BACKEND_RELEASE(nvl,o) agp_backend_release(nvl-agp_bridge)
++#define NV_AGPGART_COPY_INFO(nvl,o,p) agp_copy_info(nvl-agp_bridge,p)
++#define NV_AGPGART_ALLOCATE_MEMORY(nvl,o,count,type)
agp_allocate_memory(nvl-agp_bridge,count,type)
++#define NV_AGPGART_FREE_MEMORY(nvl,o,p) agp_free_memory(p)
++#define NV_AGPGART_BIND_MEMORY(nvl,o,p,offset) agp_bind_memory(p,offset)
++#define NV_AGPGART_UNBIND_MEMORY(nvl,o,p) agp_unbind_memory(p)
+ #elif defined(KERNEL_2_4)
+-#define NV_AGPGART_BACKEND_ACQUIRE(o) ({ (o)-acquire(); 0; })
+-#define NV_AGPGART_BACKEND_ENABLE(o,mode) (o)-enable(mode)
+-#define NV_AGPGART_BACKEND_RELEASE(o) ((o)-release())
+-#define NV_AGPGART_COPY_INFO(o,p) ({ (o)-copy_info(p); 0; })
+-#define NV_AGPGART_ALLOCATE_MEMORY(o,count,type)
(o)-allocate_memory(count,type)
+-#define NV_AGPGART_FREE_MEMORY(o,p) (o)-free_memory(p)
+-#define NV_AGPGART_BIND_MEMORY(o,p,offset) (o)-bind_memory(p,offset)
+-#define NV_AGPGART_UNBIND_MEMORY(o,p) (o)-unbind_memory(p)
++#define NV_AGPGART_BACKEND_ACQUIRE(nvl,o) ({ (o)-acquire(); 0; })
++#define NV_AGPGART_BACKEND_ENABLE(nvl,o,mode) (o)-enable(mode)
++#define NV_AGPGART_BACKEND_RELEASE(nvl,o) ((o)-release())
++#define NV_AGPGART_COPY_INFO(nvl,o,p) ({ (o)-copy_info(p);
Bug#287160: Still can't reproduce the mod_auth_mysql bug
Matthew Palmer wrote:
I didn't do that in my previous test, but I just have and it doesn't appear
to have made any difference -- no matter what combination I try, I can't
make the server give me a 500.
What a pest. I like easily reproducible bug reports...
Hello Matt,
I have upgraded to Apache2 and compiled the latest version of
libapache2-mod-auth-mysql (4.3.9-2) to try and get rid of this pesky problem but
I get the same exact results as I did before with Apache13. Something is wrong
with the require group directive (require user works fine). I am using sha1
encrypted passwords, but I have tested using MySQL and MD5 forms of
encryption with no variance in results. If I could just find out why your
configuration does not generate this bug.. Every time I try to browse to a
directory that belongs to a different group, Apache gives me the 500 error with
a configuration error in the log. The problem seems to be that
libapache2-mod-auth-mysql is trying to perform a select statement on a user
with an unassigned group which returns the apache configuration error and 500
(usernick only belongs to the web group, not the adm group in this
example). If there is *anything* else I can do to provide info, please let me know.
Best Regards,
[Fri Mar 11 04:15:14 2005] [debug] mod_auth_mysql.c(1482): Handling an
authentication request for section /var/www/
[Fri Mar 11 04:15:14 2005] [debug] mod_auth_mysql.c(1523): Starting basic user
auth for [usernick] in /var/www/, child pid 2780
[Fri Mar 11 04:15:14 2005] [debug] mod_auth_mysql.c(1338): Constructing password
collection query with passfield=[passwd], table=[mysql_auth],
userfield=[usernick], where_clause=[]
[Fri Mar 11 04:15:14 2005] [debug] mod_auth_mysql.c(1192): sec-dbh in /var/www/ is
[Fri Mar 11 04:15:14 2005] [debug] mod_auth_mysql.c(1199): Ordinary query
[Fri Mar 11 04:15:14 2005] [debug] mod_auth_mysql.c(1216): Running query:
[SELECT passwd FROM mysql_auth WHERE username='usernick']
[Fri Mar 11 04:15:14 2005] [debug] mod_auth_mysql.c(1298): Checking with SHA1Sum
[Fri Mar 11 04:15:14 2005] [debug] mod_auth_mysql.c(1300): Auth succeeded
[Fri Mar 11 04:15:14 2005] [debug] mod_auth_mysql.c(1442): Making group query
with auth_table=[mysql_auth], auth_user_field=[username], esc_user=[usernick],
esc_group=[adm], auth_group_field=[groups], where_clause=[]
[Fri Mar 11 04:15:14 2005] [debug] mod_auth_mysql.c(1449): Group query created;
[SELECT count(*) FROM mysql_auth WHERE username='usernick' and
FIND_IN_SET('adm',groups)]
[Fri Mar 11 04:15:14 2005] [debug] mod_auth_mysql.c(1192): sec-dbh in /var/www/ is
[Fri Mar 11 04:15:14 2005] [debug] mod_auth_mysql.c(1199): Ordinary query
[Fri Mar 11 04:15:14 2005] [debug] mod_auth_mysql.c(1216): Running query:
[SELECT count(*) FROM mysql_auth WHERE username='usernick' and
FIND_IN_SET('adm',groups)]
[Fri Mar 11 04:15:14 2005] [crit] [client 10.1.1.66] configuration error:
couldn't check access. No groups file?: /adm/, referer: https://my.server.net/
[Fri Mar 11 04:15:14 2005] [info] Connection to child 4 closed with unclean
shutdown(server my.server.net:443, client 10.1.1.66)
[Fri Mar 11 04:15:16 2005] [info] Connection to child 1 established (server
my.server.net:443, client 10.1.1.66)
[Fri Mar 11 04:15:16 2005] [info] Seeding PRNG with 272 bytes of entropy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#287160: Info received (was Bug#287160: Still can't reproduce the mod_auth_mysql bug)
I have gone back to version 4.3.8-1 (which is the version that works for me) and
have started back porting the changes from 4.3.9-2 until it breaks. The problem
seems to be with the new check_mysql_auth_require and this function:
if ((rv = check_mysql_auth_require(user, t, r))
!= HTTP_UNAUTHORIZED)
{
return rv;
}
If I apply the included patch to 4.3.8-1, everything seems to work fine. All
the changes after this are what breaks the require group function. I hope
that helps a little. This patch should apply cleanly to 4.3.8-1 and includes
all the changes added by 4.3.9-2 (except the check_mysql_auth_require change).
Best Regards,
--- libapache-mod-auth-mysql-4.3.8-orig/mod_auth_mysql.c2005-03-11
06:14:49.0 -0800
+++ libapache-mod-auth-mysql-4.3.8/mod_auth_mysql.c 2005-03-11
06:09:53.0 -0800
@@ -21,7 +21,7 @@
* SHA1 hash support
*/
-#define AUTH_MYSQL_VERSION 4.3.8-1
+#define AUTH_MYSQL_VERSION 4.3.9-2
#include config.h
@@ -149,23 +149,21 @@
static char *md5_hex_hash(const char *pass)
{
-#ifdef APACHE2
- apr_md5_ctx_t ct;
-#else
- AP_MD5_CTX ct;
-#endif
unsigned char hash[16];
/* This makes this function *very* specialised. Change this to
* use dynamic memory if you want to reuse it somewhere else */
static char real_hash[33];
int i;
#ifdef APACHE2
+ apr_md5_ctx_t ct;
+
apr_md5_init(ct);
apr_md5_update(ct, pass, strlen(pass));
apr_md5_final(hash, ct);
-#else
+#else
+ AP_MD5_CTX ct;
+
ap_MD5Init(ct);
-
ap_MD5Update(ct, pass, strlen(pass));
ap_MD5Final(hash, ct);
#endif
@@ -190,29 +188,26 @@
static char *sha1_hex_hash(const char *passwd)
{
-#ifdef APACHE2
- apr_sha1_ctx_t ct;
- char hash[APR_SHA1_DIGESTSIZE];
- static char real_hash[APR_SHA1_DIGESTSIZE * 2 + 1];
-#else
- AP_SHA1_CTX ct;
- char hash[SHA_DIGESTSIZE];
- static char real_hash[SHA_DIGESTSIZE * 2 + 1];
-#endif
-
+ int i;
#ifdef APACHE2
- apr_sha1_init(ct);
- apr_sha1_update(ct, passwd, strlen(passwd));
- apr_sha1_final(hash, ct);
-#else
- ap_SHA1Init(ct);
- ap_SHA1Update(ct, passwd, strlen(passwd));
- ap_SHA1Final(hash, ct);
+ apr_sha1_ctx_t ct;
+ char hash[APR_SHA1_DIGESTSIZE];
+ static char real_hash[APR_SHA1_DIGESTSIZE * 2 + 1];
+
+ apr_sha1_init(ct);
+ apr_sha1_update(ct, passwd, strlen(passwd));
+ apr_sha1_final(hash, ct);
+#else
+ AP_SHA1_CTX ct;
+ char hash[SHA_DIGESTSIZE];
+ static char real_hash[SHA_DIGESTSIZE * 2 + 1];
+
+ ap_SHA1Init(ct);
+ ap_SHA1Update(ct, passwd, strlen(passwd));
+ ap_SHA1Final(hash, ct);
#endif
- int i;
-
/* Now we convert the 20 octet hash to a 40 byte hex string */
for (i = 0; i sizeof(hash); i++) {
real_hash[2*i+1] = hash[i] 0xF;
@@ -1079,9 +1074,9 @@
#endif
{
#ifdef APACHE2
- apr_pool_cleanup_register(p, (void *) result, auth_mysql_result_cleanup,
auth_mysql_result_cleanup);
+ apr_pool_cleanup_register(p, (void *) result,
auth_mysql_result_cleanup, auth_mysql_result_cleanup);
#else
-ap_register_cleanup(p, (void *) result, auth_mysql_result_cleanup,
auth_mysql_result_cleanup);
+ ap_register_cleanup(p, (void *) result, auth_mysql_result_cleanup,
auth_mysql_result_cleanup);
#endif
}
@@ -1540,11 +1535,7 @@
#endif
case 0:
ap_note_basic_auth_failure(r);
-#ifdef APACHE2
return HTTP_UNAUTHORIZED;
-#else
- return AUTH_REQUIRED;
-#endif
break;
case 1:
return OK;
@@ -1553,11 +1544,7 @@
default:
APACHELOG(APLOG_DEBUG, r,
mysql_check_user_password returned error);
-#ifdef APACHE2
return HTTP_INTERNAL_SERVER_ERROR;
-#else
- return SERVER_ERROR;
-#endif
break;
}
}
@@ -1573,7 +1560,7 @@
{
mysql_auth_config_rec *sec = (mysql_auth_config_rec *)
ap_get_module_config(r-per_dir_config, auth_mysql_module);
#ifdef APACHE2
- char *user = r-user;
+ char *user = r-user;
#else
char *user = r-connection-user;
#endif
@@ -1583,7 +1570,7 @@
register int x;
const char *t, *w;
#ifdef APACHE2
- const apr_array_header_t *reqs_arr = ap_requires(r);
+ const apr_array_header_t *reqs_arr = ap_requires(r);
#else
const array_header *reqs_arr = ap_requires(r);
#endif
@@ -1599,11 +1586,8 @@
*/
if (!reqs_arr) {
if (sec-authoritative) {
-#ifdef APACHE2
- return HTTP_UNAUTHORIZED;
-#else
- return AUTH_REQUIRED;
-#endif
+ APACHELOG(APLOG_ERR, r, No requires line available);
+ return HTTP_UNAUTHORIZED;
} else {
Bug#287160: Reverse patch for 4.3.9-2
The trouble lies within this patch. I am trying to narrow it down as much as
possible. The first section of the code that changed looks like this:
- if ((rv = check_mysql_auth_require(user, t, r))
- != HTTP_UNAUTHORIZED)
- {
- return rv;
From the logs, check_mysql_auth_require is getting called here and the sql is
getting generated. But it is failing right away. So, next if we say its the
actual check_mysql_auth_require function, then comparing the differences it is
not much. Does the section of code above contain the proper initializers? Here
is a patch for 4.3.9-2 which does the same thing as the patch from the previous
post (except this one applies to the latest release of libapache-mod-auth).
Best Regards,
--- libapache-mod-auth-mysql-4.3.9-orig/mod_auth_mysql.c2005-03-11
09:35:14.0 -0800
+++ libapache-mod-auth-mysql-4.3.9/mod_auth_mysql.c 2005-03-11
09:39:11.0 -0800
@@ -1549,73 +1549,12 @@
}
}
-/* Go through a 'requires' line configured for the module, and return OK
- * if the user satisfies the line, or some sort of failure return code
- * otherwise.
- */
-int check_mysql_auth_require(char *user, const char *t, request_rec *r)
-{
- mysql_auth_config_rec *sec = (mysql_auth_config_rec *)
ap_get_module_config(r-per_dir_config, auth_mysql_module);
- const char *w;
- int rv;
-
- w = ap_getword(r-pool, t, ' ');
- /* If they're letting any old authenticated user, we're off the
-* hook!
-*/
- if (!strcmp(w, valid-user)) {
- return OK;
- }
-
- /* Checking a list of usernames */
- if (!strcmp(w, user)) {
- while (t[0]) {
- w = ap_getword_conf(r-pool, t);
- if (!strcmp(user, w)) {
- return OK;
- }
- }
- /* Not found */
- return HTTP_UNAUTHORIZED;
- } else if (!strcmp(w, group)) {
- /* This is the prickly one; checking whether the
-* user is a member of a listed group.
-*/
- while (t[0])
- {
- w = ap_getword_conf(r-pool, t);
- rv = mysql_check_group(r, user, (char *)w, sec);
-
- if (rv == 1)
- {
- /* Yep, we're all good */
- return OK;
- }
- else if (rv == -1)
- {
- return HTTP_INTERNAL_SERVER_ERROR;
- }
- }
- /* Distinct lack of foundage */
- return HTTP_UNAUTHORIZED;
- }
- else
- {
- APACHELOG(APLOG_ERR, r, Invalid argument to require: %s, w);
- return HTTP_INTERNAL_SERVER_ERROR;
- }
-
- APACHELOG(APLOG_ERR, r, CAN'T HAPPEN: Dropped out of the bottom of
check_mysql_auth_require!);
- return HTTP_INTERNAL_SERVER_ERROR;
-}
-
-/* This is the authorization step. We're presuming that the user has
- * successfully negotiated the step of I am who I say I am, now we're
- * checking to see if the user has permission to access this particular
- * resource. As with mysql_authenticate_basic_user, above, we return OK if
- * the user is fit to proceed, DECLINED if we don't want to make a decision
- * either way, HTTP_UNAUTHORIZED if the user is not allowed, or some apache
- * error if there was a major problem.
+/* This is the authorization step. We're presuming that the user has
successfully
+ * negotiated the step of I am who I say I am, now we're checking to see if
+ * the user has permission to access this particular resource.
+ * As with mysql_authenticate_basic_user, above, we return OK if the user
+ * is fit to proceed, DECLINED if we don't want to make a decision either way,
+ * or some apache error if there was a major problem.
*/
int mysql_check_auth(request_rec *r)
{
@@ -1626,9 +1565,10 @@
char *user = r-connection-user;
#endif
int m = r-method_number;
+ int method_restricted = 0;
int rv;
register int x;
- const char *t;
+ const char *t, *w;
#ifdef APACHE2
const apr_array_header_t *reqs_arr = ap_requires(r);
#else
@@ -1664,25 +1604,58 @@
reqs = (require_line *) reqs_arr-elts;
for (x = 0; x reqs_arr-nelts; x++) {
- /* mjp: WTF is this? */
+ /* WTF is this? */
if (!(reqs[x].method_mask (1 m))) {
continue;
}
+ method_restricted = 1;
t = reqs[x].requirement;
-
- /* OK, this might seem a little weird. The logic is that,
-* if the user is approved, that's
Bug#287160: Reverse patch for 4.3.9-2
Matthew Palmer wrote:
On Fri, Mar 11, 2005 at 11:32:11AM -0800, C.Y.M wrote:
The trouble lies within this patch. I am trying to narrow it down as much
as possible. The first section of the code that changed looks like this:
- if ((rv = check_mysql_auth_require(user, t, r))
- != HTTP_UNAUTHORIZED)
- {
- return rv;
That looks perfectly reasonable. I can't see any issues with the parameters
to this function, either.
Throw the attached single-line patch in and rebuild. An extra debug line
should pop out -- that's important.
Thanks for the debug patch. I have applied it and reproduced the error, but I
do not get any new debug info in the log. I am running apache2 in debug mode.
grep mysql_check_group complete /var/log/apache2/* -- no results
[Mon Mar 14 00:12:22 2005] [info] Initial (No.1) HTTPS request received for
child 1 (server my.website.net:443)
[Mon Mar 14 00:12:22 2005] [debug] mod_auth_mysql.c(1482): Handling an
authentication request for section /var/www/
[Mon Mar 14 00:12:22 2005] [debug] mod_auth_mysql.c(1523): Starting basic user
auth for [test_user] in /var/www/, child pid 29904
[Mon Mar 14 00:12:22 2005] [debug] mod_auth_mysql.c(1338): Constructing password
collection query with passfield=[passwd], table=[user_info],
userfield=[test_user], where_clause=[]
[Mon Mar 14 00:12:22 2005] [debug] mod_auth_mysql.c(1192): sec-dbh in /var/www/ is
[Mon Mar 14 00:12:22 2005] [debug] mod_auth_mysql.c(1199): Ordinary query
[Mon Mar 14 00:12:22 2005] [debug] mod_auth_mysql.c(1216): Running query:
[SELECT passwd FROM user_info WHERE username='test_user']
[Mon Mar 14 00:12:22 2005] [debug] mod_auth_mysql.c(1298): Checking with SHA1Sum
[Mon Mar 14 00:12:22 2005] [debug] mod_auth_mysql.c(1300): Auth succeeded
[Mon Mar 14 00:12:22 2005] [debug] mod_auth_mysql.c(1442): Making group query
with auth_table=[user_group], auth_user_field=[username], esc_user=[test_user],
esc_group=[adm], auth_group_field=[groups], where_clause=[]
[Mon Mar 14 00:12:22 2005] [debug] mod_auth_mysql.c(1449): Group query created;
[SELECT count(*) FROM user_group WHERE username='test_user' and
FIND_IN_SET('adm',groups)]
[Mon Mar 14 00:12:22 2005] [debug] mod_auth_mysql.c(1192): sec-dbh in /var/www/ is
[Mon Mar 14 00:12:22 2005] [debug] mod_auth_mysql.c(1199): Ordinary query
[Mon Mar 14 00:12:22 2005] [debug] mod_auth_mysql.c(1216): Running query:
[SELECT count(*) FROM user_group WHERE username='test_user' and
FIND_IN_SET('adm',groups)]
[Mon Mar 14 00:12:22 2005] [crit] [client 10.1.1.66] configuration error:
couldn't check access. No groups file?: /adm/, referer: https://my.website.net/
[Mon Mar 14 00:12:22 2005] [info] Connection to child 1 closed with unclean
shutdown(server my.website.net:443, client 10.1.1.66)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#287160: Reverse patch for 4.3.9-2
Matthew Palmer wrote:
On Mon, Mar 14, 2005 at 12:27:10AM -0800, C.Y.M wrote:
Thanks for the debug patch. I have applied it and reproduced the error,
but I do not get any new debug info in the log. I am running apache2 in
debug mode.
That's... odd. Once Running query gets printed, and Query maybe-failed
isn't printed, you're out the bottom of safe_mysql_query, and then your
options for the next log message are one of Group query failed, Store
result failed, or mysql_check_group complete. I don't suppose you might
not have installed the compiled module correctly? Perhaps change
AUTH_MYSQL_VERSION at the top to something unique, so you can check that
version string appears in the error log when you restart apache.
I'm sorry.. I must have messed up the patch the first time. Now I am seeing the
additional debug. The result gives me a 0 which seems correct since the user
is not in the adm group.
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1483): Handling an
authentication request for section /var/www/
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1524): Starting basic user
auth for [test_user] in /var/www/, child pid 16898
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1338): Constructing password
collection query with passfield=[passwd], table=[user_info],
userfield=[test_user], where_clause=[]
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1192): sec-dbh in /var/www/ is
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1199): Ordinary query
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1204): No DB connection open
- firing one up
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1096): Opening DB connection
for /var/www/
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1165): Persistent in
/var/www/ is 1
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1212): Correctly opened a
new DB connection
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1216): Running query:
[SELECT passwd FROM user_info WHERE username='test_user']
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1298): Checking with SHA1Sum
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1300): Auth succeeded
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1442): Making group query
with auth_table=[user_group], auth_user_field=[username], esc_user=[test_user],
esc_group=[adm], auth_group_field=[groups], where_clause=[]
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1449): Group query created;
[SELECT count(*) FROM user_group WHERE username='test_user' and
FIND_IN_SET('adm',groups)]
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1192): sec-dbh in /var/www/ is
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1199): Ordinary query
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1216): Running query:
[SELECT count(*) FROM user_group WHERE username='test_user' and
FIND_IN_SET('adm',groups)]
[Mon Mar 14 03:19:16 2005] [debug] mod_auth_mysql.c(1466): mysql_check_group
complete; result [0]
[Mon Mar 14 03:19:16 2005] [crit] [client 10.1.1.66] configuration error:
couldn't check access. No groups file?: /adm/, referer: https://my.website.net/
[Mon Mar 14 03:19:16 2005] [info] Connection to child 4 closed with unclean
shutdown(server my.website.net:443, client 10.1.1.66)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#287160: Reverse patch for 4.3.9-2
Matthew Palmer wrote: On Mon, Mar 14, 2005 at 12:27:10AM -0800, C.Y.M wrote: Thanks for the debug patch. I have applied it and reproduced the error, but I do not get any new debug info in the log. I am running apache2 in debug mode. Out of curiosity, how do you define the access to each directory? Are you defining the MySQL options within the .htaccess file or the apache2.conf file? What kind of mysql database structure are you using? I have mine setup using separate tables (one for user and one for group). The user table defines username and passwd with username as the primary key. The group table contains username and groups with both fields set to the primary keys. Note: I have tested using a single table database structure and got the same results (username, passwd, and groups in a single table). The MySQL username and pass is defined in the apache2.conf and the MySQL directives are set within the sites-available configs. Example of apache2.conf: --SNIP-- # Mod Auth MySQL Settings Auth_MySQL_Info localhost mysql_auth password Auth_MySQL_General_DB http_auth2 --SNIP-- Directory /var/www/ Options Indexes FollowSymLinks MultiViews AllowOverride AuthConfig Auth_MySQL on Auth_MySQL_Empty_Passwords off Auth_MySQL_Encryption_Types SHA1Sum Auth_MySQL_Password_Table user_info Auth_MySQL_Group_Table user_group Order allow,deny Allow from all /Directory --SNIP-- Then.. the .htaccess is like this: AuthName Authenticated Zone AuthType Basic require group adm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304559: TLS problems
After upgrading postfix (with integrated tls), I am having the same upgrade/installation problems mentioned in this thread. Also, when the server attempts to accept mail, I get the following error: Apr 14 02:46:54 nofear postfix/tlsmgr[28480]: fatal: unsupported transport type: fifo Apr 14 02:46:55 nofear postfix/master[28450]: warning: process /usr/lib/postfix/tlsmgr pid 28480 exit status 1 Apr 14 02:46:55 nofear postfix/master[28450]: warning: /usr/lib/postfix/tlsmgr: bad command startup -- throttling Apr 14 02:47:09 nofear postfix/smtpd[28483]: warning: connect to private/tlsmgr: Connection refused Apr 14 02:47:09 nofear postfix/smtpd[28483]: warning: problem talking to server private/tlsmgr: Connection refused Apr 14 02:47:10 nofear postfix/smtpd[28483]: warning: connect to private/tlsmgr: Connection refused Apr 14 02:47:10 nofear postfix/smtpd[28483]: warning: problem talking to server private/tlsmgr: Connection refused Apr 14 02:47:10 nofear postfix/smtpd[28483]: warning: no entropy for TLS key generation: disabling TLS support Best Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304559: More info
The problem appears to be that the links are created incorrectly when the
package is built (they are pointing to a non existing directory):
dpkg --contents postfix*
lrwxrwxrwx root/root 0 2005-04-14 05:50:50 ./usr/lib/libpostfix-dns.so.1
- debian/postfix/usr/lib/libpostfix-dns.so.1.0.1
lrwxrwxrwx root/root 0 2005-04-14 05:50:50
./usr/lib/libpostfix-global.so.1 -
debian/postfix/usr/lib/libpostfix-global.so.1.0.1
lrwxrwxrwx root/root 0 2005-04-14 05:50:50
./usr/lib/libpostfix-master.so.1 -
debian/postfix/usr/lib/libpostfix-master.so.1.0.1
lrwxrwxrwx root/root 0 2005-04-14 05:50:50 ./usr/lib/libpostfix-tls.so.1
- debian/postfix/usr/lib/libpostfix-tls.so.1.0.1
lrwxrwxrwx root/root 0 2005-04-14 05:50:50
./usr/lib/libpostfix-util.so.1 -
debian/postfix/usr/lib/libpostfix-util.so.1.0.1
This causes this message:
LD_LIBRARY_PATH=$(pwd)/lib:${LD_LIBRARY_PATH} dh_shlibdeps -a
dpkg-shlibdeps: warning: could not find path for libpostfix-tls.so.1
dpkg-shlibdeps: warning: could not find path for libpostfix-tls.so.1
dpkg-shlibdeps: warning: could not find path for libpostfix-tls.so.1
These same links also appear in postfix-dev.
Also, the rules file is creating a broken link:
libdb.so - /usr/lib/libdb3.so
And, libmysqlclient10-dev is a dependency where it should be bumped to
libmysqlclient12-dev.
Best Regards,
C.Y.M.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304559: More info
C.Y.M wrote:
The problem appears to be that the links are created incorrectly when the
package is built (they are pointing to a non existing directory):
dpkg --contents postfix*
lrwxrwxrwx root/root 0 2005-04-14 05:50:50
./usr/lib/libpostfix-dns.so.1
- debian/postfix/usr/lib/libpostfix-dns.so.1.0.1
lrwxrwxrwx root/root 0 2005-04-14 05:50:50
./usr/lib/libpostfix-global.so.1 -
debian/postfix/usr/lib/libpostfix-global.so.1.0.1
lrwxrwxrwx root/root 0 2005-04-14 05:50:50
./usr/lib/libpostfix-master.so.1 -
debian/postfix/usr/lib/libpostfix-master.so.1.0.1
lrwxrwxrwx root/root 0 2005-04-14 05:50:50
./usr/lib/libpostfix-tls.so.1
- debian/postfix/usr/lib/libpostfix-tls.so.1.0.1
lrwxrwxrwx root/root 0 2005-04-14 05:50:50
./usr/lib/libpostfix-util.so.1 -
debian/postfix/usr/lib/libpostfix-util.so.1.0.1
This causes this message:
LD_LIBRARY_PATH=$(pwd)/lib:${LD_LIBRARY_PATH} dh_shlibdeps -a
dpkg-shlibdeps: warning: could not find path for libpostfix-tls.so.1
dpkg-shlibdeps: warning: could not find path for libpostfix-tls.so.1
dpkg-shlibdeps: warning: could not find path for libpostfix-tls.so.1
These same links also appear in postfix-dev.
Also, the rules file is creating a broken link:
libdb.so - /usr/lib/libdb3.so
And, libmysqlclient10-dev is a dependency where it should be bumped to
libmysqlclient12-dev.
The following patches to the debian build rules and the master.cf correct my
problems..
Best Regards,
--- master.cf.orig 2005-04-16 01:53:13.0 -0700
+++ master.cf 2005-04-16 01:47:50.0 -0700
@@ -132,7 +132,7 @@
# flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store
${nexthop} ${user} ${extension}
# only used by postfix-tls
-tlsmgr fifo - - n 300 1 tlsmgr
+tlsmgr unix - - n 300 1 tlsmgr
smtpsinet n - n - - smtpd -o
smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
587 inet n - n - - smtpd -o
smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
diff -ruN postfix-2.2.2-orig/debian/control postfix-2.2.2/debian/control
--- postfix-2.2.2-orig/debian/control 2005-04-16 01:11:14.0 -0700
+++ postfix-2.2.2/debian/control2005-04-16 01:07:26.0 -0700
@@ -3,7 +3,7 @@
Priority: extra
Maintainer: LaMont Jones [EMAIL PROTECTED]
Standards-Version: 3.5.2.0
-Build-Depends: debhelper (= 4.1.16), libdb4.2-dev, libgdbm-dev, libldap2-dev
(=2.1), libpcre3-dev, libmysqlclient10-dev, patch, libssl-dev (=0.9.7-1),
libsasl2-dev, postgresql-dev, po-debconf (= 0.5.0), groff-base, dpatch
+Build-Depends: debhelper (= 4.1.16), libdb4.2-dev, libgdbm-dev, libldap2-dev
(=2.1), libpcre3-dev, libmysqlclient12-dev, patch, libssl-dev (=0.9.7-1),
libsasl2-dev, postgresql-dev, po-debconf (= 0.5.0), groff-base, dpatch
Package: postfix
Architecture: any
diff -ruN postfix-2.2.2-orig/debian/rules postfix-2.2.2/debian/rules
--- postfix-2.2.2-orig/debian/rules 2005-04-16 01:11:14.0 -0700
+++ postfix-2.2.2/debian/rules 2005-04-16 01:07:32.0 -0700
@@ -99,7 +99,12 @@
dh_clean -k
dh_installdirs -a
install lib/*.1 $(libdir)
- for i in $(libdir)/*.1; do ln -fs $${i}.so.1.0.1 $${i%.*.*}; done
+ cd $(libdir) \
+ ln -fs libpostfix-dns.so.1.0.1 libpostfix-dns.so.1 \
+ ln -fs libpostfix-global.so.1.0.1 libpostfix-global.so.1 \
+ ln -fs libpostfix-master.so.1.0.1 libpostfix-master.so.1 \
+ ln -fs libpostfix-tls.so.1.0.1 libpostfix-tls.so.1 \
+ ln -fs libpostfix-util.so.1.0.1 libpostfix-util.so.1
install lib/dict_ldap.so ${base}-ldap/${plibdir}
install lib/dict_pcre.so ${base}-pcre/${plibdir}
install lib/dict_mysql.so ${base}-mysql/${plibdir}
Bug#304920: sasl smtpd authentication not working as expected with postfix 2.2.2-1
Package: postfix Version: 2.2.2-1 Severity: Important When I attempt to send mail via smtp and authenticate via SASL, only LOGIN and PLAIN should be used (defined in /etc/postfix/sasl/smtpd.conf). Here is what I am using for smtpd.conf. # This sets smtpd to authenticate using the saslauthd daemon. pwcheck_method: saslauthd # This allows plain, login, cram-md5 and digest-md5 authentication mechanisms. mech_list: plain login But, I am unable to send mail and postfix is trying to use DIGEST-MD5 against the /etc/sasldb2 database instead of SASL. I have smtpd_sasl_security_options = noanonymous in main.cf so LOGIN and PLAIN methods of authentication should be allowed. I have a feeling that the /etc/postfix/sasl/smptd.conf file is not being used with the new version of postfix. If I go back to postfix version 2.1.5-9, everything works as expected. Best Regards, C.Y.M. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305447: invalid link to libdb3.so in build rules
Package: postfix Version: 2.2.2-2 Severity: Important In the debian/rules file, there is a link created to libdb3.so. However, /usr/lib/libdb3.so is part of the libdb3-dev package. The control file is correct in depending on libdb4.2-dev. Unfortunatly, when I change the link to point to libdb.so, postfix fails to build. --SNIP-- build: patch $(checkdir) ln -sf /usr/lib/libdb3.so debian/libdb.so --SNIP-- I am assuming the link should either be removed, since its not being used, or changed to point to: lrwxrwxrwx 1 root root 12 2005-02-05 13:19 /usr/lib/libdb.so - libdb-4.2.so build: patch $(checkdir) ln -sf /usr/lib/libdb.so debian/libdb.so Best Regards, C.Y.M. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295727: sys-syslog no longer works as expected
Corrin Lakeland wrote: On Fri, 18 Feb 2005 07:08, C.Y.M wrote: Instead of the logs being written to the syslog (like they should be), they are written to Razor's user homedir and called sys-syslog. Thanks, I'll look into it today. Hi, Just curious if you found a solution to this? Thanks, C.Y.M. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290465: debian/rules script broken for for libtheora
Package: libtheora Version: 0.0.0.alpha3-1 Description: When using apt-source get libtheora, the debian/rules file is not written properly. When I try to use fakeroot dpkg-buildpackage the process wants to try and install doc files (when all I want to do is build the package NOT install it). Thanks.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296817: Postque fatal: cannot flush mailq
Package: postfix Version: 2.1.5-7 Severity: Important Description: During bootup, the following error is displayed: Postque fatal: cannot flush mailq postfix seems to be working after the errors on boot. It appears that it is trying to flush the mailq before postfix is started. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296817: Acknowledgement (Postque fatal: cannot flush mailq)
I believe this error is caused by the change in /etc/network/if-up.d/postfix. Something like this would prevent the error but postfix does not seem to have a pid in /var/run?? if [ -e /var/run/postfix.pid ]; then /usr/sbin/sendmail -q fi Best Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296817: acknowledged by developer
Thanks for the bugfix. There is just one small typo in the change that still causes an error on boot about a unary operator expected. The following patch fixes it: --- postfix.orig2005-02-27 15:19:38.0 -0800 +++ postfix 2005-02-27 15:15:49.0 -0800 @@ -14,7 +14,7 @@ if [ -f /var/spool/postfix/pid/master.pid ]; then pid=$(sed 's/ //g' /var/spool/postfix/pid/master.pid) exe=$(ls -l /proc/$pid/exe 2/dev/null | sed 's/.* //') - if [ $exe = /usr/lib/postfix/master ]; then + if [ $exe = /usr/lib/postfix/master ]; then /usr/sbin/sendmail -q fi fi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298373: new libmysqlclient12 dependency causing libapache2-mod-php4 to segfault
Package: libapache2-mod-php4 Version: 4.3.10-9 Severity: Important Description: After building libapache2-mod-php4 with libmysqlclient12-dev, apache2 segfaults on all sql related web pages (ie; phpmyadmin). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298373: Acknowledgement (new libmysqlclient12 dependency causing libapache2-mod-php4 to segfault)
I believe the problem is with the php4-mysql package, not the libapache2-mod-php4 package. Sorry for the mix up. Hopefully, both packages are from the same package maintainer so I will not have to file a new report. Best Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416055: [PATCH] fix for kernel 2.6.19+
Package: cdfs-src
Version: 2.4.20.a+2.6.18-1
Attached is a patch to fix cdfs so it builds with kernels 2.6.19+.
Regards.
diff -ru cdfs/2.6/audio.c cdfs-2.6.20/audio.c
--- cdfs/2.6/audio.c 2006-10-24 12:44:49.0 -0700
+++ cdfs-2.6.20/2.6/audio.c 2006-12-11 12:30:47.0 -0800
@@ -167,7 +167,8 @@
/***/
struct file_operations cdfs_cdda_file_operations = {
-.read = generic_file_read,
+.read = do_sync_read,
+.aio_read = generic_file_aio_read,
.mmap = generic_file_mmap,
};
diff -ru cdfs/2.6/cddata.c cdfs-2.6.20/cddata.c
--- cdfs/2.6/cddata.c 2005-05-01 13:58:24.0 -0700
+++ cdfs-2.6.20/2.6/cddata.c 2006-12-11 12:30:47.0 -0800
@@ -76,7 +76,8 @@
struct file_operations cdfs_cddata_file_operations = {
- .read = generic_file_read,
+ .read = do_sync_read,
+ .aio_read = generic_file_aio_read,
#ifdef OLD_KERNEL
.mmap = generic_file_mmap
#else
diff -ru cdfs/2.6/cdfs.h cdfs-2.6.20/cdfs.h
--- cdfs/2.6/cdfs.h 2006-10-24 12:44:49.0 -0700
+++ cdfs-2.6.20/2.6/cdfs.h 2006-12-11 12:34:11.0 -0800
@@ -13,7 +13,7 @@
#endif
#ifndef CONFIG_CDFS_VERSION
-#define CONFIG_CDFS_VERSION 2.6.18
+#define CONFIG_CDFS_VERSION 2.6.19
#endif
diff -ru cdfs/2.6/cdXA.c cdfs-2.6.20/cdXA.c
--- cdfs/2.6/cdXA.c 2006-10-24 12:44:49.0 -0700
+++ cdfs-2.6.20/2.6/cdXA.c 2006-12-11 12:30:47.0 -0800
@@ -26,7 +26,8 @@
#include cdfs.h
struct file_operations cdfs_cdXA_file_operations = {
-.read = generic_file_read,
+.read = do_sync_read,
+.aio_read = generic_file_aio_read,
.mmap = generic_file_mmap,
};
diff -ru cdfs/2.6/hfs.c cdfs-2.6.20/hfs.c
--- cdfs/2.6/hfs.c 2005-05-01 13:58:24.0 -0700
+++ cdfs-2.6.20/2.6/hfs.c 2006-12-11 12:30:47.0 -0800
@@ -194,7 +194,8 @@
/***/
struct file_operations cdfs_cdhfs_file_operations = {
- .read = generic_file_read,
+ .read = do_sync_read,
+ .aio_read = generic_file_aio_read,
.mmap = generic_file_mmap
};
Bug#416061: [PATCH] fix for kernel 2.6.19+
Package: lufs-source Version: 0.9.7-8.1 Attached is a patch to fix the api in lufs to build with kernels 2.6.19+ (the patch for 2.6.18 is not included, refer to bug #388389). Regards. --- lufs/kernel/Linux/2.6/inode.c.orig 2007-03-24 07:15:06.0 -0700 +++ lufs/kernel/Linux/2.6/inode.c 2007-03-24 07:15:30.0 -0700 @@ -178,7 +178,6 @@ inode-i_ctime.tv_sec = fattr-f_ctime; inode-i_mtime.tv_sec = fattr-f_mtime; inode-i_atime.tv_sec = fattr-f_atime; -inode-i_blksize = fattr-f_blksize; inode-i_blocks = fattr-f_blocks; inode-i_size = fattr-f_size; --- lufs/kernel/Linux/2.6/file.c.orig 2007-03-24 07:15:13.0 -0700 +++ lufs/kernel/Linux/2.6/file.c 2007-03-24 07:16:56.0 -0700 @@ -254,7 +254,7 @@ TRACE(in\n); if(!(res = lu_revalidate_inode(dentry))) - res = generic_file_read(filp, buf, count, ppos); + res = do_sync_read(filp, buf, count, ppos); TRACE(out\n); @@ -284,7 +284,7 @@ TRACE(in\n); if(!(res = lu_revalidate_inode(dentry)) (count 0)) - res = generic_file_write(filp, buf, count, ppos); + res = do_sync_write(filp, buf, count, ppos); TRACE(out\n);
Bug#416066: nfssvc: writing fds to kernel failed
Package: nfs-kernel-server Version: 1.0.12-4+b1 After I updated to the latest stable kernel (2.6.20.4), I have been noticing the follow errors in syslog. Did the api change? Is there a patch for nfs-kernel-server? I did not have this problem with 2.6.17.14 kernels and nfs. nfsd[16801]: nfssvc: writing fds to kernel failed: errno 0 (Success) Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414669: [PATCH] missing link for libwfb.so
Package: nvidia-glx Version: 1.0.9746-2 I was getting a error in Xorg.0.log about a missing shared object. The problem is that nvidia names the .so differently. The attached patch fixes the problem. --- nvidia-graphics-drivers-1.0.9746/debian/nvidia-glx.links.in 2007-03-13 00:03:21.0 -0700 +++ nvidia-graphics-drivers-1.0.9755/debian/nvidia-glx.links.in 2007-03-12 22:53:08.0 -0700 @@ -2,6 +2,7 @@ usr/lib/libGLcore.so.#VERSION# usr/lib/libGLcore.so.1 usr/lib/libnvidia-tls.so.#VERSION# usr/lib/libnvidia-tls.so.1 usr/lib/xorg/modules/extensions/libglx.so.#VERSION# usr/lib/xorg/modules/extensions/libglx.so +usr/lib/xorg/modules/libnvidia-wfb.so.#VERSION# usr/lib/xorg/modules/libwfb.so usr/lib/libXvMCNVIDIA.so.#VERSION# usr/lib/libXvMCNVIDIA.so.1 usr/lib/libXvMCNVIDIA.so.#VERSION# usr/lib/libXvMCNVIDIA_dynamic.so.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414670: Unable to load xf86ExecX86int10
Package: nvidia-glx Version: 1.0.9746-2 I am having the following problem loading the int10 submodule with the latest nvidia drivers. I can not determine if this is an issue with nvidia or with xserver-xorg-core. ii xserver-xorg-core 1.1.1-20 X.Org X server -- core server This is what Xorg.0.log has in it. I do not see any errors about missing symbols, but there must be something missing. (II) Loading sub module int10 (II) LoadModule: int10 (II) Reloading /usr/lib/xorg/modules/libint10.so (WW) NVIDIA(1): Unable to load xf86ExecX86int10. (EE) NVIDIA(1): Unable to initialize the X Int10 module; the console may not (EE) NVIDIA(1): be restored correctly on your TV. Best Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414782: Unable to load xf86ExecX86int10
Package: xserver-xorg-core Version: 1.1.1-20 I am having the following problem loading the int10 submodule with the all my different nvidia drivers. The nvidia developers tell me this is an issue with xserver-xorg-core. This is what Xorg.0.log has in it. I do not see any errors about missing symbols, but there must be something missing. (II) Loading sub module int10 (II) LoadModule: int10 (II) Reloading /usr/lib/xorg/modules/libint10.so (WW) NVIDIA(1): Unable to load xf86ExecX86int10. (EE) NVIDIA(1): Unable to initialize the X Int10 module; the console may not (EE) NVIDIA(1): be restored correctly on your TV. Best Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410879: Unable to load xf86ExecX86int10
Additional info as requested. Thank you. X Window System Version 7.1.1 Release Date: 12 May 2006 X Protocol Version 11, Revision 0, Release 7.1.1 Build Operating System: UNKNOWN Current Operating System: Linux nofear 2.6.17.14.20070307.1 #1 PREEMPT Wed Mar 7 17:02:35 PST 2007 i686 Build Date: 07 March 2007 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Mon Mar 12 23:27:11 2007 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout Default Layout (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device nvidia0 (**) |--Screen Screen1 (1) (**) | |--Monitor Monitor1 (**) | |--Device nvidia1 (**) |--Input Device Generic Keyboard (**) Option XkbRules xorg (**) XKB: rules: xorg (**) Option XkbModel pc104 (**) XKB: model: pc104 (**) Option XkbLayout us (**) XKB: layout: us (==) Keyboard: CustomKeycode disabled (**) |--Input Device Configured Mouse (**) |--Input Device Generic Mouse (**) FontPath set to: /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, /usr/share/fonts/X11/misc/:unscaled, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/misc, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi (==) RgbPath set to /etc/X11/rgb (==) ModulePath set to /usr/lib/xorg/modules (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) No APM support in BIOS or kernel (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 1.0 X.Org XInput driver : 0.6 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/lib/xorg/modules/fonts/libbitmap.so (II) Module bitmap: vendor=X.Org Foundation compiled for 7.1.1, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.5 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/lib/xorg/modules/libpcidata.so (II) Module pcidata: vendor=X.Org Foundation compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.0 (--) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,3099 card 1106,3099 rev 00 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,b099 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:0b:0: chip 10b7,9050 card , rev 00 class 02,00,00 hdr 00 (II) PCI: 00:0e:0: chip 1131,7146 card 13c2,0003 rev 01 class 04,80,00 hdr 00 (II) PCI: 00:11:0: chip 1106,3074 card 1106,3074 rev 00 class 06,01,00 hdr 80 (II) PCI: 00:11:1: chip 1106,0571 card 1106,0571 rev 06 class 01,01,8a hdr 00 (II) PCI: 00:11:2: chip 1106,3038 card 0925,1234 rev 1b class 0c,03,00 hdr 00 (II) PCI: 00:11:3: chip 1106,3038 card 0925,1234 rev 1b class 0c,03,00 hdr 00 (II) PCI: 00:11:4: chip 1106,3038 card 0925,1234 rev 1b class 0c,03,00 hdr 00 (II) PCI: 00:11:5: chip 1106,3059 card 1297,a232 rev 30 class 04,01,00 hdr 00 (II) PCI: 01:00:0: chip 10de,0322 card 1462,9980 rev a1 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000c (VGA_EN is set) (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xec00 - 0xedff (0x200) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xe000 - 0xe7ff (0x800) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:17:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (--) PCI:*(1:0:0) nVidia Corporation NV34 [GeForce FX 5200] rev 161, Mem @ 0xec00/24, 0xe000/27 (II) Addressable bus resource ranges are [0] -1 0 0x - 0x (0x0) MX[B] [1] -1 0 0x - 0x (0x1) IX[B] (II) OS-reported resource ranges: [0] -1 0 0x0010 - 0x3fff (0x3ff0) MX[B]E(B) [1] -1 0 0x000f - 0x000f (0x1) MX[B] [2] -1 0 0x000c - 0x000e (0x3) MX[B] [3] -1 0 0x - 0x0009 (0xa) MX[B] [4] -1 0 0x - 0x (0x1) IX[B] [5] -1 0 0x - 0x00ff (0x100) IX[B] (II) PCI Memory
Bug#410879: 410879
I am having the same problem. Although I see one other bug in your log file that is part of the nvidia-glx package. I have submitted a patch to fix the libwfb.so missing file error. Refer to bug# 414669 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414782: 42_build_int10_submodules.diff
I tried removing 42_build_int10_submodules.diff from the patches and rebuild everything but I still had the same problem. Was there more to revert than just taking out this patch? I would be happy to test this if I could revert it back all the way. Best Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414669: xorg
The problem turned out to be a bad patch introduced in xserver-xorg-core. Please close. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399815: hwclock not set before root is checked
Package: util-linux Version: 2.12r-14 When hwclock.sh was set to 11 (since we need / to be writable for the adjfile), it started causing timestamp errors when checking / on reboot (with S10checkroot.sh). This only affects systems with /usr on a separate partition and is related to bug # 342887. Version 2.12r-13 seems to work ok, but I can understand the problem you face. Although, setting the hwclock after checking / will always cause timestamp errors. The hwclock must be set before any drives can be scanned or else timestamp errors will occur. Best Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418238: [PATCH] auto.smb unable to handle double spaces and default window shares
Package: autofs
Version: 4.1.4+debian-1
Attached is a patch to fix auto.smb so it can handle double spaces in file share
names (using gsub instead of sub) and also default administration shares.
Autofs did not like the $ symbol in front of the default window share names.
--CUT--
$SMBCLIENT $smbclientopts -gL $key 2/dev/null \
| awk -v key=$key -v opts=$mountopts -F'|' -- '
BEGIN { ORS=; first=1 }
/Disk/ { if (first) { print opts; first=0 };
gsub(/ /, \\ , $2);
sub(/\$/, \\$, $2);
print \\\n\t / $2, :// key / $2 }
END { if (!first) print \n; else exit 1 }
'
--CUT--
Best Regards.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418021: title
The title of this bug is misleading. Package: libx11-6 Version: 2:1.0.3-6 Severity: important It should read: Package: libx11-6 Version: 2:1.0.3-7 Severity: important -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329328: sysvinit attempts to mount selinux when it is not available
This fixes the problem.. although its not a real fix. --- rules.orig 2005-09-22 03:39:27.0 -0700 +++ rules 2005-09-22 03:31:28.0 -0700 @@ -30,7 +30,7 @@ # Builds the binary package. $(checkdir) ifeq ($(DEB_HOST_ARCH_OS),linux) - (cd src; make DISTRO=Debian WITH_SELINUX=yes) + (cd src; make DISTRO=Debian WITH_SELINUX=no) else (cd src; make DISTRO=Debian) endif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327298: spumux broken with new libmagick
Package: dvdauthor Version: 0.6.11-2 Severity: Important After testing dvdauthor 0.6.11-2 with libmagick 6.2.3.6-3, I am now able to build the dvdauthor packages. Unfortunatly, spumux is completly broken with the new libmagick versions. I am unable to create menus and my scripts now segfault due to missing .mpg files. When I attempt to go back to the stable libmagick package, something must not be getting removed because it is still broken after trying to reinstall the older stable libmagick. I have rebuilt all the packages several times with the older libmagick installed and spumux is still broken now. I am unsure if this is a dvdauthor problem, but I thought I would file it here first. I noticed someone else was talking about the same problem in the dvdauthor bug reports. --start quote-- what's the exact problem? I saw things like this in spumux strace output: 7042 stat64(orpion/dvd/menu1-0.mpg_buttons.png, unfinished ... 7042 write(2, scorpion: Unable to load file, 29 unfinished ... 7042 write(2, (/home/scorpion/dvd/menu1-0.mpg..., 45 unfinished ... So it seems to trash the path names somewhere, causing empty (or better: invisible) menus on DVDs, since the button images can not be loaded. --end quote-- As of this moment, I am stuck. Unable to go back because something is wrong the the package installation of libmagick preventing me from reinstalling the older packages. Best Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327434: Udev is not creating /dev/stdout-fd/1
Package: udev Version: 0.068-2 Severity: important Udev is not creating /dev/stdout-fd/1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327298: spumux broken with new libmagick
C.Y.M wrote: Package: dvdauthor Version: 0.6.11-2 Severity: Important Please close this report. The problem was not with spumux at all. The problem manifested itself with a new release of UDEV not creating /dev/stdout. Sorry for the bad report. Best Regards. C. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327434: Acknowledgement (Udev is not creating /dev/stdout-fd/1)
I would like to mention that this problem may also be related to HAL (not UDEV). Please forward accordingly if you find that this is the case. Best Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327434: Acknowledgement (Udev is not creating /dev/stdout-fd/1)
C.Y.M wrote: I would like to mention that this problem may also be related to HAL (not UDEV). Please forward accordingly if you find that this is the case. This is definitely a UDEV issue. I have noticed that all the links in /etc/udev/links.conf get created *except* stdin, stdout, and stderr. The only difference between those links and the others is that they are linking against nodes. Perhaps the nodes are not getting created fast enough and the link fails. When I look in /proc/self/fd/*, all the nodes are there (only the links to them are not created). Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327434: Acknowledgement (Udev is not creating /dev/stdout-fd/1)
Marco d'Itri wrote: tag 327434 unreproducible moreinfo help thanks On Sep 10, C.Y.M [EMAIL PROTECTED] wrote: This is definitely a UDEV issue. I have noticed that all the links in /etc/udev/links.conf get created *except* stdin, stdout, and stderr. The only difference between those links and the others is that they are linking against nodes. Perhaps the nodes are not getting created fast enough and the link fails. ln does not work this way (and anyway all nodes are created before udevstart returns). I think that something on your system is deleting these links. Please check. I have reverted everything that I can think of the past few days and nothing looks like it could be deleting those links. Besides, wouldnt they get recreated if I manually restarted udev after the system startup? I tried udevstart and the links are still not there. -C. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327434: Acknowledgement (Udev is not creating /dev/stdout-fd/1)
I have reverted everything that I can think of the past few days and nothing looks like it could be deleting those links. Besides, wouldnt they get recreated if I manually restarted udev after the system startup? I tried udevstart and the links are still not there. After some more testing, I am almost positive that there is some kind of race condition going on here. I am using a 2.6.13 kernel is that might make any difference to you. With the following patch, the problem is solved (although I know this is not the right way to go). I just wanted to prove that there is nothing else deleting these links. Regards, C. --- init.d/udev.orig 2005-09-10 03:56:55.0 -0700 +++ init.d/udev 2005-09-10 04:07:09.0 -0700 @@ -64,6 +64,9 @@ *) log_warning_msg links.conf: unparseable line ($type $name $arg1) ;; esac done + ln -fs /proc/self/fd/0 /dev/stdin + ln -fs /proc/self/fd/1 /dev/stdout + ln -fs /proc/self/fd/2 /dev/stderr } # this function is duplicated in preinst, postinst and d-i
Bug#327434: Acknowledgement (Udev is not creating /dev/stdout-fd/1)
C.Y.M wrote: I have reverted everything that I can think of the past few days and nothing looks like it could be deleting those links. Besides, wouldnt they get recreated if I manually restarted udev after the system startup? I tried udevstart and the links are still not there. After some more testing, I am almost positive that there is some kind of race condition going on here. I am using a 2.6.13 kernel is that might make any difference to you. With the following patch, the problem is solved (although I know this is not the right way to go). I just wanted to prove that there is nothing else deleting these links. Since I have not changed the udev package or upgraded it in any way for the past few weeks, I am fairly certain that this is not an actual UDEV bug. Some of the candidate packages responsible for this problem could be either the latest version of bash or possibly sed. I have updated all my packages so Im pretty sure if you were to do a full update you will notice the same problem. The chore now is to determine who the culprit is. Best Regards, C. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327434: Acknowledgement (Udev is not creating /dev/stdout-fd/1)
Since I have not changed the udev package or upgraded it in any way for the past few weeks, I am fairly certain that this is not an actual UDEV bug. Some of the candidate packages responsible for this problem could be either the latest version of bash or possibly sed. I have updated all my packages so Im pretty sure if you were to do a full update you will notice the same problem. The chore now is to determine who the culprit is. Sorry for the trouble. Its the new bash (3.0-15) that broke your package. Regards, C. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327477: Breaks /dev/stdin, stdout, and stderr with UDEV.
Package: bash Version: 3.0-16 Severity: grave The new version of Bash is causing udev-0.068-2 to *not* create links in /dev to the nodes in /proc/self/fd (/dev/stdin, /dev/stdout, /dev/stderr). I am using an x86 cpu with a 2.6.13 kernel. Re, C. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327477: Breaks /dev/stdin, stdout, and stderr with UDEV.
Matthias Klose wrote: tags 327477 +unreproducible thanks - please could you verify, if that occurs with dash as well? (setting the /bin/sh symlink to /bin/dash) - can you reproduce this with a kernel found in the Debian archives? I have reinstalled the new version of bash and switched the symlink to dash, and the problem does not occur. The problem is not kernel specific. In order to reproduce the problem: 1) Install New version of bash 2) Delete symlink (/dev/stdout, stdin, stderr) 3) /etc/init.d/udev restart Regards, C. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327570: missing /usr/bin/tput when rebooting
Package: initscripts Version: 2.86.ds1-1.2 When rebooting the system, I get an error message stating: missing file: /usr/bin/tput Regards, C. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319024: xfonts-scalable references Speedo
Package: xfonts-scalable Version: 6.8.2.dfsg.1-3 xfonts-scalable.postinst.in still references Speedo which has been removed from xorg. --SNIP-- #DEBHELPER# FONTDIRS=Speedo Type1 UPDATECMDS=update-fonts-scale update-fonts-dir --SNIP-- Setting up xfonts-scalable (6.8.2.dfsg.1-3) ... Updating font configuration of fontconfig... Cleaning up category cid.. Cleaning up category truetype.. Cleaning up category type1.. Updating category type1.. Updating category truetype.. Updating category cid.. xfonts-scalable postinst warning: Speedo is not a directory; not updating font directory data -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319105: dangling symlink in xterm package
Package: xterm Version: 6.8.2.dfsg.1-3 /etc/cron.daily/man-db: mandb: warning: /usr/share/man/man1/x-terminal-emulator.1.gz is a dangling symlink The current link in /etc/alternatives is: x-terminal-emulator.1.gz - /usr/X11R6/man/man1/lxterm.1.gz and should be: x-terminal-emulator.1.gz - /usr/X11R6/man/man1/lxterm.1x.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319543: #319543: new kernel-package creates ridiculous symlinks in /boot
I can confirm this bug as well. My system is x86 with 2.6.13-rc3 kernel. The bug surfaced with 9.002 (not 9.003). If I go back to 9.001, then it works as expected. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325152: find broken in dh_installdocs
Package: debhelper Version: 4.9.6 Severity: important When building packages, I get the following error with version 4.9.6. Going back to 4.9.5 fixes the problem. dh_installdocs --exclude=CVS --exclude=mplayer.1 DOCS/* find: paths must precede expression Usage: find [-H] [-L] [-P] [path...] [expression] dh_installdocs: command returned error code make: *** [binary-arch] Error 1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328248: libarts1-xine needs to link against libmodplug0c2
Package: libarts1-xine Version: 3.4.2-2 libarts1-xine should be built against libmodplug0c2 (not libmodplug0). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328248: libarts1-xine needs to link against libmodplug0c2
Adeodato Simó wrote: * C.Y.M [Wed, 14 Sep 2005 05:04:41 -0700]: Package: libarts1-xine Version: 3.4.2-2 libarts1-xine should be built against libmodplug0c2 (not libmodplug0). Er, where does libarts1-xine depend on libmodplug0? I can't find it. I guess libarts-xine is being built against libxine1 which in turn is linked against libmodplug0. So, when I goto install libmodplug0c2, it wants to remove all of the above. -C
Bug#328248: libarts1-xine needs to link against libmodplug0c2
Well, then you should've reported the bug against libxine1, not against us; we can't do nothing about it. .oO(other than NMU) Reassigned, thanks. Thanks, sorry for the confusion. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328570: external firmwre fails to load
Package: udev Version: 0.070-1 Udev fails to load external firmware. My dvb firmware fails to load. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329037: Package does not build with new linux-kernel-headers
Package: mysql-server Version: 4.0.24-10 Package does not build with new linux-kernel-headers (2.6.13+0rc3-1.1) and gcc-3.4. --SNIP-- In file included from /usr/include/asm/processor.h:18, from /usr/include/asm/atomic.h:6, from ./../include/my_global.h:287, from mysys_priv.h:17, from my_new.cc:22: /usr/include/asm/system.h:247: error: expected `,' or `...' before new /usr/include/asm/system.h: In function `long unsigned int __cmpxchg(volatile void*, long unsigned int, long unsigned int)': /usr/include/asm/system.h:250: error: `size' undeclared (first use this function) /usr/include/asm/system.h:250: error: (Each undeclared identifier is reported only once for each function it appears in.) /usr/include/asm/system.h:254: error: expected identifier before ')' token /usr/include/asm/system.h:260: error: expected identifier before ')' token /usr/include/asm/system.h:266: error: expected identifier before ')' token make[3]: *** [my_new.o] Error 1 make[3]: Leaving directory `/var/local/mysql/mysql-dfsg-4.0.24/mysys' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/local/mysql/mysql-dfsg-4.0.24' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/local/mysql/mysql-dfsg-4.0.24' make: *** [build-stamp] Error 2 --SNIP-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329039: mkisofs segfaults when creating isos
Package: mkisofs Version: 2.01+01a03-1 Severity: grave mkisofs segfaults when creating isos. Example: mkisofs -dvd-video -V ISO_`date +%d-%m-%Y` -o image.iso image Segmentation fault -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329037: Package does not build with new linux-kernel-headers
Christian Hammers wrote: Hi On 2005-09-19 sean finney wrote: On Sun, Sep 18, 2005 at 04:58:39PM -0700, C.Y.M wrote: Package: mysql-server Version: 4.0.24-10 Package does not build with new linux-kernel-headers (2.6.13+0rc3-1.1) and gcc-3.4. Hm, 4.0.24 is no longer present in unstable (superceeded by mysql-dfsg-4.1). Also, we have gcc-4.0 there. So this is maybe a non-issue? True, I did upgrade to 4.1 although I have not had a chance to build it yet. But, I thought 4.0 was/is still used for some systems. Best Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329039: mkisofs segfaults when creating isos
Steve McIntyre wrote:
On Sun, Sep 18, 2005 at 06:05:42PM -0700, C.Y.M wrote:
Package: mkisofs
Version: 2.01+01a03-1
Severity: grave
mkisofs segfaults when creating isos.
Example:
mkisofs -dvd-video -V ISO_`date +%d-%m-%Y` -o image.iso image
Segmentation fault
Can you provide an example tree that demonstrates this please? I can't
reproduce this at the moment...
Do you mean the xml?
--SNIP--
Enter do_dvdauthor
?xml version=1.0 encoding=ISO-8859-1?
dvdauthor dest=/home/video/tmp/vdr2dvd/16364/DVDSTRUCT jumppad=1
!-- The top level menu --
vmgm
menus
video format=ntsc aspect=4:3 /
audio format=mp2 channels=2 samplerate=48khz /
pgc entry=title
pre { g1=0;
if (g2 lt 1024) button=1024;
if (g2 gt 1024) button=g2;
button=1024;
}
/pre
vob
file=/home/video/tmp/vdr2dvd/16364/DVDMENU/spu-mainmenu-1.mpg pause=2/vob
button name=1 { g2=button ; jump titleset 1 menu ;
}/button
postjump cell 1;/post
/pgc
/menus
/vmgm
!-- The chapter menu and chapter for titleset 1 --
titleset
menus
video format=ntsc aspect=4:3 /
audio format=mp2 channels=2 samplerate=48khz /
pgc
pre button=2048; /pre
vob
file=/home/video/tmp/vdr2dvd/16364/DVDMENU/Titel-1/spu-submenu-1.mpg
pause=2/vob
button name=1jump vmgm menu 1;/button
button name=2jump title 1 chapter 1;/button
postjump cell 1;/post
/pgc
/menus
titles
video format=ntsc aspect=4:3 /
audio format=mp2 lang=en /
audio format=mp2 lang=en /
pgc
vob
file=/home/video/tmp/vdr2dvd/16364/DVDMENU/Titel-1/mplex.mpg
chapters=00:00:00,00:15:00,00:30:00,00
:45:00,01:00:00,01:15:00,01:30:00,01:45:00,02:00:00,02:15:00,02:30:00,02:45:00,03:00:00,03:15:00,03:30:00,03:45:00,04:00:00,0
4:15:00,04:30:00,04:45:00 pause=2/vob
postcall vmgm menu 1;/post
/pgc
/titles
/titleset
/dvdauthor
DVDAuthor::dvdauthor, version 0.6.11.
Build options: gnugetopt magick iconv freetype fribidi
Send bugs to [EMAIL PROTECTED]
INFO: Locale=en_US
INFO: Converting filenames to ISO-8859-1
INFO: dvdauthor creating VTS
STAT: Picking VTS 01
STAT: Processing
/home/video/tmp/vdr2dvd/16364/DVDMENU/Titel-1/spu-submenu-1.mpg...
INFO: Video pts = 0.178 .. 6.150
INFO: Audio[8] pts = 0.178 .. 2.170
INFO: Audio[32] pts = 0.178 .. 0.178
STAT: VOBU 10 at 2MB, 1 PGCS
INFO: Generating VTSM with the following video attributes:
INFO: MPEG version: mpeg2
INFO: TV standard: ntsc
INFO: Aspect ratio: 4:3
INFO: Resolution: 720x480
INFO: Audio ch 0 format: mp2/2ch, 48khz 20bps
STAT: Processing /home/video/tmp/vdr2dvd/16364/DVDMENU/Titel-1/mplex.mpg...
STAT: VOBU 144 at 41MB, 1 PGCS
STAT: VOBU 272 at 86MB, 1 PGCS
STAT: VOBU 400 at 135MB, 1 PGCS
STAT: VOBU 528 at 174MB, 1 PGCS
STAT: VOBU 608 at 197MB, 1 PGCS
INFO: Video pts = 0.179 .. 649.695
INFO: Audio[8] pts = 0.246 .. 649.086
INFO: Audio[9] pts = 0.246 .. 649.110
STAT: VOBU 617 at 199MB, 1 PGCS
WARN: GOP is not closed on cell 1 of source
/home/video/tmp/vdr2dvd/16364/DVDMENU/Titel-1/mplex.mpg of pgc 1
INFO: Generating VTS with the following video attributes:
INFO: MPEG version: mpeg2
INFO: TV standard: ntsc
INFO: Aspect ratio: 4:3
INFO: Resolution: 704x480
INFO: Audio ch 0 format: mp2/2ch, 48khz 20bps, 'en'
INFO: Audio ch 1 format: mp2/2ch, 48khz 20bps, 'en'
STAT: fixed 10 VOBUS
STAT: fixing VOBU at 27MB (97/617, 15%)
STAT: fixing VOBU at 66MB (209/617, 31%)
STAT: fixing VOBU at 96MB (305/617, 49%)
STAT: fixing VOBU at 135MB (401/617, 64%)
STAT: fixing VOBU at 167MB (497/617, 80%)
STAT: fixing VOBU at 193MB (593/617, 95%)
STAT: fixed 617 VOBUS
INFO: dvdauthor creating table of contents
INFO: Scanning /home/video/tmp/vdr2dvd/16364/DVDSTRUCT/VIDEO_TS/VTS_01_0.IFO
INFO: Creating menu for TOC
STAT: Processing /home/video/tmp/vdr2dvd/16364/DVDMENU/spu-mainmenu-1.mpg...
INFO: Video pts = 0.178 .. 6.150
INFO: Audio[8] pts = 0.178 .. 2.170
INFO: Audio[32] pts = 0.178 .. 0.178
STAT: VOBU 10 at 1MB, 1 PGCS
INFO: Generating VMGM with the following video attributes:
INFO: MPEG version: mpeg2
INFO: TV standard: ntsc
INFO: Aspect ratio: 4:3
INFO: Resolution: 720x480
INFO: Audio ch 0 format: mp2/2ch, 48khz 20bps
STAT: fixed 10 VOBUS
Enter do_mkisofs
17:30:57 : Start mkisofs
/usr/local/bin/vdr2dvd.sh: line 626: 22540 Segmentation fault nice -n
${PRIO} $MKISOFS $DVDMKISOFSOPTS -dvd-video -o ${
Image}.iso ${UniqueDVDDIR} $LOG 21
ERROR : exit on error: mkisofs
--SNIP--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Bug#329328: sysvinit attempts to mount selinux when it is not available
Package: sysvinit Version: 2.86.ds1-2 Sysvinit attempts to mount /selinux on boot and fails (but selinux is not currently enabled). Sysvinit should check if selinux is available before attempting to mount it. Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329328: Acknowledgement (sysvinit attempts to mount selinux when it is not available)
Further information: I have tested 2.6.13.2 and 2.6.14-rc2 kernel sources from kernel.org. Also, I have the following kernel security settings enabled: # # Security options # # CONFIG_KEYS is not set CONFIG_SECURITY=y # CONFIG_SECURITY_NETWORK is not set CONFIG_SECURITY_CAPABILITIES=m # CONFIG_SECURITY_ROOTPLUG is not set # CONFIG_SECURITY_SECLVL is not set # CONFIG_SECURITY_SELINUX is not set After updating to latest sysvinit package, I get the following error upon boot: Unable to mount /selinux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323356: udev fails to create dvb devices
Package: udev Version: 0.066-1 Severity: important After upgrading to 0.066-1, udev fails to create any devices in /dev/dvb for such cards as a Hauppauge DVB Card. Downgrading to 0.065-1 fixes the problem. Udev should be creating: /dev/dvb/adapter0/video0 etc.. Best Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323360: reference to killproc in init.d fails
Package: dirmngr
Version: 0.9.2-1
The init.d script references killproc which is not contained in the debian
package system. killall can be used as a substitute. Here is what I have
done to fix the problem:
--SNIP--
d_stop() {
killall -q -TERM $NAME
# killproc $NAME
rm -f $PIDFILE # see bug #321271
}
--SNIP--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323263: Bug#323356: udev fails to create dvb devices
Marco d'Itri wrote: On Aug 16, C.Y.M [EMAIL PROTECTED] wrote: After upgrading to 0.066-1, udev fails to create any devices in /dev/dvb for such cards as a Hauppauge DVB Card. Duplicate of #323263. Please try to help with the debugging as requested. After installing the new udev and rebooting the system, this is what happens when I try to probe the dvb card drivers: Aug 16 02:08:40 sid udevd[9498]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid udevd[9501]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid udevd[9504]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid udevd[9507]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid udevd[9510]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid udevd[9513]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid udevd[9516]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid udevd[9519]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid kernel: Linux video capture interface: v1.00 Aug 16 02:08:40 sid udevd[9522]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid udevd[9525]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid udevd[9528]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid udevd[9531]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid udevd[9534]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid udevd[9537]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid udevd[9540]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid udevd[9543]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid udevd[9546]: udevd.c: bind failed, Address already in use Aug 16 02:08:40 sid kernel: saa7146: register extension 'dvb'. Aug 16 02:08:40 sid kernel: ACPI: PCI Interrupt :00:0e.0[A] - Link [LNKB] - GSI 11 (level, low) - IRQ 11 Aug 16 02:08:40 sid kernel: saa7146: found saa7146 @ mem f0ab (revision 1, irq 11) (0x13c2,0x0003). Aug 16 02:08:40 sid kernel: DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.X). Aug 16 02:08:40 sid kernel: adapter has MAC addr = 00:d0:5c:23:6f:0c Aug 16 02:08:40 sid udev[9559]: udev_db.c: unable to read db file '/dev/.udevdb/[EMAIL PROTECTED]@:00:0e.0' Aug 16 02:08:41 sid kernel: dvb-ttpci: gpioirq unknown type=0 len=0 Aug 16 02:08:41 sid kernel: dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app 8000261e Aug 16 02:08:41 sid kernel: dvb-ttpci: firmware @ card 0 supports CI link layer interface Aug 16 02:08:41 sid kernel: dvb-ttpci: Crystal audio DAC @ card 0 detected Aug 16 02:08:41 sid kernel: saa7146_vv: saa7146 (0): registered device video0 [v4l2] Aug 16 02:08:41 sid kernel: DVB: registering frontend 0 (ST STV0299 DVB-S)... Aug 16 02:08:41 sid kernel: dvb-ttpci: found av7110-0. Aug 16 02:08:41 sid udev[9584]: udev.c: action, subsystem or devpath missing -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
