Bug#968460: ceni: udevadm and iwgetid not in /sbin
Package: ceni Version: 2.33-2 Severity: important Dear Maintainer, I wanted to configure /etc/network/interfaces and scan for wifi networks from a bare bones Debian Sid installation. Ceni was not able to detect any network interfaces to display them in UI and I was unable to scan for wifi networks or configure e/n/i. I expected Ceni to auto detect my network interfaces using udevadm, however udevadm has moved from /sbin to /usr/sbin. Also, /sbin/iwgetid belongs to wireless-tools which has not been relevant for many years, support for it could be removed at the same time. I suggest to: 1) Depend on libfile-which-perl and call File::Which::which() to find udevadm executable in PATH 2) Remove support for iwgetid 3) Depend on versions of udev package >= that which dropped the udevinfo executable A basic patch is attached to give an idea. Thanks for maintaining Ceni in Debian, I appreciate it. Cheers, Kel -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ceni depends on: ii ifupdown 0.8.35+b1 ii libcurses-ui-perl 0.9609-1 ii libexpect-perl1.21-1 ii libterm-readkey-perl 2.38-1+b1 ii perl 5.30.3-4 ii wpasupplicant 2:2.9.0-13 Versions of packages ceni recommends: ii resolvconf 1.82 Versions of packages ceni suggests: pn wpagui -- no debconf information ceni_udevadm_iwgetid.patch Description: Binary data
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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663971: $named dependency in init script and pdns
Hi insserv maintainers, there seems to be a problem with apache2's dependency on $named if pdns is installed but not enabled [1]. This does not seem to be a problem with other name servers. pdns ships /etc/insserv.conf.d/pdnsd with $named pdnsd Should this be fixed in pdnsd by adding the +, like other name service entries in /etc/insserv.conf? This. When there are many services that can each independently provide a virtual service, it has been customary to make them optional by prefixing with '+' as in /etc/insserv.conf Curious though, how has pdns been disabled in your case? Thanks, Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690536: [pkg-wpa-devel] Bug#690536: wpasupplicant does not enable AP mode at compile time
Hi Patrik, Package: wpasupplicant Version: 1.0-3 wpa_supplicant doesn't enable Access Point mode compile-time configuration option anymore. The debian/changelog file says AP mode was enabled in version 0.7.3-1, but doesn't mention the feature being intentionally disabled after that. Access point mode is needed by ConnMan to enable tethering over WiFi. It is also needed by any other network management software, e.g. NetworkManager, which intends to support tethering over WiFi. Thus it would be nice to have it enabled by default. It looks like we mucked up here when updating from 0.7 - 1.0 the build configuration was overhauled. I think that the fact that upstream defconfig omits CONFIG_AP tricked us into leaving it out. This creates an untimely problem though, this may not be a category of bug which qualifies for release team exception at this very late time in the release cycle. Here is a patch to re-enable AP mode: diff -ru a/debian/config/wpasupplicant/kfreebsd b/debian/config/wpasupplicant/kfreebsd --- wpa-1.0_old/debian/config/wpasupplicant/kfreebsd 2012-10-08 19:32:27.0 +0300 +++ wpa-1.0_new/debian/config/wpasupplicant/kfreebsd 2012-10-15 12:51:21.735613929 +0300 @@ -469,3 +469,6 @@ # XXX: Debian #650834 CONFIG_BGSCAN_SIMPLE=y + +# Enable access point mode +CONFIG_AP=Y diff -ru a/debian/config/wpasupplicant/linux b/debian/config/wpasupplicant/linux --- wpa-1.0_old/debian/config/wpasupplicant/linux 2012-10-08 19:32:27.0 +0300 +++ wpa-1.0_new/debian/config/wpasupplicant/linux 2012-10-15 12:50:44.977185881 +0300 @@ -468,3 +468,6 @@ # XXX: Debian #650834 CONFIG_BGSCAN_SIMPLE=y + +# Enable access point mode +CONFIG_AP=Y With the above configuration change, AP mode support is restored. I don't know whether the same configuration switch is to be applied for the udebs or not. No they should not, not a feature that the installer would be interested in. Thanks, Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683802: [Pkg-sysvinit-devel] Bug#683802: sysvinit: Lintian: E: init.d-script-should-depend-on-virtual-facility [patch]
Hi Sven I am pretty sure the initscripts scripts should not have more dependencies on $remote_fs, and that the lintian check do not apply here. The init.d scripts in initscripts are the framework for the other script to build upon, and the general rules often do not appyl. Incidentally, /etc/insserv.conf lists mountnfs-bootclean as a dependency of $remote_fs, but mountall-bootclean is not a dependency of $local_fs. Should it be? I don't think it needs to be that explicit, $remote_fs is a superset of $local_fs Thanks, Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573004: insserv: Please provide machine parseable output
Hi Roger, This patch has been tested, and we now have a patch for file-rc's update-rc.d which makes use of it. Would it be possible to enable this in a new upload so the file-rc change can go in? This will enable dependency-based boot in file-rc and enable deprecation and removal of sequence numbers in update-rc.d for wheezy+1. Feel free to upload a new version of insserv with this patch included, and make sure to try to get it included in upstream too. You are the most active sysvinit maintainer in Debian these days, so I consider you a co-maintainer of insserv. :) As long as the testsuite in insserv succeeds, a new upload is ok with me. It is great if you can ensure the new feature is tested in the testsuite. If you want, I can make the changes to insserv package if you'd be okay with sponsoring the result? Thanks, Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653515: [pkg-wpa-devel] Bug#653515: Very chatty in syslog; message every time rekeying occurs
Hi Josh, wpa_supplicant logs a message like this to syslog every time WPA group rekeying occurs: Dec 24 08:26:16 leaf wpa_supplicant[1319]: WPA: Group rekeying completed with AP:MA:CA:DD:RE:SS [GTK=CCMP] On a network configured to rekey frequently, this generates a large number of syslog message, drowning out more useful log messages. Does wpa_supplicant really need to log every time rekeying occurs? You can configure the logging verbosity through your /etc/network/interfaces stanza on a per interface basis, quoting from /usr/share/doc/wpasupplicant/README.Debian.gz: [snip] Rekeying events are at MSG_INFO severity, setting wpa-debug-level to -1 will raise the bar to MSG_WARNING and hide all rekeying notices (which are still readable in e.g. wpa_cli) from the logs. I appreciate the pointer to information on how to make this message go away on my system, but I intended the bug report as a request to make wpa_supplicant less chatty by default. My question above still applies: Does wpa_supplicant really need to log every time rekeying occurs? No What value does this provide? Not much to me Could this message become something that only appears at -v or above, rather than by default? Yep, sure could Now we just need this report summarised and sent to hos...@lists.shmoo.com to get something done about it. Thanks, Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657332: Please enabled hardened build flags
tags 657332 pending thanks Hi Simon, reopen 657332 thanks Dear Maintainer, The CPPFLAGS hardening flags are still missing because they are ignored by the build system. For more hardening information please have a look at [1], [2] and [3]. Thanks for the patch it is applied. Stefan and I discusssed this yesterday, he believed that dh 9 would allow us to remove some of the dpkg-buildflags usage we had, I made some tests and told him se still needed it ... I was wrong :) Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594917: The future of non-dependency-based boot
]] Kel Modderman ]] Roger Leigh I'm not sure myself. Probably because it's potentially dangerous since it would want to replace it with a symlink, and that might result in dataloss. Do you have an example of the virtual facility problem? Why would it want to replace it with a symlink? AIUI, insserv just renames the files in /etc/rcN.d ? No insserv doesn't just rename files it removes/recreates symlinks as needed depending on change to the computed dependecy graph when adding/removing a node. Why will it ever remove a file? It removes symlinks and creates new ones with an updated sequence number when the sequence number changes dues to adding/removing a new script, it doesn't remove regular files when present in symlink farm it ignores them. The current behaviour is to ignore regular files which are installed to the symlink farm, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493202#85 That doesn't look like a particularly good reason to ignore regular files vs symlinks? This reference was to give previous history on the sub-topic we're talking about (a regular file in symlink farm), not to give reason to another shit behaviour of insserv but xplain how the current behaviour came to be. Having random regular files in amongst a symlink farm which is dynamically created dependning on service set installed is a recipe for mess and I cannot think of a clean way to handle the situation other than conveying a message that says Don't do that please use update-rc.d to register your service and create start/stop links with optimised priority depending on your current service set - but thats getting a bit wordy for a one line message ... There's no reason for the message to be a single line. True, thanks for the tip. I'm happy to extend the warning to something more verbose if given a clue what people would rather read in this case. For the latter, I seem to have: : tfheen@qurzaw /etc/init.d grep Provides bootlog* bootlogd:# Provides: bootlogd bootlogs:# Provides: bootlogs bootlogs.sh:# Provides: bootlogs which makes it complain about something already provided. One of those scripts (bootlogs/ bootlogs.sh) must be an orphan conffile ? That shouldn't matter to insserv, but yes, one of them is an orphan. And it does matter - you may hate the design but that's the way it is - scripts cannot co-exist when they provide the same facility, unless they are grouped into virtual facilities. Look I love insserv as much as the next man, its not going to change much semantically between now and the time a modern init system can become the boot system for Debian because its not worth throwing excess time and effort down that sysvinit path. Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594917: The future of non-dependency-based boot
]] Roger Leigh I'm not sure myself. Probably because it's potentially dangerous since it would want to replace it with a symlink, and that might result in dataloss. Do you have an example of the virtual facility problem? Why would it want to replace it with a symlink? AIUI, insserv just renames the files in /etc/rcN.d ? No insserv doesn't just rename files it removes/recreates symlinks as needed depending on change to the computed dependecy graph when adding/removing a node. The current behaviour is to ignore regular files which are installed to the symlink farm, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493202#85 Having random regular files in amongst a symlink farm which is dynamically created dependning on service set installed is a recipe for mess and I cannot think of a clean way to handle the situation other than conveying a message that says Don't do that please use update-rc.d to register your service and create start/stop links with optimised priority depending on your current service set - but thats getting a bit wordy for a one line message ... For the latter, I seem to have: : tfheen@qurzaw /etc/init.d grep Provides bootlog* bootlogd:# Provides: bootlogd bootlogs:# Provides: bootlogs bootlogs.sh:# Provides: bootlogs which makes it complain about something already provided. One of those scripts (bootlogs/ bootlogs.sh) must be an orphan conffile ? Both of these are insserv bugs rather than sysv-rc bugs, BTW, so reassigning. Sure. Not so sure. Thanks, Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560222: [Pkg-sysvinit-devel] Bug#560222: insserv: How to disable a service permanently?
Hi Andreas, On Saturday, April 14, 2012 01:14:03 you wrote: insserv is the wrong interface to disable services. insserv -r *removes* links to services and that's exactly what it does, it does not disable the links from ever returning and never will be extended to do that. Update-rc.d has an interface for disabling initscript execution, though arguably this interface should be in the service(8) command. This was mentioned earlier in the bug report. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560222#10 Thanks, Kel i see, i was under the wrong impression that insserv and update-rc.d did the same thing, and that using update-rc.d was deprecated. so 'insserv -r' is like 'update-rc.d remove', but what i really should do is 'update-rc.d disable', which creates 'stop' links rather than deleting 'start' links. Exactly. insserv should never need to be called directly, update-rc.d continues to be the interface for all things related to adding/removing(/disabling) init scripts. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560222: [Pkg-sysvinit-devel] Bug#560222: insserv: How to disable a service permanently?
Hi Andreas the bug still exists in stable (version 1.14.0-2) and from what i remember also in testing. steps to reproduce: 1) insserv -r service 2) aptitude full-upgrade result: service is running again if the service was in the upgrade may i propose this be more than wishlist: for one, the expected behavior is that package upgrades do not override user- made system configurations without asking (this is the case at least when dealing with config files from what i've seen). disabling a service with insserv is, from a user view, just as much part of a system configuration as editing some .conf file, hence should be respected just as much. insserv is the wrong interface to disable services. insserv -r *removes* links to services and that's exactly what it does, it does not disable the links from ever returning and never will be extended to do that. Update-rc.d has an interface for disabling initscript execution, though arguably this interface should be in the service(8) command. This was mentioned earlier in the bug report. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560222#10 Thanks, Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614895: [Pkg-sysvinit-devel] Bug#614895: sysv-rc: Warning in update-rc.d swaps script and LSB Default values?
Hi All,
I think a better warning would be something like this:
update-rc.d: warning: default start runlevel arguments (2 3 4 5) do not match
foobar Default-Start values (2 3 5)
update-rc.d: warning: default stop runlevel arguments (0 1 6) do not match
foobar Default-Stop values (0 1)
A new patch would look something like:
--- update-rc.d 2011-02-23 18:40:15.0 -0800
+++ /usr/sbin/update-rc.d 2011-02-24 00:44:43.043783266 -0800
@@ -480,6 +480,7 @@
my ($name, $act) = (shift, shift);
my ($lsb_start_ref, $lsb_stop_ref, $arg_str, $lsb_str);
my (@arg_start_lvls, @arg_stop_lvls, @lsb_start_lvls, @lsb_stop_lvls);
+my $default_msg = ($act eq 'defaults') ? 'default' : '';
($lsb_start_ref, $lsb_stop_ref) =
parse_def_start_stop(/etc/init.d/$name);
@lsb_start_lvls = @$lsb_start_ref;
@@ -523,15 +524,15 @@
join(\0, sort @arg_start_lvls) ne join(\0, sort
@lsb_start_lvls)) {
$arg_str = @arg_start_lvls ? @arg_start_lvls : none;
$lsb_str = @lsb_start_lvls ? @lsb_start_lvls : none;
-warning $name start runlevel arguments ($arg_str) do not match,
-LSB Default-Start values ($lsb_str);
+warning $default_msg start runlevel arguments ($arg_str) do not
match,
+$name Default-Start values ($lsb_str);
}
if ($#arg_stop_lvls != $#lsb_stop_lvls or
join(\0, sort @arg_stop_lvls) ne join(\0, sort @lsb_stop_lvls)) {
$arg_str = @arg_stop_lvls ? @arg_stop_lvls : none;
$lsb_str = @lsb_stop_lvls ? @lsb_stop_lvls : none;
-warning $name stop runlevel arguments ($arg_str) do not match,
-LSB Default-Stop values ($lsb_str);
+warning $default_msg stop runlevel arguments ($arg_str) do not
match,
+$name Default-Stop values ($lsb_str);
}
}
What do you think?
I agree with the patch, Roger would it possible to include this patch in
sysvinit git please?
Thanks, Kel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661314: [Pkg-sysvinit-devel] Bug#661314: insserv: script foo is not an executable regular file, skipped!
Package: sysv-rc Version: 2.88dsf-22 Severity: minor Justification: confusing message Hi, If I do: apt-get install vsftpd service vsftpd stop chmod -x /etc/init.d/vsftp update-rc.d vsftpd disable then the last command produces: update-rc.d: using dependency based boot sequencing insserv: script vsftpd is not an executable regular file, skipped! However vsftpd was not skipped --- the update-rc.d vsftpd disable command behaves exactly the way I'd have wanted, even after the init script is marked executable again. Does it really do what you wanted? Were the S links for vsftp changed to K links in its start runlevels (properly disabled) or were they removed alltogether (not really disabled, technically incosistent state)? Whats ls /etc/rc*.d/*vsftp say after doing these steps? What is this message intended to convey? Could it be reworded? It think its pretty stright forward, its complaining that the script it has been asked to work on is not executable. Thanks, Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638905: insserv doesn't allow init scripts to be symlinked to clone services
tags 638905 wontfix thanks Package: insserv Version: 1.14.0-2 Severity: wishlist While updating a set of local scripts for maintaining a custom SpamAssassin install to work on squeeze, I found that insserv treated a symlink in /etc/init.d to a parent init script also in /etc/init.d as if it were the parent, not a separate script. It would be nice if it didn't flatten the symlinks like this so that a single parent script can be used together with custom settings in /etc/default/child name to run multiple instances of a daemon without having to manually copy the script or package multiple copies of the same script under different names. Unfortunately this is an impossible situation with insserv dependency based boot. Every script must provide a unique facilty and when you symlink one script to another in the same init.d dir you will now have 2 scripts which provide the same facility, and by design insserv rejects this configuration. We made insserv ignore it rather than reject it a few years ago, see http://bugs.debian.org/485045. Thanks, Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661314: insserv: script foo is not an executable regular file, skipped!
Kel Modderman wrote: update-rc.d: using dependency based boot sequencing insserv: script vsftpd is not an executable regular file, skipped! [...] What is this message intended to convey? Could it be reworded? It think its pretty stright forward, its complaining that the script it has been asked to work on is not executable. Good. The problem is that it is saying it completely skipped it (which a naive user will interpret as meaning did nothing), and that is simply not true. Sort of, maybe. (what about the other questions? :)) The non-executable script gets ignored, then later when insserv updates the symlink farm based on the overall dependency graph (which doesn't include the skipped script), symlinks to scripts which do not exist or are invalid are removed. Thanks, Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666212: insserv does not cross-build. Wrong compiler used and DEB_BUILD_OPTIONS=nocheck not supported
On Thu, Mar 29, 2012 at 07:33:19PM +0100, Wookey wrote:
diff -urN origs/insserv-1.14.0/debian/patches/130_crossbuild_fixes.patch
patched/insserv-1.14.0/debian/patches/130_crossbuild_fixes.patch
+Index: insserv-1.14.0/Makefile
+===
+--- insserv-1.14.0.orig/Makefile 2012-03-29 19:02:05.0 +0100
insserv-1.14.0/Makefile 2012-03-29 19:03:01.0 +0100
+@@ -38,7 +38,6 @@
+ LDFLAGS += -Wl,--as-needed
+LIBS += -lrpm
+ endif
+- CC = gcc
+ RM = rm -f
+ MKDIR = mkdir -p
+ RMDIR = rm -rf
This chunk is unnecessary. You can already override make variable
assignments on make's command line; variable assignments like this just
set defaults and are harmless for your purposes. Since this kind of
default is a very common pattern in Makefiles, it would be best to avoid
getting into the habit of believing that it needs to be changed to
support cross-building.
As it goes I agree with the intention of this patch, it'd be nice if the
Makefile honored the environment's CC (and COPTS and LDFLAGS for that matter).
Upstream could just as easily use:
CC ?= gcc
And all of us would be happy.
Thanks, Kel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667416: wpasupplicant: ftbfs with GCC-4.7
tag 667416 patch thanks Matthias Klose d...@debian.org (03/04/2012): Package: wpasupplicant Version: 0.7.3-6 Severity: important Tags: sid wheezy User: debian-...@lists.debian.org Usertags: ftbfs-gcc-4.7 Hi, please find attached a patch to fix this FTBFS. FTR, I don't plan to NMU. Thanks both for the bug report/patch. Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657332: Please enabled hardened build flags
tags 657332 pending thanks On Wed, Jan 25, 2012 at 06:44:52PM +0100, Moritz Muehlenhoff wrote: Package: hostapd Version: 1:0.7.3-4 Severity: important Tags: patch Please enabled hardened build flags through dpkg-buildflags. Patch attached. What's the status? Do you plan an upload in the next weeks or shall I upload a NMU? Hi Moritz, We plan to do an upload with much larger changes in mind, we will include the below changes which should have similar effect to what you proposed: --- Index: debian/rules === --- debian/rules(revision 1712) +++ debian/rules(working copy) @@ -1,9 +1,11 @@ #!/usr/bin/make -f -CFLAGS = -MMD -Wall -g +CFLAGS = -MMD -Wall +CFLAGS += $(shell dpkg-buildflags --get CFLAGS) +CPPFLAGS += $(shell dpkg-buildflags --get CPPFLAGS) +CXXFLAGS = $(shell dpkg-buildflags --get CXXFLAGS) UCFLAGS = -MMD -Wall -g -Os -CXXFLAGS = -g -LDFLAGS = -Wl,--as-needed +LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS),--as-needed BINDIR = /sbin V = 0 @@ -15,7 +17,7 @@ CXXFLAGS += -O2 endif -export CFLAGS CXXFLAGS LDFLAGS BINDIR V +export CFLAGS CPPFLAGS CXXFLAGS LDFLAGS BINDIR V DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) HOSTAPD_DOT_CONFIG:= debian/config/hostapd/$(DEB_HOST_ARCH_OS) --- Thanks, Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666212: insserv does not cross-build. Wrong compiler used and DEB_BUILD_OPTIONS=nocheck not supported
On Thu, Mar 29, 2012 at 07:33:19PM +0100, Wookey wrote: diff -urN origs/insserv-1.14.0/debian/patches/130_crossbuild_fixes.patch patched/insserv-1.14.0/debian/patches/130_crossbuild_fixes.patch +Index: insserv-1.14.0/Makefile +=== +--- insserv-1.14.0.orig/Makefile 2012-03-29 19:02:05.0 +0100 insserv-1.14.0/Makefile2012-03-29 19:03:01.0 +0100 +@@ -38,7 +38,6 @@ + LDFLAGS += -Wl,--as-needed + LIBS += -lrpm + endif +- CC = gcc +RM = rm -f + MKDIR = mkdir -p + RMDIR = rm -rf This chunk is unnecessary. You can already override make variable assignments on make's command line; variable assignments like this just set defaults and are harmless for your purposes. Since this kind of default is a very common pattern in Makefiles, it would be best to avoid getting into the habit of believing that it needs to be changed to support cross-building. (The rest looks sensible to me, though I'm not a Debian insserv maintainer.) The rest looks sensible to me too, I'm a (co)maintainer but it doesn't make my opinion much more qualified than your own :) Thanks both for your patch + comment. Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660824: [Pkg-sysvinit-devel] Bug#660824: sysvinit: Please include support for upstart in startpar
Hi Steve, Package: sysvinit Version: 2.88dsf-22 Severity: wishlist Hi there, It seems that the discussion about this patch petered out long ago on pkg-sysvinit-devel (http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2011-October/005345.html), so it's probably time to submit a proper bug report to the BTS (especially since sysvinit appears to be under new maintenance). Pursuant to bug #591791 against Debian Policy about permitting alternate init systems in Debian, I've prepared a patch against sysvinit which would make startpar aware that a given job is implemented as an upstart job instead of a SysV init script and that startpar should defer to upstart to satisfy the dependency. This enables insserv/startpar-based dependency boot to be used for sysvinit in conjunction with upstart as /sbin/init and native upstart jobs as dependencies, and is the first step towards having upstart be genuinely usable on Debian. It also rolls back the previous /lib/init/upstart-job approach, which never worked right with startpar due to the inability to express dependency information. As a result, packages shipping upstart jobs should now ship real init scripts in parallel (per the policy bug discussion), which means some changes to debhelper are wanted before this goes into effect. It does *not* allow bidirectional dependencies between upstart jobs and init scripts. It's assumed that a system that runs upstart will be converted from the bottom up - starting with rcS.d, which more or less needs to be converted as a block anyway. I've tested this patch to be regression-free on sysvinit as well as working with upstart, and verified that the package still builds on non-Linux Debian ports after applying (upstart doesn't run there anyway, so it's a simple #ifdef :P). I've also taken care to avoid adding any new runtime library dependencies here; it would have been nice to use libdbus for talking to upstart, but I guess some might resist such a change. :-) This seems like a nice approach to me and thanks for driving this forward. The patch includes two mostly unrelated changes that warrant a mention: - debian/rules has been patched to pass CFLAGS from dpkg-buildflags to the startpar makefile. Not really related, but was invaluable for having a proper debug build when testing. - The patch to startpar.c includes a change to call checkdevpts() early on. this is a bugfix in its own right; unless devpts support is checked at the top of the loop, tasks will be launched as interactive, meaning they won't be run in parallel. This at least impacts the first process launched, I haven't checked if it affects others. Apparently SuSE never had to deal with this bug because the runtime devpts checking code was ifdef'ed out there. In any case, I found a strange interaction between interactive tasks and upstart jobs; so this fix is something of a prerequisite (and may indicate a latent bug in my patch). Good catch. SuSE mount /dev/pts in very early boot (initramfs) therefore do not require the hack. We had to patch Debian's startpar for this though to get away from the shell based init.d script execution concurrency which existed at the time. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659955: [Pkg-sysvinit-devel] Bug#659955: update-rc.d: add option to specify alternative root (like insserv -p)
Package: sysv-rc Version: 2.88dsf-22 Severity: wishlist Please add an option like insserv -p or chkconfig --root to specify an alternative root for the init scripts. This would be useful for testing and for fixing other file systems. For what its worth I proposed, and wrote code for, something to this a few years ago: http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2008-July/002749.html That small thread went on to discuss the virtues of offering a 0/N patch series email which was not so helpful, and so I decided to forget about it ever since. If you'd like to revive or discuss that patch I'm all ears. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659933: [Pkg-sysvinit-devel] Bug#659933: sysvinit: system locks up during boot
Hi Brian, Package: sysvinit Version: 2.88dsf-22 Severity: important Dear Maintainer, My desktop is no longer usable unless I boot from a live cd. After grub, boot proceeds for a bit, stalls, and then spits out quite a bit of text. I'm assuming this is some sort of serious kernel panic since not even magic-sysrq function. The last page of output is composed of 8 columns filled with numbers followed by a column of process names. The process names on the last page alternate between 'modprobe' and 'sh'. I'm unsure which package is truly responsible for this bug since it happens so fast during boot time. Though this is a problem that was introduced relatively recently; first noticed this morning. I don't believe the kernel itself is reponsible either since the bug is present in both 3.2 and 3.1 (only two kernels on my system ATM) Sorry for the lack of information I provided. Let me know if there's anything further I can do to resolve this. If it is a kernel panic, then the bug probably has very little to do with the sysvinit package at all and should probably be reassigned to linux-image-flavour for the best chance of meaningful support. I've always found it difficult to capture kernel panic information, and have usually taken a photograph of the monitor as best I can at that point. It may help if it is clear enough to read the text, it may give someone with a bit of experience a clue as to what is playing up. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633026: hostapd: /run transition: Please switch to /run/sendsigs.omit.d
Hi Roger, On Thu, Jul 07, 2011 at 11:23:29PM +0100, Roger Leigh wrote: Source: hostapd Version: 1:0.7.3-2 Severity: important Your package is currently using/lib/init/rw/sendsigs.omit.d which is now deprecated and pending removal. Please update your package to use /run/sendsigs.omit.d with a versioned dependency on initscripts, as detailed below. I was about to prepare a patch for this, but saw it was fixed in SVN back in July, but it looks like it was never uploaded. Would it be possible to do that? I've prepared a package for upload, it requires sponsorship. If you are comfortable sponsoring this upload it'd be great, most of the changes are in reaction to /run. The source package can be found on mentors: http://mentors.debian.net/debian/pool/main/h/hostapd/hostapd_0.7.3-3.dsc Changes: hostapd (1:0.7.3-3) unstable; urgency=low . [ Kel Modderman ] * Use /run/sendsigs.omit.d/ for sendsigs omission pid file and depend on initscripts (= 2.88dsf-13.3). (Closes: #633026) * Migrate existing sendsigs omission pid files from /lib/init/rw to /run. * Add a loop to ifupdown.sh to wait for creation of hostapd pid file before attempting creation of sensigs omission pid file, in some cases hostapd daemon can return before creation of the pid file has been written to disk. * Adjust standards version to 3.9.2, no further changes required to satisfy that. * Only test that DAEMON_CONF is set in init.d script, do not test if what is set is readable (which assumes only one configuration file is being used). (Closes: #615821) . [ Stefan Lippers-Hollmann ] * use new anonscm URIs for alioth. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646329: [pkg-wpa-devel] Bug#646329: /etc/hostapd/ifupdown.sh does not have proper mode bits
tags 646329 moreinfo thanks Package: hostapd Version: 1:0.7.3-2+b1 /etc/hostapd/ifupdown.sh should have execute bits or hostapd fields in /etc/network/interfaces don't work. The executable bit is clearly set during package build via debian/rules override. After unpacking an hostapd binary .deb I found the permissions to be: -rwxr-xr-x 1 kelmo kelmo 3097 Feb 27 2010 ./etc/hostapd/ifupdown.sh Has something else modified your system? What permissions did actually cause you to report this? Can you please elaborate a bit more? Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645540: [Pkg-sysvinit-devel] Bug#645540: Essential package conflict between sysvinit and systemd-sysv
Well, that seems ironic, in that I would have expected the sytemd maintainer himself to have some keener interest in finally resolving this packaging problem. snip I don't claim to be a Debian packaging expert. I've only looked through the documentation. snip There will have to be some changes in the package configuration of both sysvinit and systemd-sysv - sooner or later. snip Discussions like #591791 show that there is a lot of groundwork to lay before alternative boot systems can be expressed in terms of packaging in Debian. I do not see further discussion happening here unless you manage to frame questions without disrespect. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641107: [Pkg-sysvinit-devel] Bug#641107: sysvinit: missing support for s390x
On Sat, 10 Sep 2011 09:36:17 PM Aurelien Jarno wrote: Package: sysvinit Version: 2.88dsf-13.11 Severity: normal Tags: patch User: debian-s...@lists.debian.org Usertags: s390x sysvinit builds fine on s390x, but it needs the same fixes as on s390, that is a slightly different inittab and spinners removal due to the dumb console available on s390x. The patch below fixes that. Please note that for the spinner removal it simply replaces s390 by s390x as anyway Debian now only supports 64-bit kernel on s390, so 'uname -m' returns 's390x' on both s390 and s390x. Would it be possible to include this patch in the next upload? Thanks in advance. Your patch has been applied. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640773: Fwd: RE: Bug#640773: Bug with LSB Overrides in INNSERV package
This needs to be copied to the bug, not just myself. You script is missing LSB information, please see http://wiki.debian.org/LSBInitScripts for information about what must be added to the init script for it to be LSB compliant. Something like this: ### BEGIN INIT INFO # Provides: confluence # Required-Start:$remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Description: Enable confluence blah blah blah ### END INIT INFO Thanks, Kel. -- Forwarded Message -- Subject: RE: Bug#640773: Bug with LSB Overrides in INNSERV package Date: Fri, 9 Sep 2011, 08:15:23 AM From: Grant Davies grant.dav...@webqem.com To: Kel Modderman k...@otaku42.de Sincerest apologies - attached now. -- Grant Davies www.webqem.com e. grant.dav...@webqem.com m. +61 (0)402 570 313 p. +61 (0)2 8968 1669 -- webqem: weird name. outstanding online solutions development | ads | learning | training | software -- -Original Message- From: Kel Modderman [mailto:k...@otaku42.de] Sent: Friday, 9 September 2011 6:42 AM To: Grant Davies; 640...@bugs.debian.org Subject: Re: Bug#640773: Bug with LSB Overrides in INNSERV package On Wed, 7 Sep 2011 04:29:19 PM Grant Davies wrote: Package: insserv Output: root@hb-confluence-01:/etc/init.d# insserv confluence insserv: warning: script 'S99confluence' missing LSB tags and overrides insserv: warning: script 'confluence' missing LSB tags and overrides insserv: warning: current start runlevel(s) (2 3 5) of script `confluence' overwrites defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (empty) of script `confluence' overwrites defaults (0 1 6). insserv: There is a loop at service rc.local if started insserv: There is a loop between service rc.local and mountnfs if started insserv: loop involving service mountnfs at depth 6 insserv: loop involving service nfs-common at depth 5 insserv: There is a loop between service rc.local and checkroot if started insserv: loop involving service checkroot at depth 3 insserv: loop involving service mountdevsubfs at depth 2 insserv: loop involving service bootmisc at depth 10 insserv: Starting confluence depends on rc.local and therefore on system facility `$all' which can not be true! What happens when you remove the dependency on rc.local? The /etc/init.d/confluence file is attached. Was it? didn't see it. Thanks, Kel. - confluence Description: confluence
Bug#632790: Intention to activate libnl3 support in iw wpasupplicant - we expect bugs
Hi, Stefan and I intend to have iw and wpasupplicant use libnl3 in the next uploads. This bug will manifest itself as the binaries linked to libnl3 will generate spurious messages: # iw dev wlan1 scan Failed to read classid file: Object not found BSS xx:xx:xx:xx:xx:xx (on wlan1) ... # iw list Failed to read classid file: Object not found Wiphy phy0 ... We expect people to file bugs against iw/wpasupplicant about these messages even though the problem is here. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640773: Bug with LSB Overrides in INNSERV package
On Wed, 7 Sep 2011 04:29:19 PM Grant Davies wrote: Package: insserv Output: root@hb-confluence-01:/etc/init.d# insserv confluence insserv: warning: script 'S99confluence' missing LSB tags and overrides insserv: warning: script 'confluence' missing LSB tags and overrides insserv: warning: current start runlevel(s) (2 3 5) of script `confluence' overwrites defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (empty) of script `confluence' overwrites defaults (0 1 6). insserv: There is a loop at service rc.local if started insserv: There is a loop between service rc.local and mountnfs if started insserv: loop involving service mountnfs at depth 6 insserv: loop involving service nfs-common at depth 5 insserv: There is a loop between service rc.local and checkroot if started insserv: loop involving service checkroot at depth 3 insserv: loop involving service mountdevsubfs at depth 2 insserv: loop involving service bootmisc at depth 10 insserv: Starting confluence depends on rc.local and therefore on system facility `$all' which can not be true! What happens when you remove the dependency on rc.local? The /etc/init.d/confluence file is attached. Was it? didn't see it. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627622: [pkg-wpa-devel] Bug#627622: wpasupplicant: This package makes impossible to manually
On Mon, 23 May 2011 06:47:34 AM Pedro Larroy wrote: Package: wpasupplicant Version: 0.7.3-3 Severity: important *** Please type your report below this line *** This package makes impossible to connect manuallay to a wep encrypted wifi, it keeps reconfiguring the interface. Removing the package solves the problem. On the flip side, your bug report makes it impossible to reply meaningfully because there is absolutely no information provided. * device information * log of wpasupplicant output * what software is used to configure the network - succesful network configuration - failing network configuration Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630681: /usr/sbin/wpa_gui: When Using nl80211 wpa-driver, Signal Strength is Displayed as Zero
On Thu, 16 Jun 2011 07:26:40 PM Leo L. Schwab wrote: Package: wpagui Version: 0.7.3-3 Severity: normal File: /usr/sbin/wpa_gui When using wpa_gui to perform a scan for local WAPs, the signal strengths in the list of results will be diferent depending on what wpa-driver you've configured for that interface. In my case, wpa_supplicant can talk to the iwl3945 driver using wpa-driver 'wext' or the newer 'nl80211'. If you configure wext, then the results displayed by wpa_gui will have meaningful signal strengths There exist a few people who believe the WEXT signal quality measurements are crap - and that is why the quality property is always 0 with the nl80211 framework, it is not implimented there. displayed. If, however, you configure nl80211, then wpa_gui will display all signal strengths as zero. I did a little experiment using wpa_cli to look at the scan results. Here's a sample list of results using wpa-driver wext: bssid / frequency / signal level / flags / ssid 94:44:52:5a:11:4c 2412173 [WPA-PSK-CCMP][WPA2-PSK-CCMP][WPS][ESS] Belkin.3 14C 00:1b:2f:c4:c9:11 2462219 [WEP][ESS] ewhac-water 00:14:95:3e:f2:42 2437190 [WEP][ESS] 2WIRE303 00:1b:2f:c4:c9:10 2462219 [ESS] ewhac-air 00:1f:27:74:74:00 2462172 [ESS] local-wifi 00:1d:7e:57:49:e9 2437177 [WEP][ESS] linksys_SES_42522 00:16:b6:ce:b1:9f 2437175 [WEP][ESS] jvelez And here's a list of results using wpa-driver nl80211: bssid / frequency / signal level / flags / ssid 00:1b:2f:c4:c9:10 2462-32 [ESS] ewhac-air 00:16:01:92:e1:89 2417-83 [WPA-PSK-TKIP][ESS] BERLOGA-101 94:44:52:5a:11:4c 2412-83 [WPA-PSK-CCMP][WPA2-PSK-CCMP][WPS][ESS] Belkin.3 14C 00:1b:2f:c4:c9:11 2462-33 [WEP][ESS] ewhac-water 00:14:95:3e:f2:42 2437-62 [WEP][ESS] 2WIRE303 00:16:b6:ce:b1:9f 2437-78 [WEP][ESS] jvelez It seems evident that different signal strength units are returned from the two wpa-drivers, which is confusing wpa_gui. Please investigate this matter. A signal measurement in dBm is returned by the nl80211 driver. It could provide the basis for a more meaningful signal indicator in wpa_gui. There difficult part is that wpa_gui doesn't know which driver is being used so it is a little difficult to support two different signal/quality methods based on the information it does know. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610931: [pkg-wpa-devel] Bug#610931: Please build wpasupplicant-udeb
On Sat, 30 Jul 2011 06:25:00 AM Gaudenz Steinlin wrote: Excerpts from Kel Modderman's message of 2011-07-27 13:30:37 +0200: On Wed, 27 Jul 2011 02:43:02 AM Gaudenz Steinlin wrote: OK. How do you feel about me NMUing wpa_supplicant to add the udeb? I added an updated patch for the udeb to this mail. If you are OK I'll upload this as an NMU after libnl1-udeb enters the archive. I would be very happy for you to do that. After some more investigation we (I and Otavio) decided that we rather want to move wpasupplicant to build against libnl3. I guess this has to be done at some point anyway and it avoids to have to do the whole work again for libnl3. So we created a udeb for libnl3 and will upload this soon. I hope you agree to this change. If you are against it please reply soon. This is a far more invasive change than just adding the udeb. Please be prepared to pick up the pieces in case regression in stable functionality are introduced with such a change. Doing this when moving from wpa_supplicant 0.7.x - 0.8.x (not yet released) would be more appropriate in my opinion. I am less happy about this change, but do not oppose NMU's regardless of the risk, the rewards may be worth it. The only change needed in wpasupplicant for this is to set CONFIG_LIBNL20=y in the linux and udeb configs. And cross your fingers that it works just the same, without any noticable change to the end users. Gaudenz Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610931: Please build wpasupplicant-udeb
On Wed, 27 Jul 2011 02:43:02 AM Gaudenz Steinlin wrote: OK. How do you feel about me NMUing wpa_supplicant to add the udeb? I added an updated patch for the udeb to this mail. If you are OK I'll upload this as an NMU after libnl1-udeb enters the archive. I would be very happy for you to do that. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610931: Please build wpasupplicant-udeb
Hi,
On Mon, 25 Jul 2011 09:34:27 AM Gaudenz Steinlin wrote:
Has there been any solution for the netcfg integration already,
see 201011041811.11753@otaku42.de [1], referring to the
originally proposed introduction of embedded source copies of
wpasuppliant's wpa_ctrl.[hc] into netcfg. Please also keep in
mind that crda/ wireless-regdb is required for accessing
channels 11-13/14 on modern drivers.
I've applied the existing WPA netcfg support patches developed by
Glenn Saberton, and they do appear to include a (stripped down)
wpa_ctrl.c.
That stripped down crap probably was extracted from a sideline
project (python-wpactrl) I was working on, and is not good long term
solution.
wpa_ctrl.{c,h} from current wpasupplicant source tree have lots more
dependency on other stuff. Extracting and patching wpa_ctrl.{c,h} to
be standalone is something which should be avoided - I just do not
know how currently.
Asked upstream wpa_supplicant if wpa_ctrl could be provided in a way
where it could be a shared library but received no response.
Is there any progress on this?
Nope.
Do you think it's worth poking about this again? The current code in
netcfg works (at least for the debconf wpa-psk network), but a real
library would be nicer ;-).
It cannot hurt to ask. I've already asked before, so maybe someone else can
this time :).
I
have no idea what the story is with crda/wireless-regdb, as I said
before, I don't know anything about WPA. If you'd like to help
out, though, your knowledge would be greatly valued.
I wouldn't mind helping out, don't know how though, Have little idea
about D-I environment and took long enough to just reply to this
request to feel a little embarrassed.
Also haven't seen the proposed change to netcfg anytime in recent
past to comment further. Can that be reviewed?
It's in branch people/womble/wpa of
git://git.debian.org/git/d-i/netcfg.
Gaudenz
Thanks for the link.
Do you have time to look at the code in the next days? Otherwise I'll
probably just merge as it is now and we can fix things later if there
are problems.
Do not wait for any activity from me, I'm currently not very active with
Debian work - mostly keeping up with basic maintenace related tasks.
Not familiar with netcfg or the debian-installer environment at all yet.
I have another yet unresolved problem: With the proposed udeb
configuration from the original patch and using the netlink driver I can
connect to the network, but DHCP does not work. When I build a udeb with
the same
configuration as for the normal linux package minus DBUS and smartcard
support it works. Do you know which options I need to include to get a
package where DHCP also works with the netlink driver?
From the top of my head I do not know why you observe this difference in
behaviour. Where WEXT works, nl80211 should work and vice versa.
Thanks, Kel.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633040: [pkg-wpa-devel] Bug#633040: wpasupplicant: /run transition: Please switch to /run/sendsigs.omit.d
Hi Roger,
On Fri, 8 Jul 2011 08:39:53 AM Roger Leigh wrote:
Source: wpasupplicant
Version: 0.7.3-3
Severity: important
Your package is currently using/lib/init/rw/sendsigs.omit.d
which is now deprecated and pending removal. Please update your
package to use /run/sendsigs.omit.d with a versioned dependency
on initscripts, as detailed below.
An overview of the /run transition and its current progress is
available at http://wiki.debian.org/ReleaseGoals/RunDirectory
Basically, it's now in both testing and unstable, and the next
phase of the transition is to migrate all users of /lib/init/rw
over to /run and then remove /lib/init/rw entirely for wheezy
(as soon as this transition is complete).
Your package is one of the users of sendsigs.omit.d listed here:
http://wiki.debian.org/ReleaseGoals/RunDirectory#Packages_using_.2BAC8-lib.
2BAC8-init.2BAC8-rw
Recommendations for how to do the transition may be found here:
http://wiki.debian.org/ReleaseGoals/RunDirectory#How_to_transition_from_.2B
AC8-lib.2BAC8-init.2BAC8-rw_to_.2BAC8-run.3F
For sendsigs.omit.d, we would recommend that you:
* Depend on initscripts (= 2.88dsf-13.3)
Is it really neccessary in this case?
* Replace *all* usage of /lib/init/rw with /run
I was hoping just to support (with first preference) the new location in
addition to the previous locations, then remove that code sometime in next
release cycle.
* Move all files in /lib/init/rw to /run in the package postinst, for
example:
if [ -f /lib/init/rw/sendsigs.omit.d/foo ]; then
mv /lib/init/rw/sendsigs.omit.d/foo /run/sendsigs.omit.d/foo
fi
Attached patch.
Thanks, Kel.
---
Index: debian/ifupdown/functions.sh
===
--- debian/ifupdown/functions.sh(revision 1586)
+++ debian/ifupdown/functions.sh(working copy)
@@ -40,12 +40,14 @@
WPA_CLI_TIMESTAMP=/var/run/wpa_action.${WPA_IFACE}.timestamp
WPA_CLI_IFUPDOWN=/var/run/wpa_action.${WPA_IFACE}.ifupdown
-# sendsigs omission interface, present in initscripts (= 2.86.ds1-48)
-if [ -d /lib/init/rw/sendsigs.omit.d/ ]; then
- # Debian
+if [ -d /run/sendsigs.omit.d/ ]; then
+ # Debian, initscripts (= 2.88dsf-13.3)
+
WPA_SUP_OMIT_PIDFILE=/run/sendsigs.omit.d/wpasupplicant.wpa_supplicant.${WPA_IFACE}.pid
+elif [ -d /lib/init/rw/sendsigs.omit.d/ ]; then
+ # Debian, initscripts ( 2.88dsf-13.3)
WPA_SUP_OMIT_PIDFILE=/lib/init/rw/sendsigs.omit.d/wpasupplicant.wpa_supplicant.${WPA_IFACE}.pid
elif [ -d /var/run/sendsigs.omit.d/ ]; then
- # Ubuntu, see https://launchpad.net/bugs/181541 for status
+ # Ubuntu ( oneiric)
WPA_SUP_OMIT_PIDFILE=/var/run/sendsigs.omit.d/wpasupplicant.wpa_supplicant.${WPA_IFACE}.pid
else
WPA_SUP_OMIT_PIDFILE=
Index: debian/wpasupplicant.postinst
===
--- debian/wpasupplicant.postinst (revision 1586)
+++ debian/wpasupplicant.postinst (working copy)
@@ -23,6 +23,20 @@
if ! getent group netdev /dev/null; then
addgroup --quiet --system netdev || true
fi
+
+ # Migrate sendsigs pid ommission files to /run
+ if [ -d /run/sendsigs.omit.d ]; then
+ for omitd in /lib/init/rw/sendsigs.omit.d \
+ /var/run/sendsigs.omit.d
+ do
+ if [ -d $omitd ]; then
+ for f in ${omitd}/wpasupplicant.*.pid
+ do
+ mv $f /run/sendsigs.omit.d/
+ done
+ fi
+ done
+ fi
;;
abort-upgrade|abort-deconfigure|abort-remove)
;;
---
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633040: [pkg-wpa-devel] Bug#633040: wpasupplicant: /run transition: Please switch to /run/sendsigs.omit.d
Hi Roger, On Sun, 24 Jul 2011 06:51:23 PM Roger Leigh wrote: I'm not sure this will work correctly on Debian (the Ubuntu-specific bits are incorrect for Debian AFAICT); see below. The main point is that /var/run/sendsigs.omit.d /is/ /run/sendsigs.omit.d as soon as initscripts is upgraded. In consequence, there's no need for any migration (in fact, any mv from /var/run/sendsigs.omit.d/foo to /run/sendsigs.omit.d/foo will fail, because they will be the /same/ file as a result of the bind mount or symlink, depending upon if the system was rebooted or not. This is the main reason you need the initscripts dependency. It ensures that the /run/sendsigs.omit.d path is valid, and removes the need to special-case Ubuntu. Fair enough. Thanks for the clue bat I wasn't thinking clearly on this one. Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610931: Please build wpasupplicant-udeb
On Sun, 24 Jul 2011 08:02:48 AM Gaudenz Steinlin wrote:
Hi
I'm picking up the task to integrate WPA support into
debian-installer. My goal is to have this finished by the end of
Debconf. Is anyone of you also going to attend Debconf?
Nope.
nl80211 is the way forward. It would require libnl to be included in D-I.
AFAICS with my iwlwifi card both nl80211 and wext work. Is there any
practical advantage of nl80211. If possible I would like to avoid
having to include another library into d-i.
WEXT is deprecated upstream, nl80211 is in active development and all new wifi
drivers will use it. Looking into my crystal ball I see that eventually the
WEXT compat layer will decay into something that nobody wants to keep
maintaining.
If D-I integration of wpasupplicant were to go ahead without including support
for nl80211 it would be a waste of time imo.
diff -urN wpasupplicant-0.6.10.orig/debian/control
wpasupplicant-0.6.10/debian/control [...]
+Architecture: linux-any
wpasupplicant is needed, and compatible with-, kFreeBSD as well, at
this moment kFreeBSD doesn't support wlan for unrelated reasons
(ifconfig not being able to configure wlan interfaces, besides the
open firmware issues, while firmwares are required for most
chipsets). So ignoring hurd, it should be any or at least
linux-any kfreebsd-any.
Wireless config is disabled in d-i for kfreebsd, so there's no reason
to build wpasupplicant-udeb for those arches. However, if you're
comfortable that a wpasupplicant-udeb will build correctly for those
arches, it'd save changes down the line if/when kfreebsd gets d-i
wireless support.
It'd probably be better to prepare early here and build
wpasupplicant-udeb for whatever it can build on.
I don't care that much as it mainly concerns your package, but as
kfreebsd does not currently have wireless support in d-i, the package
won't be used for now. I don't know how much work it would be to
enable wireless for kfreebsd in d-i, but that's a another task.
I have another question:
To connect to the debconf network I needed to additional kernel
modules for the encryption algorithms: aes_generic.ko and
aes-x86_64.ko. Are these the only crpyto modules required for WPA or
are there configurations where other algorithms might be needed. Of
course aes-x86_64 has to be replaced by the appropriate module on
other architectures.
It's possible, I don't really know.
Has there been any solution for the netcfg integration already, see
201011041811.11753@otaku42.de [1], referring to the originally
proposed introduction of embedded source copies of wpasuppliant's
wpa_ctrl.[hc] into netcfg. Please also keep in mind that crda/
wireless-regdb is required for accessing channels 11-13/14 on modern
drivers.
I've applied the existing WPA netcfg support patches developed by Glenn
Saberton, and they do appear to include a (stripped down) wpa_ctrl.c.
That stripped down crap probably was extracted from a sideline project
(python-wpactrl) I was working on, and is not good long term solution.
wpa_ctrl.{c,h} from current wpasupplicant source tree have lots more
dependency on other stuff. Extracting and patching wpa_ctrl.{c,h} to be
standalone is something which should be avoided - I just do not know how
currently.
Asked upstream wpa_supplicant if wpa_ctrl could be provided in a way
where it could be a shared library but received no response.
Is there any progress on this?
Nope.
I
have no idea what the story is with crda/wireless-regdb, as I said
before, I don't know anything about WPA. If you'd like to help out,
though, your knowledge would be greatly valued.
I wouldn't mind helping out, don't know how though, Have little idea
about D-I environment and took long enough to just reply to this request
to feel a little embarrassed.
Also haven't seen the proposed change to netcfg anytime in recent past to
comment further. Can that be reviewed?
It's in branch people/womble/wpa of
git://git.debian.org/git/d-i/netcfg.
Gaudenz
Thanks for the link.
Kel.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628140: [Pkg-sysvinit-devel] Bug#628140: initscripts: /etc/init.d/hostname.sh fails if /etc/hostname not present
On Sat, 28 May 2011 12:52:45 AM Edgar Fuss wrote: Package: initscripts Version: 2.88dsf-13.1 Severity: normal Tags: patch If /etc/hostname is not present, /etc/init.d/hostname.sh will pick up the kernel supplied hostname ``(none)'' and try to set this via hostname(1), wich fails. The obvious fix is to treat a hostname of ``(none)'' as, ehm, none, e.g. empty. This will give you a hostname of ``localhost''. I tend to agree that `localhost' makes more sense than `(none)' in the fallback case, but I'm not sure this is the correct place to change this. A search led me to: lkml.org/lkml/2011/4/11/14 What do you think about this? If the discussion there leads us to believe the kernel is the correct place for this bug to be fixed, this bug should be reassigned. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627797: [Pkg-sysvinit-devel] Bug#627797: checkfs does not depend on mdadm-raid
On Wed, 25 May 2011 02:25:56 AM Lars Doelle wrote: Package: initscripts Version: 2.88dsf-13.7 Description In parallel execution of the init-scripts, a race between checkfs and mdadm-raid is possible that makes checkfs fail because /dev/md0 is not yet created by mdadm-raid if the raid-device is listed with fsck in the fstab, too. Possible Correction Add Required-Start: mdadm-raid to the init-info of checkfs.sh. Should-Start: at the most, Required-Start: would infer a hard dependency. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625701: [wpasupplicant] ipw3945 ioctl[SIOCSIWENCODEEXT]: Invalid argument
Hi Ruiyan,
On Thu, 5 May 2011 06:02:47 PM Ruiyan Yu wrote:
Package: wpasupplicant
Version: 0.7.3-3
Severity: normal
--- Please enter the report below this line. ---
I was able to connect to the university network.
Since last aptitude full-upgrade I received errors shown below and was
unabled to connect.
It does not work for WPA-EPA-TTLS as well.
I dont have any other connection issues with wlan-network.
wpa_supplicant log with -dddt
---
1304546942.144667: wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0
seq_len=0 key_len=0
1304546942.144688: wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0
seq_len=0 key_len=0
1304546942.144697: wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0
seq_len=0 key_len=0
1304546942.144705: wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0
seq_len=0 key_len=0
1304546942.144713: wpa_driver_wext_set_key: alg=0 key_idx=4 set_tx=0
seq_len=0 key_len=0
1304546942.144822: Driver did not support SIOCSIWENCODEEXT
1304546942.144828: wpa_driver_wext_set_key: alg=0 key_idx=5 set_tx=0
seq_len=0 key_len=0
1304546942.144880: Driver did not support SIOCSIWENCODEEXT
wpa_supplicant.conf
---
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
eapol_version=1
ap_scan=1
network={
ssid=someid
id_str=somestr
scan_ssid=1
key_mgmt=WPA-EAP
eap=PEAP
identity=id@domain
anonymous_identity=anonymous@domain
password=somepass
ca_cert=somecert
phase2=auth=MSCHAPV2
}
interfaces
-
auto wlan0
iface wlan0 inet manual
wpa-driver wext
Can you please remove this wpa-driver line or try with wpa-driver nl80211?
Kernel: Linux 2.6.38-2-686
With this kernel, nl80211 should be better than WEXT interface.
Thanks, Kel.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625701: [wpasupplicant] ipw3945 ioctl[SIOCSIWENCODEEXT]: Invalid argument
On Thu, 5 May 2011 07:20:16 PM Ruiyan Yu wrote: Hi Kel, Am 05.05.2011 11:06, schrieb Kel Modderman: Can you please remove this wpa-driver line or try with wpa-driver nl80211? Kernel: Linux 2.6.38-2-686 With this kernel, nl80211 should be better than WEXT interface. Thanks, Kel. It works great with wpa-driver nl80211. Thanks for your help! Cool, copying the BTS + list for the record. Normally I would close a bug fixed so easily, but it seems that wpa-driver wext might actually be totally crap and cause more problems for other people. It should possibly be removed from wpa_supplicant build configuration and nl80211 used instead. I'm not sure of the best way to migrate people's /etc/network/interfaces configuration which includes wpa-driver wext. Idea's welcome. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624391: [Pkg-sysvinit-devel] Bug#624391: initscripts: postinst dupes /etc/motd into /etc/motd.tail
On Thu, 28 Apr 2011 02:44:15 PM Andrew Pollock wrote: Package: initscripts Version: 2.86.ds1-61 Severity: minor I encountered this bug on Ubuntu 10.04, but the maintainer script in question appears unmodified from Debian. Basically, the postinst of initscripts appears to copy the contents of /etc/motd into /etc/motd.tail, if it doesn't exist. This appears to be benign on Debian, but on Ubuntu, which will dynamically create an /etc/motd out of shell fragments in /etc/update-motd.d and /etc/motd.tail, it has the undesired effect of caused duplicated stale content. Ubuntu recently pushed an updated initscripts package to 10.04, which caused the problem I describe. More information in https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/634387 In short, I don't think the postinst should be creating an /etc/motd.tail if one doesn't exist already. I do not completely understand this statement. Do you mean: postinst should never create /etc/motd.tail at all? I also don't think it should go putting anything in it if it does exist. Tend to agree with this one. I'd be happy to look at/apply a patch if you could please whip one up? Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622768: [Pkg-utopia-maintainers] Bug#622768: wpasupplicant: Lost passwords after reboot/suspend every X reset
Hi Adam, On Mon, 18 Apr 2011 05:22:54 PM Michael Biebl wrote: Am 18.04.2011 07:57, schrieb Adnan Hodzic: wpa_supplicant is a non-interactive daemon. What interface is your input put into? wlan0 What _user_ interface is your password input to? The answer to that is, my gut feeling, the start of the problem. Given that you mention X restart(s) I suspect Network-Manager most of all. CC'ing the network-manager maintainer list. For some reason I too believe this is network-manager problem. I believe it's a gnome-keyring issue, but unfortunately your bug report lacks sufficient detail, so it's hard to say. Indeed. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622757: closed by Kel Modderman k...@otaku42.de (Bug#622757: fixed in wpasupplicant 0.7.3-3)
On Mon, 18 Apr 2011 07:13:49 PM Sedat Dilek wrote: +++ Not that I plan to reopen this bug-#. +++ Can you explain why you re-added the removed code part exactly back? What was the reason to drop it? Because it shouldn't be required in theory. Reality is a bit different. Why this shell-kung-fu... with that ugly sleep etc.? Because it works. Why is the below short fixup not enough in your POV? Please, keep the things simple. ( I had several startup at weekend, it works nicely. ) Because I think it's crap use of 'until', really. Furthermore: 1. Are you planning a systemd unit/service file? Co-existence with that ugly ifupdown script? Look, I wrote the script, if you want to flat out call it ugly yet still be a user of it you can can be ignored from now on. It is what it is and it made networking work for a few users. 2. Plans to upload a package with /run support? When the time is right. - Sedat - Yours sincerely, Kel. [1] http://wiki.debian.org/ReleaseGoals/RunDirectory Section #1: Packages using /lib/init/rw Section #2: How to transition from /lib/init/rw to /run? [ CODE ] - if [ -n $WPA_SUP_OMIT_PIDFILE ]; then - wpa_msg verbose creating sendsigs omission pidfile: $WPA_SUP_OMIT_PIDFILE - cat $WPA_SUP_PIDFILE $WPA_SUP_OMIT_PIDFILE - fi + until [ -S $WPA_CTRL_DIR/$WPA_IFACE ]; do + if [ -n $WPA_SUP_OMIT_PIDFILE ]; then + wpa_msg verbose creating sendsigs omission pidfile: $WPA_SUP_OMIT_PIDFILE + cat $WPA_SUP_PIDFILE $WPA_SUP_OMIT_PIDFILE + else + wpa_msg verbose sendsigs omission pidfile not created + wpa_msg stderr ctrl_interface socket not found at $WPA_CTRL_DIR/$WPA_IFACE + return 1 + fi + done [ /CODE ] On Sun, Apr 17, 2011 at 10:48 PM, Debian Bug Tracking System ow...@bugs.debian.org wrote: This is an automatic notification regarding your Bug report which was filed against the wpasupplicant package: #622757: wpasupplicant: Faulty ifupdown/functions.sh script? It has been closed by Kel Modderman k...@otaku42.de. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Kel Modderman k...@otaku42.de by replying to this email. -- 622757: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622757 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- Forwarded message -- From: Kel Modderman k...@otaku42.de To: 622757-cl...@bugs.debian.org Date: Sun, 17 Apr 2011 20:44:40 + Subject: Bug#622757: fixed in wpasupplicant 0.7.3-3 Source: wpasupplicant Source-Version: 0.7.3-3 We believe that the bug you reported is fixed in the latest version of wpasupplicant, which is due to be installed in the Debian FTP archive: wpagui_0.7.3-3_i386.deb to main/w/wpasupplicant/wpagui_0.7.3-3_i386.deb wpasupplicant_0.7.3-3.debian.tar.gz to main/w/wpasupplicant/wpasupplicant_0.7.3-3.debian.tar.gz wpasupplicant_0.7.3-3.dsc to main/w/wpasupplicant/wpasupplicant_0.7.3-3.dsc wpasupplicant_0.7.3-3_i386.deb to main/w/wpasupplicant/wpasupplicant_0.7.3-3_i386.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 622...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Kel Modderman k...@otaku42.de (supplier of updated wpasupplicant package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 17 Apr 2011 21:07:58 +1000 Source: wpasupplicant Binary: wpasupplicant wpagui Architecture: source i386 Version: 0.7.3-3 Distribution: unstable Urgency: low Maintainer: Debian/Ubuntu wpasupplicant Maintainers pkg-wpa-de...@lists.alioth.debian.org Changed-By: Kel Modderman k...@otaku42.de Description: wpagui - graphical user interface for wpa_supplicant wpasupplicant - client support for WPA and WPA2 (IEEE 802.11i) Closes: 622587 622589 622757 622821 Changes: wpasupplicant (0.7.3-3) unstable; urgency=low . * Restore code which loop waits for wpa_supplicant generated PID and UNIX socket on the filesystem before proceeeding with execution of ifupdown script. (Closes: #622757, #622589) * On DISCONNECTED event using wpa-roam, do not immediately issue reassociation command. (Closes: #622821) * Enable
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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623051: [Pkg-sysvinit-devel] Bug#623051: Wrong name for flag file in update-rc.d(8) man page?
On Sun, 17 Apr 2011 08:28:31 AM Thomas Hood wrote: Package: sysv-rc Severity: minor update-rc.d(8) says: The machines using the legacy mode will have a file /etc/init.d/.legacy-bootordering and later: FILES [...] /var/lib/sysv-rc/legacy-bootsequence Flag indicating the machine is using legacy mode for boot script ordering. Are there two flag files, or is one of the two given file names incorrect? Looking at r1625 r1635 I think /var/lib/sysv-rc/legacy-bootsequence was abandoned sometime way back when. http://lists.alioth.debian.org/pipermail/pkg-sysvinit-commits/2009-August/001515.html (r1625) http://lists.alioth.debian.org/pipermail/pkg-sysvinit-commits/2009-August/001525.html (r1635) Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622768: wpasupplicant: Lost passwords after reboot/suspend every X reset
On Fri, 15 Apr 2011 12:27:33 AM Adnan Hodzic wrote: Package: wpasupplicant Version: 0.7.3-2 Severity: important After last wpasupplicant upgrade, first all my WPA/WEP were lost, but that's the least of the problem as I need to input the password/s every time as they get lost with every reboot/suspend or even X reset. If you need any more information let me know as I would be happy to provide you with the same. wpa_supplicant is a non-interactive daemon. What interface is your input put into? The answer to that is, my gut feeling, the start of the problem. Given that you mention X restart(s) I suspect Network-Manager most of all. CC'ing the network-manager maintainer list. Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622821: wpasupplicant: reassociates after disconnect
Hi Andrew. On Fri, 15 Apr 2011 07:36:00 AM Andrew Pimlott wrote: Package: wpasupplicant Version: 0.7.3-2 Severity: normal In the changelog: * After a disconnected event, attempt to reassociate to a network when using wpa-roam. If I'm understanding this correctly, I don't see the sense in this. It definitely changes the user experience. Before, in wpa_gui, if I click Disconnect, I go off the wireless network and stay off. Now, I come right back on, which seems unintuitive. If I really want to stay off, I can't do it in wpa_gui, I have to ifdown. You might argue this is a better to do it, but I think people might be used to doing a disconnect (in wpa_gui and other front-ends) to get off the wireless network. I tend to agree with you, and what's more I cannot recall what information or events led to the decision to introduce this behaviour. Would have to dig deep through the history... Would you be able to propose in patch form, the changes you would like? Also, this change breaks /etc/wpa_supplicant/action_wpa.sh. The comments in that script indicate an expectation that disconnect implies disable. The ifplugd uses this script when it detects an ethernet cable plugged in. As a result of this change, both the ethernet and wireless interfaces stay up and may step on each other. (Which one gets the default route? Also, I am seeing weird DHCP behavior that seems to be related.) I'm not saying ifplugd is necessarily doing the right thing, but it was working before. hmm, ok. Let me know if I'm misunderstanding something. Here is my wireless interface configuration in /etc/network/interfaces: iface eth1 inet manual wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf wpa-roam-default-iface default-wireless iface default-wireless inet dhcp Looks pretty standard. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622587: wpasupplicant: Please, switch CONFIG_IEEE80211W on.
On Wed, 13 Apr 2011 06:13:35 PM sergio wrote: Package: wpasupplicant Version: 0.7.3-2 Severity: wishlist hostap on squeeze and later has CONFIG_IEEE80211W, but wpasupplicant still doesn't. Please switch it on. I agree it should be sync'd with hostapd build config. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622757: wpasupplicant: Faulty ifupdown/functions.sh script?
On Thu, 14 Apr 2011 10:50:30 PM Sedat Dilek wrote: Package: wpasupplicant Version: 0.7.3-2 Severity: normal Hi, with wpasupplicant-0.7.3 entering Debian/sid my Internet connection is not established anymore. By replacing the ifupdown/functions.sh script from wpasupplicant (0.6.10-2.1) things are as used to. I haven't got the time to look deeper into this as it WorksForMe. I have collected all relevant material (/e/n/i), the files of ifupdown-dirs from 0.6.10 and 0.7.3 (see also the diffs) and added my dsc|diff files into the attached tarball. If this kind of matters I use systemd as sysvinit replacement and resolvconf helps for static-IP network setup. Furthermore, I have no ifplugd or suggested libengine-pkcs11-openssl installed. If you have detailed instructions on how to investigate the issue, please let me know. Without reviewing any diff, it could be related to #622589 Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622837: libpcsclite1: please drop Recommends: pcscd
On Fri, 15 Apr 2011 06:40:32 PM Jonathan Nieder wrote: Ludovic Rousseau wrote: You think it is a bug. I think it is not a bug. How do you propose to solve this bug? What would be OK for you as a solution? I don't want to argue much. I do consider it a bug that installing wpasupplicant causes a setuid smartcard daemon to be installed. I believe it is an unintended consequence. It is not the best thing to happen behind the user's back. That said: - I could easily be wrong; - I am not claiming you made some bad decision before, just that this is a problem for Debian to solve (that's what the BTS is for, after all). I would propose: - if users of the library will crash or otherwise fail if pcscd is not installed, mentioning that in the package description; - otherwise, downgrading the Recommends to a Suggests and notifying the maintainers of reverse-dependencies that they should add Depends: pcscd. No doubt there are plenty of alternative fixes possible. 1) Disable support for PCSC in wpasupplicant, and noone using Debian could use this function without recompiling wpa_supplicant + friends. I do not think any Debian supporter wats this. or 2) Link against libpcsclite, and allow the end user to install daemon if they need that (and given all the arguments, you must damn well know if you need that). Given the correct dependency between libpcsclite + daemon this is _easily_ possible. 3) Will NOT rehash the dlopen() debacle. If pushed into a corner I will do 1. Prefer to do 2. Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612971: Bug#612842: Bug#612971: Bug#612842: Please make dependendency on libpcsclite1 optional
On Tue, 12 Apr 2011 04:56:09 AM Ludovic Rousseau wrote: 2011/4/10 Guillem Jover guil...@debian.org: Regardless of wpasupplicant fixing this by dropping the dependency, I disagree this is not a problem with libpcsclite. While for libpcsclite pcscd might be required, it might not for the programs using it, or for users w/o a smart card, and forcing a Depends seems too much, when a Recommends would work for everyone. It would get installed by default, and users could have the option to opt-out and remove it if desired. Exact. The package is already fixed that way. The best solution is for spasupplicant to use the libpcsclite1 library only when needed/requested by the user. Use dlopen() instead of a direct link, and change the Depends: to a Suggests: instead. I proposed a patch [1] in Debian bug #531592 Using dlopen() for shared objects not being part of ones project is just broken, please don't do or advocate that. It will cause numerous pains on transitions as the packages cannot (usually) just be binNMUed for it to pickup the new SONAME, and even if it can and any weak package metadata gets also updated, users will not have a clue what they are missing if it stops working, as it breaks partial upgrades and similar. wpasupplicant version 0.7.3-1 available in experimental now does use dlopen(). And that was a decision I was never comfortable with and have now reverted to the previous status quo. So I'd kindly ask that this gets switched as to a Recommends, regardless of any future switch to libudev (I don't really want the daemon even if it's not using hal and friends). I changed the dependency from Depends: to Recommends: in version 1.7.0-1 (09 Mar 2011) now also available in testing. This bug is already fixed. Nah it's not, the dlopen() experiment wasn't correct for all archs and I'm convinced now that it was the wrong solution to a problem. Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599241: [Pkg-sysvinit-devel] Bug#599241: Acknowledgement (Please remove obsolete usplash integration)
On Tue, 5 Apr 2011 01:59:34 PM Michael Biebl wrote: Am 13.10.2010 03:53, schrieb Kel Modderman: On Wednesday 06 October 2010 13:54:27 Michael Biebl wrote: It also looks like, that neither splashy nor plymouth (the two remaining boot splash programs) use the splash api provided by initscripts. So I'm wondering if all splash related functionality should be ripped out of initscripts. With no-one actually using it, it only bloats and slows down the initscripts. I'd love to see that crap go - but will be on holidays for a couple of weeks. I'd be more than happy to apply a patch to packaging in SVN once returned, an NMU would also not be out of order considering that us maintainers are busy with real life and are currently really struggling to pull together changes wanted for squeeze. We do have a current release team grant for upload with the changes already committed to our SVN. Has there been any progress on this? If you want a patch, please shout. No progress, and yeah, a patch is kinda what I was hinting at when you first approached. Please do not hesitate for sysvinit maintainers to make first move on this, am not aware of any work being done. I'm pretty sure all the listed sysvinit maintainers are currently not very active when it comes to maintaining sysvinit, at the moment. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599430: Announce of the upcoming NMU for the sysvinit package
On Tue, 5 Apr 2011 08:34:17 PM Henrique de Moraes Holschuh wrote: On Tue, 05 Apr 2011, Christian PERRIER wrote: I have actually been surprised of not getting any answer to this NMU intent. I don't really intend to NMU sysvinitat least not until I get a quite clear ACK from its maintainers. We're not talking about a random package here..:-) It was implicit approval, I think :-) So, I assume that my mails indeed felt under you guys' attention..:-) I for one did read it, and I had nothing against your NMU so I didn't speak up. All we ask is for a clean chroot to be used in the build, just in case, and that you do some minimal testing of the package before you upload (assuming you really need to touch only po/translation files). I too silently read the intent to NMU, and it all sounds fine. Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618277: PHASE mismatch in ifupdown script
On Wednesday 16 March 2011 22:19:02 Tormod Volden wrote: I agree that nowadays this is usually run through dbus and network-manager and not the ifupdown and /etc/interfaces way, but the result is the same. Please look at /etc/NetworkManager/dispatcher.d/01ifupdown - it sets $PHASE and does run-parts on the corresponding /etc/network/if-XXX.d directory. So in your example above, when run-parts: executing /etc/network/if-down.d/wpasupplicant is executed, $PHASE is set to down. And the pre-down clause can not be executed since there is no if-pre-down.d file. Incorrect. Add a debug print to the case statement (eg echo $0 $MODE $PHASE) run-parts: executing /etc/network/if-down.d/wpasupplicant /etc/network/if-down.d/wpasupplicant stop pre-down You do agree that any post-up and pre-down clauses in ifupdown.sh will not be run, right? No, I do not agree. Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618277: PHASE mismatch in ifupdown script
On Tuesday 15 March 2011 22:24:07 Tormod Volden wrote: On Tue, Mar 15, 2011 at 12:46 PM, Kel Modderman wrote: Can you explain what is actually wrong with the shell code I've been using for a few years, which stops it from functioning as advertised? I'm not going to be interested enough to consume time investigating a problem based on a guess. Thanks, Kel. Hi Kel, Yes, by analyzing the code I can say what goes wrong: Upon network interface activation, the action intended for the post-up phase is not executed (because the script is not in any if-post-up.d directory - it is linked in the if-up.d directory but $PHASE will here be up). The action in question is init_wpa_cli() from functions.sh. This function only does something if $WPA_ACTION_SCRIPT is set. Therefore if you personally have been using this code for some years without WPA_ACTION_SCRIPT set, you would not have experienced any problem. What the advertised use for this is, I do not know. But it is certainly not working as intended. So I will /guess/ ;) there are users out there who have problems with their WPA_ACTION_SCRIPT setup. /etc/network/interfaces --- allow-hotplug wlan0 iface wlan0 inet manual wpa-roam /etc/wpa_supplicant/wpa-roam.conf iface default inet dhcp --- # ifup -v wlan0 Configuring interface wlan0=wlan0 (inet) run-parts --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/bridge run-parts: executing /etc/network/if-pre-up.d/hostapd run-parts: executing /etc/network/if-pre-up.d/wireless-tools run-parts: executing /etc/network/if-pre-up.d/wpasupplicant wpa_supplicant: wait for wpa_cli to attach wpa_supplicant: wpa-driver nl80211,wext (default) wpa_supplicant: /sbin/wpa_supplicant -s -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0 -W -D nl80211,wext -c /etc/wpa_supplicant/wpa-roam.conf Starting /sbin/wpa_supplicant... wpa_supplicant: creating sendsigs omission pidfile: /lib/init/rw/sendsigs.omit.d/wpasupplicant.wpa_supplicant.wlan0.pid run-parts --verbose /etc/network/if-up.d run-parts: executing /etc/network/if-up.d/000resolvconf run-parts: executing /etc/network/if-up.d/mountnfs run-parts: executing /etc/network/if-up.d/ntpdate run-parts: executing /etc/network/if-up.d/openssh-server run-parts: executing /etc/network/if-up.d/wpasupplicant wpa_supplicant: /sbin/wpa_cli -B -P /var/run/wpa_action.wlan0.pid -i wlan0 -p /var/run/wpa_supplicant -a /sbin/wpa_action Starting /sbin/wpa_cli... # ifdown wlan0 -v Configuring interface wlan0=wlan0 (inet) run-parts --verbose /etc/network/if-down.d run-parts: executing /etc/network/if-down.d/resolvconf run-parts: executing /etc/network/if-down.d/wpasupplicant wpa_supplicant: terminating wpa_cli daemon via pidfile /var/run/wpa_action.wlan0.pid Stopped /sbin/wpa_cli (pid 3707). run-parts --verbose /etc/network/if-post-down.d run-parts: executing /etc/network/if-post-down.d/bridge run-parts: executing /etc/network/if-post-down.d/hostapd run-parts: executing /etc/network/if-post-down.d/wireless-tools run-parts: executing /etc/network/if-post-down.d/wpasupplicant wpa_supplicant: terminating wpa_supplicant daemon via pidfile /var/run/wpa_supplicant.wlan0.pid Stopped /sbin/wpa_supplicant (pid 3660). wpa_supplicant: removing /lib/init/rw/sendsigs.omit.d/wpasupplicant.wpa_supplicant.wlan0.pid Upon network deactivation, for the same reasons, kill_wpa_supplicant() is not run. This I can verify myself even without using WPA: 1. See that there is a running /sbin/wpa_supplicant process. 2. Deactivate networking for instance with nm-applet. 3. See that /sbin/wpa_supplicant, against intended behaviour, is still running and has therefore not been killed by kill_wpa_supplicant() . In case you added that logger line, you can see how the ifupdown script is called. This is not a guess :) This process is started/stopped via D-Bus and has *nothing* to do with the ifupdown shell script glue you are doing your guesswork on. Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618277: PHASE mismatch in ifupdown script
Hi Tormod,
On Monday 14 March 2011 08:06:31 Tormod Volden wrote:
Package: wpasupplicant
Version: 0.7.3-1
Note that I don't use wpasupplicant so I can not test this, but I
noticed it while studying various ifupdown script.
Can you explain what is actually wrong with the shell code I've been using for
a few years, which stops it from functioning as advertised?
I'm not going to be interested enough to consume time investigating a problem
based on a guess.
Thanks, Kel.
The /etc/wpa_supplicant/ifupdown.sh is linked in /etc/network/if-up.d
so it will be run with PHASE=up and not post-up. However the script
checks for post-up. Same goes for pre-down.
--- /etc/wpa_supplicant/ifupdown.sh 2009-06-01 12:32:26.0 +0200
+++ /tmp/ifupdown.sh 2011-03-13 23:01:35.0 +0100
@@ -141,7 +141,7 @@ case $MODE in
init_wpa_supplicant || exit 1
conf_wpa_supplicant || {
kill_wpa_supplicant; exit 1; }
;;
- post-up)
+ up)
init_wpa_cli|| {
kill_wpa_supplicant; exit 1; }
;;
esac
@@ -150,7 +150,7 @@ case $MODE in
stop)
do_stop
case $PHASE in
- pre-down)
+ down)
kill_wpa_cli
;;
post-down)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617199: Please upload 0.7.3 to experimental (including fix for dbus property events)
Hi Michael, On Tuesday 08 March 2011 01:32:48 Michael Biebl wrote: Hi Kel! Am 07.03.2011 11:47, schrieb Kel Modderman: A source package is available at: http://mentors.debian.net/debian/pool/main/w/wpasupplicant/wpasupplicant_0.7.3-1.dsc It contains a bunch of experimental appropriate changes including the cherry pick you want. Some of the new changes need a bit of testing and feedback. Could you please consider review and upload of it? I did some basic testing using it via NetworkManager and the package works fine so far. I didn't test any of the wpa ifupdown hooks / roaming mode or the new libpcsc dlopen. I use the ifupdown stuff all the time. No person that I know can test pcsc related functionality. Regarding the packaging, there are some smaller points: 1/ You use debhelper compat level 8, so you *need* to build depend on debhelper ( 8). Given that squeeze has debhelper 8 and even lenny has a debhelper 8 backport, there should be no problem bumping it. No problems. 2/ For b-deps like libnl-dev, you can use the new syntax libnl-dev [linux-any] That makes it more readable imho. Ok, I agree. Cheers for the tip. 3/ Does wpagui work with wpasupplicant (= 0.6.2) or should that be bumped to something 0.7.x like? It should probably be bumped, the GUI supports a few new features not available in older wpa_supplicant. 4/ Why do you need an explicit Depends on libqt4-svg? Does dh_shlibs not generate an appropriate dep? wpa_gui does not link against libQtSvg.so.4. I think in theory one could convert the svg - png and not require svg support in your QT installation. Otherwise it looks fine to me and I'd be happy to sponsor the upload. Can you address the above issues (1/ one is a must, the other I'll leave to your judgement) and let me know. I have re-uploaded the source package to mentors, same URL as before. Thanks very much for helping out. Should I wait until you get an ACK from the pcscd maintainer regarding the dlopen patch? Nope. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610931: Please build wpasupplicant-udeb
Thanks for working on WPA support in Debian's installer.
On Tuesday 25 January 2011 04:39:44 Matthew Palmer wrote:
diff -urN wpasupplicant-0.6.10.orig/debian/config/udeb
wpasupplicant-0.6.10/debian/config/udeb
[...]
+CONFIG_DRIVER_WEXT=y
Given that wext is deprecated, it would imho make more sense to use
CONFIG_DRIVER_NL80211=y instead, maybe even to leave wext disabled.
With the notable exception of ipw2100/ ipw2200, all other linux wlan
drivers weren't produced in large volumes or don't support wpa2 to
begin with; for new ones (this covers all mac80211 based ones) nl80211
support is mandatory and there are some initial efforts to add nl80211
to ipw2x00. This also avoids the need for deprecated wireless-tools in
favour of iw/ crda (which is required for ch11-14 anyways) - or being
able to use libnl for all configuration in netcfg.
I know nothing about WPA, I've just used a udeb config file that was in an
existing (out of date) patch to build a wpasupplicant udeb. In all honesty
you can set this configuration to whatever you think is best.
nl80211 is the way forward. It would require libnl to be included in D-I.
diff -urN wpasupplicant-0.6.10.orig/debian/control
wpasupplicant-0.6.10/debian/control
[...]
+Architecture: linux-any
wpasupplicant is needed, and compatible with-, kFreeBSD as well, at
this moment kFreeBSD doesn't support wlan for unrelated reasons
(ifconfig not being able to configure wlan interfaces, besides the open
firmware issues, while firmwares are required for most chipsets). So
ignoring hurd, it should be any or at least linux-any kfreebsd-any.
Wireless config is disabled in d-i for kfreebsd, so there's no reason to
build wpasupplicant-udeb for those arches. However, if you're comfortable
that a wpasupplicant-udeb will build correctly for those arches, it'd save
changes down the line if/when kfreebsd gets d-i wireless support.
It'd probably be better to prepare early here and build wpasupplicant-udeb for
whatever it can build on.
Has there been any solution for the netcfg integration already, see
201011041811.11753@otaku42.de [1], referring to the originally
proposed introduction of embedded source copies of wpasuppliant's
wpa_ctrl.[hc] into netcfg. Please also keep in mind that crda/
wireless-regdb is required for accessing channels 11-13/14 on modern
drivers.
I've applied the existing WPA netcfg support patches developed by Glenn
Saberton, and they do appear to include a (stripped down) wpa_ctrl.c.
That stripped down crap probably was extracted from a sideline project
(python-wpactrl) I was working on, and is not good long term solution.
wpa_ctrl.{c,h} from current wpasupplicant source tree have lots more dependency
on other stuff. Extracting and patching wpa_ctrl.{c,h} to be standalone is
something which should be avoided - I just do not know how currently.
Asked upstream wpa_supplicant if wpa_ctrl could be provided in a way where it
could be a shared library but received no response.
I
have no idea what the story is with crda/wireless-regdb, as I said before, I
don't know anything about WPA. If you'd like to help out, though, your
knowledge would be greatly valued.
I wouldn't mind helping out, don't know how though, Have little idea about D-I
environment and took long enough to just reply to this request to feel a little
embarrassed.
Also haven't seen the proposed change to netcfg anytime in recent past to
comment further. Can that be reviewed?
Thanks, Kel.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617199: Please upload 0.7.3 to experimental (including fix for dbus property events)
Hi Michael, On Monday 07 March 2011 15:59:07 Michael Biebl wrote: Package: wpasupplicant Version: 0.6.10-2.1 Severity: normal Hi, network-manager 0.9 will be a dependency of the upcoming GNOME3 release. Beta 1 of network-manager 0.9 has just been released. I'd like to prepare this beta version for experimental, but it requires the latest 0.7.3 wpasupplicant release including this fix http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap-07.git;a=commit;h=b80b5639935d37b95d00f86b57f2844a9c775f57 Please consider uploading 0.7.3 packages to experimental with a cherry-pick of the above patch. A source package is available at: http://mentors.debian.net/debian/pool/main/w/wpasupplicant/wpasupplicant_0.7.3-1.dsc It contains a bunch of experimental appropriate changes including the cherry pick you want. Some of the new changes need a bit of testing and feedback. Could you please consider review and upload of it? Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612842: Please make dependendency on libpcsclite1 optional
Hi Ludovic Rousseau,
On Sunday 13 February 2011 18:25:58 Ludovic Rousseau wrote:
2011/2/13 Michael Biebl bi...@debian.org:
On 11.02.2011 21:43, Ludovic Rousseau wrote:
reassign 612842 wpasupplicant
thank
Hm, I don't see how libpcsclite1 depending on pcscd is a bug in
wpasupplicant.
Could you elaborate?
wpasupplicant depends on libpcsclite1 to add support of smart cards.
libpcsclite1 has dependencies on other packages, in particular
indirectly on libhal.
Adding smart card support has a (high) cost for every body, including
the vast majority of wpasupplicant users with no smart card.
The best solution is for spasupplicant to use the libpcsclite1 library
only when needed/requested by the user.
Use dlopen() instead of a direct link, and change the Depends: to a
Suggests: instead.
I proposed a patch [1] in Debian bug #531592
Can you please take a look at attached patch? Tweaked it in preparation for
sending upstream.
The wpasupplicant Debian packagers decided to completely remove smart
card support [2]. I don't know if using dlopen() to add smart card
support back is on the roadmap.
Description: Load libpcsclite dynamically
Origin: http://w1.fi/bugz/attachment.cgi?id=149
Bug: http://w1.fi/bugz/show_bug.cgi?id=315
Bug-Debian: http://bugs.debian.org/531592
Author: Ludovic Rousseau ludovic.rouss...@gmail.com
Modified by Kel Modderman k...@otaku42.de:
* reduce ifdef's which #define stuff to one block
* make dynamic load optional via configuration option
Please note that neither of the patch author's have any means of testing
the end result.
---
--- a/src/utils/pcsc_funcs.c
+++ b/src/utils/pcsc_funcs.c
@@ -97,11 +97,25 @@ struct scard_data {
int pin1_required;
};
-#ifdef __MINGW32_VERSION
+#if defined( __MINGW32_VERSION) || defined(PCSC_DYNAMIC)
/* MinGW does not yet support WinScard, so load the needed functions
* dynamically from winscard.dll for now. */
+#ifdef __MINGW32_VERSION
static HINSTANCE dll = NULL; /* winscard.dll */
+#else
+#include dlfcn.h
+#define WINSCARDAPI
+#define WINAPI
+#define IN
+#define OUT
+#define SCardListReadersA SCardListReaders
+#define SCardConnectA SCardConnect
+#define LoadLibrary(lib) dlopen(libpcsclite.so.1, RTLD_LAZY)
+#define GetProcAddress dlsym
+#define FreeLibrary dlclose
+static void* dll = NULL;
+#endif
static const SCARD_IO_REQUEST *dll_g_rgSCardT0Pci, *dll_g_rgSCardT1Pci;
#undef SCARD_PCI_T0
--- a/wpa_supplicant/Makefile
+++ b/wpa_supplicant/Makefile
@@ -691,9 +691,13 @@ 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
+else
LIBS += $(shell pkg-config --libs libpcsclite)
endif
endif
+endif
ifdef CONFIG_SIM_SIMULATOR
CFLAGS += -DCONFIG_SIM_SIMULATOR
--- a/wpa_supplicant/defconfig
+++ b/wpa_supplicant/defconfig
@@ -204,6 +204,7 @@ CONFIG_SMARTCARD=y
# PC/SC interface for smartcards (USIM, GSM SIM)
# Enable this if EAP-SIM or EAP-AKA is included
+# If CONFIG_PCSC=dyn pcsc library is loaded dynamically
#CONFIG_PCSC=y
# Development testing
---
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608534: [Pkg-sysvinit-devel] Bug#608534: fsck exit code 32 should be treated as success
tags 608534 patch
thanks
On Saturday 01 January 2011 19:29:42 Petter Reinholdtsen wrote:
[Ben Hutchings]
However, check{root,fsck}.sh are interactive and fsck will be and
should be interruptible. If fsck checks the filesystem only due to
a schedule (number of days or number of mounts since last check) and
not due to a detected error condition then a user interrupt should
*not* be considered a failure of the init script. Please squash
exit code 32 in these init scripts.
I think a failure message should still be emitted but the boot process
allowed to continue after message about user interrupt.
Something like this might work. I have not had time to complete the
patch, nor test it, and I am not sure if it is a good idea to ignore
interrupted fsck runs, so I post the patch here for review and
feedback.
Not tagging the BTS report with 'patch' as this patch is incomplete
(need to also modify checkfsck.sh).
This works for me. Please let me know of problems or if you'd like to
see it committed.
Thanks, Kel.
---
Index: debian/src/initscripts/etc/init.d/checkfs.sh
===
--- debian/src/initscripts/etc/init.d/checkfs.sh(revision 1953)
+++ debian/src/initscripts/etc/init.d/checkfs.sh(working copy)
@@ -23,6 +23,9 @@
. /lib/init/swap-functions.sh
do_start () {
+ # Trap SIGINT so that we can handle user interupt of fsck.
+ trap INT
+
# See if we're on AC Power. If not, we're not gonna run our
# check. If on_ac_power (in /usr/) is unavailable, behave as
# before and check all file systems needing it.
@@ -109,9 +112,13 @@
splash_stop_indefinite
fi
- if [ $FSCKCODE -gt 1 ]
+ if [ $FSCKCODE -eq 32 ]
then
log_action_end_msg 1 code $FSCKCODE
+ log_warning_msg File system check was
interrupted by user
+ elif [ $FSCKCODE -gt 1 ]
+ then
+ log_action_end_msg 1 code $FSCKCODE
handle_failed_fsck
else
log_action_end_msg 0
@@ -127,8 +134,11 @@
logsave -s $FSCK_LOGFILE fsck $spinner -V -R -A $fix
$force $FSCKTYPES_OPT
FSCKCODE=$?
splash_stop_indefinite
- if [ $FSCKCODE -gt 1 ]
+ if [ $FSCKCODE -eq 32 ]
then
+ log_warning_msg File system check was
interrupted by user
+ elif [ $FSCKCODE -gt 1 ]
+ then
handle_failed_fsck
else
log_success_msg Done checking file systems.
Index: debian/src/initscripts/etc/init.d/checkroot.sh
===
--- debian/src/initscripts/etc/init.d/checkroot.sh (revision 1953)
+++ debian/src/initscripts/etc/init.d/checkroot.sh (working copy)
@@ -25,6 +25,9 @@
. /lib/init/usplash-fsck-functions.sh
do_start () {
+ # Trap SIGINT so that we can handle user interrupt of fsck.
+ trap INT
+
#
# Set SULOGIN in /etc/default/rcS to yes if you want a sulogin to
# be spawned from this script *before anything else* with a timeout,
@@ -304,8 +307,11 @@
# errors were corrected but that the boot may proceed. A return
# code of 2 or 3 indicates that the system should immediately reboot.
#
- if [ $FSCKCODE -gt 3 ]
+ if [ $FSCKCODE -eq 32 ]
then
+ log_warning_msg File system check was interrupted by user
+ elif [ $FSCKCODE -gt 3 ]
+ then
# Surprise! Re-directing from a HERE document (as in cat
EOF)
# does not work because the root is currently read-only.
log_failure_msg An automatic file system check (fsck) of the
root filesystem failed.
---
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606823: wpasupplicant: wifi does not work (not activable and no network detected)
Hi mehdi, On Sunday 12 December 2010 10:18:38 mehdi wrote: Package: wpasupplicant Version: 0.6.10-2.1 Severity: normal When i start my computer, I cannot see any wireless network, but there are actually about 15. But wired network works. What made you choose wpasupplicant package to report bug to? How did you configure wpasupplicant and what steps do you take to determine that there is a problem? Please provide more information, as it stands there is not much for me to do except make assumptions about what may be the problem, like: * missing firmware files for wireless interface * rfkill switch has disabled wireless interface * wpasupplicant package is incorrectly configured in /etc/network/interfaces or * a graphical user interface is not configuring wpa_supplicant correctly Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582917: Patch for bug #582917
On Friday 26 November 2010 06:29:05 Micha Lenk wrote: forwarded 582917 http://w1.fi/bugz/show_bug.cgi?id=355 tags 582917 + patch fixed-upstream thanks Please find attached the patch grabbed from the upstream git repository, ready for being placed in debian/patches/. I've tried it on my system and indeed it fixes the bug. :) I would appreciate if the severity of this bug could be raised to serious and if it could get fixed in Squeeze. It's unlikely I can attend to this matter before the end of the week (ie 1st week december) and every day that passes, as you know, it becomes harder to make this possible for Squeeze. I cannot reproduce/test this problem either, so justification for allowing this would probably be stronger from someone who does suffer from this problem. All that said, it'd be perfect for me if you were to do an NMU with this upstream patch ASAP, bump this severity to serious and provide justification to release team. I'd be happy to help answer any questions that the release team have. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582917: fails to connect to WPA/PEAP network in 0.6.10-2/testing while it connects in 0.6.4-3/stable
On Saturday 13 November 2010 01:36:10 Vishaal Golam wrote: Hi, Le Mon, May 24, 2010 at 04:32:44PM +0200, Michal Hocko écrivait: I have encountered problems to connect to our company WPA based wireless network. The problem seems to be related to the package version. The current Stable version (0.6.4-3) connects without any problems while the current Testing (0.6.10-2) fails in WPA handshake. This bug seem be patched in the upstream version. The patch can be find in the CyanogenMod Project: http://tinyurl.com/24bec6s Looks like it was cherry picked from upstream authour, it'd be nice to locate that in the git from w1.fi rather than somewhere else. Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599241: [Pkg-sysvinit-devel] Bug#599241: Acknowledgement (Please remove obsolete usplash integration)
On Wednesday 06 October 2010 13:54:27 Michael Biebl wrote: It also looks like, that neither splashy nor plymouth (the two remaining boot splash programs) use the splash api provided by initscripts. So I'm wondering if all splash related functionality should be ripped out of initscripts. With no-one actually using it, it only bloats and slows down the initscripts. I'd love to see that crap go - but will be on holidays for a couple of weeks. I'd be more than happy to apply a patch to packaging in SVN once returned, an NMU would also not be out of order considering that us maintainers are busy with real life and are currently really struggling to pull together changes wanted for squeeze. We do have a current release team grant for upload with the changes already committed to our SVN. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597338: [Pkg-sysvinit-devel] Bug#597338: Do not unmount virtual/kernel fs as it breaks shutdown/reboot when using systemd
On Sunday 19 September 2010 04:47:24 Michael Biebl wrote: Package: initscripts Version: 2.88dsf-12 Severity: normal Tags: patch Hi, systemd is a new init systemd, which makes use of cgroups to track running processes. The cgroupfs is mounted below /sys/fs/cgroup as shown below: $ mount | grep cgroup tmpfs on /sys/fs/cgroup type tmpfs (rw,noexec,nosuid,nodev,relatime,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,noexec,nosuid,nodev,relatime,cpuset) cgroup on /sys/fs/cgroup/ns type cgroup (rw,noexec,nosuid,nodev,relatime,ns) cgroup on /sys/fs/cgroup/cpu type cgroup (rw,noexec,nosuid,nodev,relatime,cpu) cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,noexec,nosuid,nodev,relatime,cpuacct) cgroup on /sys/fs/cgroup/devices type cgroup (rw,noexec,nosuid,nodev,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,noexec,nosuid,nodev,relatime,freezer) cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,noexec,nosuid,nodev,relatime,net_cls) /etc/init.d/umountfs tries to unmount those file systems on shutdown. As systemd still uses them, it fails, which results in error messags during reboot/shutdown. I discussed this with Tollef (Debian systemd maintainer) and Kay Sievers (udev and systemd upstream developer). We came to the conclusion that virtual/kernel file systems should not be unmounted at all, as there is no good reason to do so. The attached patch does just that. It skips all mount points below /sys/* I've been using this patch for some time now without any problems. Please consider applying it in the next upload. Thanks for the patch, it has been applied. Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594253: [Pkg-sysvinit-devel] Bug#594253: init.d/rc concurrent shutdown tries to run the stop action twice
On Wednesday 25 August 2010 07:05:14 Ron wrote: Package: sysv-rc Version: 2.86.ds1-65 Severity: normal Hi Petter :) Thanks for the tips, it turns out this is nothing particularly tricky at all, it's just a plain vanilla bug in /etc/init.d/rc ; Around line 184 we have this code: case $runlevel in 0|6) ACTION=stop ... Followed by this at line 220: if [ makefile = $CONCURRENCY ] then [ $previous != N ] startup stop ... which calls 'startup stop' the first time, and is followed at line 268 by: if [ makefile = $CONCURRENCY ] then if [ S = $runlevel ] then startup boot else startup $ACTION fi else ... Which then calls 'startup stop' again :( Thanks for the report, this change should sort out the issue: diff -u sysvinit-2.88dsf/debian/src/sysv-rc/etc/init.d/rc sysvinit-2.88dsf/debian/src/sysv-rc/etc/init.d/rc --- sysvinit-2.88dsf/debian/src/sysv-rc/etc/init.d/rc +++ sysvinit-2.88dsf/debian/src/sysv-rc/etc/init.d/rc @@ -217,10 +215,13 @@ done step=0 + # First, run the KILL scripts. if [ makefile = $CONCURRENCY ] then - [ $previous != N ] startup stop - # First, run the KILL scripts. + if [ $ACTION = start ] [ $previous != N ] + then + startup stop + fi elif [ $previous != N ] then # Run all scripts with the same level in parallel --- Thanks, Kel -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536502: releasing ownership of crda/wireless-regdb ITP's
retitle 536502 RFP: crda -- wireless Central Regulatory Domain Agent noowner 536502 retitle 572220 RFP: wireless-regdb -- wireless regulatory database noowner 572220 thanks I've owned these ITP's for over a month now and failed to close them with an upload of this software to Debian; therefore I have failed and do not wish to block efforts from anyone else who is interested. I've lost all momentum/motivation required to get these into Debian. Upstream is no longer receptive to my opinion that their default to installing a prebuilt/presigned regulatory.bin is not an option for Debian, and I've come up with a few NAK'd patches which try to make the build system more sympathetic to my cause. Existing packages are at: svn://svn.debian.org/pkg-wpa/crda/trunk http://svn.debian.org/wsvn/pkg-wpa/crda/trunk/ svn://svn.debian.org/pkg-wpa/wireless-regdb/trunk http://svn.debian.org/wsvn/pkg-wpa/wireless-regdb/trunk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573004: insserv: Please provide machine parseable output
On Monday 08 March 2010 17:23:56 Petter Reinholdtsen wrote:
[Alexander Wirt]
Therefore we would need a stable, machine parseable
output. Something like
S:NUM:RUNLEVELS:SCRIPT
K:NUM:RUNLEVELS:SCRIPT
or something like this comes into mind.
If upstream is willing, which I believe is the case but would have to
be verified, I would be happy to have this as part of the insserv
package. There is some debug code already to dump the script order.
A patch to rewrite this to be available also in non-debug builds would
probably provide what you want.
Patches welcome. :)
I added a patch to insserv which can output something like:
$ ./insserv -s
K:04:0 6:hwclock.sh
K:07:0 6:umountfs
K:03:0 1 6:rsyslog
K:04:0 6:umountnfs.sh
K:02:0 6:sendsigs
...
S:02:2 3 4 5:dnsmasq
S:02:2 3 4 5:irqbalance
S:02:2 3 4 5:cpufrequtils
S:01:2 3 4 5:loadcpufreq
...
For all scripts in init.d dir.
Is that okay?
This might make something like a runlevel.conf configuration:
./insserv -s | sort | perl -e '
printf(#%s\t%-15s %-15s %s\n, sort, off, on, script);
while (STDIN) {
chomp;
($sk, $seq, $lvls, $name) = split(:);
printf(%.2d\t%-15s %-15s %s\n, $seq,
$sk eq K ? join(,, split( , $lvls)) : -,
$sk eq S ? join(,, split( , $lvls)) : -,
$name);
}'
Thanks, Kel.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575031: Some udev info
Hi, Petter asked me to add this information, even though I do not fully understand the finer details of this bug report. udevadm can help simulate the plug/unplug events without actually doing that physically. These commands trigger KDE's media manager to show/hide the sdc1 block device, a usb stick, on my normal system (not Debian-edu/ltspfs): /sbin/udevadm trigger --action=remove --subsystem-match=block --sysname-match=sdc1 /sbin/udevadm trigger --action=add --subsystem-match=block --sysname-match=sdc1 You can also use 'udevadm monitor' to look at what udev is thinking about as you unplug/plug removable devices. Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579297: wpasupplicant: wpa_supplicant disconnects and fails to reconnect (wpa-enterprise)
On Tuesday 27 April 2010 17:59:26 Georges Toth wrote: On Tuesday 27 April 2010 08:42:15 k...@otaku42.de wrote: Package: wpasupplicant Version: 0.6.10-2 Severity: grave Justification: renders package unusable For your porticular use case maybe, but that does not make a grave severity rating for the package. I don't agree as many people use eduroam or a similar network and this problem has been reported oftenly, also on ubuntu. Hence it's not a special rare use-case. I never said it was a rare case. This simply does not meet the criteria of of a grave bug: makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package http://www.debian.org/Bugs/Developer#severities So this bug makes connecting to a certain type of network, not even fail immediately, but after some amount of time. This software currently fulfills all of my use cases without annoyance. AFAIK, wpasupplicant currently does not delete random data or open gaping holes in the system which may be exploited. You may only use this software to connect to one network, which may make it feel mostly unusable but you must consider all other use cases before selecting the highest severity. On ubuntu it has been suggested that a temporary solution would be to compile wpasupplicant with gnutls. https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/429370 The best place to seek support about this is the hostap mailing list: http://lists.shmoo.com/mailman/listinfo/hostap That's what I did and am waiting for a reply. Good, I hope that more knowledgeable people who listen to that list may have a clue and can help. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536502: ITP: crda -- wireless Central Regulatory Domain Agent
On Sunday 25 April 2010 21:06:18 Petter Reinholdtsen wrote: Is this the same package that is already packaged for Ubuntu as URL: https://launchpad.net/ubuntu/+source/wireless-crda ? Same package, no. Same software, yes. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578308: insserv: Warns about disabled services every time update-rc.d gets run.
On Monday 19 April 2010 05:32:42 Kurt Roeckx wrote: Package: insserv Version: 1.12.0-14 Severity: important If you follow the policy way of disabling a service, like for instance running update-rc.d XXX disable 2, you'll get a warning like: insserv: warning: current start runlevel(s) (3 4 5) of script `XXX' overwrites defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (2) of script `XXX' overwrites defaults (empty). I don't need to get 2 warnings because I install something but disable it. And you get that warning any time update-rc.d is run like upgrade or install of an unrelated package also having an init script. While integrating insserv into Debian, insserv was made to be quite verbose about differences between declared LSB configuration and 'on disk' configuration for all scripts, not just the one being operated on. It may be time to revisit this feature and cosmetically castrate it by making insserv only complain about the script which it is currently acting upon. However, removing this noisy output may make it easy for buggy packages to avoid scrutiny. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577478: [pkg-wpa-devel] Bug#577478: /etc/ifplug/action.d/action_wpa is a bad idea.
On Monday 12 April 2010 09:55:53 Matthew W. S. Bell wrote: /etc/ifplug/action.d/action_wpa Only modifies interfaces using the wpa-roam/wpa_action stuff, which is exactly its intention. If it does otherwise the details need to be made clear, the situation debugged and fixed up. Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577226: [apt] improve Dpkg::Chroot-Directory for installation of packages in chroot
Package: apt
Version: 0.7.25.3
Severity: wishlist
Tags: patch
Hi,
Here is a python program which bootstraps a sid system, then attempts to
install a package in the chroot:
---
#!/usr/bin/python
import apt.cache
import apt_pkg
import os
import subprocess
import sys
subprocess.call('debootstrap --variant=minbase sid /tmp/crap
http://localhost:/debian/'.split())
apt_pkg.init()
apt_pkg.config.set('Dpkg::Chroot-Directory', '/tmp/crap')
cache = apt.cache.Cache(rootdir='/tmp/crap')
apt_pkg.Config.clear(DPkg::Pre-Install-Pkgs)
cache.update()
cache.open()
cache['hello'].mark_install()
cache.commit()
---
It fails, because after chroot('/tmp/crap') the later dpkg process gets given
a filename argument which begins with the pathname to chroot itself and is
not accessible:
---
Reading package lists... Done
Building dependency tree... Done
Building data structures... Done
Reading package lists... Done
Building dependency tree... Done
Building data structures... Done
Chrooting into /tmp/crap/
dpkg: error processing /tmp/crap/var/cache/apt/archives/hello_2.5-1_amd64.deb
(--unpack):
cannot access archive: No such file or directory
Errors were encountered while processing:
/tmp/crap/var/cache/apt/archives/hello_2.5-1_amd64.deb
Traceback (most recent call last):
File ./test_apt.py, line 17, in module
cache.commit()
File /usr/lib/python2.5/site-packages/apt/deprecation.py, line 98, in
deprecated_function
return func(*args, **kwds)
File /usr/lib/python2.5/site-packages/apt/cache.py, line 381, in commit
raise SystemError(installArchives() failed)
SystemError: installArchives() failed
---
The following patch adds some logic to check each File, when
DPkg::Chroot-Directory != '/', to see if it begins with the pathname
of the chroot. If it does, it returns a substring of File without the
chroot pathname. It is careful not to strip the leading / from any File.
---
--- a/apt-pkg/deb/dpkgpm.cc
+++ b/apt-pkg/deb/dpkgpm.cc
@@ -124,6 +124,18 @@ bool pkgDPkgPM::Install(PkgIterator Pkg,
if (File.empty() == true || Pkg.end() == true)
return _error-Error(Internal Error, No file name for %s,Pkg.Name());
+ // If the filename string begins with DPkg::Chroot-Directory, return the
+ // substr that is within the chroot so dpkg can access it.
+ string chrootdir = _config-FindDir(DPkg::Chroot-Directory,/);
+ if (chrootdir.compare(/) != 0 File.find(chrootdir) == 0)
+ {
+ size_t len = chrootdir.length();
+ if (chrootdir.at(len - 1) == '/')
+len--;
+ List.push_back(Item(Item::Install,Pkg,File.substr(len)));
+ return true;
+ }
+
List.push_back(Item(Item::Install,Pkg,File));
return true;
}
---
Can you please consider applying it?
Thanks, Kel.
--- System information. ---
Architecture: amd64
Kernel: Linux 2.6.33-2.slh.3-sidux-amd64
Debian Release: squeeze/sid
500 unstablelocalhost
1 experimentallocalhost
--- Package information. ---
Depends (Version) | Installed
===-+-=
libc6(= 2.3.4) | 2.10.2-6
libgcc1(= 1:4.1.1) | 1:4.4.3-7
libstdc++6 (= 4.4.0) | 4.4.3-7
debian-archive-keyring | 2009.01.31
Package's Recommends field is empty.
Suggests(Version) | Installed
=-+-===
aptitude |
OR synaptic |
OR wajig |
dpkg-dev | 1.15.5.6
apt-doc |
bzip2 | 1.0.5-4
lzma | 4.43-14
python-apt| 0.7.94.2
--
To UNSUBSCRIBE, email to debian-bugs-dist-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#571640: debhelper: qmake build system can't be set to use qmake-qt3 or qmake-qt4
On Tuesday 02 March 2010 08:37:44 Michael Karcher wrote: Am Dienstag, den 02.03.2010, 07:44 +1000 schrieb Kel Modderman: The qmake build system in debhelper calls qmake, which, dependent on installed packages, is either Qt 3 or the Qt 4 version. If both Qt versions are installed, qmake defaults to qmake-qt3 (priority 45) over qmake-qt4 (priority 40), making the automatic build system unable to build Qt 4 packages. In the future, these build systems may be able to handle their own specific options. This build system could accept a --qmake option which sets the qmake binary to be called. That sounds like a good idea. An option to choose either qmake-qt3 or qmake-qt4, or even hard wiring qmake-qt4 as the automatic build system is mainly used for new packages that mainly use qt4 would be nice, IMHO. Hardcoding anything would be crap. Which also applies to qmake (as it is now) as well. qmake-qt4 is at least consistent on all Debian Systems, without needing a Build-Conflicts on Qt3's qmake. Nah, I think 'qmake' is the best we can do right now. It works in a clean chroot (and can be made more robust with build-conflicts, but thats a pain for a host system) and allows to take advantage of benefits of honouring noopt, nostrip DEB_BUILD_OPTIONS, being able to easily override LDFLAGS and so on, which is what I wanted to do with my couple of measly qt packages. There is no way that I know of to detect if source files of qt projects require qt3 or qt4. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536502: change ITP to RFP
retitle 536502 ITP: crda -- wireless Central Regulatory Domain Agent owner 536502 Kel Modderman k...@otaku42.de thanks Package will be maintained by pkg-wpa group. Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572220: ITP: wireless-regdb -- wireless regulatory database
Package: wnpp Severity: wishlist Owner: Kel Modderman k...@otaku42.de * Package name: wireless-regdb Upstream Author : Luis R. Rodriguez mcg...@gmail.com * URL : http://wireless.kernel.org/en/developers/Regulatory/#Theregulatorydatabase * License : ISC Programming Lang: C, Python Description : wireless regulatory database This package contains the wireless regulatory database used by the Central Regulatory Database Agent (CRDA) to configure wireless devices to operate within the radio spectrum allowed in the local jurisdiction. . This regulatory information is provided with no warranty either expressed or implied. Only Linux drivers which use cfg80211 framework can make use of the regulatory database and CRDA. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572143: [pkg-wpa-devel] Bug#572143: wpasupplicant: dbus config file wrong - doesn't associate
On Tuesday 02 March 2010 07:04:44 Oliver Joa wrote: Package: wpasupplicant Version: 0.6.10-1 Severity: important Same Problem like in Bug #567710. On my System there is a wpa_supplicant running all the time: 13169 ?S 0:00 /sbin/wpa_supplicant -u -s I configured my Wireless-Interface like this: allow-hotplug wlan0 iface wlan0 inet manual pre-up /sbin/iwconfig wlan0 txpower auto wpa-driver wext wpa-roam /etc/wpa_supplicant/home.conf post-down /sbin/iwconfig wlan0 txpower off If I do a ifup wlan0, the wpa_supplicant is started twice, the already running process is not stopped. There is a conflict and the wlan0 does not work. I tried to stop the running process, but it restarts suddenly. I replaced the /sbin/wpa_supplicant by a shell script with a sleep 86000 and killed the process so that it can not restart again. After this I replaced the binary with the original one and made a ifup wlan0 and it worked. What is the Problem? Why is /sbin/wpa_supplicant -u -s always running? On my other Laptop with Lenny there is no process running. You have network-manager, WICD or some other software installed which starts it. All these other softwares conflict with settings made in /etc/network/interfaces to an extent. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571640: debhelper: qmake build system can't be set to use qmake-qt3 or qmake-qt4
On Saturday 27 February 2010 03:31:21 Michael Karcher wrote: Package: debhelper Version: 7.4.13 Severity: normal The qmake build system in debhelper calls qmake, which, dependent on installed packages, is either Qt 3 or the Qt 4 version. If both Qt versions are installed, qmake defaults to qmake-qt3 (priority 45) over qmake-qt4 (priority 40), making the automatic build system unable to build Qt 4 packages. In the future, these build systems may be able to handle their own specific options. This build system could accept a --qmake option which sets the qmake binary to be called. For now you can use Build-Conflicts, but thats not as convenient. An option to choose either qmake-qt3 or qmake-qt4, or even hard wiring qmake-qt4 as the automatic build system is mainly used for new packages that mainly use qt4 would be nice, IMHO. Hardcoding anything would be crap. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525101: [pkg-wpa-devel] Bug#525101: wpasupplicant: does not reassociate after suspend-resume cycle
On Monday 27 April 2009 19:34:52 Marcus Better wrote: Kel Modderman skrev: Could also be a bug in the kernel module for your wireless device. It is not uncommon to see funny driver errors after suspend/resume. Ok, I think I found a corresponding upstream bug report. I would reassign the bug to linux-2.6 but have to confirm on a Debian kernel first. The upstream bug tracker that was paired with this reports indicates the situation may have changed. This is almost certainly a bug in the wireless driver or firmware and not wpa_supplicant so can I please request you reassign or update this report. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571029: [pkg-wpa-devel] Bug#571029: hostapd: if-pre-up script error
tags 571029 pending thanks On Tuesday 23 February 2010 08:05:28 green wrote: Package: hostapd Version: 1:0.6.10-1 Severity: normal I have /etc/network/interfaces set up to run hostapd like this: auto br0 iface br0 inet static hostapd /etc/hostapd/hostapd.conf address 192.168.68.1 netmask 255.255.255.0 network 192.168.68.0 broadcast 192.168.68.255 bridge_ports eth1 eth2 eth3 wlan0 When running ifup br0, I get: /etc/network/if-pre-up.d/hostapd: line 91: [: missing `]' run-parts: /etc/network/if-pre-up.d/hostapd exited with return code 1 This is easily fixed by adding a space after the '0' (zero) on line 91; from: if [ $? -eq 0]; then to: if [ $? -eq 0 ]; then Thanks for spotting that stupid error. Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570116: hostapd: diff for NMU version 1:0.6.10-1.1
On Tuesday 23 February 2010 20:05:31 Jan Dittberner wrote: tags 570116 + patch thanks Hello pkg-wpa Maintainers, I got the same problem after an update from 2.6.32-trunk (squeeze) to 2.6.32-2 (sid) this morning. I applied the patch mentioned in this bug report and got hostapd working again. I use an ath9k based card if this matters. Thanks for feedback. Here is the lspci output: 03:07.0 Network controller: Atheros Communications Inc. AR922X Wireless Network Adapter (rev 01) Subsystem: D-Link System Inc Device 3a78 Flags: bus master, 66MHz, medium devsel, latency 168, IRQ 21 Memory at fdce (32-bit, non-prefetchable) [size=64K] Capabilities: [44] Power Management version 2 Kernel driver in use: ath9k I've prepared an NMU for hostapd (versioned as 1:0.6.10-1.1) but did not upload it. Please tell me if it is ok to upload it or whether one of you wants to upload it. I'd like to fix some other bugs in the next upload too. If we have not acted in the next 7 days feel free to NMU. Are you interested in co-maintaining hostapd? Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570688: wpasupplicant: using the nl80211 driver still requires WEXT support in the kernel
On Monday 22 February 2010 06:13:52 Mircea Gherzan wrote: Kel Modderman k...@otaku42.de wrote: 0.6.11 is not released at the time of writing. That commit is in 0.6.10 anyway. Sorry, I meant 0.7.1, not 0.6.11. That commit is not even close to 0.6.10. The -stable branch still contains WEXT code: Okay, I misunderstood how git works when displaying diff's. The commit 'dbb2618300a5ed8349754bfbdec3d9c1eda9df38' looks like it is one of many commits which remove WEXT code, and is not applicable to 0.6.10 by itself. ioctl(drv-ioctl_sock, SIOCSIWAUTH, iwr) Is there any change to package 0.7.1 (at least in Sid) ? Not 'til after squeeze. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570958: [Pkg-sysvinit-devel] Bug#570958: sysvinit-utils: what are those boot and runlevel directories in /etc/init.d/?
On Monday 22 February 2010 23:32:20 Ferenc Wagner wrote: Package: sysvinit-utils Version: 2.87dsf-8.1 Severity: normal Hi, man startpar says (focus on the last sentence): The -M option switches startpar into a make(1) like behaviour. This option takes three different arguments: boot, start, and stop for reading .depend.boot or .depend.start or .depend.stop respectively in the directory /etc/init.d/. By scanning the boot and runlevel directories in /etc/init.d/ it then executes the appropriate scripts in parallel. There are no directories under /etc/init.d on my systems, isn't this some leftover (and confusing) SuSE heritage? Yeah, it should be /etc/rc*.d/. SuSE puts these directories in /etc/init.d afaik. Thanks, Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570688: wpasupplicant: using the nl80211 driver still requires WEXT support in the kernel
severity 570688 wishlist thanks On Sunday 21 February 2010 04:32:02 Mircea Gherzan wrote: Package: wpasupplicant Version: 0.6.10-1 Severity: important In 0.6.10, nl80211 driver still contains some WEXT code (iotctl/SIOCSIWAUTH). Therefore, on custom-configured vanilla kernels, without kernel WEXT support, wpa_supplicant fails to work as expected. Commit dbb2618300a5ed8349754bfbdec3d9c1eda9df38 from upstream solves this. So please upgrade to version 0.6.11. 0.6.11 is not released at the time of writing. That commit is in 0.6.10 anyway. Kel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566840: a possible option for selecting qmake command
Hey Joey,
After reading #363150 and #409953 and observing that a few packages call
a versioned qmake binary (eg. qmake-qt4) rather than just 'qmake', and also
seeing that build classes might possibly support option parsing in the future
I'd like to put forward a version of the build class which would accept
a --qmake= option, based on the examples in the option parsing patch attached
to #543507. It'd allow:
dh_auto_configure --qmake=qmake-qt3
... and the build class would call qmake-qt3 instead of the unversioned qmake,
which may point to an alternative qmake binary if other versions of qt are
installed in system.
What are your thoughts about it? Example packages which may use the option
are touchfreeze, keepassx.
Where's the best place to document the build system? POD in the class file?
Thanks, Kel
---
# A debhelper build system class for Qt projects
# (based on the makefile class).
#
# Copyright: © 2010 Kelvin Modderman
# License: GPL-2+
package Debian::Debhelper::Buildsystem::qmake;
use strict;
use warnings;
use Debian::Debhelper::Dh_Lib qw(error);
use base 'Debian::Debhelper::Buildsystem::makefile';
sub DESCRIPTION {
qmake (*.pro);
}
sub OPTIONS {
my $this=shift;
(qmake=s = \$this-{opt_qmake})
}
sub check_auto_buildable {
my $this=shift;
my @projects=glob($this-get_sourcepath('*.pro'));
my $ret=0;
if (@projects 0) {
$ret=1;
# Existence of a Makefile generated by qmake indicates qmake
# class has already been used by a prior build step, so should
# be used instead of the parent makefile class.
my $mf=$this-get_buildpath(Makefile);
if (-e $mf) {
$ret = $this-SUPER::check_auto_buildable(@_);
open(my $fh, '', $mf)
or error(unable to open Makefile: $mf);
while($fh) {
if (m/^# Generated by qmake/i) {
$ret++;
last;
}
}
close($fh);
}
}
return $ret;
}
sub configure {
my $this=shift;
my $qmake=$this-{opt_qmake} ? $this-{opt_qmake} : qmake;
my @options;
my @flags;
push @options, '-makefile';
push @options, '-nocache';
if ($ENV{CFLAGS}) {
push @flags, QMAKE_CFLAGS_RELEASE=$ENV{CFLAGS};
push @flags, QMAKE_CFLAGS_DEBUG=$ENV{CFLAGS};
}
if ($ENV{CXXFLAGS}) {
push @flags, QMAKE_CXXFLAGS_RELEASE=$ENV{CXXFLAGS};
push @flags, QMAKE_CXXFLAGS_DEBUG=$ENV{CXXFLAGS};
}
if ($ENV{LDFLAGS}) {
push @flags, QMAKE_LFLAGS_RELEASE=$ENV{LDFLAGS};
push @flags, QMAKE_LFLAGS_DEBUG=$ENV{LDFLAGS};
}
push @flags, QMAKE_STRIP=:;
push @flags, PREFIX=/usr;
$this-doit_in_builddir($qmake, @options, @flags, @_);
}
sub install {
my $this=shift;
my $destdir=shift;
# qmake generated Makefiles use INSTALL_ROOT in install target
# where one would expect DESTDIR to be used.
$this-SUPER::install($destdir, INSTALL_ROOT=$destdir, @_);
}
1;
---
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566840: set INSTALL_ROOT variable for install
On Thursday 28 January 2010 08:13:31 Joey Hess wrote:
Kel Modderman wrote:
if (@projects 0 -e $projects[0]) {
This -e test seems unnecessary, unless a .pro file could be a dangling
symlink? Otherwise, the glob will only populate @projects if *.pro files
exit.
Indeed, it seems unnecessary. It was added as a paranoid precaution.
Otherwise, it looks perfect.
Awesome.
Thanks, Kel.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566840: set PREFIX=/usr during qmake command
Hi,
Here is yet another revision which sets the PREFIX variable to '/usr' which
seems commonly used by Qt projects. Also removed the -e test discussed
previously.
Thanks, Kel.
---
# A debhelper build system class for Qt projects
# (based on the makefile class).
#
# Copyright: © 2010 Kelvin Modderman
# License: GPL-2+
package Debian::Debhelper::Buildsystem::qmake;
use strict;
use warnings;
use Debian::Debhelper::Dh_Lib qw(error);
use base 'Debian::Debhelper::Buildsystem::makefile';
sub DESCRIPTION {
qmake (*.pro);
}
sub check_auto_buildable {
my $this=shift;
my @projects=glob($this-get_sourcepath('*.pro'));
my $ret=0;
if (@projects 0) {
$ret=1;
# Existence of a Makefile generated by qmake indicates qmake
# class has already been used by a prior build step, so should
# be used instead of the parent makefile class.
my $mf=$this-get_buildpath(Makefile);
if (-e $mf) {
$ret = $this-SUPER::check_auto_buildable(@_);
open(my $fh, '', $mf)
or error(unable to open Makefile: $mf);
while($fh) {
if (m/^# Generated by qmake/i) {
$ret++;
last;
}
}
close($fh);
}
}
return $ret;
}
sub configure {
my $this=shift;
my @options;
my @flags;
push @options, '-makefile';
push @options, '-nocache';
if ($ENV{CFLAGS}) {
push @flags, QMAKE_CFLAGS_RELEASE=$ENV{CFLAGS};
push @flags, QMAKE_CFLAGS_DEBUG=$ENV{CFLAGS};
}
if ($ENV{CXXFLAGS}) {
push @flags, QMAKE_CXXFLAGS_RELEASE=$ENV{CXXFLAGS};
push @flags, QMAKE_CXXFLAGS_DEBUG=$ENV{CXXFLAGS};
}
if ($ENV{LDFLAGS}) {
push @flags, QMAKE_LFLAGS_RELEASE=$ENV{LDFLAGS};
push @flags, QMAKE_LFLAGS_DEBUG=$ENV{LDFLAGS};
}
push @flags, QMAKE_STRIP=:;
push @flags, PREFIX=/usr;
$this-doit_in_builddir('qmake', @options, @flags, @_);
}
sub install {
my $this=shift;
my $destdir=shift;
# qmake generated Makefiles use INSTALL_ROOT in install target
# where one would expect DESTDIR to be used.
$this-SUPER::install($destdir, INSTALL_ROOT=$destdir, @_);
}
1;
---
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566840: improved check_auto_buildable
Hi,
After irc discussion with Modestas, here is an update which takes more
care to set correct return value in check_auto_buildable.
Thanks, Kel.
---
# A debhelper build system class for Qt projects
# (based on the makefile class).
#
# Copyright: © 2010 Kelvin Modderman
# License: GPL-2+
package Debian::Debhelper::Buildsystem::qmake;
use strict;
use warnings;
use Debian::Debhelper::Dh_Lib qw(error);
use base 'Debian::Debhelper::Buildsystem::makefile';
sub DESCRIPTION {
qmake (*.pro);
}
sub check_auto_buildable {
my $this=shift;
my @projects=glob($this-get_sourcepath('*.pro'));
my $ret=0;
if (@projects 0 -e $projects[0]) {
$ret=1;
# Existence of a Makefile generated by qmake indicates qmake
# class has already been used by a prior build step, so should
# be used instead of the parent makefile class.
my $mf=$this-get_buildpath(Makefile);
if (-e $mf) {
$ret = $this-SUPER::check_auto_buildable(@_);
open(my $fh, '', $mf)
or error(unable to open Makefile: $mf);
while($fh) {
if (m/^# Generated by qmake/i) {
$ret++;
last;
}
}
close($fh);
}
}
return $ret;
}
sub configure {
my $this=shift;
my @options;
my @flags;
push @options, '-makefile';
push @options, '-nocache';
if ($ENV{CFLAGS}) {
push @flags, QMAKE_CFLAGS_RELEASE=$ENV{CFLAGS};
push @flags, QMAKE_CFLAGS_DEBUG=$ENV{CFLAGS};
}
if ($ENV{CXXFLAGS}) {
push @flags, QMAKE_CXXFLAGS_RELEASE=$ENV{CXXFLAGS};
push @flags, QMAKE_CXXFLAGS_DEBUG=$ENV{CXXFLAGS};
}
if ($ENV{LDFLAGS}) {
push @flags, QMAKE_LFLAGS_RELEASE=$ENV{LDFLAGS};
push @flags, QMAKE_LFLAGS_DEBUG=$ENV{LDFLAGS};
}
push @flags, QMAKE_STRIP=:;
$this-doit_in_builddir('qmake', @options, @flags, @_);
}
1;
---
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
