[PATCH] [honister] docs: fix hardcoded link warning messages

[PATCH] [honister] docs: fix hardcoded link warning messages

[michael.opdenacker]

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

Sphinx complains about hardcoded links which can be replaced by an
extlink.

So let's apply its recommendations.

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reported-by: Quentin Schulz <foss+yocto@0leil.net>
---
 documentation/bsp-guide/bsp.rst                  | 7 ++++---
 documentation/migration-guides/migration-3.4.rst | 2 +-
 documentation/overview-manual/yp-intro.rst       | 4 ++--
 documentation/ref-manual/system-requirements.rst | 2 +-
 4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index 65652ff898..1cc92d721d 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -166,8 +166,9 @@ section.
 #. *Determine the BSP Layer You Want:* The Yocto Project supports many
    BSPs, which are maintained in their own layers or in layers designed
    to contain several BSPs. To get an idea of machine support through
-   BSP layers, you can look at the `index of
-   machines <&YOCTO_RELEASE_DL_URL;/machines>`__ for the release.
+   BSP layers, you can look at the
+   :yocto_dl:`index of machines </releases/yocto/yocto-&DISTRO;/machines>`
+   for the release.
 
 #. *Optionally Clone the meta-intel BSP Layer:* If your hardware is
    based on current Intel CPUs and devices, you can leverage this BSP
@@ -877,7 +878,7 @@ Yocto Project:
    your BSP layer as listed in the ``recipes.txt`` file, which is found
    in ``poky/meta`` directory of the :term:`Source Directory`
    or in the OpenEmbedded-Core Layer (``openembedded-core``) at
-   https://git.openembedded.org/openembedded-core/tree/meta.
+   :oe_git:`/openembedded-core/tree/meta`.
 
    You should place recipes (``*.bb`` files) and recipe modifications
    (``*.bbappend`` files) into ``recipes-*`` subdirectories by
diff --git a/documentation/migration-guides/migration-3.4.rst b/documentation/migration-guides/migration-3.4.rst
index 6105015a24..8143cd4813 100644
--- a/documentation/migration-guides/migration-3.4.rst
+++ b/documentation/migration-guides/migration-3.4.rst
@@ -140,7 +140,7 @@ configuration provided and tested by the Yocto Project, there is
 simply no sense in continuing to enable prelink.
 
 There's also a concern that no one is maintaining the code, and there
-are open bugs (including `this serious one <https://bugzilla.yoctoproject.org/show_bug.cgi?id=14429>`__).
+are open bugs (including :yocto_bugs:`this serious one </show_bug.cgi?id=14429>`).
 Given that prelink does intricate address arithmetic and rewriting
 of binaries the best option is to disable the feature. It is recommended
 that you consider disabling this feature in your own configuration if
diff --git a/documentation/overview-manual/yp-intro.rst b/documentation/overview-manual/yp-intro.rst
index 7aee9db04f..3ca81428cf 100644
--- a/documentation/overview-manual/yp-intro.rst
+++ b/documentation/overview-manual/yp-intro.rst
@@ -217,8 +217,8 @@ your Metadata, the easier it is to cope with future changes.
    -  Use Board Support Package (BSP) layers from silicon vendors when
       possible.
 
-   -  Familiarize yourself with the `Yocto Project curated layer
-      index <https://www.yoctoproject.org/software-overview/layers/>`__
+   -  Familiarize yourself with the
+      :yocto_home:`Yocto Project curated layer index</software-overview/layers/>`
       or the :oe_layerindex:`OpenEmbedded layer index <>`.
       The latter contains more layers but they are less universally
       validated.
diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst
index 5c15b6de56..6df59a1745 100644
--- a/documentation/ref-manual/system-requirements.rst
+++ b/documentation/ref-manual/system-requirements.rst
@@ -320,7 +320,7 @@ If you would prefer not to use the ``install-buildtools`` script, you can instea
 download and run a pre-built buildtools installer yourself with the following
 steps:
 
-1. Locate and download the ``*.sh`` at &YOCTO_RELEASE_DL_URL;/buildtools/
+1. Locate and download the ``*.sh`` at :yocto_dl:`/releases/yocto/yocto-&DISTRO;/buildtools/`
 
 2. Execute the installation script. Here is an example for the
    traditional installer::
-- 
2.25.1

Re: [docs] [PATCH] [honister] docs: fix hardcoded link warning messages

[Quentin Schulz]

Hi Michael,

On 3/22/22 15:25, Michael Opdenacker via lists.yoctoproject.org wrote:
> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
> 
> Sphinx complains about hardcoded links which can be replaced by an
> extlink.
> 
> So let's apply its recommendations.
> 

If Sphinx is now happy,. I'm happy :)

BTW, you might want to send patches for honister tags to 
yocto-autobuilder-helper too otherwise we'll have build failures once we 
update sphinx package in the doc toolchain.

Thanks!
Quentin

Re: [docs] [PATCH] [honister] docs: fix hardcoded link warning messages

[Michael Opdenacker]

Hi Quentin,

On 3/22/22 15:35, Quentin Schulz wrote:
> Hi Michael,
>
> On 3/22/22 15:25, Michael Opdenacker via lists.yoctoproject.org wrote:
>> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
>>
>> Sphinx complains about hardcoded links which can be replaced by an
>> extlink.
>>
>> So let's apply its recommendations.
>>
>
> If Sphinx is now happy,. I'm happy :)


You were actually the first one to have a recent version of Sphinx and
propose such a patch for master.

>
> BTW, you might want to send patches for honister tags to
> yocto-autobuilder-helper too otherwise we'll have build failures once
> we update sphinx package in the doc toolchain.


... and for dunfell and hardknott tags too.
This sounds like a lot on not productive work, I'd prefer to contribute
to "master" instead :-|

I saw your latest patch
(https://git.yoctoproject.org/yocto-autobuilder-helper/commit/scripts/run-docs-build?id=8273124feb9da2ffe93fcee7c4529d5597e1684a)
and I understand that we don't break docs anymore when there is a
failure. But what about just ignoring warnings? At least these ones
don't have any impact on the generated docs.

Cheers
Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH] [honister] docs: fix hardcoded link warning messages

[Quentin Schulz]

Hi Michael,

On 3/22/22 15:58, Michael Opdenacker wrote:
> Hi Quentin,
> 
> On 3/22/22 15:35, Quentin Schulz wrote:
>> Hi Michael,
>>
>> On 3/22/22 15:25, Michael Opdenacker via lists.yoctoproject.org wrote:
>>> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
>>>
>>> Sphinx complains about hardcoded links which can be replaced by an
>>> extlink.
>>>
>>> So let's apply its recommendations.
>>>
>>
>> If Sphinx is now happy,. I'm happy :)
> 
> 
> You were actually the first one to have a recent version of Sphinx and
> propose such a patch for master.
> 
>>
>> BTW, you might want to send patches for honister tags to
>> yocto-autobuilder-helper too otherwise we'll have build failures once
>> we update sphinx package in the doc toolchain.
> 
> 
> ... and for dunfell and hardknott tags too.

Actually no. Those releases don't have the -W flag set.

> This sounds like a lot on not productive work, I'd prefer to contribute
> to "master" instead :-|
>

There'll be work involved for each Sphinx recipe update probably.

> I saw your latest patch
> (https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject.org_yocto-2Dautobuilder-2Dhelper_commit_scripts_run-2Ddocs-2Dbuild-3Fid-3D8273124feb9da2ffe93fcee7c4529d5597e1684a&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=7KvpXu-zWDEHrScQwpPEb1d7lQpqDn3tM0R6OX9vQ-setWP9vzh2eAaoa8Kh6YRC&s=jAUfJi_04ri8OvUg8fg9WTJCBYEqLd6QPSd08IqlW3c&e= )
> and I understand that we don't break docs anymore when there is a
> failure. But what about just ignoring warnings? At least these ones
> don't have any impact on the generated docs.
> 

Missing terms from bitbake are warnings IIRC and it's quite a big deal 
if we're not failing on those. I guess if we were able to mark only some 
warnings as errors, such as is possible with compilers for example, then 
I could imagine us doing something like this, yes. But in the 5s I 
looked for this I didn't find anything :/

Now that sphinx will be built by Yocto, we'll probably have much newer 
versions of Sphinx with more and more warnings (turned into errors). 
We'll need to see if it's worth patching or not or if we keep older 
toolchains (which kind of defeats the purpose of using Yocto Project to 
build the toolchain?).

Cheers,
Quentin