Package: libcap-dev
Version: 1:2.66-5+b1
Severity: minor
Tags: patch
* What led up to the situation?
Checking for defects with a new version
test-[g|n]roff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z < "man
page"
[Use "groff -e ' $' -e '\\~$' <file>" to find obvious trailing spaces.]
["test-groff" is a script in the repository for "groff"; is not shipped]
(local copy and "troff" slightly changed by me).
[The fate of "test-nroff" was decided in groff bug #55941.]
* What was the outcome of this action?
an.tmac:<stdin>:1: style: .TH missing fourth argument; consider package/project
name and version (e.g., "groff 1.23.0")
* What outcome did you expect instead?
No output (no warnings).
-.-
General remarks and further material, if a diff-file exist, are in the
attachments.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.10-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1),
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libcap-dev depends on:
ii libc6 2.40-6
ii libcap2 1:2.66-5+b1
libcap-dev recommends no packages.
Versions of packages libcap-dev suggests:
ii manpages-dev 6.9.1-1
-- no debconf information
Input file is cap_clear.3
Output from "mandoc -T lint cap_clear.3": (shortened list)
1 input text line longer than 80 bytes: cap_clear, cap_clear...
1 whitespace at end of input line
-.-.
Output from "test-groff -mandoc -t -ww -z cap_clear.3": (shortened list)
1 trailing space in the line
-.-.
Remove space characters (whitespace) at the end of lines.
Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".
Number of lines affected is
1
-.-.
Wrong distance between sentences in the input file.
Separate the sentences and subordinate clauses; each begins on a new
line. See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").
The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.
Remember coding: Only one command ("sentence") on each (logical) line.
E-mail: Easier to quote exactly the relevant lines.
Generally: Easier to edit the sentence.
Patches: Less unaffected text.
Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.
The amount of space between sentences in the output can then be
controlled with the ".ss" request.
Mark a final abbreviation point as such by suffixing it with "\&".
97:returns zero if the two capability sets are identical. A positive
100:indicates there is a difference between them. The returned
104:differences. Specifically, the macro
115:kernel. This may differ from libcap's list known at compilation
116:time. Unnamed, at compilation time, capabilites can be referred to
117:numerically and libcap will handle them appropriately. Note, the
127:return zero on success, and \-1 on failure. Other return values for
129:are described above. The function
-.-.
Split lines longer than 80 characters into two or more lines.
Appropriate break points are the end of a sentence and a subordinate
clause; after punctuation marks.
Line 3, length 130
cap_clear, cap_clear_flag, cap_get_flag, cap_set_flag, cap_fill_flag, cap_fill,
cap_compare \- capability data object manipulation
-.-.
Output from "test-groff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=10 -ww -z
":
an.tmac:<stdin>:1: style: .TH missing fourth argument; consider package/project
name and version (e.g., "groff 1.23.0")
troff:<stdin>:138: warning: trailing space in the line
-.-.
Spelling (codespell):
capabilites ==> capabilities
--- cap_clear.3 2025-01-29 23:39:13.321552295 +0000
+++ cap_clear.3.new 2025-01-30 01:24:32.082790497 +0000
@@ -1,6 +1,7 @@
-.TH CAP_CLEAR 3 "2021-10-01" "" "Linux Programmer's Manual"
+.TH CAP_CLEAR 3 2021-10-01 "" "Linux Programmer's Manual"
.SH NAME
-cap_clear, cap_clear_flag, cap_get_flag, cap_set_flag, cap_fill_flag,
cap_fill, cap_compare \- capability data object manipulation
+cap_clear, cap_clear_flag, cap_get_flag, cap_set_flag, cap_fill_flag,
+cap_fill, cap_compare \- capability data object manipulation
.SH SYNOPSIS
.nf
#include <sys/capability.h>
@@ -24,13 +25,17 @@ These functions work on a capability sta
A
.I cap_t
holds information about the capabilities in each of the three flags,
-Permitted, Inheritable, and Effective.
-Each capability in a set may be clear (disabled, 0) or set (enabled, 1).
+Permitted,
+Inheritable,
+and Effective.
+Each capability in a set may be clear (disabled, 0)
+or set (enabled, 1).
.PP
These functions work with the following data types:
.TP 18
.I cap_value_t
-identifies a capability, such as
+identifies a capability,
+such as
.BR CAP_CHOWN .
.TP
.I cap_flag_t
@@ -85,23 +90,29 @@ is used to specify the number of capabil
.IR caps .
.PP
.BR cap_fill_flag ()
-fills the to flag of one capability set, with the values in the from
+fills the to flag of one capability set,
+with the values in the from
flag of a reference capability set.
.PP
.BR cap_fill ()
fills the to flag values by copying all of the from flag values.
.PP
.BR cap_compare ()
-compares two full capability sets and, in the spirit of
+compares two full capability sets and,
+in the spirit of
.BR memcmp (),
-returns zero if the two capability sets are identical. A positive
-return
+returns zero
+if the two capability sets are identical.
+A positive return
.I value
-indicates there is a difference between them. The returned
+indicates there is a difference between them.
+The returned
.I value
carries further information about the
.BI "cap_flag_t " flag
-differences. Specifically, the macro
+differences.
+Specifically,
+the macro
.B CAP_DIFFERS
.RI ( value ", " flag )
evaluates to non-zero if the returned
@@ -112,11 +123,15 @@ components.
.PP
.BR cap_max_bits ()
returns the number of capability values known to the running
-kernel. This may differ from libcap's list known at compilation
-time. Unnamed, at compilation time, capabilites can be referred to
-numerically and libcap will handle them appropriately. Note, the
-running kernel wins and it gets to define what "all" capabilities
-means.
+kernel.
+This may differ from libcap's list known at compilation time.
+Unnamed,
+at compilation time,
+capabilities can be referred to numerically
+and libcap will handle them appropriately.
+Note,
+the running kernel wins
+and it gets to define what "all" capabilities means.
.SH "RETURN VALUE"
.BR cap_clear (),
.BR cap_clear_flag (),
@@ -124,9 +139,12 @@ means.
.BR cap_set_flag ()
and
.BR cap_compare ()
-return zero on success, and \-1 on failure. Other return values for
+return zero on success,
+and \-1 on failure.
+Other return values for
.BR cap_compare ()
-are described above. The function
+are described above.
+The function
.BR cap_max_bits ()
returns a numeric value of type
.B cap_value_t
@@ -135,12 +153,13 @@ kernel.
.PP
On failure,
.I errno
-is set to
+is set to
.BR EINVAL ,
indicating that one of the arguments is invalid.
.SH "CONFORMING TO"
These functions are mostly as per specified in the withdrawn POSIX.1e
-draft specification. The following are Linux extensions:
+draft specification.
+The following are Linux extensions:
.BR cap_fill (),
.BR cap_fill_flag (),
.BR cap_clear_flag (),
Any program (person), that produces man pages, should check the output
for defects by using (both groff and nroff)
[gn]roff -mandoc -t -ww -b -z -K utf8 <man page>
The same goes for man pages that are used as an input.
For a style guide use
mandoc -T lint
-.-
Any "autogenerator" should check its products with the above mentioned
'groff', 'mandoc', and additionally with 'nroff ...'.
It should also check its input files for too long (> 80) lines.
This is just a simple quality control measure.
The "autogenerator" may have to be corrected to get a better man page,
the source file may, and any additional file may.
Common defects:
Not removing trailing spaces (in in- and output).
The reason for these trailing spaces should be found and eliminated.
Not beginning each input sentence on a new line.
Line length should thus be reduced.
The script "reportbug" uses 'quoted-printable' encoding when a line is
longer than 1024 characters in an 'ascii' file.
See man-pages(7), item "semantic newline".
-.-
The difference between the formatted output of the original and patched file
can be seen with:
nroff -mandoc <file1> > <out1>
nroff -mandoc <file2> > <out2>
diff -u <out1> <out2>
and for groff, using
\"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -mandoc -Z - \"
instead of 'nroff -mandoc'
Add the option '-t', if the file contains a table.
Read the output from 'diff -u ...' with 'less -R' or similar.
-.-.
If 'man' (man-db) is used to check the manual for warnings,
the following must be set:
The option \"-warnings=w\"
The environmental variable:
export MAN_KEEP_STDERR=yes (or any non-empty value)
or
(produce only warnings):
export MANROFFOPT=\"-ww -b -z\"
export MAN_KEEP_STDERR=yes (or any non-empty value)
-.-
