On 26.02.25 21:34, Jelle van der Waa wrote: > From: James Addison <jay@xxxxxxxxxxxxxx> > > According to the reStructuredText documentation, internal hyperlink > targets[1] are intended to resolve within the current document. > > Sphinx has a bug that causes internal hyperlinks declared with > duplicate names to resolve nondeterministically, producing incorrect > documentation. Sphinx does not yet emit a warning when these > duplicate target names are declared. > > To improve the reproducibility and correctness of the HTML > documentation, disambiguate two labels both previously titled > "submit_improvements". > > [1] - https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#hyperlink-targets > > Link: https://github.com/sphinx-doc/sphinx/issues/13383 > Signed-off-by: James Addison <jay@xxxxxxxxxxxxxx> > > --- > V1 -> V2: re-send using different email client Many thx for looking into this. FWIW, next time please run ./scripts/get_maintainer.pl and then ensure to add the maintainers of the modified files to the list of recipients. > --- > Documentation/admin-guide/quickly-build-trimmed-linux.rst | 4 ++-- > .../admin-guide/verify-bugs-and-bisect-regressions.rst | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/Documentation/admin-guide/quickly-build-trimmed-linux.rst b/Documentation/admin-guide/quickly-build-trimmed-linux.rst > index 07cfd8863b46..2d1b6f7504c1 100644 > --- a/Documentation/admin-guide/quickly-build-trimmed-linux.rst > +++ b/Documentation/admin-guide/quickly-build-trimmed-linux.rst > @@ -347,7 +347,7 @@ again. > > [:ref:`details<uninstall>`] > > -.. _submit_improvements: > +.. _submit_trimmed_build_improvements: Hmm. Does not matter much, but adding that "trimmed_build" in the middle feels quite a bit odd to me. I recently in a similar situation added a short suffix; here it could be "_qbtl", which is derived from the initials of the file modified. I'd say that is a lot better, but using something longer is fine for me as well, especially if it's only needed in one or two places. > Did you run into trouble following any of the above steps that is not cleared up > by the reference section below? Or do you have ideas how to improve the text? > @@ -1070,7 +1070,7 @@ complicated, and harder to follow. > > That being said: this of course is a balancing act. Hence, if you think an > additional use-case is worth describing, suggest it to the maintainers of this > -document, as :ref:`described above <submit_improvements>`. > +document, as :ref:`described above <submit_trimmed_build_improvements>`. > > > .. > diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst > index 03c55151346c..1b246d8a8afb 100644 > --- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst > +++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst > @@ -267,7 +267,7 @@ culprit might be known already. For further details on what actually qualifies > as a regression check out Documentation/admin-guide/reporting-regressions.rst. > > If you run into any problems while following this guide or have ideas how to > -improve it, :ref:`please let the kernel developers know <submit_improvements>`. > +improve it, :ref:`please let the kernel developers know <submit_regression_tracing_improvements>`. > > .. _introprep_bissbs: > > @@ -1055,7 +1055,7 @@ follow these instructions. > > [:ref:`details <introoptional_bisref>`] > > -.. _submit_improvements: > +.. _submit_regression_tracing_improvements: Same here with a different suffix. Ciao, Thorsten
