Issue in man page mount_namespaces.7

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    mount or unmount → mount or umount

"This mount shares events with members of a peer group.  Mount and unmount "
"events immediately under this mount will propagate to the other mounts that "
"are members of the peer group.  I<Propagation> here means that the same "
"mount or unmount will automatically occur under all of the other mounts in "
"the peer group.  Conversely, mount and unmount events that take place under "
"peer mounts will propagate to this mount."

Re: Issue in man page mount_namespaces.7

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 702 bytes --]



On 12/4/22 10:07, Helge Kreutzmann wrote:
> Without further ado, the following was found:
> 
> Issue:    mount or unmount → mount or umount
> 
> "This mount shares events with members of a peer group.  Mount and unmount"
> "events immediately under this mount will propagate to the other mounts that"
> "are members of the peer group.  I<Propagation> here means that the same"
> "mount or unmount will automatically occur under all of the other mounts in"
> "the peer group.  Conversely, mount and unmount events that take place under"
> "peer mounts will propagate to this mount."

Fixed (and also several other identical cases).  Thanks.

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page mount_namespaces.7

[Jakub Wilk]

* Helge Kreutzmann <debian@helgefjell.de>, 2022-12-04 10:07:
>Issue:    mount or unmount → mount or umount

The system call and the command line tool are written without "n" for 
historical reasons, but it's spelled "unmount" otherwise.

>"This mount shares events with members of a peer group.  Mount and unmount "
>"events immediately under this mount will propagate to the other mounts that "
>"are members of the peer group.  I<Propagation> here means that the same "
>"mount or unmount will automatically occur under all of the other mounts in "
>"the peer group.  Conversely, mount and unmount events that take place under "
>"peer mounts will propagate to this mount."

This text looks correct to me.

-- 
Jakub Wilk

Re: Issue in man page mount_namespaces.7

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1165 bytes --]

Hi Jakub,

On 12/5/22 13:03, Jakub Wilk wrote:
> * Helge Kreutzmann <debian@helgefjell.de>, 2022-12-04 10:07:
>> Issue:    mount or unmount → mount or umount
> 
> The system call and the command line tool are written without "n" for historical 
> reasons, but it's spelled "unmount" otherwise.

Yep, what I did is change the English words for the system calls, so it now 
reads as mount(2) or umount(2).  It's a bit more noise, but experienced 
programmers can probably just read it as easily, and it is a bit more 
informative to programmers not so familiar with the syscalls.

> 
>> "This mount shares events with members of a peer group.  Mount and unmount "
>> "events immediately under this mount will propagate to the other mounts that "
>> "are members of the peer group.  I<Propagation> here means that the same "
>> "mount or unmount will automatically occur under all of the other mounts in "
>> "the peer group.  Conversely, mount and unmount events that take place under "
>> "peer mounts will propagate to this mount."
> 
> This text looks correct to me.
> 

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page mount_namespaces.7

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

At 2022-12-05T13:03:05+0100, Jakub Wilk wrote:
> * Helge Kreutzmann <debian@helgefjell.de>, 2022-12-04 10:07:
> > Issue:    mount or unmount → mount or umount
> 
> The system call and the command line tool are written without "n" for
> historical reasons, but it's spelled "unmount" otherwise.
> 
> > "This mount shares events with members of a peer group.  Mount and unmount "
> > "events immediately under this mount will propagate to the other mounts that "
> > "are members of the peer group.  I<Propagation> here means that the same "
> > "mount or unmount will automatically occur under all of the other mounts in "
> > "the peer group.  Conversely, mount and unmount events that take place under "
> > "peer mounts will propagate to this mount."

Yes, let us please not entrench Thompson spelling reforms to English in
ordinary prose, lest we creat more problems than we solve.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page mount_namespaces.7

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1085 bytes --]

On 12/5/22 13:36, G. Branden Robinson wrote:
> At 2022-12-05T13:03:05+0100, Jakub Wilk wrote:
>> * Helge Kreutzmann <debian@helgefjell.de>, 2022-12-04 10:07:
>>> Issue:    mount or unmount → mount or umount
>>
>> The system call and the command line tool are written without "n" for
>> historical reasons, but it's spelled "unmount" otherwise.
>>
>>> "This mount shares events with members of a peer group.  Mount and unmount"
>>> "events immediately under this mount will propagate to the other mounts that"
>>> "are members of the peer group.  I<Propagation> here means that the same"
>>> "mount or unmount will automatically occur under all of the other mounts in"
>>> "the peer group.  Conversely, mount and unmount events that take place under"
>>> "peer mounts will propagate to this mount."
> 
> Yes, let us please not entrench Thompson spelling reforms to English in
> ordinary prose, lest we creat more problems than we solve.

Did you mean resolv?  I didn't know solve is a word :P

> 
> Regards,
> Branden

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page mount_namespaces.7

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

On Wed, Nov 01, 2023 at 05:23:10PM +0100, Jakub Wilk wrote:
> * Alejandro Colomar <alx@kernel.org>, 2023-11-01 16:57:
> > On Wed, Nov 01, 2023 at 02:02:11PM +0000, Helge Kreutzmann wrote:
> > > Without further ado, the following was found:
> > > 
> > > Issue:    mount point → mount ?
> > 
> > I'm not sure that improves significantly.  Is there any difference
> > between a 'mount' and a 'mount point'?
> 
> We discussed it last year:
> https://lore.kernel.org/linux-man/20221205123809.5p66jmpalhd4bhoq@jwilk.net/

Hi Jakub!

Thanks for reminding of that exact message.  I don't feel qualified to
edit that paragraph.  If anyone else want to review the change, feel
invited.

Thanks,
Alex

> 
> -- 
> Jakub Wilk

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page mount_namespaces.7

[Jakub Wilk]

* Alejandro Colomar <alx@kernel.org>, 2023-11-01 16:57:
>On Wed, Nov 01, 2023 at 02:02:11PM +0000, Helge Kreutzmann wrote:
>> Without further ado, the following was found:
>>
>> Issue:    mount point → mount ?
>
>I'm not sure that improves significantly.  Is there any difference
>between a 'mount' and a 'mount point'?

We discussed it last year:
https://lore.kernel.org/linux-man/20221205123809.5p66jmpalhd4bhoq@jwilk.net/

-- 
Jakub Wilk

Re: Issue in man page mount_namespaces.7

[Helge Kreutzmann]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

Hello Alejandro
Am Wed, Nov 01, 2023 at 04:57:08PM +0100 schrieb Alejandro Colomar:
> On Wed, Nov 01, 2023 at 02:02:11PM +0000, Helge Kreutzmann wrote:
> > Without further ado, the following was found:
> > 
> > Issue:    mount point → mount ?
> 
> I'm not sure that improves significantly.  Is there any difference
> between a 'mount' and a 'mount point'?

Some time ago many man pages changed from mount point → mount, and I
thought this was a left over.

If, technically speaking, mount point is correct here, then do not
change, of course.

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 --]

Re: Issue in man page mount_namespaces.7

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

On Wed, Nov 01, 2023 at 02:02:11PM +0000, Helge Kreutzmann wrote:
> Without further ado, the following was found:
> 
> Issue:    mount point → mount ?

I'm not sure that improves significantly.  Is there any difference
between a 'mount' and a 'mount point'?

Thanks,
Alex

> 
> "The propagation type assigned to a new mount depends on the propagation type "
> "of the parent mount.  If the mount has a parent (i.e., it is a non-root "
> "mount point) and the propagation type of the parent is B<MS_SHARED>, then "
> "the propagation type of the new mount is also B<MS_SHARED>.  Otherwise, the "
> "propagation type of the new mount is B<MS_PRIVATE>."

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    mount point → mount ?

"The propagation type assigned to a new mount depends on the propagation type "
"of the parent mount.  If the mount has a parent (i.e., it is a non-root "
"mount point) and the propagation type of the parent is B<MS_SHARED>, then "
"the propagation type of the new mount is also B<MS_SHARED>.  Otherwise, the "
"propagation type of the new mount is B<MS_PRIVATE>."

Re: Issue in man page mount_namespaces.7

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 737 bytes --]



On 1/22/23 21:27, Helge Kreutzmann wrote:
> Hello Alejandro,
> On Sun, Jan 22, 2023 at 09:10:53PM +0100, Alejandro Colomar wrote:
>> On 1/22/23 20:31, Helge Kreutzmann wrote:
>>> Without further ado, the following was found:
>>>
>>> Issue:    mount point → mount
>>
>> This can be WONTFIX.
>>
>> See: <https://lore.kernel.org/linux-man/20221205123809.5p66jmpalhd4bhoq@jwilk.net/T/#u>
> 
> Done.
> 
> (I thought you were still investigating, hence my rereport).

I'm not experienced enough in the topic to be able to come up with consistent 
and precise language.  I'll leave that for others. :)

Cheers,

Alex

> 
> Greetings
> 
>             Helge
> 
> 
> 

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page mount_namespaces.7

[Helge Kreutzmann]

[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

Hello Alejandro,
On Sun, Jan 22, 2023 at 09:10:53PM +0100, Alejandro Colomar wrote:
> On 1/22/23 20:31, Helge Kreutzmann wrote:
> > Without further ado, the following was found:
> > 
> > Issue:    mount point → mount
> 
> This can be WONTFIX.
> 
> See: <https://lore.kernel.org/linux-man/20221205123809.5p66jmpalhd4bhoq@jwilk.net/T/#u>

Done. 

(I thought you were still investigating, hence my rereport).

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 --]

Re: Issue in man page mount_namespaces.7

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

Hi Helge,

At 2023-01-22T21:01:33+0100, Helge Kreutzmann wrote:
> This is the represenation we see (like B<> for bold, I<> for italics).
> It most likely does not look like this in groff.

Thanks for the quick follow up.  I wondered about this but since I
didn't see "\n" in any of your other reports, I thought that you thought
this character sequence was appearing literally in the man page sources.

> > 1ae6b2c7b8 (Alejandro Colomar   2022-03-18 20:25:09 +0100 1016) .I util\-linux
> > b324e17d32 (Alejandro Colomar   2022-12-04 20:38:06 +0100 1017)  2.27) in turn reverses the step performed by
> 
> At this point I see a hard line break as well when I read the english 
> page in man.

Yes!  This is a good catch.  Beginning a text line with space characters
forces a break (a new output line) in *roff.  That is clearly a mistake
and should be corrected.

+1 for sure.

> > That is why I suspect a problem with your tool.
> 
> I can mark it as such, i.e. a po4a problem.

Since so much of a report is automatically generated, perhaps a glossary
would be helpful.  Your reporting dialect seems to be drawn from
Perl::Pod, but I'm not clear on whether it's a _strict_ subset or if you
have your own conventions as well.

Something like:

B<foo>		foo is in boldface
I<bar>		bar is in italics or an oblique face
\n		indicates each break when breaking is surprising

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page mount_namespaces.7

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 642 bytes --]

Hi Helge,

On 1/22/23 20:31, Helge Kreutzmann wrote:
> Without further ado, the following was found:
> 
> Issue:    mount point → mount

This can be WONTFIX.

See: 
<https://lore.kernel.org/linux-man/20221205123809.5p66jmpalhd4bhoq@jwilk.net/T/#u>

Cheers,

Alex

> 
> "Here, I<A> is a mount on I<B/b>, where I<B> is the parent mount and I<b> is"
> "a subdirectory path under the mount point I<B>.  If B<B> is shared, then all"
> "most-recently-mounted mounts at I<b> on mounts that receive propagation from"
> "mount I<B> and do not have submounts under them are unmounted."

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page mount_namespaces.7

[Helge Kreutzmann]

[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]

Hello Branden,
On Sun, Jan 22, 2023 at 01:54:10PM -0600, G. Branden Robinson wrote:
> At 2023-01-22T20:31:25+0100, Helge Kreutzmann wrote:
> > Without further ado, the following was found:
> > 
> > Issue:    Why hard (and strange) line breaks?
> > 
> > "Since, when one uses\n"
> [...]
> 
> I don't see these "\n" line endings in Git HEAD or the change history of
> the page.  Maybe there is a problem with your searching/reporting tool?

This is the represenation we see (like B<> for bold, I<> for italics).
It most likely does not look like this in groff.

> 1ae6b2c7b8 (Alejandro Colomar   2022-03-18 20:25:09 +0100 1016) .I util\-linux
> b324e17d32 (Alejandro Colomar   2022-12-04 20:38:06 +0100 1017)  2.27) in turn reverses the step performed by

At this point I see a hard line break as well when I read the english 
page in man.

> That is why I suspect a problem with your tool.

I can mark it as such, i.e. a po4a problem.

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 --]

Re: Issue in man page mount_namespaces.7

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 2652 bytes --]

Hi Helge,

At 2023-01-22T20:31:25+0100, Helge Kreutzmann wrote:
> Without further ado, the following was found:
> 
> Issue:    Why hard (and strange) line breaks?
> 
> "Since, when one uses\n"
[...]

I don't see these "\n" line endings in Git HEAD or the change history of
the page.  Maybe there is a problem with your searching/reporting tool?

I would add that these are not "hard line breaks" in the *roff language.

"\n" is the register interpolation escape sequence.  It must always be
followed by an argument, the name of the register to be interpolated.

Register interpolation should not be used in portable man pages.  But I
don't think it's happening here.

groff 1.22.4 (and earlier) diagnose the incorrect input as follows.

$ printf 'hello\\n\n' | nroff | cat -s
troff: <standard input>:1: a newline character is not allowed in an escape name
hello

groff 1.23.0 will be a little more precise.  (The escape _name_ itself
is not where the invalid syntax was encountered.)

$ printf 'hello\\n\n' | ./build/test-groff -T utf8 | cat -s
troff:<standard input>:1: error: a newline character is not allowed in an escape sequence parameter
hello

In any event, "git blame" says the following about the relevant portion
of the page.

a66648bbd1 (Michael Kerrisk     2021-08-17 05:04:11 +0200 1009) Since, when one uses
a66648bbd1 (Michael Kerrisk     2021-08-17 05:04:11 +0200 1010) .BR unshare (1)
a66648bbd1 (Michael Kerrisk     2021-08-17 05:04:11 +0200 1011) to create a mount namespace,
8c9a827429 (Michael Kerrisk     2021-08-18 01:34:54 +0200 1012) the goal is commonly to provide full isolation of the mounts
a66648bbd1 (Michael Kerrisk     2021-08-17 05:04:11 +0200 1013) in the new namespace,
a66648bbd1 (Michael Kerrisk     2021-08-17 05:04:11 +0200 1014) .BR unshare (1)
a66648bbd1 (Michael Kerrisk     2021-08-17 05:04:11 +0200 1015) (since
1ae6b2c7b8 (Alejandro Colomar   2022-03-18 20:25:09 +0100 1016) .I util\-linux
b324e17d32 (Alejandro Colomar   2022-12-04 20:38:06 +0100 1017)  2.27) in turn reverses the step performed by
a66648bbd1 (Michael Kerrisk     2021-08-17 05:04:11 +0200 1018) .BR systemd (1),
8c9a827429 (Michael Kerrisk     2021-08-18 01:34:54 +0200 1019) by making all mounts private in the new namespace.
a66648bbd1 (Michael Kerrisk     2021-08-17 05:04:11 +0200 1020) That is,
a66648bbd1 (Michael Kerrisk     2021-08-17 05:04:11 +0200 1021) .BR unshare (1)
a66648bbd1 (Michael Kerrisk     2021-08-17 05:04:11 +0200 1022) performs the equivalent of the following in the new mount namespace:

That is why I suspect a problem with your tool.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    mount point → mount ?

"The propagation type assigned to a new mount depends on the propagation type "
"of the parent mount.  If the mount has a parent (i.e., it is a non-root "
"mount point) and the propagation type of the parent is B<MS_SHARED>, then "
"the propagation type of the new mount is also B<MS_SHARED>.  Otherwise, the "
"propagation type of the new mount is B<MS_PRIVATE>."

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    Why hard (and strange) line breaks?

"Since, when one uses\n"
"B<unshare>(1)\n"
"to create a mount namespace,\n"
"the goal is commonly to provide full isolation of the mounts\n"
"in the new namespace,\n"
"B<unshare>(1)\n"
"(since\n"
"I<util-linux>\n"
" 2.27) in turn reverses the step performed by\n"
"B<systemd>(1),\n"
"by making all mounts private in the new namespace.\n"
"That is,\n"
"B<unshare>(1)\n"
"performs the equivalent of the following in the new mount namespace:\n"

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    mount point → mount

"Here, I<A> is a mount on I<B/b>, where I<B> is the parent mount and I<b> is "
"a subdirectory path under the mount point I<B>.  If B<B> is shared, then all "
"most-recently-mounted mounts at I<b> on mounts that receive propagation from "
"mount I<B> and do not have submounts under them are unmounted."

Re: Issue in man page mount_namespaces.7

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2268 bytes --]

Hi Helge,

On 12/5/22 19:54, Helge Kreutzmann wrote:
> Hello Alejandro,
> On Mon, Dec 05, 2022 at 02:18:19PM +0100, Alejandro Colomar wrote:
>> On 12/5/22 13:38, Jakub Wilk wrote:
>>> * Alejandro Colomar <alx.manpages@gmail.com>, 2022-12-04 15:06:
>>>>>>> Issue:    mount point I<B> → mount I<B>
>>>>>>>
>>>>>>> "Here, I<B> is the destination mount, and I<b> is a subdirectory path under"
>>>>>>> "the mount point I<B>.  The propagation type of the resulting mount, I<B/b>,"
>>>>>>> "follows the same rules as for a bind mount, where the propagation type of"
>>>>>>> "the source mount is considered always to be private."
>>>>>>
>>>>>> I'm not sure about this one.  If we change that wording, I'd
>>>>>> like to make sure we don't lose any details in the
>>>>>> information.  Please CC any related kernel developers, and
>>>>>> suggest them review the documentation for more consistent
>>>>>> language.
>>>>>
>>>>> Until recently, there was "mount point" used all over this man
>>>>> pages. This was changed to "mount" in one of the previous
>>>>> release of man pages.
>>>>
>>>> I didn't know that; please point to the commit that did that.
>>>
>>> Probably this one:
>>>
>>>     commit 8c9a82742976dc98578338ef886776f06c0ab3f2
>>>     Author: Michael Kerrisk <mtk.manpages@gmail.com>
>>>     Date:   2021-08-18 01:34:54 +0200
>>>         mount_namespaces.7: Terminology clean-up: "mount point" ==> "mount"
>>>         Many times, this page use the terminology "mount point", where
>>>         "mount" would be better. A "mount point" is the location at which
>>>         a mount is attached. A "mount" is an association between a
>>>         filesystem and a mount point.
>>>         Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
>>>
>>> Both terms are valid, but they have different meanings.
>>>
>>> (No idea which one is appropriate in the paragraph in question.)
>>
>>
>> Thanks!  I also don't know, so I'll leave this as is for now.
> 
> So you want me to remind you later on this or should I switch it to
> WONTFIX?

You can put WONTFIX on this one.

Cheers,

Alex

> 
> Greetings
> 
>           Helge
> 

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page mount_namespaces.7

[Helge Kreutzmann]

[-- Attachment #1: Type: text/plain, Size: 2430 bytes --]

Hello Alejandro,
On Mon, Dec 05, 2022 at 02:18:19PM +0100, Alejandro Colomar wrote:
> On 12/5/22 13:38, Jakub Wilk wrote:
> > * Alejandro Colomar <alx.manpages@gmail.com>, 2022-12-04 15:06:
> > > > > > Issue:    mount point I<B> → mount I<B>
> > > > > > 
> > > > > > "Here, I<B> is the destination mount, and I<b> is a subdirectory path under"
> > > > > > "the mount point I<B>.  The propagation type of the resulting mount, I<B/b>,"
> > > > > > "follows the same rules as for a bind mount, where the propagation type of"
> > > > > > "the source mount is considered always to be private."
> > > > > 
> > > > > I'm not sure about this one.  If we change that wording, I'd
> > > > > like to make sure we don't lose any details in the
> > > > > information.  Please CC any related kernel developers, and
> > > > > suggest them review the documentation for more consistent
> > > > > language.
> > > > 
> > > > Until recently, there was "mount point" used all over this man
> > > > pages. This was changed to "mount" in one of the previous
> > > > release of man pages.
> > > 
> > > I didn't know that; please point to the commit that did that.
> > 
> > Probably this one:
> > 
> >    commit 8c9a82742976dc98578338ef886776f06c0ab3f2
> >    Author: Michael Kerrisk <mtk.manpages@gmail.com>
> >    Date:   2021-08-18 01:34:54 +0200
> >        mount_namespaces.7: Terminology clean-up: "mount point" ==> "mount"
> >        Many times, this page use the terminology "mount point", where
> >        "mount" would be better. A "mount point" is the location at which
> >        a mount is attached. A "mount" is an association between a
> >        filesystem and a mount point.
> >        Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
> > 
> > Both terms are valid, but they have different meanings.
> > 
> > (No idea which one is appropriate in the paragraph in question.)
> 
> 
> Thanks!  I also don't know, so I'll leave this as is for now.

So you want me to remind you later on this or should I switch it to
WONTFIX?

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 --]

Re: Issue in man page mount_namespaces.7

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1880 bytes --]

Hi Jakub,

On 12/5/22 13:38, Jakub Wilk wrote:
> * Alejandro Colomar <alx.manpages@gmail.com>, 2022-12-04 15:06:
>>>>> Issue:    mount point I<B> → mount I<B>
>>>>>
>>>>> "Here, I<B> is the destination mount, and I<b> is a subdirectory path under"
>>>>> "the mount point I<B>.  The propagation type of the resulting mount, I<B/b>,"
>>>>> "follows the same rules as for a bind mount, where the propagation type of"
>>>>> "the source mount is considered always to be private."
>>>>
>>>> I'm not sure about this one.  If we change that wording, I'd like to make 
>>>> sure we don't lose any details in the information.  Please CC any related 
>>>> kernel developers, and suggest them review the documentation for more 
>>>> consistent language.
>>>
>>> Until recently, there was "mount point" used all over this man pages. This 
>>> was changed to "mount" in one of the previous release of man pages.
>>
>> I didn't know that; please point to the commit that did that.
> 
> Probably this one:
> 
>    commit 8c9a82742976dc98578338ef886776f06c0ab3f2
>    Author: Michael Kerrisk <mtk.manpages@gmail.com>
>    Date:   2021-08-18 01:34:54 +0200
>        mount_namespaces.7: Terminology clean-up: "mount point" ==> "mount"
>        Many times, this page use the terminology "mount point", where
>        "mount" would be better. A "mount point" is the location at which
>        a mount is attached. A "mount" is an association between a
>        filesystem and a mount point.
>        Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
> 
> Both terms are valid, but they have different meanings.
> 
> (No idea which one is appropriate in the paragraph in question.)


Thanks!  I also don't know, so I'll leave this as is for now.

Cheers,

Alex

> 

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page mount_namespaces.7

[Jakub Wilk]

* Alejandro Colomar <alx.manpages@gmail.com>, 2022-12-04 15:06:
>>>>Issue:    mount point I<B> → mount I<B>
>>>>
>>>>"Here, I<B> is the destination mount, and I<b> is a subdirectory path under"
>>>>"the mount point I<B>.  The propagation type of the resulting mount, I<B/b>,"
>>>>"follows the same rules as for a bind mount, where the propagation type of"
>>>>"the source mount is considered always to be private."
>>>
>>>I'm not sure about this one.  If we change that wording, I'd like to 
>>>make sure we don't lose any details in the information.  Please CC 
>>>any related kernel developers, and suggest them review the 
>>>documentation for more consistent language.
>>
>>Until recently, there was "mount point" used all over this man pages. 
>>This was changed to "mount" in one of the previous release of man 
>>pages.
>
>I didn't know that; please point to the commit that did that.

Probably this one:

   commit 8c9a82742976dc98578338ef886776f06c0ab3f2
   Author: Michael Kerrisk <mtk.manpages@gmail.com>
   Date:   2021-08-18 01:34:54 +0200
   
       mount_namespaces.7: Terminology clean-up: "mount point" ==> "mount"
   
       Many times, this page use the terminology "mount point", where
       "mount" would be better. A "mount point" is the location at which
       a mount is attached. A "mount" is an association between a
       filesystem and a mount point.
   
       Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

Both terms are valid, but they have different meanings.

(No idea which one is appropriate in the paragraph in question.)

-- 
Jakub Wilk

Re: Issue in man page mount_namespaces.7

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 3177 bytes --]

Hi Helge,

On 12/4/22 15:14, Helge Kreutzmann wrote:
> Hello Alejandro,
> On Sun, Dec 04, 2022 at 03:06:40PM +0100, Alejandro Colomar wrote:
>> On 12/4/22 15:00, Helge Kreutzmann wrote:
>>> Hello Alejandro,
>>> On Sun, Dec 04, 2022 at 01:25:07PM +0100, Alejandro Colomar wrote:
>>>> On 12/4/22 10:07, Helge Kreutzmann wrote:
>>>>> Without further ado, the following was found:
>>>>>
>>>>> Issue:    mount point I<B> → mount I<B>
>>>>>
>>>>> "Here, I<B> is the destination mount, and I<b> is a subdirectory path under"
>>>>> "the mount point I<B>.  The propagation type of the resulting mount, I<B/b>,"
>>>>> "follows the same rules as for a bind mount, where the propagation type of"
>>>>> "the source mount is considered always to be private."
>>>>
>>>> I'm not sure about this one.  If we change that wording, I'd like to make
>>>> sure we don't lose any details in the information.  Please CC any related
>>>> kernel developers, and suggest them review the documentation for more
>>>> consistent language.
>>>
>>> Until recently, there was "mount point" used all over this man pages.
>>> This was changed to "mount" in one of the previous release of man
>>> pages.
>>
>>
>> I didn't know that; please point to the commit that did that.
> 
> Sorry, I probably don't have the time to do so. Please remember that I
> don't have the sources (I can for sure obtain them). I just saw a
> massiv change and wondered why this one was left out.

Okay, no problem.

> 
> So if you think it is fine, then of course you are the expert, we are
> just translators. I just pointed this out so you can contact the
> approriate experts (if necessary) and review this, if necessary. If
> not, then no problem.

Okay, I'll have a look at it.  Please ping again about this issue if I haven't 
fixed it in the future.

> 
>>> I mark it WONTFIX for now, so it doesn't get reported again and maybe
>>> you can clarify (if necessary) this in a later release.
>>
>> If you point me to the patch, I can dig into it.  Thanks!
> 
> Sorry, I don't know the inner workings of manpages and how and where
> patches are stored.

The Linux man-pages source code is here, in case you ever need it:
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/>

If you do, have a look at the README and CONTRIBUTING files.

> 
> Remember, manpages-l10n has over 100 upstream projects (although manpages is
> probably the largest), so we (or actually me at the moment) are unable
> to get into the inner workings of each project but leave it to you as
> the maintainer to handle this as you see fit. We just don't want to be
> silently fixing issues in translations without the original authors are beeing
> made aware of this.

Sure, I understand.

> 
> Thanks for your understanding.

:)

Cheers,

Alex

> 
> Greetings
> 
>          Helge

Thanks for all the reports.  I fixed most of them.  I'll apply a few other 
patches before releasing, and then in the solstice will release 6.02.  Then, 
please report again any issues that you see in the new version.

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page mount_namespaces.7

[Helge Kreutzmann]

[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]

Hello Alejandro,
On Sun, Dec 04, 2022 at 03:06:40PM +0100, Alejandro Colomar wrote:
> On 12/4/22 15:00, Helge Kreutzmann wrote:
> > Hello Alejandro,
> > On Sun, Dec 04, 2022 at 01:25:07PM +0100, Alejandro Colomar wrote:
> > > On 12/4/22 10:07, Helge Kreutzmann wrote:
> > > > Without further ado, the following was found:
> > > > 
> > > > Issue:    mount point I<B> → mount I<B>
> > > > 
> > > > "Here, I<B> is the destination mount, and I<b> is a subdirectory path under"
> > > > "the mount point I<B>.  The propagation type of the resulting mount, I<B/b>,"
> > > > "follows the same rules as for a bind mount, where the propagation type of"
> > > > "the source mount is considered always to be private."
> > > 
> > > I'm not sure about this one.  If we change that wording, I'd like to make
> > > sure we don't lose any details in the information.  Please CC any related
> > > kernel developers, and suggest them review the documentation for more
> > > consistent language.
> > 
> > Until recently, there was "mount point" used all over this man pages.
> > This was changed to "mount" in one of the previous release of man
> > pages.
> 
> 
> I didn't know that; please point to the commit that did that.

Sorry, I probably don't have the time to do so. Please remember that I
don't have the sources (I can for sure obtain them). I just saw a
massiv change and wondered why this one was left out.

So if you think it is fine, then of course you are the expert, we are
just translators. I just pointed this out so you can contact the
approriate experts (if necessary) and review this, if necessary. If
not, then no problem.

> > I mark it WONTFIX for now, so it doesn't get reported again and maybe
> > you can clarify (if necessary) this in a later release.
> 
> If you point me to the patch, I can dig into it.  Thanks!

Sorry, I don't know the inner workings of manpages and how and where
patches are stored. 

Remember, manpages-l10n has over 100 upstream projects (although manpages is
probably the largest), so we (or actually me at the moment) are unable
to get into the inner workings of each project but leave it to you as
the maintainer to handle this as you see fit. We just don't want to be
silently fixing issues in translations without the original authors are beeing
made aware of this.

Thanks for your understanding.

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 --]

Re: Issue in man page mount_namespaces.7

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1489 bytes --]

Hi Helge,

On 12/4/22 15:00, Helge Kreutzmann wrote:
> Hello Alejandro,
> On Sun, Dec 04, 2022 at 01:25:07PM +0100, Alejandro Colomar wrote:
>> On 12/4/22 10:07, Helge Kreutzmann wrote:
>>> Without further ado, the following was found:
>>>
>>> Issue:    mount point I<B> → mount I<B>
>>>
>>> "Here, I<B> is the destination mount, and I<b> is a subdirectory path under"
>>> "the mount point I<B>.  The propagation type of the resulting mount, I<B/b>,"
>>> "follows the same rules as for a bind mount, where the propagation type of"
>>> "the source mount is considered always to be private."
>>
>> I'm not sure about this one.  If we change that wording, I'd like to make
>> sure we don't lose any details in the information.  Please CC any related
>> kernel developers, and suggest them review the documentation for more
>> consistent language.
> 
> Until recently, there was "mount point" used all over this man pages.
> This was changed to "mount" in one of the previous release of man
> pages.


I didn't know that; please point to the commit that did that.

> 
> Thus I assumed that this one might have been overlooked.

Maybe.

> 
> I mark it WONTFIX for now, so it doesn't get reported again and maybe
> you can clarify (if necessary) this in a later release.

If you point me to the patch, I can dig into it.  Thanks!

> 
> Thanks!
> 
> Greetings
> 
>          Helge
> 
> 

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page mount_namespaces.7

[Helge Kreutzmann]

[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]

Hello Alejandro,
On Sun, Dec 04, 2022 at 01:25:07PM +0100, Alejandro Colomar wrote:
> On 12/4/22 10:07, Helge Kreutzmann wrote:
> > Without further ado, the following was found:
> > 
> > Issue:    mount point I<B> → mount I<B>
> > 
> > "Here, I<B> is the destination mount, and I<b> is a subdirectory path under"
> > "the mount point I<B>.  The propagation type of the resulting mount, I<B/b>,"
> > "follows the same rules as for a bind mount, where the propagation type of"
> > "the source mount is considered always to be private."
> 
> I'm not sure about this one.  If we change that wording, I'd like to make
> sure we don't lose any details in the information.  Please CC any related
> kernel developers, and suggest them review the documentation for more
> consistent language.

Until recently, there was "mount point" used all over this man pages.
This was changed to "mount" in one of the previous release of man
pages.

Thus I assumed that this one might have been overlooked.

I mark it WONTFIX for now, so it doesn't get reported again and maybe
you can clarify (if necessary) this in a later release.

Thanks!

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 --]

Re: Issue in man page mount_namespaces.7

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 638 bytes --]



On 12/4/22 10:07, Helge Kreutzmann wrote:
> Without further ado, the following was found:
> 
> Issue:    performed. → performed).
> 
> "Above, we see that the mount with ID 273 is a slave whose master is the peer"
> "group 105.  The mount point for that master is unreachable, and so a"
> "I<propagate_from> tag is displayed, indicating that the closest dominant"
> "peer group (i.e., the nearest reachable mount in the slave chain)  is the"
> "peer group with the ID 102 (corresponding to the I</mnt> mount point before"
> "the B<chroot>(1)  was performed."

Fixed.  Thanks.

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page mount_namespaces.7

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 764 bytes --]

Hi Helge,

On 12/4/22 10:07, Helge Kreutzmann wrote:
> Without further ado, the following was found:
> 
> Issue:    mount point I<B> → mount I<B>
> 
> "Here, I<B> is the destination mount, and I<b> is a subdirectory path under"
> "the mount point I<B>.  The propagation type of the resulting mount, I<B/b>,"
> "follows the same rules as for a bind mount, where the propagation type of"
> "the source mount is considered always to be private."

I'm not sure about this one.  If we change that wording, I'd like to make sure 
we don't lose any details in the information.  Please CC any related kernel 
developers, and suggest them review the documentation for more consistent language.

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page mount_namespaces.7

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 649 bytes --]



On 12/4/22 10:07, Helge Kreutzmann wrote:
> Without further ado, the following was found:
> 
> Issue:    unmounts → umounts
> 
> "Note that a mount's propagation type determines whether mounts and unmounts"
> "of mounts I<immediately under> the mount are propagated.  Thus, the"
> "propagation type does not affect propagation of events for grandchildren and"
> "further removed descendant mounts.  What happens if the mount itself is"
> "unmounted is determined by the propagation type that is in effect for the"
> "I<parent> of the mount."

Fixed (and other identical cases).  Thanks.

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Issue in man page mount_namespaces.7

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 215 bytes --]



On 12/4/22 10:07, Helge Kreutzmann wrote:
> Without further ado, the following was found:
> 
> Issue:    unmount → umount
> 
> "unmount A\n"

Fixed.  Thanks.

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    performed. → performed).

"Above, we see that the mount with ID 273 is a slave whose master is the peer "
"group 105.  The mount point for that master is unreachable, and so a "
"I<propagate_from> tag is displayed, indicating that the closest dominant "
"peer group (i.e., the nearest reachable mount in the slave chain)  is the "
"peer group with the ID 102 (corresponding to the I</mnt> mount point before "
"the B<chroot>(1)  was performed."

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    mount point → mount ?

"The propagation type assigned to a new mount depends on the propagation type "
"of the parent mount.  If the mount has a parent (i.e., it is a non-root "
"mount point) and the propagation type of the parent is B<MS_SHARED>, then "
"the propagation type of the new mount is also B<MS_SHARED>.  Otherwise, the "
"propagation type of the new mount is B<MS_PRIVATE>."

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    unmounts → umounts

"Note that a mount's propagation type determines whether mounts and unmounts "
"of mounts I<immediately under> the mount are propagated.  Thus, the "
"propagation type does not affect propagation of events for grandchildren and "
"further removed descendant mounts.  What happens if the mount itself is "
"unmounted is determined by the propagation type that is in effect for the "
"I<parent> of the mount."

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    mount point I<B> → mount I<B>

"Here, I<B> is the destination mount, and I<b> is a subdirectory path under "
"the mount point I<B>.  The propagation type of the resulting mount, I<B/b>, "
"follows the same rules as for a bind mount, where the propagation type of "
"the source mount is considered always to be private."

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    unmount → umount

"unmount A\n"

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    mount point → mount

"Here, I<A> is a mount on I<B/b>, where I<B> is the parent mount and I<b> is "
"a subdirectory path under the mount point I<B>.  If B<B> is shared, then all "
"most-recently-mounted mounts at I<b> on mounts that receive propagation from "
"mount I<B> and do not have submounts under them are unmounted."

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    mount or unmount → mount or umount

"This mount shares events with members of a peer group.  Mount and unmount "
"events immediately under this mount will propagate to the other mounts that "
"are members of the peer group.  I<Propagation> here means that the same "
"mount or unmount will automatically occur under all of the other mounts in "
"the peer group.  Conversely, mount and unmount events that take place under "
"peer mounts will propagate to this mount."

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    unmounts → umounts

"Note that a mount's propagation type determines whether mounts and unmounts "
"of mounts I<immediately under> the mount are propagated.  Thus, the "
"propagation type does not affect propagation of events for grandchildren and "
"further removed descendant mounts.  What happens if the mount itself is "
"unmounted is determined by the propagation type that is in effect for the "
"I<parent> of the mount."

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    Documentation/filesystems/sharedsubtree.txt → Documentation/filesystems/sharedsubtree.rst

"For a discussion of propagation types when moving mounts (B<MS_MOVE>)  and "
"creating bind mounts (B<MS_BIND>), see I<Documentation/filesystems/"
"sharedsubtree.txt>."

"I<Documentation/filesystems/sharedsubtree.txt> in the kernel source tree."

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    performed. → performed).

"Above, we see that the mount with ID 273 is a slave whose master is the peer "
"group 105.  The mount point for that master is unreachable, and so a "
"I<propagate_from> tag is displayed, indicating that the closest dominant "
"peer group (i.e., the nearest reachable mount in the slave chain)  is the "
"peer group with the ID 102 (corresponding to the I</mnt> mount point before "
"the B<chroot>(1)  was performed."

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    mount point → mount ?

"The propagation type assigned to a new mount depends on the propagation type "
"of the parent mount.  If the mount has a parent (i.e., it is a non-root "
"mount point) and the propagation type of the parent is B<MS_SHARED>, then "
"the propagation type of the new mount is also B<MS_SHARED>.  Otherwise, the "
"propagation type of the new mount is B<MS_PRIVATE>."

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    Documentation/filesystems/sharedsubtree.txt → Documentation/filesystems/sharedsubtree.rst

"For further details, see I<Documentation/filesystems/sharedsubtree.txt> in "
"the kernel source tree."

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    mount point I<B> → mount I<B>

"Here, I<B> is the destination mount, and I<b> is a subdirectory path under "
"the mount point I<B>.  The propagation type of the resulting mount, I<B/b>, "
"follows the same rules as for a bind mount, where the propagation type of "
"the source mount is considered always to be private."

"Here, I<A> is a mount on I<B/b>, where I<B> is the parent mount and I<b> is "
"a subdirectory path under the mount point I<B>.  If B<B> is shared, then all "
"most-recently-mounted mounts at I<b> on mounts that receive propagation from "
"mount I<B> and do not have submounts under them are unmounted."

Issue in man page mount_namespaces.7

[Helge Kreutzmann]

Without further ado, the following was found:

Issue:    unmount → umount

"unmount A\n"