Merge branch 'master' of ssh://parabolagnulinux.org:1863/home/parabola/abslibre-pre-mips64el

Conflicts:
	community/cdemu-client/PKGBUILD
	community/dcron/PKGBUILD
	community/freevo/PKGBUILD
	community/gmerlin-avdecoder/PKGBUILD
	community/hacburn/PKGBUILD
	community/htmldoc/PKGBUILD
	community/ibus-table/PKGBUILD
	community/iksemel/PKGBUILD
	community/isomaster/PKGBUILD
	community/libmatio/PKGBUILD
	community/libtlen/PKGBUILD
	community/luarocks/PKGBUILD
	community/lxde-common/PKGBUILD
	community/multipath-tools/PKGBUILD
	community/nvclock/PKGBUILD
	community/pam-krb5/PKGBUILD
	community/pidgin-musictracker/PKGBUILD
	community/pkgfile/PKGBUILD
	community/pkgtools/PKGBUILD
	community/print-manager/PKGBUILD
	community/python-pyro/PKGBUILD
	community/python-pyxmpp/PKGBUILD
	community/python2-simplejson/PKGBUILD
	community/rsnapshot/PKGBUILD
	community/setconf/PKGBUILD
	community/tagpy/PKGBUILD
	community/terminator/PKGBUILD
	community/udunits/PKGBUILD
	community/vlock/PKGBUILD
	community/winefish/PKGBUILD
	core/nss-myhostname/PKGBUILD
	extra/avfs/PKGBUILD
	extra/bmp-musepack/PKGBUILD
	extra/bmp-wma/PKGBUILD
	extra/bochs/PKGBUILD
	extra/botan/PKGBUILD
	extra/cdargs/PKGBUILD
	extra/cx_freeze/PKGBUILD
	extra/dcfldd/PKGBUILD
	extra/devilspie/PKGBUILD
	extra/emelfm2/PKGBUILD
	extra/evilwm/PKGBUILD
	extra/fssos-nsvs/PKGBUILD
	extra/gimp-dbp/PKGBUILD
	extra/gimp-gap/PKGBUILD
	extra/gimp-ufraw/PKGBUILD
	extra/gmpc/PKGBUILD
	extra/gtkpod/PKGBUILD
	extra/hercules/PKGBUILD
	extra/herqq/PKGBUILD
	extra/hydrogen/PKGBUILD
	extra/kdegames/PKGBUILD
	extra/kradio/PKGBUILD
	extra/kshutdown/PKGBUILD
	extra/libmusicbrainz4/PKGBUILD
	extra/mahjong/PKGBUILD
	extra/mcrypt/PKGBUILD
	extra/monica/PKGBUILD
	extra/mpck/PKGBUILD
	extra/mrtg/PKGBUILD
	extra/nicotine/PKGBUILD
	extra/normalize/PKGBUILD
	extra/oprofile/PKGBUILD
	extra/perl-event/PKGBUILD
	extra/perl-unicode-string/PKGBUILD
	extra/pidgin-encryption/PKGBUILD
	extra/proftpd/PKGBUILD
	extra/pymad/PKGBUILD
	extra/qiv/PKGBUILD
	extra/quodlibet/PKGBUILD
	extra/ratpoison/PKGBUILD
	extra/rox/PKGBUILD
	extra/scrot/PKGBUILD
	extra/stardict/PKGBUILD
	extra/terminal/PKGBUILD
	extra/usbview/PKGBUILD
	extra/xdelta/PKGBUILD
	extra/xdelta3/PKGBUILD
	extra/xorg-xlsfonts/PKGBUILD
	extra/zile/PKGBUILD
	mozilla-testing/iceweasel-libre/mozconfig
	mozilla-testing/iceweasel-libre/vendor.js
	social/tokyocabinet/PKGBUILD
	~fauno/notmuch/PKGBUILD
	~mtjm/thinkfan/PKGBUILD
	~mtjm/zbar/PKGBUILD

5 files changed, 0 insertions, 1128 deletions

diff --git a/core/iputils/iputils-20101006-ping-integer-overflow.patch b/core/iputils/iputils-20101006-ping-integer-overflow.patch
deleted file mode 100644
index 720e5e888..000000000
--- a/core/iputils/iputils-20101006-ping-integer-overflow.patch
+++ /dev/null
@@ -1,11 +0,0 @@
---- iputils-s20101006/ping_common.c	2010-10-06 13:59:20.000000000 +0200
-+++ iputils-s20101006-patched/ping_common.c	2012-03-09 16:42:46.878151032 +0100
-@@ -590,7 +590,7 @@
- 
- 			/* If we are here, recvmsg() is unable to wait for
- 			 * required timeout. */
--			if (1000*next <= 1000000/(int)HZ) {
-+			if (((uint64_t)1000*next) <= (uint64_t)1000000/(int)HZ) {
- 				/* Very short timeout... So, if we wait for
- 				 * something, we sleep for MININTERVAL.
- 				 * Otherwise, spin! */
diff --git a/core/iputils/iputils-20121011-flood.patch b/core/iputils/iputils-20121011-flood.patch
deleted file mode 100644
index 5ced2d115..000000000
--- a/core/iputils/iputils-20121011-flood.patch
+++ /dev/null
@@ -1,22 +0,0 @@
---- iputils-s20121011/ping_common.h	2012-11-05 10:07:40.065281888 +0100
-+++ iputils-s20121011-new/ping_common.h	2012-11-05 10:07:22.001268362 +0100
-@@ -141,7 +141,7 @@ static inline void write_stdout(const ch
- 	do {
- 		cc = write(STDOUT_FILENO, str + o, len - o);
- 		o += cc;
--	} while (len >= o || cc < 0);
-+	} while (len > o || cc < 0);
- }
- 
- /*
---- iputils-s20121011/ping_common.c	2012-11-05 10:07:40.066281889 +0100
-+++ iputils-s20121011-new/ping_common.c	2012-11-05 10:07:22.007268368 +0100
-@@ -776,7 +776,7 @@ restamp:
- 		if (!csfailed)
- 			write_stdout("\b \b", 3);
- 		else
--			write_stdout("\bC", 1);
-+			write_stdout("\bC", 2);
- 	} else {
- 		int i;
- 		__u8 *cp, *dp;
diff --git a/core/iputils/iputils-20121114-free-unintialized.patch b/core/iputils/iputils-20121114-free-unintialized.patch
deleted file mode 100644
index 524b640ea..000000000
--- a/core/iputils/iputils-20121114-free-unintialized.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From: Jan Synacek <jsynacek@redhat.com>
-Date: Wed, 14 Nov 2012 12:57:16 +0000 (+0100)
-Subject: ping: Don't free an unintialized value.
-X-Git-Url: http://www.linux-ipv6.org/gitweb/gitweb.cgi?p=gitroot%2Fiputils.git;a=commitdiff_plain;h=44c6c9a8d3f3fc65fc52e5957bfd4cc4634f0006
-
-ping: Don't free an unintialized value.
-
-Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
----
-
-diff --git a/ping.c b/ping.c
-index fe9ff8a..9de3d08 100644
---- a/ping.c
-+++ b/ping.c
-@@ -122,7 +122,7 @@ main(int argc, char **argv)
- 	u_char *packet;
- 	char *target;
- #ifdef USE_IDN
--	char *hnamebuf;
-+	char *hnamebuf = NULL;
- #else
- 	char hnamebuf[MAX_HOSTNAMELEN];
- #endif
-@@ -263,8 +263,10 @@ main(int argc, char **argv)
- #ifdef USE_IDN
- 			int rc;
- 
--			free(hnamebuf);
--			hnamebuf = NULL;
-+			if (hnamebuf) {
-+				free(hnamebuf);
-+				hnamebuf = NULL;
-+			}
- 
- 			rc = idna_to_ascii_lz(target, &idn, 0);
- 			if (rc != IDNA_SUCCESS) {
diff --git a/core/iputils/iputils-s20101006-manpages.patch b/core/iputils/iputils-s20101006-manpages.patch
deleted file mode 100644
index 764d0d36d..000000000
--- a/core/iputils/iputils-s20101006-manpages.patch
+++ /dev/null
@@ -1,1044 +0,0 @@
---- /dev/null	2011-01-26 09:02:28.396666668 -0500
-+++ iputils-s20101006/doc/arping.8	2011-01-19 04:10:18.000000000 -0500
-@@ -0,0 +1,110 @@
-+.\" This manpage has been automatically generated by docbook2man 
-+.\" from a DocBook document.  This tool can be found at:
-+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
-+.\" Please send any bug reports, improvements, comments, patches, 
-+.\" etc. to Steve Cheng <steve@ggi-project.org>.
-+.TH "ARPING" "8" "19 January 2011" "iputils-101006" "System Manager's Manual: iputils"
-+.SH NAME
-+arping \- send ARP REQUEST to a neighbour host
-+.SH SYNOPSIS
-+
-+\fBarping\fR [ \fB-AbDfhqUV\fR]  [ \fB-c \fIcount\fB\fR]  [ \fB-w \fIdeadline\fB\fR]  [ \fB-s \fIsource\fB\fR]  \fB-I \fIinterface\fB\fR \fB\fIdestination\fB\fR
-+
-+.SH "DESCRIPTION"
-+.PP
-+Ping \fIdestination\fR on device \fIinterface\fR by ARP packets,
-+using source address \fIsource\fR.
-+.SH "OPTIONS"
-+.TP
-+\fB-A\fR
-+The same as \fB-U\fR, but ARP REPLY packets used instead
-+of ARP REQUEST.
-+.TP
-+\fB-b\fR
-+Send only MAC level broadcasts. Normally \fBarping\fR starts
-+from sending broadcast, and switch to unicast after reply received.
-+.TP
-+\fB-c \fIcount\fB\fR
-+Stop after sending \fIcount\fR ARP REQUEST
-+packets. With 
-+\fIdeadline\fR
-+option, \fBarping\fR waits for
-+\fIcount\fR ARP REPLY packets, until the timeout expires.
-+.TP
-+\fB-D\fR
-+Duplicate address detection mode (DAD). See 
-+RFC2131, 4.4.1.
-+Returns 0, if DAD succeeded i.e. no replies are received
-+.TP
-+\fB-f\fR
-+Finish after the first reply confirming that target is alive.
-+.TP
-+\fB-I \fIinterface\fB\fR
-+Name of network device where to send ARP REQUEST packets. This option
-+is required.
-+.TP
-+\fB-h\fR
-+Print help page and exit.
-+.TP
-+\fB-q\fR
-+Quiet output. Nothing is displayed.
-+.TP
-+\fB-s \fIsource\fB\fR
-+IP source address to use in ARP packets.
-+If this option is absent, source address is:
-+.RS
-+.TP 0.2i
-+\(bu
-+In DAD mode (with option \fB-D\fR) set to 0.0.0.0.
-+.TP 0.2i
-+\(bu
-+In Unsolicited ARP mode (with options \fB-U\fR or \fB-A\fR)
-+set to \fIdestination\fR.
-+.TP 0.2i
-+\(bu
-+Otherwise, it is calculated from routing tables.
-+.RE
-+.TP
-+\fB-U\fR
-+Unsolicited ARP mode to update neighbours' ARP caches.
-+No replies are expected.
-+.TP
-+\fB-V\fR
-+Print version of the program and exit.
-+.TP
-+\fB-w \fIdeadline\fB\fR
-+Specify a timeout, in seconds, before
-+\fBarping\fR
-+exits regardless of how many
-+packets have been sent or received. In this case
-+\fBarping\fR
-+does not stop after
-+\fIcount\fR
-+packet are sent, it waits either for
-+\fIdeadline\fR
-+expire or until
-+\fIcount\fR
-+probes are answered.
-+.SH "SEE ALSO"
-+.PP
-+\fBping\fR(8),
-+\fBclockdiff\fR(8),
-+\fBtracepath\fR(8).
-+.SH "AUTHOR"
-+.PP
-+\fBarping\fR was written by
-+Alexey Kuznetsov
-+<kuznet@ms2.inr.ac.ru>.
-+It is now maintained by
-+YOSHIFUJI Hideaki
-+<yoshfuji@skbuff.net>.
-+.SH "SECURITY"
-+.PP
-+\fBarping\fR requires CAP_NET_RAWIO capability
-+to be executed. It is not recommended to be used as set-uid root,
-+because it allows user to modify ARP caches of neighbour hosts.
-+.SH "AVAILABILITY"
-+.PP
-+\fBarping\fR is part of \fIiputils\fR package
-+and the latest versions are  available in source form at
-+http://www.skbuff.net/iputils/iputils-current.tar.bz2.
---- /dev/null	2011-01-26 09:02:28.396666668 -0500
-+++ iputils-s20101006/doc/clockdiff.8	2011-01-19 04:10:19.000000000 -0500
-@@ -0,0 +1,81 @@
-+.\" This manpage has been automatically generated by docbook2man 
-+.\" from a DocBook document.  This tool can be found at:
-+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
-+.\" Please send any bug reports, improvements, comments, patches, 
-+.\" etc. to Steve Cheng <steve@ggi-project.org>.
-+.TH "CLOCKDIFF" "8" "19 January 2011" "iputils-101006" "System Manager's Manual: iputils"
-+.SH NAME
-+clockdiff \- measure clock difference between hosts
-+.SH SYNOPSIS
-+
-+\fBclockdiff\fR [ \fB-o\fR]  [ \fB-o1\fR]  \fB\fIdestination\fB\fR
-+
-+.SH "DESCRIPTION"
-+.PP
-+\fBclockdiff\fR Measures clock difference between us and
-+\fIdestination\fR with 1 msec resolution using ICMP TIMESTAMP
-+[2]
-+packets or, optionally, IP TIMESTAMP option
-+[3]
-+option added to ICMP ECHO.
-+[1]
-+.SH "OPTIONS"
-+.TP
-+\fB-o\fR
-+Use IP TIMESTAMP with ICMP ECHO instead of ICMP TIMESTAMP
-+messages. It is useful with some destinations, which do not support
-+ICMP TIMESTAMP (f.e. Solaris <2.4).
-+.TP
-+\fB-o1\fR
-+Slightly different form of \fB-o\fR, namely it uses three-term
-+IP TIMESTAMP with prespecified hop addresses instead of four term one.
-+What flavor works better depends on target host. Particularly,
-+\fB-o\fR is better for Linux.
-+.SH "WARNINGS"
-+.TP 0.2i
-+\(bu
-+Some nodes (Cisco) use non-standard timestamps, which is allowed
-+by RFC, but makes timestamps mostly useless.
-+.TP 0.2i
-+\(bu
-+Some nodes generate messed timestamps (Solaris>2.4), when
-+run \fBxntpd\fR. Seems, its IP stack uses a corrupted clock source,
-+which is synchronized to time-of-day clock periodically and jumps
-+randomly making timestamps mostly useless. Good news is that you can
-+use NTP in this case, which is even better.
-+.TP 0.2i
-+\(bu
-+\fBclockdiff\fR shows difference in time modulo 24 days.
-+.SH "SEE ALSO"
-+.PP
-+\fBping\fR(8),
-+\fBarping\fR(8),
-+\fBtracepath\fR(8).
-+.SH "REFERENCES"
-+.PP
-+[1] ICMP ECHO,
-+RFC0792, page 14.
-+.PP
-+[2] ICMP TIMESTAMP,
-+RFC0792, page 16.
-+.PP
-+[3] IP TIMESTAMP option,
-+RFC0791, 3.1, page 16.
-+.SH "AUTHOR"
-+.PP
-+\fBclockdiff\fR was compiled by
-+Alexey Kuznetsov
-+<kuznet@ms2.inr.ac.ru>. It was based on code borrowed
-+from BSD \fBtimed\fR daemon.
-+It is now maintained by
-+YOSHIFUJI Hideaki
-+<yoshfuji@skbuff.net>.
-+.SH "SECURITY"
-+.PP
-+\fBclockdiff\fR requires CAP_NET_RAWIO capability
-+to be executed. It is safe to be used as set-uid root.
-+.SH "AVAILABILITY"
-+.PP
-+\fBclockdiff\fR is part of \fIiputils\fR package
-+and the latest versions are  available in source form at
-+http://www.skbuff.net/iputils/iputils-current.tar.bz2.
---- /dev/null	2011-01-26 09:02:28.396666668 -0500
-+++ iputils-s20101006/doc/ping.8	2011-01-19 04:10:19.000000000 -0500
-@@ -0,0 +1,408 @@
-+.\" This manpage has been automatically generated by docbook2man 
-+.\" from a DocBook document.  This tool can be found at:
-+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
-+.\" Please send any bug reports, improvements, comments, patches, 
-+.\" etc. to Steve Cheng <steve@ggi-project.org>.
-+.TH "PING" "8" "19 January 2011" "iputils-101006" "System Manager's Manual: iputils"
-+.SH NAME
-+ping, ping6 \- send ICMP ECHO_REQUEST to network hosts
-+.SH SYNOPSIS
-+
-+\fBping\fR [ \fB-LRUbdfnqrvVaAB\fR]  [ \fB-c \fIcount\fB\fR]  [ \fB-m \fImark\fB\fR]  [ \fB-i \fIinterval\fB\fR]  [ \fB-l \fIpreload\fB\fR]  [ \fB-p \fIpattern\fB\fR]  [ \fB-s \fIpacketsize\fB\fR]  [ \fB-t \fIttl\fB\fR]  [ \fB-w \fIdeadline\fB\fR]  [ \fB-F \fIflowlabel\fB\fR]  [ \fB-I \fIinterface\fB\fR]  [ \fB-M \fIhint\fB\fR]  [ \fB-N \fInioption\fB\fR]  [ \fB-Q \fItos\fB\fR]  [ \fB-S \fIsndbuf\fB\fR]  [ \fB-T \fItimestamp option\fB\fR]  [ \fB-W \fItimeout\fB\fR]  [ \fB\fIhop\fB\fR\fI ...\fR]  \fB\fIdestination\fB\fR
-+
-+.SH "DESCRIPTION"
-+.PP
-+\fBping\fR uses the ICMP protocol's mandatory ECHO_REQUEST
-+datagram to elicit an ICMP ECHO_RESPONSE from a host or gateway.
-+ECHO_REQUEST datagrams (``pings'') have an IP and ICMP
-+header, followed by a struct timeval and then an arbitrary
-+number of ``pad'' bytes used to fill out the packet.
-+.PP
-+\fBping6\fR can also send Node Information Queries (RFC4620).
-+.SH "OPTIONS"
-+.TP
-+\fB-a\fR
-+Audible ping.
-+.TP
-+\fB-A\fR
-+Adaptive ping. Interpacket interval adapts to round-trip time, so that
-+effectively not more than one (or more, if preload is set) unanswered probes
-+present in the network. Minimal interval is 200msec for not super-user.
-+On networks with low rtt this mode is essentially equivalent to flood mode.  
-+.TP
-+\fB-b\fR
-+Allow pinging a broadcast address.
-+.TP
-+\fB-B\fR
-+Do not allow \fBping\fR to change source address of probes.
-+The address is bound to one selected when \fBping\fR starts.
-+.TP
-+\fB-m \fImark\fB\fR
-+use \fImark\fR to tag the packets going out. This is useful
-+for variety of reasons within the kernel such as using policy
-+routing to select specific outbound processing.
-+.TP
-+\fB-c \fIcount\fB\fR
-+Stop after sending \fIcount\fR ECHO_REQUEST
-+packets. With 
-+\fIdeadline\fR
-+option, \fBping\fR waits for
-+\fIcount\fR ECHO_REPLY packets, until the timeout expires.
-+.TP
-+\fB-d\fR
-+Set the SO_DEBUG option on the socket being used.
-+Essentially, this socket option is not used by Linux kernel. 
-+.TP
-+\fB-F \fIflow label\fB\fR
-+Allocate and set 20 bit flow label on echo request packets.
-+(Only \fBping6\fR). If value is zero, kernel allocates random flow label.
-+.TP
-+\fB-f\fR
-+Flood ping. For every ECHO_REQUEST sent a period ``.'' is printed,
-+while for ever ECHO_REPLY received a backspace is printed.
-+This provides a rapid display of how many packets are being dropped.
-+If interval is not given, it sets interval to zero and
-+outputs packets as fast as they come back or one hundred times per second,
-+whichever is more.
-+Only the super-user may use this option with zero interval.
-+.TP
-+\fB-i \fIinterval\fB\fR
-+Wait \fIinterval\fR seconds between sending each packet.
-+The default is to wait for one second between each packet normally,
-+or not to wait in flood mode. Only super-user may set interval
-+to values less 0.2 seconds.
-+.TP
-+\fB-I \fIinterface address\fB\fR
-+Set source address to specified interface address. Argument
-+may be numeric IP address or name of device. When pinging IPv6
-+link-local address this option is required.
-+.TP
-+\fB-l \fIpreload\fB\fR
-+If \fIpreload\fR is specified,
-+\fBping\fR sends that many packets not waiting for reply.
-+Only the super-user may select preload more than 3.
-+.TP
-+\fB-L\fR
-+Suppress loopback of multicast packets.  This flag only applies if the ping
-+destination is a multicast address.
-+.TP
-+\fB-N \fInioption\fB\fR
-+Send ICMPv6 Node Information Queries (RFC4620), instead of Echo Request.
-+.RS
-+.TP
-+\fBname\fR
-+Queries for Node Names.
-+.RE
-+.RS
-+.TP
-+\fBipv6\fR
-+Queries for IPv6 Addresses. There are several IPv6 specific flags.
-+.RS
-+.TP
-+\fBipv6-global\fR
-+Request IPv6 global-scope addresses.
-+.RE
-+.RS
-+.TP
-+\fBipv6-sitelocal\fR
-+Request IPv6 site-local addresses.
-+.RE
-+.RS
-+.TP
-+\fBipv6-linklocal\fR
-+Request IPv6 link-local addresses.
-+.RE
-+.RS
-+.TP
-+\fBipv6-all\fR
-+Request IPv6 addresses on other interfaces.
-+.RE
-+.RE
-+.RS
-+.TP
-+\fBipv4\fR
-+Queries for IPv4 Addresses.  There is one IPv4 specific flag.
-+.RS
-+.TP
-+\fBipv4-all\fR
-+Request IPv4 addresses on other interfaces.
-+.RE
-+.RE
-+.RS
-+.TP
-+\fBsubject-ipv6=\fIipv6addr\fB\fR
-+IPv6 subject address.
-+.RE
-+.RS
-+.TP
-+\fBsubject-ipv4=\fIipv4addr\fB\fR
-+IPv4 subject address.
-+.RE
-+.RS
-+.TP
-+\fBsubject-name=\fInodename\fB\fR
-+Subject name.  If it contains more than one dot,
-+fully-qualified domain name is assumed.
-+.RE
-+.RS
-+.TP
-+\fBsubject-fqdn=\fInodename\fB\fR
-+Subject name.  Fully-qualified domain name is
-+always assumed.
-+.RE
-+.TP
-+\fB-n\fR
-+Numeric output only.
-+No attempt will be made to lookup symbolic names for host addresses.
-+.TP
-+\fB-p \fIpattern\fB\fR
-+You may specify up to 16 ``pad'' bytes to fill out the packet you send.
-+This is useful for diagnosing data-dependent problems in a network.
-+For example, \fB-p ff\fR will cause the sent packet
-+to be filled with all ones.
-+.TP
-+\fB-D\fR
-+Print timestamp (unix time + microseconds as in gettimeofday) before
-+each line.
-+.TP
-+\fB-Q \fItos\fB\fR
-+Set Quality of Service -related bits in ICMP datagrams.  
-+\fItos\fR can be either decimal or hex number.
-+Traditionally (RFC1349), these have been interpreted as: 0 for reserved
-+(currently being redefined as congestion control), 1-4 for Type of Service
-+and 5-7 for Precedence.
-+Possible settings for Type of Service are: minimal cost: 0x02, 
-+reliability: 0x04, throughput: 0x08, low delay: 0x10.  Multiple TOS bits
-+should not be set simultaneously.  Possible settings for
-+special Precedence range from priority (0x20) to net control (0xe0).  You
-+must be root (CAP_NET_ADMIN capability) to use Critical or
-+higher precedence value.  You cannot set
-+bit 0x01 (reserved) unless ECN has been enabled in the kernel.
-+In RFC2474, these fields has been redefined as 8-bit Differentiated
-+Services (DS), consisting of: bits 0-1 of separate data (ECN will be used,
-+here), and bits 2-7 of Differentiated Services Codepoint (DSCP).
-+.TP
-+\fB-q\fR
-+Quiet output.
-+Nothing is displayed except the summary lines at startup time and
-+when finished.
-+.TP
-+\fB-R\fR
-+Record route.
-+Includes the RECORD_ROUTE option in the ECHO_REQUEST
-+packet and displays the route buffer on returned packets.
-+Note that the IP header is only large enough for nine such routes.
-+Many hosts ignore or discard this option.
-+.TP
-+\fB-r\fR
-+Bypass the normal routing tables and send directly to a host on an attached
-+interface.
-+If the host is not on a directly-attached network, an error is returned.
-+This option can be used to ping a local host through an interface
-+that has no route through it provided the option \fB-I\fR is also
-+used.
-+.TP
-+\fB-s \fIpacketsize\fB\fR
-+Specifies the number of data bytes to be sent.  
-+The default is 56, which translates into 64 ICMP
-+data bytes when combined with the 8 bytes of ICMP header data.
-+.TP
-+\fB-S \fIsndbuf\fB\fR
-+Set socket sndbuf. If not specified, it is selected to buffer
-+not more than one packet.
-+.TP
-+\fB-t \fIttl\fB\fR
-+Set the IP Time to Live.
-+.TP
-+\fB-T \fItimestamp option\fB\fR
-+Set special IP timestamp options.
-+\fItimestamp option\fR may be either 
-+\fItsonly\fR (only timestamps), 
-+\fItsandaddr\fR (timestamps and addresses) or 
-+\fItsprespec host1 [host2 [host3 [host4]]]\fR
-+(timestamp prespecified hops).
-+.TP
-+\fB-M \fIhint\fB\fR
-+Select Path MTU Discovery strategy.
-+\fIhint\fR may be either \fIdo\fR
-+(prohibit fragmentation, even local one), 
-+\fIwant\fR (do PMTU discovery, fragment locally when packet size
-+is large), or \fIdont\fR (do not set DF flag).
-+.TP
-+\fB-U\fR
-+Print full user-to-user latency (the old behaviour). Normally
-+\fBping\fR
-+prints network round trip time, which can be different
-+f.e. due to DNS failures. 
-+.TP
-+\fB-v\fR
-+Verbose output.
-+.TP
-+\fB-V\fR
-+Show version and exit.
-+.TP
-+\fB-w \fIdeadline\fB\fR
-+Specify a timeout, in seconds, before
-+\fBping\fR
-+exits regardless of how many
-+packets have been sent or received. In this case
-+\fBping\fR
-+does not stop after
-+\fIcount\fR
-+packet are sent, it waits either for
-+\fIdeadline\fR
-+expire or until
-+\fIcount\fR
-+probes are answered or for some error notification from network.   
-+.TP
-+\fB-W \fItimeout\fB\fR
-+Time to wait for a response, in seconds. The option affects only timeout
-+in absense of any responses, otherwise \fBping\fR waits for two RTTs.
-+.PP
-+When using \fBping\fR for fault isolation, it should first be run
-+on the local host, to verify that the local network interface is up
-+and running. Then, hosts and gateways further and further away should be
-+``pinged''. Round-trip times and packet loss statistics are computed.
-+If duplicate packets are received, they are not included in the packet
-+loss calculation, although the round trip time of these packets is used
-+in calculating the minimum/average/maximum round-trip time numbers.
-+When the specified number of packets have been sent (and received) or
-+if the program is terminated with a
-+SIGINT, a brief summary is displayed. Shorter current statistics
-+can be obtained without termination of process with signal
-+SIGQUIT.
-+.PP
-+If \fBping\fR does not receive any reply packets at all it will
-+exit with code 1. If a packet 
-+\fIcount\fR
-+and
-+\fIdeadline\fR
-+are both specified, and fewer than
-+\fIcount\fR
-+packets are received by the time the
-+\fIdeadline\fR
-+has arrived, it will also exit with code 1. 
-+On other error it exits with code 2. Otherwise it exits with code 0. This
-+makes it possible to use the exit code to see if a host is alive or
-+not.
-+.PP
-+This program is intended for use in network testing, measurement and
-+management.
-+Because of the load it can impose on the network, it is unwise to use
-+\fBping\fR during normal operations or from automated scripts.
-+.SH "ICMP PACKET DETAILS"
-+.PP
-+An IP header without options is 20 bytes.
-+An ICMP ECHO_REQUEST packet contains an additional 8 bytes worth
-+of ICMP header followed by an arbitrary amount of data.
-+When a \fIpacketsize\fR is given, this indicated the size of this
-+extra piece of data (the default is 56). Thus the amount of data received
-+inside of an IP packet of type ICMP ECHO_REPLY will always be 8 bytes
-+more than the requested data space (the ICMP header).
-+.PP
-+If the data space is at least of size of struct timeval
-+\fBping\fR uses the beginning bytes of this space to include
-+a timestamp which it uses in the computation of round trip times.
-+If the data space is shorter, no round trip times are given.
-+.SH "DUPLICATE AND DAMAGED PACKETS"
-+.PP
-+\fBping\fR will report duplicate and damaged packets.
-+Duplicate packets should never occur, and seem to be caused by
-+inappropriate link-level retransmissions.
-+Duplicates may occur in many situations and are rarely (if ever) a
-+good sign, although the presence of low levels of duplicates may not
-+always be cause for alarm.
-+.PP
-+Damaged packets are obviously serious cause for alarm and often
-+indicate broken hardware somewhere in the
-+\fBping\fR packet's path (in the network or in the hosts).
-+.SH "TRYING DIFFERENT DATA PATTERNS"
-+.PP
-+The (inter)network layer should never treat packets differently depending
-+on the data contained in the data portion.
-+Unfortunately, data-dependent problems have been known to sneak into
-+networks and remain undetected for long periods of time.
-+In many cases the particular pattern that will have problems is something
-+that doesn't have sufficient ``transitions'', such as all ones or all
-+zeros, or a pattern right at the edge, such as almost all zeros.
-+It isn't necessarily enough to specify a data pattern of all zeros (for
-+example) on the command line because the pattern that is of interest is
-+at the data link level, and the relationship between what you type and
-+what the controllers transmit can be complicated.
-+.PP
-+This means that if you have a data-dependent problem you will probably
-+have to do a lot of testing to find it.
-+If you are lucky, you may manage to find a file that either can't be sent
-+across your network or that takes much longer to transfer than other
-+similar length files.
-+You can then examine this file for repeated patterns that you can test
-+using the \fB-p\fR option of \fBping\fR.
-+.SH "TTL DETAILS"
-+.PP
-+The TTL value of an IP packet represents the maximum number of IP routers
-+that the packet can go through before being thrown away.
-+In current practice you can expect each router in the Internet to decrement
-+the TTL field by exactly one.
-+.PP
-+The TCP/IP specification states that the TTL field for TCP
-+packets should be set to 60, but many systems use smaller values
-+(4.3 BSD uses 30, 4.2 used 15).
-+.PP
-+The maximum possible value of this field is 255, and most Unix systems set
-+the TTL field of ICMP ECHO_REQUEST packets to 255.
-+This is why you will find you can ``ping'' some hosts, but not reach them
-+with
-+\fBtelnet\fR(1)
-+or
-+\fBftp\fR(1).
-+.PP
-+In normal operation ping prints the ttl value from the packet it receives.
-+When a remote system receives a ping packet, it can do one of three things
-+with the TTL field in its response:
-+.TP 0.2i
-+\(bu
-+Not change it; this is what Berkeley Unix systems did before the
-+4.3BSD Tahoe release. In this case the TTL value in the received packet
-+will be 255 minus the number of routers in the round-trip path.
-+.TP 0.2i
-+\(bu
-+Set it to 255; this is what current Berkeley Unix systems do.
-+In this case the TTL value in the received packet will be 255 minus the
-+number of routers in the path \fBfrom\fR
-+the remote system \fBto\fR the \fBping\fRing host.
-+.TP 0.2i
-+\(bu
-+Set it to some other value. Some machines use the same value for
-+ICMP packets that they use for TCP packets, for example either 30 or 60.
-+Others may use completely wild values.
-+.SH "BUGS"
-+.TP 0.2i
-+\(bu
-+Many Hosts and Gateways ignore the RECORD_ROUTE option.
-+.TP 0.2i
-+\(bu
-+The maximum IP header length is too small for options like
-+RECORD_ROUTE to be completely useful.
-+There's not much that that can be done about this, however.
-+.TP 0.2i
-+\(bu
-+Flood pinging is not recommended in general, and flood pinging the
-+broadcast address should only be done under very controlled conditions.
-+.SH "SEE ALSO"
-+.PP
-+\fBnetstat\fR(1),
-+\fBifconfig\fR(8).
-+.SH "HISTORY"
-+.PP
-+The \fBping\fR command appeared in 4.3BSD.
-+.PP
-+The version described here is its descendant specific to Linux.
-+.SH "SECURITY"
-+.PP
-+\fBping\fR requires CAP_NET_RAWIO capability
-+to be executed. It may be used as set-uid root.
-+.SH "AVAILABILITY"
-+.PP
-+\fBping\fR is part of \fIiputils\fR package
-+and the latest versions are  available in source form at
-+http://www.skbuff.net/iputils/iputils-current.tar.bz2.
---- /dev/null	2011-01-26 09:02:28.396666668 -0500
-+++ iputils-s20101006/doc/rdisc.8	2011-01-19 04:10:20.000000000 -0500
-@@ -0,0 +1,110 @@
-+.\" This manpage has been automatically generated by docbook2man 
-+.\" from a DocBook document.  This tool can be found at:
-+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
-+.\" Please send any bug reports, improvements, comments, patches, 
-+.\" etc. to Steve Cheng <steve@ggi-project.org>.
-+.TH "RDISC" "8" "19 January 2011" "iputils-101006" "System Manager's Manual: iputils"
-+.SH NAME
-+rdisc \- network router discovery daemon
-+.SH SYNOPSIS
-+
-+\fBrdisc\fR [ \fB-abdfstvV\fR]  [ \fB\fIsend_address\fB\fR]  [ \fB\fIreceive_address\fB\fR] 
-+
-+.SH "DESCRIPTION"
-+.PP
-+\fBrdisc\fR implements client side of the ICMP router discover protocol.
-+\fBrdisc\fR is invoked at boot time to populate the network
-+routing tables with default routes. 
-+.PP
-+\fBrdisc\fR listens on the ALL_HOSTS (224.0.0.1) multicast address
-+(or \fIreceive_address\fR provided it is given) 
-+for ROUTER_ADVERTISE messages from routers. The received
-+messages are handled by first ignoring those listed router addresses
-+with which the host does not share a network. Among the remaining addresses
-+the ones with the highest preference are selected as default routers
-+and a default route is entered in the kernel routing table
-+for each one of them.
-+.PP
-+Optionally, \fBrdisc\fR can avoid waiting for routers to announce 
-+themselves by sending out a few ROUTER_SOLICITATION messages
-+to the ALL_ROUTERS (224.0.0.2) multicast address 
-+(or \fIsend_address\fR provided it is given) 
-+when it is started.
-+.PP
-+A timer is associated with each router address and the address will
-+no longer be considered for inclusion in the the routing tables if the 
-+timer expires before a new 
-+\fBadvertise\fR message is received from the router.
-+The address will also be excluded from consideration if the host receives an 
-+\fBadvertise\fR
-+message with the preference being maximally negative.
-+.PP
-+Server side of router discovery protocol is supported by Cisco IOS
-+and by any more or less complete UNIX routing daemon, f.e \fBgated\fR.
-+.SH "OPTIONS"
-+.TP
-+\fB-a\fR
-+Accept all routers independently of the preference they have in their 
-+\fBadvertise\fR messages.
-+Normally \fBrdisc\fR only accepts (and enters in the kernel routing
-+tables) the router or routers with the highest preference.
-+.TP
-+\fB-b\fR
-+Opposite to \fB-a\fR, i.e. install only router with the best
-+preference value. It is default behaviour.
-+.TP
-+\fB-d\fR
-+Send debugging messages to syslog.
-+.TP
-+\fB-f\fR
-+Run \fBrdisc\fR forever even if no routers are found.
-+Normally \fBrdisc\fR gives up if it has not received any 
-+\fBadvertise\fR message after after soliciting three times,
-+in which case it exits with a non-zero exit code.
-+If \fB-f\fR is not specified in the first form then 
-+\fB-s\fR must be specified.
-+.TP
-+\fB-s\fR
-+Send three \fBsolicitation\fR messages initially to quickly discover
-+the routers when the system is booted.
-+When \fB-s\fR is specified \fBrdisc\fR
-+exits with a non-zero exit code if it can not find any routers.
-+This can be overridden with the \fB-f\fR option.
-+.TP
-+\fB-t\fR
-+Test mode. Do not go to background.
-+.TP
-+\fB-v\fR
-+Be verbose i.e. send lots of debugging messages to syslog.
-+.TP
-+\fB-V\fR
-+Print version and exit.
-+.SH "HISTORY"
-+.PP
-+This program was developed by Sun Microsystems (see copyright
-+notice in source file). It was ported to Linux by
-+Alexey Kuznetsov
-+<kuznet@ms2.inr.ac.ru>.
-+It is now maintained by
-+YOSHIFUJI Hideaki
-+<yoshfuji@skbuff.net>.
-+.SH "SEE ALSO"
-+.PP
-+\fBicmp\fR(7),
-+\fBinet\fR(7),
-+\fBping\fR(8).
-+.SH "REFERENCES"
-+.PP
-+Deering, S.E.,ed "ICMP Router Discovery Messages",
-+RFC1256, Network Information Center, SRI International,
-+Menlo Park, Calif., September 1991.
-+.SH "SECURITY"
-+.PP
-+\fBrdisc\fR requires CAP_NET_RAWIO to listen
-+and send ICMP messages and capability CAP_NET_ADMIN
-+to update routing tables. 
-+.SH "AVAILABILITY"
-+.PP
-+\fBrdisc\fR is part of \fIiputils\fR package
-+and the latest versions are  available in source form at
-+http://www.skbuff.net/iputils/iputils-current.tar.bz2.
---- /dev/null	2011-01-26 09:02:28.396666668 -0500
-+++ iputils-s20101006/doc/tracepath.8	2011-01-19 04:10:20.000000000 -0500
-@@ -0,0 +1,97 @@
-+.\" This manpage has been automatically generated by docbook2man 
-+.\" from a DocBook document.  This tool can be found at:
-+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
-+.\" Please send any bug reports, improvements, comments, patches, 
-+.\" etc. to Steve Cheng <steve@ggi-project.org>.
-+.TH "TRACEPATH" "8" "19 January 2011" "iputils-101006" "System Manager's Manual: iputils"
-+.SH NAME
-+tracepath, tracepath6 \- traces path to a network host discovering MTU along this path
-+.SH SYNOPSIS
-+
-+\fBtracepath\fR [ \fB-n\fR]  [ \fB-b\fR]  [ \fB-l \fIpktlen\fB\fR]  \fB\fIdestination\fB\fR [ \fB\fIport\fB\fR] 
-+
-+.SH "DESCRIPTION"
-+.PP
-+It traces path to \fIdestination\fR discovering MTU along this path.
-+It uses UDP port \fIport\fR or some random port.
-+It is similar to \fBtraceroute\fR, only does not require superuser
-+privileges and has no fancy options.
-+.PP
-+\fBtracepath6\fR is good replacement for \fBtraceroute6\fR
-+and classic example of application of Linux error queues.
-+The situation with IPv4 is worse, because commercial
-+IP routers do not return enough information in icmp error messages.
-+Probably, it will change, when they will be updated.
-+For now it uses Van Jacobson's trick, sweeping a range
-+of UDP ports to maintain trace history.
-+.SH "OPTIONS"
-+.TP
-+\fB-n\fR
-+Print primarily IP addresses numerically.
-+.TP
-+\fB-b\fR
-+Print both of host names and IP addresses.
-+.TP
-+\fB-l\fR
-+Sets the initial packet length to \fIpktlen\fR instead of
-+65536 for \fBtracepath\fR or 128000 for \fBtracepath6\fR.
-+.SH "OUTPUT"
-+.PP
-+
-+.nf
-+root@mops:~ # tracepath6 3ffe:2400:0:109::2
-+ 1?: [LOCALHOST]                              pmtu 1500
-+ 1:  dust.inr.ac.ru                   0.411ms
-+ 2:  dust.inr.ac.ru        asymm  1   0.390ms pmtu 1480
-+ 2:  3ffe:2400:0:109::2               463.514ms reached
-+     Resume: pmtu 1480 hops 2 back 2
-+.fi
-+.PP
-+The first column shows TTL of the probe, followed by colon.
-+Usually value of TTL is obtained from reply from network,
-+but sometimes reply does not contain necessary information and
-+we have to guess it. In this case the number is followed by ?.
-+.PP
-+The second column shows the network hop, which replied to the probe.
-+It is either address of router or word [LOCALHOST], if
-+the probe was not sent to the network.
-+.PP
-+The rest of line shows miscellaneous information about path to
-+the correspinding hetwork hop. As rule it contains value of RTT.
-+Additionally, it can show Path MTU, when it changes.
-+If the path is asymmetric
-+or the probe finishes before it reach prescribed hop, difference
-+between number of hops in forward and backward direction is shown
-+following keyword async. This information is not reliable.
-+F.e. the third line shows asymmetry of 1, it is because the first probe
-+with TTL of 2 was rejected at the first hop due to Path MTU Discovery.
-+.PP
-+The last line summarizes information about all the path to the destination,
-+it shows detected Path MTU, amount of hops to the destination and our
-+guess about amount of hops from the destination to us, which can be
-+different when the path is asymmetric.
-+.SH "SEE ALSO"
-+.PP
-+\fBtraceroute\fR(8),
-+\fBtraceroute6\fR(8),
-+\fBping\fR(8).
-+.SH "AUTHOR"
-+.PP
-+\fBtracepath\fR was written by
-+Alexey Kuznetsov
-+<kuznet@ms2.inr.ac.ru>.
-+.SH "SECURITY"
-+.PP
-+No security issues.
-+.PP
-+This lapidary deserves to be elaborated.
-+\fBtracepath\fR is not a privileged program, unlike
-+\fBtraceroute\fR, \fBping\fR and other beasts of this kind.
-+\fBtracepath\fR may be executed by everyone who has some access
-+to network, enough to send UDP datagrams to investigated destination
-+using given port.
-+.SH "AVAILABILITY"
-+.PP
-+\fBtracepath\fR is part of \fIiputils\fR package
-+and the latest versions are  available in source form at
-+http://www.skbuff.net/iputils/iputils-current.tar.bz2.
-diff -Naur /dev/null iputils-s20101006/doc/rarpd.8
----  /dev/null	2011-01-26 09:02:28.396666668 -0500
-+++ iputils-s20101006/doc/rarpd.8	2011-01-08 20:09:51.270811811 -0500
-@@ -0,0 +1,84 @@
-+.\" This manpage has been automatically generated by docbook2man 
-+.\" from a DocBook document.  This tool can be found at:
-+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
-+.\" Please send any bug reports, improvements, comments, patches, 
-+.\" etc. to Steve Cheng <steve@ggi-project.org>.
-+.TH "RARPD" "8" "08 January 2011" "iputils-101006" "System Manager's Manual: iputils"
-+.SH NAME
-+rarpd \- answer RARP REQUESTs
-+.SH SYNOPSIS
-+
-+\fBarping\fR [\fB-aAvde\fR] [\fB-b \fIbootdir\fB\fR] [\fB\fIinterface\fB\fR]
-+
-+.SH "DESCRIPTION"
-+.PP
-+Listens
-+RARP
-+requests from clients. Provided MAC address of client
-+is found in \fI/etc/ethers\fR database and
-+obtained host name is resolvable to an IP address appropriate
-+for attached network, \fBrarpd\fR answers to client with RARPD
-+reply carrying an IP address.
-+.PP
-+To allow multiple boot servers on the network \fBrarpd\fR
-+optionally checks for presence Sun-like bootable image in TFTP directory.
-+It should have form \fBHexadecimal_IP.ARCH\fR, f.e. to load
-+sparc 193.233.7.98 \fIC1E90762.SUN4M\fR is linked to
-+an image appropriate for SUM4M in directory \fI/etc/tftpboot\fR.
-+.SH "WARNING"
-+.PP
-+This facility is deeply obsoleted by
-+BOOTP
-+and later
-+DHCP protocols.
-+However, some clients really still need this to boot.
-+.SH "OPTIONS"
-+.TP
-+\fB-a\fR
-+Listen on all the interfaces. Currently it is an internal
-+option, its function is overridden with \fIinterface\fR
-+argument. It should not be used.
-+.TP
-+\fB-A\fR
-+Listen not only RARP but also ARP messages, some rare clients
-+use ARP by some unknown reason.
-+.TP
-+\fB-v\fR
-+Be verbose.
-+.TP
-+\fB-d\fR
-+Debug mode. Do not go to background.
-+.TP
-+\fB-e\fR
-+Do not check for presence of a boot image, reply if MAC address
-+resolves to a valid IP address using \fI/etc/ethers\fR
-+database and DNS. 
-+.TP
-+\fB-b \fIbootdir\fB\fR
-+TFTP boot directory. Default is \fI/etc/tftpboot\fR
-+.SH "SEE ALSO"
-+.PP
-+\fBarping\fR(8),
-+\fBtftpd\fR(8).
-+.SH "AUTHOR"
-+.PP
-+\fBrarpd\fR was written by
-+Alexey Kuznetsov
-+<kuznet@ms2.inr.ac.ru>.
-+It is now maintained by
-+YOSHIFUJI Hideaki
-+<yoshfuji@skbuff.net>.
-+.SH "SECURITY"
-+.PP
-+\fBrarpd\fR requires CAP_NET_RAWIO capability
-+to listen and send RARP and ARP packets. It also needs CAP_NET_ADMIN
-+to give to kernel hint for ARP resolution; this is not strictly required,
-+but some (most of, to be more exact) clients are so badly broken that
-+are not able to answer ARP before they are finally booted. This is
-+not wonderful taking into account that clients using RARPD in 2002
-+are all unsupported relic creatures of 90's and even earlier.
-+.SH "AVAILABILITY"
-+.PP
-+\fBrarpd\fR is part of \fIiputils\fR package
-+and the latest versions are  available in source form at
-+http://www.skbuff.net/iputils/iputils-current.tar.bz2.
-diff -Naur /dev/null iputils-s20101006/doc/tftpd.8
---- /dev/null	2011-01-26 09:02:28.396666668 -0500
-+++ iputils-s20101006/doc/tftpd.8	2011-01-08 20:09:51.723407498 -0500
-@@ -0,0 +1,85 @@
-+.\" This manpage has been automatically generated by docbook2man 
-+.\" from a DocBook document.  This tool can be found at:
-+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
-+.\" Please send any bug reports, improvements, comments, patches, 
-+.\" etc. to Steve Cheng <steve@ggi-project.org>.
-+.TH "TFTPD" "8" "08 January 2011" "iputils-101006" "System Manager's Manual: iputils"
-+.SH NAME
-+tftpd \- Trivial File Transfer Protocol server
-+.SH SYNOPSIS
-+
-+\fBtftpd\fR \fB\fIdirectory\fB\fR
-+
-+.SH "DESCRIPTION"
-+.PP
-+\fBtftpd\fR is a server which supports the DARPA
-+Trivial File Transfer Protocol
-+(RFC1350).
-+The TFTP server is started
-+by \fBinetd\fR(8).
-+.PP
-+\fIdirectory\fR is required argument; if it is not given
-+\fBtftpd\fR aborts. This path is prepended to any file name requested
-+via TFTP protocol, effectively chrooting \fBtftpd\fR to this directory.
-+File names are validated not to escape out of this directory, however
-+administrator may configure such escape using symbolic links.
-+.PP
-+It is in difference of variants of \fBtftpd\fR usually distributed
-+with unix-like systems, which take a list of directories and match
-+file names to start from one of given prefixes or to some random
-+default, when no arguments were given. There are two reasons not to
-+behave in this way: first, it is inconvenient, clients are not expected
-+to know something about layout of filesystem on server host.
-+And second, TFTP protocol is not a tool for browsing of server's filesystem,
-+it is just an agent allowing to boot dumb clients. 
-+.PP
-+In the case when \fBtftpd\fR is used together with
-+\fBrarpd\fR(8),
-+tftp directories in these services should coincide and it is expected
-+that each client booted via TFTP has boot image corresponding
-+its IP address with an architecture suffix following Sun Microsystems
-+conventions. See 
-+\fBrarpd\fR(8)
-+for more details.
-+.SH "SECURITY"
-+.PP
-+TFTP protocol does not provide any authentication.
-+Due to this capital flaw \fBtftpd\fR is not able to restrict
-+access to files and will allow only publically readable
-+files to be accessed. Files may be written only if they already
-+exist and are publically writable.
-+.PP
-+Impact is evident, directory exported via TFTP \fBmust not\fR
-+contain sensitive information of any kind, everyone is allowed
-+to read it as soon as a client is allowed. Boot images do not contain
-+such information as rule, however you should think twice before
-+publishing f.e. Cisco IOS config files via TFTP, they contain
-+\fBunencrypted\fR passwords and may contain some information
-+about the network, which you were not going to make public.
-+.PP
-+The \fBtftpd\fR server should be executed by \fBinetd\fR
-+with dropped root privileges, namely with a user ID giving minimal
-+access to files published in tftp directory. If it is executed
-+as superuser occasionally, \fBtftpd\fR drops its UID and GID
-+to 65534, which is most likely not the thing which you expect.
-+However, this is not very essential; remember, only files accessible
-+for everyone can be read or written via TFTP.
-+.SH "SEE ALSO"
-+.PP
-+\fBrarpd\fR(8),
-+\fBtftp\fR(1),
-+\fBinetd\fR(8).
-+.SH "HISTORY"
-+.PP
-+The \fBtftpd\fR command appeared in 4.2BSD. The source in iputils
-+is cleaned up both syntactically (ANSIized) and semantically (UDP socket IO).
-+.PP
-+It is distributed with iputils mostly as good demo of an interesting feature
-+(MSG_CONFIRM) allowing to boot long images by dumb clients
-+not answering ARP requests until they are finally booted.
-+However, this is full functional and can be used in production.
-+.SH "AVAILABILITY"
-+.PP
-+\fBtftpd\fR is part of \fIiputils\fR package
-+and the latest versions are  available in source form at
-+http://www.skbuff.net/iputils/iputils-current.tar.bz2.
-diff -Naur /dev/null iputils-s20101006/doc/traceroute6.8
---- /dev/null	1969-12-31 19:00:00.000000000 -0500
-+++ iputils-s20101006/doc/traceroute6.8	2011-01-08 20:09:52.114781859 -0500
-@@ -0,0 +1,42 @@
-+.\" This manpage has been automatically generated by docbook2man 
-+.\" from a DocBook document.  This tool can be found at:
-+.\" <http://shell.ipoline.com/~elmert/comp/docbook2X/> 
-+.\" Please send any bug reports, improvements, comments, patches, 
-+.\" etc. to Steve Cheng <steve@ggi-project.org>.
-+.TH "TRACEROUTE6" "8" "08 January 2011" "iputils-101006" "System Manager's Manual: iputils"
-+.SH NAME
-+traceroute6 \- traces path to a network host
-+.SH SYNOPSIS
-+
-+\fBtraceroute6\fR [\fB-dnrvV\fR] [\fB-i \fIinterface\fB\fR] [\fB-m \fImax_ttl\fB\fR] [\fB-p \fIport\fB\fR] [\fB-q \fImax_probes\fB\fR] [\fB-s \fIsource\fB\fR] [\fB-w \fIwait time\fB\fR] \fB\fIdestination\fB\fR [\fB\fIsize\fB\fR]
-+
-+.SH "DESCRIPTION"
-+.PP
-+Description can be found in 
-+\fBtraceroute\fR(8),
-+all the references to IP replaced to IPv6. It is needless to copy
-+the description from there.
-+.SH "SEE ALSO"
-+.PP
-+\fBtraceroute\fR(8),
-+\fBtracepath\fR(8),
-+\fBping\fR(8).
-+.SH "HISTORY"
-+.PP
-+This program has long history. Author of \fBtraceroute\fR
-+is Van Jacobson and it first appeared in 1988. This clone is
-+based on a port of \fBtraceroute\fR to IPv6 published
-+in NRL IPv6 distribution in 1996. In turn, it was ported
-+to Linux by Pedro Roque. After this it was kept in sync by    
-+Alexey Kuznetsov
-+<kuznet@ms2.inr.ac.ru>. And eventually entered
-+\fBiputils\fR package.
-+.SH "SECURITY"
-+.PP
-+\fBtracepath6\fR requires CAP_NET_RAWIO capability
-+to be executed. It is safe to be used as set-uid root.
-+.SH "AVAILABILITY"
-+.PP
-+\fBtraceroute6\fR is part of \fIiputils\fR package
-+and the latest versions are  available in source form at
-+http://www.skbuff.net/iputils/iputils-current.tar.bz2.
diff --git a/core/iputils/permission-fix.patch b/core/iputils/permission-fix.patch
deleted file mode 100644
index c47636f84..000000000
--- a/core/iputils/permission-fix.patch
+++ /dev/null
@@ -1,15 +0,0 @@
---- traceroute-1.4a12/Makefile.in.old	2000-11-23 21:05:29.000000000 +0100
-+++ traceroute-1.4a12/Makefile.in	2008-09-27 20:04:30.000000000 +0200
-@@ -90,10 +90,10 @@
- 	sed -e 's/.*/char version[] = "&";/' $(srcdir)/VERSION > $@
- 
- install: force
--	$(INSTALL) -m 4555 -o root -g bin traceroute $(DESTDIR)$(BINDEST)
-+	$(INSTALL) -m 4555 -o root -g root traceroute $(DESTDIR)$(BINDEST)
- 
- install-man: force
--	$(INSTALL) -m 444 -o bin -g bin traceroute.8 $(DESTDIR)$(MANDEST)/man8
-+	$(INSTALL) -m 644 -o root -g root traceroute.8 $(DESTDIR)$(MANDEST)/man8
- 
- lint: $(GENSRC) force
- 	lint -hbxn $(SRC) | \