Message ID | 20220322142502.550191-1-michael.opdenacker@bootlin.com |
---|---|
State | New |
Headers | show |
Series | [honister] docs: fix hardcoded link warning messages | expand |
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
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.
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
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::