On Sat, May 16, 2020 at 10:10:27AM +0200, Michael Kerrisk (man-pages) wrote: > sys-utils/ipcs.1 | 22 ++++++++++++++++++++-- > 1 file changed, 20 insertions(+), 2 deletions(-) Applied, thanks. -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com
On Thu, May 14, 2020 at 11:51:29PM +0000, Bjarni Ingi Gislason wrote: > misc-utils/kill.1 | 2 +- > misc-utils/lsblk.8 | 2 +- > sys-utils/mount.8 | 1 - > sys-utils/unshare.1 | 8 ++++---- > term-utils/agetty.8 | 2 +- > text-utils/more.1 | 4 ++-- > 6 files changed, 9 insertions(+), 10 deletions(-) Applied, thanks. -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com
On Sun, May 17, 2020 at 11:13:22PM +0800, Yannick Le Pennec wrote: > disk-utils/fdisk.8 | 2 +- > sys-utils/eject.c | 2 +- > sys-utils/mount.8 | 2 +- > sys-utils/rfkill.8 | 2 +- > sys-utils/tunelp.8 | 2 +- > sys-utils/zramctl.8 | 2 +- > 6 files changed, 6 insertions(+), 6 deletions(-) Applied, thanks. -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com
Hello Karel, On Mon, 18 May 2020 at 10:28, Karel Zak <kzak@redhat.com> wrote: > > On Sat, May 16, 2020 at 10:24:59AM +0200, Michael Kerrisk (man-pages) wrote: > > Hello Karel, > > > > Perhaps a little inspired by Helge's recent reports, I wonder about > > submitting some wide-ranging patches to improve consistency across > > the util-linux manual pages. > > > > As an example, there's quite a bit of variation in the order of > > .SH sections in the manual pages (e.g., in the placement of the SEE > > ALSO section). The pages would be more readable if the ordering was > > more consistent. > > > > Would you entertain patches that made wide-ranging changes > > that fixed that sort of thing (without changing page content? > > No problem, Ok. > but it would be nice to somehow document that is expected > to avoid future changes in an opposite way. For example add some info > to Documentation/howto-man-page.txt. Agreed. For man-pages, I created man-pags(7) to document those expectations. At least some of that should be applicable in othe pojects, if they want. > BTW, I'm not sure about man pages as ideal format to maintain > documentation (because it's mostly about formatting than about > content). I think about AsciiDoc or so in future. What do you think > about this idea? I'm not too knowledgeable in AsciiDc, but my impression is that it's too limited in terms of its formatting opinions. If I did move man-pages, the most likely candidate would probably be Sphinx, as is nowadays used in the kernel docs. But, that would require converting a thousand pages or so, and I have not so far had the stomach for that. Of course, you have a rather smaller set of pages to deal with, so a conversion step sould be more easily entertained. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
On Sat, May 16, 2020 at 10:24:59AM +0200, Michael Kerrisk (man-pages) wrote: > Hello Karel, > > Perhaps a little inspired by Helge's recent reports, I wonder about > submitting some wide-ranging patches to improve consistency across > the util-linux manual pages. > > As an example, there's quite a bit of variation in the order of > .SH sections in the manual pages (e.g., in the placement of the SEE > ALSO section). The pages would be more readable if the ordering was > more consistent. > > Would you entertain patches that made wide-ranging changes > that fixed that sort of thing (without changing page content? No problem, but it would be nice to somehow document that is expected to avoid future changes in an opposite way. For example add some info to Documentation/howto-man-page.txt. BTW, I'm not sure about man pages as ideal format to maintain documentation (because it's mostly about formatting than about content). I think about AsciiDoc or so in future. What do you think about this idea? Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com
Most date back to reorganisation of the Documentation/ tree in 2016,
new paths based on v5.7-rc5:
fdisk.8: Documentation/{,admin-guide/}devices.txt
eject.c: Documentation/{,userspace-api/}ioctl/cdrom.rst
mount.8: Documentation/filesystems/adfs.{txt,rst}
rfkill.8: Documentation/{rfkill.txt,driver-api/rfkill.rst}
tunelp.8: Documentation/{parport.txt,admin-guide/parport.rst}
zramctl.8: Documentation/{blockdev/zram.txt,admin-guide/blockdev/zram.rst}
Signed-off-by: Yannick Le Pennec <yannick.lepennec@live.fr>
---
disk-utils/fdisk.8 | 2 +-
sys-utils/eject.c | 2 +-
sys-utils/mount.8 | 2 +-
sys-utils/rfkill.8 | 2 +-
sys-utils/tunelp.8 | 2 +-
sys-utils/zramctl.8 | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/disk-utils/fdisk.8 b/disk-utils/fdisk.8
index cc172a0a5..dcc587fed 100644
--- a/disk-utils/fdisk.8
+++ b/disk-utils/fdisk.8
@@ -161,7 +161,7 @@ The
.I partition
is a device name followed by a partition number. For example, /dev/sda1 is the
first partition on the first hard disk in the system. See also Linux kernel
-documentation (the Documentation/devices.txt file).
+documentation (the Documentation/admin-guide/devices.txt file).
.SH SIZES
The "last sector" dialog accepts partition size specified by number of sectors
diff --git a/sys-utils/eject.c b/sys-utils/eject.c
index 2f3b200bf..651ecc7d8 100644
--- a/sys-utils/eject.c
+++ b/sys-utils/eject.c
@@ -330,7 +330,7 @@ static void auto_eject(const struct eject_control *ctl)
* Stops CDROM from opening on manual eject button press.
* This can be useful when you carry your laptop
* in your bag while it's on and no CD inserted in it's drive.
- * Implemented as found in Documentation/ioctl/cdrom.txt
+ * Implemented as found in Documentation/userspace-api/ioctl/cdrom.rst
*/
static void manual_eject(const struct eject_control *ctl)
{
diff --git a/sys-utils/mount.8 b/sys-utils/mount.8
index 13a5f7167..7f5da2d2b 100644
--- a/sys-utils/mount.8
+++ b/sys-utils/mount.8
@@ -1342,7 +1342,7 @@ Set the owner and group of the files in the filesystem (default: uid=gid=0).
Set the permission mask for ADFS 'owner' permissions and 'other' permissions,
respectively (default: 0700 and 0077, respectively).
See also
-.IR /usr/src/linux/Documentation/filesystems/adfs.txt .
+.IR /usr/src/linux/Documentation/filesystems/adfs.rst .
.SS "Mount options for affs"
.TP
diff --git a/sys-utils/rfkill.8 b/sys-utils/rfkill.8
index 9eff913b8..eb640954f 100644
--- a/sys-utils/rfkill.8
+++ b/sys-utils/rfkill.8
@@ -110,7 +110,7 @@ for the Debian project (and may be used by others).
.SH "SEE ALSO"
.BR powertop (8),
.BR systemd-rfkill (8),
-.UR https://\:git.\:kernel.\:org/\:pub/\:scm/\:linux/\:kernel/\:git/\:torvalds/\:linux.git/\:tree/\:Documentation/\:rfkill.txt
+.UR https://\:git.\:kernel.\:org/\:pub/\:scm/\:linux/\:kernel/\:git/\:torvalds/\:linux.git/\:tree/\:Documentation/\:driver-api/\:rfkill.rst
Linux kernel documentation
.UE
.SH AVAILABILITY
diff --git a/sys-utils/tunelp.8 b/sys-utils/tunelp.8
index 5c927458f..7716ba7e1 100644
--- a/sys-utils/tunelp.8
+++ b/sys-utils/tunelp.8
@@ -34,7 +34,7 @@ irq is handled by the parport driver. You can change the parport irq for
example via
.IR /proc/parport/*/irq .
Read
-.I /usr/src/linux/Documentation/parport.txt
+.I /usr/src/linux/Documentation/admin-guide/parport.rst
for more details on parport.
.TP
\fB\-t\fR, \fB\-\-time\fR \fImilliseconds\fR
diff --git a/sys-utils/zramctl.8 b/sys-utils/zramctl.8
index c6ecdc3d5..12983f144 100644
--- a/sys-utils/zramctl.8
+++ b/sys-utils/zramctl.8
@@ -118,7 +118,7 @@ and use it as swap device.
# zramctl --reset /dev/zram0
.fi
.SH SEE ALSO
-.UR http://git.\:kernel.\:org\:/cgit\:/linux\:/kernel\:/git\:/torvalds\:/linux.git\:/tree\:/Documentation\:/blockdev\:/zram.txt
+.UR http://git.\:kernel.\:org\:/cgit\:/linux\:/kernel\:/git\:/torvalds\:/linux.git\:/tree\:/Documentation\:/admin-guide\:/blockdev\:/zram.rst
Linux kernel documentation
.UE .
.SH AUTHORS
--
2.20.1
Hello Karel, Perhaps a little inspired by Helge's recent reports, I wonder about submitting some wide-ranging patches to improve consistency across the util-linux manual pages. As an example, there's quite a bit of variation in the order of .SH sections in the manual pages (e.g., in the placement of the SEE ALSO section). The pages would be more readable if the ordering was more consistent. Would you entertain patches that made wide-ranging changes that fixed that sort of thing (without changing page content? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
From: Michael Kerrisk <mtk.manpages@gmail.com> Date: Sat, 16 May 2020 09:45:11 +0200 Subject: [PATCH] ipcs.1: ipcs no longer needs read permission on IPC resources With changes starting around util-linux commit 058e81540fbb0d2b78 that switched from using IPC_STAT to parsing /proc/sysvipc/*, ipcs now shows all IPC objects rather than just the objects for which the user has read permission. Update the page to reflect this fact, and also add a NOTES section describing the historical and fallback behavior where /proc is not available. Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com> --- sys-utils/ipcs.1 | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/sys-utils/ipcs.1 b/sys-utils/ipcs.1 index 93c35e323..4b3baaaa5 100644 --- a/sys-utils/ipcs.1 +++ b/sys-utils/ipcs.1 @@ -8,8 +8,7 @@ ipcs \- show information on IPC facilities [options] .SH DESCRIPTION .B ipcs -shows information on the inter-process communication facilities -for which the calling process has read access. +shows information on inter-process communication facilities. By default it shows information about all three resources: shared memory segments, message queues, and semaphore arrays. .SH OPTIONS @@ -76,6 +75,25 @@ Print sizes in bytes. .TP .B \-\-human Print sizes in human-readable format. +.SH NOTES +The current implementation of +.B ipcs +obtains information about available IPC resources by parsing the files in +.IR /proc/sysvipc . +Before util-linux version v2.23, an alternate mechanism was used: the +.BR IPC_STAT +command of +.BR msgctl (2), +.BR semctl (2), +and +.BR shmctl (2). +This mechanism is also used in later util-linux versions in the case where +.I /proc +is unavailable. +A limitation of the +.B IPC_STAT +mechanism is that it can only be used to retrieve information about +IPC resources for which the user has read permission. .SH SEE ALSO .BR ipcmk (1), .BR ipcrm (1), -- 2.26.2 -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
I'd like to release v2.35.2 on Monday (and 2.36-rc1 later). See below
the current stable/v2.35 branch. Any objections and suggestions?
Karel
Anatoly Pugachev (1):
docs: Correct ChangeLog URL to history log.
Disconnect3d (1):
Fix off by one when checking "/dev/mapper/" path
Gaël PORTAY (2):
libfdisk: (script) fix segmentation fault
lib/mangle: check for the NULL string argument
J William Piggott (1):
hwclock: make glibc 2.31 compatible
Jakub Wilk (2):
scriptlive: fix man page formatting
scriptlive: fix typo
Jiaxun Yang (1):
lscpu: Adapt MIPS cpuinfo
Johannes Thumshirn (1):
blkzone: deny destructive ioctls on busy blockdev
Karel Zak (23):
libfdisk: (script) accept sector-size, ignore unknown headers
fstrim: do not use Protect setting in systemd service
libfdisk: (script) fix memory leak
sfdisk: fix ref-counting for the script
lscpu: fix SIGSEGV on archs without drawers & books
umount: don't try it as non-suid if not found mountinfo entry
lsblk: fix -P regression from v2.34
chsh: (man) fix default behavior description
hwclock: fix audit exit status
su, runuser: (man) add more info about PATH and PAM
lscpu: use official name for HiSilicon tsv110
libmount: improve smb{2,3} support
libmount: smb2 is unsupported alias
libfdisk: remove unwanted assert()
pylibmount: cleanup and sync UL_RaiseExc
eject: fix compiler warning [-Wformat-overflow]
sfdisk: only report I/O errors on --move-data
libfdisk: (script) fix partno_from_devname()
docs: add swap to 1st fstab field
libfdisk: fix partition calculation for BLKPG_* ioctls
wipefs: fix man page --no-headings short option
libblkid: fix fstatat() use in blkid__scan_dir()
libblkid: fix compiler warning [-Wsign-compare]
Lukas Czerner (1):
blkdiscard: (man) offset and length must be sector aligned
Mark Barbone (1):
Fix typo in the mount (8) man page
Mark Hindley (1):
tests: Fix for misc/fallocate test build failure.
Pali Rohár (2):
libblkid: Fix UTF-16 support in function blkid_encode_to_utf8()
exfat: Fix parsing exfat label
Ritika Srivastava (1):
lsblk: Ignore hidden devices
Roberto Bergantinos Corpas (1):
libmount: fix mount -a EBUSY for cifs
Sami Kerola (4):
kill: include sys/types.h before checking SYS_pidfd_send_signal
docs: kill.1 add note about shell-internal kill implementations
ctrlaltdel: display error message indicated by errno
write: fix potential string overflow
Sven Wiltink (1):
lsblk: Fall back to ID_SERIAL
Tycho Andersen (1):
libmount: do not unnecessarily chmod utab.lock
Wolfram Sang (1):
bash-completion: umount explicitly needs gawk
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
On Fri, May 15, 2020 at 05:41:33PM +0900, Johannes Thumshirn wrote: > sys-utils/blkzone.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Applied, thanks. > + fd = init_device(ctl, O_WRONLY | O_EXCL); > + if (fd < 0) > + errx(EXIT_FAILURE, _("%s: unable to open"), ctl->devname); I have removed this error message. It's already within init_device(). Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com
On Fri, May 15, 2020 at 09:53:46AM +0000, Johannes Thumshirn wrote: > On 15/05/2020 10:50, Chris Hofstaedtler wrote: > > * Johannes Thumshirn <johannes.thumshirn@wdc.com> [200515 10:41]: > >> If a user submits a zone management ioctl from user-space, like a zone > >> reset and a file-system (like zonefs or f2fs) is mounted on the zoned > >> block device, the zone will get reset and the file-system's cached value > >> of the zone's write-pointer becomes invalid. > >> > >> Subsequent writes to this zone from the file-system will result in > >> unaligned writes and the drive will error out. > > > > "error out" meaning what exactly? > > The drive will report an Unaligned Write error. > > > > >> Open the block device file in exclusive mode for submitting these ioctls. > >> If a file-system is mounted the kernel will return -EBUSY and we can't > >> continue issuing the ioctl. > > > > Isn't this something the kernel should enforce, then? > > I did a patch for the kernel yesterday [1] enforcing this limitation, but as > Damien said it's SYS_CAP_ADMIN and with great power comes great responsibility. > We're also allowing other raw block device accesses on block devices. > > [1] https://lore.kernel.org/linux-block/BY5PR04MB69006DE86D1050620B5EDAA4E7BD0@BY5PR04MB6900.namprd04.prod.outlook.com/ > > > What's to stop anybody from calling the ioctl from another tool, > > without using O_EXCL? > > Nothing, but still we don't need to make one's life hard by letting blkzone go > havoc with FS internal caching. If another tool does zone resets, it's up to them > to check for mounted block devices. O_EXCL good idea, it nothing unusual that you can do crazy things with devices with mounted filesystem (see for example fdisk(s), wipefs, ...). And sometimes it is valid use-case to do "bad" things and in this case we have --force option in our tools (for example to avoid O_EXCL). Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com
On 15/05/2020 10:50, Chris Hofstaedtler wrote: > * Johannes Thumshirn <johannes.thumshirn@wdc.com> [200515 10:41]: >> If a user submits a zone management ioctl from user-space, like a zone >> reset and a file-system (like zonefs or f2fs) is mounted on the zoned >> block device, the zone will get reset and the file-system's cached value >> of the zone's write-pointer becomes invalid. >> >> Subsequent writes to this zone from the file-system will result in >> unaligned writes and the drive will error out. > > "error out" meaning what exactly? The drive will report an Unaligned Write error. > >> Open the block device file in exclusive mode for submitting these ioctls. >> If a file-system is mounted the kernel will return -EBUSY and we can't >> continue issuing the ioctl. > > Isn't this something the kernel should enforce, then? I did a patch for the kernel yesterday [1] enforcing this limitation, but as Damien said it's SYS_CAP_ADMIN and with great power comes great responsibility. We're also allowing other raw block device accesses on block devices. [1] https://lore.kernel.org/linux-block/BY5PR04MB69006DE86D1050620B5EDAA4E7BD0@BY5PR04MB6900.namprd04.prod.outlook.com/ > What's to stop anybody from calling the ioctl from another tool, > without using O_EXCL? Nothing, but still we don't need to make one's life hard by letting blkzone go havoc with FS internal caching. If another tool does zone resets, it's up to them to check for mounted block devices.
* Johannes Thumshirn <johannes.thumshirn@wdc.com> [200515 10:41]: > If a user submits a zone management ioctl from user-space, like a zone > reset and a file-system (like zonefs or f2fs) is mounted on the zoned > block device, the zone will get reset and the file-system's cached value > of the zone's write-pointer becomes invalid. > > Subsequent writes to this zone from the file-system will result in > unaligned writes and the drive will error out. "error out" meaning what exactly? > Open the block device file in exclusive mode for submitting these ioctls. > If a file-system is mounted the kernel will return -EBUSY and we can't > continue issuing the ioctl. Isn't this something the kernel should enforce, then? What's to stop anybody from calling the ioctl from another tool, without using O_EXCL? Chris
If a user submits a zone management ioctl from user-space, like a zone reset and a file-system (like zonefs or f2fs) is mounted on the zoned block device, the zone will get reset and the file-system's cached value of the zone's write-pointer becomes invalid. Subsequent writes to this zone from the file-system will result in unaligned writes and the drive will error out. Open the block device file in exclusive mode for submitting these ioctls. If a file-system is mounted the kernel will return -EBUSY and we can't continue issuing the ioctl. Reported-by: Coly Li <colyli@suse.de> Cc: Damien Le Moal <Damien.LeMoal@wdc.com> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> --- sys-utils/blkzone.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sys-utils/blkzone.c b/sys-utils/blkzone.c index 8d9de2e1bba7..a4b59754616e 100644 --- a/sys-utils/blkzone.c +++ b/sys-utils/blkzone.c @@ -301,7 +301,9 @@ static int blkzone_action(struct blkzone_control *ctl) if (!zonesize) errx(EXIT_FAILURE, _("%s: unable to determine zone size"), ctl->devname); - fd = init_device(ctl, O_WRONLY); + fd = init_device(ctl, O_WRONLY | O_EXCL); + if (fd < 0) + errx(EXIT_FAILURE, _("%s: unable to open"), ctl->devname); if (ctl->offset & (zonesize - 1)) errx(EXIT_FAILURE, _("%s: offset %" PRIu64 " is not aligned " -- 2.24.1
On Thu, May 14, 2020 at 10:15:47PM +0200, John Paul Adrian Glaubitz wrote: > On 5/14/20 10:09 PM, Michael Kerrisk wrote: > >> On 5/14/20 8:51 PM, Helge Kreutzmann wrote: > >>> I'm now reporting the errors for your project. If future reports should > >>> use another channel, please let me know. > >> > >> I think you should send your changes as patches, preferably with a git pull > >> request as the current form of submitting these changes requires a lot of > >> manual editing due to the large number of changes involved. > > > > Well, yes, but see > > https://lore.kernel.org/util-linux/CAKgNAkgqKs=Q4qvPHirHa6KjW3qOqyyNG7sCxHX2RfWiOBqRbg@mail.gmail.com/ > > Doesn't convince, me really. I don't think it's too much to ask for to > read the documentation of git and then create a set of patches. Helge's way provides opportunity for other mailing list members to contribute :-) > I wouldn't accept such mass mails for my own projects, it's just way too > much work to import all these changes manually. And I also haven't seen > any other project do that in the past 20 years, so I'm not sure how successful > this strategy is. Sharing is caring ... better report bugs than ignore. Karel -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com
Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z [ "test-groff" is a developmental version of "groff" ] Input file is ././misc-utils/kill.1 <./misc-utils/kill.1>:173 (macro BR): only 1 argument, but more are expected #### Input file is ././misc-utils/lsblk.8 troff: backtrace: '/home/bg/git/groff/build/s-tmac/an-old.tmac':478: macro 'BR' troff: backtrace: file '<./misc-utils/lsblk.8>':122 troff: <./misc-utils/lsblk.8>:122: warning: trailing space #### Input file is ././sys-utils/mount.8 an-old.tmac: <./sys-utils/mount.8>:2427 (.RE): warning: extra .RE or .RS is missing before it; "an-RS-open" is 0. #### Input file is ././sys-utils/unshare.1 <./sys-utils/unshare.1>:176 (macro BR): only 1 argument, but more are expected <./sys-utils/unshare.1>:181 (macro BR): only 1 argument, but more are expected <./sys-utils/unshare.1>:240 (macro BR): only 1 argument, but more are expected <./sys-utils/unshare.1>:246 (macro BR): only 1 argument, but more are expected #### Input file is ././term-utils/agetty.8 troff: backtrace: file '<./term-utils/agetty.8>':130 troff: <./term-utils/agetty.8>:130: warning: trailing space #### Input file is ././text-utils/more.1 troff: backtrace: file '<./text-utils/more.1>':91 troff: <./text-utils/more.1>:91: warning: macro 'b' not defined #### The output from nroff and troff is unchanged, except for the word "number" in text-utils/more.1, that was missing. Signed-off-by: Bjarni Ingi Gislason <bjarniig@rhi.hi.is> --- misc-utils/kill.1 | 2 +- misc-utils/lsblk.8 | 2 +- sys-utils/mount.8 | 1 - sys-utils/unshare.1 | 8 ++++---- term-utils/agetty.8 | 2 +- text-utils/more.1 | 4 ++-- 6 files changed, 9 insertions(+), 10 deletions(-) diff --git a/misc-utils/kill.1 b/misc-utils/kill.1 index 65872ce19..27258d293 100644 --- a/misc-utils/kill.1 +++ b/misc-utils/kill.1 @@ -170,7 +170,7 @@ preferred in relation to the .BR kill (1) executable described by this manual. Easiest way to ensure one is executing the executable is to use full path when calling the command, for example: -.BR "/bin/kill --version" +.B "/bin/kill \-\-version" .SH RETURN CODES .B kill has the following return codes: diff --git a/misc-utils/lsblk.8 b/misc-utils/lsblk.8 index 416b28298..1b73e6f25 100644 --- a/misc-utils/lsblk.8 +++ b/misc-utils/lsblk.8 @@ -119,7 +119,7 @@ The default is to use tree for the column 'NAME' (see also \fB\-\-tree\fR). The default list of columns may be extended if \fIlist\fP is specified in the format \fI+list\fP (e.g., \fBlsblk \-o +UUID\fP). .TP -.BR \-O , " \-\-output\-all " +.BR \-O , " \-\-output\-all" Output all available columns. .TP .BR \-P , " \-\-pairs" diff --git a/sys-utils/mount.8 b/sys-utils/mount.8 index 54af6c2b1..05117c727 100644 --- a/sys-utils/mount.8 +++ b/sys-utils/mount.8 @@ -2424,7 +2424,6 @@ Parity bytes for FEC (default: 2). Optional. Path to pkcs7 signature of root hash hex string. Requires crypt_activate_by_signed_key() from cryptsetup and kernel built with CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG. For device reuse, signatures have to be either used by all mounts of a device or by none. Optional. -.RE .PP Supported since util-linux v2.35. .PP diff --git a/sys-utils/unshare.1 b/sys-utils/unshare.1 index a58821921..86506ffa3 100644 --- a/sys-utils/unshare.1 +++ b/sys-utils/unshare.1 @@ -173,12 +173,12 @@ implies creating a new mount namespace since the /proc mount would otherwise mess up existing programs on the system. The new proc filesystem is explicitly mounted as private (with MS_PRIVATE|MS_REC). .TP -.BR \-\-map\-user=\fIuid|name +.BI \-\-map\-user= uid|name Run the program only after the current effective user ID has been mapped to \fIuid\fP. If this option is specified multiple times, the last occurrence takes precedence. This option implies \fB\-\-user\fR. .TP -.BR \-\-map\-group=\fIgid|name +.BI \-\-map\-group= gid|name Run the program only after the current effective group ID has been mapped to \fIgid\fP. If this option is specified multiple times, the last occurrence takes precedence. This option implies \fB\-\-setgroups=deny\fR and \fB\-\-user\fR. @@ -237,13 +237,13 @@ Set the user ID which will be used in the entered namespace. Set the group ID which will be used in the entered namespace and drop supplementary groups. .TP -.BR "\-\-monotonic \fIoffset" +.BI \-\-monotonic " offset" Set the offset of .B CLOCK_MONOTONIC which will be used in the entered time namespace. This option requires unsharing a time namespace with \fB\-\-time\fP. .TP -.BR "\-\-boottime \fIoffset" +.BI \-\-boottime " offset" Set the offset of .B CLOCK_BOOTTIME which will be used in the entered time namespace. This option requires diff --git a/term-utils/agetty.8 b/term-utils/agetty.8 index fa92df09c..fd6cf4b44 100644 --- a/term-utils/agetty.8 +++ b/term-utils/agetty.8 @@ -127,7 +127,7 @@ messages to be displayed on different terminals. The \-\-show\-issue Display the current issue file (or other) on the current terminal and exit. Use this option to review the current setting, it is not designed for any other -purpose. Note that output may use some default or incomplete information as +purpose. Note that output may use some default or incomplete information as proper output depends on terminal and agetty command line. .TP \-h, \-\-flow\-control diff --git a/text-utils/more.1 b/text-utils/more.1 index 2176d5528..4cf445f87 100644 --- a/text-utils/more.1 +++ b/text-utils/more.1 @@ -88,9 +88,9 @@ compatibility. .TP \fB\-n\fR, \fB\-\-lines \fInumber\fR Specify the -.b number +.I number of lines per screenful. The -.b number +.I number argument is a positive decimal integer. The .B \-\-lines option shall override any values obtained from any other source, such as -- 2.26.2
Hello John, On Thu, 14 May 2020 at 22:15, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: > > On 5/14/20 10:09 PM, Michael Kerrisk wrote: > >> On 5/14/20 8:51 PM, Helge Kreutzmann wrote: > >>> I'm now reporting the errors for your project. If future reports should > >>> use another channel, please let me know. > >> > >> I think you should send your changes as patches, preferably with a git pull > >> request as the current form of submitting these changes requires a lot of > >> manual editing due to the large number of changes involved. > > > > Well, yes, but see > > https://lore.kernel.org/util-linux/CAKgNAkgqKs=Q4qvPHirHa6KjW3qOqyyNG7sCxHX2RfWiOBqRbg@mail.gmail.com/ > > Doesn't convince, me really. I don't think it's too much to ask for to > read the documentation of git and then create a set of patches. Yes, but probably the work for Helge to do that is a factor of *several* times the work of someone with commit access doing the manual edits. > I wouldn't accept such mass mails for my own projects, it's just way too > much work to import all these changes manually. I agree. It's a pain. > And I also haven't seen > any other project do that in the past 20 years, so I'm not sure how successful > this strategy is. I'm not sure how successful it will be either. But, one project just did what you haven't seen in the past 20 years, just last month :-). Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
On 5/14/20 10:09 PM, Michael Kerrisk wrote:
>> On 5/14/20 8:51 PM, Helge Kreutzmann wrote:
>>> I'm now reporting the errors for your project. If future reports should
>>> use another channel, please let me know.
>>
>> I think you should send your changes as patches, preferably with a git pull
>> request as the current form of submitting these changes requires a lot of
>> manual editing due to the large number of changes involved.
>
> Well, yes, but see
> https://lore.kernel.org/util-linux/CAKgNAkgqKs=Q4qvPHirHa6KjW3qOqyyNG7sCxHX2RfWiOBqRbg@mail.gmail.com/
Doesn't convince, me really. I don't think it's too much to ask for to
read the documentation of git and then create a set of patches.
I wouldn't accept such mass mails for my own projects, it's just way too
much work to import all these changes manually. And I also haven't seen
any other project do that in the past 20 years, so I'm not sure how successful
this strategy is.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hello John, On Thu, May 14, 2020 at 9:20 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: > > Hello Helge! > > On 5/14/20 8:51 PM, Helge Kreutzmann wrote: > > I'm now reporting the errors for your project. If future reports should > > use another channel, please let me know. > > I think you should send your changes as patches, preferably with a git pull > request as the current form of submitting these changes requires a lot of > manual editing due to the large number of changes involved. Well, yes, but see https://lore.kernel.org/util-linux/CAKgNAkgqKs=Q4qvPHirHa6KjW3qOqyyNG7sCxHX2RfWiOBqRbg@mail.gmail.com/ Cheers, Michael
On 5/14/20 9:42 PM, Helge Kreutzmann wrote: >> I think you should send your changes as patches, preferably with a git pull >> request as the current form of submitting these changes requires a lot of >> manual editing due to the large number of changes involved. > > Sorry, this won't be possible as stated in my long e-mail. I haven't read that mail, but I don't understand what reason should prevent anyone from sending a patch. > However, in the future the number of changes should be (much!) lower, > as I don't think we wait another 10 years for reporting. > > And you can process them at your convenience, for us (translators) > there is no time pressure at all, many (formatting) issues are fixed > in the translation already. But how are the changes supposed to get into the git repository? If you send something like 50 mails, someone has to sit down and edit all these changes manually. I don't think anyone is going to do that, it's just way too tedious. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz@debian.org `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[-- Attachment #1: Type: text/plain, Size: 1174 bytes --] Hello Adrian, On Thu, May 14, 2020 at 09:20:07PM +0200, John Paul Adrian Glaubitz wrote: > On 5/14/20 8:51 PM, Helge Kreutzmann wrote: > > I'm now reporting the errors for your project. If future reports should > > use another channel, please let me know. > > I think you should send your changes as patches, preferably with a git pull > request as the current form of submitting these changes requires a lot of > manual editing due to the large number of changes involved. Sorry, this won't be possible as stated in my long e-mail. However, in the future the number of changes should be (much!) lower, as I don't think we wait another 10 years for reporting. And you can process them at your convenience, for us (translators) there is no time pressure at all, many (formatting) issues are fixed in the translation already. Greetings Helge -- Dr. Helge Kreutzmann debian@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
Hello Helge!
On 5/14/20 8:51 PM, Helge Kreutzmann wrote:
> I'm now reporting the errors for your project. If future reports should
> use another channel, please let me know.
I think you should send your changes as patches, preferably with a git pull
request as the current form of submitting these changes requires a lot of
manual editing due to the large number of changes involved.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Dear util-linux maintainers.
the manpage-l10n project maintains a large number of translations of
man pages both from a large variety of sources (including util-linux) as
well for a large variety of target languages.
During their work translators notice different possible issues in the
original (english) man pages. Sometiems this is a straightforward
typo, sometimes a hard to read sentence, sometimes this is a
convention not held up and sometimes we simply do not understand the
original.
We use several distributions as sources and update regularly (at
least every 2 month). This means we are fairly recent (some
distributions like archlinux also update frequently) but might miss
the latest upstream version once a while, so the error might be
already fixed. We apologize and ask you to close the issue immediately
if this should be the case, but given the huge volume of projects and
the very limited number of volunteers we are not able to double check
each and every issue.
Secondly we translators see the manpages in the neutral po format,
i.e. converted and harmonized, but not the original source (be it man,
groff, xml or other). So we cannot provide a true patch (where
possible), but only an approximation which you need to convert into
your source format.
Finally the issues I'm reporting have accumulated over time and are
not always discovered by me, so sometimes my description of the
problem my be a bit limited - do not hesitate to ask so we can clarify
them.
I'm now reporting the errors for your project. If future reports should
use another channel, please let me know.
**
Man page: rtcwake.8
Issue: to terminal → the terminal
"The suspend setup may be interrupted by active hardware; for example "
"wireless USB input devices that continue to send events for some fraction of "
"a second after the return key is pressed. B<rtcwake> tries to avoid this "
"problem and it waits to terminal to settle down before entering a system "
"sleep."
Greetings
Helge
--
Dr. Helge Kreutzmann debian@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Dear util-linux maintainers.
the manpage-l10n project maintains a large number of translations of
man pages both from a large variety of sources (including util-linux) as
well for a large variety of target languages.
During their work translators notice different possible issues in the
original (english) man pages. Sometiems this is a straightforward
typo, sometimes a hard to read sentence, sometimes this is a
convention not held up and sometimes we simply do not understand the
original.
We use several distributions as sources and update regularly (at
least every 2 month). This means we are fairly recent (some
distributions like archlinux also update frequently) but might miss
the latest upstream version once a while, so the error might be
already fixed. We apologize and ask you to close the issue immediately
if this should be the case, but given the huge volume of projects and
the very limited number of volunteers we are not able to double check
each and every issue.
Secondly we translators see the manpages in the neutral po format,
i.e. converted and harmonized, but not the original source (be it man,
groff, xml or other). So we cannot provide a true patch (where
possible), but only an approximation which you need to convert into
your source format.
Finally the issues I'm reporting have accumulated over time and are
not always discovered by me, so sometimes my description of the
problem my be a bit limited - do not hesitate to ask so we can clarify
them.
I'm now reporting the errors for your project. If future reports should
use another channel, please let me know.
**
Man page: runuser.1
Issue: Markup missing and copy → sync?
"Create pseudo-terminal for the session. The independent terminal provides "
"better security as user does not share terminal with the original session. "
"This allow to avoid TIOCSTI ioctl terminal injection and another security "
"attacks against terminal file descriptors. The all session is also possible "
"to move to background (e.g., \"runuser --pty -u username -- command &\"). "
"If the pseudo-terminal is enabled then runuser command works as a proxy "
"between the sessions (copy stdin and stdout)."
Greetings
Helge
--
Dr. Helge Kreutzmann debian@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Dear util-linux maintainers.
the manpage-l10n project maintains a large number of translations of
man pages both from a large variety of sources (including util-linux) as
well for a large variety of target languages.
During their work translators notice different possible issues in the
original (english) man pages. Sometiems this is a straightforward
typo, sometimes a hard to read sentence, sometimes this is a
convention not held up and sometimes we simply do not understand the
original.
We use several distributions as sources and update regularly (at
least every 2 month). This means we are fairly recent (some
distributions like archlinux also update frequently) but might miss
the latest upstream version once a while, so the error might be
already fixed. We apologize and ask you to close the issue immediately
if this should be the case, but given the huge volume of projects and
the very limited number of volunteers we are not able to double check
each and every issue.
Secondly we translators see the manpages in the neutral po format,
i.e. converted and harmonized, but not the original source (be it man,
groff, xml or other). So we cannot provide a true patch (where
possible), but only an approximation which you need to convert into
your source format.
Finally the issues I'm reporting have accumulated over time and are
not always discovered by me, so sometimes my description of the
problem my be a bit limited - do not hesitate to ask so we can clarify
them.
I'm now reporting the errors for your project. If future reports should
use another channel, please let me know.
**
Man page: script.1
Issue: B<scriptreplay (1)> → B<scriptreplay>(1)
"B<script> makes a typescript of everything on your terminal session. The "
"terminal data are stored in raw form to the log file and information about "
"timing to another (optional) structured log file. The timing log file is "
"necessary to replay the session later by B<scriptreplay (1)> and to store "
"additional information about the session."
Greetings
Helge
--
Dr. Helge Kreutzmann debian@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/