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#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#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#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#416066: nfssvc: writing fds to kernel failed
Steinar H. Gunderson wrote: On Sat, Mar 24, 2007 at 09:00:22AM -0700, C.Y.M wrote: 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) That's odd. There was a bug for this in the kernel at some point, but it was fixed. Could you please contact upstream? The patch must have gotten lost at some point. (In any case, this is not an nfs-utils bug; it's in the kernel.) /* Steinar */ Thanks. I have tried a newer kernel (2.6.21-rc5) and the problem is fixed. There must be a bug in kernel 2.6.20.4. Please close. Best Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414670: Acknowledgement (Unable to load xf86ExecX86int10)
Debian Bug Tracking System wrote: Thank you for the problem report you have sent regarding Debian. This is an automatically generated reply, to let you know your message has been received. It is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Randall Donald [EMAIL PROTECTED] If you wish to submit further information on your problem, please send it to [EMAIL PROTECTED] (and *not* to [EMAIL PROTECTED]). If you have filed this report in error and wish to close it, please send mail to [EMAIL PROTECTED] with an explanation why the bug report should be closed. Please do not reply to the address at the top of this message, unless you wish to report a problem with the Bug-tracking system. Debian bug tracking system administrator (administrator, Debian Bugs database) Please close. This is a bug with the following patch (42_build_int10_submodules.diff) in xserver-xorg-core-1.1.1-20. Best Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414669: acknowledged by developer (closing 414669)
Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #414669: [PATCH] missing link for libwfb.so, which was filed against the nvidia-glx package. It has been marked as closed by one of the developers, namely Randall Donald [EMAIL PROTECTED]. You should be hearing from them with a substantive response shortly, in case you haven't already. If not, please contact them directly. Debian bug tracking system administrator (administrator, Debian Bugs database) Sorry, this bug is still open. Please re-open. I accidentally replied to close the wrong one. 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: 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#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#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: [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: 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#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]
Re: BUG: warning at fs/inotify.c:181 with linux-2.6.18
>> >> Thank you for the confirmation. Please include me in this thread if >> someone >> finds the answer. This bug seems to occur very frequently on my >> machine with >> 2.6.18.1 so I have been forced to revert back to 2.6.17.13 until I can >> fix it. > > I haven't got around to looking at it yet, sorry. > > It does seem like my inotify scalability patch is involved, however it is > interesting that you cannot reproduce the problem in 2.6.17.13. > > I probably won't get around to having a look at it for a while, but if you > would like to speed up the process you could try running a git bisect to > find which patch is making the error trigger for you. > I finally got around to try 2.6.18.2 and I still seem to have this problem. Has anyone had a chance to make a patch for this yet? Best Regards. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: warning at fs/inotify.c:181 with linux-2.6.18
Thank you for the confirmation. Please include me in this thread if someone finds the answer. This bug seems to occur very frequently on my machine with 2.6.18.1 so I have been forced to revert back to 2.6.17.13 until I can fix it. I haven't got around to looking at it yet, sorry. It does seem like my inotify scalability patch is involved, however it is interesting that you cannot reproduce the problem in 2.6.17.13. I probably won't get around to having a look at it for a while, but if you would like to speed up the process you could try running a git bisect to find which patch is making the error trigger for you. I finally got around to try 2.6.18.2 and I still seem to have this problem. Has anyone had a chance to make a patch for this yet? Best Regards. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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]
Re: [linux-dvb] [av7110/budget/budget-ci/budget-av drivers] please test: drivers switched to I2C interrupt mode
Oliver Endriss wrote: Hm - it compiles here without any warnings. ;-( Maybe some problem with macro expansion. The attached patch replaces the macros by inline functions. Does it work now? That fixed it. It compiles with no warning now, using a 2.6.17.13 kernel. Thanks! Seems to be working fine so far with my Nexus-S. Best Regards. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [av7110/budget/budget-ci/budget-av drivers] please test: drivers switched to I2C interrupt mode
Oliver Endriss wrote: Hi, Thanks to Hartmut, I2C transfers of the saa7146 may now use interrupt mode. It will be enabled for av7110, budget, budget-ci and budget-av drivers. This might reduce cpu load and speed-up tuning. For testing the changesets are in my repositories: - http://linuxtv.org/hg/~endriss/v4l-dvb - http://linuxtv.org/hg/~endriss/v4l-dvb-av7110-refactoring The changesets are: - http://linuxtv.org/hg/~endriss/v4l-dvb?cmd=changeset;node=5db1929d9501;style=gitweb - http://linuxtv.org/hg/~endriss/v4l-dvb?cmd=changeset;node=3e346cd18d78;style=gitweb - http://linuxtv.org/hg/~endriss/v4l-dvb?cmd=changeset;node=55496629964b;style=gitweb Please test and report any problems if you run devices supported by the av7110, budget, budget-ci or budget-av drivers. If nobody complains these changesets will be submitted to HG master next weekend. It seems to build fine, but I am getting the following warnings: /var/local/linuxtv.cvs/v4l-dvb/v4l/av7110_hw.c: In function `av7110_bootarm': /var/local/linuxtv.cvs/v4l-dvb/v4l/av7110_hw.c:237: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/av7110_hw.c:301: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/av7110.c: In function `start_debi_dma': /var/local/linuxtv.cvs/v4l-dvb/v4l/av7110.c:359: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/av7110.c: In function `stop_ts_capture': /var/local/linuxtv.cvs/v4l-dvb/v4l/av7110.c:1178: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/av7110.c: In function `start_ts_capture': /var/local/linuxtv.cvs/v4l-dvb/v4l/av7110.c:1192: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/av7110.c: In function `av7110_detach': /var/local/linuxtv.cvs/v4l-dvb/v4l/av7110.c:2703: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/av7110.c:2718: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/av7110.c: In function `av7110_irq': /var/local/linuxtv.cvs/v4l-dvb/v4l/av7110.c:2771: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_i2c.c: In function `saa7146_i2c_writeout': /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_i2c.c:194: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_i2c.c:200: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_core.c: In function `interrupt_hw': /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_core.c:277: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_core.c:296: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_video.c: In function `video_begin': /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_video.c:766: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_video.c: In function `video_end': /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_video.c:811: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_vbi.c: In function `vbi_workaround': /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_vbi.c:95: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_vbi.c:113: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_vbi.c: In function `saa7146_set_vbi_capture': /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_vbi.c:195: warning: comparison of distinct pointer types lacks a cast /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_vbi.c: In function `vbi_stop': /var/local/linuxtv.cvs/v4l-dvb/v4l/saa7146_vbi.c:330: warning: comparison of distinct pointer types lacks a cast Best Regards. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
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
Re: [vdr] FF card A/V sync suggestion
Chad Flynt wrote: I am sure this is more widespread than people imagine. I know that everyone I talk to has this issue. But most don't participate on the ML. There are forums that have talked bout it all over. Most of us have just as said, gotten used to it and assumed it will never be addressed. So I too am glad to see it being discussed once again, and do hope there can be a resolution. I wish I understood more about how it all pieced together to help. The problem seems extra prevalent when watching cartoons. I would assume that many of the frames are repeated the same during the voice over and because they're using stack compression, they won't send any empty (null) frames. This is why the A/V desync is so terrible whenever I try to watch the Simpsons. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Udo Richter wrote: C.Y.M wrote: mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc -quiet 001.vdr Notice that -framedrop is added to the command line. I wonder if that is the reason why mplayer is immune to the a/v desync problem. Definitely not just that. My playback issue already disappears when using the most simple command line: mplayer -vo mpegpes -ao mpegpes 001.vdr. And just for completeness: No serious CPU load when playing back with VDR or mplayer. Yes, if the extra CPU load by mplayer is not even noticeable when playing back VDR recordings, and it is not prone to any type or desync, then I vote we all try to figure out what mplayer is doing and repeat it. Whats a few extra CPU cycles if it becomes much much more stable in the end. Thanks everyone for chiming in on this one. I really hope that this time we can stop passing the buck and just git'r done. :) Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Torgeir Veimo wrote: On 22 Oct 2006, at 22:33, C.Y.M wrote: And just for completeness: No serious CPU load when playing back with VDR or mplayer. Yes, if the extra CPU load by mplayer is not even noticeable when playing back VDR recordings, and it is not prone to any type or desync, then I vote we all try to figure out what mplayer is doing and repeat it. Whats a few extra CPU cycles if it becomes much much more stable in the end. The reason i mentioned the dvbplayer.c thread, is that this problem was mitigated by using different code to feed the softdevice mpeg2 decoder; using softplay to playback recordings provided dropout free playback. I'm not sure if softplay works with FF cards, but you might get the source at softdevice.berlios.de to give it a try. I use xine with my FF card and it works flawlessly and fixes all my problems, but since I never had trouble with the FF card when just watching live TV, I thought it was such a waste of CPU to have to use software decoding for everything. I only have problems when playing back recordings with the FF card. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Udo Richter wrote: C.Y.M wrote: Utilizing mpegpes is really the best of both worlds. We would still be using the video output on the FF card but having software to process the actual mpeg decoding. There would be no transcoding involved because obviously the recording would already be in a DVB resolution format. This leaves the question: If the video is already in DVB compatible mpeg2 format, what does mplayer do before forwarding the data stream to the DVB card, that VDR does not? Basically, VDR just forwards the whole data stream to the DVB driver. If mplayer is immune against stream desyncing, then they must do some repacking/fixing to the data stream that helps the DVB hardware on decoding. If the answer to this question could be discovered, then problem solved. So, what you are suggesting is VDR is not doing something that mplayer is doing that fixes the problem. Hmm... so then it is not a driver or firmware issue after all?? Could we agree that much? :) This has been back and forth for a long long time with the drivers development team and Klaus. hehe. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Klaus Schmidinger wrote: C.Y.M wrote: ... [ problem with A/V desync ] I would have to say that this is exactly the same thing I have been experiencing for years and years. But, this never happens with budget cards.. only FF cards. I'm not sure what you mean here. Budget cards can't replay, so it's clear that this problem can't happen with them. Or are you saying that this only happens with recordings made from FF cards, and not with recordings made from budget cards? Both, of course, replayed via a FF card. What I was trying to say is that the recordings are not damaged. They seem to playback fine with a software decoder on both FF and budget cards. I think that Udo has brought up a very good point about why mplayer is immune to the a/v desync problem when just using mpegpes to forward the video to the FF dvb card. BR. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
My theory is that since audio is typically 600ms ahead of video, maybe the audio buffers run over. Strange thing is why this happens reproducible on blackness. Maybe due to extremely low bit rate in this situation, more frames get packed into one data block, causing data flow to be disturbed beyond some limit. It cant be too high data rate, ATV+ has just 2mbit avg, 4mbit max data rate. Does it also occur with the latest test firmware? http://www.suse.de/~werner/test_av-f22623.tar.bz2 If yes, please provide short sample clips. Please verify that the clips are not damaged, i.e. they play fine with mplayer or xine. Yes, it still happens on every firmware revision. But, I really dont think this is a firmware issue as much as it is a VDR one. There must be several ways to approach this problem but the best way would be an open source solution IMHO. If mplayer can successfully forward the video every time straight to the FF card w/o any transcoding, then why cant VDR do the same thing? Im sure someone can post links to problematic recordings if you need some to test with. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Tero Siironen wrote: On 20.10.2006 15.09, Klaus Schmidinger [EMAIL PROTECTED] wrote: C.Y.M wrote: Since it has been several years now and I have never been able to solve the a/v desync issues with my Nexus-S FF card when playing back recordings... I'm replaying many recordings (actually most of what I watch are recordings ;-) and don't even remember when was the last time I had an A/V desync. Are you getting this with recordings from particular channels, or does it happen all the time? Also, is this with MPEG audio or AC3? Well here in Finland the channels at least where I've seen this to happen are two commercial channels (MTV3 and Nelonen). I don't remember seeing those problems with non-commercial channels (YLE's channels). The a/v sync problems usually occur when commercial break ends and program continues. But it happens also in the spots where there has been commercial break in the original broadcast but not in here. However, like Pasi Juppo told earlier in other thread, in last weeks episode of Lost there was many fadeout-fadeins between scenes and a/v desync happened on every one of these. I preserved an example clip of this with length of 3 minutes and there is four desync spots in it. So it is not directly related to commercial breaks. I think this happens almost on every recording made from these two channels. Audio is normal MPEG. I would have to say that this is exactly the same thing I have been experiencing for years and years. But, this never happens with budget cards.. only FF cards. My guess is that it is firmware/driver related. But, since only a handful of people have the source code to the firmware, it is virtually impossible to fix. we could work around it by using mplayer with mpegpes to playback the problematic recordings and live tv is never an issue. I would just like another way of playing back the recordings in VDR w/o having to rely on the firmware of the FF card that nobody can fix. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Udo Richter wrote: Tero Siironen wrote: However, like Pasi Juppo told earlier in other thread, in last weeks episode of Lost there was many fadeout-fadeins between scenes and a/v desync happened on every one of these. I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade into black, the data stream seems to get stuck, frames get delayed, and as consequence A/V desyncs and playback gets jerky, with lots of audio and video frame drops. This can be fixed by pausing and jumping a few frames backwards. My theory is that since audio is typically 600ms ahead of video, maybe the audio buffers run over. Strange thing is why this happens reproducible on blackness. Maybe due to extremely low bit rate in this situation, more frames get packed into one data block, causing data flow to be disturbed beyond some limit. It cant be too high data rate, ATV+ has just 2mbit avg, 4mbit max data rate. This theory sounds reasonable. Any idea on a way to fix it? The biggest question is if it can be fixed from within VDR's source code or if it would require an additional firmware/driver revision. I have given up hope on it. The only way I know of that is reliable is using software decoding. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
C.Y.M wrote: Udo Richter wrote: Tero Siironen wrote: However, like Pasi Juppo told earlier in other thread, in last weeks episode of Lost there was many fadeout-fadeins between scenes and a/v desync happened on every one of these. I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade into black, the data stream seems to get stuck, frames get delayed, and as consequence A/V desyncs and playback gets jerky, with lots of audio and video frame drops. This can be fixed by pausing and jumping a few frames backwards. My theory is that since audio is typically 600ms ahead of video, maybe the audio buffers run over. Strange thing is why this happens reproducible on blackness. Maybe due to extremely low bit rate in this situation, more frames get packed into one data block, causing data flow to be disturbed beyond some limit. It cant be too high data rate, ATV+ has just 2mbit avg, 4mbit max data rate. This theory sounds reasonable. Any idea on a way to fix it? The biggest question is if it can be fixed from within VDR's source code or if it would require an additional firmware/driver revision. I have given up hope on it. The only way I know of that is reliable is using software decoding. But, the biggest question is.. why does the ONLY happen when playing back recordings?? Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card A/V sync suggestion
Juri Haberland wrote: Klaus Schmidinger [EMAIL PROTECTED] wrote: C.Y.M wrote: Since it has been several years now and I have never been able to solve the a/v desync issues with my Nexus-S FF card when playing back recordings... I'm replaying many recordings (actually most of what I watch are recordings ;-) and don't even remember when was the last time I had an A/V desync. I also have A/V desyncs. This is with one TT-DVB-T (and a TT-DVB-C, most of the time we record and watch via the DVB-T card). In most cases it is bad reception. Pausing and restarting the video fixes it - most of the time - but sometimes I have to switch back to live TV and restart the video. Are you getting this with recordings from particular channels, or does it happen all the time? Also, is this with MPEG audio or AC3? There is no AC3 involved - just plain replay via FBAS and audio out of the TT card. The A/V desync problem would not be so critical if it corrected itself with some type of time code. In fact, even playing bad recordings back with some kind of software decoder can give you a desync once in a while, but the difference is that the software method fixes the desync automatically (without having to fast forward or rewind to the next GOP). Utilizing mpegpes is really the best of both worlds. We would still be using the video output on the FF card but having software to process the actual mpeg decoding. There would be no transcoding involved because obviously the recording would already be in a DVB resolution format. The CPU usage would be very minimal and I would not need to install X-windows or some type of framebuffer. I am just talking about regular MPEG audio/video. It doesn't seem like it would that hard to modify the mplayer plugin for just this purpose. In fact, it already works. But there are a few minor issues with it. 1) Mplayer can not get the correct seek time when playing back VDR recordings for some reason (causing the time bar to show incorrect values). 2) Mplayer can not handle playing back split files (ie; 001.vdr, 002.vdr). As of now each one must be selected individually. 3) Sometimes when playing back a video with mplayer (using only a single FF card in the machine), something puts a lock on something in /dev/dvb/adapter0/*. So, if a timer should happen to go off in VDR while you are playing back a video with mplayer, VDR will crash when attempting to start recording with the timer. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR to Xine playback -- no Audio?
mlists wrote: I'm running VDR 1.4.3 with hoochster's patches. I've install xine but I'm not getting any audio. When vdr starts up and then xine -- I'm getting this: vdr-xine: Client connecting ... vdr-xine: Client connected! [VM]buffered 50.2 frames (v:50.2, a:0.0) buffered 51.5 frames (v:51.5, a:0.0) Is this what I should see? That looks right, but it seems like alot of buffered frames. I think mine is set to buffer only 4 frames with a hysteric of 4. About the sound, what i did was loop the audio output of the nexus-s back into the line-in on my soundcard using that 1/8 stereo jack plug coming out of the nexus. Next, make sure you have your mixer settings correct. Good luck.. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] FF card A/V sync suggestion
Since it has been several years now and I have never been able to solve the a/v desync issues with my Nexus-S FF card when playing back recordings, I was thinking about what could be done. As of now, I have been using xine with my FF card to fix the problem. But, if I use xine, then even live tv is played back over software. The problem was never with live tv, only playing back recordings. What if the mplayer plugin was modified to replace the default vdr playback for recordings. It currently works as is, but it has problems with split files (ie; 001.vdr, 002.vdr, etc.). Also, it would be nice if there was an option to replace the default playback in vdr for recordings (so we wouldnt have to select the mplayer plugin first every time). Just a suggestion, but using mplayer over mpegpes would definitely be a better solution for fixing the a/v desync instead of having to use xine for everything (since there never was a problem with live tv). Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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]
[Pkg-sysvinit-devel] 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. ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
[Pkg-sysvinit-devel] 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. ___ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
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#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]
Re: AW: [vdr] vdr-xine xine-lib 1.1.2 (patch update)
martin wrote: Hey Darren, since some days, the xine-lib has changed a bit, so your patches fail against version 1.1.3. I've updated all necessary patches, to make xine-lib running with the current cvs version. You may want to update our patches on your site! What about xine-lib_modify_expand_plugin.patch? Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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]
Re: [linux-dvb] [patch 0/8] budget_ci: improve IR input handling
David Härdeman wrote: On Tue, October 3, 2006 2:33, C.Y.M said: David Härdeman wrote: This series of patches includes a number of bugfixes and changes to the IR input handling of the budget-ci driver. If these patches are successful, can they also be implemented into the regular nexus-s ir drivers too? Which driver is that? av7110? Yes. I have the same lirc issues with my full featured nexus card as others do with hauppauge budget cards. I'm sorry, but I don't quite follow...the ir driver for the av7110 uses the Linux input system (i.e. appears as a keyboard more or less), why use LIRC? Exactly what issues do you have? If I want to use Mythtv with the Nexus-S, then I have to use LIRC. But, everyone that I talk to with a hauppauge card seems to have a double key press problem when trying to use LIRC with those built in IR sensors. Best Regards. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch 0/8] budget_ci: improve IR input handling
David Härdeman wrote: On Tue, October 3, 2006 2:33, C.Y.M said: David Härdeman wrote: This series of patches includes a number of bugfixes and changes to the IR input handling of the budget-ci driver. If these patches are successful, can they also be implemented into the regular nexus-s ir drivers too? Which driver is that? av7110? Yes I have the same lirc issues with my full featured nexus card as others do with hauppauge budget cards. I'm sorry, but I don't quite follow...the ir driver for the av7110 uses the Linux input system (i.e. appears as a keyboard more or less), why use LIRC? Exactly what issues do you have? If I want to use Mythtv with the Nexus-S, then I have to use LIRC. But, everyone that I talk to with a hauppauge card seems to get double key presses when they try to use LIRC on that built in IR sensors. Best Regards. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch 0/8] budget_ci: improve IR input handling
David Härdeman wrote: This series of patches includes a number of bugfixes and changes to the IR input handling of the budget-ci driver. They are based on the dvb-ir patchset by Darren Salt and the two budget-ci patches that I recently sent to the list (meaning that they supercede patches 1 - 6 from Darren's series and my two previous patches). The result is a much more pleasant IR experience with snappier key reporting and some added features like RC5 device decoding. Compiled and tested with a programmable remote. Testers, comments and/or commits are welcome... If these patches are successful, can they also be implemented into the regular nexus-s ir drivers too? I have the same lirc issues with my full featured nexus card as others do with hauppauge budget cards. Best Regards. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [vdr] multiple keypresses with remote plugin
Oliver Endriss wrote: Torgeir Veimo wrote: On 21 Sep 2006, at 09:03, Marko Mäkelä wrote: On Sun, Sep 17, 2006 at 11:43:09AM +0100, Torgeir Veimo wrote: Using the remote plugin with a /dev/input/eventX setup for a hauppauge grey remote via a nova-t sensor with X11/Xv using softdevice works perfectly. With the same setup with directfb single button presses very often are detected as multiple button presses. I don't remember seeing a reply to this. What does evtest report when you press a button? It appears to be correct, it's just too fast, see below Please post the output of evtest for - a single (short) keypress - a long keypress I have the same problem using a nexus-s ir sensor and the grey remote with lirc. Evtest seems to show the right output, but lirc detects double key presses. If I set the toggle_bit in lircd.conf to 2, then I do not get double key presses with lirc, but the key repeat is then disabled permanently. If I use inputlirc instead of regular lirc, then the key presses work as expected. Unfortunately, vdr does not seem to work with inputlirc. It would be nice to get lirc to function properly when accessing /dev/input/eventX when using a hauppauge remote and ir sensor. When I build lirc, I configure it with --with-driver=devinput. BR. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] MP3/MPlayer plugin 0.9.15 available
- Added -S option to ppmtoy4m call in example image convert script. Suggested by Thorsten Gehrig. I was thinking of something more like this for backwards compatibility: @@ -61,17 +61,23 @@ # # now run the conversion # + +# 'chroma subsampling mode' mjpegtools = 1.8.0 +if ppmtoy4m -h | egrep -q '420mpeg2' ; then +SUBSAMPLINGMODE=-S 420mpeg2 +fi + if [ $FORMAT = ntsc ]; then pnmscale $S $TMP | \ pnmpad -black -width 704 -height 480 | \ ppmntsc | \ -ppmtoy4m -S 420mpeg2 -v 0 -n 1 -r -F 3:1001 | \ +ppmtoy4m -v 0 -n 1 -r -F 3:1001 $SUBSAMPLINGMODE | \ mpeg2enc -f 7 -T 90 -F 4 -nn -a 2 -v 0 -o $MPG else pnmscale $S $TMP | \ pnmpad -black -width 704 -height 576 | \ ppmntsc --pal | \ -ppmtoy4m -S 420mpeg2 -v 0 -n 1 -r -F 25:1 | \ +ppmtoy4m -v 0 -n 1 -r -F 25:1 $SUBSAMPLINGMODE | \ mpeg2enc -f 7 -T 90 -F 3 -np -a 2 -v 0 -o $MPG fi # Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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#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]
Re: AW: [vdr] execute command after vdr starts
martin wrote: Just add option -r script.sh #!/bin/sh case $1 in before) ;; after) echo After recording $2 /usr/local/bin/startnoad.sh $2 ;; edited) echo Edited recording $2 ;; *) echo ERROR: unknown state: $1 ;; esac Thanks for your replay, but I was looking for a switch that would make vdr run a script right after vdr starts up. Can this be adopted to that? This seems to only work after a recording has occurred. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: AW: [vdr] execute command after vdr starts
Udo Richter wrote: C.Y.M wrote: Thanks for your replay, but I was looking for a switch that would make vdr run a script right after vdr starts up. If you want to start a program together with VDR, why don't you put it into your runvdr script? Because in the runvdr script, the vdr command is executed by an eval statement which basically waits for the process to die before it continues on. eval $VDRCMD if test $? -eq 0 -o $? -eq 2; then exit; fi echo `date` Reloading DVB drivers ... This is how the script makes vdr will restart automatically when it crashes. I'm looking for a way to have vdr execute the command so I dont have to guess with sleep statements. BR. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] execute command after vdr starts
Is there a command line switch that would allow me to define a command vdr must excute after initial startup? I see one for before and after recordings, but I am looking for a way to execute a command after startup only. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] changes to runvdr for a nexus-s
Here is an example of the changes that I have had to make to runvdr so that my
nexus-s works. I have added a maximum retry value to runvdr so that vdr will
not keep attempting to start over and over if there is a major problem with
reception. Also, I have added a minimum runtime (in seconds) that vdr must have
in order to continue attempting to restart after a crash. For example, if vdr
crashes within 10 seconds and the minimum runtime required is 45 seconds, then
runvdr will consider that VDR has major problems and it will not try to keep
restarting up to the maximum allowed retries. However, the maximum retry value
can be set to 0 which would tell runvdr to attempt a restart unlimited times
after crashing.
BR.
--- vdr-1.4.2/runvdr.orig 2006-09-05 06:30:55.0 -0700
+++ vdr-1.4.2/runvdr 2006-09-05 06:31:37.0 -0700
@@ -22,26 +22,72 @@
#
# $Id: runvdr 1.19 2006/05/14 16:02:05 kls Exp $
-VDRPRG=./vdr
-VDRCMD=$VDRPRG -w 60 $*
+## Start Configuration Section ##
+# Disable NPTL (recommended)
+export LD_ASSUME_KERNEL=2.4.1
+#export LD_ASSUME_KERNEL=2.4.19
+
+# Uncomment to disable UTF-8 within VDR
+#export LANG=en_US
+#export LC_CTYPE=iso_8859_1
+
+PLUGINS=-Premote -Pscreenshot -Pepgsearch -Pprefermenu -Pdvdselect -Pvcd -Pfemon -Ptaste -Pstreamdev-server -Pstreamplayer -Ptext2skin -Pyaepg -Pundelete -Pweatherng -Posdpip -Pmplayercluster -Peggtimer -Psysinfo -Plocals -Pradioinfo -P'mp3 -C /etc/vdr -m /etc/vdr/plugins/mount.sh -i /etc/vdr/plugins/image_convert.sh -c /etc/vdr/images' -P'dvd -C/dev/cdrom' -P'mplayer -M /etc/vdr/plugins/mplayer.sh -m /etc/vdr/plugins/mount.sh' -P'xine -r -X 720 -Y 480'
+
+# VDR Recording directory (default is usually /video)
+VIDEO_DIR=/video
+# VDR Configuration directory where setup.conf lives
+CFG_DIR=/etc/vdr
+# Where the VDR epg.data file lives
+EPG_DIR=/etc/vdr
+# Search path for VDR plugins
+PLUG_DIR=/usr/local/bin/PLUGINS/lib
+# Startup Options passed to VDR
+OPTIONS=--terminal=/dev/tty8 -l 3 -w 0 --grab=/tmp
+# Path to VDR binary
+VDRPRG=/usr/local/bin/vdr
+# Path to insdvb.sh (for loading dvb modules)
+INSDVB=/usr/local/bin/insdvb.sh
+# Path to mplayer
+MPLAY=/usr/bin/mplayer
+# Path to startup video
+VIDEO=/etc/vdr/VDRboot-NTSC.mpeg
+# Number of times runvdr will attempt to restart vdr after a crash has occured (set to 0 for no limit)
+MAXTRIES=10
+# Minimum runtime required (in seconds) for vdr to continue restart attempts
+MINRUN=45
+
+## End Configuration Section ##
+
+if [ ! -e ${INSDVB} ]; then
+ echo -e ERROR: ${INSDVB} was not detected. Exiting. \n
+ exit 0
+fi
+
+VDRCMD=$VDRPRG -v $VIDEO_DIR -E $EPG_DIR -c $CFG_DIR -L $PLUG_DIR $OPTIONS $PLUGINS
KILL=/usr/bin/killall -q -TERM
# Detect whether the DVB driver is already loaded
# and return 0 if it *is* loaded, 1 if not:
function DriverLoaded()
{
- return 1
+ grep -qse dvb[-_]core /proc/modules
}
# Load all DVB driver modules needed for your hardware:
function LoadDriver()
{
+ ${INSDVB} load
+ if [ -e ${MPLAY} ]; then
+${MPLAY} -frames 145 -vo mpegpes -ao mpegpes ${VIDEO} 2/dev/null 1/dev/null
+ fi
+ echo
}
# Unload all DVB driver modules loaded in LoadDriver():
function UnloadDriver()
{
+ ${INSDVB} unload
}
# Load driver if it hasn't been loaded already:
@@ -49,13 +95,26 @@
LoadDriver
fi
+LASTRESTART=$(date +%s)
+LOOPCOUNT=0
while (true) do
- eval $VDRCMD
+ if [ $LOOPCOUNT -le $MAXTRIES ] || [ $MAXTRIES -eq 0 ] ; then
+eval $VDRCMD
+ else
+$KILL runvdr
+ fi
if test $? -eq 0 -o $? -eq 2; then exit; fi
- echo `date` reloading DVB driver
- $KILL $VDRPRG
+ TIMEOFDEATH=$(date +%s)
+ if [ $TIMEOFDEATH -le $(($LASTRESTART + $MINRUN)) ] ; then
+echo `date` VDR crashed in `expr $TIMEOFDEATH - $LASTRESTART` seconds. Minimum required runtime for VDR is $MINRUN seconds. Killing runvdr process...
+$KILL runvdr
+ fi
+ echo `date` Reloading DVB drivers
+ $KILL vdr
sleep 10
UnloadDriver
LoadDriver
- echo `date` restarting VDR
+ LASTRESTART=$(date +%s)
+ LOOPCOUNT=`expr $LOOPCOUNT + 1`
+ echo `date` Restarting VDR $LOOPCOUNT time(s). Maximum retries set to $MAXTRIES
done
#!/bin/sh
# insmod modules from current directory without having to install them first
# KERNELVER=`uname -r`
# KERNELDIR=/lib/modules/$KERNELVER/misc
sync
function DriverLoaded()
{
grep -qse dvb[-_]core /proc/modules
}
case $1 in
load)
if ! DriverLoaded; then
echo -n -e \nInserting DVB modules into kernel\n
# av7110 based full featured cards
modprobe stv0299
# saa7146 based siemens/technotrend/hauppauge cards
modprobe dvb-ttpci
# wait for udev to create the devices before continuing
until [ -e /dev/dvb/adapter0/video0 ]; do
sleep 1
done
if [ -e /usr/local/bin/loadkeys/av7110_loadkeys ]; then
/usr/local/bin/loadkeys/av7110_loadkeys
[vdr] sofdevice and softplay cvs cleanups
I have been trying to clean up my builds and when updated softdevice and
softplay via cvs, noticed several warning about unused variables. Also, it
appears that softplay does not have the current Makefile fixes required to build
under the latest VDR.
Best Regards,
--- softdevice.cvs/video-shm.c.orig 2006-09-03 04:34:56.0 -0700
+++ softdevice.cvs/video-shm.c 2006-09-03 04:41:00.0 -0700
@@ -285,16 +285,16 @@
};
void cShmVideoOut::YUV(sPicBuffer *buf) {
-uint8_t *Py=buf-pixel[0]+(buf-edge_height)*buf-stride[0]
-+buf-edge_width;
-uint8_t *Pu=buf-pixel[1]+(buf-edge_height/2)*buf-stride[1]
-+buf-edge_width/2;
-uint8_t *Pv=buf-pixel[2]+(buf-edge_height/2)*buf-stride[2]
-+buf-edge_width/2;
-int Ystride=buf-stride[0];
-int UVstride=buf-stride[1];
-int Width=buf-width;
-int Height=buf-height;
+//uint8_t *Py=buf-pixel[0]+(buf-edge_height)*buf-stride[0]
+//+buf-edge_width;
+//uint8_t *Pu=buf-pixel[1]+(buf-edge_height/2)*buf-stride[1]
+//+buf-edge_width/2;
+//uint8_t *Pv=buf-pixel[2]+(buf-edge_height/2)*buf-stride[2]
+//+buf-edge_width/2;
+//int Ystride=buf-stride[0];
+//int UVstride=buf-stride[1];
+//int Width=buf-width;
+//int Height=buf-height;
if (!ctl-attached) {
setupStore-shouldSuspend=1;
@@ -354,8 +354,8 @@
return;
};
-int width= ctl-max_width Width ? ctl-max_width : Width;
-int height= ctl-max_height Height ? ctl-max_height : Height;
+//int width= ctl-max_width Width ? ctl-max_width : Width;
+//int height= ctl-max_height Height ? ctl-max_height : Height;
ctl-width=fwidth;
ctl-height=fheight;
--- softdevice.cvs/video-xv.c.orig 2006-09-03 04:35:18.0 -0700
+++ softdevice.cvs/video-xv.c 2006-09-03 04:36:34.0 -0700
@@ -1814,10 +1814,10 @@
+buf-edge_width/2;
uint8_t *Pv=buf-pixel[2]+(buf-edge_height/2)*buf-stride[2]
+buf-edge_width/2;
- int Ystride=buf-stride[0];
- int UVstride=buf-stride[1];
- int Width=buf-width;
- int Height=buf-height;
+// int Ystride=buf-stride[0];
+// int UVstride=buf-stride[1];
+// int Width=buf-width;
+// int Height=buf-height;
if ( Py Pu Pv ) {
#if VDRVERSNUM = 10307
--- softplay.cvs/Makefile.orig 2006-05-19 01:04:59.0 -0700
+++ softplay.cvs/Makefile 2006-05-19 01:05:35.0 -0700
@@ -90,4 +90,4 @@
@echo Distribution package created as $(PACKAGE).tgz
clean:
- @-rm -f $(OBJS) $(DEPFILE) *.so *.tgz core* *~
+ @-rm -f $(OBJS) $(DEPFILE) *.so *.tgz core* *~ getFFmpegLibs
diff -ru softplay/Makefile softplay.cvs/Makefile
--- softplay/Makefile.orig 2006-03-20 12:09:20.0 -0800
+++ softplay/Makefile 2006-04-01 18:22:00.0 -0800
@@ -11,7 +11,7 @@
#LIBFFMPEG=/home/martin/vdr/ffmpeg
#LIBFFMPEG=/home/martin/vdr/ffmpeg-0.4.9-pre1
-LIBFFMPEG=/usr/local/include/ffmpeg/
+LIBFFMPEG=/usr/include/ffmpeg/
### The version number of this plugin (taken from the main source file):
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] sofdevice and softplay cvs cleanups
C.Y.M wrote:
I have been trying to clean up my builds and when updated softdevice and
softplay via cvs, noticed several warning about unused variables. Also, it
appears that softplay does not have the current Makefile fixes required to
build
under the latest VDR.
And this one too..
BR.
diff -ru softplay.cvs.orig/Makefile softplay.cvs/Makefile
--- softplay.cvs.orig/Makefile 2006-04-26 00:29:15.0 -0700
+++ softplay.cvs/Makefile 2006-04-26 00:59:27.0 -0700
@@ -24,7 +24,6 @@
### The directory environment:
-DVBDIR = ../../../../DVB
VDRDIR = ../../..
LIBDIR = ../../lib
TMPDIR = /tmp
@@ -35,7 +34,11 @@
### The version number of VDR (taken from VDR's config.h):
-VDRVERSION = $(shell grep 'define VDRVERSION ' $(VDRDIR)/config.h | awk '{ print $$3 }' | sed -e 's///g')
+VDRVERSION = $(shell sed -ne '/define VDRVERSION/s/^.*\(.*\).*$$/\1/p' $(VDRDIR)/config.h)
+APIVERSION = $(shell sed -ne '/define APIVERSION/s/^.*\(.*\).*$$/\1/p' $(VDRDIR)/config.h)
+ifeq ($(strip $(APIVERSION)),)
+ APIVERSION = $(VDRVERSION)
+endif
### The name of the distribution archive:
@@ -44,7 +47,7 @@
### Includes and Defines (add further entries here):
-INCLUDES += -I$(VDRDIR)/include -I$(DVBDIR)/include -I$(LIBFFMPEG) -I$(LIBFFMPEG)/libavformat -I$(LIBFFMPEG)/libavcodec -I$(LIBFFMPEG)/libavutil
+INCLUDES += -I$(VDRDIR)/include -I$(LIBFFMPEG) -I$(LIBFFMPEG)/libavformat -I$(LIBFFMPEG)/libavcodec -I$(LIBFFMPEG)/libavutil
DEFINES += -D_GNU_SOURCE -DPLUGIN_NAME_I18N='$(PLUGIN)'
@@ -79,7 +82,7 @@
libvdr-$(PLUGIN).so: $(OBJS)
$(CXX) $(CXXFLAGS) -shared $(OBJS) $(LIBS) -o $@
- @cp $@ $(LIBDIR)/[EMAIL PROTECTED](VDRVERSION)
+ @cp $@ $(LIBDIR)/[EMAIL PROTECTED](APIVERSION)
dist: clean
@-rm -rf $(TMPDIR)/$(ARCHIVE)
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xine-lib.cvs Compile stop errors
Darren Salt wrote: I demand that Stone may or may not have written... There is a fixed patchset here: URL:http://www.youmustbejoking.demon.co.uk/patches/vdr-xine/ Darren, should all of these patches in your vdr-xine directory be applied to current xine development? Thanks for the patches. Eventually. I won't commit them without being told that they're ready for commit and, ideally, not before they've been reviewed. Darren, has the xine-lib_modify_expand_plugin.patch been integrated to cvs now? Seems to cause an error. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [linux-dvb] Mythtv with NEXUS-S only
Gavin Hamill wrote: On Sat, 26 Aug 2006 13:37:35 +0300 Lauri Tischler [EMAIL PROTECTED] wrote: I was wondering is it possible to have Mythtv running with NEXUS-S FF card only, using it for capture _and_ tv-out MythTV site seems to be centered around PVR-card. I don't believe so - that's what VDR is for. Myth grew up on analogue reception and playing DivX / NuppelVideo, etc. - the DVB support is only a more recent addition, but playback still runs through the Myth core relying on either software decode or the PVR250/350 cards, etc. A FF card doesn't have the features Myth needs (i.e. being a full 24-bit framebuffer). Older versions of mythtv did have a check box to enable FF hardware acceleration. This option was removed in recent cvs versions, but I dont know why. BR. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Bug#366931: Apt fails of 0 byte files
Package: apt Version: 0.6.44 Severity: important When I type apt-get source, apt fails on the following: Reading package lists... Done Building dependency tree... Done E: Unable to parse package file /var/lib/apt/lists/sentinel.dk_debian_dists_unstable_contrib_source_Sources (2) E: Unable to parse package file /var/lib/apt/lists/sentinel.dk_debian_dists_unstable_non-free_source_Sources (2) If i go back to the previous version of apt, then it works fine. With the current version of apt, I am unable to get any source using apt-get source. The twi files above that apt-get fails on are 0 byte files. -rw-r--r-- 1 root root0 May 16 2005 sentinel.dk_debian_dists_unstable_contrib_binary-i386_Packages -rw-r--r-- 1 root root0 May 16 2005 sentinel.dk_debian_dists_unstable_contrib_source_Sources -rw-r--r-- 1 root root 6848 May 17 2005 sentinel.dk_debian_dists_unstable_main_binary-i386_Packages -rw-r--r-- 1 root root 2171 May 16 2005 sentinel.dk_debian_dists_unstable_main_source_Sources -rw-r--r-- 1 root root0 May 16 2005 sentinel.dk_debian_dists_unstable_non-free_binary-i386_Packages -rw-r--r-- 1 root root0 May 16 2005 sentinel.dk_debian_dists_unstable_non-free_source_Sources BR. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366931: Apt fails of 0 byte files
Michael Vogt wrote: On Fri, May 12, 2006 at 12:59:42AM -0700, C.Y.M wrote: Package: apt Version: 0.6.44 Severity: important Thanks for your bugreport. When I type apt-get source, apt fails on the following: Reading package lists... Done Building dependency tree... Done E: Unable to parse package file /var/lib/apt/lists/sentinel.dk_debian_dists_unstable_contrib_source_Sources (2) E: Unable to parse package file /var/lib/apt/lists/sentinel.dk_debian_dists_unstable_non-free_source_Sources (2) If i go back to the previous version of apt, then it works fine. With the current version of apt, I am unable to get any source using apt-get source. The twi files above that apt-get fails on are 0 byte files. [..] Do I understand this correctly, the previous version worked with zero size files? The new one does not? (it is not the new version that incorrectly creates those zero byte files)? That is correct, the zero byte files were always there from both versions of apt. The new version of apt is just unable to parse the zero byte files like the previous version can. BR. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366219: The first section in the PT_DYNAMIC segment is not the .dynamic section
Package: nvidia-glx Version: 1.0.8756-4 Severity: important When attempting to build nvidia drivers from the source, I get the following errors: dh_testdir dh_testroot dh_installchangelogs dh_installdocs -s dh_installexamples dh_installdebconf dh_installinit dh_installman dh_link dh_strip BFD: debian/nvidia-glx/usr/lib/stL0AwHo: warning: allocated section `.bss' not in segment BFD: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: The first section in the PT_DYNAMIC segment is not the .dynamic section strip: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: Bad value BFD: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: The first section in the PT_DYNAMIC segment is not the .dynamic section strip: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: Bad value dh_strip: command returned error code 256 make[1]: *** [binary-common] Error 1 make[1]: Leaving directory `/var/local/nvidia-glx/nvidia-graphics-drivers-1.0.8756' make: *** [binary-arch] Error 2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366222: dh_strip fails
Package: debhelper Version: 5.0.34 Severity: grave When building packages, dh_strip is now failing. For example, the nvidia-glx package: dh_testdir dh_testroot dh_installchangelogs dh_installdocs -s dh_installexamples dh_installdebconf dh_installinit dh_installman dh_link dh_strip BFD: debian/nvidia-glx/usr/lib/stL0AwHo: warning: allocated section `.bss' not in segment BFD: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: The first section in the PT_DYNAMIC segment is not the .dynamic section strip: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: Bad value BFD: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: The first section in the PT_DYNAMIC segment is not the .dynamic section strip: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: Bad value dh_strip: command returned error code 256 make[1]: *** [binary-common] Error 1 make[1]: Leaving directory `/var/local/nvidia-glx/nvidia-graphics-drivers-1.0.8756' make: *** [binary-arch] Error 2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366222: dh_strip fails
I don't think this is a bug in dh_strip; it looks like you have a buggy binutils installed. I've been using this version of debhelper to build all kinds of packages, without any errors of this kind; and in any case, the error messages are from strip, not from dh_strip. There has been a binutils update in the past month, so it's possible this is a change in binutils that only affects certain sorts of objects. I think it's best to assign the bug there for further investigation. Thanks for taking a look at this. Can you tell me what version of binutils you are using (assuming you are using Sid). Best Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366222: strip binary broken with latest binutils
Going back to binutils_2.16.1cvs20060117-1 fixed the strip problem. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366219: stip binary
Sorry for reporting this against the nvidia-glx package. This is a binutils problem. Please close this against the nvidia package. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366222: dh_strip fails
Steve Langasek wrote: On Sat, May 06, 2006 at 02:41:58AM -0700, C.Y.M wrote: I don't think this is a bug in dh_strip; it looks like you have a buggy binutils installed. I've been using this version of debhelper to build all kinds of packages, without any errors of this kind; and in any case, the error messages are from strip, not from dh_strip. There has been a binutils update in the past month, so it's possible this is a change in binutils that only affects certain sorts of objects. I think it's best to assign the bug there for further investigation. Thanks for taking a look at this. Can you tell me what version of binutils you are using (assuming you are using Sid). I'm using binutils 2.16.1cvs20060413-1 in a variety of environments, and haven't seen this error. You said that nvidia-glx was an example of dh_strip failing. What other packages have you seen this problem with? So far, the nvidia packages are the only ones I've seen with a problem. But, I reverted back to the previous release of binutils (binutils_2.16.1cvs20060117-1_i386) and you were right. Strip now works with the older version. Best Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366222: dh_strip fails
Joey Hess wrote: C.Y.M wrote: strip: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: Bad value BFD: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: The first section in the PT_DYNAMIC segment is not the .dynamic section I'll reassign this to the right package (you know, the one with strip in it), but it looks to me like your elf binary is corrupt, maybe a broken compiler or linker or it was built with the wrong options somehow? Unless you can give a recipe to reproduce this, the bug severity is inflated. To reproduce this try apt-get source nvidia-glx and then build it with fakeroot dpkg-buildpackage. When I went back to the previous version of binutils, it fixed the problem. Best Regards. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366222: dh_strip fails
Package: debhelper Version: 5.0.34 Severity: grave When building packages, dh_strip is now failing. For example, the nvidia-glx package: dh_testdir dh_testroot dh_installchangelogs dh_installdocs -s dh_installexamples dh_installdebconf dh_installinit dh_installman dh_link dh_strip BFD: debian/nvidia-glx/usr/lib/stL0AwHo: warning: allocated section `.bss' not in segment BFD: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: The first section in the PT_DYNAMIC segment is not the .dynamic section strip: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: Bad value BFD: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: The first section in the PT_DYNAMIC segment is not the .dynamic section strip: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: Bad value dh_strip: command returned error code 256 make[1]: *** [binary-common] Error 1 make[1]: Leaving directory `/var/local/nvidia-glx/nvidia-graphics-drivers-1.0.8756' make: *** [binary-arch] Error 2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366222: dh_strip fails
I don't think this is a bug in dh_strip; it looks like you have a buggy binutils installed. I've been using this version of debhelper to build all kinds of packages, without any errors of this kind; and in any case, the error messages are from strip, not from dh_strip. There has been a binutils update in the past month, so it's possible this is a change in binutils that only affects certain sorts of objects. I think it's best to assign the bug there for further investigation. Thanks for taking a look at this. Can you tell me what version of binutils you are using (assuming you are using Sid). Best Regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358831: bash operand errors (forwarded from C.Y.M)
C.Y.M wrote: Chet Ramey wrote: Matthias Klose wrote: C.Y.M writes: Reverting back to bash 3.0 fixes the problem. It seems bash 3.1 has broken the way the arrays are read. Once again bitten by using a too-general function for consistency across different expansions :-). I will be releasing a patch for this. Excellent. Thank you for taking the time to look at this. This problem is now fixed with bash31-017. Thank you. BR. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362778: missing /usr/lib/libXft.la
Package: libxft-dev Version: 2.1.8.2-6 Severity: important Please include /usr/lib/libXft.la in the installation. I use it to link into some older applications still. BR. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362777: missing /usr/lib/libXrender.la
Package: libxrender-dev Version: 0.9.0.2-2 Severity: important Please include /usr/lib/libXrender.la in the installation. I use it to link into some older applications still. BR. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362783: broken manpages
Package: libxau-dev Version: 1.0.0-2 Broken manpages mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauGetBestAuthByAddr.3x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauFileName.3x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauGetAuthByAddr.3x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauDisposeAuth.3x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauLockAuth.3x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauReadAuth.3x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauWriteAuth.3x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauUnlockAuth.3x.gz: bad symlink or ROFF `.so' request -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362782: Broken manpages
Package: xbase-clients Version: 7.0.0-2 Broken manpages mandb: can't open /usr/share/man/man1x/bitmap.1x: No such file or directory mandb: warning: /usr/share/man/man1/atobm.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/bitmap.1x: No such file or directory mandb: warning: /usr/share/man/man1/bmtoa.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapin.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapinfo.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapout.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapproto.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapreset.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapstats.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapchar.1x.gz: bad symlink or ROFF `.so' request -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362778: missing /usr/lib/libXft.la
Package: libxft-dev Version: 2.1.8.2-6 Severity: important Please include /usr/lib/libXft.la in the installation. I use it to link into some older applications still. BR. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362777: missing /usr/lib/libXrender.la
Package: libxrender-dev Version: 0.9.0.2-2 Severity: important Please include /usr/lib/libXrender.la in the installation. I use it to link into some older applications still. BR. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362783: broken manpages
Package: libxau-dev Version: 1.0.0-2 Broken manpages mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauGetBestAuthByAddr.3x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauFileName.3x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauGetAuthByAddr.3x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauDisposeAuth.3x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauLockAuth.3x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauReadAuth.3x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauWriteAuth.3x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory mandb: warning: /usr/share/man/man3/XauUnlockAuth.3x.gz: bad symlink or ROFF `.so' request -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362782: Broken manpages
Package: xbase-clients Version: 7.0.0-2 Broken manpages mandb: can't open /usr/share/man/man1x/bitmap.1x: No such file or directory mandb: warning: /usr/share/man/man1/atobm.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/bitmap.1x: No such file or directory mandb: warning: /usr/share/man/man1/bmtoa.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapin.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapinfo.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapout.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapproto.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapreset.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapstats.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapchar.1x.gz: bad symlink or ROFF `.so' request -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362645: nvidia-glx-dev conflicts with libgl1-mesa-dev and can not install with latest Xorg
Package: nvidia-glx-dev Version: 1.0.8756-4 Severity: important nvidia-glx-dev will not install and so I can not link any applications to the new nvidia drivers. dpkg: regarding nvidia-glx-dev_1.0.8756-4_i386.deb containing nvidia-glx-dev: nvidia-glx-dev conflicts with libgl-dev libgl1-mesa-dev provides libgl-dev and is installed. dpkg: error processing nvidia-glx-dev_1.0.8756-4_i386.deb (--install): conflicting packages - not installing nvidia-glx-dev Errors were encountered while processing: nvidia-glx-dev_1.0.8756-4b_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362645: nvidia-glx-dev conflicts with libgl1-mesa-dev and can not install with latest Xorg
Randall Donald wrote: On Fri, 2006-04-14 at 12:05 -0700, C.Y.M wrote: dpkg: regarding nvidia-glx-dev_1.0.8756-4_i386.deb containing nvidia-glx-dev: nvidia-glx-dev conflicts with libgl-dev libgl1-mesa-dev provides libgl-dev and is installed. dpkg: error processing nvidia-glx-dev_1.0.8756-4_i386.deb (--install): conflicting packages - not installing nvidia-glx-dev Errors were encountered while processing: nvidia-glx-dev_1.0.8756-4b_i386.deb Did you read the changelog? I have moved the header files back to /usr/include thus making it only possible to have one libgl-dev package installed at a time. If i try to remove libgl1-mesa-dev, then I cant have Xorg installed. Too many dependencies. What do you recommend? I also noticed that the diversions are incorrect when building some packages, like mplayer and vlc: dh_shlibdeps -s dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/X11R6/lib/libGL.so.1 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx to: /usr/X11R6/lib/nvidia/libGL.so.1.xlibmesa dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/lib/libGL.so.1 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.xlibmesa dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/X11R6/lib/libGL.so.1 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx to: /usr/X11R6/lib/nvidia/libGL.so.1.xlibmesa dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/lib/libGL.so.1.2 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.2.xlibmesa dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/lib/libGL.so.1 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.xlibmesa dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/X11R6/lib/libGL.so.1.2 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx to: /usr/X11R6/lib/nvidia/libGL.so.1.2.xlibmesa dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/X11R6/lib/libGL.so.1.2 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx to: /usr/X11R6/lib/nvidia/libGL.so.1.2.xlibmesa dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/lib/libGL.so.1.2 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.2.xlibmesa dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/X11R6/lib/libGL.so.1 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx to: /usr/X11R6/lib/nvidia/libGL.so.1.xlibmesa dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/lib/libGL.so.1 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.xlibmesa dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/X11R6/lib/libGL.so.1 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx to: /usr/X11R6/lib/nvidia/libGL.so.1.xlibmesa dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/lib/libGL.so.1.2 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.2.xlibmesa dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/lib/libGL.so.1 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.xlibmesa dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/X11R6/lib/libGL.so.1.2 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx to: /usr/X11R6/lib/nvidia/libGL.so.1.2.xlibmesa dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/X11R6/lib/libGL.so.1.2 dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx to: /usr/X11R6/lib/nvidia/libGL.so.1.2.xlibmesa dpkg-shlibdeps: warning: diversions involved - output may be incorrect diversion by nvidia-glx from: /usr/lib/libGL.so.1.2 dpkg-shlibdeps
Bug#361824: nvidia-glx-dev conflicts with xlibmesa-gl-dev
Package: nvidia-glx-dev Version: 1.0.8756-1 Severity: important nvidia-glx-dev conflicts with xlibmesa-gl-dev and can not be installed. dpkg: regarding nvidia-glx-dev_1.0.8756-1b_i386.deb containing nvidia-glx-dev: nvidia-glx-dev conflicts with libgl-dev xlibmesa-gl-dev provides libgl-dev and is installed. dpkg: error processing nvidia-glx-dev_1.0.8756-1b_i386.deb (--install): conflicting packages - not installing nvidia-glx-dev (Reading database ... 158554 files and directories currently installed.) Preparing to replace nvidia-glx 1.0.8178-3b (using nvidia-glx_1.0.8756-1b_i386.deb) ... Unpacking replacement nvidia-glx ... Setting up nvidia-glx (1.0.8756-1b) ... Installing new version of config file /etc/init.d/nvidia-glx ... Creating NVIDIA TLS links... done. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361578: required obsolete library - libdb2
Package: htdig Version: 3.1.6-11.1 Severity: important Htdig requires libdb2 for installation. libdb2 has been obsoleted from Sid for i386. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361369: conflicting files with modutils
Package: manpages-dev Version: 2.25-1 Severity: important Conflicts with modutils pacakage. dpkg: error processing /var/cache/apt/archives/manpages-dev_2.25-1_all.deb (--unpack): trying to overwrite `/usr/share/man/man2/create_module.2.gz', which is also in package modutils dpkg-deb: subprocess paste killed by signal (Broken pipe) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361033: missing package dependency libdigest-nilsimsa-perl
Package: razor Version: 2.810-1 Severity: important The libdigest-nilsimsa-perl package has been removed from Sid. Preparing to replace razor 2.720-1 (using razor_2.810-1_i386.deb) ... Unpacking replacement razor ... dpkg: dependency problems prevent configuration of razor: razor depends on libdigest-nilsimsa-perl; however: Package libdigest-nilsimsa-perl is not installed. dpkg: error processing razor (--install): dependency problems - leaving unconfigured Errors were encountered while processing: razor [EMAIL PROTECTED]:/var/local/razor$ sudo apt-get install libdigest-nilsimsa-perl Reading package lists... Done Building dependency tree... Done Package libdigest-nilsimsa-perl is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package libdigest-nilsimsa-perl has no installation candidate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360343: dangling symlink libtemplate.so
Package: unixodbc-dev Version: 2.2.11-11 Dangling symlink in /usr/lib/: libtemplate.so - libtemplate.so.1.0.0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360345: dangling symlink libtdsodbc.so
Package: freetds-dev Version: 0.63-2 Dangling symlink in /usr/lib/: libtdsodbc.so - libtdsodbc.so.0.0.0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
