Bug#693371: insserv: Please update insserv.conf to ensure mountall-bootclean is run
Hi Roger,
Package: insserv
Version: 1.14.0-4
Severity: serious
Tags: patch
Justification: Breaks boot
See also:
#677097
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677097
When we added mountall-bootclean to initscripts, I didn't realise
at the time that the dependencies were insufficient, and $local_fs
requires mountall-bootclean to be run, or it can be mis-ordered
and delete /run.
The attached patch fixes up insserv to add mountall-bootclean to
$local_fs. I've included the change to both debian/patches and
to insserv.conf so you can apply whatever you feel best.
Flagged as serious since this does prevent systems from booting.
I'm going to also make the change to sysvinit to add
X-Start-Before: bootmish.sh to mountall_bootclean
but it would be good to have it here as well to make it less
easy to break your system.
Thanks for the patch, I've committed the following, when I make it available
on mentors (this evening) would you be willing to check upload?
Kel
---
Index: debian/changelog
===
--- debian/changelog(revision 1080)
+++ debian/changelog(revision 1081)
@@ -1,3 +1,12 @@
+insserv (1.14.0-5) unstable; urgency=low
+
+ * Add +mountall-bootclean to $local_fs virtual facility definition in
+insserv.conf. (Closes: #693371)
+ * Add test_bootmisc_order test to suite to verify the mountall-bootclean
+dependency works as expected.
+
+ -- Kel Modderman k...@otaku42.de Sun, 18 Nov 2012 11:55:44 +1000
+
insserv (1.14.0-4) unstable; urgency=low
* Provide machine parseable output which may be used by file-rc to calculate
Index: debian/patches/11_debian_conf.patch
===
--- debian/patches/11_debian_conf.patch (revision 1080)
+++ debian/patches/11_debian_conf.patch (revision 1081)
@@ -9,7 +9,7 @@
# All local filesystems are mounted (done during boot phase)
#
-$local_fs boot.localfs +boot.crypto
-+$local_fs +mountall +mountoverflowtmp +umountfs
++$local_fs +mountall +mountall-bootclean +mountoverflowtmp +umountfs
#
# Low level networking (ethernet card)
Index: debian/run-testsuite
===
--- debian/run-testsuite(revision 1080)
+++ debian/run-testsuite(revision 1081)
@@ -2358,7 +2358,61 @@
rm -f ${tmpdir}/rc.conf
}
##
+test_bootmisc_order() {
+echo
+echo info: mountall-bootclean.sh must start before bootmisc.sh
+echo
+initdir_purge
+
+set +C
+cat 'EOF' $insconf
+$local_fs +mountall +mountall-bootclean
+$remote_fs $local_fs
+EOF
+set -C
+
+initdir_purge
+
+insertscript mountall.sh 'EOF'
+### BEGIN INIT INFO
+# Provides: mountall
+# Required-Start:
+# Required-Stop:
+# Default-Start: S
+# Default-Stop:
+### END INIT INFO
+EOF
+
+insertscript mountall-bootclean.sh 'EOF'
+### BEGIN INIT INFO
+# Provides: mountall-bootclean
+# Required-Start:mountall
+# Required-Stop:
+# Default-Start: S
+# Default-Stop:
+### END INIT INFO
+EOF
+
+insertscript bootmisc.sh 'EOF'
+### BEGIN INIT INFO
+# Provides: bootmisc
+# Required-Start:$remote_fs
+# Required-Stop:
+# Default-Start: S
+# Default-Stop:
+### END INIT INFO
+EOF
+
+list_rclinks
+
+check_order S mountall.sh mountall-bootclean.sh
+check_order S mountall-bootclean.sh bootmisc.sh
+
+update_conf
+}
+##
+
test_normal_sequence
test_override_files
test_override_loop
@@ -2401,3 +2455,4 @@
test_undetected_loop # 2 non-fatal tests failing
test_invalid_core_string
test_show_all
+test_bootmisc_order
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670085: insserv: update-rc.d is a dangling symlink
Hi Roger, On 22.04.2012 23:03, Eddy Petrișor wrote: On 22.04.2012 22:58, Eddy Petrișor wrote: Subject: insserv: update-rc.d is a dangling symlink Package: insserv Version: 1.14.0-3 I forgot to add this info: heidi:/home/eddy# ls -l /usr/sbin/update-rc* lrwxrwxrwx 1 root root 29 Sep 22 2009 /usr/sbin/update-rc.d - /usr/sbin/update-rc.d-insserv -rwxr-xr-x 1 root root 16894 Mar 13 09:14 /usr/sbin/update-rc.d.distrib heidi:/home/eddy# dpkg -S /usr/sbin/update-rc.d.distrib diversion by insserv from: /usr/sbin/update-rc.d diversion by insserv to: /usr/sbin/update-rc.d.distrib After trying to reinstall sysv-rc and insserv a few times to no avail, I looked into sysv-rc's postinst and suspected the problem was that the divert will be removed if only /var/run/sysv-rc.upgrade existed, so I manually ran these commands insserv (1.14.0-3) stopped shipping update-rc.d-insserv, since it was almost identical to the update-rc.d shipped by sysv-rc for quite some time now and the update-rc.d diversion should have been removed some time ago. Somehow Eddy's system still contained a diversion, could sysv-rc.postinst perhaps remove this diversion unconditionally? Or should insserv provide a postinst to do only that in your opinion? Thanks, Kel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670085: insserv: update-rc.d is a dangling symlink
reassign 670085 sysv-rc
tags 670085 patch
thanks
This could possibly be protected with a dpkg --compare-versions, the
check_divert function is still present in sysv-rc.postinst so may as well do
this here instead of adding a postinst to insserv.
From ba1746e211413b07d57c6ee4906260cb0fd81305 Mon Sep 17 00:00:00 2001
From: Kel Modderman k...@otaku42.de
Date: Mon, 23 Apr 2012 20:38:40 +1000
Subject: [PATCH] Unconditionally remove diversion of update-rc.d to
update-rc.d-insserv.
---
debian/sysv-rc.postinst |6 ++
1 file changed, 6 insertions(+)
diff --git a/debian/sysv-rc.postinst b/debian/sysv-rc.postinst
index 24243c9..cbc60fb 100644
--- a/debian/sysv-rc.postinst
+++ b/debian/sysv-rc.postinst
@@ -164,6 +164,12 @@ try_to_convert() {
case $1 in
configure)
+ if check_divert status /usr/sbin/update-rc.d \
+ /usr/sbin/update-rc.d-insserv ; then
+ check_divert false /usr/sbin/update-rc.d \
+ /usr/sbin/update-rc.d-insserv
+ fi
+
if dpkg --compare-versions $2 lt 2.88dsf-23; then
rm -f /etc/init.d/.legacy-bootordering
fi
--
1.7.10
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650995: causes dependency loop in boot sequence (according to insserv)
Hi all, Package: console-common Version: 0.7.86 Severity: serious Installation of console-common 0.7.86 has failed in unstable for me with the following insserv error: I'd like to think of it as a console-common error which causes insserv to reject the keymap.sh script header causing dpkg to report an error state :) Setting up console-common (0.7.86) ... Looking for keymap to install: NONE insserv: There is a loop between service checkfs and cryptdisks if started insserv: loop involving service cryptdisks at depth 12 insserv: loop involving service checkroot at depth 11 insserv: There is a loop between service nfs-common and hwclock if started insserv: loop involving service hwclock at depth 12 insserv: There is a loop between service lvm2 and cryptdisks-early if started insserv: loop involving service cryptdisks-early at depth 12 insserv: There is a loop between service checkfs and cryptdisks if started insserv: There is a loop between service nfs-common and hwclock if started insserv: There is a loop between service lvm2 and cryptdisks-early if started insserv: loop involving service mountnfs at depth 8 insserv: loop involving service nfs-common at depth 7 insserv: loop involving service portmap at depth 6 insserv: loop involving service mountall at depth 4 insserv: loop involving service checkfs at depth 3 insserv: loop involving service lvm2 at depth 2 insserv: loop involving service udev at depth 1 insserv: loop involving service mtab at depth 13 insserv: There is a loop between service mountall and checkfs if started insserv: loop involving service keymap at depth 16 insserv: loop involving service hibernate-cleanup at depth 20 insserv: loop involving service networking at depth 22 insserv: loop involving service restorecond at depth 32 insserv: There is a loop between service mountnfs and nfs-common if started insserv: loop involving service alsa-utils at depth 33 insserv: loop involving service ifupdown-clean at depth 34 insserv: loop involving service console-screen at depth 34 insserv: exiting now without changing boot order! update-rc.d: error: insserv rejected the script header dpkg: error processing console-common (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: console-common There is a change in dependency information in the keymap.sh init.d script of console-common 0.7.86 that is not fully articulated in the changelog: diff -Nru console-common-0.7.85/debian/keymap.sh console-common-0.7.86/debian/keymap.sh --- console-common-0.7.85/debian/keymap.sh 2009-11-01 05:41:53.0 +1000 +++ console-common-0.7.86/debian/keymap.sh 2011-12-05 01:05:31.0 +1000 @@ -1,8 +1,8 @@ #!/bin/sh ### BEGIN INIT INFO # Provides: keymap -# Required-Start: mountdevsubfs -# Required-Stop: +# Required-Start: mountdevsubfs $remote_fs +# Required-Stop:$remote_fs # Default-Start:S # Default-Stop: # X-Interactive: true --- checkroot.sh declares a Should-Start depndency on keymap which is a declaration that keymap service should start before checkroot.sh when present, but now keymap is declaring that it only starts once the $remote_fs virtual boot checkpoint is satisfied which is much much later in the boot process. This is an impossible relationship because checkroot.sh is required by other services which must start before $remote_fs is satisfied. I would like to know why this change in dependency was made by the console-common maintainers? Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623003: [Pkg-sysvinit-devel] Bug#623003: initscripts: checkfs fails with already mounted error after lenny to squeeze upgrade
On Sun, 17 Apr 2011 01:12:35 AM Thorben Jändling wrote: Package: initscripts Version: 2.88dsf-13.1 Severity: critical Tags: squeeze Justification: breaks unrelated software After upgrade from lenny to squeeze my system no longer boots. Here is the boot up text: --- Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...[6.221138] input: PC Speaker as /devices/platform/pcspkr/input/input0 [6.291937] AMD Geode RNG detected [7.053147] padlock: VIA PadLock not detected. [7.213202] geode-aes: GEODE AES engine enabled. [7.299985] Error: Driver 'pcspkr' is already registered, aborting... [7.554242] kjournald starting. Commit interval 5 seconds [7.603203] kjournald starting. Commit interval 5 seconds [7.686370] kjournald starting. Commit interval 5 seconds [7.692588] EXT3 FS on sdb3, internal journal [7.697022] EXT3 FS on sdb2, internal journal [7.701965] EXT3-fs: mounted filesystem with ordered data mode. [7.707988] EXT3 FS on sdb5, internal journal [7.712420] EXT3-fs: mounted filesystem with ordered data mode. [7.718384] EXT3-fs: mounted filesystem with ordered data mode. Why are volumes being mounted at this point? What is the output of ls -1 /etc/rcS.d/, and content of /etc/fstab? Is there a custom udev rule in there auto-mounting volumes? Thanks, Kel. done. Activating swap...[8.216609] Adding 497972k swap on /dev/sdb1. Priority:-1 extents:1 across:497972k done. Checking root file system...fsck from util-linux-ng 2.17.2 /: clean, 57717/137360 files, 316504/549360 blocks done. [8.995602] leds_alix2: system is recognized as PC Engines ALIX.2 [9.027061] Registered led device: alix:1 [9.065850] Registered led device: alix:2 Cleaning up ifupdown [9.095594] Registered led device: alix:3 Loading kernel modules...done. Setting up networking Activating lvm and md swap...done. Checking file systems...fsck from util-linux-ng 2.17.2 /dev/sdb2 is mounted. e2fsck: Cannot continue, aborting. /dev/sdb3 is mounted. e2fsck: Cannot continue, aborting. /dev/sdb5 is mounted. e2fsck: Cannot continue, aborting. fsck died with exit status 8 failed (code 8). File system check failed. A log is being saved in /var/log/fsck/checkfs if that location is writable. Please repair the file system manually. ... failed! A maintenance shell will now be started. CONTROL-D will terminate this shell and resume system boot. ... (warning). Give root password for maintenance (or type Control-D to continue): [ 14.297635] usb 1-2: new high speed USB device using ehci_hcd and address 2 [ 14.435250] usb 1-2: New USB device found, idVendor=1058, idProduct=1003 [ 14.441984] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 14.449147] usb 1-2: Product: External HDD [ 14.453634] usb 1-2: Manufacturer: Western Digital The /var/log/fsck/checkfs files does not say anything more then the error given here. With ctrl+d the system boots normally, however this is a headless system, and I rather not have to keep attaching a serial cable.. Thank you Thorben -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i586) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages initscripts depends on: ii coreutils 8.5-1GNU core utilities ii debianutils 3.4 Miscellaneous utilities specific t ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii mount 2.17.2-9 Tools for mounting and manipulatin ii sysv-rc 2.88dsf-13.1 System-V-like runlevel change mech ii sysvinit-utils 2.88dsf-13.1 System-V-like utilities Versions of packages initscripts recommends: ii e2fsprogs 1.41.12-2 ext2/ext3/ext4 file system utiliti ii psmisc22.11-1utilities that use the proc file s initscripts suggests no packages. -- no debconf information ___ Pkg-sysvinit-devel mailing list pkg-sysvinit-de...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618719: FTBFS on kfreebsd: ../src/utils/pcsc_funcs.o: undefined reference to symbol 'dlsym@@GLIBC_2.3'
On Mon, 11 Apr 2011 09:03:49 AM Michael Biebl wrote: Am 10.04.2011 20:48, schrieb Guillem Jover: On Sat, 2011-03-19 at 22:17:38 +1000, Kel Modderman wrote: Looks like the build failure is due to 08_pcsc_dynamic.patch We could drop the patch or we could update the patch to add '-ldl' to LIBS in build system. I'm undecided, and atm extremely burnt out with real life work, so am looking for some advice. 08_pcsc_dynamic.patch is untested by anyone, not very beautiful looking. Also it seems up to me to push to upstream, which I'm not totally confident about. As I mentioned in bug 612842 [0] (I just resent my reply now which never arrived), I think this patch in itself is a bad idea, so I'd say just drop it. Afaics, Ludovic is not going to change his mind, regarding this matter. Given Guillems' input, I'd also vote for disabling pcscd support completely. I'm tempted to do that, but would hate to think that could make potential users of wpasupplicant's ability to interface with pcsc have a much harder time on Debian. What got us here is mostly due to pcsc maintainers unwillingness to move shared lib to /lib, and using an inappropriately strong relationship between related packages. I've been running wpasupplicant 0.7.1 for weeks now and for my purposes (wpa(2) psk) it was rock solid. Kel, would you mind uploading it to unstable? The kfreebsd build failure was the ony real blocker afaics. I can sponsor the upload as usual. Thanks for the continued support, the source package is at: http://mentors.debian.net/debian/pool/main/w/wpasupplicant/wpasupplicant_0.7.3-2.dsc Changes: wpasupplicant (0.7.3-2) unstable; urgency=low . * Upload to unstable. * Remove 08_pcsc_dynamic.patch and forget the idea about dynamically loading libpcsc. (Closes: #618719) * Build with support for pcsc and link with libpcsc. Reopens #531592 and #612715. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618719: FTBFS on kfreebsd: ../src/utils/pcsc_funcs.o: undefined reference to symbol 'dlsym@@GLIBC_2.3'
On Friday 18 March 2011 07:46:23 Michael Biebl wrote: Package: wpasupplicant Version: 0.7.3-1 Severity: serious Hi, wpasupplicant ftbfs on kfree-bsd: /usr/bin/ld: ../src/utils/pcsc_funcs.o: undefined reference to symbol 'dlsym@@GLIBC_2.3' /usr/bin/ld: note: 'dlsym@@GLIBC_2.3' is defined in DSO //lib/libdl.so.2 so try adding it to the linker command line //lib/libdl.so.2: could not read symbols: Invalid operation collect2: ld returned 1 exit status make[2]: *** [wpa_supplicant] Error 1 Complete build log is at https://buildd.debian.org/fetch.cgi?pkg=wpasupplicantarch=kfreebsd-amd64ver=0.7.3-1stamp=1299705072file=logas=raw Looks like the build failure is due to 08_pcsc_dynamic.patch We could drop the patch or we could update the patch to add '-ldl' to LIBS in build system. I'm undecided, and atm extremely burnt out with real life work, so am looking for some advice. 08_pcsc_dynamic.patch is untested by anyone, not very beautiful looking. Also it seems up to me to push to upstream, which I'm not totally confident about. Further to the problem, upstream build system seems not to add '-ldl' to LIBS for BSD configurations. For example: $ grep -A1 -B1 '\-ldl' wpa_supplicant/Makefile ifndef CONFIG_DRIVER_BSD LIBS += -ldl endif -- ifneq ($(CONFIG_L2_PACKET), freebsd) LIBS += -ldl endif I do not know why this is the case, and I think this will come up if I was to push this patch upstream. There are multiple places in which this linker flag gets added to LIBS for non BSD configurations which is why we did not witness this build failure on linux before now. Attached is what I drafted up in working copy of pkg-wpa SVN in response to the FTBFS notifications some days ago, comments about how to proceed are very welcome. I know Stephan's inclination is to drop the patch and let someone with the hardware and know how fix up the problem in the future. Thanks, Kel. --- Index: debian/patches/08_pcsc_dynamic.patch === --- debian/patches/08_pcsc_dynamic.patch(revision 1571) +++ debian/patches/08_pcsc_dynamic.patch(working copy) @@ -42,12 +42,13 @@ #undef SCARD_PCI_T0 --- a/wpa_supplicant/Makefile +++ b/wpa_supplicant/Makefile -@@ -691,9 +691,13 @@ ifdef CONFIG_NATIVE_WINDOWS +@@ -691,9 +691,14 @@ ifdef CONFIG_NATIVE_WINDOWS #dynamic symbol loading that is now used in pcsc_funcs.c #LIBS += -lwinscard else +ifeq ($(CONFIG_PCSC), dyn) +CFLAGS += -DPCSC_DYNAMIC ++LIBS += -ldl +else LIBS += $(shell pkg-config --libs libpcsclite) endif Index: debian/changelog === --- debian/changelog(revision 1573) +++ debian/changelog(working copy) @@ -1,3 +1,10 @@ +wpasupplicant (0.7.3-2) UNRELEASED; urgency=low + + * Modify debian/patches/08_pcsc_dynamic.patch to add dl to LIBS to link +with. + + -- Kel Modderman k...@otaku42.de Fri, 11 Mar 2011 23:37:07 +1000 + wpasupplicant (0.7.3-1) experimental; urgency=low [ Kel Modderman ] --- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595431: Aborting fsck aborts all scripts in rcS.d
On Saturday 04 September 2010 06:39:49 Goswin von Brederlow wrote:
Package: insserv
Version: 1.14.0-2
Severity: critical
Hi,
during boot /etc/rcS.d/S13checkfs.sh starts a filesystem check (hasn't
been checked for 197 days) as well as giving some errors for missing
devices. Since I didn't want to wait for the fsck before fixing the
missing devices I aborted the check with crlt-c. This resulted in the
fsck to be aborted but then also skipped all further rcS.d scripts
saying:
Running scripts in rcS.d/ took 41 seconds.
INIT: Entering runlevel: 2
Given that filesystem weren't mounted or anything that didn't work out
well leaving the system unusable.
This is a serious regressions from before insserv. The old behaviour
was to display a message asking for the root password to get a shell
or ctrl-D to continue booting.
How does changing /etc/init.d/rc with the below patch modify behaviour?
Thanks, Kel.
--- rc~
+++ rc
@@ -43,7 +43,7 @@ on_exit() {
trap on_exit EXIT # Enable emergency handler
# Ignore CTRL-C only in this shell, so we can interrupt subprocesses.
-trap : INT QUIT TSTP
+trap INT QUIT TSTP
# Set onlcr to avoid staircase effect.
stty onlcr 01
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580564: kdb: Hangs under certain circumstances during boot with CONCURRENCY enabled
tags 580564 pending thanks On Friday 07 May 2010 16:22:53 Petter Reinholdtsen wrote: severity 580564 grave thanks [Michael Guntsche] For other packages it seems to work ok (udev). Sure, but udev was already listed in insserv.conf. I tried that and it works here as well. KBD starts on its own again. Good. I've been able to reproduce the problem with a simple test case, which is commited to svn and will make sure we do not upload with such problem again. The easiest way to see that insserv fail to detect the X-Interactive: true flag is to look in /etc/init.d/.depend.*, where the INTERACTIVE setting is wrong. I've reported the problem upstream, and hope to have a fix available soon. Raising severity to keep the broken insserv out of testing. I committed 30_interactive_regexp_match_fix.patch which should fix the issue. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573048: hostapd incompatible with 2.6.33 kernel
severity 573048 important thanks On Tuesday 09 March 2010 00:17:55 Daniel wrote: Package: hostapd Version: 1:0.6.10-2 Severity: grave Justification: renders package unusable Bull. Running kernel 2.6.32.8 together with the above hostapd version worked just fine That's why the submitted severity is bull. but after I've updated the kernel from 2.6.32.8 to 2.6.33 (both from kernel.org) hostapd does not start any more. That's a problem that could be fixed, but I aint looked into it myself. Thanks for the extra info. Thanks, Kel. Output of /etc/init.d/hostapd: Starting advanced IEEE 802.11 management: hostapdioctl[SIOCGIWRANGE]: Invalid argument ioctl[SIOCSIWRTS]: Invalid argument rmdir[ctrl_interface]: No such file or directory (warning). Manually starting hostapd using the cmd hostapd -t -P /var/run/hostapd.pid -dd /etc/hostapd/hostapd.conf reports: 1267968202.414304: Configuration file: /etc/hostapd/hostapd.conf 1267968202.416436: ctrl_interface_group=0 1267968202.445810: Opening raw packet socket for ifindex 0 1267968202.445896: BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits) ioctl[SIOCGIWRANGE]: Invalid argument 1267968202.446733: nl80211: Added 802.11b mode based on 802.11g information 1267968202.446768: Allowed channel: mode=1 chan=1 freq=2412 MHz max_tx_power=20 dBm 1267968202.446867: Allowed channel: mode=1 chan=2 freq=2417 MHz max_tx_power=20 dBm 1267968202.446900: Allowed channel: mode=1 chan=3 freq=2422 MHz max_tx_power=20 dBm 1267968202.446929: Allowed channel: mode=1 chan=4 freq=2427 MHz max_tx_power=20 dBm 1267968202.446959: Allowed channel: mode=1 chan=5 freq=2432 MHz max_tx_power=20 dBm 1267968202.446988: Allowed channel: mode=1 chan=6 freq=2437 MHz max_tx_power=20 dBm 1267968202.447016: Allowed channel: mode=1 chan=7 freq=2442 MHz max_tx_power=20 dBm 1267968202.447046: Allowed channel: mode=1 chan=8 freq=2447 MHz max_tx_power=20 dBm 1267968202.447075: Allowed channel: mode=1 chan=9 freq=2452 MHz max_tx_power=20 dBm 1267968202.447103: Allowed channel: mode=1 chan=10 freq=2457 MHz max_tx_power=20 dBm 1267968202.447133: Allowed channel: mode=1 chan=11 freq=2462 MHz max_tx_power=20 dBm 1267968202.447163: Allowed channel: mode=0 chan=1 freq=2412 MHz max_tx_power=20 dBm 1267968202.447192: Allowed channel: mode=0 chan=2 freq=2417 MHz max_tx_power=20 dBm 1267968202.447221: Allowed channel: mode=0 chan=3 freq=2422 MHz max_tx_power=20 dBm 1267968202.447250: Allowed channel: mode=0 chan=4 freq=2427 MHz max_tx_power=20 dBm 1267968202.447278: Allowed channel: mode=0 chan=5 freq=2432 MHz max_tx_power=20 dBm 1267968202.447307: Allowed channel: mode=0 chan=6 freq=2437 MHz max_tx_power=20 dBm 1267968202.447336: Allowed channel: mode=0 chan=7 freq=2442 MHz max_tx_power=20 dBm 1267968202.447365: Allowed channel: mode=0 chan=8 freq=2447 MHz max_tx_power=20 dBm 1267968202.447393: Allowed channel: mode=0 chan=9 freq=2452 MHz max_tx_power=20 dBm 1267968202.447422: Allowed channel: mode=0 chan=10 freq=2457 MHz max_tx_power=20 dBm 1267968202.447451: Allowed channel: mode=0 chan=11 freq=2462 MHz max_tx_power=20 dBm 1267968202.447587: RATE[0] rate=10 flags=0x2 1267968202.447619: RATE[1] rate=20 flags=0x6 1267968202.447644: RATE[2] rate=55 flags=0x6 1267968202.447668: RATE[3] rate=110 flags=0x6 1267968202.447694: RATE[4] rate=60 flags=0x0 1267968202.447718: RATE[5] rate=90 flags=0x0 1267968202.447742: RATE[6] rate=120 flags=0x0 1267968202.447767: RATE[7] rate=180 flags=0x0 1267968202.447791: RATE[8] rate=240 flags=0x0 1267968202.447816: RATE[9] rate=360 flags=0x0 1267968202.447840: RATE[10] rate=480 flags=0x0 1267968202.447865: RATE[11] rate=540 flags=0x0 1267968202.447890: Passive scanning not supported 1267968202.447913: Mode: IEEE 802.11g Channel: 6 Frequency: 2437 MHz ioctl[SIOCSIWRTS]: Invalid argument 1267968202.460912: Could not set RTS threshold for kernel driver 1267968202.460947: wlan0: Unable to setup interface. rmdir[ctrl_interface]: No such file or directory The last error msg rmdir[...] does not appear in case I run mkdir /var/run/hostapd before starting hostapd, nevertheless hostapd does not start: r...@router:~# mkdir /var/run/hostapd r...@router:~# hostapd -t -P /var/run/hostapd.pid -dd /etc/hostapd/hostapd.conf 1267968532.506341: Configuration file: /etc/hostapd/hostapd.conf 1267968532.508508: ctrl_interface_group=0 1267968532.537844: Opening raw packet socket for ifindex 0 1267968532.537929: BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits) ioctl[SIOCGIWRANGE]: Invalid argument 1267968532.538839: nl80211: Added 802.11b mode based on 802.11g information 1267968532.538877: Allowed channel: mode=1 chan=1 freq=2412 MHz max_tx_power=20 dBm 1267968532.538909: Allowed channel: mode=1 chan=2 freq=2417 MHz max_tx_power=20 dBm 1267968532.538939: Allowed channel: mode=1 chan=3 freq=2422 MHz max_tx_power=20 dBm 1267968532.538969: Allowed channel: mode=1
Bug#524314: [Pkg-sysvinit-devel] Bug#524314: [sysv-rc] Sysv-rc always reports that actions failed
tags 524314 moreinfo thanks On Thursday 16 April 2009 18:04:27 Carlo Aquilini wrote: Package: sysv-rc Version: 2.86.ds1-61 Severity: critical Sysv-rc always reports that actions failed even if they are successfully accomplished. This breaks reconfiguration of every package that call invoke-rc.d during upgrade, remove, purge, install or reinstall. You need to provide actual data to support this claim, such as commands which reproduce the problem described. Thanks, Kel.
Bug#524314: [Pkg-sysvinit-devel] Bug#524314: [sysv-rc] Sysv-rc always reports that actions failed
On Thursday 16 April 2009 18:42:39 Carlo Aquilini wrote: Hello, I discovered it during acpid upgrade that failed claiming that it couldn't stop and restart the service (solved by momentarily renaming /etc/init.d/acpid and then upgrading). The output of the upgrade should be provided. One example could be freepops: $ ps aux | grep freepops carlo 8052 0.0 0.0 3212 752 pts/0S+ 10:28 0:00 grep freepops nobody 15771 0.4 0.3 27936 7448 ?S09:48 0:11 /usr/bin/freepopsd -p 110 -n -s nobody.nogroup $ sudo invoke-rc.d freepops stop * Stopping freepops daemon freepopsd [ OK ] invoke-rc.d: initscript freepops, action stop failed. $ ps aux | grep freepops carlo11644 0.0 0.0 3212 752 pts/0R+ 10:34 0:00 grep freepops $ sudo invoke-rc.d freepops start * Starting freepops daemon freepopsd [ OK ] invoke-rc.d: initscript freepops, action start failed. $ ps aux | grep freepops nobody 12303 0.0 0.0 5980 1708 ?S10:35 0:00 /usr/bin/freepopsd -p 110 -n -s nobody.nogroup carlo12690 0.0 0.0 3212 752 pts/0R+ 10:36 0:00 grep freepops So that package freepops is stopped and started successfully, but invoke-rc.d claims that the actions failed. This happens with every service in /etc/init.d/ I installed the freepops package to investigate, and then run the following commands: r...@nomad:/home/kelmo# invoke-rc.d freepops start Starting freepops daemon: freepopsd. r...@nomad:/home/kelmo# invoke-rc.d freepops stop Stopping freepops daemon: freepopsd. r...@nomad:/home/kelmo# The output look a little different to yours, and I cannot reproduce the failure. Thanks, Kel.
Bug#524314: [Pkg-sysvinit-devel] Bug#524314: [sysv-rc] Sysv-rc always reports that actions failed
reassign 524314 splashy retitle 524314 splashy causes init scripts to exit with error tags 524314 - moreinfo thanks On Thursday 16 April 2009 19:50:38 Carlo Aquilini wrote: Il giorno gio, 16/04/2009 alle 19.18 +1000, Kel Modderman ha scritto: I installed the freepops package to investigate, and then run the following commands: r...@nomad:/home/kelmo# invoke-rc.d freepops start Starting freepops daemon: freepopsd. r...@nomad:/home/kelmo# invoke-rc.d freepops stop Stopping freepops daemon: freepopsd. r...@nomad:/home/kelmo# The output look a little different to yours, and I cannot reproduce the failure. Thanks, Kel. Looking to your output (without the [OK]) I realized which is the problem...splashy. Purging splashy the problem is gone and the upgrade is perfect. This information needs to be on the bug report, CC'ing. Please can you reassign this bug to splashy? I can't do it. Ok. Thanks, Kel.
Bug#509484: [pkg-wpa-devel] Bug#509484: wpasupplicant prevent kpowersave kde4.2 powersave to suspend
On Tuesday 23 December 2008 05:25:32 valette wrote: Package: wpasupplicant Version: 0.6.6-1 Severity: critical Justification: breaks unrelated software Which? Duplicate of #508526 ? Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509484: [pkg-wpa-devel] Bug#509484: wpasupplicant prevent kpowersave kde4.2 powersave to suspend
severity 509484 important thanks On Tuesday 23 December 2008 07:33:21 Eric Valette wrote: Kel Modderman wrote: On Tuesday 23 December 2008 05:25:32 valette wrote: Package: wpasupplicant Version: 0.6.6-1 Severity: critical Justification: breaks unrelated software Which? Kpowersave 5suspend to ram) and any suspend software using pm-suspend(e.g KDE4.2 power management widget for example also). The chosen severity seems very high to me, this problem causes an error case which prevents the actions which make software suspend from proceeding; it doesn't modify, or even break, any part of the suspend actions. Duplicate of #508526 ? Yes. Strange I looked at similar bug before submitting it. Must have overlooked it Ok. The patch from 508526 is committed to package Vcs. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504696: ndiswrapper-source: longs ESSIDs can expose security vulnerability
Package: ndiswrapper-source
Version: 1.53-1
Severity: grave
Tags: security patch
Justification: user security hole
From [0]:
Anders Kaseorg discovered that ndiswrapper did not correctly handle long
ESSIDs. For a system using ndiswrapper, a physically near-by attacker could
generate specially crafted wireless network traffic and execute arbitrary
code with root privileges. (CVE-2008-4395 [1])
Attached is the diff contrinuted by Anders Kaseorg to [2].
[0] http://www.ubuntu.com/usn/usn-662-1
[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4395
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/275860
Thanks, Kel.
---
diff --git a/ubuntu/ndiswrapper/iw_ndis.c b/ubuntu/ndiswrapper/iw_ndis.c
index b114ef6..01d3751 100644
--- a/ubuntu/ndiswrapper/iw_ndis.c
+++ b/ubuntu/ndiswrapper/iw_ndis.c
@@ -47,12 +47,7 @@ int set_essid(struct ndis_device *wnd, const char *ssid, int
ssid_len)
req.length = ssid_len;
if (ssid_len)
memcpy(req.essid, ssid, ssid_len);
- DBG_BLOCK(2) {
- char buf[NDIS_ESSID_MAX_SIZE+1];
- memcpy(buf, ssid, ssid_len);
- buf[ssid_len] = 0;
- TRACE2(ssid = '%s', buf);
- }
+ TRACE2(ssid = '%.*s', ssid_len, ssid);
res = mp_set(wnd, OID_802_11_SSID, req, sizeof(req));
if (res) {
@@ -125,7 +120,6 @@ static int iw_get_essid(struct net_device *dev, struct
iw_request_info *info,
EXIT2(return -EOPNOTSUPP);
}
memcpy(extra, req.essid, req.length);
- extra[req.length] = 0;
if (req.length 0)
wrqu-essid.flags = 1;
else
@@ -1000,7 +994,7 @@ static int iw_set_nick(struct net_device *dev, struct
iw_request_info *info,
if (wrqu-data.length IW_ESSID_MAX_SIZE || wrqu-data.length = 0)
return -EINVAL;
- memset(wnd-nick, 0, sizeof(wnd-nick));
+ wnd-nick_len = wrqu-data.length;
memcpy(wnd-nick, extra, wrqu-data.length);
return 0;
}
@@ -1010,7 +1004,7 @@ static int iw_get_nick(struct net_device *dev, struct
iw_request_info *info,
{
struct ndis_device *wnd = netdev_priv(dev);
- wrqu-data.length = strlen(wnd-nick);
+ wrqu-data.length = wnd-nick_len;
memcpy(extra, wnd-nick, wrqu-data.length);
return 0;
}
diff --git a/ubuntu/ndiswrapper/ndis.h b/ubuntu/ndiswrapper/ndis.h
index 27ba99e..65d6b0b 100644
--- a/ubuntu/ndiswrapper/ndis.h
+++ b/ubuntu/ndiswrapper/ndis.h
@@ -878,6 +878,7 @@ struct ndis_device {
unsigned long scan_timestamp;
struct encr_info encr_info;
char nick[IW_ESSID_MAX_SIZE];
+ size_t nick_len;
struct ndis_essid essid;
struct auth_encr_capa capa;
enum ndis_infrastructure_mode infrastructure_mode;
diff --git a/ubuntu/ndiswrapper/proc.c b/ubuntu/ndiswrapper/proc.c
index fd5f433..6feff23 100644
--- a/ubuntu/ndiswrapper/proc.c
+++ b/ubuntu/ndiswrapper/proc.c
@@ -97,10 +97,8 @@ static int procfs_read_ndis_encr(char *page, char **start,
off_t off,
p += sprintf(p, \n);
res = mp_query(wnd, OID_802_11_SSID, essid, sizeof(essid));
- if (!res) {
- essid.essid[essid.length] = '\0';
- p += sprintf(p, essid=%s\n, essid.essid);
- }
+ if (!res)
+ p += sprintf(p, essid=%.*s\n, essid.length, essid.essid);
res = mp_query_int(wnd, OID_802_11_ENCRYPTION_STATUS, encr_status);
if (!res) {
typeof(wnd-encr_info.keys[0]) tx_key;
diff --git a/ubuntu/ndiswrapper/wrapndis.c b/ubuntu/ndiswrapper/wrapndis.c
index f6e5d46..35ef1cd 100644
--- a/ubuntu/ndiswrapper/wrapndis.c
+++ b/ubuntu/ndiswrapper/wrapndis.c
@@ -2028,7 +2028,7 @@ static wstdcall NTSTATUS NdisAddDevice(struct
driver_object *drv_obj,
wnd-attributes = 0;
wnd-dma_map_count = 0;
wnd-dma_map_addr = NULL;
- wnd-nick[0] = 0;
+ wnd-nick_len = 0;
init_timer(wnd-hangcheck_timer);
wnd-scan_timestamp = 0;
init_timer(wnd-iw_stats_timer);
---
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504696: ndiswrapper-source: longs ESSIDs can expose security vulnerability
Attached is debdiff, have uploaded a package to mentors.debian.net:
http://mentors.debian.net/debian/pool/main/n/ndiswrapper/ndiswrapper_1.53-2.dsc
---
diff -u ndiswrapper-1.53/debian/changelog ndiswrapper-1.53/debian/changelog
--- ndiswrapper-1.53/debian/changelog
+++ ndiswrapper-1.53/debian/changelog
@@ -1,3 +1,11 @@
+ndiswrapper (1.53-2) unstable; urgency=high
+
+ * Add debian/patches/CVE-2008-4395.patch to fix a vulnerability in handling
+of long ESSIDs which allows execution of code as root via remote attacker.
+(Closes: #504696)
+
+ -- Kel Modderman [EMAIL PROTECTED] Thu, 06 Nov 2008 21:06:38 +1000
+
ndiswrapper (1.53-1) unstable; urgency=low
[ Kel Modderman ]
diff -u ndiswrapper-1.53/debian/patches/series
ndiswrapper-1.53/debian/patches/series
--- ndiswrapper-1.53/debian/patches/series
+++ ndiswrapper-1.53/debian/patches/series
@@ -1,0 +2 @@
+CVE-2008-4395.patch
only in patch2:
unchanged:
--- ndiswrapper-1.53.orig/debian/patches/CVE-2008-4395.patch
+++ ndiswrapper-1.53/debian/patches/CVE-2008-4395.patch
@@ -0,0 +1,85 @@
+Anders Kaseorg discovered that ndiswrapper did not correctly handle long
+ESSIDs. For a system using ndiswrapper, a physically near-by attacker
+could generate specially crafted wireless network traffic and execute
+arbitrary code with root privileges. (CVE-2008-4395)
+
+https://bugs.launchpad.net/ubuntu/+source/linux/+bug/275860
+---
+--- a/driver/iw_ndis.c
b/driver/iw_ndis.c
+@@ -47,12 +47,7 @@ int set_essid(struct ndis_device *wnd, c
+ req.length = ssid_len;
+ if (ssid_len)
+ memcpy(req.essid, ssid, ssid_len);
+- DBG_BLOCK(2) {
+- char buf[NDIS_ESSID_MAX_SIZE+1];
+- memcpy(buf, ssid, ssid_len);
+- buf[ssid_len] = 0;
+- TRACE2(ssid = '%s', buf);
+- }
++ TRACE2(ssid = '%.*s', ssid_len, ssid);
+
+ res = mp_set(wnd, OID_802_11_SSID, req, sizeof(req));
+ if (res) {
+@@ -125,7 +120,6 @@ static int iw_get_essid(struct net_devic
+ EXIT2(return -EOPNOTSUPP);
+ }
+ memcpy(extra, req.essid, req.length);
+- extra[req.length] = 0;
+ if (req.length 0)
+ wrqu-essid.flags = 1;
+ else
+@@ -1000,7 +994,7 @@ static int iw_set_nick(struct net_device
+
+ if (wrqu-data.length IW_ESSID_MAX_SIZE || wrqu-data.length = 0)
+ return -EINVAL;
+- memset(wnd-nick, 0, sizeof(wnd-nick));
++ wnd-nick_len = wrqu-data.length;
+ memcpy(wnd-nick, extra, wrqu-data.length);
+ return 0;
+ }
+@@ -1010,7 +1004,7 @@ static int iw_get_nick(struct net_device
+ {
+ struct ndis_device *wnd = netdev_priv(dev);
+
+- wrqu-data.length = strlen(wnd-nick);
++ wrqu-data.length = wnd-nick_len;
+ memcpy(extra, wnd-nick, wrqu-data.length);
+ return 0;
+ }
+--- a/driver/ndis.h
b/driver/ndis.h
+@@ -878,6 +878,7 @@ struct ndis_device {
+ unsigned long scan_timestamp;
+ struct encr_info encr_info;
+ char nick[IW_ESSID_MAX_SIZE];
++ size_t nick_len;
+ struct ndis_essid essid;
+ struct auth_encr_capa capa;
+ enum ndis_infrastructure_mode infrastructure_mode;
+--- a/driver/proc.c
b/driver/proc.c
+@@ -97,10 +97,8 @@ static int procfs_read_ndis_encr(char *p
+ p += sprintf(p, \n);
+
+ res = mp_query(wnd, OID_802_11_SSID, essid, sizeof(essid));
+- if (!res) {
+- essid.essid[essid.length] = '\0';
+- p += sprintf(p, essid=%s\n, essid.essid);
+- }
++ if (!res)
++ p += sprintf(p, essid=%.*s\n, essid.length, essid.essid);
+ res = mp_query_int(wnd, OID_802_11_ENCRYPTION_STATUS, encr_status);
+ if (!res) {
+ typeof(wnd-encr_info.keys[0]) tx_key;
+--- a/driver/wrapndis.c
b/driver/wrapndis.c
+@@ -2028,7 +2028,7 @@ static wstdcall NTSTATUS NdisAddDevice(s
+ wnd-attributes = 0;
+ wnd-dma_map_count = 0;
+ wnd-dma_map_addr = NULL;
+- wnd-nick[0] = 0;
++ wnd-nick_len = 0;
+ init_timer(wnd-hangcheck_timer);
+ wnd-scan_timestamp = 0;
+ init_timer(wnd-iw_stats_timer);
---
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485769: [pkg-wpa-devel] Bug#485769: wpasupplicant crashes: not with 32bit kernel
severity 485769 important thanks On Sunday 24 August 2008 23:50:05 Stefan Fritsch wrote: Hrm. It works with linux-image-2.6.25-2-686. Maybe the severity is not grave after all. But wpasupplicant should not crash. I cannot reproduce the problem, neither can my peer. Also have little idea of what can be wrong. Downgrading the severity as it seem to work for many people. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494514: insserv: Test suite fail on alpha
Hi Petter and Steve,
On Monday 18 August 2008 16:46:08 Petter Reinholdtsen wrote:
[Steve Langasek]
In this case, NFS...
Right. So ext3 and NFS should be ok. :)
I can try against a different filesystem tomorrow if you like.
If you happen to know what file system is used on the autobuilder, or
if ext2/ext3 is not the default file system on alpha, it would be
useful to have a test with those file systems as well. If not, it
will be a shot in the dark, and I have no idea what file system to
suggest.
I think insserv can handle this situation without disabling optimisations, the
problem seems to concern the use of an underterministic directory sequence,
as returned by a while readdir() loop, when scanning the init.d/ directory to
load LSB init info.
The fact that the problem was discovered with a symlink test, is I think
interesting, but not neccessarily an indication of some lower level problem
with kernel / filesystem interaction. The problem can be reproduced with a more
simple test too:
---
test_deterministic_order() {
echo
echo info: test two or more initscripts providing same facility, making sure
echo info: that the first script can be registered with insserv, but others
fail.
echo
initdir_purge
addscript abc 'EOF' || true
### BEGIN INIT INFO
# Provides: service
# Required-Start:
# Required-Stop:
# Default-Start: S
# Default-Stop:
### END INIT INFO
EOF
addscript xyz 'EOF' || true
### BEGIN INIT INFO
# Provides: service
# Required-Start:
# Required-Stop:
# Default-Start: S
# Default-Stop:
### END INIT INFO
EOF
addscript hjk 'EOF' || true
### BEGIN INIT INFO
# Provides: service
# Required-Start:
# Required-Stop:
# Default-Start: S
# Default-Stop:
### END INIT INFO
EOF
insserv_reg xyz || true
insserv_reg hjk || true
insserv_reg abc || true
list_rclinks
check_script_present S xyz
check_script_not_present S abc
check_script_not_present S hjk
}
---
The above test will always fail, but differently when run on different
filesystems
(eg. ext3 vs tmpfs). It seems the information that readdir(3) returns from a
filesystem is not always the same.
insserv could defend against this behaviour, by ensuring that the script being
registered is parsed first, followed by all other scripts. I've put together a
hack to do just that, it is attached. WIll commit it to the packaging SVN with
test case for further discussions.
Thanks, Kel.
---
--- a/insserv.c
+++ b/insserv.c
@@ -2238,6 +2238,7 @@
boolean del = false;
boolean defaults = false;
boolean ignore = false;
+boolean loadarg = argc;
myname = basename(*argv);
@@ -2490,17 +2491,45 @@
/*
* Scan now all scripts found in the init.d/ directory
*/
-while ((d = readdir(initdir)) != (struct dirent*)0) {
- const boolean isarg = chkfor(d-d_name, argv, argc);
+for (;;) {
service_t * service = (service_t*)0;
char * token;
char * begin = (char*)0;/* hold start pointer of strings
handled by strsep() */
boolean hard = false;
+ boolean isarg = false;
uchar lsb = 0;
#if defined(DEBUG) (DEBUG 0)
int nobug = 0;
#endif
+ if ((d = readdir(initdir)) == (struct dirent*)0) {
+ /*
+* If first script in argument list was loaded in advance, then
+* rewind the init.d/ directory stream and attempt to load all
+* other scripts.
+*/
+ if (loadarg) {
+ loadarg = false;
+ rewinddir(initdir);
+ continue;
+ }
+ break;
+ }
+
+ isarg = chkfor(d-d_name, argv, argc);
+
+ /*
+* Load first script in argument list before all other scripts. This
+* avoids problems with loading services in underterministic sequence
+* returned by readdir(3).
+*/
+ if (loadarg !isarg)
+ continue;
+ else if (loadarg isarg (curr_argc != 0))
+ continue;
+ else if (!loadarg isarg (curr_argc == 0))
+ continue;
+
if (*d-d_name == '.')
continue;
errno = 0;
---
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494166: madwifi-source: HAL ABI mismatch with 0.9.4+r3772.20080716-1
severity 494166 important thanks On Sunday 10 August 2008 22:11:37 Kel Modderman wrote: On Friday 08 August 2008 01:08:29 Luc Begault wrote: Package: madwifi-source Version: 1:0.9.4+r3772.20080716-1 Severity: grave Justification: renders package unusable After an upgrade to 2.6.26-1, I tried to rebuild the madwifi package against new headers, when modprobing ath_pci, I have this error in dmesg: MadWifi: HAL ABI mismatch; driver expects 0x8052700, HAL reports 0x6090700 and the wifi card can't be used. Regards. Paste the exact output from the shell please. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481752: [Pkg-spca5xx-devel] Bug#481752: Cannot install on a custom kernel
tags 481752 wishlist thanks On Sunday 18 May 2008 21:46:41 Jonny Lamb wrote: Package: gspca-source Version: 01.00.20-1 Severity: grave Justification: Makes package uninstallable gspca-source is installable just fine ;-) Sarcasm aside, I partially agree with you, but do not agree with the severity considering the justification given. My reasoning is below. Hi, I just tried installing the gspca kernel module using module-assistant. I use a custom kernel, downloaded straight from kernel.org, compiled and installed myself, and because the kernel module package *depends* on a kernel, the package installation fails for me: dpkg -Ei /usr/src/gspca-modules-2.6.24.2_01.00.20-1_i386.deb Selecting previously deselected package gspca-modules-2.6.24.2. (Reading database ... 178712 files and directories currently installed.) Unpacking gspca-modules-2.6.24.2 (from .../gspca-modules-2.6.24.2_01.00.20-1_i386.deb) ... dpkg: dependency problems prevent configuration of gspca-modules-2.6.24.2: gspca-modules-2.6.24.2 depends on linux-image-2.6.24.2 | kernel-image-2.6.24.2; however: Package linux-image-2.6.24.2 is not installed. Package kernel-image-2.6.24.2 is not installed. dpkg: error processing gspca-modules-2.6.24.2 (--install): dependency problems - leaving unconfigured Errors were encountered while processing: gspca-modules-2.6.24.2 I had a quick look at other packages that provide -source packages (for example rt2500), and it looks like the kernel packages should be recommended, not depended on. I include a patch to fix this below: Not the various module packages I maintain, personally I like to hard depend to make removal of all kernel _and_ modules a pleasent experience. There is no policy or best practise for this situation, only opinions, as far as I know. diff -Nruad -Nruad gspca-01.00.20.orig/debian/control.modules.in gspca-01.00.20/debian/control.modules.in --- gspca-01.00.20.orig/debian/control.modules.in 2008-05-18 12:36:49.0 +0100 +++ gspca-01.00.20/debian/control.modules.in 2008-05-18 12:37:44.0 +0100 @@ -7,7 +7,7 @@ Package: gspca-modules-_KVERS_ Architecture: any -Depends: linux-image-_KVERS_ | kernel-image-_KVERS_ +Recommends: linux-image-_KVERS_ | kernel-image-_KVERS_ Provides: gspca-modules Conflicts: spca5xx-modules-_KVERS_ Description: gspca modules for Linux (kernel _KVERS_) Your patch will be applied immediately, but I do not know when the next upload will be. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477765: refer to #476689
Hi Martin, Please refer to bug #476689, I believe your bootstrap issue is tracked there. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476689: [debian-archive-keyring] Downgrading dependency of gnupg causes failure to cdebootstrap minimal chroot
Is anyone interested in fix this this bug? It has been bounced around the BTS, is incorrectly marked as wontfix after the last forcemerge, and no response to last suggestion a few days ago. To reiterate: The downgrade of dependency of gnupg to recommends causes problems because apt cannot handle this situation gracefully (as shown by waldi). The dependency should be reinstated until such a time apt has adjusted. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476689: [debian-archive-keyring] Downgrading dependency of gnupg causes failure to cdebootstrap minimal chroot
On Saturday 19 April 2008 00:03:58 Philipp Kern wrote: Not a bug in debian-archive-keyring, but in cdebootstrap. It should install recommends. OTOH it's also #476532 in apt, as it should use gpgv instead and depend on it Wouldn't it be easier to just revert to depending on gnupg considering the point in release timeline Debian is at, and fix up the collateral damage of this desired change (possibly with more coordination) when the core packages that require change are not in a state of frozen development? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472653: wrong CONFIG_BUSYBOX_EXEC_PATH
Package: busybox Version: 1:1.9.2-1 I believe this configuration change is needed if busybox is to be used as 'mount' before /proc is mounted: --- diff -Nrup busybox-1.9.2.orig/debian/config/config.deb busybox-1.9.2/debian/config/config.deb --- busybox-1.9.2.orig/debian/config/config.deb 2008-03-26 01:31:01.0 +1000 +++ busybox-1.9.2/debian/config/config.deb 2008-03-26 02:05:44.0 +1000 @@ -31,7 +31,7 @@ CONFIG_FEATURE_SUID=y # CONFIG_FEATURE_SUID_CONFIG_QUIET is not set # CONFIG_SELINUX is not set CONFIG_FEATURE_PREFER_APPLETS=y -CONFIG_BUSYBOX_EXEC_PATH=/proc/self/exe +CONFIG_BUSYBOX_EXEC_PATH=/bin/busybox CONFIG_FEATURE_SYSLOG=y CONFIG_FEATURE_HAVE_RPC=y -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467198: madwifi-source: m-a doesn't install due to dependencies problems (madwifi-tools)
On Sunday 24 February 2008 03:54:30 Colomban Wendling wrote: Package: madwifi-source Version: 1:0.9.4~rc2-1 Severity: grave Justification: renders package unusable The installation of the new version of madwifi-source doesn't work due to madwifi-tools dpendencies problems. After compilation with module-assistant, the instalation reports the following: Selecting previously deselected package madwifi-modules-2.6.22-3-amd64. (Reading database ... 176935 files and directories currently installed.) Unpacking madwifi-modules-2.6.22-3-amd64 (from .../madwifi-modules-2.6.22-3-amd64_0.9.4~rc2-1+2.6.22-6.lenny1_amd64.deb) ... dpkg: dependency problems prevent configuration of madwifi-modules-2.6.22-3-amd64: madwifi-modules-2.6.22-3-amd64 depends on madwifi-tools (= 1:0.9.4~rc2+dfsg-1); however: Version of madwifi-tools on system is 1:0.9.3+dfsg-3. dpkg: error processing madwifi-modules-2.6.22-3-amd64 (--install): dependency problems - leaving unconfigured Errors were encountered while processing: madwifi-modules-2.6.22-3-amd64 I: Direct installation failed, trying to post-install the dependencies Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following packages will be REMOVED: madwifi-modules-2.6.22-3-amd64 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 1036kB disk space will be freed. Do you want to continue [Y/n]? y (Reading database ... 176951 files and directories currently installed.) Removing madwifi-modules-2.6.22-3-amd64 ... What exact command did you use? What distribution (testing|sid)? Do you have latest madwifi-tools installed? If so what version? What does apt-cache policy madwifi-tools say? Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#467198: madwifi-source: m-a doesn't install due to dependencies problems (madwifi-tools)
On Sunday 24 February 2008 13:36:28 Colomban Wendling wrote: What exact command did you use? What distribution (testing|sid)? Do you have latest madwifi-tools installed? If so what version? What does apt-cache policy madwifi-tools say? Kel. Hi, I'm using Testing. I've build madwifi-source with m-a suite : m-a prepare, build then install As I've done with the previous version. Yes, I've the latest madwifi-tools from testing repositories, I've no updates at this time. My madwifi-tools version is 1:0.9.3+dfsg-3, and it is the latest from testing repositories (as aptitude says after an update). As you see, it doesn't match the madwifi-source version number. You can see the same at packages.debian.org for testing (and sid for mips and mipsel arch). the madwifi-tools policy: $ apt-cache policy madwifi-tools madwifi-tools: Installed: 1:0.9.3+dfsg-3 Candidate: 1:0.9.3+dfsg-3 Version table: *** 1:0.9.3+dfsg-3 0 900 http://ftp.fr.debian.org lenny/contrib Packages 900 http://ftp.fr.debian.org testing/contrib Packages 100 /var/lib/dpkg/status 1:0.9.3+dfsg-1 0 -20 ftp://fr.archive.ubuntu.com gutsy/universe Packages It seems for me that the madwifi-tools package has to be updated in the repositories to match the madwifi-source version, isn't it? new madwifi-tools has not yet migrated to testing. It seems that mips and mipsel build daemons have not yet attempted to build the package. That is bad, and not something I can do anything about. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464514: [pkg-wpa-devel] Bug#464514: wpasupplicant segfaults after successful authentication
tags 464514 pending
thanks
On Thursday 07 February 2008 19:56:05 Alex wrote:
Package: wpasupplicant
Version: 0.6.2+git20080202.gde6ccd7-1 0
Severity: critical
Using the configuration (no problems with older wpasupplicant)
network={
[...]
key_mgmt=IEEE8021X
eap=TTLS
phase2=auth=MSCHAPV2
[...]
}
wpasupplicant dies with:
--
AP-TTLS: Phase 2 MSCHAPV2 authentication succeeded
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
Speicherzugriffsfehler
--
-dd shows a massive loop of
--
EAPOL: KEY_RX entering state KEY_RECEIVE
EAPOL: processKey
EAPOL: RX IEEE 802.1X ver=1 type=3 len=57 EAPOL-Key: type=1
key_length=13 key_index=0x2
--
after which wpasupplicant finally segfaults.
I downgraded to the version in testing.
I believe to this to be fixed in the current pkg-wpa SVN, which pulled the
latest hostap git and included the following bugfix:
http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=8c0dad4904474016c373573414c8e16ba51e88ad
Thanks, Kel.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463353: madwifi-source: patch for compilation under 2.6.24
tags 463353 pending thanks On Wednesday 06 February 2008 05:46:11 Eric Cooper wrote: Package: madwifi-source Version: 1:0.9.3.2-2 Tags: patch Followup-For: Bug #463353 Did you read the bug report before going to trouble of making patch? pkg-madwifi is fixed with regard to this issue, some packages for testing are available and upstream are just about to release 0.9.4. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463547: [pkg-wpa-devel] Bug#463547: FTBFS: uic file generated with too recent version of Qt Designer
tags 463547 pending thanks On Monday 04 February 2008 07:00:16 Joachim Breitner wrote: Version: 0.6.2-1 Hi, Am Sonntag, den 03.02.2008, 01:22 +1000 schrieb Kel Modderman: On Friday 01 February 2008 21:58:14 Kel Modderman wrote: On Friday 01 February 2008 21:11:03 Joachim Breitner wrote: Package: wpasupplicant Version: 0.6.1~git20071119-1 Severity: serious Hi, trying to recompile the package here I get this error: /usr/share/qt3/bin/uic wpagui.ui -o .ui/wpagui.h uic: File generated with too recent version of Qt Designer (4.0 vs. 3.3.7) uic is an alternative, which happens to point to /usr/bin/uic-qt3 here on my system. The build should therefore use uic-qt4. This should be fixed in experimental already. Did you confirm if it is fixed in experimental yet? Oh, sorry, no: It seems that when I ran apt-get source, it fetched the version from experimental already, so no, the problem was present in that version. Aha, which is why I totally misunderstood the bug. Also what was missing was the really informative parts of the error message that were snipped from the original bug report (the part where qmake-qt3 was used to generate the Makefile). I assume that a package should build independently of the /etc/alternatives settings, right? Yes, we must hardcode the path to the version of qmake required, which is currently /usr/bin/qmake-qt4. http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/2008-February/001493.html Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463547: [pkg-wpa-devel] Bug#463547: FTBFS: uic file generated with too recent version of Qt Designer
On Friday 01 February 2008 21:58:14 Kel Modderman wrote: On Friday 01 February 2008 21:11:03 Joachim Breitner wrote: Package: wpasupplicant Version: 0.6.1~git20071119-1 Severity: serious Hi, trying to recompile the package here I get this error: /usr/share/qt3/bin/uic wpagui.ui -o .ui/wpagui.h uic: File generated with too recent version of Qt Designer (4.0 vs. 3.3.7) uic is an alternative, which happens to point to /usr/bin/uic-qt3 here on my system. The build should therefore use uic-qt4. This should be fixed in experimental already. Did you confirm if it is fixed in experimental yet? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463547: [pkg-wpa-devel] Bug#463547: FTBFS: uic file generated with too recent version of Qt Designer
On Friday 01 February 2008 21:11:03 Joachim Breitner wrote: Package: wpasupplicant Version: 0.6.1~git20071119-1 Severity: serious Hi, trying to recompile the package here I get this error: /usr/share/qt3/bin/uic wpagui.ui -o .ui/wpagui.h uic: File generated with too recent version of Qt Designer (4.0 vs. 3.3.7) uic is an alternative, which happens to point to /usr/bin/uic-qt3 here on my system. The build should therefore use uic-qt4. This should be fixed in experimental already. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463353: madwifi-source: cannot build with 2.6.24-1-686
On Thursday 31 January 2008 23:56:21 Damyan Ivanov wrote: Proposed updates are at: http://sidux.net/kelmo/debian/pool/non-free/m/madwifi/madwifi_0.9.4~rc1-1.dsc http://sidux.net/kelmo/debian/pool/contrib/m/madwifi-tools/madwifi-tools_0.9.3+dfsg-4.dsc I gave these a try. They built fine (2.6.24-1-amd64). The madwifi-modules generated by m-a has Depends: madwifi-tools without version. As I understand it, the blacklisting of ath5k in madwifi-tools is introduced in 0.9.3+dfsg-4 so perhaps the Depends line in generated madwifi-modules should be adjusted to include version? Ack, done. After installing madwifi-tools 0.9.3+dfsg-4 and rebooting, everything came as before. No ath5k was loaded, madwifi seems to work fine. Thanks for feedback. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463353: madwifi-source: cannot build with 2.6.24-1-686
On Thursday 31 January 2008 20:41:00 Stephen Gran wrote: This one time, at band camp, Kel Modderman said: Thank you for this very useful information. Even when this obstacle is passed, the current madwifi version will fail to build. I've been working on getting the madwifi.org team to work towards a release in the coming week that would not fail to compile against 2.6.24. Am also thinking of packaging the SVN trunk variant of madwifi, possibly for experimental, or possibly for unstable (instead of the upcoming stable upstream release). I'd be interested in hearing the opinion of any developer who is interested in uploading a new madwifi package to the archive in the next few days. Just to let you know, 2.6.24 (in Debian - 2.6.25 for vanilla kernel) is shipping the ath5k module, which is AIUI replacing madwifi. I don't know if that affects your plans, but I wanted to be sure you were aware of it. Am pretty well informed about ath5k movements with regards to mainline inclusion (am involved with madwifi.org team that handles development of the non-free madwifi and free ath5k module) but not with debian's movements. Thanks for the heads up. Madwifi, unfortunately, will still be in demand for a short while, so while I'll be supporting its removal from Debian archive (and my todo list) ASAP, will still try and provide a service for some users who require it until ath5k is able to satisfy their requirements in the meantime. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463353: madwifi-source: cannot build with 2.6.24-1-686
On Thursday 31 January 2008 22:01:02 Stephen Gran wrote: This one time, at band camp, Kel Modderman said: Am pretty well informed about ath5k movements with regards to mainline inclusion (am involved with madwifi.org team that handles development of the non-free madwifi and free ath5k module) but not with debian's movements. Thanks for the heads up. Cool, wasn't trying to teach you to suck eggs :) Thanks for looking after madwifi and now ath5k - you've kept several of my laptops connected over the years. About the only way I can see Madwifi being a useful package now that ath5k is on the scene is to have madwifi actively claim priority over ath5k by blacklisting it via conffile file in /etc/modprobe.d/ (installed by madwifi-tools package). This is staged for next madwifi-tools upload pending discussion. This way, users of madwifi (who actively install it on their systems) won't be shocked by sudden changes with coming with new linux-image with ath5k. madwifi-tools is a hard dependency of the generated modules package, removing madwifi-tools would cause removal of all active madwifi components on system and allow ath5k a chance. New systems, of course, won't get madwifi-tools installed. Do you think this would be an ok action to take at this stage? Proposed updates are at: http://sidux.net/kelmo/debian/pool/non-free/m/madwifi/madwifi_0.9.4~rc1-1.dsc http://sidux.net/kelmo/debian/pool/contrib/m/madwifi-tools/madwifi-tools_0.9.3+dfsg-4.dsc for anyone interested in trying out with linux-image-2.6.24. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463353: madwifi-source: cannot build with 2.6.24-1-686
On Thursday 31 January 2008 12:57:51 Chip Salzenberg wrote: Package: madwifi-source Version: 1:0.9.3.2-2 Severity: grave Justification: renders package unusable Here's a log of the failure: dh_testdir dh_testroot dh_clean -k # Build modules /usr/bin/make -C /usr/src/modules/madwifi modules \ KERNELPATH=/lib/modules/2.6.24-1-686/build KERNELRELEASE=2.6.24-1-686 KERNELCONF=/lib/modules/2.6.24-1-686/build/.config make[2]: Entering directory `/usr/src/modules/madwifi' Checking requirements... ok. Checking kernel configuration... ok. /usr/bin/make -C /lib/modules/2.6.24-1-686/build SUBDIRS=/usr/src/modules/madwifi modules make[3]: Entering directory `/usr/src/linux-headers-2.6.24-1-686' /usr/src/modules/madwifi/scripts/get_arch.mk:44: *** ARCH mismatch: supplied x86, determined i386. Stop. make[3]: *** [_module_/usr/src/modules/madwifi] Error 2 make[3]: Leaving directory `/usr/src/linux-headers-2.6.24-1-686' make[2]: *** [modules] Error 2 make[2]: Leaving directory `/usr/src/modules/madwifi' make[1]: *** [binary-modules] Error 2 make[1]: Leaving directory `/usr/src/modules/madwifi' make: *** [kdist_build] Error 2 Noted, thanks for your report. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463353: madwifi-source: cannot build with 2.6.24-1-686
On Thursday 31 January 2008 15:59:08 Damyan Ivanov wrote: -=| Kel Modderman, Thu, Jan 31, 2008 at 01:11:35PM +1000 |=- On Thursday 31 January 2008 12:57:51 Chip Salzenberg wrote: make[3]: Entering directory `/usr/src/linux-headers-2.6.24-1-686' /usr/src/modules/madwifi/scripts/get_arch.mk:44: *** ARCH mismatch: supplied x86, determined i386. Stop. Noted, thanks for your report. For your information, similar errors happens on amd64: /usr/src/modules/madwifi/scripts/get_arch.mk:44: *** ARCH mismatch: supplied x86, determined x86_64. Stop. I noted the following in linux-2.6 (2.6.24~rc8-1~experimental.1) changelog that may be relevant: [ Bastian Blank ] * [amd64, i386]: Set kernel architecture to x86. * [i386]: Remove linux-libc-dev arch override. Thank you for this very useful information. Even when this obstacle is passed, the current madwifi version will fail to build. I've been working on getting the madwifi.org team to work towards a release in the coming week that would not fail to compile against 2.6.24. Am also thinking of packaging the SVN trunk variant of madwifi, possibly for experimental, or possibly for unstable (instead of the upcoming stable upstream release). I'd be interested in hearing the opinion of any developer who is interested in uploading a new madwifi package to the archive in the next few days. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426224: [Pkg-sysvinit-devel] Bug#426224: shutdown patches - the choices
Hi, On Thursday 13 December 2007 17:35:20 Artur Szymiec wrote: Kel Modderman pisze: Package: sysvinit Version: 2.86.ds1-38.1 Hi, I'm following up on this ticket, since I've not received any response for the best part of 6 months. The patch I proposed here is, IMHO, the most complete of the ones offered so far. Recently, I was made aware of someone also claiming [0] the patch [1] from Werner Fink, discussed [2] on the novell bug tracker, would be great to include into our own Debian version of sysvinit to fix the shutdown issue of spinning down disks correctly (...or not). However, r1067 [3] was committed to pkg-sysvinit trunk, which merges the changes done in the libata-fixes branch which was for testing [4]. Tejun Heo, an active libata/kernel hacker, replied [5] with information that Werner Fink was also working on this issue. Tejun was also active in the development of the patch as seen on the novell bug discussion [2]. I emailed the list [6] with discussion requested at [4], created a patch for the debian package [7], and tested the patch thoroughly on a very wide variety of hardware from debian installed and live-cd environments over the last 6 months. The patch works as advertised. opensuse 10.3 also contains a sysvinit using the mentioned patch. This means it has seen widespread testing from a variety of people on a variety of hardware. The patch matches the criteria set out at [8] about how hddown.c could best handle this (except using /proc): [quote] a) it uses sysfs and not /proc to locate disks, and that it locates all IDE and SCSI/libata disks, or maybe do both /proc and sysfs. b) that it verifies the state of kernel disk spindown control for each disk, and for the disks where it is unavailable: b1) issue cache sync to disk b2) issue spin down to disk c) for the disks where kernel spin down control is available, enable it and skip to next disk. [/quote] The patch does not suffer from limitation of an alternate patch offered to fix the situation that is discussed at [9], which seems to be similar in limitation to what has been merged [3]. Ok, there are too many damn numbers listed below with references. But you get the picture I hope, that I'm concerned about the direction the maintainers [10] intend to take in order to fix this issue, and that I've laid out as much information, patch and help that I can to try and convince them there is a better solution. Thanks, Kel. [0] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-December/0 02141.html [1] https://bugzilla.novell.com/attachment.cgi?id=145904 [2] https://bugzilla.novell.com/show_bug.cgi?id=229210 [3] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-commits/2007-November /000955.html [4] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-June/00196 1.html [5] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-June/00196 3.html [6] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-June/00197 2.html [7] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-June/00197 4.html [8] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224#10 [9] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436703 [10] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-December/0 02142.html ___ Pkg-sysvinit-devel mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel Greetings, I've sent a patch for Debian sysv init hdd down over a month ago (4.11.2007). Till now I haven't receive any comment regarding it. Could you please review it too ? Attached files (hdd.c and a patch in attachment). Why would I want to look up another patch to review it after already investing time recommending what I truly believe to be a comprehensive fix? This is surely the job of the maintainers to discuss the options and choose their choice of action. The trick is to solicit a response from them. If you really want me to, make it a bit easier by giving a unambiguous link to the content _and_ state what it does better in comparison to what we could inherit from Werner Fink that I've argued in favour of a long long time ago, and referenced again in the mail you replied to. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426224: shutdown patches - the choices
Package: sysvinit Version: 2.86.ds1-38.1 Hi, I'm following up on this ticket, since I've not received any response for the best part of 6 months. The patch I proposed here is, IMHO, the most complete of the ones offered so far. Recently, I was made aware of someone also claiming [0] the patch [1] from Werner Fink, discussed [2] on the novell bug tracker, would be great to include into our own Debian version of sysvinit to fix the shutdown issue of spinning down disks correctly (...or not). However, r1067 [3] was committed to pkg-sysvinit trunk, which merges the changes done in the libata-fixes branch which was for testing [4]. Tejun Heo, an active libata/kernel hacker, replied [5] with information that Werner Fink was also working on this issue. Tejun was also active in the development of the patch as seen on the novell bug discussion [2]. I emailed the list [6] with discussion requested at [4], created a patch for the debian package [7], and tested the patch thoroughly on a very wide variety of hardware from debian installed and live-cd environments over the last 6 months. The patch works as advertised. opensuse 10.3 also contains a sysvinit using the mentioned patch. This means it has seen widespread testing from a variety of people on a variety of hardware. The patch matches the criteria set out at [8] about how hddown.c could best handle this (except using /proc): [quote] a) it uses sysfs and not /proc to locate disks, and that it locates all IDE and SCSI/libata disks, or maybe do both /proc and sysfs. b) that it verifies the state of kernel disk spindown control for each disk, and for the disks where it is unavailable: b1) issue cache sync to disk b2) issue spin down to disk c) for the disks where kernel spin down control is available, enable it and skip to next disk. [/quote] The patch does not suffer from limitation of an alternate patch offered to fix the situation that is discussed at [9], which seems to be similar in limitation to what has been merged [3]. Ok, there are too many damn numbers listed below with references. But you get the picture I hope, that I'm concerned about the direction the maintainers [10] intend to take in order to fix this issue, and that I've laid out as much information, patch and help that I can to try and convince them there is a better solution. Thanks, Kel. [0] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-December/002141.html [1] https://bugzilla.novell.com/attachment.cgi?id=145904 [2] https://bugzilla.novell.com/show_bug.cgi?id=229210 [3] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-commits/2007-November/000955.html [4] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-June/001961.html [5] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-June/001963.html [6] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-June/001972.html [7] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-June/001974.html [8] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426224#10 [9] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=436703 [10] http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2007-December/002142.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446824: CVE-2007-5448 remote denial of service via crafted beacon frame
tags 446824 pending thanks On Tue, 16 Oct 2007 08:37:31 am Nico Golde wrote: | Madwifi 0.9.3.2 and earlier allows remote attackers to cause a denial | of service (panic) via a beacon frame with a large length value in the | extended supported rates (xrates) element, which triggers an assertion | error, related to net80211/ieee80211_scan_ap.c and | net80211/ieee80211_scan_sta.c. net80211/ieee80211_scan_ap.c in not vulnerable in any stable release from madwifi.org[0], the CVE is slightly misleading in regards to that detail. Package awaiting sponsorship. Thanks, Kel. [0] http://madwifi.org/changeset/2749 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446824: CVE-2007-5448 remote denial of service via crafted beacon frame
On Wed, 17 Oct 2007 03:01:24 am Nico Golde wrote: Hi, * Nico Golde [EMAIL PROTECTED] [2007-10-16 17:59]: Hi Kel, * Kel Modderman [EMAIL PROTECTED] [2007-10-16 17:14]: tags 446824 pending thanks On Tue, 16 Oct 2007 08:37:31 am Nico Golde wrote: | Madwifi 0.9.3.2 and earlier allows remote attackers to cause a | denial of service (panic) via a beacon frame with a large length | value in the extended supported rates (xrates) element, which | triggers an assertion error, related to | net80211/ieee80211_scan_ap.c and | net80211/ieee80211_scan_sta.c. net80211/ieee80211_scan_ap.c in not vulnerable in any stable release from madwifi.org[0], the CVE is slightly misleading in regards to that detail. Well I never said it is :) But thanks for the information, I checked this and added it as not-affected to the security tracker. Correction, I misunderstood you, thanks Moritz for pointing me to this. At least the code in ieee80211_scan_sta.c is vulnerable in the Debian versions if I don't miss anything. Kind regards Nico Yes, thats correct. ieee80211_scan_sta.c is vulnerable in all upstream and debian versions. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446039: madwifi-source: won't complie under 2.6.23
severity 446039 wishlist tags 446039 pending thanks On Wed, 10 Oct 2007 12:37:24 pm R E Riding wrote: Package: madwifi-source Version: 1:0.9.3.2-1 Severity: grave Justification: renders package unusable after configuring and making kernel 2.6.23 using make-kpkg, make-kpkg --added-modules madwifi modules fails with the following error: # Build modules /usr/bin/make -C /usr/src/modules/madwifi modules \ KERNELPATH=/usr/src/linux-2.6.23 KERNELRELEASE=2.6.23 KERNELCONF=/usr/src/linux-2.6.23/.config make[3]: Entering directory `/usr/src/modules/madwifi' Checking requirements... ok. Checking kernel configuration... ok. /usr/bin/make -C /usr/src/linux-2.6.23 SUBDIRS=/usr/src/modules/madwifi modules make[4]: Entering directory `/usr/src/linux-2.6.23' CC [M] /usr/src/modules/madwifi/ath/if_ath.o CC [M] /usr/src/modules/madwifi/ath/if_ath_pci.o cc1: warnings being treated as errors In file included from /usr/src/modules/madwifi/ath/../net80211/if_media.h:44, from /usr/src/modules/madwifi/ath/if_ath_pci.c:61: /usr/src/modules/madwifi/ath/../net80211/ieee80211_linux.h:532: warning: 'struct file_operations' declared inside parameter list/usr/src/modules/madwifi/ath/../net80211/ieee80211_linux.h:532: warning: its scope is only this definition or declaration, which is probably not what you want make[6]: *** [/usr/src/modules/madwifi/ath/if_ath_pci.o] Error 1 make[5]: *** [/usr/src/modules/madwifi/ath] Error 2 make[4]: *** [_module_/usr/src/modules/madwifi] Error 2 make[4]: Leaving directory `/usr/src/linux-2.6.23' make[3]: *** [modules] Error 2 make[3]: Leaving directory `/usr/src/modules/madwifi' make[2]: *** [binary-modules] Error 2 make[2]: Leaving directory `/usr/src/modules/madwifi' make[1]: *** [kdist_build] Error 2 make[1]: Leaving directory `/usr/src/modules/madwifi' Module /usr/src/modules/madwifi failed. The madwifi modules still compile under 2.6.22.9, ruling out the recent upgrade to gcc-4.2.2-1 (I think). The package is not broken, an upstream kernel version not yet packaged in debian is not compatible with it, adjusting severity accordingly. Thanks for notification, pkg-madwifi svn has been prepared for 2.6.23 for a few weeks now, and just needs a tag and upload. I guess we have to add an extra Closes: now too. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438746: libqt4-qt3support needs tighter dependency on libqt4-*
reassign 438746 libqt4-qt3support thanks libqt4-qt3support can be installed alongside incompatible qt4 libs, eg: libqt4-core4.3.1-2 libqt4-gui 4.3.1-2 libqt4-qt3support 4.3.0-4 The above combination of packages inhibited wpagui to start for a user. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438746: wpa_gui not useable : Cannot mix incompatible Qt libraries
Hi, On Mon, 20 Aug 2007 01:00:08 am Didier Raboud wrote: Package: wpagui Version: 0.6.0-2 Severity: serious --- Please enter the report below this line. --- Hi, when launching wpa_gui, I get this error which makes the whole wpagui package unuseable : $ wpa_gui Cannot mix incompatible Qt libraries Abandon Your libqt4-qt3support seems out of date in comparison to the other qt4 libs installed on your system, and this is causing the problem. --- Package information. --- Depends (Version) | Installed =-+- libc6 (= 2.5-5) | 2.6-2 libgcc1 (= 1:4.2-20070516) | 1:4.2-20070712-1 libqt4-core(= 4.3.0) | 4.3.1-2 libqt4-gui (= 4.3.0) | 4.3.1-2 libqt4-qt3support (= 4.3.0) | 4.3.0-4 libstdc++6 (= 4.2-20070516) | 4.2-20070712-1 wpasupplicant | 0.6.0-1 Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434816: Doesn't work at all with kernel 2.6.22
severity 434816 important thanks On Fri, 27 Jul 2007 08:23:11 am David wrote: Package: madwifi-source Version: 1:0.9.3-3 Severity: grave --- Please enter the report below this line. --- After upgrading the kernel and, of course, doing m-a a-i madwifi and rebooting, debian can't see any network interface. I compiled the last snapshot from the upstream and I can see the essids again. I dispute your claim, since I'm running a 2.6.22 based kernel with madwifi install via debian package 0.9.3-2 ii madwifi-modules-2.6.22.1-kel-smp-11:0.9.3-3+1 There I believe that the package does work, it not severity grave and ask for you to dig around and give some more information. Thank, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429437: new MAKEDEV usage chroot un friendly
On Tue, 19 Jun 2007 07:58:35 am Ludovic RESLINGER wrote: On Mon, Jun 18, 2007 at 01:10:38PM +1000, [EMAIL PROTECTED] wrote: Package: libraw1394-8 Version: 1.2.1-3 Severity: serious Tags: patch The new postinst is broken for the common case of installing package in chroot. set -e is used and cd /dev/ ./MAKEDEV is called unconditionally. Please test for existance of ./MAKEDEV, or that you are in a chroot, or just tack a || true onto the offending line. Setting up libraw1394-8 (1.2.1-3) ... Creating device node /dev/raw1394... /var/lib/dpkg/info/libraw1394-8.postinst: line 5: ./MAKEDEV: No such file or directory dpkg: error processing libraw1394-8 (--configure): subprocess post-installation script returned error exit status 1 Thanks, Kel. Hello, I need to know if you use makedev or udev. In a clean chroot, there is nothing in /dev. udev was installed. No my patch is not best answer, but it at least allows package to be installed in chroot. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429437: new MAKEDEV usage chroot un friendly
On Tue, 19 Jun 2007 07:58:35 am Ludovic RESLINGER wrote: Hello, I need to know if you use makedev or udev. I should have said: In the chroot, at the time libraw1394-8.postinst was called, udev was installed but inactive due to the fact that it detects it was installed in a chroot in udev.postinst and is no-op. This means that udev does not provide /dev/MAKEDEV in a chroot. There exist only a minimal static /dev at that time. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425738: madwifi: several DOS-able holes
Hi Bernd and security team, On Thu, 24 May 2007 02:28:12 am Bernd Zeimetz wrote: Package: madwifi Version: 0.9.3 Severity: critical Tags: security Hi, I was wondering how long it would take for someone to file a bug. 0.9.3-2 was uploaded to unstable[0] before the vulnerabilities were made public by the team at madwifi.org. It contained the pertinent patches. although I'm pretty sure you know about those issues, it won't be bad to have them listed in the bugtracker. In case Etch is affected, too, please get the fixes into r1. http://madwifi.org/ticket/1270 http://madwifi.org/ticket/1335 http://madwifi.org/ticket/1334 Last time madwifi vulnerabilities were discussed with the security team[1] there was a strong indication that non-free was not cared for[2]. I didn't know how much truth there was to that at the time as there was no further action required then. This time further action could be taken as there do exist security flaws in the madwifi package shipped with etch. The debian security FAQ states[3] that the security team generally don't care for contrib or non-free but they may be influenced into passing on required changes if handed to them on a silver platter by the maintainer or some other developer. A debdiff is attached that would fix the security concerns in madwifi stable version 1:0.9.2+r1842.20061207-2. Below is a brief description of the security concerns taken from the 0.9.3.1 madwifi release announcement, there are no known CVE id's at this time. 1. Remote DoS: insufficient input validation (beacon interval) The beacon interval information that is gathered while scanning for Access Points is not properly validated. This could be exploited from remote to cause a DoS due to a division by zero exception. See also: http://madwifi.org/ticket/1270 2. Remote DoS: insufficient input validation (Fast Frame parsing) The code which parses fast frames and 802.3 frames embedded therein does not properly validate the size parameters in such frames. This could be exploited from remote to cause a DoS due to a NULL-pointer dereference. See also: http://madwifi.org/ticket/1335 3. Local DoS: insufficient input validation (WMM parameters) A restricted local user could pass invalid data to two ioctl handlers, causing a DoS due to access being made to invalid addresses. Chances are that this issue also might allow read and/or write access to kernel memory; this has not yet been verified. See also: http://madwifi.org/ticket/1334 I've tested the resulting debian package and it does not change behaviour in ways that will make the end user unhappy as far as I can see. Hopefully it also conforms to guidelines set out in the debian reference for targetting security related fixes to the stable branch. Thanks, Kel. [0] http://packages.qa.debian.org/m/madwifi/news/20070522T134706Z.html [1] http://lists.alioth.debian.org/pipermail/pkg-madwifi-maintainers/2007-April/000626.html [2] http://lists.alioth.debian.org/pipermail/pkg-madwifi-maintainers/2007-April/000634.html [3] http://www.debian.org/security/faq#contrib [4] http://madwifi.org/wiki/Releases/0.9.3.1 diff -u madwifi-0.9.2+r1842.20061207/debian/patches/00list madwifi-0.9.2+r1842.20061207/debian/patches/00list --- madwifi-0.9.2+r1842.20061207/debian/patches/00list +++ madwifi-0.9.2+r1842.20061207/debian/patches/00list @@ -1,0 +2,3 @@ +01_secfix-0.9.3-sizecheck-take3 +02_secfix-0.9.3-wmmparams-take2 +03_secfix-0.9.3-beacon_interval_range diff -u madwifi-0.9.2+r1842.20061207/debian/control madwifi-0.9.2+r1842.20061207/debian/control --- madwifi-0.9.2+r1842.20061207/debian/control +++ madwifi-0.9.2+r1842.20061207/debian/control @@ -2,7 +2,7 @@ Section: non-free/net Priority: optional Maintainer: Debian madwifi team [EMAIL PROTECTED] -Uploaders: Loic Minier [EMAIL PROTECTED], Kel Modderman [EMAIL PROTECTED], Matt Brown [EMAIL PROTECTED], Alex Wallis [EMAIL PROTECTED] +Uploaders: Loic Minier [EMAIL PROTECTED], Kel Modderman [EMAIL PROTECTED], Matt Brown [EMAIL PROTECTED], Alex Wallis [EMAIL PROTECTED] Build-Depends: cdbs, debhelper (= 5.0.37), bzip2, dpatch Standards-Version: 3.7.2 diff -u madwifi-0.9.2+r1842.20061207/debian/changelog madwifi-0.9.2+r1842.20061207/debian/changelog --- madwifi-0.9.2+r1842.20061207/debian/changelog +++ madwifi-0.9.2+r1842.20061207/debian/changelog @@ -1,3 +1,19 @@ +madwifi (1:0.9.2+r1842.20061207-3) stable-security; urgency=high + + * Backport upstream security fixes: +- Remote DoS: insufficient input validation (beacon interval) + debian/patches/03_secfix-0.9.3-beacon_interval_range.dpatch + http://madwifi.org/ticket/1270 +- Remote DoS: insufficient input validation (Fast Frame parsing) + debian/patches/01_secfix-0.9.3-sizecheck-take3.dpatch + http://madwifi.org/ticket/1335 +- Local DoS: insufficient input validation (WMM parameters) + debian/patches/02_secfix-0.9.3-wmmparams-take2.dpatch + http://madwifi.org/ticket/1334 + * Update
Bug#419057: ndiswrapper-source: Fails to compile with Upstream Kernel source 2.6.20.6
severity 419057 wishlist thanks Hi Subhashis, On Saturday 14 April 2007 00:19, Subhashis Roy wrote: Package: ndiswrapper-source Version: 1.28-1 Severity: grave Justification: renders package unusable ...when used with stuff outside of what is in etch. This is not a grave shortcoming of ndiswrapper-source, how can it be expected to work with a kernel that was not present in debian at the time the archive was frozen to new updates? Presently the running kernel is 2.6.17.11 (from kernel.org) on a Pentium-IV. However, building the Etch ndiswrapper kernel source with the default linux-2.6.20.6 source using 'kpkg' failed with the following message. --- make[3]: Entering directory `/usr/src/modules/ndiswrapper' /usr/bin/make -C /usr/src/linux-2.6.20.6 SUBDIRS=/usr/src/modules/ndiswrapper make[4]: Entering directory `/usr/src/linux-2.6.20.6' LD /usr/src/modules/ndiswrapper/built-in.o CC [M] /usr/src/modules/ndiswrapper/crt.o CC [M] /usr/src/modules/ndiswrapper/hal.o CC [M] /usr/src/modules/ndiswrapper/iw_ndis.o CC [M] /usr/src/modules/ndiswrapper/loader.o CC [M] /usr/src/modules/ndiswrapper/ndis.o /usr/src/modules/ndiswrapper/ndis.c:39:47: error: macro INIT_WORK passed 3 arguments, but takes just 2 /usr/src/modules/ndiswrapper/ndis.c: In function 'ndis_init': /usr/src/modules/ndiswrapper/ndis.c:39: error: 'INIT_WORK' undeclared (first use in this function) /usr/src/modules/ndiswrapper/ndis.c:39: error: (Each undeclared identifier is reported only once /usr/src/modules/ndiswrapper/ndis.c:39: error: for each function it appears in.) /usr/src/modules/ndiswrapper/ndis.c: In function 'NdisMIndicateStatus': /usr/src/modules/ndiswrapper/ndis.c:1862: warning: unused variable 'radio_status' make[5]: *** [/usr/src/modules/ndiswrapper/ndis.o] Error 1 make[4]: *** [_module_/usr/src/modules/ndiswrapper] Error 2 make[4]: Leaving directory `/usr/src/linux-2.6.20.6' make[3]: *** [default] Error 2 make[3]: Leaving directory `/usr/src/modules/ndiswrapper' make[2]: *** [binary-modules] Error 2 make[2]: Leaving directory `/usr/src/modules/ndiswrapper' make[1]: *** [kdist_build] Error 2 - Then use the version from sid/unstable. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403301: [pkg-wpa-devel] Bug#403301: wpasupplicant: segfaults with Cisco Aironet
severity 403301 important thanks Hi Matteo, Lowered severity, this does not meet grave bug criteria, IMHO. The package works fine with supported devices and did not cause you any harm. On Saturday 16 December 2006 11:50, Matteo Croce wrote: Package: wpasupplicant Version: 0.5.5-4 Severity: grave Justification: renders package unusable What's wrong here? [~]$ sudo wpa_supplicant -Dwext -ieth0 -c/etc/wpa_supplicant/wpa_supplicant.conf ioctl[SIOCSIWAUTH]: Operation not supported WEXT auth param 7 value 0x1 - ioctl[SIOCSIWAUTH]: Operation not supported WEXT auth param 4 value 0x0 - Failed to initialize control interface '/var/run/wpa_supplicant'. You may have another wpa_supplicant process already running or the file was left by an unclean termination of wpa_supplicant in which case you will need to manually remove this file before starting wpa_supplicant again. Your device (its firmware) presumably does not support WPA. During some researching of these cisco aironet devices, I found a nice table of WPA support here: http://www.ippp.dur.ac.uk/Computing/wirelessLinux.html Its features are also well described here: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.drivers.802.11b.html#Arlan802 Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398466: NMU Ready
On Saturday 09 December 2006 08:00, Matt Brown wrote: The fix described in the third post is incorrect. The backported patches applied in -3 have already reordered this part of the code so that it works correctly with madwifi. Unfortunately that backport missed the final component of the fix, which was to all the hostapd_flush_old_stations call to fail when setting up an interface. eg: http://hostap.epitest.fi/cgi-bin/viewcvs.cgi/hostap/hostapd/hostapd.c.diff? r2=1.168r1=1.167diff_format=u I will upload an NMU fixing this shortly. NMU diff is attached Thanks very much. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401345: [Pkg-spca5xx-devel] Bug#401345: builds fine here..
On Sunday 03 December 2006 12:11, Andreas Henriksson wrote: I can't reproduce your problem with spca5xx-source. How are you building? I've tried building the spca5xx-source in an unstable amd64 pbuilder, then installing the spca5xx-source package and building that with module-assistant which produces /usr/src/modass/spca5xx-modules-2.6.18-3-amd64_20060501-2 +2.6.18-6_amd64.deb How did you reach the error? I too cannot reproduce error on amd64 or i386 with various 2.6.18 and 2.6.19 based kernels. BTW Andreas, gspca should be used now. It is the successor of spca5xx. Thanks, Kel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398466: hostapd 0.5.5-3 serious regression with madwifi
On Tuesday 14 November 2006 08:43, Kel Modderman wrote: Package: hostapd Version: 1:0.5.5-3 Severity: grave Justification: renders package unusable The subtle changes between 0.5.5-2 and 0.5.5-3 have exposed a showstopping bug when used in conjunction with certain madwifi driver versions (specifically 0.9.2+r1784.20061027-1 currently in debian). This should not pass into testing, where 0.5.5-2 is working perfectly. Further information will follow. It is exactly this problem: http://lists.shmoo.com/pipermail/hostap/2006-October/014354.html I propose that we revert recent backport of fixes/enhancements to the driver_madwifi code, so that we can at leas take advantage of the partial hostapd support (everything != plaintext) that has proven to be working well in the released version 0.5.5. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398466: hostapd 0.5.5-3 serious regression with madwifi
Package: hostapd Version: 1:0.5.5-3 Severity: grave Justification: renders package unusable The subtle changes between 0.5.5-2 and 0.5.5-3 have exposed a showstopping bug when used in conjunction with certain madwifi driver versions (specifically 0.9.2+r1784.20061027-1 currently in debian). This should not pass into testing, where 0.5.5-2 is working perfectly. Further information will follow. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396055: [PATCH]: include sioq.[ch] in module tarball
tags 396055 + patch thanks Hi, Please apply attached patch. I think svenl's post above does not apply here, I saw the two files in the orig.tar.gz of current package with my own eyes. Kel. diff -u unionfs-1.3.20061029.0124+debian/debian/rules unionfs-1.3.20061029.0124+debian/debian/rules --- unionfs-1.3.20061029.0124+debian/debian/rules +++ unionfs-1.3.20061029.0124+debian/debian/rules @@ -61,7 +61,7 @@ # Copy files mkdir linux-2.6 cp Makefile.kernel linux-2.6/Makefile - cp branchman.c commonfops.c copyup.c dentry.c dirfops.c dirhelper.c file.c inode.c lookup.c main.c persistent_inode.c print.c rdstate.c rename.c stale_inode.c subr.c super.c unionfs.h unionfs_debug.h unionfs_imap.h unionfs_macros.h unlink.c xattr.c linux-2.6 + cp branchman.c commonfops.c copyup.c dentry.c dirfops.c dirhelper.c file.c inode.c lookup.c main.c persistent_inode.c print.c rdstate.c rename.c sioq.c sioq.h stale_inode.c subr.c super.c unionfs.h unionfs_debug.h unionfs_imap.h unionfs_macros.h unlink.c xattr.c linux-2.6 mv Makefile Makefile.upstream cp debian/Makefile Makefile diff -u unionfs-1.3.20061029.0124+debian/debian/changelog unionfs-1.3.20061029.0124+debian/debian/changelog --- unionfs-1.3.20061029.0124+debian/debian/changelog +++ unionfs-1.3.20061029.0124+debian/debian/changelog @@ -1,3 +1,12 @@ +unionfs (1.3.20061029.0124+debian-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Include sioq.[ch] in line of configure-stamp debian/rules target that is +responsible for copying required upstream contents into debian module +source tarball staging area. + + -- Kel Modderman [EMAIL PROTECTED] Sun, 12 Nov 2006 12:21:59 +1000 + unionfs (1.3.20061029.0124+debian-1) unstable; urgency=low * New upstream snapshot:
Bug#386227: [Pkg-spca5xx-devel] Bug#386227: spca5xx-source: Compile failure with kernel 2.6.18
On Wednesday 18 October 2006 04:22, Brad Sawatzky wrote: On Tue, 17 Oct 2006, Kel Modderman wrote: On Tuesday 17 October 2006 05:23, Moritz Muehlenhoff wrote: severity 386227 grave thanks Package: spca5xx-source Version: 20060501-1 Severity: important Tags: patch [ . . . ] spca5xx-source has been integrated in linux-modules-extra-2.6. I suppose it should be removed entirely? Yes, it should. linux-modules-extra-2.6 appears to be sort of a meta-package -- it depends on the '*-source' packages being available for the modules it wants to build. I just took a look at the source package for linux-modules-extra-2.6 (2.6.18-1) unstable (5 Oct 2006) and the control file lists a depend on spca5xx-source. I don't think you want to remove spca5xx-source. (Or did I misunderstand what you meant?) Heh, I meant that spca5xx-modules meta-package should be removed. Maybe i was confused with a different thread. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386227: [Pkg-spca5xx-devel] Bug#386227: spca5xx-source: Compile failure with kernel 2.6.18
On Tuesday 17 October 2006 05:23, Moritz Muehlenhoff wrote: severity 386227 grave thanks On Tue, Sep 05, 2006 at 11:54:29PM -0400, Brad Sawatzky wrote: Package: spca5xx-source Version: 20060501-1 Severity: important Tags: patch Some v4l header information got shuffled around in kernel 2.6.18. The attached patch updates spca5xx.h to include media/v4l2-common.h. Seems to work after that. You may want to check to see if the v4l changes came in during 2.6.17 and update the patch accordingly. spca5xx-source has been integrated in linux-modules-extra-2.6. I suppose it should be removed entirely? Yes, it should. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390787: Unusable: ath_pci: disagrees about version of symbol lots of symbols
On Tuesday 03 October 2006 11:46, Chip Salzenberg wrote: Package: madwifi-source Version: 1:0.9.2+r1710.20060914-1 Severity: grave Justification: renders package unusable The drivers seem to build OK for kernel 2.6.16-2-686, but when I try to actually use them, I get a raft of disagrees about version of symbol reports, and some of the modules in the package refuse to load. To wit: Oct 2 18:35:54 kernel: pccard: CardBus card inserted into slot 0 Oct 2 18:35:54 kernel: ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) Oct 2 18:35:54 kernel: wlan: 0.8.4.2 (0.9.3) Oct 2 18:35:54 kernel: ath_rate_sample: 1.2 (0.9.3) Oct 2 18:35:54 kernel: ath_pci: disagrees about version of symbol ath_rate_tx_complete Oct 2 18:35:54 kernel: ath_pci: Unknown symbol ath_rate_tx_complete Oct 2 18:35:54 kernel: ath_pci: disagrees about version of symbol ieee80211_encap Oct 2 18:35:54 kernel: ath_pci: Unknown symbol ieee80211_encap Oct 2 18:35:54 kernel: ath_pci: disagrees about version of symbol ieee80211_input Oct 2 18:35:54 kernel: ath_pci: Unknown symbol ieee80211_input Oct 2 18:35:54 kernel: ath_pci: disagrees about version of symbol ieee80211_ifattach Oct 2 18:35:54 kernel: ath_pci: Unknown symbol ieee80211_ifattach Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ieee80211_beacon_update Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_beacon_update Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ieee80211_find_channel Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_find_channel Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ieee80211_find_rxnode Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_find_rxnode Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ath_rate_attach Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ath_rate_attach Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ieee80211_vap_setup Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_vap_setup Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ieee80211_ifdetach Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_ifdetach Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ieee80211_free_node Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_free_node Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ieee80211_input_monitor Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_input_monitor Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ath_rate_newassoc Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ath_rate_newassoc Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ieee80211_crypto_newkey Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_crypto_newkey Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ieee80211_crypto_setkey Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_crypto_setkey Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ath_rate_dynamic_proc_register Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ath_rate_dynamic_proc_register Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ieee80211_dump_pkt Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_dump_pkt Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ieee80211_ioctl_create_vap Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_ioctl_create_vap Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ieee80211_dfs_test_return Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_dfs_test_return Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ieee80211_stop_running Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_stop_running Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol ieee80211_cipher_none Perhaps you have handbuilt modules littering your kernel's module libdir, or you did not first remove all previous modules from kernel space before loading new modules? Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389171: ndiswrapper-source: doesn't compile on 2.6.17-1 and 2.6.17-2
On Sunday 24 September 2006 23:28, ste wrote: Package: ndiswrapper-source Version: 1.23-1 Severity: grave Justification: renders package unusable IMHO, this is not grave, but lets not worry about arguing that point . . . Building this module fails on 2.6.17-1 and 2.6.17-2 giving me this errors: In file included from /usr/src/modules/ndiswrapper/ndis.c:2665: ▒ │ /usr/src/modules/ndiswrapper/ndis_exports.h:143: error: ▒ │ ‘EthFilterDprIndicateReceive’ undeclared here (not in a function) ▒ │ /usr/src/modules/ndiswrapper/ndis_exports.h:144: error: ▒ │ ‘EthFilterDprIndicateReceiveComplete’ undeclared here (not in a function) ▒ │ /usr/src/modules/ndiswrapper/ndis_exports.h:228: error: ▒ │ ‘NdisMSetAttributes’ undeclared here (not in a function) ▒ │ make[4]: *** [/usr/src/modules/ndiswrapper/ndis.o] Error 1 ▒ │ make[3]: *** [_module_/usr/src/modules/ndiswrapper] Error 2 cd /usr/src/modules/ndiswrapper make distclean Does that help? *_exports.h *may* exist if timestamps are out of whack. So using 'distclean' instead of 'clean' in debian/rules may avoid this in the future. Otherwise, I cannot reproduce this problem, as that version of the module has always compiled fine for me, on 2.6.17 and 2.6.18. Thanks, Kel.
Bug#386164: [pkg-wpa-devel] Bug#386164: wpasupplicant is missing versioned depends: on lsb-base
On Wednesday 06 September 2006 05:24, Andreas Janssen wrote: The missing functions log_action_begin and log_action_end were introduced in lsb-base 3.0-6. Ok, thanks. wpasupplicant packaging has been updated accordingly. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386156: hostapd is missing versioned depends: on lsb-base
On Wednesday 06 September 2006 03:32, Andreas Janssen wrote: Package: hostapd Version: 1:0.5.5-1 Severity: serious Justification: Policy 3.5 hostapd 0.5.5 needs init script functions that are not available in older versions of lsb-base. Running a backport on Sarge results in: /etc/init.d/hostapd: line 38: log_daemon_msg: command not found /etc/init.d/hostapd: line 44: log_progress_msg: command not found As hostapd needs lsb-base and lsb-base is not marked essential, hostapd must depend on lsb-base. Because it only works with newer versions of lsb-base the depends: should be versioned. Thanks, applied and ready for upload. (depend on version = 3.0-3 as per advice and lsb-base changelog) @ Faidon, please update from pkg-wpa/hostapd svn when time permits. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374342: [pkg-wpa-devel] Bug#374342: Needs more testing
Hi Reinhard I am fine if you feel that this package needs more testing for a while, however, I would like to point out what small problems occur if we roll back to the 0.4 series of wpa_supplicant upstream: * non-backwards compatible wpa_supplicant.conf options may disrupt the end users configuration, causing wpa_supplicant to fail when parsing the file * we can offer a self-contained roaming solution with the 0.5 series, that may fill the void for users of the old init style roaming (even Felix!) * 0.5 series contains some patches to enhance operation with some driver Madwifi will eventually propagate to testing, and the wpa_supplicant version in same archive will not support it. Also, there have been no bug reports since last upload indicating large problems with functionality. (I realise it is still early days) You may be able to refute my minor points of discussion for *not* freezing propagation with a strong argument *to* freeze it, so I will wait patiently for that :-) I am confident that the 0.5 series will be tagged as stable by Jouni before the time that Etch is released (quite a few months away yet, iirc), therefore, I'd like to concentrate more on testing and developing infrastructure around 0.5 before that time comes. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374342: Needs more testing
Reinhard Tartler wrote: Madwifi will eventually propagate to testing, and the wpa_supplicant version in same archive will not support it. You mean Version 0.svnr1644.0.9.0-2? Perhaps we can coordinate transition of the two packages? On the other hand, we can tell users to install wpasupplicant .deb from unstable in their testing system. I do not think that extra co-ordination would be worth the effort here, I am sure we can guide these people to the correct sources during this relatively short period of time. Also, there have been no bug reports since last upload indicating large problems with functionality. (I realise it is still early days) I remember #373776, which was bounced from Elimar Riesebieter [EMAIL PROTECTED] to pkg-wpa-devel. Ok, this is a madwifi-ng bug. Bugs which directly relate from the 0.5 branch did not appear yet. That would almost definitely be madwifi specific (unfortunately). To bring up my reservations to this list (I already mentioned them on irc). I think the 0.5 branch is a bit dangerous, because: a) the 0.5 branch didn't get as much test coverage than the 0.4 branch. Bugs are more likely. b) Semantic changes in the code of new features, which are still under development. I fear that behavior changes may disrupt our package c) config file changes like mentioned above. Ack. I am confident that the 0.5 series will be tagged as stable by Jouni before the time that Etch is released (quite a few months away yet, iirc), therefore, I'd like to concentrate more on testing and developing infrastructure around 0.5 before that time comes. Yes, afaik, etch is currently targeted for december this year. I think that we are both (well, espec. you ;) active enough to stabilize a wpasupplicant 0.5 for etch release. So yes, I mostly agree with you. I'd still appreciate if we could have the 0.5 branch tested for say, 2 more weekends and wait for reports. I don't expect many bugs, but I'm rather conservative for users of 'testing'. Yep, and I agree with the extended period of testing too. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364582: [Pkg-spca5xx-devel] Bug#364582: spca5xx-modules-i386: Recommend on non-Debian package
Joerg Jaspert wrote: Package: spca5xx-modules-i386 Severity: serious Hi Your binaries contain a line Recommends: spcacat, spcaview, spcaserv, but Im unable to find those packages in Debian (or in Provides). Thats against Policy 2.2.1. --8schnipp-8--- In addition, the packages in main * must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package) --8schnapp-8--- Indeed, and apologies. Those recommends snuck into control.modules.in of the spca5xx-source package in my over-anxiousness to have spcaview in debian. Fixed in pkg-spca5xx SVN. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362265: madwifi: FTBFS on mipsel
Kel Modderman wrote: Aurelien Jarno wrote: Package: madwifi Version: 0.svn20060207-4 Severity: serious Justification: no longer builds from source Trying to builf madwifi version 0.svn20060207-4 on mipsel, I have seen it now fails to build from source: rm -rf debian/patched /usr/bin/make -C tools clean make[1]: Entering directory `/home/aurel32/madwifi/madwifi-0.svn20060207/tools' ../Makefile.inc:203: ../hal/public/mips-elf.inc: No such file or directory make[1]: *** No rule to make target `../hal/public/mips-elf.inc'. Stop. make[1]: Leaving directory `/home/aurel32/madwifi/madwifi-0.svn20060207/tools' make: *** [clean] Error 2 The problem was already there in the previous version, but the error was ignored. Therefore I suggest to make the following change: diff -u madwifi-0.svn20060207/debian/rules madwifi-0.svn20060207/debian/rules --- madwifi-0.svn20060207/debian/rules +++ madwifi-0.svn20060207/debian/rules @@ -41 +41 @@ -$(MAKE) -C tools clean +-$(MAKE) -C tools clean My intention was to make the upstream tools/Makefile _never_ call Makefile.inc. I will look into this some more this weekend. Thanks for the report. Kel. Okay, the clean target is being called first, before the dirty Makefile is patched. Ignoring this error is okay (for now) with the suggested fix. Will make that change for the next upload, thanks. madwifi-ng has been cleaned up in this regard, therefore this will not cause problems when we switch to those sources. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362265: madwifi: FTBFS on mipsel
Aurelien Jarno wrote: Package: madwifi Version: 0.svn20060207-4 Severity: serious Justification: no longer builds from source Trying to builf madwifi version 0.svn20060207-4 on mipsel, I have seen it now fails to build from source: rm -rf debian/patched /usr/bin/make -C tools clean make[1]: Entering directory `/home/aurel32/madwifi/madwifi-0.svn20060207/tools' ../Makefile.inc:203: ../hal/public/mips-elf.inc: No such file or directory make[1]: *** No rule to make target `../hal/public/mips-elf.inc'. Stop. make[1]: Leaving directory `/home/aurel32/madwifi/madwifi-0.svn20060207/tools' make: *** [clean] Error 2 The problem was already there in the previous version, but the error was ignored. Therefore I suggest to make the following change: diff -u madwifi-0.svn20060207/debian/rules madwifi-0.svn20060207/debian/rules --- madwifi-0.svn20060207/debian/rules +++ madwifi-0.svn20060207/debian/rules @@ -41 +41 @@ - $(MAKE) -C tools clean + -$(MAKE) -C tools clean My intention was to make the upstream tools/Makefile _never_ call Makefile.inc. I will look into this some more this weekend. Thanks for the report. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360387: [pkg-wpa-devel] Bug#360387: init script gone
What would people say to providing an init daemon for wpasupplicant in a separate binary package, for example, wparoamd or so? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351658: [Pkg-spca5xx-devel] Bug#351658: spca5xx-modules-2.6-k7-smp: doesn't depend on the corresponding kernel package
Gerfried Fuchs wrote: * Kel Modderman [EMAIL PROTECTED] [2006-02-07 06:15]: Gerfried Fuchs wrote: Furthermore, a mailinglist -request address as maintainer address is a *very* bad idea, I seriously hope you consider changing that, too. I did not see this in our sources anywhere, can you please be more specific about this problem? Maintainer: Debian spca5xx Maintainers [EMAIL PROTECTED] You seem to have used it for your initial package and changed it later. The data is stored in the override file maintained by the ftp master team, you are receiving a mail about this difference with every upload. I see it in the Packages files distributed in our archive, you need to reply to the mail about this changes and tell the ftp master team that the change is needed, this isn't done automatically. So long, Alfie Cheers Alfie, the bug was found (rather embarrisingly) and fixed. The binary module control template was incorrect in spca5xx-source. So hopefully Otavio will find a moment to upload the fixed *versions* soon. Depends issue was also fixed, pending Otavio's nod of approval. Is that action sufficient? (not sure about dealing directly with the ftp masters) Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351658: [Pkg-spca5xx-devel] Bug#351658: spca5xx-modules-2.6-k7-smp: doesn't depend on the corresponding kernel package
Gerfried Fuchs wrote: Package: spca5xx-modules-2.6.15-1-686 Version: 20060101+1 Severity: serious Justification: Policy 7.2 Hi! The modules packages slipped into testing because they don't depend on their corresponding kernel images they are built against. They don't make any sense standalone without their kernel, thus please add a Depends on the kernel-image to them. Yes, very bad mistake indeed, apologies and this should be fixed in our working copy. Furthermore, a mailinglist -request address as maintainer address is a *very* bad idea, I seriously hope you consider changing that, too. I did not see this in our sources anywhere, can you please be more specific about this problem? Maintainer: Debian spca5xx Maintainers [EMAIL PROTECTED] So long, Alfie Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
