Linux-man Archive on lore.kernel.org
 help / color / Atom feed
* Errors in man pages, here: mount_namespaces(7): Understanding
@ 2020-04-19  6:48 Helge Kreutzmann
  2020-04-20 10:14 ` Michael Kerrisk (man-pages)
  2020-04-20 10:26 ` On bug bombing Michael Kerrisk (man-pages)
  0 siblings, 2 replies; 5+ messages in thread
From: Helge Kreutzmann @ 2020-04-19  6:48 UTC (permalink / raw)
  To: mtk.manpages; +Cc: linux-man

Dear manpages maintainers.
the manpage-l10n project maintains a large number of translations of
man pages both from a large variety of sources (including manpages) 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 translate 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. As requested, each
issue is sent in an unique mail for easier tracking on your side. If
future reports should use another channel, please let me know.

**

What does "come as a single unit from more privileged mount" mean?

"Mounts that come as a single unit from more privileged mount are locked "
"together and may not be separated in a less privileged mount namespace.  "
"(The B<unshare>(2)  B<CLONE_NEWNS> operation brings across all of the mounts "
"from the original mount namespace as a single unit, and recursive mounts "
"that propagate between mount namespaces propagate as a single unit.)"

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Errors in man pages, here: mount_namespaces(7): Understanding
  2020-04-19  6:48 Errors in man pages, here: mount_namespaces(7): Understanding Helge Kreutzmann
@ 2020-04-20 10:14 ` Michael Kerrisk (man-pages)
  2020-04-20 10:26 ` On bug bombing Michael Kerrisk (man-pages)
  1 sibling, 0 replies; 5+ messages in thread
From: Michael Kerrisk (man-pages) @ 2020-04-20 10:14 UTC (permalink / raw)
  To: Helge Kreutzmann; +Cc: mtk.manpages, linux-man

On 4/19/20 8:48 AM, Helge Kreutzmann wrote:
> Dear manpages maintainers.
> the manpage-l10n project maintains a large number of translations of
> man pages both from a large variety of sources (including manpages) 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 translate 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. As requested, each
> issue is sent in an unique mail for easier tracking on your side. If
> future reports should use another channel, please let me know.
> 
> **
> 
> What does "come as a single unit from more privileged mount" mean?
> 
> "Mounts that come as a single unit from more privileged mount are locked "
> "together and may not be separated in a less privileged mount namespace.  "
> "(The B<unshare>(2)  B<CLONE_NEWNS> operation brings across all of the mounts "
> "from the original mount namespace as a single unit, and recursive mounts "
> "that propagate between mount namespaces propagate as a single unit.)"

I applied the patch below. Let me know if that does not help.

Thanks,

Michael

index 87d872ffc..9232b4b6e 100644
--- a/man7/mount_namespaces.7
+++ b/man7/mount_namespaces.7
@@ -97,7 +97,7 @@ This ensures that mappings performed in less
 privileged mount namespaces will not propagate to more privileged
 mount namespaces.
 .IP *
-Mounts that come as a single unit from more privileged mount are
+Mounts that come as a single unit from a more privileged mount namespace are
 locked together and may not be separated in a less privileged mount
 namespace.
 (The


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* On bug bombing
  2020-04-19  6:48 Errors in man pages, here: mount_namespaces(7): Understanding Helge Kreutzmann
  2020-04-20 10:14 ` Michael Kerrisk (man-pages)
@ 2020-04-20 10:26 ` Michael Kerrisk (man-pages)
  2020-05-01  7:20   ` Helge Kreutzmann
  1 sibling, 1 reply; 5+ messages in thread
From: Michael Kerrisk (man-pages) @ 2020-04-20 10:26 UTC (permalink / raw)
  To: Helge Kreutzmann; +Cc: mtk.manpages, linux-man

Hello Helge,

On 4/19/20 8:48 AM, Helge Kreutzmann wrote:
> Dear manpages maintainers.
> the manpage-l10n project maintains a large number of translations of
> man pages both from a large variety of sources (including manpages) 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 translate 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. As requested, each
> issue is sent in an unique mail for easier tracking on your side. If
> future reports should use another channel, please let me know.

I am torn between saying thank you for all the effort you
clearly made and saying PLEASE DON'T DO THIS!

Submitting one hundred plus bug reports at the same time
is _very_ burdensome for an upstream maintainer. Honestly,
if it had not been for lockdown, I might simply have ignored
the whole series of mails.

In the future, please do not wait for  huge backlog to build up
before sending me reports. (10 reports at a time is fine; 100, 
not so much.)

In any case, thank you very much for your many reports.

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: On bug bombing
  2020-04-20 10:26 ` On bug bombing Michael Kerrisk (man-pages)
@ 2020-05-01  7:20   ` Helge Kreutzmann
  2020-05-01  8:34     ` Michael Kerrisk (man-pages)
  0 siblings, 1 reply; 5+ messages in thread
From: Helge Kreutzmann @ 2020-05-01  7:20 UTC (permalink / raw)
  To: Michael Kerrisk (man-pages); +Cc: linux-man


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

Hello Michael,
On Mon, Apr 20, 2020 at 12:26:41PM +0200, Michael Kerrisk (man-pages) wrote:
> I am torn between saying thank you for all the effort you
> clearly made and saying PLEASE DON'T DO THIS!

Ok.

> Submitting one hundred plus bug reports at the same time
> is _very_ burdensome for an upstream maintainer. Honestly,
> if it had not been for lockdown, I might simply have ignored
> the whole series of mails.

That would have been a pitty.

I would have assumed that you process them at your convenience, i.e.
each when you have time.

> In the future, please do not wait for  huge backlog to build up
> before sending me reports. (10 reports at a time is fine; 100, 
> not so much.)

Well, in the past (i.e. 10 years) we (german) translators always said
"we should report this". But "we" always amounted to no one doing it.
We were only recording issues found. So I finally decided to proceed. 

Since you are our biggest upstream, I started with your pages.
Intially I would have made one big bug report, but I understood this
is not requested from your side. 

Since it was mostly script based (and I was working on the scripts
while preparing) they came in all at once. I could have added a
throttle, like 10 / day, of course.

I'm still learning the process(es), so the next upstream might get a
better experience and I apologize for all the glitches I made.

Anyhow, I hope to report more frequent (and with much lower numbers) in
the future.

> In any case, thank you very much for your many reports.

Thanks from my side that you accepted and processed them.

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: On bug bombing
  2020-05-01  7:20   ` Helge Kreutzmann
@ 2020-05-01  8:34     ` Michael Kerrisk (man-pages)
  0 siblings, 0 replies; 5+ messages in thread
From: Michael Kerrisk (man-pages) @ 2020-05-01  8:34 UTC (permalink / raw)
  To: Helge Kreutzmann; +Cc: linux-man

Hello Helge,

On Fri, 1 May 2020 at 09:20, Helge Kreutzmann <debian@helgefjell.de> wrote:
>
> Hello Michael,
> On Mon, Apr 20, 2020 at 12:26:41PM +0200, Michael Kerrisk (man-pages) wrote:
> > I am torn between saying thank you for all the effort you
> > clearly made and saying PLEASE DON'T DO THIS!
>
> Ok.
>
> > Submitting one hundred plus bug reports at the same time
> > is _very_ burdensome for an upstream maintainer. Honestly,
> > if it had not been for lockdown, I might simply have ignored
> > the whole series of mails.
>
> That would have been a pitty.
>
> I would have assumed that you process them at your convenience, i.e.
> each when you have time.

Time is always in short supply :-}. And sometime, when I queue things,
they just get lost (for ever, or for a long time).

> > In the future, please do not wait for  huge backlog to build up
> > before sending me reports. (10 reports at a time is fine; 100,
> > not so much.)
>
> Well, in the past (i.e. 10 years) we (german) translators always said
> "we should report this". But "we" always amounted to no one doing it.
> We were only recording issues found. So I finally decided to proceed.

I figured that the story must be something like this. So, in any case,
thank you that you did the work. It is appreciated.

> Since you are our biggest upstream, I started with your pages.
> Intially I would have made one big bug report, but I understood this
> is not requested from your side.

Yes. Individual reports is best. That way, I can accept/reject/discuss
each issue individually.

> Since it was mostly script based (and I was working on the scripts
> while preparing) they came in all at once. I could have added a
> throttle, like 10 / day, of course.
>
> I'm still learning the process(es), so the next upstream might get a
> better experience and I apologize for all the glitches I made.

I do suggest at least warnin the upstream that a lot of reports are
about to land...

> Anyhow, I hope to report more frequent (and with much lower numbers) in
> the future.
>
> > In any case, thank you very much for your many reports.
>
> Thanks from my side that you accepted and processed them.

You're welcome!

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-19  6:48 Errors in man pages, here: mount_namespaces(7): Understanding Helge Kreutzmann
2020-04-20 10:14 ` Michael Kerrisk (man-pages)
2020-04-20 10:26 ` On bug bombing Michael Kerrisk (man-pages)
2020-05-01  7:20   ` Helge Kreutzmann
2020-05-01  8:34     ` Michael Kerrisk (man-pages)

Linux-man Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-man/0 linux-man/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-man linux-man/ https://lore.kernel.org/linux-man \
		linux-man@vger.kernel.org
	public-inbox-index linux-man

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-man


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git