Bug#495848: package deviates from standard mail-transport-agent dependency.
Package: fwlogwatch Severity: normal Hello! Your packag depends on postfix | mail-transport-agent. Exim (v4) is generally considered the default mta in Debian and is also the package providing mail-transport-agent which has the highest priority. Is there any particular reason why your package needs to deviate from which mta is pulled in by default? If not, could you please consider streamlining your package with the rest so we have a uniform behaviour in debian? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495854: package deviates from standard mail-transport-agent dependency.
Package: opendb Severity: normal Hello! Your packag depends on postfix | mail-transport-agent. Exim (v4) is generally considered the default mta in Debian and is also the package providing mail-transport-agent which has the highest priority. Is there any particular reason why your package needs to deviate from which mta is pulled in by default? If not, could you please consider streamlining your package with the rest so we have a uniform behaviour in debian? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495845: package deviates from standard mail-transport-agent dependency.
Package: dak Severity: normal Hello! Your packag depends on postfix | mail-transport-agent. Exim (v4) is generally considered the default mta in Debian and is also the package providing mail-transport-agent which has the highest priority. Is there any particular reason why your package needs to deviate from which mta is pulled in by default? If not, could you please consider streamlining your package with the rest so we have a uniform behaviour in debian? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495853: package deviates from standard mail-transport-agent dependency.
Package: sks Severity: normal Hello! Your packag depends on postfix | mail-transport-agent. Exim (v4) is generally considered the default mta in Debian and is also the package providing mail-transport-agent which has the highest priority. Is there any particular reason why your package needs to deviate from which mta is pulled in by default? If not, could you please consider streamlining your package with the rest so we have a uniform behaviour in debian? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495844: package deviates from standard mail-transport-agent dependency.
Package: cyrus-common-2.2 Severity: normal Hello! Your packag depends on postfix | mail-transport-agent. Exim (v4) is generally considered the default mta in Debian and is also the package providing mail-transport-agent which has the highest priority. Is there any particular reason why your package needs to deviate from which mta is pulled in by default? If not, could you please consider streamlining your package with the rest so we have a uniform behaviour in debian? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495849: package deviates from standard mail-transport-agent dependency.
Package: ilohamail Severity: normal Hello! Your packag depends on postfix | mail-transport-agent. Exim (v4) is generally considered the default mta in Debian and is also the package providing mail-transport-agent which has the highest priority. Is there any particular reason why your package needs to deviate from which mta is pulled in by default? If not, could you please consider streamlining your package with the rest so we have a uniform behaviour in debian? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495843: cvs-mailcommit: package deviates from standard mail-transport-agent dependency.
Package: cvs-mailcommit Severity: normal Hello! Your packag depends on postfix | mail-transport-agent. Exim (v4) is generally considered the default mta in Debian and is also the package providing mail-transport-agent which has the highest priority. Is there any particular reason why your package needs to deviate from which mta is pulled in by default? If not, could you please consider streamlining your package with the rest so we have a uniform behaviour in debian? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495855: package deviates from standard mail-transport-agent dependency.
Package: diffmon Severity: normal Hello! Your packag depends on sendmail | mail-transport-agent. Exim (v4) is generally considered the default mta in Debian and is also the package providing mail-transport-agent which has the highest priority. Is there any particular reason why your package needs to deviate from which mta is pulled in by default? If not, could you please consider streamlining your package with the rest so we have a uniform behaviour in debian? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495852: package deviates from standard mail-transport-agent dependency.
Package: mumble-server-web Severity: normal Hello! Your packag depends on postfix | mail-transport-agent. Exim (v4) is generally considered the default mta in Debian and is also the package providing mail-transport-agent which has the highest priority. Is there any particular reason why your package needs to deviate from which mta is pulled in by default? If not, could you please consider streamlining your package with the rest so we have a uniform behaviour in debian? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495856: package deviates from standard mail-transport-agent dependency.
Package: kuvert Severity: normal Hello! Your packag depends on sendmail | mail-transport-agent. Exim (v4) is generally considered the default mta in Debian and is also the package providing mail-transport-agent which has the highest priority. Is there any particular reason why your package needs to deviate from which mta is pulled in by default? If not, could you please consider streamlining your package with the rest so we have a uniform behaviour in debian? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495857: package deviates from standard mail-transport-agent dependency.
Package: sympa Severity: normal Hello! Your packag depends on sendmail | mail-transport-agent. Exim (v4) is generally considered the default mta in Debian and is also the package providing mail-transport-agent which has the highest priority. Is there any particular reason why your package needs to deviate from which mta is pulled in by default? If not, could you please consider streamlining your package with the rest so we have a uniform behaviour in debian? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495859: package deviates from standard mail-transport-agent dependency.
Package: uqwk Severity: normal Hello! Your packag depends on ssmtp | mail-transport-agent. Exim (v4) is generally considered the default mta in Debian and is also the package providing mail-transport-agent which has the highest priority. Is there any particular reason why your package needs to deviate from which mta is pulled in by default? If not, could you please consider streamlining your package with the rest so we have a uniform behaviour in debian? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495858: package deviates from standard mail-transport-agent dependency.
Package: movabletype-opensource Severity: normal Hello! Your packag depends on nullmailer | mail-transport-agent. Exim (v4) is generally considered the default mta in Debian and is also the package providing mail-transport-agent which has the highest priority. Is there any particular reason why your package needs to deviate from which mta is pulled in by default? If not, could you please consider streamlining your package with the rest so we have a uniform behaviour in debian? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495852: package deviates from standard mail-transport-agent dependency.
On ons, 2008-08-20 at 22:50 +0200, Patrick Matthäi wrote: I will change it with the next upload but I will not upload a new revision just because of this bug so it could happen, that it will be changed after Lenny. No rush. It's not critical in any way. I'm just happy to see that you agree in providing a reliable and uniform default, no matter what our personal preferences are. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495856: package deviates from standard mail-transport-agent dependency.
On tor, 2008-08-21 at 10:30 +1000, Alexander Zangerl wrote: if you have exim installed, kuvert does not override your wish. If you have *any* mta installed (including sendmail), the kuvert dependency will be fullfilled through the | mail-transport-agent alternative. the same happens if you tell apt to get an mta of your choice. if on the other hand you select no mta, you get my choice - which is anything BUT exim. This sucks. Please see the principle of leaste surprise. You should not end up with different mta installed based on in which order you installed your other packages. Is there any particular reason why your package needs to deviate from which mta is pulled in by default? i dislike exim extremely. Then please advocate that the global default is changed rather then having your own little mini-rebellion. Also, choice is not hurt by having one streamlined default so that argument is complete crap. Just because choice is an option doesn't mean we have to make a complete mess out of the entire distribution. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495853: package deviates from standard mail-transport-agent dependency.
On Thu, Aug 21, 2008 at 12:37:38AM -0700, Steve Langasek wrote: Where did you discuss this mass filing of (useless) bugs before you submitted them? The previous discussions has lead nowhere. No use in discussing it yet again, instead it's time to act! In particular, these bugs are *contrary* to the developing consensus in the thread at http://lists.debian.org/debian-devel/2008/05/msg00381.html ff. There where no consensus, since you where all just discussing overengineered solutions for solving the problem and all pointing out bugs in eachothers suggestions. Using exim4 | mail-transport-agent is the most straight-forward solution and will require minimal changes. When (or even if) the default mta changes, we can easily introduce the default-mta then (and maybe people would even have come up with a bug-free overengineered solution by then). I offer to fix up all packages to exim4 | mail-transport-agent *and* when there is a working default-mta proposal and a need for changing the actual default mta fix it up in every package. If people put as much effort into actually working on packages as they did on debating in useless threads that leads nowhere the distribution would be in a hell of alot better shape. Over and out. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495844: package deviates from standard mail-transport-agent dependency.
I see your problem, but on the other hand I don't think the current dep expresses it correctly. For anyone who already has an mta installed (which is a pretty high risk) the postfix | m-t-a will not do anything like you wish for. I don't know how the package management tools handle this, but I would look into how Dep: exim4 | m-t-a, Recommends: postfix would be resolved. That would in my mind more clearly express what you are after and since the package management tools nowadays installs recommends by default chances are the user will actually end up with a configuration you guys support even if they have a previous mta installed. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439268: patch to fix pam_mail quiet option.
tags 439268 + patch
thanks
The attached patch fixes the problem for me. HTH, HAND.
--
Regards,
Andreas Henriksson
Make quiet option of pam_mail work. Fixes http://bugs.debian.org/439268
Author: Andreas Henriksson [EMAIL PROTECTED]
Upstream status: N/A
diff -uri pam-1.0.1/modules/pam_mail/pam_mail.c pam-1.0.1-quiet/modules/pam_mail/pam_mail.c
--- pam-1.0.1/modules/pam_mail/pam_mail.c 2007-04-30 12:56:24.0 +0200
+++ pam-1.0.1-quiet/modules/pam_mail/pam_mail.c 2008-08-22 11:11:07.0 +0200
@@ -303,8 +303,13 @@
{
int retval;
-if (!(ctrl PAM_MAIL_SILENT) ||
- ((ctrl PAM_QUIET_MAIL) type == HAVE_NEW_MAIL))
+if ((ctrl PAM_MAIL_SILENT) ||
+ ((ctrl PAM_QUIET_MAIL) type != HAVE_NEW_MAIL))
+ {
+ D((keeping quiet));
+ retval = PAM_SUCCESS;
+ }
+else
{
if (ctrl PAM_STANDARD_MAIL)
switch (type)
@@ -345,11 +350,6 @@
break;
}
}
-else
- {
- D((keeping quiet));
- retval = PAM_SUCCESS;
- }
D((returning %s, pam_strerror(pamh, retval)));
return retval;
Bug#498498: iproute: adding route blackholes doesn't work for IPv6
On ons, 2008-09-10 at 15:43 +0200, Thomas Jacob wrote: [...] # ip route add to blackhole 2001::1/128 RTNETLINK answers: No such device [...] Could you please try to specify a device name as well? Seems to work here: $ ping6 -c 1 2001::1 PING 2001::1(2001::1) 56 data bytes --- 2001::1 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms $ sudo ip route add to blackhole 2001::1/128 dev lo $ ip -6 ro sh | grep 2001::1 unreachable 2001::1 dev lo metric 1024 error -101 mtu 16436 advmss 16376 hoplimit 4294967295 $ ping6 -c 1 2001::1 connect: Network is unreachable $ sudo ip ro del 2001::1 $ Please tell me if you still think this is a bug in iproute (and please describe it a bit more so I can understand the problem). -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497011: /sbin/ip: abbreviation of network-prefix is no longer possible with ip route
tag 497011 fixed-upstream thanks The patch I wrote to support classful abbrevated addresses has been supported applied in the upstream git repository. This means deprecated classfull addresses like 10.0/8 should now work again, but invalid address specifications that happened to work before like 10/8 still is treated as invalid. This is as far as I see we can go in backwards compatability. The upstream change was after all a bugfix (127.2/8 was treated as 127.2.0.0/8 which is wrong by all current and obsolete standards). I'll close this bug when we package the next upstream release. You could argue that this problem is only partially fixed, but that would only result in a wontfix tag and more clutter in the bug tracking system unless you have a really good idea on how to improve the situation. I hope the current situation is good enough. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494372: severity of 494372 is wishlist
# Automatically generated email from bts, devscripts version 2.10.35 # group with the other improve documentation-bugs for better buglist overview. severity 494372 wishlist -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499808: iproute: missing documentation for qdisc hfsc
On mån, 2008-09-22 at 17:42 +0200, Achim Schaefer wrote: the qdisc hfsc is completely not documented. Any help with improving the documentation would be greatly appreciated! For anyone interested in helping out, please also see the other documentation related bugs at http://bugs.debian.org/iproute . -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499808: iproute: missing documentation for qdisc hfsc
On Wed, Sep 24, 2008 at 08:19:20AM +0200, Achim Schaefer wrote: My problem is, I did not even find anything on the web. That problem is not localized to you anyone will have the same problem. ;) Some digging in the source code probably needed to find out all details. (Run apt-get source iproute and look in the iproute-*/tc/ directory.) There are some pages describing the algo, but I havn't found anything which would be similar to a documentation how to use it. I have an example which works more or less, but A first step would be a listing in the main tc manpage. To be hoest I'm not familiar with debian enouth to do this. Don't worry about the technical details of how to integrate it. I'd be happy to help out with manpage formatting, creating a patch and forwarding it upstream if you can work out a suitable text that we can use. It doesn't need to be complete (at first), as you said just mentioning something about it is better then nothing (although integrating something upstream is a bit of work, so we probably want to spin it a couple of times before doing that). (You can use any pseudo-formatting you like and just email whatever text you come up with to this bugreport, and I'll have a look at it.) Contributions on the documentation side is very needed and would be greatly appreciated! Unfortunately digging down into a qdisc to find out the details can be very time consuming, which is why we (the current Debian iproute maintainers) can't do it for *every* qdisc. We need help from people who use and are familiar with some qdisc to write something about that one. -- Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496269: possible cause of gvfs-fuse crash.
Hello! Very good information in the bugreport. I've had a quick look at it and here's my guess I'm probably totally wrong, and even if I'm right the real fix is still unknown. Both the valgrind run and the backtrace of the thread which gets the segfault contains run_sync_state_machine. In the backtrace there's also an assertion failure visible! g_input_stream_clear_pending: assertion `G_IS_INPUT_STREAM (stream)' failed The backtrace says we're doing a g_input_stream_read and Valgrind complains on line 450, which means res == -1. Combining these clews I think g_input_stream_read was called with a file-data_stream which for some reason is not a valid input stream, the first thing g_input_stream_read does is return -1 if this assertion fails, so io_error will still be NULL. On line 450 io_error is then dereferenced by io_error-message. An ugly fix might be to check if io_error is NULL before dereferencing it, but the real fix would be to figure out why the assertion fails! (Why is file-data_stream not a valid stream?) -- Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439268: [Fwd: Re: [PATCH] fix quiet option of pam_mail.]
tags 439268 + fixed-upstream thanks Forwarded Message From: Thorsten Kukuk [EMAIL PROTECTED] To: Andreas Henriksson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PATCH] fix quiet option of pam_mail. Date: Thu, 25 Sep 2008 13:53:26 +0200 On Sat, Sep 06, Andreas Henriksson wrote: Same patch as submitted to debian earlier, looks like an upstream bug so here you go. When the silent flag was not given, it cancelled out the quiet option. Make quiet option of pam_mail work. Fixes http://bugs.debian.org/439268 Thanks, I commited it into Linux-PAM CVS. Thorsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489340: iproute2: no error message when link up command fails.
Hi Stephen and co.!
Johannes Berg reported that iproute2 doesn't give any error message when
ip link set ... up failed for him (as opposed to ifconfig):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489340
The ways he suggested didn't work for me to reproduce, but I found out
simply using the wmaster0 device works as a testcase.
(You'll need a wireless device, probably with a driver based on the new
mac80211 stack).
I've debugged this into a place in the bundled rtnetlink library where
if there's a netlink error - it is ignored if there's no errno, which
seems weird. I don't really understand the code, but this proof of
concept patch makes ip link set dev wmaster0 up spit out an error
message atleast. Could you please have a look at what's going on here?
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 5ae64f7..afa58fb 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -351,6 +351,7 @@ int rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n,
pid_t peer,
if (errno == 0) {
if (answer)
memcpy(answer, h,
h-nlmsg_len);
+ fprintf(stderr, Unknown
netlink error.\n);
return 0;
}
perror(RTNETLINK answers);
For the record, here's what ifconfig says:
$ sudo ifconfig wmaster0 up
SIOCSIFFLAGS: Operation not supported
--
Regards,
Andreas Henriksson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489340: iproute2: no error message when link up command fails.
On ons, 2008-07-16 at 15:03 -0700, Stephen Hemminger wrote: On Thu, 17 Jul 2008 00:00:58 +0200 Andreas Henriksson [EMAIL PROTECTED] wrote: [...] + fprintf(stderr, Unknown netlink error.\n); return 0; [..] libnetlink shouldn't print the error, it needs to be done by the caller. ... and iproute should exit with a proper error code. This isn't possible today, as there's no way for the caller to detect the error! I was just trying to be a bit helpful on where we end up in the code. If anyone could help out with how to modify the code to solve all this, that would be nice. I don't understand the current code tries to do. (By the way, most uses of rtnl_* seems to be if (rtnl_* 0) exit(1); in iproute2 currently. The error messages are in libnetlink.) -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489340: iproute2: no error message when link up command fails.
On ons, 2008-07-16 at 15:53 -0700, Stephen Hemminger wrote:
The netlink message in question is marked as type ERROR but the errno
encoded in the message is zero.
if (h-nlmsg_type == NLMSG_ERROR) {
struct nlmsgerr *err = (struct nlmsgerr*)NLMSG_DATA(h);
if (l sizeof(struct nlmsgerr)) {
fprintf(stderr, ERROR truncated\n);
} else {
errno = -err-error;
if (errno == 0) {
if (answer)
memcpy(answer, h, h-nlmsg_len);
return 0;
}
perror(RTNETLINK answers);
}
So the netlink library just treats as a successful return.
Why? This seems like a really bad idea to me, and none of the callers in
iproute benefits from this as far as I can see.
Just ripping out the errno == 0 special casing looks like and option to
me, unless anyone can find a reason for it.
(It'll give an error message and an error exit code! The message will be
strange, but lets blame the kernel for that cosmetic issue. Atleast the
user got some kind of notification.)
Moving the return 0; inside the if (answer) would be another
(atleast for iproutes callers of the library functions)...
To me it looks like the problem is in the kernel sending back
a NLMSG_ERROR with errno of zero. Some code path isn't setting
it up properly.
None the less, it would be be good if the application wouldn't poop it's
pants when it can be avoided - broken kernel or not.
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 5ae64f7..4413165 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -348,12 +348,7 @@ int rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr
*n, pid_t peer,
fprintf(stderr, ERROR truncated\n);
} else {
errno = -err-error;
- if (errno == 0) {
- if (answer)
- memcpy(answer, h,
h-nlmsg_len);
- return 0;
- }
- perror(RTNETLINK answers);
+ perror(RTNETLINK error);
}
return -1;
}
--
Regards,
Andreas Henriksson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489340: retitle 489340 to errno not propagated when link up fails., reassign 489340 to linux-2.6 ...
# Automatically generated email from bts, devscripts version 2.10.34 retitle 489340 errno not propagated when link up fails. reassign 489340 linux-2.6 # see the attachment in the mail from Patrick McHardy. tags 489340 + patch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487541: Some result of eggdrop/tcl debugging.
Hello! As shown in Marcs backtrace, the reason the eggdrop freezes is because the Tcl_DoOneEvent function called from main goes sleeping even though it's passed the flag TCL_DONT_WAIT (which should make it a non-blocking function). I've looked at the differences between running in forground mode vs. background mode as this as reported works around the problem. The difference that makes the function not block is to avoid calling fork! Replace int xx = fork() in src/bg.c with int xx = 0 and you'll get a working (non-forking) eggdrop. (The other difference here would be that bg_do_detach() isn't called in the parent, but this doesn't make any difference. Try replacing it with exit(0) and you'll still get the freeze.) Next step would be to figure out why forking matters (Seems there's a home-grown tcl initialization method, init_tcl in src/tcl.c, which I'll treat as a likely suspect going forward...) -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497960: severity of 497960 is normal
On Sat, Sep 06, 2008 at 12:22:11PM +0200, Philipp Kern wrote: # oh noes, not a default build flavour, thus not RC severity 497960 normal Yet another case of policy common sense. By looking at debian/rules you can see that USE_OPENSSL=1 is a debian package construction and breaking it is a sucky regression no matter what policy says about it. (I guess the reason why the users of ircd-hybrid needs to rebuild in the first place is because of the distributable problems of GPL vs OpenSSL.) Anyway, ... The problem comes from the apparently untested patch which was added in the latest version. Snipped from the package changelog: * Add 19_sslonly.dpatch to allow setting a channel to be only joinable by SSL-users or people on localhost, thanks to Joshua Kwan. (Closes: #419934) Disabling this patch in debian/patches/00list would be a safe way of fixing the regression. (The feature in the patch might be a good idea when the patch is fixed, but all the patch does now is nothing in the non-ssl case and breaks build in the ssl case.) I've attached a build-fix which i have *no* *idea* if it's the correct fix, but it looks kind of like the localClient part was a cut'n'paste error from a couple of lines above where fd is used. -- Andreas Henriksson --- ircd-hybrid-7.2.2.dfsg.2/debian/patches/19_sslonly.dpatch 2008-09-06 16:14:19.0 +0200 +++ ircd-hybrid-7.2.2.dfsg.2-fixed/debian/patches/19_sslonly.dpatch 2008-09-06 16:15:23.0 +0200 @@ -71,7 +71,7 @@ +int fd = source_p-localClient-fd.fd; +fde_t *F = lookup_fd(fd); + -+if (F !F-ssl strcmp(source_p-localClient-sockhost, 127.0.0.1)) ++if (F !F-ssl strcmp(source_p-sockhost, 127.0.0.1)) +return (ERR_SSLONLYCHAN); +} +#else
Bug#497960: merge duplicate bugreports.
merge 497960 482630 thanks This was apparently a complete waste of my time as the problem and solution was already reported over 100 days ago. Sucks that I didn't spot that this was a duplicate report. -- Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480863: patch available for vino localOnly ipv4/ipv6 issue.
tags 480863 + patch thanks Just reporting that a patch is now available (awaiting review) in the upstream bug at http://bugzilla.gnome.org/show_bug.cgi?id=403192 -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464521: tag iproute traffic bug.
tag 464521 + pending thanks Justin B Rye answered the call for review of an updated package description which also includes the suggested improvement for searches for traffic includes iproute. (I made a minor change in the short description from networking control .. to networking and traffic control) The full commit details are available here: http://git.debian.org/?p=collab-maint/pkg-iproute.git;a=commitdiff;h=4a5a6b4b5ae4752dc96c877e810db171c29795f2 -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357172: iproute and dotted-quad netmask
tag 357272 = pending fixed 357172 20071016-1 found 357172 20071016-3 fixed 357172 20080108-1 thanks Oh fsck! I must have broken this when I reverted my fix and cherry-picked (parts of?) the upstream fix in -3. Anyway, it works with to-be-released version 20080108-1 in pkg-iproute git, so I'm marking it pending. Thanks for catching this. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357172: another thing about iproute and netmasks.
... and by the way: [EMAIL PROTECTED]:/tmp$ dpkg -l iproute | grep iproute ii iproute 20080108-1 Professional tools to control the networking in Linux kernels [EMAIL PROTECTED]:/tmp$ sudo ip route add 10.2.3.4/255.255.255.0 dev dummy0 RTNETLINK answers: Invalid argument [EMAIL PROTECTED]:/tmp$ sudo ip route add 10.2.3.0/255.255.255.0 dev dummy0 [EMAIL PROTECTED]:/tmp$ -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416687: ... obsolete /proc/sys/kernel/hotplug
Hello! The kernel version moving the hotplug over to /sys from /proc/sys is probably 2.6.16 (based on the date of the git changes and the release date of the kernel). The exact commit which introduces this is: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0f76e5acf9dc788e664056dda1e461f0bec93948 Please see the commit message which has a nice description. IIRC the statement that the old /proc/sys interface is obsolete is a bit strong and has been debated if it should be said to be obsolete at all. You are expected to have /proc/sys. Kernel people want to clean up /proc to only contain process information, but the truth is that we'll need to remain backwards compatibility in /proc for many years to go. Being an early adopter of /sys probably won't hurt though. HTH, HAND. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460657: libbeagle-dev: please ship examples
Package: libbeagle-dev Version: 0.3.0-2 Severity: wishlist Please install the examples/ found in the source under /usr/share/doc/libbeagle-dev/ Thanks. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libbeagle-dev depends on: ii libbeagle10.3.0-2library for accessing beagle using libbeagle-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459652: iproute-doc should only be built by binary-indep
Package: iproute Version: 20071016-3 Severity: wishlist In the latest upload we made iproute-doc an Architecture: all package, which it should be but it seems we missed one thing I noticed this in the build log: ERROR: Package builds iproute-doc_20071016-3_all.deb when binary-indep target is not called. This is a bug in the packaging. The file debian/rules needs to be modified to build iproute-doc under binary-indep instead of binary-arch. (Filing it here so I don't forget it, because I don't think I'll be so lucky to stumble upon it again if I do.) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages iproute depends on: ii libc6 2.7-5 GNU C Library: Shared libraries ii libdb4.6 4.6.21-5 Berkeley v4.6 Database Libraries [ Versions of packages iproute recommends: ii libatm1 2.4.1-17.1 shared library for ATM (Asynchrono -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357172: just got word that my dotte-duad patch for iproute2 got included upstream.
tags 357172 + fixed-upstream thanks Stephen Hemminger just said he has applied the patch for support of dotted-quad netmasks in the upstream repo. This means we can hopefully close this bug in the next upstream release. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456918: Please apply patchseries for ifupdown in experimental
Package: ifupdown
Version: 0.7~alpha2
Severity: wishlist
Hello!
Here's a bunch of patches to improve ifupdown 0.7~alpha2 (the current version
in experimental).
This fixes some minor issues like typos, finilizes the transition away
from ifconfig/route, and (most importantly IMHO) reinstates the support for
using netmask in /etc/network/interfaces for backwards compatibility
purposes.
Description for each patch available in the top of the file...
(For additional backwards compatibility looking at #359618 might be
interesting, since people might have those old pesky ethX:Y virtual
interfaces in their /e/n/i which ifconfig required because it can't handle
adding several ip-adresses to the same interface.)
--
Regards,
Andreas Henriksson
From d374dc2554f92fcbdc27a05b0394844aed96f957 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson [EMAIL PROTECTED]
Date: Wed, 12 Dec 2007 20:26:23 +0100
Subject: [PATCH] Fix aadr typo
---
ifupdown.nw |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ifupdown.nw b/ifupdown.nw
index 075cecc..1c8e6c8 100644
--- a/ifupdown.nw
+++ b/ifupdown.nw
@@ -4154,7 +4154,7 @@ method loopback
This method may be used to define the IPv6 loopback interface.
up
ip link set dev %iface% up
-ip aadr add dev %iface% ::1
+ip addr add dev %iface% ::1
down
ip addr del dev %iface% ::1
ip link set dev %iface% down
--
debian.1.5.3.7.1-dirty
From b3f32a4456ebc734f164aec640c8110775cdcd26 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson [EMAIL PROTECTED]
Date: Wed, 12 Dec 2007 20:29:57 +0100
Subject: [PATCH] Add netmask option to inet static for backwards compability.
Add a note about it being *obsolete* to the help text.
Add a note to address help text about the posibility to specify netmask.
Also add a versioned dependency on iproute 20071016-1, which was the first
debian package version to support dotted-quad netmasks (which was
previously the required format in /etc/network/interfaces).
---
debian/control |2 +-
ifupdown.nw|5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/debian/control b/debian/control
index 9222ed3..95e80e4 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Build-Depends: debhelper (= 4.1.68), nowebm, po-debconf
Package: ifupdown
Architecture: any
-Depends: net-tools, iproute, debconf (= 1.2.0) | debconf-2.0, lsb-base, ${shlibs:Depends}
+Depends: net-tools, iproute (= 20071016-1), debconf (= 1.2.0) | debconf-2.0, lsb-base, ${shlibs:Depends}
Suggests: dhcp3-client | dhcp-client, ppp
Replaces: netbase ( 4.00)
Description: high level tools to configure network interfaces
diff --git a/ifupdown.nw b/ifupdown.nw
index 1c8e6c8..3611cd1 100644
--- a/ifupdown.nw
+++ b/ifupdown.nw
@@ -4001,7 +4001,8 @@ method static
allocated IPv4 addresses.
options
-address address -- Address (dotted quad) *required*
+address address -- Address (dotted quad/netmask) *required*
+netmask mask-- Netmask (dotted quad or CIDR) *obsolete*
broadcast broadcast_address -- Broadcast address (dotted quad)
metric metric -- Routing metric for default gateway (integer)
gateway address -- Default gateway (dotted quad)
@@ -4011,7 +4012,7 @@ method static
mtu size-- MTU size
up
-ip addr add %address% [[broadcast %broadcast%]] \
+ip addr add %address%[[/%netmask%]] [[broadcast %broadcast%]] \
[[peer %pointtopoint%]] dev %iface%
ip link set dev %iface% [[mtu %mtu%]] [[address %lladdress%]] up
--
debian.1.5.3.7.1-dirty
From 882d34d30981f86eb781e0d80287267f41edad7c Mon Sep 17 00:00:00 2001
From: Andreas Henriksson [EMAIL PROTECTED]
Date: Wed, 12 Dec 2007 21:05:17 +0100
Subject: [PATCH] Flush addresses when taking down a static inet interface.
Addresses won't be automagically removed when taking a link down via iproute2.
To not fail to add them next time ifup runs for this interface we flush all
adresses on the interface before taking down the link.
---
ifupdown.nw |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/ifupdown.nw b/ifupdown.nw
index 3611cd1..0e68f00 100644
--- a/ifupdown.nw
+++ b/ifupdown.nw
@@ -4019,6 +4019,7 @@ method static
[[ ip route add default via %gateway% [[metric %metric%]] dev %iface% ]]
down
+ip addr flush dev %iface%
[[ ip route del default via %gateway% [[metric %metric%]] dev %iface% ]]
ip link set dev %iface% down
@
--
debian.1.5.3.7.1-dirty
From ce4029bc1102a7f137c751abd6fe1912dd69f67f Mon Sep 17 00:00:00 2001
From: Andreas Henriksson [EMAIL PROTECTED]
Date: Wed, 12 Dec 2007 22:01:07 +0100
Subject: [PATCH] Replace remaining ifconfig parts with iproute2
inet dhcp:
- replace hwaddress class address with lladdress address
- switch from ifconfig to iproute2
inet6 static:
- drop support for setting media type
(old deprecated driver-dependent interface in ifconfig doesn't have
Bug#456918: Please apply patchseries for ifupdown in experimental
On ons, 2007-12-19 at 04:46 +1000, Anthony Towns wrote: That is so cheating!! :) Haha! You caught me in the act... but it was so easy I couldn't resist! A hook in a single place, and *boom*, full dotted-quad support all over iproute. :) -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414086: Regarding the become the new default bug.
Hello Matt! I was the person who closed the bug report (#414086) about iproute: become the new default. I did this because I see no value in it at all. I will try to elaborate on this further... First of all, I have no evidence that any improvements in iproute itself is needed for it to become the new default. The only thing that's needed is that people start to actually use it. You can do this yourself just by installing it! (If you *do* find something that needs improvement in iproute, please file a bug about *that* and we'll fix it.) If you also want to completely get rid of net-tools, then I suggest you start filing wishlist bug-reports against the packages that depends on net-tools if they don't already have those. To find these packages you simply run apt-cache rdepends net-tools. One of the main things you would want to get ported is probably ifupdown, and those who seek will find that in experimental there is a version who has been ported to use iproute instead of net-tools. There are several issues still remaining, not least keeping backwards compatability with the old syntax of /etc/network/interfaces. I've recently started to help out in improving this experimental version of ifupdown (see #456918 for my initial work) which is what I consider is the important part to get ported over (the rest of the packages can just pull in net-tools via it's dependencies, and hopefully they'll get ported over when enough people nag about why they must have both iproute and net-tools installed - where I'll just direct all those nags away from iproute). My goals is to have it included in time for Lenny, but I doubt that will happen so don't count on it! The remaining issues should be tracked as bugs against ifupdown though, not iproute! There are a couple of things that makes just switching from net-tools to iproute not that easy. First of all, iproute is a not portable to other platforms then Linux (since it uses netlink which is a kernel interface only available on Linux). Debian has non-linux architectures but none of them has ever been included in an official release AFAIK. I'll let you decide how important this is. Another thing is that iproute is not a superset of net-tools! When one thinks of net-tools you usually think of ifconfig and route. These two can and should be replaced by iproute commands, but there are several others: /usr/sbin/arp - no iproute equivalent AFAIK. /sbin/ifconfig - use ip link, ip addr, ... /sbin/nameif - use ip link set name foo dev bar or udev or whatever! /sbin/plipconfig - no idea. /sbin/rarp - no iproute equivalent AFAIK. /sbin/route - use ip route ... /sbin/slattach - no idea. /sbin/ipmaddr - probably can be replaced by iproute, no idea. /sbin/iptunnel - probably can be replaced by ip tunnel ... /sbin/mii-tool - use ethtool! /bin/netstat - why not keep using? (possible alternativ could be lsof) Basically, each transition needs to be looked into You can't just say switch to iproute!. And no, none of these missing parts are things that are planned for iproute - we don't replace stuff just for the fun of it all. There's no need to write a new netstat for example (although I personally more often tend to use lsof then netstat). Who knows, but maybe the useful parts of net-tools should be split out so they can be pulled in separately but at the same time it seems silly to split up a small package like net-tools. One might also want to investigate what busybox offers, maybe the missing parts can be provided have good enough equivalents in busybox. But again, I want to stress that none of these are iproute problems. If you want have this bug as keeping track of when iproute can be upgraded to important (and thus installed by default), I suggest you start adding blocker bugs to this because I won't. If there's no activity on the bug, there's no reason to keep it around and I *will* close it again (and I hope I've given enough explanation about it this time). Personally I think a big transition issue like this where you need to collect alot of ideas and plan stuff are better done on a wiki or similar. Once you've figured out what needs to be done you file small individual bug-reports against affected packages, and each of those small bugs getting fixed will bring you closer to the grand unified goal. Hope this helps, have a nice day! -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456918: one more patch for experimental ifupdown - restore hwaddress.
Hello again!
Here's an additional patch on top of the previous in the series. It
restores backwards compatability for the hwaddress option (and drops
the new lladdress option that was invented for the new syntax).
(this leaves only the media option for full backwards compatability
AFAIK, but I'm not going to care about that one since it was driver
specific and probably not widely used.)
More details in the top of the patch file. See attachment.
Please note that this patch only updates the noweb file, the generated
files needs to be updated after the patch is applied!
--
Regards,
Andreas Henriksson
commit d0d8fcd837a0ee817b2265bc9ba1c516d5c07190
Author: Andreas Henriksson [EMAIL PROTECTED]
Date: Wed Dec 19 20:24:46 2007 +0100
Restore hwaddress compatability (and drop newly invented lladdress).
The previous interfaces syntax was hwaddress class address since thats what
ifconfig used.
(class is one of ether, ax25, ARCnet or netrom.
address is dependent on the above choice.)
With iproute you only need to specify the address thus the new syntax
hwaddress address, so we need to strip off the class if we detect it has
been specified to keep backwards compatability.
This is implemented here, and we also supply two tests for new and old style
hwaddress syntax.
diff --git a/debian/remaketests.sh b/debian/remaketests.sh
index 8d27291..e54ad99 100755
--- a/debian/remaketests.sh
+++ b/debian/remaketests.sh
@@ -24,7 +24,7 @@ done
cat EOF
result=true
-for test in 1 2 3 4; do
+for test in 1 2 3 4 5 6; do
args=\$(cat tests/testcase.\$test | sed -n 's/^# RUN: //p')
./ifup -nv --force -i tests/testcase.\$test \$args \\
tests/up-res-out.\$test 2tests/up-res-err.\$test ||
diff --git a/debian/testbuild b/debian/testbuild
index 89910c7..b1f7ee4 100755
--- a/debian/testbuild
+++ b/debian/testbuild
@@ -145,8 +145,51 @@ echo hello
run-parts --verbose /etc/network/if-up.d
EOF
+cat tests/testcase.5 EOF
+# RUN: -a
+# old style hwaddress including class
+auto eth0
+iface eth0 inet static
+ address 1.2.3.4
+ netmask 24
+ hwaddress ether 00:DE:AD:00:BE:AF
+EOF
+cat tests/up.5 EOF
+stdout
+stderr
+Configuring interface eth0=eth0 (inet)
+run-parts --verbose /etc/network/if-pre-up.d
+ip addr add 1.2.3.4/24 dev eth0
+ip link set dev eth0 address 00:DE:AD:00:BE:AF up
+
+run-parts --verbose /etc/network/if-up.d
+EOF
+
+cat tests/testcase.6 EOF
+# RUN: -a
+# new style hwaddress without class
+auto eth0
+iface eth0 inet static
+ address 1.2.3.4
+ netmask 24
+ hwaddress 00:DE:AD:00:BE:AF
+EOF
+
+cat tests/up.6 EOF
+stdout
+stderr
+Configuring interface eth0=eth0 (inet)
+run-parts --verbose /etc/network/if-pre-up.d
+ip addr add 1.2.3.4/24 dev eth0
+ip link set dev eth0 address 00:DE:AD:00:BE:AF up
+
+run-parts --verbose /etc/network/if-up.d
+EOF
+
+
+
result=true
-for test in 1 2 3 4; do
+for test in 1 2 3 4 5 6; do
args=$(cat tests/testcase.$test | sed -n 's/^# RUN: //p')
./ifup -nv --force -i tests/testcase.$test $args \
tests/up-res-out.$test 2tests/up-res-err.$test ||
diff --git a/ifupdown.nw b/ifupdown.nw
index 96e69cc..048c10e 100644
--- a/ifupdown.nw
+++ b/ifupdown.nw
@@ -1846,6 +1846,7 @@ with.
process iface option line=
convert [[post-up]] and [[pre-down]] aliases to [[up]] and [[down]]
check for duplicate options
+fix old interfaces syntax for backwards compabitibility
add option
@
@@ -1878,6 +1879,31 @@ if (strcmp(firstword, pre-down) == 0) {
}
}
}
+@
+
+fix old interfaces syntax for backwards compabitibility=
+{
+ if (strcmp(firstword, hwaddress) == 0)
+ {
+ char *space = strchr(rest, ' ');
+
+ if (space != NULL) {
+ *space = '\0';
+ if (strcasecmp(rest, ether) == 0 ||
+strcasecmp(rest, ax25) == 0 ||
+strcasecmp(rest, ARCnet) == 0 ||
+strcasecmp(rest, netrom) == 0)
+ {
+/* found deprecated class attribute */
+memmove(rest, space+1, strlen(space+1)+1);
+ }
+ else
+ {
+*space = ' ';
+ }
+ }
+ }
+}
@
Given the previous definition of [[add_variable()]] adding an option
@@ -4008,13 +4034,13 @@ method static
gateway address -- Default gateway (dotted quad)
pointopoint address -- Address of other end point (dotted quad). \
Note the spelling of point-to.
-lladdress address -- Link local address. (Replaces hwaddress)
+hwaddress address -- Hardware address.
mtu size-- MTU size
up
ip addr add %address%[[/%netmask%]] [[broadcast %broadcast%]] \
[[peer %pointtopoint%]] dev %iface%
-ip link set dev %iface% [[mtu %mtu%]] [[address %lladdress%]] up
+ip link set dev %iface% [[mtu %mtu%]] [[address %hwaddress%]] up
[[ ip route add default via %gateway% [[metric %metric%]] dev %iface% ]]
@@ -4052,10 +4078,10 @@ method dhcp
leasetime leasetime -- Preferred lease time in seconds (dhcpcd
Bug#414086: please describe what prevents iproute from being used.
On ons, 2007-12-19 at 11:00 -0800, Matt Taggart wrote: The only problem I know if with iproute is that it is Priority: optional. This is not really a problem, we'll make it Priority: important as soon as ifupdown is ready to move over. Having bugs open in the BTS for a long time is not a personal reflection on the maintainer of the package or the quality of the package. Nor was it my intent to demand that you personally drive any sort of transition. The BTS is a tool used to make debian better. Now maybe it suffers from if you have a hammer everything looks like a nail problem... I agree and I'm definitely taking bug reports as a personall offence, but at the same time it's cluttering up the bug page distracting attention away from the real bugs. I guess this is what you are saying by the hammer quote (sorry, I'm not a native english speaker so my understanding is limited). Do you agree that debian should move to iproute as the default way of configuring networking? If so, how would you like to track that transition? I fully agree, and that's why I'm actively working on it. My preference on how to do it is to identify the actual problems and report them individually against the package where they exist (hopefully including a patch if possible). Meta-bugreports like We should improve Debian doesn't really help much on the way here. You'll probably be happy to know that I've just sent another patch to #456918, which restores backwards compatability for the hwaddress option in /etc/network/interfaces. Now the only backwards-incompatible change is that the media option is removed (which means it will be ignored), but writing about this in the package NEWS file is probably more then enough to consider that solved. A big remaining issue for ifupdown is still the problem on how to support non-linux architectures (where iproute isn't available). This is not something I'm interested in working on, and I hope it won't stop ifupdown from moving the experimental version into unstable (and soon testing after that). After the patch series I've sent is applied ifupdown is IMHO ready, not taking the non-linux architectures into consideration, for mainstream testing. Hopefully I can steal a bit of time from Anthony Towns soon and discuss with him what possible issues still remains before he thinks ifupdown 0.7 is ready for unstable. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451098: still interested in maintaining gnome-launch-box in debian?
Hello Julien! I noticed you have uploaded 0.4 to ubuntu, but debian is still stuck at 0.2. Do you intend to work on this package in debian? I'll happily take it over if you don't want to. (Please properly orphan or put out an request for adoption for any package you don't want to work on anymore in debian.) -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451098: still interested in maintaining gnome-launch-box in debian?
Hi! On Thu, Dec 20, 2007 at 03:26:04PM +0100, Julien Lavergne wrote: update seems to break the binding for my sponsors. If you want to test the new package, you can find it here : http://mentors.debian.net/debian/pool/main/g/gnome-launch-box/ This is the version I've been running for a long time. Works great for me. I guess you didn't see my mail asking about why this version hasn't been sponsored? If your sponsor has found a problem with the package then it would be wise to try to solve that, as we don't want to upload a know-broken version. If you need help tracking the problem down, please try to post information about it somewhere (usually you shouldn't open a bug about stuff not in debian in the BTS, but I guess why not make an exception this time?). Feel free to contact me if you need sponsorship in the future and your regular sponsor is too busy or similar. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404956: ip rule flush semantics changed...
tag 404956 + moreinfo unreproducible thanks Hello! I'm having a look at an old iproute bug, http://bugs.debian.org/404956, where you have reported that the semantics of ip rule flush changed. The bug was filed against version 20061002-3 and I've tried to see how it acted in previous versions. I've now tried all of these old upstream releases: iproute2-2.6.11-050310.tar.gz iproute2-2.6.14-051107.tar.gz iproute2-2.6.11-050314.tar.gz iproute2-2.6.15-060110.tar.gz iproute2-2.6.11-050330.tar.gz iproute2-2.6.16-060323.tar.gz ... and for me they all work the same as the current version when it comes to ip rule flush, meaning they delete every rule they can when flushing (which is what I would expect of a flush command). This leaves only the one rule that can not be deleted: 0: from all lookup local There seems to be two possible problems mentioned in the bugreport: - change in what a command does between iproute versions - command does something else then expected. The first one would clearly not be very nice, but as I've tried several of the previous versions and can't see any change in what happens I need more info to reproduce that problem - for now I'll have to treat it as if you can't see it, it's not there. The second problem might be a bit more fuzzy, and should probably be discussed more - since it might just as well be a misunderstanding of the command rather then a bug. The ip manpage contains description of what the default rules are, and it also mentions that the 0 rule is special and can't be deleted. This is not stated for the other two default rules, so if you want to use ip rule flush to restore the defaults you should also add back these two other rules. Flush doesn't mean restore defaults for any ip commands as far as I know. It means delete everything. Flush should, if used at all, always be used very carefully. Could you please provide some more insight into this bugreport? -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394780: [RFC] old stuff - Kernel Bug Tracker Bug 7398
-- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435977: ifupdown openvpn patch.
Hello Mike! Was just looking at your patch for openvpn support in ifupdown and found a minor nitpick. Seems like you've made the vpn parameter optional by wrapping %vpn% in [[ ... ]]. I don't see how it would work if you don't give the vpn parameter. I guess you just want to remove the [[ and ]] so that it becomes a required field... -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448138: post-up vs. up in /etc/network/interfaces.
Hello Laurent! I'm looking at the bug you reported against ifupdown, http://bugs.debian.org/448138. I can't really comment on the underlying problem, but thought I might just chime in on one thing. As seeing the post-up hooks are run before ifenslave script, so I cannot do the arp trick as interface does not exists, and even if I force it deleted when interface come up. This is maybe a wanted thing but It does not seems intuitive to me. (/etc/network/if-up.d/ should maybe renamed /etc/network/if-post-up.d/ ?) Or I just miss something... While pre-up is it's own command, post-up is just an alias for up! I don't know if you can determine in which order the if-up.d scripts and the (post-)up commands are run. You seems to have found out that the scripts are run before the commands for you (but I don't know if this is something to rely on always happening). Maybe ifupdown should be modified to make the post-up it's own command where you can be sure it runs after the if-up.d scripts, so we have pre-up - configure - up (scripts) - post-up. That way you'll have reliable order and it would hopefully solve your problem. Just an idea For now you can probably work around your problem by sticking the commands in scripts in if-up.d and name them to be run after the other if-up.d scripts -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413428: ifupdown always modprobes ipv6 before bringing up inet6 interfaces in ubuntu.
Just wanted to send a note about this bug has already been solved in Ubuntu, by always modprobing ipv6 as the first command when bringing up an inet6 interface. See https://patches.ubuntu.com/i/ifupdown/ (They have also added an option to module-init-tools, -Q, to make it be totally silent.) IMHO it should be modprobing net-pf-10 instead. This way the protocol family 10 can carry an alias to the correct module - or none if you want to blacklist ipv6 for some reason. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#338348: Lets not hide the ifupdown patch for fixing udhcpc. ;)
Eric seems to have missed to CC the bug report when he sent in his
patch, making it only available if you choose full text of the message
to control which set the patch tag.
Anyway, to make it easy to access Erics patch I've attached it to this
mail so it shows up in the actual bug report.
--
Regards,
Andreas Henriksson
--- ifupdown.nw.old 2005-11-13 00:21:11.0 +0100
+++ ifupdown.nw 2005-12-03 01:08:27.0 +0100
@@ -3940,7 +3940,7 @@
elsif (execable(/sbin/dhclient))
pump -i %iface% -r \
elsif (execable(/sbin/pump) mylinuxver() = mylinux(2,1,100))
-cat /var/run/udhcpc.%iface%.pid | xargs -i kill -TERM {} \
+kill -USR2 `cat /var/run/udhcpc.%iface%.pid`;kill -TERM `cat /var/run/udhcpc.%iface%.pid` \
elsif (execable(/sbin/udhcpc))
dhcpcd -k %iface% \
elsif (execable(/sbin/dhcpcd))
Bug#255222: Add .pid to wvdial pidfiles.
tag 255222 + patch thanks Attached a trivial and completely untested patch for the change Thomas Hood suggested (mainly so I can tag the bug patch to make it shows up as having a suggested solution already). This patch is against the ifupdown.nw file in ifupdown 0.7~alpha3 (experimental). A friendly reminder: don't forget to update the generated files by running noweb ifupdown.nw after applying it! -- Regards, Andreas Henriksson --- ifupdown-0.7~alpha3/ifupdown.nw.orig 2007-12-26 22:58:40.0 +0100 +++ ifupdown-0.7~alpha3/ifupdown.nw 2007-12-26 22:59:00.0 +0100 @@ -4201,10 +4201,10 @@ provider name -- Use /name/ as the provider (from /etc/ppp/peers). up /sbin/start-stop-daemon --start -x /usr/bin/wvdial \ - -p /var/run/wvdial.%iface% -b -m -- [[ %provider% ]] + -p /var/run/wvdial.%iface%.pid -b -m -- [[ %provider% ]] down /sbin/start-stop-daemon --stop -x /usr/bin/wvdial \ - -p /var/run/wvdial.%iface% -s 2 + -p /var/run/wvdial.%iface%.pid -s 2 @
Bug#296115: porting ifupdown to non-linux...
retitle 296115 ifupdown: port to non-linux platforms (kfreebsd / hurd) found 296115 0.7~alpha3 thanks Hello Michael! I just ran into bug #296115 where you supplied a patch for ifupdown on non-linux platforms a long time ago. Is there any chance you are still interested in working on this? Version 0.7 of ifupdown, available in experimental, has been ported to use iproute2 commands on linux. Since iproute2 is a linux-specific tool (by using rtnetlink to communicating with the kernel), other architectures now really needs to provide their own .defn files in ifupdown to work. (These are the files that contains the commands needed for each /etc/network/interfaces action.) This is one of the last remaining issues for the experimental version of ifupdown before it can enter unstable as far as I know. It would be great if you where willing to work on this and I would be happy to assist with what little ifupdown knowledge I have to help along the way! -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306224: Possibility of hitting two birds with one stone?
While looking at #306224 it hit me that possibly the patch in #389996 would maybe also solve this problem? Just thought I'd mention it... -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319234: Scripts in /etc/network/if-post-up.d/ are not executed
The reason that directory doesn't exist (and scripts put in there doesn't get executed) is because post-up is simply an alias for up. Internally post-up gets translated/rewritten to up (and pre-down to down IIRC). Maybe a symlink named if-post-up.d could be shipped pointing to if-up.d to make this more obvious (but on the other hand, introducing new compatibility symlinks might need a better reason then this). -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#316411: merge 253472 and 316411?
This bug might be because of the same issue as reported in bug #253472. The details are discussed in this followup message to that bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=253472#10 -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303161: No need to delete net.enable anymore - close #303161.
I've discussed the problem reported in bug #303161 with Marco d'Itri and it seems to be gone along with the hotplug package which doesn't exist anymore. This bug can be closed now. On tor, 2007-12-27 at 00:49 +0100, Marco d'Itri wrote: On Dec 27, Andreas Henriksson [EMAIL PROTECTED] wrote: I've been happily ignoring the whole history behind hotplug/udev/whatever up until now To me it looks like /etc/init.d/hotplug-net is gone and nothing is creating the net.enable file anymore, but maybe it has moved to another This is correct, indeed. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#251559: Does ifupdown 0.7 fix your problem?
fixed 251559 0.7~alpha3 thanks On ons, 2007-12-26 at 19:24 -0500, Josh Carroll wrote: Unfortunately, I no longer run Debian on that machine, so I am unable to test. Sorry! According to my testing with ifupdown 0.7~alpha3 this problem is fixed. (Unless you explicitly specifies one, iproute2 doesn't set a broadcast address and lets the kernel figure it out itself - which it does perfectly.) -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408453: v4tunnel mtu settings workaround + patch.
tag 408453 + patch thanks The v4tunnel method in ifupdown doesn't have a mtu option (see man interfaces). All non-existant options are ignored. If you want to set the mtu on your tunnel, a possible solution would be to use the up option and issue a ip link set device mtu size. I've attached a (trivial but completely untested) patch against ifupdown 0.7~alpha3 (plus the patch in #255222 which shouldn't cause problems except a warning for a bit of offset) which adds an mtu option in v4tunnel. Friently reminder for anyone who apply the patch: don't forget to update the autogenerated files by running noweb ifupdown.nw after applying it. -- Regards, Andreas Henriksson commit 2c32acb04bcca1e0393e3375f189409aca2063d4 Author: Andreas Henriksson [EMAIL PROTECTED] Date: Thu Dec 27 16:49:44 2007 +0100 Add mtu option to v4tunnel (Closes: #408453) diff --git a/ifupdown.nw b/ifupdown.nw index e6d9280..cc96c06 100644 --- a/ifupdown.nw +++ b/ifupdown.nw @@ -4283,11 +4283,12 @@ method v4tunnel dotted quad) gateway address -- Default gateway (colon delimited) ttl time -- TTL setting +mtu size -- MTU setting up ip tunnel add %iface% mode sit remote %endpoint% [[local %local%]] \ [[ttl %ttl%]] -ip link set %iface% up +ip link set %iface% up [[mtu %mtu%]] [[ ip addr add %address%/%netmask% dev %iface% ]] [[ ip route add %gateway% dev %iface% ]] [[ ip route add ::/0 via %gateway% dev %iface% ]]
Bug#440319: Your bug on ifupdown about media option and mii-tool.
fixed 440319 0.7~alpha3 thanks To not get to much offtopic here, the original bug report was about media option. The documentation clearly states that media option is a driver dependent setting, this is inherited from net-tools ifconfig. Since you didn't provide any output I can only assume the ifconfig command returns an error when trying to use the media option, and ifupdown always bails out when something fails. This would explain why the route command never runs to add your gateway. A new driver like tg3 most likely does not support this driver-dependent interface at all (you would probably need to use an old ISA cards and ancient drivers for those for this option to be supported) I'm marking this as fixed in 0.7~alpha3 where media is removed entirely and won't be causing problems like this. If you have problems with mii-tool, you wouldn't be the first one and I encurage you to file bugs against it. With ethtool I think you'll have to dig deeper into the documentation to find out how it works. If you believe you have found a bug feel free to report it against ethtool. (This includes the Priority if you feel it's currently wrong.) -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448138: same problem in both bugs.
The problem reported in #346459 is the same or atleast similar to the one in #448138. Both have their own suggested solution -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#149897: The bug you reported about ip route ... equalize ...
retitle 149897 documentation: no need to patch kernel for equalize. tag 149897 = severity wishlist thanks Hello Andras! Thank you very much for getting back to me on this! On lör, 2007-12-29 at 12:41 +0100, Andras Korn wrote: On Tue, Dec 25, 2007 at 02:08:16AM +0100, Andreas Henriksson wrote: I tried to reproduce the problem but when I tried to add a route with equalize I got Invalid argument. The ip manpage told me equalize only works if the kernel is patched. What kernel version is that? I can add this route to a vanilla kernel (OK, it has the vserver patch but that doesn't really touch multipath routing). I guess I must have done something else wrong. I tested this on Debian Unstable with the regular packaged linux 2.6.22-3-amd64, but if I follow the example you gave below it works for me too. [...] If I then ifconfig dummy0 up again, the dead half of the route comes back. So I'd say this works as expected now. [...] Very good to hear this has resolved itself. The only thing that remains is the false statement in the documentation about having to patch the kernel. Lets treat this report as a bug against the documentation from now on. I'll try to dig some and see if I can find it which kernel version the support first appeared. -- Regards, Andreas Henriksson
Bug#149897: The bug you reported about ip route ... equalize ...
retitle 149897 equalize kernel patch not available for current kernels? thanks On lör, 2007-12-29 at 13:22 +0100, Andreas Henriksson wrote: Very good to hear this has resolved itself. The only thing that remains is the false statement in the documentation about having to patch the kernel. Lets treat this report as a bug against the documentation from now on. I'll try to dig some and see if I can find it which kernel version the support first appeared. It seems like the required patch[1] which implements the feature is only available for 2.4.18. As far as I can tell it only /looks/ like it works with current kernels, because the kernel has the RTM_F_EQUALIZE flag (but no actual implementation). The flag has been there since atleast 2.4.0. man 7 rtnetlink says: RTM_F_EQUALIZE a multicast equalizer (not yet implemented) grepping linux 2.6.22 source for RTM_F_EQUALIZE only gets a single hit, the definition. It's not actually used anywhere. ./include/linux/rtnetlink.h:#define RTM_F_EQUALIZE 0x400 /* Multipath equalizer: NI */ (I guess NI in the comment means Not Implemented.) I haven't found out why the patch hasn't been merged, but I did find some discussion[2] between Guus Sliepen (original patch author?) and Patrick McHardy which seems to mention some of the problems in it. One of those might be the reason it never got merged in mainline. So. Updating the documentation to state the fact that the required kernel patch doesn't exist (for kernels supported by Debian) doesn't seem very useful. Possibly the support for equalize in iproute should be dropped completely since it's never been part of any official kernel release, and since it hasn't been solved in all these years noone will probably ever implement this. I'll ask upstream [1] http://www.trash.net/~kaber/equalize/ [2] http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/1314.html -- Regards, Andreas Henriksson
Bug#458325: Typo fix, multicast equalize - multipath equalize
Package: manpages Version: 2.67-1 Severity: wishlist Tags: patch On sön, 2007-12-30 at 11:42 +0100, Andras Korn wrote: On Sat, Dec 29, 2007 at 03:15:08PM +0100, Andreas Henriksson wrote: man 7 rtnetlink says: RTM_F_EQUALIZE a multicast equalizer (not yet implemented) This at least should be multipath, not multicast. (See bug #149897 for original discussion...) Patch attached. -- Regards, Andreas Henriksson diff -uri manpages-2.67.orig/man7/rtnetlink.7 manpages-2.67/man7/rtnetlink.7 --- manpages-2.67.orig/man7/rtnetlink.7 2007-09-20 18:26:31.0 +0200 +++ manpages-2.67/man7/rtnetlink.7 2007-12-30 13:32:31.0 +0100 @@ -276,7 +276,7 @@ if the route changes, notify the user via rtnetlink T} RTM_F_CLONED:route is cloned from another route -RTM_F_EQUALIZE:a multicast equalizer (not yet implemented) +RTM_F_EQUALIZE:a multipath equalizer (not yet implemented) .TE .I rtm_table
Bug#458539: iproute2 syntax change in tc police?
Hello Patrick McHardy! We have recently updated iproute in debian and have reports about the new version breaking shorewall generated scripts. The original bug-report can be found at: http://bugs.debian.org/458539 Commands like tc filter add dev ppp0 parent : protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 4mbit burst 10k drop flowid :1 apparently no longer works. The flowid is not accepted anymore. Reverting commit 720a2e8d99... which you authored seems to fix this. http://git.kernel.org/?p=linux/kernel/git/shemminger/iproute2.git;a=commitdiff;h=720a2e8d990707749b2cafa77ab3cd2b8241ec47 I guess the flowid is invalid syntax, but that it just got ignored instead of caught before... Could you please have a look and tell me what you think about this? -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458539: iproute2 syntax change in tc police?
On ons, 2008-01-02 at 00:39 +0100, Andreas Henriksson wrote: [...] Commands like tc filter add dev ppp0 parent : protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 4mbit burst 10k drop flowid :1 apparently no longer works. The flowid is not accepted anymore. Reverting commit 720a2e8d99... which you authored seems to fix this. [...] After further investigation it seems clear to me that reverting the commit 720a2e8d990707749b2... is the correct thing to do, since the real fix for the problem this commit was supposed to fix was instead fixed in commit c29391c7c68f031e246c... Whatever you specify after a u32 police you will now get a syntax error, and according to tc filter add u32 help there are several things that you are supposed to be able to specify after a police. So, Steven, please revert 720a2e8d990707749b2... -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462979: openvpn: [INTL:sv] Please update swedish translation
Package: openvpn Version: 2.1~rc4-2 Severity: wishlist Tags: patch l10n Attached patch updates the sv.po file sent out by the debian-l10n-enlish team after their review of the template file. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages openvpn depends on: ii debconf [debconf-2.0] 1.5.18 Debian configuration management sy ii libc6 2.7-6 GNU C Library: Shared libraries ii liblzo2-2 2.02-3 data compression library ii libpam0g 0.99.7.1-5 Pluggable Authentication Modules l ii libssl0.9.8 0.9.8g-4 SSL shared libraries openvpn recommends no packages. -- debconf information excluded --- /home/gem/Desktop/sv.po 2008-01-28 19:08:47.0 +0100 +++ /home/gem/Desktop/openvpn-sv.po 2008-01-28 19:10:06.0 +0100 @@ -15,9 +15,9 @@ Project-Id-Version: openvpn 2.0.2-1\n Report-Msgid-Bugs-To: [EMAIL PROTECTED] POT-Creation-Date: 2008-01-26 17:45+0100\n -PO-Revision-Date: 2007-01-21 22:00+0100\n +PO-Revision-Date: 2008-01-28 19:08+0100\n Last-Translator: Andreas Henriksson [EMAIL PROTECTED]\n -Language-Team: Swedish [EMAIL PROTECTED]\n +Language-Team: Swedish [EMAIL PROTECTED]\n MIME-Version: 1.0\n Content-Type: text/plain; charset=iso-8859-1\n Content-Transfer-Encoding: 8bit\n @@ -35,18 +35,8 @@ #. Description #. NOT REVIEWED, obsolete #: ../templates:2001 -msgid -Previous versions of openvpn started at the same time as most of other -services. This means that most of these services couldn't use openvpn since -it may have been unavailable when they started. Newer versions of the -openvpn package will start earlier. (i.e. a S16openvpn link in rc[235].d -instead of a S20openvpn) -msgstr -Tidigare versioner av OpenVPN startade samtidigt som många andra tjänster. -Detta betyder att många av dessa tjänster inte kunde använda sig av OpenVPN -eftersom den inte var tillgänglig när de startade. Senare versioner av -OpenVPN startar tidigare. (Dvs, en S18openvpn länk i rc[235].d istället för -en S20openvpn) +msgid Previous versions of openvpn started at the same time as most of other services. This means that most of these services couldn't use openvpn since it may have been unavailable when they started. Newer versions of the openvpn package will start earlier. (i.e. a S16openvpn link in rc[235].d instead of a S20openvpn) +msgstr Tidigare versioner av OpenVPN startade samtidigt som många andra tjänster. Detta betyder att många av dessa tjänster inte kunde använda sig av OpenVPN eftersom den inte var tillgänglig när de startade. Senare versioner av OpenVPN startar tidigare. (Dvs, en S18openvpn länk i rc[235].d istället för en S20openvpn) #. Type: boolean #. Description @@ -54,75 +44,57 @@ #. Type: boolean #. Description #. NOT REVIEWED, obsolete -#: ../templates:2001 ../templates:6001 -msgid -If you accept here, the package upgrade will make this change for you. If -you refuse, nothing will change, and openvpn will be working just like it -did before. -msgstr -Om du accepterar här kommer paketuppgraderingen att skapa denna åt dig. Om -du vägrar kommer ingenting att göras och OpenVPN kommer att fungerar precis -som den gjorde tidigare. +#: ../templates:2001 +#: ../templates:6001 +msgid If you accept here, the package upgrade will make this change for you. If you refuse, nothing will change, and openvpn will be working just like it did before. +msgstr Om du accepterar här kommer paketuppgraderingen att skapa denna åt dig. Om du vägrar kommer ingenting att göras och OpenVPN kommer att fungerar precis som den gjorde tidigare. #. Type: boolean #. Description #: ../templates:3001 msgid Create the TUN/TAP device? -msgstr +msgstr Skapa TUN/TAP-gränssnittet? #. Type: boolean #. Description #: ../templates:3001 -msgid -If you choose this option, the /dev/net/tun device needed by OpenVPN will be -created. -msgstr +msgid If you choose this option, the /dev/net/tun device needed by OpenVPN will be created. +msgstr Om du väljer detta alternativ kommer specialfilen /dev/net/tun som behövs av OpenVPN att skapas. #. Type: boolean #. Description #: ../templates:3001 msgid You should not choose this option if you're using devfs. -msgstr +msgstr Du skall ej välja detta alternativ om du använder devfs. #. Type: boolean #. Description #: ../templates:4001 msgid Stop OpenVPN when upgraded? -msgstr +msgstr Stoppa OpenVPN vid uppgradering? #. Type: boolean #. Description #: ../templates:4001 -msgid -The upgrade process stops the running daemon before installing the new -version. If you are installing or upgrading the system remotely, that could -break the upgrade
Bug#463218: ifupdown: 0.7 - please add versioned dependency on iproute.
Package: ifupdown Version: 0.7~alpha3 Severity: wishlist Hello! iproute 20080108-1, which is now available in both testing and unstable, has both support for dotted-quad netmasks (which I unfortunately broke in 20071016-3) and has also been bumped to severity important. Since ifupdown is important and policy says packages shouldn't depend on other packages with lower priority, plus the need for dotted-quad netmasks support for backwards compatability with peoples /etc/network/interfaces (which in ifupdown = 0.6 *required* dotted-quad) please add a versioned dependency on iproute = 20080108-1 for the 0.7 (experimental) version of ifupdown. Thanks. (With this minor nitpick fixed, I think it would be nice to see 0.7 get pushed towards unstable.) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ifupdown depends on: ii debconf [debconf-2.0] 1.5.18 Debian configuration management sy ii iproute 20080108-1 Professional tools to control the ii libc6 2.7-6 GNU C Library: Shared libraries ii lsb-base 3.1-24 Linux Standard Base 3.1 init scrip ii net-tools 1.60-19The NET-3 networking toolkit ifupdown recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445940: Regarding your bugreport against iproute
On lör, 2007-11-10 at 10:21 +0100, Dr. Markus Waldeck wrote: I upgraded from Linux dlh 2.6.22-2-686 to Linux dlh 2.6.22-3-686 #1 SMP Mon Oct 22 22:11:56 UTC 2007 i686 GNU/Linux and lnstat works without any problems! This is nice to hear. Although I don't understand the reason why that would fix the problem. Maybe we should still investigate this some more before closing the bug. I've downgraded to 2.6.22-2-amd64 (I run amd64) and still can't reproduce the problem. Unfortunately I haven't been able to figure out the problem by looking at the backtraces you sent either... (but I've been quite busy the last couple of weeks so I haven't spent much time looking at it.) Are there any chance I could have access to your system (when it's set up so the problem can be reproduced)? Being able to reproduce the problem myself would help me alot in trying to track down what's going on... -- Regards, Andreas Henriksson
Bug#445940: Regarding your bugreport against iproute
On lör, 2007-11-10 at 14:38 +0100, Dr. Markus Waldeck wrote: Unfortunately I deinstalled the kernel 2.6.22-2-686 from the partition in which the problem occured yesterday. I have still a rsynced backup of this partion. But if I boot the backup partition with the kernel 2.6.22-2-686 lnstat works fine. So I could not reproduce the problem at all :-(. I've asked the debian kernel maintainers and they also have no clue why any of the changes between -2 and -3 would be related in any way. I guess we'll have to leave this as a mystery... If someone can reproduce, we'll reopen the bug and investigate it again then. The information you provided will hopefully be of good value if the problem will need to be debugged in the future. Thanks for taking the time to reporting the bug and sending in further information about it along the way! Have a nice weekend! -- Regards, Andreas Henriksson
Bug#451098: New upstream version of gnome-launch-box available (v0.4).
Package: gnome-launch-box Version: 0.2 Severity: wishlist Hello! There seems to be a newer upstream version available for quite some time (even before you created the debian package of 0.2?!). I've created a watch file (attached) for the gnome-launch-box package which you can add as debian/watch to help you keep track of new upstream versions. What are the future plans for gnome-launch-box? Any plans for an updated package soon? :) -- Regards, Andreas Henriksson version=3 http://ftp.imendio.com/pub/imendio/gnome-launch-box/src/gnome-launch-box-(.*)\.tar\.gz
Bug#451098: New upstream version of gnome-launch-box available (v0.4).
On Tue, Nov 13, 2007 at 01:29:05PM +0100, Martin Michlmayr wrote: * Andreas Henriksson [EMAIL PROTECTED] [2007-11-13 11:29]: Package: gnome-launch-box There's no such package in Debian. What does dpkg -p gnome-launch-box | grep Maintainer: say? Since it's outdated I wasn't interested in installing it. I looked at http://packages.debian.org/gnome-launch-box and fetched the source on my sid installation by apt-get source gnome-launch-box. Has it been removed or added recently? http://packages.debian.org/sid/gnome-launch-box says the maintainer is: Maintainer: * Julien Lavergne mailto:[EMAIL PROTECTED] -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451162: libgnokii3-dev: trying to overwrite other packages files.
Package: libgnokii3-dev Version: 0.6.20-1 Severity: normal The new version of libgnokii3-dev fails to install for me... The following packages will be upgraded: libgnokii3-dev 1 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded. Need to get 378kB of archives. After unpacking 28.7kB will be used. Do you want to continue? [Y/n/?] Writing extended state information... Done Get:1 http://ftp.de.debian.org unstable/main libgnokii3-dev 0.6.21-1 [378kB] Fetched 378kB in 2s (155kB/s) Reading changelogs... Done (Reading database ... 154908 files and directories currently installed.) Preparing to replace libgnokii3-dev 0.6.20-1 (using .../libgnokii3-dev_0.6.21-1_amd64.deb) ... Unpacking replacement libgnokii3-dev ... dpkg: error processing /var/cache/apt/archives/libgnokii3-dev_0.6.21-1_amd64.deb (--unpack): trying to overwrite directory `/usr/lib/pkgconfig' in package librsvg2.0-cil with nondirectory dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libgnokii3-dev_0.6.21-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Reading task descriptions... Done Building tag database... Done -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libgnokii3-dev depends on: ii libbluetooth-dev [libbluetoot 3.20-1 Development files for using the Bl ii libgnokii30.6.21-1 Gnokii library ii libxpm-dev1:3.5.7-1 X11 pixmap library (development he libgnokii3-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451162: Patch for Bug#451162
tags 451162 + patch severity 451162 serious thanks Adding the attached file (10_fix_pkgconfig.dpatch) in debian/patches/ and adding 10_fix_pkgconfig to debian/patches/00list should resolve the issue. Fix is to make sure the pkgconfig directory exists before installing files to it. (Additionally a couple of trailing slashes are added, they don't hurt and work as safety-guards to make sure the file doesn't get installed in place of the directory if the directory is missing!) HTH. HAND. -- Regards, Andreas Henriksson 10_fix_pkgconfig.dpatch Description: application/shellscript
Bug#451227: bandwidthd: Preconfigure appears to be borked
tags 451227 + etch fixed 451227 2.0.1+cvs20050208-11 thanks On Wed, Nov 14, 2007 at 11:45:10AM +0200, Colin Alston [EMAIL PROTECTED] wrote: Preconfigure error on install: cp: cannot stat `/usr/share/doc/bandwidthd/bandwidthd.conf': No such file or directory Cosmetic, package installs ok after this error Known problem, unfortunately it was found to late into the freeze so the fix couldn't get in (as the severity of the problem wasn't high enough). Tagging it accordingly. IIRC, If you have the iproute package installed before installing bandwidthd you'll not hit this problem. (Which is why I missed it in the first place.) Workaround is thus to have iproute installed, which I can recommend for everybody even if you're not going to install bandwidthd. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451541: libgnokii3-dev: pkgconfig file gnokii.pc missing.
Package: libgnokii3-dev Version: 0.6.21-2 Severity: important Tags: patch Hi again! Thanks for uploading my last patch so fast, unfortunately I have sad news. The current package installs fine, but it's missing the gnokii.pc file which makes the -dev package kind of useless. The problem seems to be that install-includes in common/Makefile never gets called from anywhere, which is probably also the cause for the previous problem I submitted. Applying both patches sure doesn't hurt though, so I've made one more patch rather then updating the last one! Sorry for not having caugth this the first time around! :( Please see the attached patch, that makes the toplevel Makefiles install-includes trigger subdirectories install-includes and adds install-includes to includes/Makefile. Same as last time, add the attached 11_fix_installinc.dpatch in debian/patches/ and add 11_fix_installinc last in debian/patches/00list. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libgnokii3-dev depends on: ii libbluetooth-dev [libbluetoot 3.20-1 Development files for using the Bl ii libgnokii30.6.21-2 Gnokii library ii libxpm-dev1:3.5.7-1 X11 pixmap library (development he libgnokii3-dev recommends no packages. -- no debconf information 11_fix_installinc.dpatch Description: application/shellscript
Bug#451401: oops, sorry for duplicate bugreport.
forcemerge 451401 451541 thanks Sorry for opening a new bug about the gnokii.pc issue, when one was already reported. Anyway, now you have two solutions to chose from. (I ofcourse think mine is best, but since I fucked up last time you probably don't trust me anymore anyway... ;P) (fyi, I've built the latest upstream version of gnome-phone-manager against libgnokii3-dev with my patch attached to verify everything works fine with it.) -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452080: git-core: tries to overwrite other packages files (liberror-perl).
Package: git-core Version: 1:1.5.3.5-1 Severity: important Unpacking replacement git-core ... dpkg: error processing /var/cache/apt/archives/git-core_1%3a1.5.3.6-1_amd64.deb (--unpack): trying to overwrite `/usr/share/perl5/Error.pm', which is also in package liberror-perl Errors were encountered while processing: /var/cache/apt/archives/git-core_1%3a1.5.3.6-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: dpkg: dependency problems prevent configuration of git-email: git-email depends on git-core ( 1:1.5.3.6); however: Version of git-core on system is 1:1.5.3.5-1. dpkg: error processing git-email (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: git-email -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages git-core depends on: ii cpio2.9-6GNU cpio -- a program to manage ar ii libc6 2.6.1-6 GNU C Library: Shared libraries ii libcurl3-gnutls 7.17.1-1 Multi-protocol file transfer libra ii libdigest-sha1-perl 2.11-2 NIST SHA-1 message digest algorith ii liberror-perl 0.15-8 Perl module for error/exception ha ii libexpat1 1.95.8-4 XML parsing C library - runtime li ii perl-modules5.8.8-12 Core Perl modules ii zlib1g 1:1.2.3.3.dfsg-7 compression library - runtime Versions of packages git-core recommends: ii curl 7.17.1-1Get a file from an HTTP, HTTPS or ii git-doc 1:1.5.3.6-1 fast, scalable, distributed revisi ii less 409-1 Pager program similar to more ii openssh-client [ssh-client] 1:4.6p1-6 secure shell client, an rlogin/rsh ii patch2.5.9-4 Apply a diff file to an original ii rsync2.6.9-5 fast remote file copy program (lik -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452080: oh, fsck... duplicate bugreport.
forcemerge 452080 452078 thanks Sorry for the duplicate, as usual I'm unable to see the existing bugreport until *seconds* after I've reported a duplicate. Merging them -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452077: Also remove Error.pm in install-indep target.
tags 452080 + patch thanks The attached patch fixes the problems which seems to be caused by make install in the install-indep target in debian/rules installing the Error.pm module *again*, after it was removed when being installed in the install-arch target. (No idea why it ends up in debian/git-core/ when DESTDIR is set to debian/tmp/?!) Please carefully examine the patch to make sure it's actually correct. All I've done is to verify that it works for me. -- Regards, Andreas Henriksson diff -uri git-core-1.5.3.6/debian/rules git-core-1.5.3.6-fixed/debian/rules --- git-core-1.5.3.6/debian/rules 2007-11-20 18:59:29.0 + +++ git-core-1.5.3.6-fixed/debian/rules 2007-11-20 19:00:00.0 + @@ -120,6 +120,8 @@ install -d -m0755 '$(TMP)' DESTDIR='$(TMP)' $(MAKE) install install-doc \ CC='$(CC)' CFLAGS='$(CFLAGS)' $(OPTS) + rm -f '$(GIT)'-core/usr/share/perl5/Error.pm + rm -f '$(GIT)'-core/usr/share/man/man3/private-Error.3pm $(MAKE) -CDocumentation install-webdoc WEBDOC_DEST='$(TMP)'/html \ 2/dev/null # git-doc
Bug#357172: [PATCH] iproute2: support dotted-quad netmask notation.
Suggested patch for allowing netmask to be specified in dotted quad format.
See http://bugs.debian.org/357172
(Known problem: this will not prevent some invalid syntaxes,
ie. 255.0.255.0 will be treated as 255.255.255.0)
Comments? Suggestions? Improvements?
Signed-off-by: Andreas Henriksson [EMAIL PROTECTED]
diff --git a/lib/utils.c b/lib/utils.c
index 4c42dfd..277ab45 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -47,6 +47,25 @@ int get_integer(int *val, const char *arg, int base)
return 0;
}
+int get_netmask(unsigned *val, const char *arg, int base)
+{
+ inet_prefix addr;
+
+ if (!get_unsigned(val, arg, base))
+ return 0;
+
+ /* try coverting dotted quad to CIDR */
+ if (!get_addr_1(addr, arg, AF_INET)) {
+ u_int32_t mask;
+ *val=0;
+ for (mask = addr.data[0]; mask; mask = 1)
+ (*val)++;
+ return 0;
+ }
+
+ return -1;
+}
+
int get_unsigned(unsigned *val, const char *arg, int base)
{
unsigned long res;
@@ -304,7 +323,8 @@ int get_prefix_1(inet_prefix *dst, char *arg, int family)
dst-bitlen = 32;
}
if (slash) {
- if (get_unsigned(plen, slash+1, 0) || plen
dst-bitlen) {
+ if (get_netmask(plen, slash+1, 0)
+ || plen dst-bitlen) {
err = -1;
goto done;
}
--
Regards,
Andreas Henriksson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#199054: Summary of investigation of bugreport.
I'm going to sum up what I've discoverd during investigating this bugreport. Issue ifconfig and iproute2 (sometimes) shows different numbers for network statistics (like send and received packets/bytes/etc). Cause The statistics are stored as unsigned long in the kernel. Variables of type unsigned long are eigther 32 or 64bits large depending on architecture. This makes the problem only expose itself with a 64bit kernel (no matter if the userspace is 32 or 64 bits in this case). ifconfig gets it's statistics from /proc/net/dev where it's exposed as _text_. iproute2 gets it's statistics from a binary netlink interface. When exporting the statistics binary there's a problem between kernel/userspace about agreeing how large an unsigned long is, since you can run a 64bit kernel (where the unsigned long then would be 64bits) and a 32bit userland (where it would be 32 bits and would overflow). The kernel has an static-sized unsigned 32bits variable type called u32 to avoid these kind of problems. For some reason (like not bloating 32bit achitectures?) the u32 variable type was used in the netlink interface that iproute2 uses instead of an u64 which would have enough room on both types of architectures (but would be useless/wasteful on 32bit ones). This makes the number that iproute2 gets it's hands on to always have rolled over at 32bits even if the kernels unsigned long is 64 bits. Problem There really isn't a problem. Any program using these statistics needs to cope with rollovers, which will (eventually) happen for both 32bits and 64bits statistics. It's however unfortunate that ifconfig and iproute2 differ in the statistics which will be confusing for people not aware of the internals behind this. The numbers between ifconfig and iproute2 can't be compared (unless the ifconfig numbers are post-processed to rollover at 32bits as well). Solution(s) Even though this isn't really a bug and ifconfig is supposed to be deprecated since a long time on linux, it would preferably be handled anyway since ifconfig hasn't and (unfortunately) most likely will not go away in the near future to not cause the confusion for people comparing the ifconfig and iproute2 output. There are two ways of doing this, the easy way and the hard (proper?) way. The easy way is just to force the /proc/net/dev output to rollover at 32bits as well, even though it's not really necessary in itself. This way both methods would roll over at 32bits and the confusion wouldn't occur. Unfortunately changing even the smallest thing in /proc files has shown to cause breakage in userland code in the past and one could never really be sure what problems this change would have on all possible applications that might use /proc/net/dev. The hard way is to add a 64bit (u64) variant of the statistics to kernels netlink interface and add the abitily in iproute2 to use this if the kernel provides it instead of the old/current 32bits interface. Both of these methods depend on modifications in the kernel! Additionally, one could argue that the bug really is in the kernel and that it's a feature request / wishlish for iproute2 to support this non-yet-existing kernel function. Or that this is just as much a bug in ifconfig. Just because iproute2 and ifconfig states differently doesn't mean it's the fault of iproute2. If you would want to shift the blame towards ifconfig, you could use the fact that it could even be fixed in ifconfig without requiring kernel modification (but then there are probably many other programs that use the /proc/net/dev values and would require the same fix). Since I've already submitted[1] a patch for the simple solution to the (linux) netdev mailing list, and noone cared to comment or apply it. I guess they would prefer a nice backwards-compatible implementation of the hard solution, or probably even that this is such a small issue that it's not worth fixing. Possibly the /proc filesystem is going to be cleaned up one day in a distant future to remove all the cruft that is not process-related (and break all applications, like ifconfig, that depends on these deprecated methods of gathering kernel information). I'm suggesting documenting the behaviour (unless this bug report doesn't count as good enough documentation) and lowering the severity to wishlist. Most likely noone will care to fix this since there's so little to gain. [1]: See http://www.spinics.net/lists/netdev/msg35472.html or http://marc.info/?l=linux-netdevm=118415534518953 -- Regards, Andreas Henriksson signature.asc Description: This is a digitally signed message part
Bug#163021: More (negative) information about esqf.
This bug is apparently not getting fixed, since it's been open for a long time now with no action. I'm going to argue why it instead should be tagged wontfix (and possibly closed), to atleast dignify the bug reporter with an answer to his request. (But as I'm not the maintainer, I won't add the tag myself.) - The esqf is described as a verbatime copy of sqf which some hardcoded values exposed as configurable and some other modifications. The reason I've read was to not jeopardise the stability of the original sfq with changes. I'd say that if these changes now has been proven reliable the proper way of dealing with this would be to merge them into sfq, instead of merging the development version - esfq. Someone else seems to agree and there's recently been an effort to port some of esfq features (the useful ones which isn't supposed to be covered by a planned rewrite). See http://www.spinics.net/lists/netdev/msg37041.html (Posts to the netdev list on 29 Juli 2007 titled SFQ: backport some features from ESFQ (try 2)) - As far as I know there has been no effort to merge esfq in the upstream kernel and I'm guessing there will be no future attempts eigther. This will likely make the upstream iproute2 maintainer to refuse to merge the userspace part and the debian maintainers would have to manage the maintainance burden. I would say that the time spent on carrying and maintaining a patch in debian would be better spent on getting the features merged upstream into SFQ. -- Regards, Andreas Henriksson signature.asc Description: This is a digitally signed message part
Bug#163021: [Fwd: Mail delivery failed: returning message to sender]
The submitter doesn't seem to be reachable anymore eigther: [EMAIL PROTECTED] SMTP error from remote mail server after RCPT TO:[EMAIL PROTECTED]: host MX1.EMAILSRVR.COM [66.216.121.101]: 550 5.1.1 [EMAIL PROTECTED]: Recipient address rejected: User unknown in relay recipient table -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398912: Unable to reproduce iproute2 problem.
tags 398912 + moreinfo thanks Hi Michal Pokrywka. I'm currently doing some bug triaging on on the iproute package in Debian. I'm unable to reproduce the problem you reported last year on my Debian Unstable AMD64 installation nor on another Debian Stable i386 installation. Do you have the possibility to test if you can reproduce this still? In case you've forgot all about this, the instructions you provided is available at: http://bugs.debian.org/398912 I'm hoping that maybe the problem has been fixed since this was reported (or possibly that it was some other fault, like broken memory or something causing random weird problems). -- Regards, Andreas Henriksson signature.asc Description: This is a digitally signed message part
Bug#175462: Additional information, updated for current versions, different sizes for overflowing.
Hello! I'm doing some bug triaging on the iproute bugs in Debian. I've tried to reproduce the problem reported in bug#175462 on my Debian Etch (i386) and Debian Sid (AMD64) computers. The problem seem to persist, even though I got other numbers that triggered the overflows then what was reported in the original description of the problem. On Debian Etch i386: buffer 10240kb - burst 10Mb buffer 10241kb - burst 4086kb $ dpkg -l | grep iproute ii iproute 20061002-3 Professional tools to control the networking $ uname -r 2.6.18-4-amd64 $ sudo tc qdisc add dev rtl8139 parent root handle 2: tbf latency 10ms buffer 10240kb mpu 64 rate 40kbit $ sudo tc -s qdisc ls |grep 2: qdisc tbf 2: dev rtl8139 rate 4bit burst 10Mb lat 9.8ms $ sudo tc qdisc del dev rtl8139 $ sudo tc qdisc add dev rtl8139 parent root handle 2: tbf latency 10ms buffer 10241kb mpu 64 rate 40kbit $ sudo tc -s qdisc ls |grep 2: qdisc tbf 2: dev rtl8139 rate 4bit burst 4086Mb lat 2197.8s $ sudo tc qdisc del dev rtl8139 root On Debian Sid AMD64: Not reproducible. $ dpkg -l | grep iproute ii iproute 20070313-1 Professional tools to control the networking $ uname -r 2.6.22-1-amd64 $ sudo tc qdisc add dev nvif parent root handle 2: tbf latency 10ms buffer 10738kb mpu 64 rate 40kbit $ /sbin/tc -s qdisc ls | grep 2: qdisc tbf 2: dev nvif rate 4bit burst 10738Kb lat 10.0ms $ sudo tc qdisc del dev nvif root Using a 32bit/i386 Sid chroot on the same Sid AMD64: buffer 10kb - burst 10kb buffer 11kb - burst 4294956559b # dpkg -l | grep iproute ii iproute20070313-1 Professional tools to control the networking # uname -r 2.6.22-1-amd64 # tc qdisc add dev nvif parent root handle 2: tbf latency 10ms buffer 10kb mpu 64 rate 40kbit # tc -s qdisc ls | grep 2: qdisc tbf 2: dev nvif rate 4bit burst 10Kb lat 10.0ms # tc qdisc del dev nvif root # tc qdisc add dev nvif parent root handle 2: tbf latency 10ms buffer 11kb mpu 64 rate 40kbit # tc -s qdisc ls | grep 2: qdisc tbf 2: dev nvif rate 4bit burst 4294956559b lat 115.3ms # tc qdisc del dev nvif root I hope to look closer into this soon and hopefully find out why this happens... -- Regards, Andreas Henriksson signature.asc Description: This is a digitally signed message part
Bug#175462: Solved?
Hello again!
After much hunting... Can the solution be this trivial?
The attached patch replaces long with unsigned in a helper function.
(This patch is against the iproute version in sid, but the etch version
can be fixed the same way - except the functions are called
tc_core_usec2tick and tc_core_tick2usec instead of tick2time/time2tick.)
Please try the attached patch and see if it fixes the issue for you.
--
Regards,
Andreas Henriksson
diff -uri iproute-20070313.orig/tc/tc_core.c iproute-20070313/tc/tc_core.c
--- iproute-20070313.orig/tc/tc_core.c 2007-03-13 22:50:56.0 +0100
+++ iproute-20070313/tc/tc_core.c 2007-08-15 00:41:30.0 +0200
@@ -35,12 +35,12 @@
}
-long tc_core_time2tick(long time)
+unsigned tc_core_time2tick(unsigned time)
{
return time*tick_in_usec;
}
-long tc_core_tick2time(long tick)
+unsigned tc_core_tick2time(unsigned tick)
{
return tick/tick_in_usec;
}
diff -uri iproute-20070313.orig/tc/tc_core.h iproute-20070313/tc/tc_core.h
--- iproute-20070313.orig/tc/tc_core.h 2007-03-13 22:50:56.0 +0100
+++ iproute-20070313/tc/tc_core.h 2007-08-15 00:41:49.0 +0200
@@ -7,8 +7,8 @@
#define TIME_UNITS_PER_SEC 10
int tc_core_time2big(long time);
-long tc_core_time2tick(long time);
-long tc_core_tick2time(long tick);
+unsigned tc_core_time2tick(unsigned time);
+unsigned tc_core_tick2time(unsigned tick);
long tc_core_time2ktime(long time);
long tc_core_ktime2time(long ktime);
unsigned tc_calc_xmittime(unsigned rate, unsigned size);
Bug#398912: Unable to reproduce iproute2 problem.
tags 398912 - moreinfo
tags 398912 + patch
thanks
On ons, 2007-08-15 at 18:23 +0200, Michal Pokrywka wrote:
I just tested script attached to my bugreport and bug still exists.
I reproduced it on two different machines: PIII with Linux 2.6.18-4-686
and PIV with few xen domains with Linux 2.6.18-4-xen-686.
Hello again!
Thanks for testing and verifying the problem still exists.
With your hint I made some more efforts into reproducing it and managed
to do so on an older Pentium computer running Etch as well.
I've located the problem and created a patch that works for me. If you
could verify that it works for you as well that would be great.
The attached patch is against the Etch version of iproute, but seems to
apply against the Sid version as well (with some offset and fuzz, but
without failing).
Have a nice day!
--
Regards,
Andreas Henriksson
diff -urip iproute-20061002/include/utils.h iproute-20061002.fixed2/include/utils.h
--- iproute-20061002/include/utils.h 2006-10-02 22:13:34.0 +0200
+++ iproute-20061002.fixed2/include/utils.h 2007-08-16 00:51:58.0 +0200
@@ -132,7 +132,7 @@ int print_timestamp(FILE *fp);
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
extern int cmdlineno;
-extern size_t getcmdline(char **line, size_t *len, FILE *in);
+extern ssize_t getcmdline(char **line, size_t *len, FILE *in);
extern int makeargs(char *line, char *argv[], int maxargs);
#endif /* __UTILS_H__ */
diff -urip iproute-20061002/lib/utils.c iproute-20061002.fixed2/lib/utils.c
--- iproute-20061002/lib/utils.c 2006-10-02 22:13:34.0 +0200
+++ iproute-20061002.fixed2/lib/utils.c 2007-08-16 00:49:02.0 +0200
@@ -578,9 +578,9 @@ int print_timestamp(FILE *fp)
int cmdlineno;
/* Like glibc getline but handle continuation lines and comments */
-size_t getcmdline(char **linep, size_t *lenp, FILE *in)
+ssize_t getcmdline(char **linep, size_t *lenp, FILE *in)
{
- size_t cc;
+ ssize_t cc;
char *cp;
if ((cc = getline(linep, lenp, in)) 0)
@@ -608,9 +608,11 @@ size_t getcmdline(char **linep, size_t *
if (cp)
*cp = '\0';
- *linep = realloc(*linep, strlen(*linep) + strlen(line1) + 1);
+ *lenp = strlen(*linep) + strlen(line1) + 1;
+ *linep = realloc(*linep, *lenp);
if (!*linep) {
fprintf(stderr, Out of memory\n);
+ *lenp = 0;
return -1;
}
cc += cc1 - 2;
signature.asc
Description: This is a digitally signed message part
Bug#438463: libsdl1.2debian: new release available 1.2.12 (includes pulseaudio module)
Package: libsdl1.2debian Version: 1.2.11-9 Severity: wishlist There seems to be a new upstream version available, which among other things seems to add a module for PulseAudio that I'd like to try. If you could package this new version and add the PA module, that would be great! -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libsdl1.2debian depends on: ii libsdl1.2debian-alsa 1.2.11-9 Simple DirectMedia Layer (with X11 libsdl1.2debian recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437330: patch for TypeError in fretsonfire.
# Disclaimer: I know nothing about python. Never expect any python # changes I do to be correct. tags 437330 + patch thanks Hello David! I had the same problem as you reported about the FretsOnFire game in Debian crashing on startup. The changes in the attached patch made it work for me. (Now the biggest remaining problem is that I miss every note. ;P) HTH, HAND! -- Regards, Andreas Henriksson diff -uri ./game/DummyAmanith.py /tmp/fretsonfire/game/DummyAmanith.py --- ./game/DummyAmanith.py 2007-02-20 20:42:46.0 +0100 +++ /tmp/fretsonfire/game/DummyAmanith.py 2007-08-18 16:09:05.0 +0200 @@ -39,7 +39,9 @@ pass def SetViewport(self, x, y, w, h): -glViewport(x, y, w, h) +glw = int(w) +glh = int(h) +glViewport(x, y, GLsizei(glw), GLsizei(glh)) def SetProjection(self, left, right, bottom, top): glMatrixMode(GL_PROJECTION) diff -uri ./game/GameEngine.py /tmp/fretsonfire/game/GameEngine.py --- ./game/GameEngine.py 2007-04-07 10:11:34.0 +0200 +++ /tmp/fretsonfire/game/GameEngine.py 2007-08-18 16:18:03.0 +0200 @@ -165,7 +165,9 @@ geometry = (0, 0, w, h) self.svg = SvgContext(geometry) self.svg.setRenderingQuality(self.config.get(opengl, svgquality)) -glViewport(*viewport) +glw = int(viewport[2]) +glh = int(viewport[3]) +glViewport(int(viewport[0]), int(viewport[1]), GLsizei(glh), GLsizei(glh)) self.input = Input() self.view = View(self, geometry) diff -uri ./game/View.py /tmp/fretsonfire/game/View.py --- ./game/View.py 2007-03-18 15:01:53.0 +0100 +++ /tmp/fretsonfire/game/View.py 2007-08-18 16:20:33.0 +0200 @@ -136,10 +136,10 @@ viewport = glGetIntegerv(GL_VIEWPORT) if normalize: - w = viewport[2] - viewport[0] - h = viewport[3] - viewport[1] + w = int ( viewport[2] - viewport[0] ) + h = int ( viewport[3] - viewport[1] ) # aspect ratio correction - h *= (float(w) / float(h)) / (4.0 / 3.0) + h *= int((float(w) / float(h)) / (4.0 / 3.0)) viewport = [0, 0, 1, h / w] if yIsDown:
Bug#435678: Status of Cheese packaging?
Hello Franz! Just writing for a quick check of the status of the intended Cheese package in Debian. Any progress? Ubuntu seems to have packages available[0], maybe they could be used or atleast be a useful base for your packages... [0]: http://packages.ubuntu.com/cheese -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438994: iproute: manpage cleanups, add manpages for rtacct, arpd.
Package: iproute Severity: wishlist Tags: patch I've put together a couple of manpages for some commands in the iproute package based on the sgml docs. (arpd and rtacct) I've unfortunately not received any reply to my request of getting these added upstream, so that's why I'm asking for inclusion in the debian package. First off, the current manpages in debian/man/* seems to be available already in the upstream source so please remove these duplicates. Then please add the two attached manpages to debian/man/. Lastly, the rtstat(8), ctstat(8) could be linked to the lnstat(8) manpage, as those two commands are just compability symlinks for lnstat. The nstat(8) could also be symlinked to rtacct(8) manpage provided here. (Unfortunately I don't have a patch to create these symlinks for you, and symlinks can't be represented in a diff so it needs to be scripted somewhere.) -- Regards, Andreas Henriksson .TH ARPD 8 28 June, 2007 .SH NAME arpd \- userspace arp daemon. .SH SYNOPSIS Usage: arpd [ -lk ] [ -a N ] [ -b dbase ] [ -f file ] [ interfaces ] .SH DESCRIPTION The .B arpd daemon collects gratuitous ARP information, saving it on local disk and feeding it to kernel on demand to avoid redundant broadcasting due to limited size of kernel ARP cache. .SH OPTIONS .TP -h -? Print help .TP -l Dump arpd database to stdout and exit. Output consists of three columns: interface index, IP address and MAC address. Negative entries for dead hosts are also shown, in this case MAC address is replaced by word FAILED followed by colon and time when the fact that host is dead was proven the last time. .TP -f FILE Read and load arpd database from FILE in text format similar dumped by option -l. Exit after load, probably listing resulting database, if option -l is also given. If FILE is -, stdin is read to get ARP table. .TP -b DATABASE location of database file. Default location is /var/lib/arpd/arpd.db .TP -a NUMBER arpd not only passively listens ARP on wire, but also send brodcast queries itself. NUMBER is number of such queries to make before destination is considered as dead. When arpd is started as kernel helper (i.e. with app_solicit enabled in sysctl or even with option -k) without this option and still did not learn enough information, you can observe 1 second gaps in service. Not fatal, but not good. .TP -k Suppress sending broadcast queries by kernel. It takes sense together with option -a. .TP -n TIME Timeout of negative cache. When resolution fails arpd suppresses further attempts to resolve for this period. It makes sense only together with option -k This timeout should not be too much longer than boot time of a typical host not supporting gratuitous ARP. Default value is 60 seconds. .TP -r RATE Maximal steady rate of broadcasts sent by arpd in packets per second. Default value is 1. .TP -B NUMBER Number of broadcasts sent by tt/arpd/ back to back. Default value is 3. Together with option tt/-R/ this option allows to police broadcasting not to exceed B+R*T over any interval of time T. .P INTERFACE is the name of networking interface to watch. If no interfaces given, arpd monitors all the interfaces. In this case arpd does not adjust sysctl parameters, it is supposed user does this himself after arpd is started. .P Signals .br arpd exits gracefully syncing database and restoring adjusted sysctl parameters, when receives SIGINT or SIGTERM. SIGHUP syncs database to disk. SIGUSR1 sends some statistics to syslog. Effect of another signals is undefined, they may corrupt database and leave sysctl praameters in an unpredictable state. .P Note .br In order for arpd to be able to serve as ARP resolver, kernel must be compiled with the option CONFIG_ARPD and, in the case when interface list in not given on command line, variable app_solicit on interfaces of interest should be in /proc/sys/net/ipv4/neigh/*. If this is not made arpd still collects gratuitous ARP information in its database. .SH EXAMPLES .TP arpd -b /var/tmp/arpd.db Start arpd to collect gratuitous ARP, but not messing with kernel functionality. .TP killall arpd ; arpd -l -b /var/tmp/arpd.db Look at result after some time. .TP arpd -b /var/tmp/arpd.db -a 1 eth0 eth1 Enable kernel helper, leaving leading role to kernel. .TP arpd -b /var/tmp/arpd.db -a 3 -k eth0 eth1 Completely replace kernel resolution on interfaces eth0 and eth1. In this case kernel still does unicast probing to validate entries, but all the broadcast activity is suppressed and made under authority of arpd. .PP This is mode which arpd is supposed to work normally. It is not default just to prevent occasional enabling of too aggressive mode occasionally. .TH RTACCT 8 27 June, 2007 .SH NAME nstat, rtacct - network statistics tools. .SH SYNOPSIS Usage: nstat [ -h?vVzrnasd:t: ] [ PATTERN [ PATTERN ] ] .br Usage: rtacct [ -h?vVzrnasd:t: ] [ ListOfRealms ] .SH DESCRIPTION .B nstat and .B rtacct are simple tools to monitor kernel snmp counters and network
Bug#445780: Wrong color on winxp as well. Left mouse-button clicks not working.
I get the same yellow-instead-of-grey as the previously posted screenshot when I connect to Windows XP. Haven't yet run into a segfault, but left mouse-button clicks seems to be ignored (right works fine) so my hands are pretty tied by that. Everything worked fine in previous version. rdesktop outputs this to console while connecting: WARNING: Remote desktop does not support colour depth 24; falling back to 16 -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444457: upstream patch works for me.
Hello! I can reproduce the problem (in another way) on Debian unstable (amd64). I can also confirm that the patch[1] posted in the upstream bug report fixes the problem for me. [1]: https://bugs.freedesktop.org/attachment.cgi?id=11896 -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446274: less segfault when searching dvb scan output.
Package: less Version: 408-1 Severity: normal [EMAIL PROTECTED]:/tmp$ less /tmp/c.txt first screen of output /foobar Segmentation fault Rebuilt with DEB_BUILD_OPTIONS=noopt,nostrip,debug gdb gives me this backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00405cc2 in put_wchar (pp=0x7fff687f6ae0, ch=0) at charset.c:622 622 *(*pp)++ = (char) ch; (gdb) bt #0 0x00405cc2 in put_wchar (pp=0x7fff687f6ae0, ch=0) at charset.c:622 #1 0x00415af9 in cvt_text ( odst=0x62c550 Kanal Lokal G´, osrc=0x62c550 Kanal Lokal G´, lenp=0x7fff687f6b44, ops=6) at search.c:154 #2 0x00416ad7 in search_range (pos=5395, endpos=6372, search_type=17, matches=0, maxlines=-1, plinepos=0x0, pendpos=0x7fff687f6ba8) at search.c:1100 #3 0x0041716d in prep_hilite (spos=228, epos=6372, maxlines=-1) at search.c:1457 #4 0x0040dd2b in forw_line (curr_pos=228) at input.c:70 #5 0x00415d3d in repaint_hilite (on=0) at search.c:286 #6 0x00416e85 in search (search_type=1, pattern=0x627380 SVT, n=1) at search.c:1269 #7 0x00408fa5 in multi_search (pattern=0x627380 SVT, n=1) at command.c:800 #8 0x004083f3 in exec_mca () at command.c:196 #9 0x00408b35 in mca_char (c=10) at command.c:524 #10 0x00409169 in commands () at command.c:932 #11 0x00402144 in main (argc=-1, argv=0x7fff687f6f58) at main.c:286 (gdb) My /tmp/c.txt file attached. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (300, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23-rc9 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages less depends on: ii debianutils 2.25.1 Miscellaneous utilities specific t ii libc6 2.6.1-5GNU C Library: Shared libraries ii libncurses5 5.6+20071006-2 Shared libraries for terminal hand less recommends no packages. -- no debconf information Aftonbladet TV7:59400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:819:818:810 Aftonbladet TV7:77800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:819:818:810 Animal Planet:62600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:1089:1088:1080 Axess TV:59400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:809:808:800 Axess TV:77800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:809:808:800 BBC Prime:59400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:829:828:820 BBC Prime:77800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:829:828:820 BBC World:59400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:1179:1178:1170 BBC World:77800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:1179:1178:1170 Boxer Navigator:59400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:0:65534 Boxer Navigator:62600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:65534 Boxer Navigator:67400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:65534 Boxer Navigator:67400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:65534 Boxer Navigator:77800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:0:65534 Canal 7:67400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:1069:1068:1060 Canal 7:67400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:1069:1068:1060 C+ Film 1:67400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:919:918:910 C+ Film 1:67400:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:919:918:910 C+ Film 2 Sport
Bug#446274: new bug in less?
tags 446274 + patch
thanks
On tor, 2007-10-11 at 13:25 -0700, Mark Nudelman wrote:
On 10/11/2007 9:59 AM, Andreas Henriksson wrote:
I just reported a segfault in less to the Debian bug tracking system.
See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446274
When I search in less having the attached file open I get a segfault on
my Debian Unstable (less 408) AMD64 machine. I can not reproduce this on
My Debian Stable/Etch (less 394) i386 machine, so maybe it's a new
regression?
Hi Andreas,
This is indeed a new bug in less-408. I think the patch below fixes it.
If you want to try the patch, let me know if it works for you.
--Mark
Works for me! Thanks! :)
diff -c -r1.26 charset.c
*** charset.c 2007/09/28 14:48:33 1.26
--- charset.c 2007/10/11 20:23:32
***
*** 668,673
--- 668,674
char *limit;
{
LWCHAR ch;
+ int len;
char *p = *pp;
if (!utf_mode)
***
*** 679,692
ch = (LWCHAR) ((p limit) ? *--p : 0);
} else if (dir 0)
{
! if (p + utf_len(*p) limit)
ch = 0;
! else
{
ch = get_wchar(p);
! p++;
! while (IS_UTF8_TRAIL(*p))
! p++;
}
} else
{
--- 680,694
ch = (LWCHAR) ((p limit) ? *--p : 0);
} else if (dir 0)
{
! len = utf_len(*p);
! if (p + len limit)
! {
ch = 0;
! p = limit;
! } else
{
ch = get_wchar(p);
! p += len;
}
} else
{
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428442: [Fwd: Re: iproute2: resend of patches from Debian.]
Forwarded Message
From: Patrick McHardy [EMAIL PROTECTED]
To: Andreas Henriksson [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: iproute2: resend of patches from Debian.
Date: Thu, 11 Oct 2007 23:05:39 +0200
Andreas Henriksson wrote:
Add mpath to ip manpage.
From: Norbert Buchmuller [EMAIL PROTECTED]
The 'mpath' parameter of 'ip route' is not documented in the manual page
nor in ip-cref.tex.
...huge part of the text in the patch was taken from the net/ipv4/Kconfig
file in the Linux kernel source (2.6.18). I suppose that's OK because both
Linux and iproute2 are GPL'd, but I let you know anyway.
See Debian bug #428442 - http://bugs.debian.org/428442
diff -Naur iproute-20061002/doc/ip-cref.tex
iproute-20061002.fixed/doc/ip-cref.tex
--- iproute-20061002/doc/ip-cref.tex 2007-06-11 19:26:52.0 +0200
+++ iproute-20061002.fixed/doc/ip-cref.tex2007-06-11 20:34:09.0
+0200
@@ -1348,6 +1348,28 @@
route reflecting its relative bandwidth or quality.
\end{itemize}
+\item \verb|mpath MP_ALGO|
This has been removed from the kernel again because of complete
brokeness, so this patch shouldn't be merged.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407641: fixed upstream in 1.0.14-rc4
fixed 407641 1.0.14~rc4-1 thanks This bug seems to have been fixed upstream in v1.0.14-rc4. -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
