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. ** Sentence to long "A signal may be generated (and thus pending) for a process as a whole (e." "g., when sent using B<kill>(2)) or for a specific thread (e.g., certain " "signals, such as B<SIGSEGV> and B<SIGFPE>, generated as a consequence of " "executing a specific machine-language instruction are thread directed, as " "are signals targeted at a specific thread using B<pthread_kill>(3)). A " "process-directed signal may be delivered to any one of the threads that does " "not currently have the signal blocked. If more than one of the threads has " "the signal unblocked, then the kernel chooses an arbitrary thread to which " "to deliver the signal." -- 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/
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. > > ** > > Sentence to long > > "A signal may be generated (and thus pending) for a process as a whole (e." > "g., when sent using B<kill>(2)) or for a specific thread (e.g., certain " > "signals, such as B<SIGSEGV> and B<SIGFPE>, generated as a consequence of " > "executing a specific machine-language instruction are thread directed, as " > "are signals targeted at a specific thread using B<pthread_kill>(3)). A " > "process-directed signal may be delivered to any one of the threads that does " > "not currently have the signal blocked. If more than one of the threads has " > "the signal unblocked, then the kernel chooses an arbitrary thread to which " > "to deliver the signal." I can't find the text referred to. I think you may be working with an older version of the page. Can you please check. Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
* Michael Kerrisk (man-pages) <mtk.manpages@gmail.com>, 2020-04-20, 10:33:
>>"A signal may be generated (and thus pending) for a process as a whole (e."
>>"g., when sent using B<kill>(2)) or for a specific thread (e.g., certain "
>>"signals, such as B<SIGSEGV> and B<SIGFPE>, generated as a consequence of "
>>"executing a specific machine-language instruction are thread directed, as "
>>"are signals targeted at a specific thread using B<pthread_kill>(3)). A "
>>"process-directed signal may be delivered to any one of the threads that does "
>>"not currently have the signal blocked. If more than one of the threads has "
>>"the signal unblocked, then the kernel chooses an arbitrary thread to which "
>>"to deliver the signal."
>
>I can't find the text referred to. I think you may be working
>with an older version of the page. Can you please check.
In 3b9d44099f234e8e, the long sentence was replaced with this paragraph:
"A signal may be process-directed or thread-directed. A process-directed
signal is one that is targeted at (and thus pending for) the process as
a whole. A signal may be process-directed because it was generated by
the kernel for reasons other than a hardware exception, or because it
was sent using kill(2) or sigqueue(3). A thread-directed signals is one
that is targeted at a specific thread. A signal may be thread-directed
because it was generated as a consequence of executing a specific
machine-language instruction that triggered a hardware exception (e.g.,
SIGSEGV for an invalid memory access, or SIGFPE for a math error), or
because it was it was targeted at a specific thread using interfaces
such as tgkill(2) or pthread_kill(3).
--
Jakub Wilk
On Mon, 20 Apr 2020 at 10:49, Jakub Wilk <jwilk@jwilk.net> wrote: > > * Michael Kerrisk (man-pages) <mtk.manpages@gmail.com>, 2020-04-20, 10:33: > >>"A signal may be generated (and thus pending) for a process as a whole (e." > >>"g., when sent using B<kill>(2)) or for a specific thread (e.g., certain " > >>"signals, such as B<SIGSEGV> and B<SIGFPE>, generated as a consequence of " > >>"executing a specific machine-language instruction are thread directed, as " > >>"are signals targeted at a specific thread using B<pthread_kill>(3)). A " > >>"process-directed signal may be delivered to any one of the threads that does " > >>"not currently have the signal blocked. If more than one of the threads has " > >>"the signal unblocked, then the kernel chooses an arbitrary thread to which " > >>"to deliver the signal." > > > >I can't find the text referred to. I think you may be working > >with an older version of the page. Can you please check. > > In 3b9d44099f234e8e, the long sentence was replaced with this paragraph: > > "A signal may be process-directed or thread-directed. A process-directed > signal is one that is targeted at (and thus pending for) the process as > a whole. A signal may be process-directed because it was generated by > the kernel for reasons other than a hardware exception, or because it > was sent using kill(2) or sigqueue(3). A thread-directed signals is one > that is targeted at a specific thread. A signal may be thread-directed > because it was generated as a consequence of executing a specific > machine-language instruction that triggered a hardware exception (e.g., > SIGSEGV for an invalid memory access, or SIGFPE for a math error), or > because it was it was targeted at a specific thread using interfaces > such as tgkill(2) or pthread_kill(3). Thanks, Jakub. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
[-- Attachment #1: Type: text/plain, Size: 2781 bytes --] Hello Michael, On Mon, Apr 20, 2020 at 10:51:00AM +0200, Michael Kerrisk (man-pages) wrote: > On Mon, 20 Apr 2020 at 10:49, Jakub Wilk <jwilk@jwilk.net> wrote: > > > > * Michael Kerrisk (man-pages) <mtk.manpages@gmail.com>, 2020-04-20, 10:33: > > >>"A signal may be generated (and thus pending) for a process as a whole (e." > > >>"g., when sent using B<kill>(2)) or for a specific thread (e.g., certain " > > >>"signals, such as B<SIGSEGV> and B<SIGFPE>, generated as a consequence of " > > >>"executing a specific machine-language instruction are thread directed, as " > > >>"are signals targeted at a specific thread using B<pthread_kill>(3)). A " > > >>"process-directed signal may be delivered to any one of the threads that does " > > >>"not currently have the signal blocked. If more than one of the threads has " > > >>"the signal unblocked, then the kernel chooses an arbitrary thread to which " > > >>"to deliver the signal." > > > > > >I can't find the text referred to. I think you may be working > > >with an older version of the page. Can you please check. > > > > In 3b9d44099f234e8e, the long sentence was replaced with this paragraph: > > > > "A signal may be process-directed or thread-directed. A process-directed > > signal is one that is targeted at (and thus pending for) the process as > > a whole. A signal may be process-directed because it was generated by > > the kernel for reasons other than a hardware exception, or because it > > was sent using kill(2) or sigqueue(3). A thread-directed signals is one > > that is targeted at a specific thread. A signal may be thread-directed > > because it was generated as a consequence of executing a specific > > machine-language instruction that triggered a hardware exception (e.g., > > SIGSEGV for an invalid memory access, or SIGFPE for a math error), or > > because it was it was targeted at a specific thread using interfaces > > such as tgkill(2) or pthread_kill(3). > > Thanks, Jakub. Thanks. We are working with what our upstreams provide, and especially archlinux tries to update frequently (but we might lag a few weeks behind them), so from time to time the issue might already been fixed. Due to the sheer size of upstreams and man pages and potential issues to be fixed we unfortunately might occasionally thus report issues already dealt with by you (or your fellow maintainers of other projects). Sorry for the noise. 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 --]