Bug#673436: [patch], suffixes(7): Warnings from grotty
tags 673436 fixed-upstream thanks Thanks Bjarni. I've applied your patch. Cheers, Michael On Sat, May 19, 2012 at 5:41 AM, Bjarni Ingi Gislason bjarn...@rhi.hi.is wrote: Package: manpages Version: 3.27-1 Severity: minor Tags: patch [Also sent to upstream, linux-man and mtk.manpages] From man ... (nroff ...): grotty:standard input (standard input):1763: character above first line discarded grotty:standard input (standard input):2688: character above first line discarded grotty:standard input (standard input):3286: character above first line discarded The culprit is Dl 0 - (vertical line) where is one line (40 nroff units) to long. Or there is a bug in grotty. nroff or tbl makes an empty line where a page break is. Patch: --- suffixes.7 2012-04-26 22:58:40.0 + +++ suffixes.7.new 2012-05-18 01:22:54.0 + @@ -35,6 +35,9 @@ .\ FIXME, mtk, May 2007: rendering this page yields the error: .\ grotty:suffixes.7:1725: character above first line discarded .\ +.\ nroff (man) (or tbl) needs a long page to avoid warnings +.\ from grotty (at imagined page breaks). Bug in grotty? +.if n .pl 1000v .TH SUFFIXES 7 2000-11-16 Linux Linux Programmer's Manual .SH NAME suffixes \- list of file suffixes -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: i386 (i586) Kernel: Linux 2.6.32-45 Locale: LANG=is_IS, LC_CTYPE=is_IS (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash manpages depends on no packages. manpages recommends no packages. Versions of packages manpages suggests: ii man-db [man-browser] 2.5.7-8 on-line manual pager -- no debconf information -- Bjarni I. Gislason -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673873: netdevice(7): Line in table too long
tags 673873 fixed-upstream
thanks
Thanks Bjarni. Applied upstream (3.42).
On Tue, May 22, 2012 at 7:45 AM, Bjarni Ingi Gislason
bjarn...@rhi.hi.is wrote:
Package: manpages
Version: 3.27-1
Severity: minor
Tags: patch
From man ... (nroff -ww ...):
nroff: netdevice.7: warning: around line 98: table wider than line width
No right adjustment in text blocks in tables.
Patch:
--- netdevice.7 2012-04-26 22:58:40.0 +
+++ netdevice.7.new 2012-05-21 15:32:56.0 +
@@ -91,6 +91,8 @@
Get or set the active flag word of the device.
.I ifr_flags
contains a bit mask of the following values:
+.\ Do not right adjust text blocks in tables
+.na
.TS
tab(:);
c s
@@ -102,7 +104,9 @@
IFF_LOOPBACK:Interface is a loopback interface.
IFF_POINTOPOINT:Interface is a point-to-point link.
IFF_RUNNING:Resources allocated.
-IFF_NOARP:No arp protocol, L2 destination address not set.
+IFF_NOARP:T{
+No arp protocol, L2 destination address not set.
+T}
IFF_PROMISC:Interface is in promiscuous mode.
IFF_NOTRAILERS:Avoid use of trailers.
IFF_ALLMULTI:Receive all multicast packets.
@@ -120,6 +124,7 @@
.TE
+.ad
Setting the active flag word is a privileged operation, but any
process may read it.
.TP
-- System Information:
Debian Release: 6.0.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable')
Architecture: i386 (i586)
Kernel: Linux 2.6.32-45
Locale: LANG=is_IS, LC_CTYPE=is_IS (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
manpages depends on no packages.
manpages recommends no packages.
Versions of packages manpages suggests:
ii man-db [man-browser] 2.5.7-8 on-line manual pager
-- no debconf information
--
Bjarni I. Gíslason
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of The Linux Programming Interface; http://man7.org/tlpi/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673873: netdevice(7): Line in table too long
tags 673873 fixed-upstream
thanks
Thanks Bjarni. Applied upstream (3.42).
On Tue, May 22, 2012 at 7:45 AM, Bjarni Ingi Gislason
bjarn...@rhi.hi.is wrote:
Package: manpages
Version: 3.27-1
Severity: minor
Tags: patch
From man ... (nroff -ww ...):
nroff: netdevice.7: warning: around line 98: table wider than line width
No right adjustment in text blocks in tables.
Patch:
--- netdevice.7 2012-04-26 22:58:40.0 +
+++ netdevice.7.new 2012-05-21 15:32:56.0 +
@@ -91,6 +91,8 @@
Get or set the active flag word of the device.
.I ifr_flags
contains a bit mask of the following values:
+.\ Do not right adjust text blocks in tables
+.na
.TS
tab(:);
c s
@@ -102,7 +104,9 @@
IFF_LOOPBACK:Interface is a loopback interface.
IFF_POINTOPOINT:Interface is a point-to-point link.
IFF_RUNNING:Resources allocated.
-IFF_NOARP:No arp protocol, L2 destination address not set.
+IFF_NOARP:T{
+No arp protocol, L2 destination address not set.
+T}
IFF_PROMISC:Interface is in promiscuous mode.
IFF_NOTRAILERS:Avoid use of trailers.
IFF_ALLMULTI:Receive all multicast packets.
@@ -120,6 +124,7 @@
.TE
+.ad
Setting the active flag word is a privileged operation, but any
process may read it.
.TP
-- System Information:
Debian Release: 6.0.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable')
Architecture: i386 (i586)
Kernel: Linux 2.6.32-45
Locale: LANG=is_IS, LC_CTYPE=is_IS (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
manpages depends on no packages.
manpages recommends no packages.
Versions of packages manpages suggests:
ii man-db [man-browser] 2.5.7-8 on-line manual pager
-- no debconf information
--
Bjarni I. Gíslason
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of The Linux Programming Interface; http://man7.org/tlpi/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660479: Debian bug 660479
tags 660479 fixed-upstream thanks I've applied the patch at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660479#109 for upstream 3.41. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540872: clock_gettime(2): Document that real-time processes want CLOCK_MONOTONIC, not CLOCK_REALTIME
On Sun, Apr 29, 2012 at 10:21 AM, Simon Paillard spaill...@debian.org wrote: tags + upstream thanks Hi, On Mon, Aug 10, 2009 at 11:30:34AM -0700, Josh Triplett wrote: Package: manpages Version: 3.22-1 Severity: wishlist Developers of real-time programs (programs using real-time scheduling and/or expecting low latency) sometimes see CLOCK_REALTIME and think they want to use that, when they almost certainly don't. Please consider adding some clarification that the real-time of CLOCK_REALTIME refers to wall-clock time (as opposed to CPU or process time, for instance) and that developers of real-time applications want to use CLOCK_MONOTONIC. Michael Kerrisk improved clock_getres.2 in manpages 3.40: .B CLOCK_MONOTONIC Clock that cannot be set and represents monotonic time since some unspecified starting point. +This clock is not affected by discontinuous jumps in the system time +(e.g., if the system administrator manually changes the clock), +but is affected by the incremental adjustments performed by +.BR adjtime (2) +and NTP. Maybe one can add (please proofread my english): This clock allow to precisely measuring time elapsed, for use in real-time programs. http://pubs.opengroup.org/onlinepubs/009604599/functions/clock_getres.html Simon, would that text not better apply to CLOCK_MONOTONIC_RAW? -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564874: manpages: Please ship ld.so manpage
On Mon, Apr 30, 2012 at 5:42 AM, Simon Paillard spaill...@debian.org wrote: reassign 564874 manpages,libc-bin thanks On Tue, Jan 12, 2010 at 11:38:15AM +, Andrew Suffield wrote: Package: manpages Version: 3.23-1 Severity: normal The current ld.so manpage is from glibc. It's gratuitously out of date and just plain wrong in places. The one in manpages is current and reasonably accurate. Please arrange for the version from manpages to be shipped instead of the glibc version. I concur, but we need agreement of libc-bin maintainers. http://people.debian.org/~spaillard/libc-or-manpages/ld.so.8.libc-bin http://people.debian.org/~spaillard/libc-or-manpages/ld.so.8.manpages-linux The manpages-linux version provides more environment variables: LD_AUDIT LD_DYNAMIC_WEAK LD_HWCAP_MASK LD_ORIGIN_PATH LD_POINTER_GUARD LD_SHOW_AUXV LD_USE_LOAD_BIAS (but no more LD_ASSUME_KERNEL). For info: Jonathan Neider, CCed was looking at integrating those pieces of the Debian libc-bin page that were missing from the upstream man-pages ld.so.8 page. We did upstream one piece already, but I'm not sure what Jonathan's current plans are for further work. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621075: manpages-dev: rtnetlink documents wrong return type for RTA_PAYLOAD
RTA_PAYLOAD casts the expression to int, at least in 2.6.38.2. It's documented as unsinged int. Trivial patch included. Even since 2.6.11: http://lxr.linux.no/#linux+v2.6.11/include/linux/rtnetlink.h#L120 I'm missing it. How is it concluded that the result is cast to (int)? Looking at the header file, one half of a larrger expression is cast to (int), but not the whole expression. Cheers. Michael The kernel header probably ought be modified not to perform this rather questionable cast, in which case RTA_LENGTH()'s result type would be inherited, but that's an issue for another bug. diff -ur manpages-pristine//man3/rtnetlink.3 manpages-3.27//man3/rtnetlink.3 --- manpages-pristine//man3/rtnetlink.3 2011-04-06 05:13:34.137124578 -0500 +++ manpages-3.27//man3/rtnetlink.3 2011-04-06 05:13:55.033179278 -0500 @@ -23,7 +23,7 @@ .sp .BI void *RTA_DATA(struct rtattr * rta ); .sp -.BI unsigned int RTA_PAYLOAD(struct rtattr * rta ); +.BI int RTA_PAYLOAD(struct rtattr * rta ); .sp .BI struct rtattr *RTA_NEXT(struct rtattr * rta \ , unsigned int rtabuflen ); Patch forwarded on the linux-man mailing list, thanks. -- Simon Paillard -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#156154: Patch
tags 156154 fixed-upstream thanks Fixed in upstream man-pages-3.40 Cheers, Michael On Wed, Feb 2, 2011 at 3:41 AM, Eugen Dedu eugen.d...@pu-pm.univ-fcomte.fr wrote: tag 156154 - help + patch thanks Here is the patch to fix this bug. This bug appears with 3.27-1. -- Eugen Dedu http://eugen.dedu.free.fr -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538641: manpages: fixes to utf-8.7
tags 538641 fixed-upstream thanks Applied for upstream 3.41. Cheers, Michael On Sun, Jul 26, 2009 at 11:56 AM, brian m. carlson sand...@crustytoothpaste.ath.cx wrote: Package: manpages Version: 3.21-1 Severity: normal Tags: patch I've attached a patch to utf-8.7. It clarifies that 0xc0 and 0xc1 are not valid in any UTF-8 encoding[0], and it also references RFC 3629 instead of RFC 2279. [0] In order to have 0xc0, you'd have to have a two-byte encoding with all the data bits zero in the first byte (and thus only six bits of data), which would be an ASCII character encoded in the non-shortest form. Similarly with 0xc1. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash manpages depends on no packages. manpages recommends no packages. Versions of packages manpages suggests: ii konqueror [man-browser] 4:4.2.4-1 KDE 4's advanced file manager, web ii man-db [man-browser] 2.5.5-3 on-line manual pager -- no debconf information -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBAgAGBQJKa5urAAoJEL9TXYEfUvaLIokP/As/Hb6tqChVoIMGyfjESsQ9 2+mujSh6IF+dPQsklKnUcNeIeySOW9KbwShipea0X6M2CPAMqUzQmtaYWJ3r4U0y 2TLgKduAb6HC7H3dvLIy+iC4ePVZ6mi/rxqOtm+b2X6AEzMLSAQz5fgPw9WlpPmJ FW2qEMUYrRpZZapEQ1db3zrJ+DmzPExhg7ptppN7F2nPbMKcrJZvbfFwGRpzsJwB mLWGLKCqWL/ee12jmDaaVOqwv0m3+tfUHwo6ZsrYvnA3K5jqNFV27DpJv6e4PEZZ lTz6G3UkwWAFXXDq2PF1hNv8yQRFD0GQD5639dr9MairyrrLSGP3VwK+VgO5FWTm Os1AvJ0wUkHABaBuP98XWxEAGsdmyJa9v/IE5gZlJgjCQhbBk24/tUF1nYPX5Djk E2yqxEv8/8WHhYybEK43EKEpNsscUYxeHexAR5G6NDGJdprzuCFwidwwBsNkfH9p M2PwvbvyrVu9n3BpMI43z4nCK5i9JB4WVF6oteM61+GuybynTnvqX7twg6Nk5TDF vdoU3F7Q/IksmkeUjlf00z0N/y22/OQULJOf3InJInwej4KCdwd/i+dp4AD7tpqm q5g+2STGAFuF0sYPsEtK5xgH1bMv4WmmxhSjbzW/v5NYvDoZCf4Ml3j8WzQUt3kW jnbHbbgSUEmMP3gNeFaf =4cZN -END PGP SIGNATURE- -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540872: clock_gettime(2): Document that real-time processes want CLOCK_MONOTONIC, not CLOCK_REALTIME
tags 540872 fixed-upstream thanks Hi Josh! On Mon, Apr 30, 2012 at 7:15 AM, Josh Triplett j...@joshtriplett.org wrote: On Sun, Apr 29, 2012 at 10:40:48PM +1200, Michael Kerrisk (man-pages) wrote: On Sun, Apr 29, 2012 at 10:21 AM, Simon Paillard spaill...@debian.org wrote: tags + upstream thanks Hi, On Mon, Aug 10, 2009 at 11:30:34AM -0700, Josh Triplett wrote: Package: manpages Version: 3.22-1 Severity: wishlist Developers of real-time programs (programs using real-time scheduling and/or expecting low latency) sometimes see CLOCK_REALTIME and think they want to use that, when they almost certainly don't. Please consider adding some clarification that the real-time of CLOCK_REALTIME refers to wall-clock time (as opposed to CPU or process time, for instance) and that developers of real-time applications want to use CLOCK_MONOTONIC. Michael Kerrisk improved clock_getres.2 in manpages 3.40: .B CLOCK_MONOTONIC Clock that cannot be set and represents monotonic time since some unspecified starting point. +This clock is not affected by discontinuous jumps in the system time +(e.g., if the system administrator manually changes the clock), +but is affected by the incremental adjustments performed by +.BR adjtime (2) +and NTP. Maybe one can add (please proofread my english): This clock allow to precisely measuring time elapsed, for use in real-time programs. http://pubs.opengroup.org/onlinepubs/009604599/functions/clock_getres.html Simon, would that text not better apply to CLOCK_MONOTONIC_RAW? Probably, yes. Ideally, I'd also like to see something like this added to the description of CLOCK_REALTIME, to help avert a common trap people fall into: 'The realtime in the name CLOCK_REALTIME refers to wall-clock time, not to suitability for realtime (latency-sensitive) applications. Such applications generally want to use CLOCK_MONOTONIC or CLOCK_MONOTONIC_RAW.' How about doing this in a different way. Instead of pointing the reader at CLOCK_MONOTONIC*, let's be more explicit about what CLOCK_REALTIME is, so that it's evident to the designer of a realtime application that they don't want this clock. [[ .TP .B CLOCK_REALTIME System-wide clock that measures real (i.e., wall-clock) time. Setting this clock requires appropriate privileges. This clock is affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the clock), and by the incremental adjustments performed by .BR adjtime (2) and NTP. ]] Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609033: manpages-dev: please improve isgreater(3) description
On Wed, Apr 25, 2012 at 1:50 AM, Vincent Lefevre vinc...@vinc17.net wrote: On 2012-04-24 22:13:11 +1200, Michael Kerrisk (man-pages) wrote: Vincent, On Thu, Jan 6, 2011 at 5:38 AM, Vincent Lefevre vinc...@vinc17.net wrote: The isgreater(3) man page says: The normal relation operations (like , less than) will fail if one of the operands is NaN. This will cause an exception. To avoid this, C99 defines these macros. The macros are guaranteed to evaluate their operands only once. The operands can be of any real floating-point type. It should probably be emphasised that the operands must not be of integer types. The man page already says: The operands can be of any real floating-point type. Is that not emphasis enough? This is a bit ambiguous, as can is not necessarily exclusive. Macros often have a function-like interface: for instance, if a real floating-point type is expected and the user provides an integer, then the integer will automatically be converted to a real floating-point type. This is not the case here. Also, the beginning of the paragraph is a bit like saying that isgreater is a safe replacement for to avoid a possible exception. However, while with the user doesn't need to take care of the types, this is not the case for isgreater. For instance, in order to avoid a possible exception, one should do the following replacements: With double x int i; replace x i x 0 by isgreater (x, (double) i) isgreater (x, 0.0) Users may easily forget to do the change on the second argument. So, how about the following replacement text: [[ The macros are guaranteed to evaluate their arguments only once. The arguments must be of real floating-point type (note: do not pass integer values as arguments to these macros, since the arguments will *not* be promoted to real-floating types). ]] ? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609033: manpages-dev: please improve isgreater(3) description
tags 609033 fixed-upstream thanks Vincent, I've made this change for upstream 3.41. Thanks, Michael On Sun, May 6, 2012 at 10:34 AM, Vincent Lefevre vinc...@vinc17.net wrote: On 2012-05-05 23:53:08 +1200, Michael Kerrisk (man-pages) wrote: So, how about the following replacement text: [[ The macros are guaranteed to evaluate their arguments only once. The arguments must be of real floating-point type (note: do not pass integer values as arguments to these macros, since the arguments will *not* be promoted to real-floating types). ]] ? Perfect! Thanks, -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671514: console_codes(4): Some fixes to the manual, table, spaces, ellipsis
tags 671514 fixed-upstream thanks Applied for upstream 3.41. Thanks Bjarni! On Sat, May 5, 2012 at 6:45 AM, Bjarni Ingi Gislason bjarn...@rhi.hi.is wrote: Package: manpages Version: 3.40 Severity: minor Tags: patch Warning from groff: warning: around line 185: table wider than line width After some space fixes, a new warning: warning: around line 496: table wider than line width Length of line extended for the relevant tables. Some periods (full stop) protected, space adjusted Patch is in the attachment. System Information is for the 3.27-1 version -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: i386 (i586) Kernel: Linux 2.6.32-41 Locale: LANG=is_IS, LC_CTYPE=is_IS (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash manpages depends on no packages. manpages recommends no packages. Versions of packages manpages suggests: ii man-db [man-browser] 2.5.7-8 on-line manual pager -- no debconf information -- Bjarni I. Gislason -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662046: manpages-dev: mbsrtowcs() (et al.) is an accident waiting to happen (mbstate_t)
Andreas, So, unless we want every third user of mbsrtowcs(3) to get it wrong, fatally, the documentation should be extended. A sample phrase would be for mbstate_t parameter init, there's no initializer function defined by the standard - the user is required to have done a proper memset() on it. Could you write a short patch for mbsrtowcs(3)? Adding an example of a proper memset() would also be nice. And, which other pages need a similar change? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633505: manpages-dev: fts(3) has inaccurate description of physical vs. logical
On Thu, Aug 23, 2012 at 10:28 PM, Simon Paillard spaill...@debian.org wrote: forwarded 633505 linux-...@vger.kernel.org thanks Hi, On Sun, Jul 10, 2011 at 10:30:43PM +0100, James Youngman wrote: Package: manpages-dev Version: 3.27-1 Severity: minor The descriptions of the effects of FTS_LOGICAL and FTS_PHISICAL in the subsection entitled fts_open() are correct. But the DESCRIPTION section is incorrect. It says: It is possible to walk the hierarchy logically (ignoring symbolic links) or physically (visiting symbolic links), order the walk of the hierarchy or prune and/or revisit portions of the hierarchy. This is not accurate. Symbolic links are never ignored. Here is a clearer description: It is possible to walk the hierarchy logically (visiting the files that symbolic links point to, like find -L) or physically (visiting the symbolic links themselves instead, like find -P) , order the walk of the hierarchy or prune and/or revisit portions of the hierarchy. Thanks for the report James, confirmed by test, patch a bit modified and forwarded upstream. Thanks Simon. Applied for 3.44. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#122383: your bug -- manpages-dev: Ptrace manpage on IA64 is for Linux 2.2
On Mon, Jul 23, 2012 at 11:32 PM, Simon Paillard spaill...@debian.org wrote: tags 122383 +confirmed thanks Hi, On Thu, Dec 22, 2005 at 11:45:21AM +0100, Johan Walles wrote: 2005/12/21, Justin Pryzby justinpry...@users.sourceforge.net: Does this bug still apply in recent manpages packages? Yes. Although not to the same extent as before. PTRACE_GETFPREGS still doesn't exist on ia64. The man page implies it does. It's documented and the documentation says nothing about this function not existing on some platforms. The attached program builds and runs fine on ia32. It doesn't even build on ia64: error: `PTRACE_GETFPREGS' undeclared. Possibly it's broken on other platforms as well, although the ia64 is the only non-mainstream platform I have access to. This doesn't build either on ia64 today, with the same error. And ptrace.2 doesn't mention such kind of function unavailability (except arguments order change for sparc). For 3.44, I've added a note to the page to say that PTRAGE_GETREGS PTRAGE_SETREGS PTRAGE_GETFPREGS PTRAGE_SETFPREGS are not available on all architectures. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675891: manpages: proc(5) /proc/[pid]/stat starttime field has wrong unit
tags 675891 fixed-upstream thanks On Mon, Jun 4, 2012 at 1:20 AM, Frédéric Brière fbri...@fbriere.net wrote: Package: manpages Version: 3.40-0.1 Severity: normal File: /usr/share/man/man5/proc.5.gz The proc(5) description of the starttime field under /proc/[pid]/stat states that the value is expressed in jiffies, but both the code (fs/proc/array.c) and the actual values show that it is really expressed in clock ticks as defined by USER_HZ. The text was once true, but things changed in Linux 2.6 and the page was not updated. I applied the patch below. Cheers, Michael --- a/man5/proc.5 +++ b/man5/proc.5 @@ -824,7 +824,10 @@ Since kernel 2.6.17, this field is no longer maintained, and is hard coded as 0. .TP \fIstarttime\fP %llu (was %lu before Linux 2.6) -The time in jiffies the process started after system boot. +The time the process started after system boot. +In kernels before Linux 2.6, this value was expressed in jiffies. +Since Linux 2.6, the value is expressed in clock ticks (divide by +.IR sysconf(_SC_CLK_TCK) ). .TP \fIvsize\fP %lu Virtual memory size in bytes. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#383296: manpages: nlmsg_pid/nl_pid is *not* the process ID
tags 383296 fixed-upstream
thanks
I've applied the patch below. Will be in upstream 3.42.
Thanks,
Michael
--- a/man7/netlink.7
+++ b/man7/netlink.7
@@ -4,7 +4,7 @@
.\ Based on the original comments from Alexey Kuznetsov
.\ Modified 2005-12-27 by Hasso Tepper ha...@estpak.ee
.\ $Id: netlink.7,v 1.8 2000/06/22 13:23:00 ak Exp $
-.TH NETLINK 7 2012-04-14 Linux Linux Programmer's Manual
+.TH NETLINK 7 2012-07-28 Linux Linux Programmer's Manual
.SH NAME
netlink \- Communication between kernel and userspace (AF_NETLINK)
.SH SYNOPSIS
@@ -139,7 +139,7 @@ struct nlmsghdr {
__u16 nlmsg_type; /* Type of message content. */
__u16 nlmsg_flags; /* Additional flags. */
__u32 nlmsg_seq;/* Sequence number. */
-__u32 nlmsg_pid;/* PID of the sending process. */
+__u32 nlmsg_pid;/* Sender port ID. */
};
.fi
.in
@@ -291,7 +291,7 @@ not equal 0).
struct sockaddr_nl {
sa_family_t nl_family; /* AF_NETLINK */
unsigned short nl_pad; /* Zero. */
-pid_t nl_pid; /* Process ID. */
+pid_t nl_pid; /* Port ID. */
__u32 nl_groups; /* Multicast groups mask. */
};
.fi
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652443: ioprio_get(2): document who==0
[CCing Jens because of the discussion below about IOPRIO_WHO_USER
below; he may have a comment]
[CCing Марк, who independently noted the lack of documentation for
IOPRIO_WHO_PROCESS, who==0 .]
[CCing Colin McCabe who sent other recent fixes for the ioprio_set.2 page]
On Sat, Dec 17, 2011 at 11:26 PM, Kalle Olavi Niemitalo k...@iki.fi wrote:
Package: manpages-dev
Version: 3.32-0.2
Severity: wishlist
File: /usr/share/man/man2/ioprio_get.2.gz
The ioprio_get(2) manual page describes the meanings of the which
and who parameters:
IOPRIO_WHO_PROCESS
who is a process ID identifying a single process.
IOPRIO_WHO_PGRP
who is a process group ID identifying all the members of
a process group.
IOPRIO_WHO_USER
who is a user ID identifying all of the processes that
have a matching real UID.
The manual page should mention that IOPRIO_WHO_PROCESS and
IOPRIO_WHO_PGRP also allow who==0.
Yes.
As implemented in
fs/ioprio.c, who==0 means the calling process or its process
group. The ioprio program in util-linux already uses the
feature. This is worth documenting separately because
e.g. tcsetpgrp does not treat pgrp==0 in that way.
Agreed, this should be documented since various APIs interpret pgrp==0
differently. Some (e.g., killpg(2)) are like this syscall, others are
not.
For IOPRIO_WHO_USER, the situation is more complex: who==0 means
the root user in ioprio_set but the current user (I think the
real UID of the calling process) in ioprio_get. (That
inconsistency might even be a bug.)
So, I'm not sure I'm following the kernel code too well here...
@Jens, your comments would be very welovem.
In ioprio_get() (Linux 3.5 kernel source file fs/ioprio.c), I see the following:
case IOPRIO_WHO_USER:
uid = make_kuid(current_user_ns(), who);
if (!who)
user = current_user();
else
user = find_user(uid);
if (!user)
break;
do_each_thread(g, p) {
if (!uid_eq(task_uid(p), user-uid))
continue;
tmpio = get_task_ioprio(p);
if (tmpio 0)
continue;
if (ret == -ESRCH)
ret = tmpio;
else
ret = ioprio_best(ret, tmpio);
} while_each_thread(g, p);
if (who)
free_uid(user);
break;
In ioprio_set(), I see:
case IOPRIO_WHO_USER:
uid = make_kuid(current_user_ns(), who);
if (!uid_valid(uid))
break;
if (!who)
user = current_user();
else
user = find_user(uid);
if (!user)
break;
do_each_thread(g, p) {
if (!uid_eq(task_uid(p), uid))
continue;
ret = set_task_ioprio(p, ioprio);
if (ret)
goto free_uid;
} while_each_thread(g, p);
free_uid:
if (who)
free_uid(user);
break;
This suggests to me that you are right Kalle, in your interpretation
of who==0 for the IOPRIO_WHO_USER, since ioprio_get() uses
current_iser()-uid for its scan while ioprio_get() uses the UID
returned by make_kuid() (So, to be precise, I think who==0 in this
case means the UID of the uer who is thye super user in this user
namespace). If that's correct, it does of course need to be
documented. I'd be happy to get confirmation from Jens on this point.
I suppose that the differing meaning of who==0 for IOPRIO_WHO_USER in
ioprio_get() versus ioprio_set() is by design. But if so, like you
Kalle, I agree that it's a design point that is likely to surprise
users (and surprises here might have security implications). Again,
I'd like to get input from Jens.
In the meantime, I've applied the patch below to cover the other two cases.
Thanks,
Michael
--- a/man2/ioprio_set.2
+++ b/man2/ioprio_set.2
@@ -56,10 +56,16 @@ is interpreted, and has one of the following values:
.B IOPRIO_WHO_PROCESS
.I who
is a process ID or thread ID identifying a single process or thread.
+If
+.I who
+is 0, then operate on the calling thread.
.TP
.B IOPRIO_WHO_PGRP
.I who
is a process group ID identifying all the members of a process group.
Bug#604928: stat.2: EOVERFLOW not only for st_size; bit/byte confusion
tags 604928 fixed-upstream thanks On Tue, Oct 23, 2012 at 1:55 AM, Simon Paillard spaill...@debian.org wrote: Control: -1 found 3.42-1 On Thu, Nov 25, 2010 at 03:08:30PM +0100, Lionel Elie Mamane wrote: stat(2) says: ERRORS (...) EOVERFLOW (stat()) path refers to a file whose size cannot be represented in the type off_t. This can occur when an application compiled on a 32-bit platform without -D_FILE_OFFSET_BITS=64 calls stat() on a file whose size exceeds (231)-1 bits. 1) It would seem to me that the condition for this to occur would be a file whose size exceeds (231)-1 *bytes*, not bits. Still applicable to manpages 3.43. 2) I got this for an overflow on st_ino (64 bit kernel, 32 bit userland, CIFS mount of a Windows-served share). Confirmed with OpenGroup: http://pubs.opengroup.org/onlinepubs/009695399/functions/stat.html [EOVERFLOW] The file size in bytes or the number of blocks allocated to the file or the file serial number cannot be represented correctly in the structure pointed to by buf. egblic: sysdeps/unix/sysv/linux/xstatconv.c it can be st_ino, st_size or st_blocks So I'd suggest this text become something along the lines of: path or fd refers to a file for which the value of a field of the stat structure cannot be represented in its type. This usually occurs with applications compiled on a 32-bit platform without -D_FILE_OFFSET_BITS=64. The most common occurrence is when such an application calls stat() on a file whose size exceeds (231)-1 bytes; but it can also occur e.g. for the st_ino field, e.g. when such an application is run on a 64 bit kernel. An other proposal attached. Thanks Simon. I applied a modified version of your patch, as below. Cheers, Michael --- a/man2/stat.2 +++ b/man2/stat.2 @@ -341,17 +341,23 @@ A component of the path prefix of is not a directory. .TP .B EOVERFLOW -.RB ( stat ()) .I path -refers to a file whose size cannot be represented in the type -.IR off_t . -This can occur when an application compiled on a 32-bit platform without +or +.I fd +refers to a file whose size, inode number, +or number of blocks cannot be represented in, respectively, the types +.IR off_t , +.IR ino_t , +or +.IR blkcnt_t . +This error can occur when, for example, +an application compiled on a 32-bit platform without .I -D_FILE_OFFSET_BITS=64 calls .BR stat () on a file whose size exceeds .I (131)-1 -bits. +bytes. .SH CONFORMING TO These system calls conform to SVr4, 4.3BSD, POSIX.1-2001. .\ SVr4 documents additional -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610036: manpages: update manpage for resolv.conf for IPv6 support
tags 610036 fixed-upstream thanks On Thu, Oct 25, 2012 at 2:14 AM, Simon Paillard spaill...@debian.org wrote: Control: -1 tag +patch Hi, On Sat, Jun 09, 2012 at 07:43:46PM +0200, Witold Baryluk wrote: On 06-09 15:36, Simon Paillard wrote: On Sat, Jan 15, 2011 at 12:52:17AM +0100, Witold Baryluk wrote: [..] I today discovered undocumented feature of resolv.conf Nameply nameserver can be a IPv6 address! Current manpage (implicitly) says only IPv4 is supported. == nameserver 2001:470:20::2 nameserver 149.156.82.205 Well, not documented indeed, I wonder if it is really necessary to explicit this. Well, many programs often use slightly different notation for IPv4 and IPv6, like putting IPv6 in square brackets (this is for example a case for hosts.allow/hosts.deny syntax). Code (function inet_pton6) says it conforms to RFC 1884: 2.2 Text Representation of Addresses http://tools.ietf.org/html/rfc1884#page-4 In the same time, inet_pton manpages says it's RFC2373 (a small update, not changing IPv6 address string format): http://tools.ietf.org/html/rfc2373#section-2.2 Patch sent upstream. It also needs documenting, in case in the future glibc would allow changing default port 53 to something else. One could think that it will be something like 'nameserver 10.0.1.1:5353', but it will not work in ipv6 case. So probably a keyword-like syntax 'nameserver 10.0.1.1 port 5353', or squere brackets notations (like in URLs), will be needed. Let's keep future evolutions for future documentation :) Some tools like network-manager, resolvconf, rdnssd, openvpn, etc. sometimes need to write to resolv.conf and until it is documented and stabilized, it cannot be done safely. PS: btw, I've checked v4/v6 in this manpage, glibc happens to not implement sortlist for IPv6 addresses. Simon, I've applied a slightly modified version of your patch, for upstream 3.45. Cheers, Michael --- a/man5/resolv.conf.5 +++ b/man5/resolv.conf.5 @@ -42,8 +42,9 @@ and the domain search path is constructed from the domain name. The different configuration options are: .TP \fBnameserver\fP Name server IP address -Internet address (in dot notation) of a name server -that the resolver should query. +Internet address of a name server that the resolver should query, +either an IPv4 address (in dot notation), +or an IPv6 address in colon (and possibly dot) notation as per RFC 2373. Up to .B MAXNS (currently 3, see \fIresolv.h\fP) name servers may be listed, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652443: ioprio_get(2): document who==0
Hi Jens,
Would you be able to comment please...
Thanks,
Michael
On Sun, Jul 29, 2012 at 8:32 AM, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
[CCing Jens because of the discussion below about IOPRIO_WHO_USER
below; he may have a comment]
[CCing Марк, who independently noted the lack of documentation for
IOPRIO_WHO_PROCESS, who==0 .]
[CCing Colin McCabe who sent other recent fixes for the ioprio_set.2 page]
On Sat, Dec 17, 2011 at 11:26 PM, Kalle Olavi Niemitalo k...@iki.fi wrote:
Package: manpages-dev
Version: 3.32-0.2
Severity: wishlist
File: /usr/share/man/man2/ioprio_get.2.gz
The ioprio_get(2) manual page describes the meanings of the which
and who parameters:
IOPRIO_WHO_PROCESS
who is a process ID identifying a single process.
IOPRIO_WHO_PGRP
who is a process group ID identifying all the members of
a process group.
IOPRIO_WHO_USER
who is a user ID identifying all of the processes that
have a matching real UID.
The manual page should mention that IOPRIO_WHO_PROCESS and
IOPRIO_WHO_PGRP also allow who==0.
Yes.
As implemented in
fs/ioprio.c, who==0 means the calling process or its process
group. The ioprio program in util-linux already uses the
feature. This is worth documenting separately because
e.g. tcsetpgrp does not treat pgrp==0 in that way.
Agreed, this should be documented since various APIs interpret pgrp==0
differently. Some (e.g., killpg(2)) are like this syscall, others are
not.
For IOPRIO_WHO_USER, the situation is more complex: who==0 means
the root user in ioprio_set but the current user (I think the
real UID of the calling process) in ioprio_get. (That
inconsistency might even be a bug.)
So, I'm not sure I'm following the kernel code too well here...
@Jens, your comments would be very welovem.
In ioprio_get() (Linux 3.5 kernel source file fs/ioprio.c), I see the
following:
case IOPRIO_WHO_USER:
uid = make_kuid(current_user_ns(), who);
if (!who)
user = current_user();
else
user = find_user(uid);
if (!user)
break;
do_each_thread(g, p) {
if (!uid_eq(task_uid(p), user-uid))
continue;
tmpio = get_task_ioprio(p);
if (tmpio 0)
continue;
if (ret == -ESRCH)
ret = tmpio;
else
ret = ioprio_best(ret, tmpio);
} while_each_thread(g, p);
if (who)
free_uid(user);
break;
In ioprio_set(), I see:
case IOPRIO_WHO_USER:
uid = make_kuid(current_user_ns(), who);
if (!uid_valid(uid))
break;
if (!who)
user = current_user();
else
user = find_user(uid);
if (!user)
break;
do_each_thread(g, p) {
if (!uid_eq(task_uid(p), uid))
continue;
ret = set_task_ioprio(p, ioprio);
if (ret)
goto free_uid;
} while_each_thread(g, p);
free_uid:
if (who)
free_uid(user);
break;
This suggests to me that you are right Kalle, in your interpretation
of who==0 for the IOPRIO_WHO_USER, since ioprio_get() uses
current_iser()-uid for its scan while ioprio_get() uses the UID
returned by make_kuid() (So, to be precise, I think who==0 in this
case means the UID of the uer who is thye super user in this user
namespace). If that's correct, it does of course need to be
documented. I'd be happy to get confirmation from Jens on this point.
I suppose that the differing meaning of who==0 for IOPRIO_WHO_USER in
ioprio_get() versus ioprio_set() is by design. But if so, like you
Kalle, I agree that it's a design point that is likely to surprise
users (and surprises here might have security implications). Again,
I'd like to get input from Jens.
In the meantime, I've applied the patch below to cover the other two cases.
Thanks,
Michael
--- a/man2/ioprio_set.2
+++ b/man2/ioprio_set.2
@@ -56,10 +56,16 @@ is interpreted, and has one of the following values:
.B IOPRIO_WHO_PROCESS
Bug#674051: rtnetlink(7): Line in table too long
tags 674051 fixed-upstream thanks On Wed, May 23, 2012 at 6:53 AM, Bjarni Ingi Gislason bjarn...@rhi.hi.is wrote: Package: manpages Version: 3.27-1 Severity: minor Tags: patch From man ... (nroff -ww ...): nroff: rtnetlink.7: warning: around line 415: table wider than line width Column gutter reduced to fit line length Right adjustment in text blocks removed in tables Some header made centered in tables One table put on same page Patch: Thanks Bjarni. Applied for upstream 3.42. Cheers, Michael --- rtnetlink.7 2012-04-26 22:58:40.0 + +++ rtnetlink.7.new 2012-05-21 22:35:12.0 + @@ -81,9 +81,10 @@ is the unique interface index, .I ifi_change is reserved for future use and should be always set to 0x. +.na .TS tab(:); -c +c s s l l l. Routing attributes rta_type:value type:description @@ -99,6 +100,7 @@ see below T}:Interface Statistics. .TE +.ad .sp The value type for IFLA_STATS is \fIstruct net_device_stats\fP. .TP @@ -145,7 +147,7 @@ for a permanent address set by the user and other undocumented flags. .TS tab(:); -c +c s s l l l. Attributes rta_type:value type:description @@ -195,6 +197,7 @@ unsigned int rtm_flags; }; .fi +.na .TS tab(:); l l. @@ -219,6 +222,8 @@ refer to an external resolver (not implemented) T} .TE +.ad +.na .TS tab(:); l l. @@ -232,6 +237,7 @@ RTPROT_BOOT:during boot RTPROT_STATIC:by the administrator .TE +.ad Values larger than .B RTPROT_STATIC @@ -244,6 +250,7 @@ .I rtm_scope is the distance to the destination: +.na .TS tab(:); l l. @@ -255,6 +262,7 @@ RT_SCOPE_HOST:route on the local host RT_SCOPE_NOWHERE:destination doesn't exist .TE +.ad The values between .B RT_SCOPE_UNIVERSE @@ -265,6 +273,7 @@ The .I rtm_flags have the following meanings: +.na .TS tab(:); l l. @@ -274,6 +283,7 @@ RTM_F_CLONED:route is cloned from another route RTM_F_EQUALIZE:a multipath equalizer (not yet implemented) .TE +.ad .I rtm_table specifies the routing table @@ -290,9 +300,11 @@ .B RT_TABLE_UNSPEC and .BR RT_TABLE_DEFAULT . +.\ Keep table on same page +.bp +1 .TS tab(:); -c +c s s l l l. Attributes rta_type:value type:description @@ -410,8 +422,8 @@ .fi .TS tab(:); -c -l l l. +c s s +l2 l2 l. Attributes rta_type:value type:Description _ -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: i386 (i586) Kernel: Linux 2.6.32-45 Locale: LANG=is_IS, LC_CTYPE=is_IS (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash manpages depends on no packages. manpages recommends no packages. Versions of packages manpages suggests: ii man-db [man-browser] 2.5.7-8 on-line manual pager -- no debconf information -- Bjarni I. Gislason -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673875: netlink(7): Line in table is too long
tags 673875 fixed-upstream
thanks
On Tue, May 22, 2012 at 7:48 AM, Bjarni Ingi Gislason
bjarn...@rhi.hi.is wrote:
Package: manpages
Version: 3.27-1
Severity: minor
Tags: patch
From man ... (nroff -ww ...):
nroff: netlink.7: warning: around line 195: table wider than line width
Hozizontal line incorparated into table.
No right adjustment of text blocks in tables.
Thanks Bjarni. Applied for upstream 3.42.
Cheers,
Michael
--- netlink.7 2012-04-26 22:58:40.0 +
+++ netlink.7.new 2012-05-21 16:31:43.0 +
@@ -169,14 +169,12 @@
.BR rtnetlink (7)
for
.BR NETLINK_ROUTE .
-
-Standard flag bits in
-.I nlmsg_flags
-.br
--
.TS
tab(:);
+l s
lB l.
+Standard flag bits in \fInlmsg_flags\fP
+_
NLM_F_REQUEST:Must be set on all request messages.
NLM_F_MULTI:T{
The message is part of a multipart message terminated by
@@ -185,13 +183,16 @@
NLM_F_ACK:Request for an acknowledgment on success.
NLM_F_ECHO:Echo this request.
.TE
-
-Additional flag bits for GET requests
-.br
--
+.ad
+.sp 1
+.\ No right adustment for text blocks in tables
+.na
.TS
tab(:);
+l s
lB l.
+Additional flag bits for GET requests
+_
NLM_F_ROOT:Return the complete table instead of a single entry.
NLM_F_MATCH:T{
Return all entries matching criteria passed in message content.
@@ -199,27 +200,32 @@
T}
.\ FIXME NLM_F_ATOMIC is not used any more?
NLM_F_ATOMIC:Return an atomic snapshot of the table.
-NLM_F_DUMP:Convenience macro; equivalent to (NLM_F_ROOT|NLM_F_MATCH).
+NLM_F_DUMP:T{
+Convenience macro; equivalent to (NLM_F_ROOT|NLM_F_MATCH).
+T}
.TE
-
+.ad
+.sp 1
Note that
.B NLM_F_ATOMIC
requires the
.B CAP_NET_ADMIN
capability or an effective UID of 0.
-Additional flag bits for NEW requests
-.br
--
+.na
.TS
tab(:);
+l s
lB l.
+Additional flag bits for NEW requests
+_
NLM_F_REPLACE:Replace existing matching object.
NLM_F_EXCL:Don't replace if the object already exists.
NLM_F_CREATE:Create object if it doesn't already exist.
NLM_F_APPEND:Add to the end of the object list.
.TE
-
+.ad
+.sp 1
.I nlmsg_seq
and
.I nlmsg_pid
-- System Information:
Debian Release: 6.0.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable')
Architecture: i386 (i586)
Kernel: Linux 2.6.32-45
Locale: LANG=is_IS, LC_CTYPE=is_IS (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
manpages depends on no packages.
manpages recommends no packages.
Versions of packages manpages suggests:
ii man-db [man-browser] 2.5.7-8 on-line manual pager
-- no debconf information
--
Bjarni I. Gislason
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of The Linux Programming Interface; http://man7.org/tlpi/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662781: getopt.3 has a bad example, as is evident in #655685 report
The following corrects a bad example in the manual page. It also emphasizes the issue. See, for example, #655685, which was filed for procps. Hi. Upstream maintainer of man-pages here. I'm not at all sure that the problem in #655685 is because of getopt(). (How did you conclude that it is?) Allowing a space between option character and argument is longstanding UNIX (and Linux behavior), and as far as I can see POSIX is explicit in allowing it--POSIX.1-2001 contains this text (note point 2): The getopt() function shall return the next option character (if one is found) from argv that matches a character in opt‐ string, if there is one that matches. If the option takes an argument, getopt() shall set the variable optarg to point to the option-argument as follows: 1. If the option was the last character in the string pointed to by an element of argv, then optarg shall contain the next element of argv, and optind shall be incremented by 2. If the resulting value of optind is greater than argc, this indicates a missing option-argument, and getopt() shall return an error indication. 2. Otherwise, optarg shall point to the string following the option character in that element of argv, and optind shall be incremented by 1. Thanks, Michael --- a/getopt.3 2012-03-06 11:33:58.252003620 +0200 +++ b/getopt.3 2012-03-06 11:33:36.0 +0200 @@ -371,14 +371,28 @@ has a technical error described in POSIX The GNU implementation (and probably all other implementations) implements the correct behavior rather than that specified. +.PP +There should be no white space between a short option name +and its possible arguments. +That is, use +.IR -unsecs +, not +.IR -u nsecs . +With long options, use =, with no space characters either before or +after it. That is, +.IR --units=nsecs +, nothing else. .SH EXAMPLE The following trivial example program uses .BR getopt () to handle two program options: .IR \-n , with no associated value; and -.IR \-t val , +.IR \-tval , which expects an associated value. +Note that +.IR \-t val , +with a space, does not work. .nf .sp #include unistd.h -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662781: getopt.3 has a bad example, as is evident in #655685 report
On Wed, Mar 7, 2012 at 11:21 AM, Regid Ichira regi...@yahoo.com wrote: --- On Tue, 3/6/12, Michael Kerrisk (man-pages) wrote: Hi. Upstream maintainer of man-pages here. I'm not at all sure that the problem in #655685 is because of getopt(). (How did you conclude that it is?) The Debian maintainer think so. Based on what is written at http://bugs.debian.org/655685, I think it is unlikely not to point to getopt. Allowing a space between option character and argument is longstanding UNIX (and Linux behavior), and as far as I can see POSIX is explicit in allowing it I was just trying to make the manual page accurately document the actual behavior of the program. Do you think I should close my report, and file a bug to libc (assuming this is not yet reported)? I would say that it's a bit of a leap from reading that bug report to assume that the problem *must* be in getopt(3). I'd want to see a minimal test case demonstrating the behavior. And I assume the libc maintainers would want to see the same. In the meantime, I doubt that the problem is getopt(3), since then there would have been a rash of bug reports on this issue. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564874: manpages: Please ship ld.so manpage
Andrew, On 07/21/13 00:27, Andrew Suffield wrote: Things from my past coming back to haunt me, but if people want to keep ccing me... On Sat, Jul 20, 2013 at 10:15:25PM +0200, Michael Kerrisk wrote: Yes. I've never been quite sure though whether the particular kernel versions to specify for LD_ASSUME_KERNEL when selecting the threading implementation are distro-specific, so I'm reluctant to go into the detail in the page. As you note, I do hint at the 2.2.5 version in the pthreads(7): asuffield@cyclone:~$ readelf -n /lib/x86_64-linux-gnu/libc.so.6 Notes at offset 0x0270 with length 0x0024: Owner Data size Description GNU 0x0014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: cddff8f45f5aa7b5ce64717e9e6ae3899f27972c Notes at offset 0x0294 with length 0x0020: Owner Data size Description GNU 0x0010 NT_GNU_ABI_TAG (ABI version tag) OS: Linux, ABI: 2.6.26 asuffield@cyclone:~$ LD_ASSUME_KERNEL=2.6.25 /bin/true /bin/true: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory asuffield@cyclone:~$ LD_ASSUME_KERNEL=2.6.26 /bin/true asuffield@cyclone:~$ Apparently glibc has moved on and there's nothing in wheezy that can use the old numbers. I expect other distros are similar. This information is probably only of historical interest now. The number 2.2.5 used to be special because it was the *minimum* version supported by the non-TLS libc that was shipped at the time. Yup, I already noticed that older LD_ASSUME_KERNEL values gave results such as the above. However, I was not sure of the intention of your response? Did you mean that the proposed text should be changed? If so, could you be more specific about what changes you'd like. Thanks, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604019: Remove lilo from SEE ALSO too
tags 604019 fixed-upstream thanks On 08/01/13 09:54, Eugen Dedu wrote: Salut Simon, From the new man page: SEE ALSO lilo.conf(5), klogd(8), lilo(8), mount(8) lilo items should be removed from here too. Done. Thanks for spotting that. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553477: [PATCH] dir_colors.5: keywords SUID, SGID, STICKY, STICKY_OTHER_WRITABLE, OTHER_WRITABLE
tags 553477 fixed-upstream thanks Simon, I have applied this patch, and also added the various synonyms that the reporter, Stas, pointed out. Cheers, Michael On 08/06/13 02:14, Simon Paillard wrote: See http://bugs.debian.org/553477 See ls.c and dircolors.c in coreutils --- man5/dir_colors.5 | 15 +++ 1 file changed, 15 insertions(+) diff --git a/man5/dir_colors.5 b/man5/dir_colors.5 index b81dc4f..162c739 100644 --- a/man5/dir_colors.5 +++ b/man5/dir_colors.5 @@ -149,6 +149,21 @@ Specifies the color used for a character device special file. .B EXEC \fIcolor-sequence\fR Specifies the color used for a file with the executable attribute set. .TP +.B SUID \fIcolor-sequence\fR +Specifies the color used for a file with the set-user-ID attribute set. +.TP +.B SGID \fIcolor-sequence\fR +Specifies the color used for a file with the set-group-ID attribute set. +.TP +.B STICKY \fIcolor-sequence\fR +Specifies the color used for a directory with the sticky attribute set. +.TP +.B STICKY_OTHER_WRITABLE \fIcolor-sequence\fR +Specifies the color used for a other-writable directory with the executable attribute set. +.TP +.B OTHER_WRITABLE \fIcolor-sequence\fR +Specifies the color used for a other-writable directory without the executable attribute set. +.TP .B LEFTCODE \fIcolor-sequence\fR Specifies the .I left code -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664688: keyctl(2): Unnecessary tab in some lines in the manual
tags 664688 fixed-upstream thanks On Tue, Mar 20, 2012 at 10:41 AM, Bjarni Ingi Gislason bjarn...@rhi.hi.is wrote: Package: manpages-dev Version: 3.27-1 Severity: minor Tags: patch From groff: standard input:22: warning: tab character in unquoted macro argument standard input:25: warning: tab character in unquoted macro argument standard input:28: warning: tab character in unquoted macro argument standard input:31: warning: tab character in unquoted macro argument standard input:34: warning: tab character in unquoted macro argument standard input:37: warning: tab character in unquoted macro argument standard input:40: warning: tab character in unquoted macro argument standard input:43: warning: tab character in unquoted macro argument standard input:46: warning: tab character in unquoted macro argument standard input:49: warning: tab character in unquoted macro argument standard input:52: warning: tab character in unquoted macro argument standard input:55: warning: tab character in unquoted macro argument standard input:58: warning: tab character in unquoted macro argument standard input:61: warning: tab character in unquoted macro argument standard input:64: warning: tab character in unquoted macro argument standard input:67: warning: tab character in unquoted macro argument standard input:70: warning: tab character in unquoted macro argument Patch: Thanks! Applied for upstream 3.38. Cheers, Michael --- keyctl.2 2012-03-17 19:27:44.0 + +++ keyctl.2.new 2012-03-17 19:50:51.0 + @@ -19,55 +19,55 @@ .BR keyctl () has a number of functions available: .TP -.B KEYCTL_GET_KEYRING_ID +.B KEYCTL_GET_KEYRING_ID Ask for a keyring's ID. .TP -.B KEYCTL_JOIN_SESSION_KEYRING +.B KEYCTL_JOIN_SESSION_KEYRING Join or start named session keyring. .TP -.B KEYCTL_UPDATE +.B KEYCTL_UPDATE Update a key. .TP -.B KEYCTL_REVOKE +.B KEYCTL_REVOKE Revoke a key. .TP -.B KEYCTL_CHOWN +.B KEYCTL_CHOWN Set ownership of a key. .TP -.B KEYCTL_SETPERM +.B KEYCTL_SETPERM Set perms on a key. .TP -.B KEYCTL_DESCRIBE +.B KEYCTL_DESCRIBE Describe a key. .TP -.B KEYCTL_CLEAR +.B KEYCTL_CLEAR Clear contents of a keyring. .TP -.B KEYCTL_LINK +.B KEYCTL_LINK Link a key into a keyring. .TP -.B KEYCTL_UNLINK +.B KEYCTL_UNLINK Unlink a key from a keyring. .TP -.B KEYCTL_SEARCH +.B KEYCTL_SEARCH Search for a key in a keyring. .TP -.B KEYCTL_READ +.B KEYCTL_READ Read a key or keyring's contents. .TP -.B KEYCTL_INSTANTIATE +.B KEYCTL_INSTANTIATE Instantiate a partially constructed key. .TP -.B KEYCTL_NEGATE +.B KEYCTL_NEGATE Negate a partially constructed key. .TP -.B KEYCTL_SET_REQKEY_KEYRING +.B KEYCTL_SET_REQKEY_KEYRING Set default request-key keyring. .TP -.B KEYCTL_SET_TIMEOUT +.B KEYCTL_SET_TIMEOUT Set timeout on a key. .TP -.B KEYCTL_ASSUME_AUTHORITY +.B KEYCTL_ASSUME_AUTHORITY Assume authority to instantiate key. .P These are wrapped by -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: i386 (i586) Kernel: Linux 2.6.32-41 Locale: LANG=is_IS, LC_CTYPE=is_IS (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages manpages-dev depends on: ii manpages 3.27-1 Manual pages about using a GNU/Lin manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii man-db [man-browser] 2.5.7-8 on-line manual pager -- no debconf information -- Bjarni I. Gislason -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655088: rtnetlink.3: incorrect example
tags 655088 fixed-upstream thanks Hello Kirill, and Simon, On Fri, Mar 23, 2012 at 1:34 PM, Simon Paillard spaill...@debian.org wrote: tags 655088 +confirmed +forwarded thanks Hi Kirill, On Sun, Jan 08, 2012 at 05:59:47PM +0400, Kirill Brilliantov wrote: Exaple code in rtnetlink.3 isn't work. If you set append NLM_F_ACK to nlmsg_flags and will read answer you get this - error 22 (Numerical result out of range) This patch correct example code: --- rtnetlink.3.org 2012-01-08 17:19:05.0 +0400 +++ rtnetlink.3 2012-01-08 17:22:49.0 +0400 @@ -109,7 +109,7 @@ rta = (struct rtattr *)(((char *) req) + NLMSG_ALIGN(req.nh.nlmsg_len)); rta\-rta_type = IFLA_MTU; - rta\-rta_len = sizeof(unsigned int); + rta\-rta_len = RTA_LENGTH(sizeof(unsigned int)); req.n.nlmsg_len = NLMSG_ALIGN(req.nh.nlmsg_len) + RTA_LENGTH(sizeof(mtu)); Thanks, I've forwarded your patch upstream. Long ago, Sergei reported the same issue, and no-one confirmed the issue, and I did not have time to investigate, so it sat in my inbox. Thanks for this patch. PS: by the way, please do let all subscribed people to receive your bug reports, not maintonly, this way, upstream maintainer would have receive your report directly (Mickael Kerrisk is following the BTS). And that's good advice. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665780: {fread,fwrite}.3: The return value can be the number of characters
This patch makes no sense to me. How could this information be useful? I can see no reason to take this patch upstream. On Mon, Mar 26, 2012 at 2:54 PM, Regid Ichira regi...@yahoo.com wrote: Package: manpages-dev Version: 3.35-0.1 Severity: normal Tags: patch File: /usr/share/man/man3/fread.3.gz 1. The return value is the number of characters in one case. 2. Doesn't the request to continue the fread synopsis line makes it longer then 80 characters? --- a/fread.3 2012-03-26 03:26:43.677236481 +0200 +++ b/fread.3 2012-03-26 03:26:08.0 +0200 @@ -47,8 +47,8 @@ fread, fwrite \- binary stream input/out .nf .B #include stdio.h .sp -.BI size_t fread(void * ptr , size_t size , size_t nmemb \ -, FILE * stream ); +.BI size_t fread(void * ptr , size_t size , size_t nmemb , +.BI FILE * stream ); .sp .BI size_t fwrite(const void * ptr , size_t size , size_t nmemb , .BI FILE * stream ); @@ -82,10 +82,11 @@ For nonlocking counterparts, see .BR fread () and .BR fwrite () -return the number of items successfully read or written (i.e., not the -number of characters). -If an error occurs, or the end-of-file is -reached, the return value is a short item count (or zero). +return the number of items successfully read or written. This number +equal the number of bytes only when +.I size +is 1. It might be less then the requested count (or zero) if an +error occurs, or the end-of-file is reached. .PP .BR fread () does not distinguish between end-of-file and error, and callers must use -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665780: {fread,fwrite}.3: The return value can be the number of characters
tags 665780 fixed-upstream thanks Hello Regid, On Tue, Mar 27, 2012 at 12:31 AM, Regid Ichira regi...@yahoo.com wrote: --- On Mon, 3/26/12, Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote: This patch makes no sense to me. Why not? Won't char c[10]; fwrite(c, sizeof(char), sizeof(c), stream); be writing 10 bytes, and returns 10? I think the intention of the composer of the page was to emphasize that the number of items returned is not necessarily the number of bytes. How could this information be useful? 1. It is an accurate description. 2. The current phrasing is more confusing for beginners. I also slightly rephrased it: [...] Sorry. I was a hasty reading your patch--I noticed what you added, but not what you removed ((i.e., not the number of characters)). I think that your change does improve the page. I've applied a modified version of your patch for upstream 3.39. The patch is shown below. Cheers, Michael --- a/man3/fread.3 +++ b/man3/fread.3 @@ -40,7 +40,7 @@ .\ Modified Thu Apr 20 20:43:53 1995 by Jim Van Zandt j...@vanzandt.mv.com .\ Modified Fri May 17 10:21:51 1996 by Martin Schulze j...@infodrom.north.de .\ -.TH FREAD 3 1996-05-17 GNU Linux Programmer's Manual +.TH FREAD 3 2012-03-30 GNU Linux Programmer's Manual .SH NAME fread, fwrite \- binary stream input/output .SH SYNOPSIS @@ -79,13 +79,18 @@ obtaining them from the location given by For nonlocking counterparts, see .BR unlocked_stdio (3). .SH RETURN VALUE +On success, .BR fread () and .BR fwrite () -return the number of items successfully read or written (i.e., not the -number of characters). -If an error occurs, or the end-of-file is -reached, the return value is a short item count (or zero). +return the number of +.I items +read or written. +This number equals the number of bytes transferred only when +.I size +is 1. +If an error occurs, or the end of the file is reached, +the return value is a short item count (or zero). .PP .BR fread () does not distinguish between end-of-file and error, and callers must use -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#337581: manpages-dev: dbopen(3) documents non-existent interface
tags 337581 fixed-upstream thanks On Sun, Dec 12, 2010 at 9:55 PM, brian m. carlson sand...@crustytoothpaste.net wrote: This package contains a dbopen(3) manpage, but no such interface exists anywhere in libc6[0]. Yes, it looks like glibc dropped these starting with v2.2. The db.h file referred to in it is part of a separate package (in my particular case, libdb4.7-dev). I suspect that this documents the old Berkeley DB 2 interface that was for a long time included with glibc, but it has been years since that's been included. If my suspicion is correct, you'll probably want to remove this manpage from the package. And while you're at it, close 95279. [0] dpkg -L libc6 | grep -E '^/lib.*so.' | xargs nm -D | grep dbopen returns no results. Upstream man-pages has a long memory (it does not just document the latest version of glibc/the kernel), so I am reluctant to delete these pages. But obviously, something should be done. For upstream 3.40, in these pages: btree.3 dbopen.3 hash.3 mpool.3 recno.3 I added this text at the start of DESCRIPTION in = .IR Note well : This page documents interfaces provided in glibc up until version 2.1. Since version 2.2, glibc no longer provides these interfaces. Probably, you are looking for the APIs provided by the .I libdb library instead. = Thanks for the report, Brian. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654926: manpages-dev: inotify_rm_watch(2) incorrectly lists the type of the second argument
tags 654926 fixed-upstream thanks On Sat, Jan 7, 2012 at 10:54 AM, Tom Fogal tempor...@sogetthis.com wrote: Package: manpages-dev Version: 3.27-1 Severity: minor The man page for inotify_rm_watch(2) indicates that the second argument should be of type uint32_t. In /usr/include/sys/inotify.h, the argument is listed as being of type integer. The 'int'eger argument makes more sense anyway, as the argument should take what inotify_add_watch(2) returns, and that function returns an integer. This was fixed in upstream 3.29. Thanks, Michael -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages manpages-dev depends on: ii manpages 3.27-1 Manual pages about using a GNU/Lin manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii elvis-console [man-browser] 2.2.0-11.1 powerful clone of the vi/ex text e ii konqueror [man-browser] 4:4.4.5-2 advanced file manager, web browser ii man-db [man-browser] 2.5.7-8 on-line manual pager -- no debconf information -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665303: libc-bin: getent.1 from (linux-)manpages
On Tue, Apr 24, 2012 at 12:19 AM, Simon Paillard spaill...@debian.org wrote: Hi, On Thu, Mar 22, 2012 at 11:38:45PM +0100, Simon Paillard wrote: Package: libc-bin Version: 2.13-27 Severity: wishlist In upstream linux-manpages 3.37 (hopefully soon in Debian), a getent.1 manpage is now provided: http://people.debian.org/~spaillard/getent_man/getent.1.linux-man Compared to the Debian one: http://people.debian.org/~spaillard/getent_man/getent.1.libc-bin I think we can reasonably tell the linux-manpages' version provides more details. A replace will be used so that the getent.1 from manpages is used. Do you agree with that ? Once manpages 3.37 uploaded, can you stop installing getent.1 in the future ? Do you have a position regarding this request ? I understand from linux-man mailing list that people from libc are now working with Michael Kerrisk to move content to linux-man. I think that last sentence probably overstates things. The libc folk seem divided about how much they want to cooperate with man-pages. Some are warm to the idea of direct contribution to man-pages, others are not so much. What actually will happen is yet to be seen. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607398: [PATCH] resolv.conf.5: Describe single-request option
tags 607398 fixed-upstream thanks Petr, On Sat, May 16, 2009 at 5:17 AM, Petr Baudis pa...@suse.cz wrote: The single-request option was introduced with glibc-2.10. Also, a note is added to resolver(3) that many of the options are actually described in resolv.conf(5). Signed-off-by: Petr Baudis pa...@suse.cz --- Ping, what about the other patches? ;-) diff --git a/man3/resolver.3 b/man3/resolver.3 index eabc1a4..181468a 100644 --- a/man3/resolver.3 +++ b/man3/resolver.3 @@ -232,6 +232,9 @@ domain and in parent domains. This option is used by .BR gethostbyname (3). [Enabled by default]. +.PP +This list is not complete. You can find some other flags described in +.BR resolv.conf (5). .SH RETURN VALUE The .BR res_init () I applied these two patches separately. diff --git a/man5/resolv.conf.5 b/man5/resolv.conf.5 index 4d67c75..2a2c694 100644 --- a/man5/resolv.conf.5 +++ b/man5/resolv.conf.5 @@ -231,6 +231,19 @@ sets in .IR _res.options . This enables support for the DNS extensions described in RFC\ 2671. +.TP +.BR single-request (since glibc 2.10) +sets +.BR RES_SNGLKUP +in +.IR _res.options . +By default, glibc performs IPv4 and IPv6 lookups in parallel since +version 2.9 (though many distribution packages of glibc are known +to disable that behavior in this version). Some appliance DNS servers +cannot handle these queries properly and make the requests time out. +This option disables the behavior and makes glibc perform the IPv6 +and IPv4 requests sequentially (at the cost of some slowdown of the +resolving process). .RE .LP The \fIdomain\fP and \fIsearch\fP keywords are mutually exclusive. I applied a slightly modified version of the above patch that dropped the details about distros. See below. These patches will appear in man-pages-3.40. Cheers, Michael --- a/man5/resolv.conf.5 +++ b/man5/resolv.conf.5 @@ -231,6 +231,19 @@ sets in .IR _res.options . This enables support for the DNS extensions described in RFC\ 2671. +.TP +.BR single-request (since glibc 2.10) +sets +.BR RES_SNGLKUP +in +.IR _res.options . +By default, glibc performs IPv4 and IPv6 lookups in parallel since +version 2.9. +Some appliance DNS servers +cannot handle these queries properly and make the requests time out. +This option disables the behavior and makes glibc perform the IPv6 +and IPv4 requests sequentially (at the cost of some slowdown of the +resolving process). .RE .LP The \fIdomain\fP and \fIsearch\fP keywords are mutually exclusive. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609033: manpages-dev: please improve isgreater(3) description
Vincent, On Thu, Jan 6, 2011 at 5:38 AM, Vincent Lefevre vinc...@vinc17.net wrote: Package: manpages-dev Version: 3.27-1 Severity: wishlist The isgreater(3) man page says: The normal relation operations (like , less than) will fail if one of the operands is NaN. This will cause an exception. To avoid this, C99 defines these macros. The macros are guaranteed to evaluate their operands only once. The operands can be of any real floating-point type. It should probably be emphasised that the operands must not be of integer types. The man page already says: The operands can be of any real floating-point type. Is that not emphasis enough? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704787: manpages: units should use an actual µ
tags 704787 fixed-upstream thanks On Fri, Apr 5, 2013 at 11:24 PM, brian m. carlson sand...@crustytoothpaste.net wrote: Package: manpages Version: 3.44-1 Severity: minor File: /usr/share/man/man7/units.7.gz Tags: patch The units(7) man page uses an ASCII u in place of the actual Greek letter mu. Since we're in the twenty-first century, with UTF-8-compatible terminals and terminal emulators, we should use the actual letter µ instead of an ASCII approximation. Attached is a patch to do that. It's against the current master of the Vcs-Git repository. Seems reasonable to me. Applied. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705293: manpages-dev: access(2) does not document return-value behavior for F_OK
tags 705293 fixed-upstream thanks On Fri, Apr 12, 2013 at 5:26 PM, The Wanderer wande...@fastmail.fm wrote: Package: manpages-dev Version: 3.44-1 Severity: normal Dear Maintainer, The man page for the 'access' function describes two ways to use the function: to check whether the current real user ID has specific permissions for a file (R_OK, W_OK, X_OK), or to check whether that file simply exists (F_OK). The Return Value section of the man page, however, appears to be written exclusively in the context of the check permissions modes. It documents a value of zero as meaning success (all requested permissions granted), but does not describe the meanings of return values when checking only for existence rather than attempting to check any permissions. A usage example near the bottom of what appears to be the z/OS man page for the same function http://publib.boulder.ibm.com/infocenter/zos/v1r11/topic/com.ibm.zos.r11.bpxbd00/rtacc.htm seems to indicate that in the check existence mode, a return value of zero indicates that the file exists, and nonzero indicates that the file does not exist; however, even in that version of the man page, the Returned Value section appears to be written exclusively in the context of the check permissions modes. Thanks for the report. I agree that the page should be clearer on this point. I've amended the REURN VALUE section to read: On success (all requested permissions granted, or mode is F_OK and the file exists), zero is returned. On error (at least one bit in mode asked for a permission that is denied, or mode is F_OK and the file does not exist, or some other error occurred), -1 is returned, and errno is set appropriately. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703845: manpages-dev: typo in error() man page error_one_per_line
On Sun, Mar 24, 2013 at 6:28 PM, Britton Kerin britton.ke...@gmail.com wrote: Package: manpages-dev Version: 3.27-1 Severity: minor The header of the man page has 'error_on_per_line' but the actual extern int being documented is 'error_one_per_line'. Of course this also shows up as the wrong file in man3 This was fixed upstream in May 2012 (upstream man-pages-3.41). Thanks, Michael -- System Information: Debian Release: 6.0.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686-bigmem (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages manpages-dev depends on: ii manpages 3.27-1 Manual pages about using a GNU/Lin manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii man-db [man-browser] 2.5.7-8on-line manual pager -- no debconf information -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553413: proc(5): Add field numbers
On Mon, Nov 19, 2012 at 9:57 PM, Simon Paillard spaill...@debian.org wrote: Control: tag -1 +upstream On Sat, Oct 31, 2009 at 03:02:25AM +0100, Samuel Thibault wrote: Package: manpages Version: 3.22-1 Severity: minor Tags: patch To make it easier to use cut to select the desired fields, it is useful to have the field numbers in the documentation. The attached patch does this. Michael, this is a improvement that could be upstreamed, are you interested ? I'd be interested but it doesn't apply cleanly to current usptream -- many hunks rejected. Could you or Samuel draft a version against upstream? hanks, Michael --- proc.5.orig 2009-10-31 02:49:17.0 +0100 +++ proc.52009-10-31 03:00:48.0 +0100 @@ -607,64 +607,64 @@ format specifiers, are: .RS .TP 12 -\fIpid\fP %d +(1) \fIpid\fP %d The process ID. .TP -\fIcomm\fP %s +(2) \fIcomm\fP %s The filename of the executable, in parentheses. This is visible whether or not the executable is swapped out. .TP -\fIstate\fP %c +(3) \fIstate\fP %c One character from the string RSDZTW where R is running, S is sleeping in an interruptible wait, D is waiting in uninterruptible disk sleep, Z is zombie, T is traced or stopped (on a signal), and W is paging. .TP -\fIppid\fP %d +(4) \fIppid\fP %d The PID of the parent. .TP -\fIpgrp\fP %d +(5) \fIpgrp\fP %d The process group ID of the process. .TP -\fIsession\fP %d +(6) \fIsession\fP %d The session ID of the process. .TP -\fItty_nr\fP %d +(7) \fItty_nr\fP %d The controlling terminal of the process. (The minor device number is contained in the combination of bits 31 to 20 and 7 to 0; the major device number is in bits 15 t0 8.) .TP -\fItpgid\fP %d +(8) \fItpgid\fP %d .\ This field and following, up to and including wchan added 0.99.1 The ID of the foreground process group of the controlling terminal of the process. .TP -\fIflags\fP %u (%lu before Linux 2.6.22) +(9) \fIflags\fP %u (%lu before Linux 2.6.22) The kernel flags word of the process. For bit meanings, see the PF_* defines in .IR linux/sched.h . Details depend on the kernel version. .TP -\fIminflt\fP %lu +(10) \fIminflt\fP %lu The number of minor faults the process has made which have not required loading a memory page from disk. .TP .\ field 11 -\fIcminflt\fP %lu +(11) \fIcminflt\fP %lu The number of minor faults that the process's waited-for children have made. .TP -\fImajflt\fP %lu +(12) \fImajflt\fP %lu The number of major faults the process has made which have required loading a memory page from disk. .TP -\fIcmajflt\fP %lu +(13) \fIcmajflt\fP %lu The number of major faults that the process's waited-for children have made. .TP -\fIutime\fP %lu +(14) \fIutime\fP %lu Amount of time that this process has been scheduled in user mode, measured in clock ticks (divide by .IR sysconf(_SC_CLK_TCK) . @@ -673,12 +673,12 @@ so that applications that are not aware of the guest time field do not lose that time from their calculations. .TP -\fIstime\fP %lu +(15) \fIstime\fP %lu Amount of time that this process has been scheduled in kernel mode, measured in clock ticks (divide by .IR sysconf(_SC_CLK_TCK) . .TP -\fIcutime\fP %ld +(16) \fIcutime\fP %ld Amount of time that this process's waited-for children have been scheduled in user mode, measured in clock ticks (divide by @@ -688,13 +688,13 @@ This includes guest time, \fIcguest_time\fP (time spent running a virtual CPU, see below). .TP -\fIcstime\fP %ld +(17) \fIcstime\fP %ld Amount of time that this process's waited-for children have been scheduled in kernel mode, measured in clock ticks (divide by .IR sysconf(_SC_CLK_TCK) . .TP -\fIpriority\fP %ld +(18) \fIpriority\fP %ld (Explanation for Linux 2.6) For processes running a real-time scheduling policy .RI ( policy @@ -715,7 +715,7 @@ the scheduler weighting given to this process. .\ And back in kernel 1.2 days things were different again. .TP -\fInice\fP %ld +(19) \fInice\fP %ld The nice value (see .BR setpriority (2)), a value in the range 19 (low priority) to \-20 (high priority). @@ -730,81 +730,81 @@ .\ \fItimeout\fP %u .\ The time in jiffies of the process's next timeout. .\ timeout was removed sometime around 2.1/2.2 -\fInum_threads\fP %ld +(20) \fInum_threads\fP %ld Number of threads in this process (since Linux 2.6). Before kernel 2.6, this field was hard coded to 0 as a placeholder for an earlier removed field. .TP .\ field 21 -\fIitrealvalue\fP %ld +(21) \fIitrealvalue\fP %ld The time in jiffies before the next .B SIGALRM is sent to the process due to an interval timer. Since kernel 2.6.17, this field is no longer maintained, and is hard coded as 0. .TP -\fIstarttime\fP %llu (was %lu before Linux 2.6) +(22) \fIstarttime\fP %llu (was %lu before Linux 2.6) The time in jiffies the process started after
Bug#553413: proc(5): Add field numbers
tags 553413 fixed-upstream thanks I've now myself made all of these changes, at the same time as I made some other changes in proc(5). I omitted this piece of the downstream patch: @@ -1195,16 +1195,16 @@ .in +4n .nf -cache buffer size in KB -capacity number of sectors -driver driver version -geometry physical and logical geometry -identify in hexadecimal -media media type -model manufacturer's model number -settings drive settings -smart_thresholds in hexadecimal -smart_values in hexadecimal +(1) cache buffer size in KB +(2) capacity number of sectors +(3) driver driver version +(4) geometry physical and logical geometry +(5) identify in hexadecimal +(6) media media type +(7) model manufacturer's model number +(8) settings drive settings +(9) smart_thresholds in hexadecimal +(10) smart_values in hexadecimal .fi .in That piece didn't make sense, since those items are files, not fields. I also omitted the slabinfo piece, since really the place for those details is in the slabinfo(5) page, which is itself seriously out of date (see FIXMEs in the page source). Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528015: manpages: securetty is not only used to restrict root login
On Sun, May 10, 2009 at 12:59 PM, Nicolas FRANCOIS (Nekral) nicolas.franc...@centraliens.net wrote: Package: manpages Version: 3.21-1 Severity: normal Tags: patch Hello, pam_unix, with the nullok_secure option uses /etc/securetty for a slightly different purpose than documented in securetty(5). securetty(5) could also be completed to indicate that PAM also support securetty (with pam_securetty). Note that the nullok_secure option is a Debian specific patch for PAM. I'm attaching a proposal for these two additions. Thanks in advance, Nicolas, is there some non-Debian-specific stuff here that could be applied upstream? If you would craft a patch against (current) upstream, I'll apply it. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#309599: manpages-dev: Return value of res_search and friends
Florian, Can you provide some supporting eveidence for this patch -- (simple) test code or a specific references in the glibs source? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575077: manpages-dev: va_copy manpage doesn't specify the intended behaviour of va_copy
tags 575077 fixed-upstream thanks Friedrich, I've added the following text upstream: The va_copy() macro copies the (previously initialized) vari‐ able argument list src to dest. The behavior is as if va_start() were applied to dest with the same last argument, followed by the same number of va_arg() invocations that was used to reach the current state of src. Thanks for your report. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620746: lutimes.3: please warn about possibility of ENOSYS
tags 620746 fixed-upstream thanks Jonathan, I have applied a patch for man-pages-3.50. Thanks for the report. Cheers, Michael On Sun, Apr 3, 2011 at 9:45 PM, Jonathan Nieder jrnie...@gmail.com wrote: Package: manpages-dev Version: 3.27-1 Severity: minor Tags: upstream Justification: http://bugs.debian.org/620679 Hi, The lutimes(3) manpage explains: Errors are as for utimes(2), with the following additions for futimes(): EBADF fd is not a valid file descriptor. ENOSYS The /proc file system could not be accessed. where for reference, the list of errors in utimes(2) is below[1]. But it never mentions a certain, more common error: ENOSYS (Linux: the kernel version is below 2.6.22.) Assuming I can trust utimensat(2), it might also be good to mention EACCES times is NULL, and the file is marked immutable (see chattr(1). EFAULT times points to an invalid address, or filename is NULL or an invalid address EINVAL invalid value in one of the tv_nsec fields (see utimensat(2)), or an invalid value in one of the tv_sec fields ELOOP too many symbolic links were encountered in resolving filename ENAMETOOLONG filename is too long ENOENT a component of filename does not refer to an existing directory or file, or filename is an empty string ENOTDIR one of the prefix components of filename is not a directory EPERM attempting to change a time but the file is marked append-only (see chattr(1)) ESRCH search permission is denied for one of the prefix components of filename though I'm not sure such detail is warranted --- maybe path_resolution.7 could mention the errors it can produce, and the error section in utimensat.2 and futimes.3 could just say something like EACCES, ESRCH, ENAMETOOLONG, ENOTDIR, ELOOP see path_resolution(7) to cover that part. Hope that helps. [1] EACCES Search permission is denied for one of the directories in the path prefix of path (see also path_resolution(7)). EACCES times is NULL, the caller's effective user ID does not match the owner of the file, the caller does not have write access to the file, and the caller is not privileged (Linux: does not have either the CAP_DAC_OVERRIDE or the CAP_FOWNER capability). ENOENT filename does not exist. EPERM times is not NULL, the caller's effective UID does not match the owner of the file, and the caller is not privileged (Linux: does not have the CAP_FOWNER capability). EROFS path resides on a read-only file system. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674034: manpages-dev: please mention that getpeername() does not work with udp connections as one could expect
tags 674034 fixed-upstream thanks On Tue, May 22, 2012 at 6:53 PM, Kai Kunschke k...@kunfoo.org wrote: Package: manpages-dev Version: 3.27-1 Severity: minor Tags: upstream patch Subject: /usr/share/man/man2/getpeername.2.gz: please mention that getpeername() does not work with udp connections as one could expect Package: manpages-dev Version: 3.27-1 File: /usr/share/man/man2/getpeername.2.gz Severity: minor Tags: patch upstream getpeername() will never deliver the address of a udp client on server side, even if he called connect(). The way to go is recvfrom(). A note in the manpage would have saved me a lot of time. I've applie dthe patch below upstream. Cheers, Michael --- a/man2/getpeername.2 +++ b/man2/getpeername.2 @@ -37,7 +37,7 @@ .\ Modified 17 Jul 2002, Michael Kerrisk mtk.manpa...@gmail.com .\Added 'socket' to NAME, so that man -k socket will show this page. .\ -.TH GETPEERNAME 2 2008-12-03 Linux Linux Programmer's Manual +.TH GETPEERNAME 2 2013-02-12 Linux Linux Programmer's Manual .SH NAME getpeername \- get name of connected peer socket .SH SYNOPSIS @@ -111,6 +111,34 @@ Some POSIX confusion resulted in the present also used by glibc. See also .BR accept (2). + +For stream sockets, once a +.BR connect (2) +has been performed, either socket can call +.BR getpeername () +to obtain the address of the peer socket. +On the other hand, datagram sockets are connectionless. +Calling +.BR connect (2) +on a datagram socket merely sets the peer address for outgoing +datagrams sent with +.BR write (2) +or +.BR recv (2). +The caller of +.BR connect (2) +can use +.BR getpeername () +to obtain the peer address that it earlier set for the socket. +However, the peer socket is unaware of this information, and calling +.BR getpeername () +on the peer socket will return no useful information (unless a +.BR connect (2) +call was also executed on the peer). +Note also that the receiver of a datagram can obtain +the address of the sender when using +.BR recvfrom (2). + .SH SEE ALSO .BR accept (2), .BR bind (2), -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542601: manpages-dev: mmap(2) manpage doesn't say that MAP_ANON is not available if _XOPEN_SOURCE is defined
tags 542601 fixed-upstream thanks On Thu, Aug 20, 2009 at 1:02 PM, Török Edwin edwinto...@gmail.com wrote: Package: manpages-dev Version: 3.22-1 Severity: normal When _XOPEN_SOURCE is defined the glibc headers no longer define MAP_ANON or MAP_ANONYMOUS (because _BSD_SOURCE is no longer defined by default). So if I want to use both pread(2) and mmap(2) in same C source file, I have to define both _XOPEN_SOURCE and _BSD_SOURCE to get the prototype for pread *and* MAP_ANON for mmap(2). The manpage of pread(2) does say that _XOPEN_SOURCE 500 is needed, but doesn't say that this breaks mmap. mmap's manpage doesn't say that some constants may not be available under _XOPEN_SOURCE. Why is _XOPEN_SOURCE 500 even needed for pread? It is a POSIX function, and defining _XOPEN_SOURCE is not needed for other POSIX functions. Also the POSIX manpage for pread(3p) doesn't say that _XOPEN_SOURCE is needed, so this seems like an unnecessary complication on Linux. If pread(2) was available w/o _XOPEN_SOURCE being defined, then the problem with using pread and mmap would no longer exist. I think this is rather a question for glibc though. I applied the patch below upstream. Thanks, Michael --- a/man2/mmap.2 +++ b/man2/mmap.2 @@ -49,6 +49,8 @@ mmap, munmap \- map or unmap files or devices into memory .BIint fd , off_t offset ); .BI int munmap(void * addr , size_t length ); .fi + +See NOTES for information on feature test macro requirements. .SH DESCRIPTION .BR mmap () creates a new mapping in the virtual address space of @@ -541,6 +543,36 @@ If the flag is specified, and .I addr is 0 (NULL), then the mapped address will be 0 (NULL). + +Certain +.I flags +constants are defined only if either +.BR _BSD_SOURCE +or +.BR _SVID_SOURCE +is defined. +(Requiring +.BR _GNU_SOURCE +also suffices, +and requiring that macro specifically would have been more logical, +since these flags are all Linux specific.) +The relevant flags are: +.BR MAP_32BIT , +.BR MAP_ANONYMOUS +(and the synonym +.BR MAP_ANON ), +.BR MAP_DENYWRITE , +.BR MAP_EXECUTABLE , +.BR MAP_FILE , +.BR MAP_GROWSDOWN , +.BR MAP_HUGETLB , +.BR MAP_LOCKED , +.BR MAP_NONBLOCK , +.BR MAP_NORESERVE , +.BR MAP_POPULATE , +and +.BR MAP_STACK . + .SH BUGS On Linux there are no guarantees like those suggested above under .BR MAP_NORESERVE . -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691195: Bug#652443: ioprio_get(2): document who==0
Hi Jens, Would you be able to comment on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691195 please? Either in that bug, or to this mail? Thanks, Michael On Mon, Oct 22, 2012 at 10:05 PM, Simon Paillard spaill...@debian.org wrote: Version: 3.42-1 On Sun, Jul 29, 2012 at 08:32:49AM +0200, Michael Kerrisk (man-pages) wrote: On Sat, Dec 17, 2011 at 11:26 PM, Kalle Olavi Niemitalo k...@iki.fi wrote: The ioprio_get(2) manual page describes the meanings of the which and who parameters: IOPRIO_WHO_PROCESS who is a process ID identifying a single process. IOPRIO_WHO_PGRP who is a process group ID identifying all the members of a process group. The manual page should mention that IOPRIO_WHO_PROCESS and IOPRIO_WHO_PGRP also allow who==0. Yes. As implemented in fs/ioprio.c, who==0 means the calling process or its process group. The ioprio program in util-linux already uses the feature. This is worth documenting separately because e.g. tcsetpgrp does not treat pgrp==0 in that way. Agreed, this should be documented since various APIs interpret pgrp==0 differently. Some (e.g., killpg(2)) are like this syscall, others are not. Documented by Michael in 82fdd7c7d0, already in manpages 3.42. IOPRIO_WHO_USER who is a user ID identifying all of the processes that have a matching real UID. For IOPRIO_WHO_USER, the situation is more complex: who==0 means the root user in ioprio_set but the current user (I think the real UID of the calling process) in ioprio_get. (That inconsistency might even be a bug.) Remaning items as http://bugs.debian.org/691195 -- Simon Paillard -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533232: read(2): document behavior when count=0 but fd is not open
tags 533232 fixed-upstream thanks On Mon, Jun 15, 2009 at 9:12 PM, Zack Weinberg za...@panix.com wrote: Package: manpages-dev Version: 3.21-1 Severity: minor The read(2) manpage currently says If _count_ is zero, read() returns zero and has no other results. but this does not explain what happens if the _fd_ or _buf_ parameters are invalid (== would cause an error return or a segmentation fault if _count_ were nonzero). I experimented and found that Linux returns -1/EBADF if count is zero but fd refers to a file descriptor that is not open; all the other cases I can trivially test (read 0 bytes from an fd open for writing only, read 0 bytes with an invalid buffer pointer) do return 0 and leave errno untouched. I do not, however, know if this behavior can be relied on in portable code. (If not, it might be nice to mention that fcntl(fd, F_GETFL, 0) is a portable way to determine whether 'fd' is an open file descriptor.) Zack, POSIX deliberately leaves the behavor here open. The read(3p) page says: Before any action described below is taken, and if nbyte is zero, the read() function may detect and return errors as described below. In the absence of errors, or if error detec‐ tion is not performed, the read() function shall return zero and have no other results. I've adjusted the text in the Linux read(2) page, replacing: If count is zero, read() returns zero and has no other results. with If count is zero, read() may detect the errors described below. In the absence of any errors, of if read() does not check for errors, a read() with a count of 0 returns zero and has no other effects. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700529: manpages-dev: confusing NOTES section on O_NONBLOCK in read(2)
tags 700529 fixed-upstream thanks On Thu, Feb 14, 2013 at 12:38 AM, Marc Lehmann debian-report...@plan9.de wrote: Package: manpages-dev Version: 3.40-0.1 Severity: minor The read(2) manpage (possibly others) contains this confusing paragraph in the NOTES section: Many file systems and disks were considered to be fast enough that the implementation of O_NONBLOCK was deemed unnecessary. So, O_NONBLOCK may not be available on files and/or disks. However, this can neither be true, nor is there reasonable semantics for O_NONBLOCK on files. The reason for this is that for O_NONBLOCK to make sense, you need data to arrive on its own (pipe write on other side, tcp packet received etc.). For files, there is no such source of data - while an implementatioon that indeed only returned what it currently has in the the buffer cache is theoretically feasible, no new data would arrive on its own, as the kernel would need to know how much data to read, and from where, so programs would effectively deadlock as there is no way to tell the kernel to read more data for the next read (and there is no way to wait for more data, as it would be for pipes and sockets with e.g. select). I would suggest simply deleting this paragraph, as it continues to confuse people into thinking O_NONBLOCK semantics are possible with files. Well, O_NONBLOCK does have meaningful semantics w.r.t. file locks. But, that doesn't seem to be what this paragraph is talking about, and I agree with you that it is confusing. I've removed it. Thanks for the report. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564874: manpages: Please ship ld.so manpage
On Sun, Apr 29, 2012 at 7:42 PM, Simon Paillard spaill...@debian.org wrote: (but no more LD_ASSUME_KERNEL). I just drafted the following for ld.so.8 in man-pages: LD_ASSUME_KERNEL (glibc since 2.2.3) Each shared library can inform the dynamic linker of the minimum kernel ABI version that it requires. (This requirement is encoded in an ELF note section that is typically named .note.ABI-tag.) At run time, the dynamic linker determines the ABI version of the running kernel and will reject loading shared libraries that specify minimum ABI versions that exceed that ABI version. LD_ASSUME_KERNEL can be used to cause the dynamic linker to assume that it is running on a system with a differ‐ ent kernel ABI version. For example, the following com‐ mand line causes the dynamic linker to assume it is run‐ ning on Linux 2.2.5 when loading the shared libraries required by myprog: $ LD_ASSUME_KERNEL=2.2.5 ./myprog On systems that provide multiple versions of a shared library (in different directories in the search path) that have different minimum kernel ABI version require‐ ments, LD_ASSUME_KERNEL can be used to select the ver‐ sion of the library that is used (dependent on the directory search order). Historically, the most common use of the LD_ASSUME_KERNEL feature was to manually select the older LinuxThreads POSIX threads implementa‐ tion on systems that provided both LinuxThreads and NPTL (which latter was typically the default on such sys‐ tems). Look okay? Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666972: manpages: 'man proc': /proc/partition block size and count method undocumented
On Wed, Aug 21, 2013 at 11:49 PM, Simon Paillard spaill...@debian.org wrote: Control: tag -1 +upstream On Mon, Apr 02, 2012 at 08:43:17PM -0400, A. Costa wrote: Package: manpages Version: 3.35-0.1 Severity: normal Dear Maintainer, % man proc | grep -A 2 -n '/proc/partition' 988: /proc/partitions 989- Contains major and minor numbers of each partition as well as number of 990- blocks and partition name. There's no mention of how many bytes are in a block, and no description of how block numbers are counted. A full definition of fields is available in the kernel tree: http://lxr.linux.no/#linux+v3.5/Documentation/iostats.txt We can either just point to that doc in the manpage, or document all the fields of /proc/partition. It would I think be best to have this information in the man page. But, I cannot see where you are finding the info in Documentation/iostats.txt, Simon. A. Costa: From scanning the source code (where the count of blocks is part_nr_sects_read(part) 1 in block/genhd.c::show_partition() -- I assume a sector is 512 B), I'm reasonably sure that /proc/partitions is giving us 1024-byte blocks. Here's my experiment: $ cat /proc/partitions | grep sdc1 8 33 1465136128 sdc1 $ df -B 1024 | grep sdc1 /dev/sdc1 1464421040 447518960 1016902080 31% /run/media/mtk/CNM1500 $ bc -q 1465136128 * 100 / 1464421040 1000488 In other words, the difference between the two values is just under 0.05%. Looking at the source code of 'df', it gets it's information using the statvfs() function which in turn calls statfs(2). I confirmed that direct statfs(2) calls return information precisely consistent with the output of df. The question is still why there is a difference between blocks as reported by statfs() and /proc/partitions, with the latter always a little bigger than the former. Well, looking at the statfs() implementation (fs/statfs.c), the relevant field pulled from kernel data structures is 'f_blocks', and looking in (for example), fs/ext4/super.c::ext4_statfs(),, I find: buf-f_blocks = ext4_blocks_count(es) - EXT4_C2B(sbi, overhead); sbi is super block info. That looks to me to mean that stafs() is deducting a small amount from the number of blocks, for the overhead of the super block info, and without digging too much further, I'm going to guess that that might explain the difference from /proc/partitions. However, that's all fairly speculative, so I'm not confident enough to put too much detail into the page. However, I did apply the small patch below: Cheers, Michael diff --git a/man5/proc.5 b/man5/proc.5 index e40dd4d..95eb743 100644 --- a/man5/proc.5 +++ b/man5/proc.5 @@ -2160,7 +2160,7 @@ socket and Path is the bound path (if any) of the socket. .TP .I /proc/partitions Contains major and minor numbers of each partition as well as number -of blocks and partition name. +of 1024-byte blocks and partition name. .TP .I /proc/pci This is a listing of all PCI devices found during kernel initialization -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729570: Year since 1900
tags 729570 fixed-upstream
thanks
On 11/15/13 09:40, Simon Paillard wrote:
Control: tag -1 +confirmed +upstream
On Thu, Nov 14, 2013 at 02:14:17PM +0100, Mathieu Malaterre wrote:
Package: manpages-dev
Tags: patch
It would be nice if the man page for strptime would be changed from:
...
The broken-down time structure tm is defined in time.h as follows:
struct tm {
[...]
int tm_mday; /* day of the month */
int tm_mon;/* month */
int tm_year; /* year */
int tm_wday; /* day of the week */
int tm_yday; /* day in the year */
int tm_isdst; /* daylight saving time */
};
...
into:
int tm_year; /* year since 1900 */
Thanks for your report.
I think there is a risk of confusion for tm_mon (month) at least.
We could just copy the struct from the .h and have the range included ?
FTR, time.h says:
struct tm
{
int tm_sec; /* Seconds. [0-60] (1 leap second)
*/
int tm_min; /* Minutes. [0-59] */
int tm_hour; /* Hours. [0-23] */
int tm_mday; /* Day. [1-31] */
int tm_mon; /* Month. [0-11] */
int tm_year; /* Year - 1900. */
int tm_wday; /* Day of week. [0-6] */
int tm_yday; /* Days in year.[0-365] */
int tm_isdst; /* DST. [-1/0/1]*/
Thanks. I applied the change below.
Cheers,
Michael
commit fae39e4795e9ea86ea41f25a9c572ee8e747c9ac
Author: Michael Kerrisk mtk.manpa...@gmail.com
Date: Mon Dec 30 19:24:41 2013 +1300
strptime.3: Add number ranges to comments in 'tm' structure
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729570
Reported-by: Mathieu Malaterre ma...@debian.org
Reported-by: Simon Paillard spaill...@debian.org
Signed-off-by: Michael Kerrisk mtk.manpa...@gmail.com
diff --git a/man3/strptime.3 b/man3/strptime.3
index 1630a76..c9fd7b5 100644
--- a/man3/strptime.3
+++ b/man3/strptime.3
@@ -266,15 +266,15 @@ as follows:
.in +4n
.nf
struct tm {
-int tm_sec;/* seconds */
-int tm_min;/* minutes */
-int tm_hour; /* hours */
-int tm_mday; /* day of the month */
-int tm_mon;/* month */
-int tm_year; /* year */
-int tm_wday; /* day of the week */
-int tm_yday; /* day in the year */
-int tm_isdst; /* daylight saving time */
+int tm_sec;/* Seconds (0-60) */
+int tm_min;/* Minutes (0-59) */
+int tm_hour; /* Hours (0-23) */
+int tm_mday; /* Day of the month (1-31) */
+int tm_mon;/* Month (0-11) */
+int tm_year; /* Year - 1900 */
+int tm_wday; /* Day of the week (0-6, Sunday = 0) */
+int tm_yday; /* Day in the year (0-365, 1 Jan = 0) */
+int tm_isdst; /* Daylight saving time */
};
.fi
.in
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723659: strspn, strcspn - search a string for a set of characters
tags -1 fixed-upstream thanks On 09/19/13 02:18, Mathieu Malaterre wrote: Package: manpages-dev $ man strspn | head -6 [...] strspn, strcspn - search a string for a set of characters However from POSIX: http://pubs.opengroup.org/onlinepubs/009695399/functions/strspn.html strspn - get length of a substring Thanks, I made it get length of a prefix substring. Okay? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735590: manpages: filesystems(5) should describe the nodev prefix in /proc/filesystems
Axel, On Fri, Jan 17, 2014 at 6:53 AM, Axel Beckert a...@debian.org wrote: Package: manpages Version: 3.55-1 filesystems(5) says: When, as is customary, the proc filesystem is mounted on /proc, you can find in the file /proc/filesystems which filesystems your kernel currently supports. If you need a currently unsupported one, insert the corresponding module or recompile the kernel. My /proc/filesystems looks like this: $ cat /proc/filesystems nodev sysfs nodev rootfs nodev ramfs nodev bdev nodev proc nodev cgroup nodev cpuset nodev tmpfs nodev devtmpfs nodev debugfs nodev securityfs nodev sockfs nodev pipefs nodev anon_inodefs nodev devpts nodev hugetlbfs nodev pstore nodev mqueue btrfs ext3 ext2 ext4 fuseblk nodev fuse nodev fusectl nodev binfmt_misc nodev aufs $ filesystems(5) should mention the nodev prefix (and maybe other potential prefixes) and describe its/their meaning.. One thing that would have helped here is if you could have supplied some text explaining what nodev is. (Or, if you don't know, then it would help to explicitly note that in the bug.) I believe the appropriate text would be something like [[ If the work nodev appears before a filesystem name, then that filesystem does not require a corresponding device in order to be mounted (i.e., it is a pseudo-filesystem). ]] Look okay to you? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735590: manpages: filesystems(5) should describe the nodev prefix in /proc/filesystems
tags 735590 fixed-upstream thanks Hi Axel, On Sat, Jan 18, 2014 at 12:08 AM, Axel Beckert a...@debian.org wrote: Hi Michael, Michael Kerrisk (man-pages) wrote: One thing that would have helped here is if you could have supplied some text explaining what nodev is. I had some idea, but was unsure and looked into the man-page to read more about it. (Or, if you don't know, then it would help to explicitly note that in the bug.) I didn't expect that this needs explicit mentioning. The thing is, I sometimes get bug reports from people who *do* know the details, but they initially neither tell me them nor indicate that they know them--perhaps because they think the point is obvious enough that I don't need to be told. So, it saves me a few cycles if people tell me what they do or don't know; then I know what I can or can't ask them. ;-) See what I mean? [[ If the work nodev appears before a filesystem name, then that filesystem does not require a corresponding device in order to be mounted (i.e., it is a pseudo-filesystem). ]] Look okay to you? Doesn't clash with what I guessed, but since I was looking for facts, I can't say if it's correct or wrong. I just now noticed that nodev is documented in /proc/filesystems [[ If a filesystem is marked with nodev, this means that it does not require a block device to be mounted (e.g., virtual filesystem, network filesystem) ]] So what's needed is a pointer from filesystems(5) to proc(5). I'll add that. Thanks for the report. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638186: locale({1,5}) should describe LANG and LANGUAGE
LANG and LANGUAGE certainly *are* described in the upstream locale(5) page On Sat, Jan 18, 2014 at 11:13 AM, Simon Paillard spaill...@debian.org wrote: Control: -1 retitle locale(5) should describe LANG and LANGUAGE Hi, On Wed, Aug 17, 2011 at 04:18:03PM +0200, Gioele Barabucci wrote: Package: manpages Version: 3.23 The man page for `locale(1)` do not describe the LANG and LANGUAGE environment variables. Note locale(1) is not from manpages package: libc-bin: /usr/share/man/man1/locale.1.gz `environ(7)` describes only LANG and refers to `locale(5)` for further explaination. `locale(5)` do not describe neither LANG or LANGUAGE. Both LANG and LANGUAGE are described in LSB 4.0, although not in depth. Shouldn't the meaning and the format of LANG and LANGUAGE and the difference between these two environment variables be explained in `locale` manpages? -- Simon Paillard -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638186: locale({1,5}) should describe LANG and LANGUAGE
My apologies. They are described in the *locale(7)* page. On Sat, Jan 18, 2014 at 10:51 PM, Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote: LANG and LANGUAGE certainly *are* described in the upstream locale(5) page On Sat, Jan 18, 2014 at 11:13 AM, Simon Paillard spaill...@debian.org wrote: Control: -1 retitle locale(5) should describe LANG and LANGUAGE Hi, On Wed, Aug 17, 2011 at 04:18:03PM +0200, Gioele Barabucci wrote: Package: manpages Version: 3.23 The man page for `locale(1)` do not describe the LANG and LANGUAGE environment variables. Note locale(1) is not from manpages package: libc-bin: /usr/share/man/man1/locale.1.gz `environ(7)` describes only LANG and refers to `locale(5)` for further explaination. `locale(5)` do not describe neither LANG or LANGUAGE. Both LANG and LANGUAGE are described in LSB 4.0, although not in depth. Shouldn't the meaning and the format of LANG and LANGUAGE and the difference between these two environment variables be explained in `locale` manpages? -- Simon Paillard -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638186: locale({1,5}) should describe LANG and LANGUAGE
tags 638186 fixed-upstream thanks So, I've added locale(7) in the SEE ALSO references of locale(5) and environ(7). Note that locale(5) describes a FILE, while locale(7) describes environment variables. I also applied the diff below to environ(7). I believe this is sufficient to address the problem. If not, let me know. Cheers, Michael diff --git a/man7/environ.7 b/man7/environ.7 index 4a0f38f..2864b04 100644 --- a/man7/environ.7 +++ b/man7/environ.7 @@ -31,7 +31,7 @@ .\ Modified Wed Jan 24 06:37:24 2001 by Eric S. Raymond (e...@thyrsus.com) .\ Modified Thu Dec 13 23:53:27 2001 by Martin Schulze j...@infodrom.org .\ -.TH ENVIRON 7 2009-07-25 Linux Linux Programmer's Manual +.TH ENVIRON 7 2014-01-18 Linux Linux Programmer's Manual .SH NAME environ \- user environment .SH SYNOPSIS @@ -76,15 +76,19 @@ from the password file The name of a locale to use for locale categories when not overridden by .B LC_ALL -or more specific environment variables like +or more specific environment variables such as .BR LC_COLLATE , .BR LC_CTYPE , .BR LC_MESSAGES , .BR LC_MONETARY , .BR LC_NUMERIC , -.BR LC_TIME , -cf. -.BR locale (5). +and +.BR LC_TIME +(see +.BR locale (7) +for further details of the +.BR LC_* +environment variables). .TP .B PATH The sequence of directory prefixes that @@ -146,8 +150,11 @@ A random collection: The variables .BR LANG , LANGUAGE , NLSPATH , LOCPATH , .BR LC_ALL , LC_MESSAGES , -etc. influence locale handling, cf. -.BR locale (5). +and so on influence locale handling; see +.BR catopen (3), +.BR gettext (3), +and +.BR locale (7). .LP .B TMPDIR influences the path prefix of names created by @@ -251,4 +258,4 @@ should consider renaming their option to .BR putenv (3), .BR setenv (3), .BR unsetenv (3), -.BR locale (5) +.BR locale (7) On Sat, Jan 18, 2014 at 10:53 PM, Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote: My apologies. They are described in the *locale(7)* page. On Sat, Jan 18, 2014 at 10:51 PM, Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote: LANG and LANGUAGE certainly *are* described in the upstream locale(5) page On Sat, Jan 18, 2014 at 11:13 AM, Simon Paillard spaill...@debian.org wrote: Control: -1 retitle locale(5) should describe LANG and LANGUAGE Hi, On Wed, Aug 17, 2011 at 04:18:03PM +0200, Gioele Barabucci wrote: Package: manpages Version: 3.23 The man page for `locale(1)` do not describe the LANG and LANGUAGE environment variables. Note locale(1) is not from manpages package: libc-bin: /usr/share/man/man1/locale.1.gz `environ(7)` describes only LANG and refers to `locale(5)` for further explaination. `locale(5)` do not describe neither LANG or LANGUAGE. Both LANG and LANGUAGE are described in LSB 4.0, although not in depth. Shouldn't the meaning and the format of LANG and LANGUAGE and the difference between these two environment variables be explained in `locale` manpages? -- Simon Paillard -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626983: ferror(): return no error when the stream is closed
Note that the fclose(3) page does already say: RETURN VALUE Upon successful completion 0 is returned. Otherwise, EOF is returned and errno is set to indicate the error. In either case any further access (including another call to fclose()) to the stream results in undefined behavior. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669866: manpages: New manual page: hostname(5)
I'd be willing to take this page into upstream man-pages, but it needs to have a license (see https://www.kernel.org/doc/man-pages/licenses.html). On Tue, May 1, 2012 at 9:04 PM, Tollef Fog Heen tfh...@err.no wrote: ]] Roger Leigh Tollef, would it be possible for systemd to drop hostname(5) and use the common copy? Sure. (You probably didn't intend to attach the second part of your patch, it's an emacs backup file.) Just tell me what version of manpages will provide it and I'll stop shipping once that happens. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574370: manpages-dev: select(2) sets cannot become undefined
tags 574370 fixed-upstream thanks I've made the text: On error, -1 is returned, and errno is set to indicate the error; the file descriptor sets are unmodified, and timeout becomes undefined. Thanks for the report. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669866: manpages: New manual page: hostname(5)
On 04/21/2014 10:04 AM, Petter Reinholdtsen wrote: [Roger Leigh] Sorry, I've not done anything on this lately--I'm not too active in Debian at present due to RSI and other reasons. Petter, would you possibly be able to look into this on the sysvinit side? As far as I can see from URL: https://bugs.debian.org/669866 , the upstream manpages maintainer is waiting for copyright information for the hostname.5 file. This can only be provide by the authors, and nothing I can do from the sysvinit side. Exactly. The page text says it was written by Lennart P and Roger. If they're both agreeable, and have a license, then I'd take the page. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669866: manpages: New manual page: hostname(5)
[Adding Lennart] On 04/21/2014 05:01 PM, Roger Leigh wrote: On Mon, Apr 21, 2014 at 03:39:20PM +0200, Michael Kerrisk (man-pages) wrote: On 04/21/2014 10:04 AM, Petter Reinholdtsen wrote: [Roger Leigh] Sorry, I've not done anything on this lately--I'm not too active in Debian at present due to RSI and other reasons. Petter, would you possibly be able to look into this on the sysvinit side? As far as I can see from URL: https://bugs.debian.org/669866 , the upstream manpages maintainer is waiting for copyright information for the hostname.5 file. This can only be provide by the authors, and nothing I can do from the sysvinit side. Exactly. The page text says it was written by Lennart P and Roger. If they're both agreeable, and have a license, then I'd take the page. For my part, I'm happy for my contributions to this page to be licensed under whatever DFSG-free licence you use for the manpages. Hi Lennart, See https://bugs.debian.org/669866. Roger Leigh has made a proposal that the hostname(5) page should be upstreamed into man-pages. This makes some sense to me, since /etc/hostname is a standard system file (like /etc/paasswwd, /etc/group, etc.), and most of those are documented by man-pages. It appears that the page is currently distributed by both Debian and as part of systemd, and the version referred top in the bug is noted as being written by you and Roger. What do you think of passing this page to man-pages? Does it make sense? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574041: [daniel.bal...@gmail.com: man 2 write - clarification]
On Sun, Mar 14, 2010 at 9:24 PM, Joey Schulze j...@infodrom.org wrote: Package: manpages-dev Version: 3.24-1 Forwarded mail from Daniel. - Forwarded message from Daniel Baluta daniel.bal...@gmail.com - Date: Wed, 10 Mar 2010 12:48:24 +0200 Subject: man 2 write - clarification From: Daniel Baluta daniel.bal...@gmail.com To: ubuntu-devel-disc...@lists.ubuntu.com, j...@debian.org Hello, The following phrase taken from man 2 write manual page is confusing: POSIX requires that a read(2) which can be proved to occur after a write() has returned returns the new data. I think you should you some comas to make a clear statement. POSIX requires that a read(2), which can be proved to occur after a write() has returned, returns the new data. Adding those comma would change the meaning of the sentence, rendering it incorrect. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669866: manpages: New manual page: hostname(5)
@Roger, ping! On Fri, Jan 24, 2014 at 9:57 AM, Michael Kerrisk (man-pages) mtk.manpa...@gmail.com wrote: I'd be willing to take this page into upstream man-pages, but it needs to have a license (see https://www.kernel.org/doc/man-pages/licenses.html). On Tue, May 1, 2012 at 9:04 PM, Tollef Fog Heen tfh...@err.no wrote: ]] Roger Leigh Tollef, would it be possible for systemd to drop hostname(5) and use the common copy? Sure. (You probably didn't intend to attach the second part of your patch, it's an emacs backup file.) Just tell me what version of manpages will provide it and I'll stop shipping once that happens. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728240: Processed: Re: Bug#728240: libc6: S_IFMT constants not included when _POSIX_C_SOURCE is defined as 200112L
tags 728240 fixed-upstream thanks The story sadly is quite complicated. I added the following text to the page upstream: The definitions of most of the above file type test macros are provided if any of the following feature test macros are defined: _BSD_SOURCE (in glibc 2.19 and earlier), _SVID_SOURCE (in glibc 2.19 and earlier), or _DEFAULT_SOURCE (in glibc 2.20 and later). In addition, definitions of all of the above macros except S_IFSOCK and S_ISSOCK() are provided if _XOPEN_SOURCE is defined. The definition of S_IFSOCK can also be exposed by defining _XOPEN_SOURCE with a value of 500 or greater. The definition of S_ISSOCK() is exposed if any of the following feature test macros is defined: _BSD_SOURCE (in glibc 2.19 and earlier), _DEFAULT_SOURCE (in glibc 2.20 and later), _XOPEN_SOURCE with a value of 500 or greater, or _POSIX_C_SOURCE with a value of 200112L or greater. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729436: [libc6-dev] strcasecmp declared twice
tags 729436 fixed-upstream thanks On 05/05/2014 05:53 PM, Aurelien Jarno wrote: reassign 729436 manpages-dev retitle 729436 manpages-dev: please explain why strcasecmp(3) is defined in both string.h and strings.h thanks On Tue, Nov 12, 2013 at 10:26:56PM +0200, Török Edwin wrote: Package: libc6-dev Version: 2.17-93 Severity: normal --- Please enter the report below this line. --- According to strcasecmp(3) and strcasecmp(3p) the function strcasecmp should be declared in strings.h. However it is actually declared both in string.h and strings.h: /usr/include/string.h:extern int strcasecmp (const char *__s1, const char *__s2) /usr/include/string.h:extern int strcasecmp_l (const char *__s1, const char *__s2, /usr/include/strings.h:extern int strcasecmp (const char *__s1, const char *__s2) /usr/include/strings.h:extern int strcasecmp_l (const char *__s1, const char *__s2, __locale_t __loc) If the declaration in string.h is a typo, please remove it. This is not a typo, but there for historical reasons. The strcasecmp() and strncasecmp() functions first appeared in 4.4BSD and have been introduced the same way in the GNU libc. Their prototypes existed previously in string.h before they were moved to strings.h for IEEE Std 1003.1-2001 (POSIX.1) compliance, as string.h is supposed to be for ISO C functions, and strcasecmp() is not an ISO C function. The prototype in string.h has been kept for compatibility reasons. Otherwise please update the manpage to mention that on Linux the function is actually declared in both string.h and strings.h, and you should check yourself that you included strings.h because you won't get any warning from the compiler about implicit declarations. I am therefore reassigning this bug to the manpages-dev package to update the corresponding manpage. Fair enough. Upstream, I have added the following text under NOTES: The strcasecmp() and strncasecmp() functions first appeared in 4.4BSD, where they were declared in string.h. Thus, for reasons of historical compatibility, the glibc string.h header file also declares these functions, if the _DEFAULT_SOURCE (or, in glibc 2.19 and earlier, _BSD_SOURCE) feature test macro is defined. Okay? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#344233: Bug still exists
On 09/01/2013 03:43 AM, Thomas Hood wrote: In Debian 7 the host.conf(5) man page still describes the order option which has been inoperative for years and still refers to resolv+(8) which doesn't exist. And it still fails to mention nsswitch.conf. I've queued a fix for this upstream. Cheers, Michael Original Message Subject: Re: [PATCH] host.conf(5): order option deprecated, replaced by nsswitch.conf(5) Date: Sat, 17 May 2014 17:15:22 +0200 From: Michael Kerrisk (man-pages) mtk.manpa...@gmail.com To: Simon Paillard spaill...@debian.org, linux-...@vger.kernel.org CC: mtk.manpa...@gmail.com On 12/09/2012 06:13 PM, Simon Paillard wrote: http://www.sourceware.org/bugzilla/show_bug.cgi?id=2389 http://repo.or.cz/w/glibc.git/commit/b9c65d0902e5890c4f025b574725154032f8120a Reported at http://bugs.debian.org/270368 http://bugs.debian.org/396633 [...] Simon, I propose the patch below. Look okay to you? Cheers, Michael diff --git a/man3/resolver.3 b/man3/resolver.3 index a3fd2e8..7dc2002 100644 --- a/man3/resolver.3 +++ b/man3/resolver.3 @@ -29,7 +29,7 @@ .\ Modified 1993-07-25 by Rik Faith (fa...@cs.unc.edu) .\ Modified 2004-10-31 by aeb .\ -.TH RESOLVER 3 2013-03-05 GNU Linux Programmer's Manual +.TH RESOLVER 3 2014-05-17 GNU Linux Programmer's Manual .SH NAME res_init, res_query, res_search, res_querydomain, res_mkquery, res_send, dn_comp, dn_expand \- resolver routines @@ -90,7 +90,7 @@ The .BR res_init () function reads the configuration files (see .BR resolv.conf (5)) -to get the default domain name, search order and name +to get the default domain name and name server address(es). If no server is given, the local host is tried. If no domain is given, that associated with the local host is used. diff --git a/man5/host.conf.5 b/man5/host.conf.5 index a289cb4..e3d9073 100644 --- a/man5/host.conf.5 +++ b/man5/host.conf.5 @@ -23,7 +23,7 @@ .\ %%%LICENSE_END .\ .\ 2003-08-23 Martin Schulze j...@infodrom.org Updated according to glibc 2.3.2 -.TH HOST.CONF 5 2003-08-23 Linux Linux System Administration +.TH HOST.CONF 5 2014-05-17 Linux Linux System Administration .SH NAME host.conf \- resolver configuration file .SH DESCRIPTION @@ -32,15 +32,7 @@ The file contains configuration information specific to the resolver library. It should contain one configuration keyword per line, followed by appropriate configuration information. -The keywords recognized are -.IR order , trim , multi , nospoof , spoof , and reorder . -These keywords are described below. -.TP -.I order -This keyword specifies how host lookups are to be performed. -It should be followed by one or more lookup methods, separated by commas. -Valid methods are -.IR bind , hosts , and nis . +The following keywords are recognized: .TP .I trim This keyword may be listed more than once. @@ -133,19 +125,14 @@ Reordering is done for all lookup methods. The default value is .IR off . .SH ENVIRONMENT -There are six environment variables that can be used to allow users to +The following environment variables can be used to allow users to override the behavior which is configured in -.IR /etc/host.conf . +.IR /etc/host.conf : .TP .B RESOLV_HOST_CONF If set, this variable points to a file that should be read instead of .IR /etc/host.conf . .TP -.B RESOLV_SERV_ORDER -Overrides the -.I order -command. -.TP .B RESOLV_SPOOF_CHECK Overrides the .IR nospoof , spoofalert and spoof @@ -196,8 +183,25 @@ and a new environment variable can take arguments like .IR off , nowarn and warn . Line comments can appear anywhere and not only at the beginning of a line. +.SS Historical +In glibc 2.4 and earlier, the following keyword is recognized: +.TP +.I order +This keyword specifies how host lookups are to be performed. +It should be followed by one or more lookup methods, separated by commas. +Valid methods are +.IR bind , hosts , and nis . +The +.B RESOLV_SERV_ORDER +environment variable could be used to override the +.I order +command. +.PP +The +.BR nsswitch.conf (5) +file is the modern way of controlling the order of host lookups. .SH SEE ALSO .BR gethostbyname (3), +.BR nsswitch.conf (5) .BR hostname (7), -.BR named (8), -.BR resolv+ (8) +.BR named (8) diff --git a/man5/resolv.conf.5 b/man5/resolv.conf.5 index 3680a82..f9a0ba1 100644 --- a/man5/resolv.conf.5 +++ b/man5/resolv.conf.5 @@ -20,7 +20,7 @@ .\ .\ Added ndots remark by Bernhard R. Link - debian bug #182886 .\ -.TH RESOLV.CONF 5 2014-02-22 Linux Programmer's Manual +.TH RESOLV.CONF 5 2014-05-17 Linux Programmer's Manual .UC 4 .SH NAME resolv.conf \- resolver configuration file @@ -290,6 +290,7 @@ in the first column are treated as comments. .SH SEE ALSO .BR gethostbyname (3), .BR resolver (3), +.BR nsswitch.conf (5) .BR hostname (7), .BR named (8) .br -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training
Bug#669866: manpages: New manual page: hostname(5)
Hi Lennart, On Wed, Apr 23, 2014 at 7:15 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 23.04.14 07:42, Michael Kerrisk (man-pages) (mtk.manpa...@gmail.com) wrote: On 04/21/2014 05:01 PM, Roger Leigh wrote: On Mon, Apr 21, 2014 at 03:39:20PM +0200, Michael Kerrisk (man-pages) wrote: On 04/21/2014 10:04 AM, Petter Reinholdtsen wrote: [Roger Leigh] Sorry, I've not done anything on this lately--I'm not too active in Debian at present due to RSI and other reasons. Petter, would you possibly be able to look into this on the sysvinit side? As far as I can see from URL: https://bugs.debian.org/669866 , the upstream manpages maintainer is waiting for copyright information for the hostname.5 file. This can only be provide by the authors, and nothing I can do from the sysvinit side. Exactly. The page text says it was written by Lennart P and Roger. If they're both agreeable, and have a license, then I'd take the page. For my part, I'm happy for my contributions to this page to be licensed under whatever DFSG-free licence you use for the manpages. Hi Lennart, See https://bugs.debian.org/669866. Roger Leigh has made a proposal that the hostname(5) page should be upstreamed into man-pages. This makes some sense to me, since /etc/hostname is a standard system file (like /etc/paasswwd, /etc/group, etc.), and most of those are documented by man-pages. It appears that the page is currently distributed by both Debian and as part of systemd, and the version referred top in the bug is noted as being written by you and Roger. What do you think of passing this page to man-pages? Does it make sense? I don't mind if the man page is added to the manpages package under any license you like, but do note that /etc/hostname is a Debianism, which we added to systemd and thus is now supported by the union of Debian-derived distributions and those which adopted systemd. I am not sure what the rules regarding what belongs in the manpages package is, but I have the suspicion that at least Slackware and Gentoo don't have this file. Also, in the systemd context the man page refers to hostnamectl(1) which doesn't exist outside of systemd, and we make stricter recommendations on the hostname to store in /etc/hostname than debian probably traditionally made. Thanks for the above details, which I was unaware of. Sounds to me like it would be best not to take this into man-pages. I'll leave Debian to work out what they want to do. How does the Debian version of the man page look like? Is it available online? How would the version you'd add to the manpages package look like? See below. The systemd version you find here: http://www.freedesktop.org/software/systemd/man/hostname.html Looks pretty similar. Cheers, Michael diff -urN manpages-3.35.original/man5/hostname.5 manpages-3.35/man5/hostname.5 --- manpages-3.35.original/man5/hostname.51970-01-01 01:00:00.0 +0100 +++ manpages-3.35/man5/hostname.52012-04-21 14:53:11.618069753 +0100 @@ -0,0 +1,33 @@ +.TH HOSTNAME 5 2012-04-09 Linux Linux Programmer's Manual +.SH NAME +/etc/hostname \- local host name configuration +.SH DESCRIPTION +The +.B /etc/hostname +file configures the name of the local system that is set during boot, +with the +.BR hostname (1) +command. It should contain a single newline-terminated host name +string. The host name may be a free-form string up to 64 characters in +length, however it is recommended that it consists only of 7bit ASCII +lower-case characters and no spaces or dots, and limits itself to the +format allowed for DNS domain name labels, even though this is not a +strict requirement. +.PP +Depending on the operating system other configuration files might be +checked for configuration of the host name as well, however only as a +fallback. +.SH FILES +.I /etc/hostname +.SH NOTES +The hostname file and format are supported by both the Debian System V +init system (initscripts) and systemd. +.SH SEE ALSO +.PP +.BR hostname (1), +.BR sethostname (2), +.BR hostname (7). +.SH AUTHORS +.PP +Lennart Poettering lenn...@poettering.net and Roger Leigh +rle...@debian.org. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745775: manpages-dev: connect(2) does not document EADDRNOTAVAIL
William, this report is a little vague... Do you have a *minimal* program that demonstrates the problem? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745775: manpages-dev: connect(2) does not document EADDRNOTAVAIL
On 04/25/2014 11:02 PM, William Morriss wrote:
Okay I was able to do it without fork. This one been tested on Arch
Linux and Ubuntu. It's simpler I think and also won't give the bind
error. It's below and attached.
William,
Thanks for that. I've got it now, I think. The point is I think
that you are running out of ephemeral ports on the system. An
ephemeral port is a random port number that an Internet domain
socket is assigned during any of the following operations:
* bind(), specifying a port number of 0
* listen() on an unbound socket
* connect() on an unbound socket
* sendto() on an unbound socket
The point is that port numbers are 16 bits long, and the ephemeral port
numbers that are used by unprivileged processes is restricted to the
range given in /proc/sys/net/ipv4/ip_local_port_range (see the ip(7) man
page).
I've appended an even simpler program below that I think produces
the error for the same reason as your program. (You may need to
run as root and up your open files limit (ulimit -n) when
testing this.) You might want to confirm that it's doing something
equivalent your program, in terms of triggering the error.
Funnily enough, someone asked me the other day what happens if you
run out of ephemeral ports, and I replied that the relevant system
call would get an error. The next question was: what error? I said
I didn't know (was a way from a machine, so could not check the
man page). And now we see that the error is not in a man page.
However, things are sadly a little worse than I expected. The various
cases above give different errors if the ephemeral port range is
exhausted:
* listen() and bind() give EADDRINUSE
* connect() gives EADDRNOTAVAIL
* sendto() gives EAGAIN
I will add this text to connect()
EADDRNOTAVAIL
(Internet domain sockets) The socket referred to by
sockfd had not previously been bound to an address and,
upon attempting to bind it to an ephemeral port, it was
determined that all port numbers in the ephemeral port
range are currently in use. See the discussion of
/proc/sys/net/ipv4/ip_local_port_range in ip(7).
and similar text to the other pages. And I've updated the text in
ip(7) to say
ip_local_port_range (since Linux 2.2)
This file contains two integers that define the default
local port range allocated to sockets that are not
explicitly bound to a port number—that is, the range
used for ephemeral ports. An ephemeral port is allo‐
cated to a socket in the following circumstances:
* the port number in a socket address is specified as 0
when calling bind(2);
* listen(2) is called on a stream socket that was not
previously bound;
* connect(2) was called on a socket that was not not
previously bound;
* sendto(2) is called on a datagram socket that was not
not previously bound.
Allocation of ephemeral ports starts with the first num‐
ber in ip_local_port_range and ends with the second num‐
ber. If the range of ephemeral ports is exhausted, then
the relevant system call returns an error (but see BUGS)
Note that the port range in ip_local_port_range should
not conflict with the ports used by masquerading
(although the case is handled). Also, arbitrary choices
may cause problems with some firewall packet filters
that make assumptions about the local ports in use. The
first number should be at least greater than 1024, or
better, greater than 4096, to avoid clashes with well
known ports and to minimize firewall problems.
Thanks for the report.
Cheers,
Michael
/*#* consume_ephemeral_ports_connect.c
Determine what error is generated when connect() is
unable to obtain an ephemeral port.
Usage: ./consume_ephemeral_ports_connect [num-loops [sleep-secs]]
*/
/*#**
Change history
Apr 14Initial creation
*/
#include netinet/in.h
#include arpa/inet.h
#include sys/socket.h
#include sys/types.h
#include stdio.h
#include stdlib.h
#include unistd.h
#include string.h
#include limits.h
#define errMsg(msg) do { perror(msg); } while (0)
#define errExit(msg)do { perror(msg); exit(EXIT_FAILURE); \
} while (0)
int
main(int argc, char *argv[])
{
struct sockaddr_in svaddr, claddr;
int sfd, cfd, afd, limit, j;
socklen_t len;
limit = (argc 1) ? atoi(argv[1]) : INT_MAX;
sfd = socket(AF_INET, SOCK_STREAM, 0);
if (sfd == -1)
errExit(socket);
memset(svaddr, 0, sizeof(struct sockaddr_in));
svaddr.sin_family = AF_INET;
svaddr.sin_addr.s_addr = htonl(INADDR_ANY);
svaddr.sin_port = 0;
if (bind(sfd, (struct sockaddr *) svaddr,
sizeof(struct sockaddr_in)) == -1)
Bug#746569: getrusage: documents how to get RUSAGE_THREAD
tags 746569 fixed-upstream thanks [forgot to CC control@ on last mail...] On 05/01/2014 04:19 PM, Bill Allombert wrote: Package: manpages-dev Version: 3.61-1 Severity: normal Hello Simon, man getrusage documents RUSAGE_THREAD. However, as far as I can see, this symbol is only available if _GNU_SOURCE is defined, but this is not documented. So either libc-dev or manpages-dev should be fixed to match. Cheers, -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746569: getrusage: documents how to get RUSAGE_THREAD
tags 746569 fixed-upstream thanks On 05/01/2014 04:19 PM, Bill Allombert wrote: Package: manpages-dev Version: 3.61-1 Severity: normal Hello Simon, man getrusage documents RUSAGE_THREAD. However, as far as I can see, this symbol is only available if _GNU_SOURCE is defined, but this is not documented. So either libc-dev or manpages-dev should be fixed to match. It's the man page that needs a fix. I'll add a note that _GNU_SOURCE is required. Thanks for the report, Bill. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708394: manpages-dev: connect(2) does not documment EPROTOTYPE
tags 708394 fixed-upstream thanks I added the following text to the man page: EPROTOTYPE The socket type does not support the requested communi‐ cations protocol. This error can occur, for example, on an attempt to connect a UNIX domain datagram socket to a stream socket. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748887: manpages-dev: Mistake in STDIO(3) manpage
tags 748887 fixed-upstream thanks Colin, Thanks for reporting that. That text bug had been there for 20 years! Fixed now, after a patch from Simon Paillard. Cheers, Michael On Wed, May 21, 2014 at 10:26 PM, Colin Williams colinwilliams1...@gmail.com wrote: Package: manpages-dev Version: 3.65-1 Severity: normal Dear Maintainer, The stdio manpage seems to have a mistake in the following sentence: At program startup, three text streams are predefined and need not be opened explicitly: standard input (for reading conventional input), standard output (for writing conventional input), and standard error (for writing diagnostic output). I believe the description of standard output should say: standard output (for writing conventional output). I am running Debian 7.5, however I downloaded the Unstable package (3.65-1), and looked in stdio.3.gz, the error still appears to be there. -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748926: manpages-dev: umask(2) example unclear
On Thu, May 22, 2014 at 12:40 PM, wxcafe wxc...@wxcafe.net wrote: Package: manpages-dev Version: 3.65-1 Severity: minor Dear Maintainer, the man page for umask(2) is a bit unclear, in that it contains the following line : 0666 ~022 = 0644; i.e., rw-r--r-- that is slightly misleading (took me ~6 hours to understand where the problem was coming from) for anyone who doesn't use ~ as NOT. Suggested fix : replace that line with something like 0666 ! 022 = 0644; since 110 110 110 NAND 000 010 010 = 110 100 100; i.e., rw-r--r-- But ~ *is* the C bitwise-NOT operator. So I don't understand this piece: for anyone who doesn't use ~ as NOT... Thus, the existing text seems fine to me. Cheers, Michael -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages manpages-dev depends on: ii manpages 3.65-1 manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii man-db [man-browser] 2.6.7.1-1 -- no debconf information -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756599: printf(3) manpage: stray asterisk in NAN*
Jakub, I do not know the details here, but are you sure this is wrong? The preceding part of the sentence says [and a string starting with nan for NaN, in the case of f conversion], and I take the * to mean a wildcard pattern match, analogous with [a string starting with nan for NaN]. This is just my guess though. Cheers, Michael On Thu, Jul 31, 2014 at 10:58 AM, Jakub Wilk jw...@debian.org wrote: Package: manpages-dev Version: 3.65-1 Severity: minor The printf(3) manpage reads: The C99 standard specifies [-]inf or [-]infinity for infinity, and a string starting with nan for NaN, in the case of f conversion, and [-]INF or [-]INFINITY or NAN* in the case of F conversion.) Please remove the stray asterisk after NAN. -- Jakub Wilk -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756599: printf(3) manpage: stray asterisk in NAN*
Could you make this character italic, to make it clear it is not literal? Without being sure of the details, I am reluctant to make any change. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756602: printf(3) manpage: please document that %n can't include flags, width or precision
tags 756602 fixed-upstream thanks Hello Jakub, I've applied the patch below. Cheers, Michael --- a/man3/printf.3 +++ b/man3/printf.3 @@ -332,9 +332,7 @@ For other conversions, the behavior is undefined. .B \- The converted value is to be left adjusted on the field boundary. (The default is right justification.) -Except for -.B n -conversions, the converted value is padded on the right with blanks, rather +The converted value is padded on the right with blanks, rather than on the left with blanks or zeros. A .B \- @@ -788,10 +786,17 @@ or .TP .B n The number of characters written so far is stored into the integer -indicated by the -.I int\ * -(or variant) pointer argument. +pointed to by the corresponding argument. +That argument shall be an +.I int\ *, +or variant, as specified by the +.B l +or +.B ll +length modifier. No argument is converted. +The behavior is undefined if the conversion specification includes +any flags, a field width, or a precision. .TP .B m (Glibc extension.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756602: printf(3) manpage: please document that %n can't include flags, width or precision
On Thu, Jul 31, 2014 at 6:41 PM, Jakub Wilk jw...@debian.org wrote: * Michael Kerrisk mtk.manpa...@gmail.com, 2014-07-31, 12:42: I've applied the patch below. Thanks! +That argument shall be an +.I int\ *, +or variant, as specified by the +.B l +or +.B ll +length modifier. Hmm. Why only l or ll? According to the C99 standard, all the length modifiers that can be used with integer conversions (hh, h, l, ll, j, z, t) can be also used with %n. -- Jakub Wilk Good point. How about: [[ That argument shall be an .I int\ *, or variant whose size matches the (optionally) supplied integer length modifier. ]] ? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756602: printf(3) manpage: please document that %n can't include flags, width or precision
On Fri, Aug 1, 2014 at 12:46 PM, Jakub Wilk jw...@debian.org wrote: * Michael Kerrisk mtk.manpa...@gmail.com, 2014-08-01, 08:55: [[ That argument shall be an .I int\ *, or variant whose size matches the (optionally) supplied integer length modifier. ]] Looks good to me, thanks! Now I noticed that in the The length modifier subsection, the n conversion is mentioned only in the descriptions of hh, h, l, and ll. Could we make it more consistent? I applied the below. Thanks, Michael diff --git a/man3/printf.3 b/man3/printf.3 index 47fdf2c..47fa149 100644 --- a/man3/printf.3 +++ b/man3/printf.3 @@ -527,6 +527,10 @@ A following integer conversion corresponds to an .I intmax_t or .I uintmax_t +argument, or a following +.B n +conversion corresponds to a pointer to an +.I intmax_t argument. .TP .B z @@ -534,6 +538,10 @@ A following integer conversion corresponds to a .I size_t or .I ssize_t +argument, or a following +.B n +conversion corresponds to a pointer to a +.I size_t argument. .\ (Linux libc5 has .\ .B Z @@ -543,6 +551,10 @@ argument. .B t A following integer conversion corresponds to a .I ptrdiff_t +argument, or a following +.B n +conversion corresponds to a pointer to a +.I ptrdiff_t argument. .PP SUSv2 knows about only the length modifiers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758293: /usr/share/man/man3/drand48.3.gz: rand48() incorrectly declared obsolete
tags 758293 fixed-upstream thanks On 08/16/2014 04:52 AM, Lorenzo Beretta wrote: Package: manpages-dev Version: 3.65-1 Severity: minor File: /usr/share/man/man3/drand48.3.gz Dear Maintainer, see Keith Thompson's detailed explanation at http://stackoverflow.com/a/25276434. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages manpages-dev depends on: ii manpages 3.65-1 manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii konqueror [man-browser] 4:4.13.3-1 ii man-db [man-browser] 2.6.7.1-1 I've simply removed the sentence about SVID. drand48() is in current POSIX. It's unclear why SVID 3 would have marked it obsolete, but that's crufty information that--as you seem to realize--only serves to pointlessly worry people. Thanks for the report. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775328: manpages: urandom manpage is misleading
tags 775328 fixed-upstream thanks Mathieu, On 14 January 2015 at 08:57, Mathieu Malaterre ma...@debian.org wrote: Package: manpages Version: 3.74-1 Severity: normal Dear Maintainer, The manpage for `urandom` is misleading, at least with recent linux kernel. The current man page reads as: [...] A read from the /dev/urandom device will not block waiting for more entropy. [...] However since commit 79a8468747c5 only a maximum of 32MB are returned. It should be clarified in the documentation that urandom only return random data within this size. See: https://bugzilla.kernel.org/show_bug.cgi?id=80981#c9 Full reference: http://unix.stackexchange.com/a/178957/32896 Suggested patch: [...] A read from the /dev/urandom device will not block waiting for more entropy, but will only return random bytes with a maximum of 32MB per read(2) system call. [...] Thanks for the report. In upstream, I've added a sentence similar to your proposal. Cheers, Michael -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) manpages depends on no packages. manpages recommends no packages. Versions of packages manpages suggests: ii man-db [man-browser] 2.7.0.2-5 -- no debconf information -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773443: host.conf.5: spoof deprecated ?
Hello Stéphane, On 10 March 2015 at 00:26, Stéphane Aulery saul...@free.fr wrote: Hello Michael, Le lundi 09 mars 2015 à 10:03:09, Michael Kerrisk (man-pages) a écrit : On 03/09/2015 08:59 AM, Stéphane Aulery wrote: Le lundi 09 mars 2015 à 08:22:01, Michael Kerrisk (man-pages) a écrit : On 03/08/2015 02:05 PM, Stéphane Aulery wrote: A Debian user reported that [1]: spoof* keywords (nospoof, spoofalert, spoof) are here from 1996, they are still valid keywords but do not have any effect apparently, no libraries or tools use them it is misleading to see references to resolv+ and rlogin, the keywords are just ignored these days; the only meaning they have is that they are allowed by host.conf syntax The glibc source code seems to confirm that the keywords nospoof, spoofalert and spoof are accepted but without effects. I could find nothing in the changelog. Could you please confirm that they are obsolete? I could correct the man page accordingly. I had a quick grep in the glibc source code. It appears that you (and the reporter) are correct. (Even back in glibc 2.1, things look the same). A patch would be appreciated! I dug a little further comparing versions 2.0.6 [1], 2.0.7 [2] and trunk [3] of glibc and I come to a different conclusion. The keywords nospoof, spoofalert, spoof and RESOLV_SPOOF_CHECK were added to glibc 2.0.7 but never implemented and documented in the changelog. Perfect -- that's exactly the sort of detail it's great to have in man-pages! Cheers, Michael [1] http://ftp.gnu.org/gnu/glibc/glibc-2.0.6.tar.gz [2] http://archive.debian.org/debian/dists/hamm/main/source/libs/glibc_2.0.7t.orig.tar.gz [3] https://sourceware.org/git/?p=glibc.gita=searchh=HEADst=greps=spoofsr=1 Regards, -- Stéphane Aulery -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773443: [PATCH] host.conf.5: keywords and env. var. nospoof, spoofalert, spoof and RESOLV_SPOOF_CHECK were added to glibc 2.0.7 but never implemented
On 03/10/2015 12:27 AM, Stéphane Aulery wrote: Move descriptions to historical section and reorder it for clarity Thanks, Stéphane. Applied. But please make patch titles shorter (72 chars) --move text to the body of the commit message as needed. Thanks, Michael Debian Bug #773443 reported by yg...@ygrex.ru https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773443 Signed-off-by: Stéphane Aulery saul...@free.fr --- man5/host.conf.5 | 125 --- 1 file changed, 63 insertions(+), 62 deletions(-) diff --git a/man5/host.conf.5 b/man5/host.conf.5 index 9ff2ed3..08da435 100644 --- a/man5/host.conf.5 +++ b/man5/host.conf.5 @@ -66,52 +66,6 @@ This is by default, as it may cause a substantial performance loss at sites with large hosts files. .TP -.I nospoof -Valid values are -.IR on and off . -If set to -.IR on , -the resolv+ library will attempt to prevent hostname spoofing to -enhance the security of -.BR rlogin and rsh . -It works as follows: after performing a host address lookup, resolv+ -will perform a hostname lookup for that address. -If the two hostnames -do not match, the query will fail. -The default value is -.IR off . -.TP -.I spoofalert -Valid values are -.IR on and off . -If this option is set to -.I on -and the -.I nospoof -option is also set, resolv+ will log a warning of the error via the -syslog facility. -The default value is -.IR off . -.TP -.I spoof -Valid values are -.IR off , nowarn and warn . -If this option is set to -.IR off , -spoofed addresses are permitted and no warnings will be emitted -via the syslog facility. -If this option is set to -.IR warn , -resolv+ will attempt to prevent hostname spoofing to -enhance the security and log a warning of the error via the syslog -facility. -If this option is set to -.IR nowarn , -the resolv+ library will attempt to prevent hostname spoofing to -enhance the security but not emit warnings via the syslog facility. -Setting this option to anything else is equal to setting it to -.IR nowarn . -.TP .I reorder Valid values are .IR on and off . @@ -133,15 +87,6 @@ override the behavior which is configured in If set, this variable points to a file that should be read instead of .IR /etc/host.conf . .TP -.B RESOLV_SPOOF_CHECK -Overrides the -.IR nospoof , spoofalert and spoof -commands in the same way as the -.I spoof -command is parsed. -Valid values are -.IR off , nowarn and warn . -.TP .B RESOLV_MULTI Overrides the .I multi @@ -184,6 +129,10 @@ can take arguments like .IR off , nowarn and warn . Line comments can appear anywhere and not only at the beginning of a line. .SS Historical +The +.BR nsswitch.conf (5) +file is the modern way of controlling the order of host lookups. +.PP In glibc 2.4 and earlier, the following keyword is recognized: .TP .I order @@ -191,15 +140,67 @@ This keyword specifies how host lookups are to be performed. It should be followed by one or more lookup methods, separated by commas. Valid methods are .IR bind , hosts , and nis . -The +.TP .B RESOLV_SERV_ORDER -environment variable could be used to override the -.I order -command. +Overrides the order command. .PP -The -.BR nsswitch.conf (5) -file is the modern way of controlling the order of host lookups. +Since glibc 2.0.7, the following keywords and environment variable have +been recognized but never implemented: +.TP +.I nospoof +Valid values are +.IR on and off . +If set to +.IR on , +the resolv+ library will attempt to prevent hostname spoofing to +enhance the security of +.BR rlogin and rsh . +It works as follows: after performing a host address lookup, resolv+ +will perform a hostname lookup for that address. +If the two hostnames +do not match, the query will fail. +The default value is +.IR off . +.TP +.I spoofalert +Valid values are +.IR on and off . +If this option is set to +.I on +and the +.I nospoof +option is also set, resolv+ will log a warning of the error via the +syslog facility. +The default value is +.IR off . +.TP +.I spoof +Valid values are +.IR off , nowarn and warn . +If this option is set to +.IR off , +spoofed addresses are permitted and no warnings will be emitted +via the syslog facility. +If this option is set to +.IR warn , +resolv+ will attempt to prevent hostname spoofing to +enhance the security and log a warning of the error via the syslog +facility. +If this option is set to +.IR nowarn , +the resolv+ library will attempt to prevent hostname spoofing to +enhance the security but not emit warnings via the syslog facility. +Setting this option to anything else is equal to setting it to +.IR nowarn . +.TP +.B RESOLV_SPOOF_CHECK +Overrides the +.IR nospoof , spoofalert and spoof +commands in the same way as the +.I spoof +command is parsed. +Valid values are +.IR
Bug#773443: host.conf.5: spoof deprecated ?
On 03/09/2015 08:59 AM, Stéphane Aulery wrote: Le lundi 09 mars 2015 à 08:22:01, Michael Kerrisk (man-pages) a écrit : Hello Stéphane On 03/08/2015 02:05 PM, Stéphane Aulery wrote: ** COPY OF GLIBC BUGZILLA #18091 FOR INFORMATION ** https://sourceware.org/bugzilla/show_bug.cgi?id=18091 - Hello, A Debian user reported that [1]: spoof* keywords (nospoof, spoofalert, spoof) are here from 1996, they are still valid keywords but do not have any effect apparently, no libraries or tools use them it is misleading to see references to resolv+ and rlogin, the keywords are just ignored these days; the only meaning they have is that they are allowed by host.conf syntax The glibc source code seems to confirm that the keywords nospoof, spoofalert and spoof are accepted but without effects. I could find nothing in the changelog. Could you please confirm that they are obsolete? I could correct the man page accordingly. I had a quick grep in the glibc source code. It appears that you (and the reporter) are correct. (Even back in glibc 2.1, things look the same). A patch would be appreciated! Eventually, I may check others values too. Do you to want to drop obsolete values or add a note ? Best to keep a note that they exist, but do nothing. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773443: host.conf.5: spoof deprecated ?
Hello Stéphane On 03/08/2015 02:05 PM, Stéphane Aulery wrote: ** COPY OF GLIBC BUGZILLA #18091 FOR INFORMATION ** https://sourceware.org/bugzilla/show_bug.cgi?id=18091 - Hello, A Debian user reported that [1]: spoof* keywords (nospoof, spoofalert, spoof) are here from 1996, they are still valid keywords but do not have any effect apparently, no libraries or tools use them it is misleading to see references to resolv+ and rlogin, the keywords are just ignored these days; the only meaning they have is that they are allowed by host.conf syntax The glibc source code seems to confirm that the keywords nospoof, spoofalert and spoof are accepted but without effects. I could find nothing in the changelog. Could you please confirm that they are obsolete? I could correct the man page accordingly. I had a quick grep in the glibc source code. It appears that you (and the reporter) are correct. (Even back in glibc 2.1, things look the same). A patch would be appreciated! Cheers, Michael PS For reports like this, when you've checked things, it would speed things a little to note how you deduced your info (e.g., reference to source file and function). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773443 -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630029: Processed: retitle 630029 to read/write/readv/writev/sendfile.2: undocumented cap on number of bytes read/written
tags 630029 fixed-upstream thanks And here's the documentation fix. Thanks, Michael diff --git a/man2/pread.2 b/man2/pread.2 index de1e951..c7a7fdd 100644 --- a/man2/pread.2 +++ b/man2/pread.2 @@ -85,6 +85,12 @@ and .BR pwrite () returns the number of bytes written. +Note that is not an error for a successful call to transfer fewer bytes +than requested (see +.BR read (2) +and +.BR write (2)). + On error, \-1 is returned and .I errno is set to indicate the cause of the error. diff --git a/man2/read.2 b/man2/read.2 index 62d7d8b..c581f72 100644 --- a/man2/read.2 +++ b/man2/read.2 @@ -87,6 +87,8 @@ available right now (maybe because we were close to end-of-file, or because we are reading from a pipe, or from a terminal), or because .BR read () was interrupted by a signal. +See also NOTES. + On error, \-1 is returned, and .I errno is set appropriately. @@ -178,6 +180,14 @@ or to return the number of bytes already read. .SH CONFORMING TO SVr4, 4.3BSD, POSIX.1-2001. .SH NOTES +On Linux, +.BR read () +(and similar system calls) will transfer at most +0x7000 (2,147,479,552) bytes, +returning the number of bytes actually transferred. +.\ commit e28cc71572da38a5a12c1cfe4d7032017adccf69 +(This is true on both 32-bit and 64-bit systems.) + On NFS filesystems, reading small amounts of data will update the timestamp only the first time, subsequent calls may not do so. This is caused diff --git a/man2/readv.2 b/man2/readv.2 index 3cc0813..3cf0c2f 100644 --- a/man2/readv.2 +++ b/man2/readv.2 @@ -184,6 +184,13 @@ return the number of bytes read; and .BR pwritev () return the number of bytes written. + +Note that is not an error for a successful call to transfer fewer bytes +than requested (see +.BR read (2) +and +.BR write (2)). + On error, \-1 is returned, and \fIerrno\fP is set appropriately. .SH ERRORS The errors are as given for diff --git a/man2/sendfile.2 b/man2/sendfile.2 index 972564c..ef9ba6c 100644 --- a/man2/sendfile.2 +++ b/man2/sendfile.2 @@ -113,6 +113,7 @@ Note that a successful call to .BR sendfile () may write fewer bytes than requested; the caller should be prepared to retry the call if there were unsent bytes. +See also NOTES. On error, \-1 is returned, and .I errno @@ -166,6 +167,12 @@ Other UNIX systems implement with different semantics and prototypes. It should not be used in portable programs. .SH NOTES +.BR sendfile () +will transfer at most 0x7000 (2,147,479,552) bytes, +returning the number of bytes actually transferred. +.\ commit e28cc71572da38a5a12c1cfe4d7032017adccf69 +(This is true on both 32-bit and 64-bit systems.) + If you plan to use .BR sendfile () for sending files to a TCP socket, but need diff --git a/man2/write.2 b/man2/write.2 index 90ef9b5..3e8c363 100644 --- a/man2/write.2 +++ b/man2/write.2 @@ -89,6 +89,10 @@ Note that not all filesystems are POSIX conforming. .SH RETURN VALUE On success, the number of bytes written is returned (zero indicates nothing was written). +It is not an error if this number is smaller than the number of bytes +requested; this may happen for example because the disk device was filled. +See also NOTES. + On error, \-1 is returned, and \fIerrno\fP is set appropriately. @@ -217,6 +221,14 @@ then the call fails with the error .BR EINTR ; if it is interrupted after at least one byte has been written, the call succeeds, and returns the number of bytes written. + +On Linux, +.BR read () +(and similar system calls) will transfer at most +0x7000 (2,147,479,552) bytes, +returning the number of bytes actually transferred. +.\ commit e28cc71572da38a5a12c1cfe4d7032017adccf69 +(This is true on both 32-bit and 64-bit systems.) .SH BUGS According to POSIX.1-2008/SUSv4 Section XSI 2.9.7 (Thread Interactions with Regular File Operations): -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621057: printf.3: ATTRIBUTES: Note functions those are thread-safe
On 03/23/2015 04:24 AM, Zeng Linggang wrote:
The markings match glibc markings.
Hello Zeng Linggang,
This patch seems to have been sent twice...
Cheers,
Michael
Signed-off-by: Zeng Linggang zenglg...@cn.fujitsu.com
Signed-off-by: Ma Shimiao mashimiao.f...@cn.fujitsu.com
---
man3/printf.3 | 23 +++
1 file changed, 23 insertions(+)
diff --git a/man3/printf.3 b/man3/printf.3
index bf84f07..8b24f20 100644
--- a/man3/printf.3
+++ b/man3/printf.3
@@ -822,6 +822,29 @@ A \(aq%\(aq is written.
No argument is converted.
The complete conversion
specification is \(aq%%\(aq.
+.SH ATTRIBUTES
+For an explanation of the terms used in this section, see
+.BR attributes (7).
+.TS
+allbox;
+lb lb lb
+l l l.
+InterfaceAttribute Value
+T{
+.BR printf (),
+.BR fprintf (),
+.br
+.BR sprintf (),
+.BR snprintf (),
+.br
+.BR vprintf (),
+.BR vfprintf (),
+.br
+.BR vsprintf (),
+.BR vsnprintf ()
+T} Thread safety MT-Safe locale
+.TE
+
.SH CONFORMING TO
The
.BR fprintf (),
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787625: /usr/share/man/man7/epoll.7.gz: epoll(7): wrong string provided to perror in example code
tags 787625 fixed-upstream
thanks
Fixed with upstream commit be6b243ae2d6b3ba158684c945076a1fd65a6f2f
On 4 June 2015 at 16:49, Michael Kerrisk (man-pages)
mtk.manpa...@gmail.com wrote:
On 06/03/2015 03:17 PM, Uwe Kleine-König wrote:
Package: manpages
Version: 3.74-1
Severity: minor
File: /usr/share/man/man7/epoll.7.gz
The example code in epoll(7) includes:
nfds = epoll_wait(epollfd, events, MAX_EVENTS, -1);
if (nfds == -1) {
perror(epoll_pwait);
I suggest to pass epoll_wait (i.e. without a 'p') to perror instead.
Thanks, Uwe. Fixed.
Cheers,
Michael
-- System Information:
Debian Release: 8.0
APT prefers proposed-updates
APT policy: (900, 'proposed-updates'), (900, 'stable'), (600, 'unstable'),
(500, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
manpages depends on no packages.
manpages recommends no packages.
Versions of packages manpages suggests:
ii man-db [man-browser] 2.7.0.2-5
-- no debconf information
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787625: /usr/share/man/man7/epoll.7.gz: epoll(7): wrong string provided to perror in example code
On 06/03/2015 03:17 PM, Uwe Kleine-König wrote:
Package: manpages
Version: 3.74-1
Severity: minor
File: /usr/share/man/man7/epoll.7.gz
The example code in epoll(7) includes:
nfds = epoll_wait(epollfd, events, MAX_EVENTS, -1);
if (nfds == -1) {
perror(epoll_pwait);
I suggest to pass epoll_wait (i.e. without a 'p') to perror instead.
Thanks, Uwe. Fixed.
Cheers,
Michael
-- System Information:
Debian Release: 8.0
APT prefers proposed-updates
APT policy: (900, 'proposed-updates'), (900, 'stable'), (600, 'unstable'),
(500, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
manpages depends on no packages.
manpages recommends no packages.
Versions of packages manpages suggests:
ii man-db [man-browser] 2.7.0.2-5
-- no debconf information
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#788870: Processed: Bug#788870: [base-files] 'LANG=C man 8 resolv+': (fwd)
tags 788870 fixed-upstream thanks This reference was removed in upstream man-pages in May 2014, with commit 0921ce4ab089dca648a4d25f8e7dad8942b84567. Thanks, Michael On 16 June 2015 at 12:36, Debian Bug Tracking System ow...@bugs.debian.org wrote: Processing commands for cont...@bugs.debian.org: reassign 788870 manpages Bug #788870 [base-files] [base-files] 'LANG=C man 8 resolv+': Bug reassigned from package 'base-files' to 'manpages'. No longer marked as found in versions base-files/8+deb8u1. Ignoring request to alter fixed versions of bug #788870 to the same values previously set retitle 788870 manpages references resolv+(8) but does not include it Bug #788870 [manpages] [base-files] 'LANG=C man 8 resolv+': Changed Bug title to 'manpages references resolv+(8) but does not include it' from '[base-files] 'LANG=C man 8 resolv+':' thanks Stopping processing here. Please contact me if you need assistance. -- 788870: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788870 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794876: manpages-dev: Should guide users away from deprecated sys_errlist more
On 08/07/2015 04:24 PM, Dale E. Martin wrote: Package: manpages-dev Version: 3.74-1 Severity: wishlist Tags: patch Dear Maintainer, I recently caused a problem for myself when writing some C-code by making direct use of sys_errlist. I did this after reading the manpage for perror. The code I wrote worked on Debian 7, but was not binary compatible with Debian 6, much to my surprise. Replacing my use of sys_errlist with strerror fixed the problem. I have attached a suggested update to the perror (3) manpage. It is meant as an example, I have no strong feelings about my actual text. Hello Dale, Your submission would be much better to understand as a diff (preferably against latest upstream), with an explanation of how your proposed changes address the problem you encountered. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794559: ld.so(8) LD_LIBRARY_PATH also treats ';' as a seperator
tags 794559 fixed-upstream thanks On 08/04/2015 02:05 PM, Jonathan David Amery wrote: Package: manpages Version: 3.44-1 Severity: normal The documentation for LD_LIBRARY_PATH notes that the list is colon-seperated; however ld.so also treats ';' as a seperator (possibly for compatability reasons). The manpage should note this otherwise the results of trying to have a library path that includes a ';' as part of a directory name are very confusing. Thanks Jonathan. I confirm your point, and I've applied the patch below. Cheers, Michael diff --git a/man8/ld.so.8 b/man8/ld.so.8 index 700628c..1c643c7 100644 --- a/man8/ld.so.8 +++ b/man8/ld.so.8 @@ -228,8 +228,9 @@ when they are first referenced. This is useful when using a debugger. .TP .B LD_LIBRARY_PATH -A colon-separated list of directories in which to search for +A list of directories in which to search for ELF libraries at execution-time. +The items in the list are separated by either colons or semicolons. Similar to the .B PATH environment variable. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794217: socketpair: unclear where the SOCK_NONBLOCK and SOCK_CLOEXEC flags go
tags 794217 fixed-upstream thanks Hello Goswin, On 07/31/2015 12:41 PM, Goswin von Brederlow wrote: Package: manpages-dev Version: 3.74-1 Severity: minor File: socketpair Hi, reading 'man 2 socketpair' it is unclear where the new SOCK_NONBLOCK and SOCK_CLOEXEC flags go in the function call. One has to read through man 2 socket to discover that the type argument now also serves as flags. I recommend making this a bit clearer by changing the Notes from: Since Linux 2.6.27, socketpair() supports the SOCK_NONBLOCK and SOCK_CLOEXEC flags described in socket(2). to: Since Linux 2.6.27, socketpair() supports the SOCK_NONBLOCK and SOCK_CLOEXEC flags in the _type_ argument as described in socket(2). Thanks for the report. I've changed the upstream page, as you propose. MfG aus München Michael -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armel Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages manpages-dev depends on: ii manpages 3.61-1 manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii man-db [man-browser] 2.6.7.1-1 -- no debconf information -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#803459: drand48(3): errors on interval bounds
tags 803459 fixed-upstream thanks Hello Vincent On 10/30/2015 11:17 AM, Vincent Lefevre wrote: > Package: manpages-dev > Version: 3.74-1 > Severity: normal > > The drand48(3) man page contains: > >The drand48() and erand48() functions return nonnegative >double-precision floating-point values uniformly distributed >between [0.0, 1.0). > > Instead of "between", it should be "over". > > Then, more importantly, there are errors for lrand48, nrand48, > lrand48, and jrand48: > >The lrand48() and nrand48() functions return nonnegative >long integers uniformly distributed between 0 and 2^31. > >The mrand48() and jrand48() functions return signed long >integers uniformly distributed between -2^31 and 2^31. > > According to POSIX, the right bound is 2^31 - 1. Or if you want to > keep 2^31, you should give a semi-open interval as in POSIX: [0,2^31) > and [-2^31,2^31) respectively. Upstream, I have applied the patch below. Thanks for the report. Cheers, Michael diff --git a/man3/drand48.3 b/man3/drand48.3 index 1d4799f..0de9cf2 100644 --- a/man3/drand48.3 +++ b/man3/drand48.3 @@ -81,22 +81,22 @@ The and .BR erand48 () functions return nonnegative -double-precision floating-point values uniformly distributed between -[0.0, 1.0). +double-precision floating-point values uniformly distributed over the interval +[0.0,\ 1.0). .PP The .BR lrand48 () and .BR nrand48 () functions return nonnegative -long integers uniformly distributed between 0 and 2^31. +long integers uniformly distributed over the interval [0,\ 2^31). .PP The .BR mrand48 () and .BR jrand48 () functions return signed long -integers uniformly distributed between \-2^31 and 2^31. +integers uniformly distributed over the interval [\-2^31,\ 2^31). .PP The .BR srand48 (), -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Bug#799674: Properly document l/ll length modifier for double/long double argument
(Upstream mainatiner here.) On 09/21/2015 03:08 PM, Mathieu Malaterre wrote: > Package: manpages-dev > Version: 3.65-1 > Severity: wishlist > > Currenly the man page for *printf family is difficult to read with > regards to float, double and long double printing. The man page for > *scanf family is much clearer. AFAIK there is a confusion with an old > C89 behavior, since C99 the actual way to print a double is "lf" and > "llf" for long double. > > Right now it reads as: > > l (ell) A following integer conversion corresponds to a > long int or unsigned long int argument, or a following n conversion > corresponds to a pointer to a long int argument, or a following c > conversion corresponds to a wint_t argument, or a > following s conversion corresponds to a pointer to wchar_t argument. > > Accordingly 'll' and 'L' may need to be updated. So, I looked at this report, and I can't understand what the problem is that is being reported. What precisely do you think needs fixing? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
