Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
On Sat, Nov 05, 2005 at 12:21:00AM +, Christoph Hellwig wrote: On Fri, Nov 04, 2005 at 12:29:20PM +0900, Horms wrote: do I take that comment to mean that upstream can't update the drivers but Debian can? And if so, do you recommend updating Debian's kernel packages, or putting the updates elsewhere? Well, we could upstream, but so far no one is annoyed enough to overrid the driver maintainer. This is outrageous. Do you know any contacts at Intel to whom we could complain? I guess there would be many people willing to write a nice email about how impractical (actually, insane) such a policy is? -- - Harald Welte [EMAIL PROTECTED] http://gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) pgptj6y6wwuGN.pgp Description: PGP signature
Bug#337176: initramfs-tools: initrd unusable on amd64
I can confirm that adding symlink lib64 - lib to initrd.img will fix this problem. -- Tommi Vainikainen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337497: initramfs-tools: [powerpc] doesn't work on pegasos - ALERT! /dev/hda1 does
* Sven Luther wrote: ALERT!: /dev/hda1 does not exist, Dropping to a shell! I saw the same on my notebook (i386) when using MODULES=dep in initramfs.conf. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337599: linux-image-2.6.13-1-k7: Please make SECURITY_CAPABILITIES as module
reassign 337599 realtime-lsm thanks On Sun, Oct 16, 2005 at 02:13:04PM +0200, Mario Izquierdo (mariodebian) wrote: I want to compile realtime-lsm module in 2.6.13-1-k7 but module-asisstant don't work: This was already decided to be a realtime-lsm bug. Bastian -- It is undignified for a woman to play servant to a man who is not hers. -- Spock, Amok Time, stardate 3372.7 signature.asc Description: Digital signature
Bug#337607: initramfs-tools: Boot scripts tries to use evms_activate (and mdrun?), which isn't inside initrd.img
Package: initramfs-tools Version: 0.38 Severity: grave Inside generated initrd.img /scripts/local-top/evms script tries to execute /sbin/evms_activate. I don't use evms and I don't have evms files installed on my computer, and probably related to this fact, initrd.img does not contain /sbin/evms_activate and therefore booting fails. Same is true with /scripts/local-top/md. Maybe same is true with LVM, but vgchange gets installed to my initrd.img correctly because I've lvm tools installed. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-amd64-k8 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Versions of packages initramfs-tools depends on: ii busybox 1:1.01-3 Tiny utilities for small and embed ii cpio 2.6-9 GNU cpio -- a program to manage ar ii klibc-utils 1.1.1-2small statically-linked utilities ii mklibs-copy 0.1.18 Shared library reduction script ii udev 0.071-1/dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information Added by hand: ii lvm2 2.01.14-3 The Linux Logical Volume Manager -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337614: CONFIG_MODVERSIONS should not be used in distro kernels
Package: linux-image-2.6.14-1-686 Version: 2.6.14-2 Severity: normal Hello, please consider not using CONFIG_MODVERSIONS in future. Reason: it makes installation of alternative modules with the same names hard till unpossible. Current example: ipw2200, which is contained in 2.6.14 in a very old version. I cannot load the new version because lots of errors about conflicting versions are detected (in dependent ieee82... modules which I have built as well). Eduard. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.14-1-686 depends on: ii module-init-tools 3.2-pre9-3 tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.11-10 Yet Another mkInitRD linux-image-2.6.14-1-686 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337614: CONFIG_MODVERSIONS should not be used in distro kernels
On Sat, Nov 05, 2005 at 11:33:53AM +0100, Eduard Bloch wrote: Package: linux-image-2.6.14-1-686 Version: 2.6.14-2 Severity: normal Hello, please consider not using CONFIG_MODVERSIONS in future. Reason: it makes installation of alternative modules with the same names hard till unpossible. Current example: ipw2200, which is contained in 2.6.14 in a very old version. I cannot load the new version because lots of errors about conflicting versions are detected (in dependent ieee82... modules which I have built as well). Well, you could just subtly modifythe name or something, and do a diversion, not sure. The pwc module maintainer does exactly that, and has no such problem. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337497: initramfs-tools: [powerpc] doesn't work on pegasos - ALERT! /dev/hda1 does
On Sat, Nov 05, 2005 at 10:43:56AM +0100, Norbert Tretkowski wrote: * Sven Luther wrote: ALERT!: /dev/hda1 does not exist, Dropping to a shell! I saw the same on my notebook (i386) when using MODULES=dep in initramfs.conf. the above was with MODULES=most though. Well, whatever wasdefault, and since it had loads of cruft ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337614: CONFIG_MODVERSIONS should not be used in distro kernels
On Sat, Nov 05, 2005 at 11:33:53AM +0100, Eduard Bloch wrote: please consider not using CONFIG_MODVERSIONS in future. Reason: it makes installation of alternative modules with the same names hard till unpossible. Current example: ipw2200, which is contained in 2.6.14 in a very old version. I cannot load the new version because lots of errors about conflicting versions are detected (in dependent ieee82... modules which I have built as well). Err, _why_ do you get different symbol versions? They are supposed to be stable. Bastian -- Klingon phaser attack from front! 100% Damage to life support signature.asc Description: Digital signature
Bug#337614: CONFIG_MODVERSIONS should not be used in distro kernels
#include hallo.h * Bastian Blank [Sat, Nov 05 2005, 12:22:46PM]: On Sat, Nov 05, 2005 at 11:33:53AM +0100, Eduard Bloch wrote: please consider not using CONFIG_MODVERSIONS in future. Reason: it makes installation of alternative modules with the same names hard till unpossible. Current example: ipw2200, which is contained in 2.6.14 in a very old version. I cannot load the new version because lots of errors about conflicting versions are detected (in dependent ieee82... modules which I have built as well). Err, _why_ do you get different symbol versions? They are supposed to be stable. How should I know? I have even removed all the kernel equivalents and kept only custom versions of ieee8* and ipw22* modules, did rmmod and depmod -a, and still got: Nov 5 10:26:14 debian kernel: ieee80211_crypt: unregistered algorithm 'NULL' (deinit) Nov 5 10:26:24 debian kernel: ieee80211_crypt: registered algorithm 'NULL' Nov 5 10:26:24 debian kernel: ieee80211: 802.11 data/management/control stack, 1.1.6 Nov 5 10:26:24 debian kernel: ieee80211: Copyright (C) 2004-2005 Intel Corporation [EMAIL PROTECTED] Nov 5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol ieee80211_wx_set_encode Nov 5 10:26:24 debian kernel: ipw2200: Unknown symbol ieee80211_wx_set_encode Nov 5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol ieee80211_wx_get_encode Nov 5 10:26:24 debian kernel: ipw2200: Unknown symbol ieee80211_wx_get_encode Nov 5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol ieee80211_txb_free Nov 5 10:26:24 debian kernel: ipw2200: Unknown symbol ieee80211_txb_free Nov 5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol ieee80211_wx_get_scan Nov 5 10:26:24 debian kernel: ipw2200: Unknown symbol ieee80211_wx_get_scan Nov 5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol ieee80211_rx Nov 5 10:26:24 debian kernel: ipw2200: Unknown symbol ieee80211_rx Nov 5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol ieee80211_rx_mgt Nov 5 10:26:24 debian kernel: ipw2200: Unknown symbol ieee80211_rx_mgt Nov 5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol free_ieee80211 Nov 5 10:26:24 debian kernel: ipw2200: Unknown symbol free_ieee80211 Nov 5 10:26:24 debian kernel: ipw2200: disagrees about version of symbol alloc_ieee80211 Nov 5 10:26:24 debian kernel: ipw2200: Unknown symbol alloc_ieee80211 Eduard. -- Marcus Cole: I am a Ranger! We walk in the dark places no others may enter! We stand on a bridge, and no one may pass. We live for the One! We DIE for the ONE! -- Quotes from Babylon 5 --
Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not loaded in initrd
Package: linux-image-2.6.14-1-k7 Version: 2.6.14-2 Severity: critical Justification: breaks the whole system Booting with original initrd gives black screen. Regenerating initrd with yaird solved the problem. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1-k7 Locale: LANG=ca_ES, LC_CTYPE=ca_ES (charmap=ISO-8859-1) Versions of packages linux-image-2.6.14-1-k7 depends on: ii module-init-tools 3.2-pre9-3 tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.11-11 Yet Another mkInitRD linux-image-2.6.14-1-k7 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336450: acknowledged by developer (Bug#336450: fixed in yaird 0.0.11-11)
Confirmed fix working. Thanks guys. Richard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337614: CONFIG_MODVERSIONS should not be used in distro kernels
On Sat, Nov 05, 2005 at 12:32:02PM +0100, Eduard Bloch wrote: How should I know? I have even removed all the kernel equivalents and kept only custom versions of ieee8* and ipw22* modules, did rmmod and depmod -a, and still got: Okay, so you build ipw2200 against the symbol versions of the ieee80211 module included in the kernel from /lib/modules/$(uname -r)/source/Module.symvers. It seems that kbuild needs an option to disable versions for external modules. Bastian -- Insults are effective only where emotion is present. -- Spock, Who Mourns for Adonais? stardate 3468.1 signature.asc Description: Digital signature
Bug#336993: more info about #336993
Hi using cramfs in /etc/yaird/Default.cfg: #FORMAT cpio FORMAT cramfs and booting with: Linux root=/dev/ram init=/init rw i go pass the initrd, but mounting the root partition then fails end with messages like: /sbin/mkdnod: `/dev/sda': Read-only filesystem. /sbin/mkdnod: `/dev/sda4': Read-only filesystem. i could boot on 2.6.14 after recompiling with the command fakeroot make-kpkg --append-to-version -1-powerpc64-noinitrd \ --revision 2.6.14-2.0 --arch powerpc64 kernel_image with the following diffs to the config (change XFS to whatever your root filesystem is): 3,4c3,4 # Linux kernel version: 2.6.14-1-powerpc64 # Tue Nov 1 15:37:43 2005 --- # Linux kernel version: 2.6.14-powerpc64-noinitrd # Sat Nov 5 11:03:09 2005 747c747 CONFIG_SCSI=m --- CONFIG_SCSI=y 753,754c753,754 CONFIG_BLK_DEV_SD=m CONFIG_CHR_DEV_ST=m --- CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y 756c756 CONFIG_BLK_DEV_SR=m --- CONFIG_BLK_DEV_SR=y 758c758 CONFIG_CHR_DEV_SG=m --- CONFIG_CHR_DEV_SG=y 771c771 CONFIG_SCSI_SPI_ATTRS=m --- CONFIG_SCSI_SPI_ATTRS=y 801c801 CONFIG_SCSI_SATA=m --- CONFIG_SCSI_SATA=y 803c803 CONFIG_SCSI_SATA_SVW=m --- CONFIG_SCSI_SATA_SVW=y 2176c2176 CONFIG_XFS_FS=m --- CONFIG_XFS_FS=y 2267c2267 CONFIG_EXPORTFS=m --- CONFIG_EXPORTFS=y cheers, piem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not loaded in initrd
Processing commands for [EMAIL PROTECTED]: reassign 337625 initramfs-tools Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not loaded in initrd Bug reassigned from package `linux-image-2.6.14-1-k7' to `initramfs-tools'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not loaded in initrd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 reassign 337625 initramfs-tools thanks On Sat, 05 Nov 2005 13:06:58 +0100 Pau Capdevila [EMAIL PROTECTED] wrote: Booting with original initrd gives black screen. Sounds like you had initramfs-tools and not yaird installed at the time of initially installing the kernel. Reassigning to initramfs-tools. Regenerating initrd with yaird solved the problem. Yes, this has been fixed with most recent version of yaird. If this is fixed in recent initramfs-tools as well, I believe this bug can be closed. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDbKXxn7DbMsAkQLgRAnsYAKCVQJ2MQTHPWvGmJQQpf92cqY279wCdE1xr w1Fv9N54GX8l5PVtlh/f+oU= =rhZP -END PGP SIGNATURE-
Re: Sid linux-2.6 in SVN (Was: linux-2.6_2.6.14-2_hppa.changes ACCEPTED)
On Fri, Nov 04, 2005 at 10:15:01AM +0100, Christian T. Steigies wrote: BTW another question, what is the deal with klibc? My buildd refused to build it, since it is marked not for m68k. What is needed to make it build on m68k? Accoring to the maintainer, it hasn't been ported yet (#334917). FWIW, I put it on the todo http://wiki.debian.org/DebianM68kPorting. -- Stephen R. Marenka If life's not fun, you're not doing it right! [EMAIL PROTECTED] signature.asc Description: Digital signature
kernel-package (10.004) heading for experimental
Hi folks, This is the big one. The kernel image packages produced now use debconf to ask questions. This version has been tested as best I can -- I created all the kernel packages, individually, as well as the make-kpkg buildpackage; I tried both with and withoug --initrd, and I have installed 2.6.14 kernels on my i386 hardware to ensure the debconf stuff at least works for me in a brand new UML instance. This is the last version to go into experimental; I'll wait for bug report, and fix some recent reports, and upload to Sid in a day or so. So please test this version. manoj kernel-package (10.004) experimental; urgency=low * Bug fix: using debconf, thanks to Robert Millan (Closes: #115884) * Bug fix: does not install non-interactively, thanks to Matt Kraai (Closes: #247782) * This fine tunes the dependencies between targets. All of the package building targets are ones that insert themselves into the normal flow of policy specified targets, so they must hook themselves into the stream. That means, in essence, that they must depend on the configure and corresponding build targets (with stamps) and ensure that the prep work is all done before they are invoked. The advantage is that nothing is going to be remade more often than it needs to. It also means we do not need to produce as many stamp files. So, the only dependencies on any of the intermediate targets are targets that have not been registered into the ladder created in rulesets/common/targets.mk * The kernel image maintainer scripts have been greatly changed. Firstly, they now use debconf; and a number of questions have been moved to the config file (create-kimage-link-$version, old-initrd-link, old-dir-initrd-link, old-system-map-link) while others are asked conditionally in the postinst (depmod-error, depmod-error-initrd, bootloader-test-error, bootloader-error). The postinst has also become far less verbose; the users are far better educated a decade after this was written, and there are other sources of information about booting than the postinst of a kernel image. * The preinst also uses debconf. All the questions asked are still here -- we just use debconf to ask the user. Also, the priority, and need to break non-interactive installs was re-evaluated, and the preinst breaks in far fewer cases than it did before. * Second, the postinst gets rid of the code that generated boot floppies and created lilo.conf (that latter was probably illegal under current policy anyway). The do_boot_enable and do_boot_floppy configuration variables in /etc/kernel-img.conf are now invalid. * Also, the source tree is not automatically cleaned; the do_clean configuration variable, and the environment variable CLEAN_SOURCE are now control if the source tree is optionally cleaned after the kernel image package is built. more gory details === * kernel/ruleset/local.mk (CONFIG-common): since some of the others depend on it, only stamp-conf/debian remains on this target (CONFIG-arch): moved .config here -- the headers and image targets are the most likely to need this done. (CONFIG/kernel): moved conf.vars stamp-conf/kernel out here, so that stamp-conf/debian and .config shall be already done by the time they are invoked. (BUILD-common): Before any building is done, we should ensure that all the sanity checks are met -- instead of bombing out _after_ a lengthy build process. (debian): Make it depend on a target with a proper stamp, so it is not invoked over and over again. All of the package building targets are ones that insert themselves into the normal flow of policy specified targets, so they must hook themselves into the stream. That means, in essence, that they must depend on the configure and corresponding build targets (with stamps) and ensure that the prep work is all done before they are invoked. (CLEAN/$(i_package)): Ensure that the templates.master, and the templates, are created even on clean, for the kernel image package. * kernel/ruleset/targets/headers.mk (install/$(h_package)): Since we have taken care to insert this target into the flow specified in rulesets/common/targets.mk, we need not have any dependencies here. The advantage is that nothing is going tobe remade more often than it needs to. It also means we do not need to produce a stamp file ourselves. * kernel/ruleset/targets/manual.mk (install/$(m_package)): Minimize the dependencies for this target -- we are reduced to only having targets that have not been registered into the ladder created in rulesets/common/targets.mk * kernel/ruleset/targets/source.mk (install/$(s_package)): Reduce dependencies, for the reasons cited above. (binary/$(s_package)): Ditto. *
Re: Bug#337479: yaird: should use /usr/bin/perl, not /usr/local/bin/perl
severity 337479 serious thanks On Sat, Nov 05, 2005 at 04:31:02PM +0100, Mattia Dongili wrote: I'd say this is a problem in the submitter's build host. I's like configuring a package with silly ./configure options and pretending it works everywhere. :) No it is not, it is perfectly valid to have a compatible file laying around. As this changes the output of the build process in an unpredictable way, it needs to be fixed, I adjusted the severity to show this. Bastian -- You're too beautiful to ignore. Too much woman. -- Kirk to Yeoman Rand, The Enemy Within, stardate unknown signature.asc Description: Digital signature
Processed: Re: Bug#337479: yaird: should use /usr/bin/perl, not /usr/local/bin/perl
Processing commands for [EMAIL PROTECTED]: severity 337479 serious Bug#337479: yaird: should use /usr/bin/perl, not /usr/local/bin/perl Severity set to `serious'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337663: initramfs-tools: droping in rescue shell has no loadkeys and do not default to right keymap.
Sven Luther wrote: Package: initramfs-tools Severity: normal Well, as said, it is rather painful when one is dropped in the rescue shell, to have it default to us keymap, even though you have another kind of keyboard layout (azerty for me). At least it should include the loadkeys binary as well as the keymaps if it fails to autodetect the right thing. Friendly, Sven Luther Little-known fact: the 'kbd-chooser' binary acts as loadkeys within d-i. So we should make sure its loaded and there is a symlink to it from /bin/loadkeys. Regards Alastair -- System Information: Debian Release: 3.1 Architecture: powerpc (ppc) Kernel: Linux 2.6.12-1-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334123: marked as done (linux-image-2.6.13-1-k7: 2.6.12 works OK, 2.6.13 doesn't)
Your message dated Sat, 5 Nov 2005 19:29:03 +0100 with message-id [EMAIL PROTECTED] and subject line Bug#334123: linux-image-2.6.13-1-k7: 2.6.12 works OK, 2.6.13 doesn't has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 15 Oct 2005 18:15:51 + From [EMAIL PROTECTED] Sat Oct 15 11:15:51 2005 Return-path: [EMAIL PROTECTED] Received: from port-212-202-37-43.dynamic.qsc.de (knarzkiste.dyndns.org) [212.202.37.43] by spohr.debian.org with esmtp (Exim 3.36 1 (Debian)) id 1EQqZT-00084f-00; Sat, 15 Oct 2005 11:15:51 -0700 Received: by knarzkiste.dyndns.org (Postfix, from userid 0) id 1D078E006A91; Sat, 15 Oct 2005 20:15:49 +0200 (CEST) Content-Type: multipart/mixed; boundary0015114324== MIME-Version: 1.0 From: Ralf Hildebrandt [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: linux-image-2.6.13-1-k7: 2.6.12 works OK, 2.6.13 doesn't X-Mailer: reportbug 3.17 Date: Sat, 15 Oct 2005 20:15:49 +0200 Message-Id: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 This is a multi-part MIME message sent by reportbug. --===0015114324== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Package: linux-image-2.6.13-1-k7 Version: 2.6.13-1 Severity: normal 2.6.12-1-k7 works OK, the USB mouse works. Booting 2.6.13-1-k7 results in problems with the USB controller and IRQ 11 issues. I attached dmesg output for kernel 2.6.12 and 2.6.13; maybe the diff between the two can give some insights on what exactly causes the USB ports to utterly malfunction. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages linux-image-2.6.13-1-k7 depends on: ii initrd-tools 0.1.82 tools to create initrd image for p ii module-init-tools 3.2-pre9-2 tools for managing Linux kernel mo linux-image-2.6.13-1-k7 recommends no packages. -- no debconf information --===0015114324== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=2.6.12-1-k7 Linux version 2.6.12-1-k7 ([EMAIL PROTECTED]) (gcc version 4.0.2 20050917 (prerelease) (Debian 4.0.1-8)) #1 Tue Sep 27 13:22:07 JST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 1bf4 (usable) BIOS-e820: 1bf4 - 1bf5 (ACPI data) BIOS-e820: 1bf5 - 1c00 (ACPI NVS) BIOS-e820: 1c00 - 2000 (reserved) BIOS-e820: fff8 - 0001 (reserved) 0MB HIGHMEM available. 447MB LOWMEM available. On node 0 totalpages: 114496 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 110400 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: RSDP (v000 MSI ) @ 0x000f8350 ACPI: RSDT (v001 MSI1013 0x08242005 MSFT 0x0097) @ 0x1bf4 ACPI: FADT (v002 MSI1013 0x08242005 MSFT 0x0097) @ 0x1bf40200 ACPI: MADT (v001 MSIOEMAPIC 0x08242005 MSFT 0x0097) @ 0x1bf40300 ACPI: WDRT (v001 MSIMSI_OEM 0x08242005 MSFT 0x0097) @ 0x1bf40360 ACPI: MCFG (v001 MSIOEMMCFG 0x08242005 MSFT 0x0097) @ 0x1bf403b0 ACPI: SSDT (v001 OEM_ID OEMTBLID 0x0001 INTL 0x02002026) @ 0x1bf43620 ACPI: OEMB (v001 MSIMSI_OEM 0x08242005 MSFT 0x0097) @ 0x1bf50040 ACPI: DSDT (v001MSI 1013 0x08242005 INTL 0x02002026) @ 0x ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 16 ACPI: Skipping IOAPIC probe due to 'noapic' option. Allocating PCI resources starting at 2000 (gap: 2000:dff8) Built 1 zonelists
Bug#337682: initramfs-tools: ROOT=probe not implemented.
Package: initramfs-tools Severity: wishlist initramfs-tools generated ramdisk don't allow not passing the root filesystem in the command line, which would be probed at ramdisk boot time. This is a regression from initrd-tools which supported this feature. The way it works is to have the ramdisk generation detect the root partition, and use it as default if not overriden by the kernel command line. Friendly, Sven Luther -- System Information: Debian Release: 3.1 Architecture: powerpc (ppc) Kernel: Linux 2.6.12-1-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333052: 2.6.14, udev: unknown symbols for ehci_hcd
On Sat, Nov 05, 2005 at 06:31:04PM +0100, Kay Sievers wrote:
I've got these messages several times on the experimental SUSE too,
but can't reproduce it so far, even without Rusty's patch to modprobe
they have disappeared. See here for the details:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333052
Just to let you know, I've also met this problem (on another distro),
and did not know about this bugreport until now.
So I've done another workaround: modprobe already parses /proc/modules
to check whether the modules needed are already loaded, and this file
also shows us the state of the modules, being Loading, Live or
Unloading.
With my patch, modprobe waits until the needed modules come out of the
Loading or Unloading state.
--
pozsy
--- module-init-tools-3.2-pre4.orig/modprobe.c 2005-05-08 09:38:52.0
+0200
+++ module-init-tools-3.2-pre4/modprobe.c 2005-10-24 13:19:39.0
+0200
@@ -363,6 +363,7 @@
FILE *proc_modules;
char *line;
+start:
/* Might not be mounted yet. Don't fail. */
proc_modules = fopen(/proc/modules, r);
if (!proc_modules)
@@ -373,12 +374,31 @@
if (entry strcmp(entry, modname) == 0) {
/* If it exists, usecount is the third entry. */
- if (usecount) {
- entry = strtok(NULL, \n);
- if (entry
-(entry = strtok(NULL, \n)) != NULL)
+ if (!(entry = strtok(NULL, \n)))
+ goto out;
+
+ if (!(entry = strtok(NULL, \n))) /* usecount */
+ goto out;
+ else
+ if (usecount)
*usecount = atoi(entry);
+
+ if (!(entry = strtok(NULL, \n))) /* - */
+ goto out;
+
+ if (!(entry = strtok(NULL, \n))) /* status */
+ goto out;
+ else {
+ if (!strcmp(entry, Loading) || !strcmp(entry,
Unloading)) {
+ usleep(10);
+ free(line);
+ fclose(proc_modules);
+ goto start;
+ }
+ goto out;
}
+
+ out:
free(line);
fclose(proc_modules);
return 1;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337704: initramfs-tools: evms root *still* broken -- only part of 336617 resolved!
Package: initramfs-tools
Version: 0.38
Severity: important
Tags: patch
336617 was closed out without using the additional patches I submitted.
I'm having problems re-opening the bug, so I'm just submitting a new one.
The following two patches need to be applied to evms 0.38 in order to allow
booting to evms volumes located on lvm and md regions. Tested with stock
linux-image-2.6.14-1-686-smp.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (650, 'testing'), (600, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-686-smp
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages initramfs-tools depends on:
ii busybox 1:1.01-3 Tiny utilities for small and embed
ii cpio 2.6-9 GNU cpio -- a program to manage ar
ii klibc-utils 1.1.1-2small statically-linked utilities
ii mklibs-copy 0.1.18 Shared library reduction script
ii udev 0.071-1/dev/ and hotplug management daemo
initramfs-tools recommends no packages.
-- no debconf information
--- initramfs-tools/hooks/evms 2005-11-01 22:21:25.0 -0800
+++ initramfs-tools/hooks/evms 2005-11-02 09:30:55.0 -0800
@@ -21,15 +21,16 @@
fi
cp /sbin/evms_activate ${DESTDIR}/sbin
+cp /etc/evms.conf ${DESTDIR}/etc
EVMS_VERSION=$(/usr/sbin/evms_query info | grep EVMS Version | awk '{ print
$3; }')
mkdir -p ${DESTDIR}/lib/evms/${EVMS_VERSION}
-for x in disk lvm2 dos multipath; do
+for x in bbr bbr_seg bsd disk dos drivelink gpt lvm2 mac md multipath; do
cp /lib/evms/${EVMS_VERSION}/${x}* ${DESTDIR}/lib/evms/${EVMS_VERSION}
done
-for x in dm_mod; do
+for x in dm_mod linear raid0 raid1 raid10 raid5 raid6; do
manual_add_modules ${x}
done
--- initramfs-tools/scripts/local-top/evms 2005-09-19 05:49:09.0
-0700
+++ initramfs-tools/scripts/local-top/evms 2005-11-02 09:31:34.0
-0800
@@ -1,6 +1,6 @@
#!/bin/sh
-PREREQ=lvm
+PREREQ=
prereqs()
{
@@ -16,16 +16,15 @@
esac
evms=${ROOT#/dev/evms/}
-
case ${evms} in
- /dev/root)
- unset evms
- ;;
/*)
exit 0
;;
esac
-
-modprobe -q dm-mod
+unset evms
+
+for module in dm-mod linear raid0 raid1 raid10 raid5 raid6 ; do
+ modprobe -q $module
+done
/sbin/evms_activate
Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not loaded in initrd
reassign #337625 yaird stop no thanks On Sat, 05 Nov 2005, Jonas Smedegaard wrote: Sounds like you had initramfs-tools and not yaird installed at the time of initially installing the kernel. Reassigning to initramfs-tools. no mention of initramfs-tools in initial report. Regenerating initrd with yaird solved the problem. Yes, this has been fixed with most recent version of yaird. then mark it fixed with the new nice Version header. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not loaded in initrd
Processing commands for [EMAIL PROTECTED]: reassign #337625 yaird Bug#337625: linux-image-2.6.14-1-k7: Framebuffer module for NVIDIA card not loaded in initrd Bug reassigned from package `initramfs-tools' to `yaird'. stop no thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336988: yaird: ignoring 'mesh' doesn't allow root device to be found
Package: yaird Version: 0.0.11-11 Followup-For: Bug #336988 *chuckle* 'mesh' is the onboard oldworld SCSI host adapter; my installation happens to be on this, so when I boot 2.6.14-1-powerpc, I have no root filesystem. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-powerpc Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages yaird depends on: ii cpio 2.6-9 GNU cpio -- a program to manage ar ii dash 0.5.2-8 The Debian Almquist Shell ii libc62.3.5-7 GNU C Library: Shared libraries an ii libhtml-template-perl2.6-2 HTML::Template : A module for usin ii libparse-recdescent-perl 1.94.free-1 Generates recursive-descent parser ii perl 5.8.7-7 Larry Wall's Practical Extraction yaird recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335230: More Code also Random, but less :-)
Alle 22:29, giovedì 3 novembre 2005, hai scritto: Progress update: Really nice! System has no lvm2, mdadm or dmsetup installed. I applied your patches too but I think that my system needs more care: # yaird -t yaird error: Don't know how to choose between /dev/mapper/lvm2|sicuro|cache and /dev/evms/lvm2/sicuro/cache for dm-31 (fatal) How should we handle that? -- ESC:wq
Bug#337724: Yaird, grub and d-i should also support dmraid devices.
Package: yaird Version: any Tags: upstream, patch Severity: normal As dbug:335230 this should help bringing to yaird the boot support for dmraid devices. As you all know dmraid is now in debian, should be nice to add support for it also in partman (d-i) udeb providing and in grub, I done it manually so should be possibile to also patch grub-install to handle it. Also d-i should be trivial. CC:ed also maintainers of grub, dm-raid and d-i for seeing their interest in supporting this task and asking this question : Should I fill also bugs for grub and d-i (for yaird I'm like little authorized) ? --- begin yaird only part I know that evms support is unfinished yet, but I got this code working! It actually booted my dmraid system, it seems that my perl skills are growing :-) It is someway dirty and has poor RC checking, but works, at least worked for me. Patch included, diffed from yaird-evms archive from the above dbug page. Feel free to include in upcoming yaird 0.12 :-) -- ESC:wq yaird-dmraid.diff.bz2 Description: BZip2 compressed data
Bug#333052: 2.6.14, udev: unknown symbols for ehci_hcd
On Sat, 2005-11-05 at 19:48 +0100, Pozsar Balazs wrote: On Sat, Nov 05, 2005 at 06:31:04PM +0100, Kay Sievers wrote: I've got these messages several times on the experimental SUSE too, but can't reproduce it so far, even without Rusty's patch to modprobe they have disappeared. See here for the details: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333052 Just to let you know, I've also met this problem (on another distro), and did not know about this bugreport until now. So I've done another workaround: modprobe already parses /proc/modules to check whether the modules needed are already loaded, and this file also shows us the state of the modules, being Loading, Live or Unloading. With my patch, modprobe waits until the needed modules come out of the Loading or Unloading state. Yes, this was going to be my solution. However, we only need to resort to this is locking fails (read-only root filesystem). Rusty. -- A bad analogy is like a leaky screwdriver -- Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323136: linux-2.6: patch from 2.6.13
Hi Lior, Could you give 2.6.14-2 (currently in unstable) a try? All the fixes mentioned in the bug trail should be included in it. Thanks, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328534: Adaptec 2005S Hangs with current experiemental 2.6.13-686-smp kernel
Hi, Could you please check whether 2.6.14-2, which is currently in unstable, still oopses/hangs with your controllers? Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327416: marked as done (CAN-2005-2490/CAN-2005-2492: Two sendmsg() related vulnerabilites)
Your message dated Sat, 5 Nov 2005 21:42:21 -0800 (PST)
with message-id [EMAIL PROTECTED]
and subject line CAN-2005-2490/CAN-2005-2492: Two sendmsg() related
vulnerabilites
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 9 Sep 2005 23:29:08 +
From [EMAIL PROTECTED] Fri Sep 09 16:29:08 2005
Return-path: [EMAIL PROTECTED]
Received: from (vserver151.vserver151.serverflex.de) [193.22.164.111]
by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
id 1EDsIt-0002oA-00; Fri, 09 Sep 2005 16:29:07 -0700
Received: from dsl-084-059-136-208.arcor-ip.net ([84.59.136.208]
helo=localhost.localdomain)
by vserver151.vserver151.serverflex.de with esmtpsa
(TLS-1.0:RSA_AES_256_CBC_SHA:32)
(Exim 4.50)
id 1EDsIo-0007FW-Ph
for [EMAIL PROTECTED]; Sat, 10 Sep 2005 01:29:03 +0200
Received: from jmm by localhost.localdomain with local (Exim 4.52)
id 1EDsJe-0001ps-KU; Sat, 10 Sep 2005 01:29:54 +0200
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Moritz Muehlenhoff [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: CAN-2005-2490/CAN-2005-2492: Two sendmsg() related vulnerabilites
X-Mailer: reportbug 3.17
Date: Sat, 10 Sep 2005 01:29:54 +0200
X-Debbugs-Cc: Debian Security Team [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
X-SA-Exim-Connect-IP: 84.59.136.208
X-SA-Exim-Mail-From: [EMAIL PROTECTED]
X-SA-Exim-Scanned: No (on vserver151.vserver151.serverflex.de); SAEximRunCond
expanded to false
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-11.0 required=4.0 tests=BAYES_00,HAS_PACKAGE,
X_DEBBUGS_CC autolearn=ham version=2.60-bugs.debian.org_2005_01_02
Package: linux-2.6
Severity: important
Tags: security
[Severity important only, as amd64 is not yet officially in the archive]
These patches were posted as part of the stable review cycle on linux-kernel,
they're probably available in git already.
CAN-2005-2490: (local privilege escalation on amd64)
When we copy 32bit -msg_control contents to kernel, we walk the same
userland data twice without sanity checks on the second pass.
Second version of this patch: the original broke with 64-bit arches
running 32-bit-compat-mode executables doing sendmsg() syscalls with
unaligned CMSG data areas
Another thing is that we use kmalloc() to allocate and sock_kfree_s()
to free afterwards; less serious, but also needs fixing.
Patch by Al Viro, David Miller, David Woodhouse
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
include/net/compat.h |2 +-
net/compat.c | 44 ++--
net/socket.c |3 ++-
3 files changed, 29 insertions(+), 20 deletions(-)
Index: linux-2.6.13.y/include/net/compat.h
===
--- linux-2.6.13.y.orig/include/net/compat.h
+++ linux-2.6.13.y/include/net/compat.h
@@ -33,7 +33,7 @@ extern asmlinkage long compat_sys_sendms
extern asmlinkage long compat_sys_recvmsg(int,struct compat_msghdr __user
*,unsigned);
extern asmlinkage long compat_sys_getsockopt(int, int, int, char __user *, int
__user *);
extern int put_cmsg_compat(struct msghdr*, int, int, int, void *);
-extern int cmsghdr_from_user_compat_to_kern(struct msghdr *, unsigned char *,
+extern int cmsghdr_from_user_compat_to_kern(struct msghdr *, struct sock *,
unsigned char *,
int);
#endif /* NET_COMPAT_H */
Index: linux-2.6.13.y/net/compat.c
===
--- linux-2.6.13.y.orig/net/compat.c
+++ linux-2.6.13.y/net/compat.c
@@ -135,13 +135,14 @@ static inline struct compat_cmsghdr __us
* thus placement) of cmsg headers and length are different for
* 32-bit apps. -DaveM
*/
-int cmsghdr_from_user_compat_to_kern(struct msghdr *kmsg,
+int cmsghdr_from_user_compat_to_kern(struct msghdr *kmsg, struct sock *sk,
unsigned char *stackbuf, int stackbuf_size)
{
struct compat_cmsghdr __user *ucmsg;
struct cmsghdr *kcmsg, *kcmsg_base;
compat_size_t ucmlen;
__kernel_size_t kcmlen, tmp;
+ int err = -EFAULT;
kcmlen = 0;
kcmsg_base = kcmsg = (struct cmsghdr *)stackbuf;
@@ -156,6 +157,7 @@ int cmsghdr_from_user_compat_to_kern(str
Bug#337279: yaird: /boot != /tmp
Sven Luther wrote: because i was thinking that the problem happened during boot time, and since there where issues of read-only filesystems. ... This is definitely at creation time. BTW, erik, i am not sure to have the files in non-/tmp will help security-wise, since it will only protect from people looking after the exact yaird behavior, and knowing about the situation. Messages sent to [EMAIL PROTECTED] are not cc'd to me (this isn't aimed at you, Sven; rather the other people who have commented in the BTS). You have to send to [EMAIL PROTECTED] or me directly... Darn you BTS! A lot of the standard /tmp races don't apply to yaird because yaird uses mkdir, not open. Concerns about races w/ tmpreaper are also not an issue, because yaird is run with admin supervision; certainly, if the admin does not notice someone slowing his system so that yaird runs for days so that tmpreaper decides to remove yaird's tmpdir then, well, he deserves what he gets. And, for the record, I (the admin) did not decide to use /boot as a temporary directory. Using TMPDIR is fine, but when its not set, the default should be /tmp, because that's the way Unix programs are supposed to work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333052: 2.6.14, udev: unknown symbols for ehci_hcd
Pozsar Balazs wrote: On Sat, Nov 05, 2005 at 06:31:04PM +0100, Kay Sievers wrote: With my patch, modprobe waits until the needed modules come out of the Loading or Unloading state. For testing I have added it to Debian's module-init-tools 3.2-pre9. Works for me. Regards Harri signature.asc Description: OpenPGP digital signature
Bug#337704: evms root on lvm/md [was Re: bug 336617]
tags 337704 moreinfo stop On Sat, 05 Nov 2005, Paul Traina wrote: You closed this bug, but it didn't fix the additional issues I reported. Please reopen. Paul hurrah for opening an separate bug. Sesse is using plain EVMS root, you seem to use an heavier mix. your patch also seems not to be clean enough yet, because he removes prerequisites only to add them later on. can you please add more info about your setup to your bug report: /etc/fstab, pvscan and /proc/mdstat why is /etc/evms.conf needed? you add lots of evms libs: +for x in bbr bbr_seg bsd disk dos drivelink gpt lvm2 mac md multipath; do thanks for your info. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: evms root on lvm/md [was Re: bug 336617]
Processing commands for [EMAIL PROTECTED]: tags 337704 moreinfo Bug#337704: initramfs-tools: evms root *still* broken -- only part of 336617 resolved! Tags were: patch Tags added: moreinfo stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
