From 48748377a41a697a2b280ddbecb1c39487d1b7b8 Mon Sep 17 00:00:00 2001 From: Paul Barker Date: Fri, 27 Nov 2020 15:19:09 +0000 Subject: documentation: Simplify yocto_git links The yocto_git external link directive is modified to include the `/cgit/cgit.cgi` element of the URL so that we can simplify the links in the text. Manual links to git.yoctoproject.org are converted to use the yocto_git directive where possible. Note that this directive can't be used in some places such as example code. (From yocto-docs rev: 3a8ba5dcc783411c73fe49fb217cbc4d6528d9a7) Signed-off-by: Paul Barker Signed-off-by: Nicolas Dechesne Signed-off-by: Richard Purdie --- documentation/bsp-guide/bsp.rst | 21 ++++++------ documentation/conf.py | 2 +- .../dev-manual/dev-manual-common-tasks.rst | 39 ++++++++++------------ documentation/dev-manual/dev-manual-start.rst | 4 +-- documentation/kernel-dev/kernel-dev-advanced.rst | 4 +-- documentation/kernel-dev/kernel-dev-maint-appx.rst | 4 +-- .../overview-manual/overview-manual-concepts.rst | 17 +++++----- .../overview-manual-development-environment.rst | 7 ++-- .../overview-manual/overview-manual-yp-intro.rst | 12 +++---- documentation/ref-manual/migration-1.3.rst | 2 +- documentation/ref-manual/migration-1.6.rst | 2 +- documentation/ref-manual/migration-2.2.rst | 4 +-- documentation/ref-manual/migration-2.3.rst | 2 +- documentation/ref-manual/migration-2.5.rst | 6 ++-- documentation/ref-manual/migration-3.0.rst | 2 +- documentation/ref-manual/ref-classes.rst | 2 +- documentation/ref-manual/ref-devtool-reference.rst | 4 +-- documentation/ref-manual/ref-tasks.rst | 2 +- documentation/ref-manual/ref-terms.rst | 4 +-- documentation/ref-manual/ref-variables.rst | 2 +- documentation/test-manual/test-manual-intro.rst | 4 +-- .../test-manual/test-manual-test-process.rst | 6 ++-- .../toaster-manual/toaster-manual-reference.rst | 15 ++++----- .../toaster-manual-setup-and-use.rst | 4 +-- 24 files changed, 80 insertions(+), 91 deletions(-) (limited to 'documentation') diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst index d6a4f545cc..357e740a5c 100644 --- a/documentation/bsp-guide/bsp.rst +++ b/documentation/bsp-guide/bsp.rst @@ -172,8 +172,7 @@ section. #. *Optionally Clone the meta-intel BSP Layer:* If your hardware is based on current Intel CPUs and devices, you can leverage this BSP layer. For details on the ``meta-intel`` BSP layer, see the layer's - `README `__ - file. + :yocto_git:`README ` file. #. *Navigate to Your Source Directory:* Typically, you set up the ``meta-intel`` Git repository inside the :term:`Source Directory` (e.g. @@ -902,13 +901,13 @@ Yocto Project: ``meta-bsp_root_name`` directory. This license covers the BSP Metadata as a whole. You must specify which license to use since no default license exists when one is not specified. See the - :yocto_git:`COPYING.MIT ` + :yocto_git:`COPYING.MIT ` file for the Raspberry Pi BSP in the ``meta-raspberrypi`` BSP layer as an example. - *README File:* You must include a ``README`` file in the ``meta-bsp_root_name`` directory. See the - :yocto_git:`README.md ` + :yocto_git:`README.md ` file for the Raspberry Pi BSP in the ``meta-raspberrypi`` BSP layer as an example. @@ -1181,16 +1180,16 @@ Use these steps to create a BSP layer: :yocto_git:`Source Repositories <>`. To get examples of what you need in your configuration file, locate a layer (e.g. "meta-ti") and examine the - :yocto_git:`local.conf ` + :yocto_git:`local.conf ` file. - *Create a Machine Configuration File:* Create a ``conf/machine/bsp_root_name.conf`` file. See - :yocto_git:`meta-yocto-bsp/conf/machine ` + :yocto_git:`meta-yocto-bsp/conf/machine ` for sample ``bsp_root_name.conf`` files. Other samples such as - :yocto_git:`meta-ti ` + :yocto_git:`meta-ti ` and - :yocto_git:`meta-freescale ` + :yocto_git:`meta-freescale ` exist from other vendors that have more specific machine and tuning examples. @@ -1204,7 +1203,7 @@ Use these steps to create a BSP layer: The remainder of this section provides a description of the Yocto Project reference BSP for Beaglebone, which resides in the -:yocto_git:`meta-yocto-bsp ` +:yocto_git:`meta-yocto-bsp ` layer. BSP Layer Configuration Example @@ -1413,7 +1412,7 @@ Project Reference Manual. .. note:: For more information on how the SPL variables are used, see the - :yocto_git:`u-boot.inc ` + :yocto_git:`u-boot.inc ` include file. - :term:`UBOOT_* `: Defines @@ -1457,7 +1456,7 @@ The ``meta-yocto-bsp/recipes-kernel/linux`` directory in the layer contains metadata used to build the kernel. In this case, a kernel append file (i.e. ``linux-yocto_5.0.bbappend``) is used to override an established kernel recipe (i.e. ``linux-yocto_5.0.bb``), which is located in -:yocto_git:`/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux`. +:yocto_git:`/poky/tree/meta/recipes-kernel/linux`. Following is the contents of the append file: :: diff --git a/documentation/conf.py b/documentation/conf.py index c906d066a9..a626b1f14d 100644 --- a/documentation/conf.py +++ b/documentation/conf.py @@ -75,7 +75,7 @@ extlinks = { 'yocto_bugs': ('https://bugzilla.yoctoproject.org%s', None), 'yocto_ab': ('https://autobuilder.yoctoproject.org%s', None), 'yocto_docs': ('https://docs.yoctoproject.org%s', None), - 'yocto_git': ('https://git.yoctoproject.org%s', None), + 'yocto_git': ('https://git.yoctoproject.org/cgit/cgit.cgi%s', None), 'oe_home': ('https://www.openembedded.org%s', None), 'oe_lists': ('https://lists.openembedded.org%s', None), 'oe_git': ('https://git.openembedded.org%s', None), diff --git a/documentation/dev-manual/dev-manual-common-tasks.rst b/documentation/dev-manual/dev-manual-common-tasks.rst index 4257a4bb99..891fd9b001 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.rst +++ b/documentation/dev-manual/dev-manual-common-tasks.rst @@ -75,7 +75,7 @@ Follow these general steps to create your layer without using tools: ``conf`` directory and then modify the file as needed. The ``meta-yocto-bsp/conf/layer.conf`` file in the Yocto Project - :yocto_git:`Source Repositories ` + :yocto_git:`Source Repositories ` demonstrates the required syntax. For your layer, you need to replace "yoctobsp" with a unique identifier for your layer (e.g. "machinexyz" for a layer named "meta-machinexyz"): @@ -2107,15 +2107,12 @@ being able to provide the ``virtual/kernel`` item. Now comes the time to actually build an image and you need a kernel recipe, but which one? You can configure your build to call out the -kernel recipe you want by using the -:term:`PREFERRED_PROVIDER` -variable. As an example, consider the -`x86-base.inc `_ -include file, which is a machine (i.e. -:term:`MACHINE`) configuration file. -This include file is the reason all x86-based machines use the -``linux-yocto`` kernel. Here are the relevant lines from the include -file: +kernel recipe you want by using the :term:`PREFERRED_PROVIDER` variable. As +an example, consider the :yocto_git:`x86-base.inc +` include file, which is a +machine (i.e. :term:`MACHINE`) configuration file. This include file is the +reason all x86-based machines use the ``linux-yocto`` kernel. Here are the +relevant lines from the include file: :: PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto" @@ -3058,7 +3055,7 @@ The following steps describe how to set up the AUH utility: 7. *Create and Edit an AUH Configuration File:* You need to have the ``upgrade-helper/upgrade-helper.conf`` configuration file in your build directory. You can find a sample configuration file in the - :yocto_git:`AUH source repository `. + :yocto_git:`AUH source repository `. Read through the sample file and make configurations as needed. For example, if you enabled build history in your ``local.conf`` as @@ -3122,7 +3119,7 @@ the layer tree. You can easily set up to run the AUH utility on a regular basis by using a cron job. See the -:yocto_git:`weeklyjob.sh ` +:yocto_git:`weeklyjob.sh ` file distributed with the utility for an example. Using ``devtool upgrade`` @@ -4362,9 +4359,9 @@ your tunings to best consider build times and package feed maintenance. higher levels noted earlier can be useful. For example, consider how NXP (formerly Freescale) allows for the easy reuse of binary packages in their layer - :yocto_git:`meta-freescale `. + :yocto_git:`meta-freescale `. In this example, the - :yocto_git:`fsl-dynamic-packagearch ` + :yocto_git:`fsl-dynamic-packagearch ` class shares GPU packages for i.MX53 boards because all boards share the AMD GPU. The i.MX6-based boards can do the same because all boards share the Vivante GPU. This class inspects the BitBake @@ -5564,7 +5561,7 @@ partition. Source plugins are subclasses defined in plugin files. As shipped, the Yocto Project provides several plugin files. You can see the source plugin files that ship with the Yocto Project -:yocto_git:`here `. +:yocto_git:`here `. Each of these plugin files contains source plugins that are designed to populate a specific Wic image partition. @@ -6175,7 +6172,7 @@ system to make your images more secure: - Consider enabling a Mandatory Access Control (MAC) framework such as SMACK or SELinux and tuning it appropriately for your device's usage. You can find more information in the - :yocto_git:`meta-selinux ` layer. + :yocto_git:`meta-selinux ` layer. Tools for Hardening Your Image ------------------------------ @@ -8436,7 +8433,7 @@ might be significant in human-readable form. Here is an example: To see changes to the build history using a web interface, follow the instruction in the ``README`` file -:yocto_git:`here `. +:yocto_git:`here `. Here is a sample screenshot of the interface: @@ -9511,7 +9508,7 @@ the build system to run the task again. For an example of a commit that makes a cosmetic change to invalidate shared state, see this - :yocto_git:`commit `. + :yocto_git:`commit `. Running Specific Tasks ---------------------- @@ -10475,7 +10472,7 @@ used testing branches for OpenEmbedded-Core are as follows: proposed changes to the core metadata. - *poky "master-next" branch:* This branch is part of the - :yocto_git:`poky ` repository and combines proposed + :yocto_git:`poky ` repository and combines proposed changes to bitbake, the core metadata and the poky distro. Similarly, stable branches maintained by the project may have corresponding @@ -11381,7 +11378,7 @@ this function, you have to follow the following steps: SPDX_DEPLOY_DIR = "${DEPLOY_DIR}" //Optional For more usage information refer to :yocto_git:`the meta-spdxscanner repository -`. +`. Copying Licenses that Do Not Exist @@ -11487,7 +11484,7 @@ Setting Up Your Own Error Reporting Server ------------------------------------------ If you want to set up your own error reporting server, you can obtain -the code from the Git repository at :yocto_git:`/cgit/cgit.cgi/error-report-web/`. +the code from the Git repository at :yocto_git:`/error-report-web/`. Instructions on how to set it up are in the README document. Using Wayland and Weston diff --git a/documentation/dev-manual/dev-manual-start.rst b/documentation/dev-manual/dev-manual-start.rst index 07e822899a..1c2314c430 100644 --- a/documentation/dev-manual/dev-manual-start.rst +++ b/documentation/dev-manual/dev-manual-start.rst @@ -586,7 +586,7 @@ Working from a copy of the upstream :ref:`dev-manual/dev-manual-start:accessing preferred method for obtaining and using a Yocto Project release. You can view the Yocto Project Source Repositories at :yocto_git:`/`. In particular, you can find the ``poky`` -repository at :yocto_git:`/cgit.cgi/poky`. +repository at :yocto_git:`/poky`. Use the following procedure to locate the latest upstream copy of the ``poky`` Git repository: @@ -600,7 +600,7 @@ Use the following procedure to locate the latest upstream copy of the 3. *Find the URL Used to Clone the Repository:* At the bottom of the page, note the URL used to clone that repository - (e.g. :yocto_git:`/cgit.cgi/poky`). + (e.g. :yocto_git:`/poky`). .. note:: diff --git a/documentation/kernel-dev/kernel-dev-advanced.rst b/documentation/kernel-dev/kernel-dev-advanced.rst index 6999057b8a..db0a1eb2e5 100644 --- a/documentation/kernel-dev/kernel-dev-advanced.rst +++ b/documentation/kernel-dev/kernel-dev-advanced.rst @@ -200,7 +200,7 @@ either :term:`FILESEXTRAPATHS` if you are creating Metadata in `recipe-space <#recipe-space-metadata>`__, or the top level of -:yocto_git:`yocto-kernel-cache ` +:yocto_git:`yocto-kernel-cache ` if you are creating `Metadata outside of the recipe-space <#metadata-outside-the-recipe-space>`__. @@ -469,7 +469,7 @@ supported kernel type. For BSPs supported by the Yocto Project, the BSP description files are located in the ``bsp`` directory of the ``yocto-kernel-cache`` repository organized under the "Yocto Linux Kernel" heading in the - :yocto_git:`Yocto Project Source Repositories `. + :yocto_git:`Yocto Project Source Repositories <>`. This section overviews the BSP description structure, the aggregation concepts, and presents a detailed example using a BSP supported by the diff --git a/documentation/kernel-dev/kernel-dev-maint-appx.rst b/documentation/kernel-dev/kernel-dev-maint-appx.rst index 69f680688f..ec1c0ac03d 100644 --- a/documentation/kernel-dev/kernel-dev-maint-appx.rst +++ b/documentation/kernel-dev/kernel-dev-maint-appx.rst @@ -103,7 +103,7 @@ patch, or BSP: located by searching these system directories: - The in-tree kernel-cache directories, which are located in the - :yocto_git:`yocto-kernel-cache ` + :yocto_git:`yocto-kernel-cache ` repository organized under the "Yocto Linux Kernel" heading in the :yocto_git:`Yocto Project Source Repositories <>`. @@ -167,7 +167,7 @@ specific to some target hardware. The end result is a branched, clean history tree that makes up the kernel for a given release. You can see the script (``kgit-scc``) responsible for this in the - :yocto_git:`yocto-kernel-tools ` + :yocto_git:`yocto-kernel-tools ` repository. - The steps used to construct the full kernel tree are the same diff --git a/documentation/overview-manual/overview-manual-concepts.rst b/documentation/overview-manual/overview-manual-concepts.rst index 353a2f99ff..1b522910d2 100644 --- a/documentation/overview-manual/overview-manual-concepts.rst +++ b/documentation/overview-manual/overview-manual-concepts.rst @@ -273,7 +273,7 @@ The ``local.conf`` file provides many basic variables that define a build environment. Here is a list of a few. To see the default configurations in a ``local.conf`` file created by the build environment script, see the -:yocto_git:`local.conf.sample ` +:yocto_git:`local.conf.sample ` in the ``meta-poky`` layer: - *Target Machine Selection:* Controlled by the @@ -393,17 +393,17 @@ figure <#general-workflow-figure>`__: configurations. This type of information is specific to a particular target architecture. A good example of a BSP layer from the `Poky Reference Distribution <#gs-reference-distribution-poky>`__ is the - :yocto_git:`meta-yocto-bsp ` + :yocto_git:`meta-yocto-bsp ` layer. - *Policy Configuration:* Distribution Layers (i.e. "Distro Layer" in the following figure) providing top-level or general policies for the images or SDKs being built for a particular distribution. For example, in the Poky Reference Distribution the distro layer is the - :yocto_git:`meta-poky ` + :yocto_git:`meta-poky ` layer. Within the distro layer is a ``conf/distro`` directory that contains distro configuration files (e.g. - :yocto_git:`poky.conf ` + :yocto_git:`poky.conf ` that contain many policy configurations for the Poky distribution. The following figure shows an expanded representation of these three @@ -427,9 +427,8 @@ Model <#the-yocto-project-layer-model>`__" sections both earlier in this manual. If you explored the previous links, you discovered some areas where many -layers that work with the Yocto Project exist. The `Source -Repositories `__ also shows layers -categorized under "Yocto Metadata Layers." +layers that work with the Yocto Project exist. The :yocto_git:`Source +Repositories <>` also shows layers categorized under "Yocto Metadata Layers." .. note:: @@ -879,7 +878,7 @@ This step in the build process consists of the following tasks: variables. For information on how this variable works within that class, see the :ref:`autotools ` class - :yocto_git:`here `. + :yocto_git:`here `. - *do_compile*: Once a configuration task has been satisfied, BitBake compiles the source using the @@ -957,7 +956,7 @@ The :term:`FILES` variable defines the files that go into each package in :term:`PACKAGES`. If you want details on how this is accomplished, you can look at -:yocto_git:`package.bbclass `. +:yocto_git:`package.bbclass `. Depending on the type of packages being created (RPM, DEB, or IPK), the :ref:`do_package_write_* ` diff --git a/documentation/overview-manual/overview-manual-development-environment.rst b/documentation/overview-manual/overview-manual-development-environment.rst index 983e1919ef..5baf08946b 100644 --- a/documentation/overview-manual/overview-manual-development-environment.rst +++ b/documentation/overview-manual/overview-manual-development-environment.rst @@ -416,7 +416,7 @@ files. Git uses "branches" to organize different development efforts. For example, the ``poky`` repository has several branches that include the current "&DISTRO_NAME_NO_CAP;" branch, the "master" branch, and many branches for past Yocto Project releases. You can see all the branches -by going to https://git.yoctoproject.org/cgit.cgi/poky/ and clicking on the +by going to :yocto_git:`/poky/` and clicking on the ``[...]`` link beneath the "Branch" heading. Each of these branches represents a specific area of development. The @@ -461,9 +461,8 @@ Yocto Project Release. Git uses "tags" to mark specific changes in a repository branch structure. Typically, a tag is used to mark a special point such as the final change (or commit) before a project is released. You can see the -tags used with the ``poky`` Git repository by going to -https://git.yoctoproject.org/cgit.cgi/poky/ and clicking on the ``[...]`` link -beneath the "Tag" heading. +tags used with the ``poky`` Git repository by going to :yocto_git:`/poky/` +and clicking on the ``[...]`` link beneath the "Tag" heading. Some key tags for the ``poky`` repository are ``jethro-14.0.3``, ``morty-16.0.1``, ``pyro-17.0.0``, and diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/overview-manual-yp-intro.rst index 83ed18a375..2b9ea91490 100644 --- a/documentation/overview-manual/overview-manual-yp-intro.rst +++ b/documentation/overview-manual/overview-manual-yp-intro.rst @@ -267,9 +267,8 @@ with the string ``meta-``. , but it is a commonly accepted standard in the Yocto Project community. -For example, if you were to examine the `tree -view `__ of the -``poky`` repository, you will see several layers: ``meta``, +For example, if you were to examine the :yocto_git:`tree view ` +of the ``poky`` repository, you will see several layers: ``meta``, ``meta-skeleton``, ``meta-selftest``, ``meta-poky``, and ``meta-yocto-bsp``. Each of these repositories represents a distinct layer. @@ -467,7 +466,7 @@ The following list consists of components associated with the OpenEmbedded-derived systems, which includes the Yocto Project. The Yocto Project and the OpenEmbedded Project both maintain the OpenEmbedded-Core. You can find the OE-Core metadata in the Yocto - Project :yocto_git:`Source Repositories `. + Project :yocto_git:`Source Repositories `. Historically, the Yocto Project integrated the OE-Core metadata throughout the Yocto Project source repository reference system @@ -671,7 +670,7 @@ Poky is a combined repository of BitBake, OpenEmbedded-Core (which is found in ``meta``), ``meta-poky``, ``meta-yocto-bsp``, and documentation provided all together and known to work well together. You can view these items that make up the Poky repository in the -:yocto_git:`Source Repositories `. +:yocto_git:`Source Repositories `. .. note:: @@ -870,8 +869,7 @@ helpful for getting started: set of recipes. You can see the Metadata in the ``meta`` directory of the Yocto - Project `Source - Repositories `__. + Project :yocto_git:`Source Repositories <>`. - *Packages:* In the context of the Yocto Project, this term refers to a recipe's packaged output produced by BitBake (i.e. a "baked diff --git a/documentation/ref-manual/migration-1.3.rst b/documentation/ref-manual/migration-1.3.rst index 5f975850ba..12e225b149 100644 --- a/documentation/ref-manual/migration-1.3.rst +++ b/documentation/ref-manual/migration-1.3.rst @@ -173,7 +173,7 @@ the OpenEmbedded community layers such as ``meta-oe`` and ``meta-gnome``. For the remainder, you can now find them in the ``meta-extras`` repository, which is in the :yocto_git:`Source Repositories <>` at -:yocto_git:`/cgit/cgit.cgi/meta-extras/`. +:yocto_git:`/meta-extras/`. .. _1.3-linux-kernel-naming: diff --git a/documentation/ref-manual/migration-1.6.rst b/documentation/ref-manual/migration-1.6.rst index a6c4c8a93a..822d5cfa03 100644 --- a/documentation/ref-manual/migration-1.6.rst +++ b/documentation/ref-manual/migration-1.6.rst @@ -411,6 +411,6 @@ The previous reference BSPs for the ``beagleboard`` and ``routerstationpro`` machines are still available in a new ``meta-yocto-bsp-old`` layer in the :yocto_git:`Source Repositories <>` at -:yocto_git:`/cgit/cgit.cgi/meta-yocto-bsp-old/`. +:yocto_git:`/meta-yocto-bsp-old/`. diff --git a/documentation/ref-manual/migration-2.2.rst b/documentation/ref-manual/migration-2.2.rst index 8afa8ffdda..ac247dce46 100644 --- a/documentation/ref-manual/migration-2.2.rst +++ b/documentation/ref-manual/migration-2.2.rst @@ -292,9 +292,9 @@ The following changes took place for BitBake: functionality. These changes will affect external tools that use BitBake's tinfoil module. For information on these changes, see the changes made to the scripts supplied with OpenEmbedded-Core: - `1 `__ + :yocto_git:`1 ` and - `2 `__. + :yocto_git:`2 `. - The task management code has been rewritten to avoid using ID indirection in order to improve performance. This change is unlikely diff --git a/documentation/ref-manual/migration-2.3.rst b/documentation/ref-manual/migration-2.3.rst index 4041ad0556..c0a8f04195 100644 --- a/documentation/ref-manual/migration-2.3.rst +++ b/documentation/ref-manual/migration-2.3.rst @@ -323,7 +323,7 @@ The following package management changes took place: .. note:: For further details on this change, see the - :yocto_git:`commit message `. + :yocto_git:`commit message `. .. _migration-2.3-removed-recipes: diff --git a/documentation/ref-manual/migration-2.5.rst b/documentation/ref-manual/migration-2.5.rst index 1aeddc81c3..7f1b80938f 100644 --- a/documentation/ref-manual/migration-2.5.rst +++ b/documentation/ref-manual/migration-2.5.rst @@ -180,7 +180,7 @@ or :: The earlier build-time provides behavior was a quirk of the way the Python manifest file was created. For more information on this change please see :yocto_git:`this commit -`. +`. .. _migration-2.5-miscellaneous-changes: @@ -293,8 +293,8 @@ The following are additional changes: - Patches whose context does not match exactly (i.e. where patch reports "fuzz" when applying) will generate a warning. For an example - of this see `this - commit `__. + of this see :yocto_git:`this commit + `. - Layers are expected to set ``LAYERSERIES_COMPAT_layername`` to match the version(s) of OpenEmbedded-Core they are compatible with. This is diff --git a/documentation/ref-manual/migration-3.0.rst b/documentation/ref-manual/migration-3.0.rst index 047b75526f..7ef2742f8b 100644 --- a/documentation/ref-manual/migration-3.0.rst +++ b/documentation/ref-manual/migration-3.0.rst @@ -197,7 +197,7 @@ The following BitBake changes have occurred. - The arguments passed to functions used with :term:`bitbake:BB_HASHCHECK_FUNCTION` have changed. If you are using your own custom hash check function, - see :yocto_git:`/cgit/cgit.cgi/poky/commit/?id=40a5e193c4ba45c928fccd899415ea56b5417725` + see :yocto_git:`/poky/commit/?id=40a5e193c4ba45c928fccd899415ea56b5417725` for details. - Task specifications in ``BB_TASKDEPDATA`` and class implementations diff --git a/documentation/ref-manual/ref-classes.rst b/documentation/ref-manual/ref-classes.rst index 62876194d1..e0cdbe87fa 100644 --- a/documentation/ref-manual/ref-classes.rst +++ b/documentation/ref-manual/ref-classes.rst @@ -2774,7 +2774,7 @@ To use this class, you need to define a number of variables: These variables list alternative commands needed by a package, provide pathnames for links, default links for targets, and so forth. For details on how to use this class, see the comments in the -:yocto_git:`update-alternatives.bbclass ` +:yocto_git:`update-alternatives.bbclass ` file. .. note:: diff --git a/documentation/ref-manual/ref-devtool-reference.rst b/documentation/ref-manual/ref-devtool-reference.rst index 93fd1465f9..a769b3bd40 100644 --- a/documentation/ref-manual/ref-devtool-reference.rst +++ b/documentation/ref-manual/ref-devtool-reference.rst @@ -349,7 +349,7 @@ particular recipe. .. note:: - For the ``oe-core`` layer, recipe maintainers come from the - `maintainers.inc `_ + :yocto_git:`maintainers.inc ` file. - If the recipe is using the :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:git fetcher (\`\`git://\`\`)` @@ -388,7 +388,7 @@ satisfied. When a reason for not upgrading displays, the reason is usually written into the recipe using the ``RECIPE_NO_UPDATE_REASON`` variable. See the - :yocto_git:`base-passwd.bb ` + :yocto_git:`base-passwd.bb ` recipe for an example. :: diff --git a/documentation/ref-manual/ref-tasks.rst b/documentation/ref-manual/ref-tasks.rst index 299e8f7d66..9fde9a8378 100644 --- a/documentation/ref-manual/ref-tasks.rst +++ b/documentation/ref-manual/ref-tasks.rst @@ -301,7 +301,7 @@ to locate and apply patch files to the source code. Patch files, by default, are ``*.patch`` and ``*.diff`` files created and kept in a subdirectory of the directory holding the recipe file. For example, consider the -:yocto_git:`bluez5 ` +:yocto_git:`bluez5 ` recipe from the OE-Core layer (i.e. ``poky/meta``): :: diff --git a/documentation/ref-manual/ref-terms.rst b/documentation/ref-manual/ref-terms.rst index b4ceebc0bb..f59aaf2788 100644 --- a/documentation/ref-manual/ref-terms.rst +++ b/documentation/ref-manual/ref-terms.rst @@ -218,7 +218,7 @@ universal, the list includes them just in case: In the context of the kernel ("kernel Metadata"), the term refers to the kernel config fragments and features contained in the - :yocto_git:`yocto-kernel-cache ` + :yocto_git:`yocto-kernel-cache ` Git repository. :term:`OpenEmbedded-Core (OE-Core)` @@ -232,7 +232,7 @@ universal, the list includes them just in case: core set of recipes. You can see the Metadata in the ``meta`` directory of the Yocto - Project :yocto_git:`Source Repositories `. + Project :yocto_git:`Source Repositories `. :term:`OpenEmbedded Build System` The build system specific to the Yocto diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/ref-variables.rst index 921d19e7f5..f8cd5416d9 100644 --- a/documentation/ref-manual/ref-variables.rst +++ b/documentation/ref-manual/ref-variables.rst @@ -3600,7 +3600,7 @@ system and gives an overview of their function and contents. configuration file. You cannot set the variable in a recipe file. See the - :yocto_git:`local.conf.sample.extended ` + :yocto_git:`local.conf.sample.extended ` file for additional information. Also, for information on creating an initramfs, see the ":ref:`dev-manual/dev-manual-common-tasks:building an initial ram filesystem (initramfs) image`" section in the Yocto Project Development Tasks Manual. diff --git a/documentation/test-manual/test-manual-intro.rst b/documentation/test-manual/test-manual-intro.rst index cf511e9256..b41972084b 100644 --- a/documentation/test-manual/test-manual-intro.rst +++ b/documentation/test-manual/test-manual-intro.rst @@ -25,14 +25,14 @@ loaded with information from the README files and notes from key engineers: - *yocto-autobuilder2:* This - :yocto_git:`README.md ` + :yocto_git:`README.md ` is the main README which detials how to set up the Yocto Project Autobuilder. The ``yocto-autobuilder2`` repository represents the Yocto Project's console UI plugin to Buildbot and the configuration necessary to configure Buildbot to perform the testing the project requires. -- *yocto-autobuilder-helper:* This :yocto_git:`README ` +- *yocto-autobuilder-helper:* This :yocto_git:`README ` and repository contains Yocto Project Autobuilder Helper scripts and configuration. The ``yocto-autobuilder-helper`` repository contains the "glue" logic that defines which tests to run and how to run them. diff --git a/documentation/test-manual/test-manual-test-process.rst b/documentation/test-manual/test-manual-test-process.rst index bbf0103803..8a5e29d922 100644 --- a/documentation/test-manual/test-manual-test-process.rst +++ b/documentation/test-manual/test-manual-test-process.rst @@ -35,9 +35,9 @@ which the result was required. The Autobuilder does build the ``master`` branch once daily for several reasons, in particular, to ensure the current ``master`` branch does build, but also to keep ``yocto-testresults`` -(:yocto_git:`/cgit.cgi/yocto-testresults/`), +(:yocto_git:`/yocto-testresults/`), buildhistory -(:yocto_git:`/cgit.cgi/poky-buildhistory/`), and +(:yocto_git:`/poky-buildhistory/`), and our sstate up to date. On the weekend, there is a master-next build instead to ensure the test results are updated for the less frequently run targets. @@ -45,7 +45,7 @@ run targets. Performance builds (buildperf-\* targets in the console) are triggered separately every six hours and automatically push their results to the buildstats repository at: -:yocto_git:`/cgit.cgi/yocto-buildstats/`. +:yocto_git:`/yocto-buildstats/`. The 'quick' targets have been selected to be the ones which catch the most failures or give the most valuable data. We run 'fast' ptests in diff --git a/documentation/toaster-manual/toaster-manual-reference.rst b/documentation/toaster-manual/toaster-manual-reference.rst index 2202d599f6..ed0bad11b7 100644 --- a/documentation/toaster-manual/toaster-manual-reference.rst +++ b/documentation/toaster-manual/toaster-manual-reference.rst @@ -25,8 +25,7 @@ A layer index is a web application that contains information about a set of custom layers. A good example of an existing layer index is the OpenEmbedded Layer Index. A public instance of this layer index exists at http://layers.openembedded.org. You can find the code for this -layer index's web application at -http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/. +layer index's web application at :yocto_git:`/layerindex-web/`. When you tie a layer source into Toaster, it can query the layer source through a @@ -83,9 +82,8 @@ index. In the previous section, the code for the OpenEmbedded Metadata Index (i.e. http://layers.openembedded.org) was referenced. You can use -this code, which is at -http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/, as a -base to create your own layer index. +this code, which is at :yocto_git:`/layerindex-web/`, as a base to create +your own layer index. Use the Administration Interface ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -165,14 +163,13 @@ As shipped, Toaster is configured to work with the following releases: - *Yocto Project &DISTRO; "&DISTRO_NAME;" or OpenEmbedded "&DISTRO_NAME;":* This release causes your Toaster projects to build against the head of the &DISTRO_NAME_NO_CAP; branch at - https://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=&DISTRO_NAME_NO_CAP; or - http://git.openembedded.org/openembedded-core/commit/?h=&DISTRO_NAME_NO_CAP;. + :yocto_git:`/poky/log/?h=&DISTRO_NAME_NO_CAP;` or + :oe_git:`/openembedded-core/commit/?h=&DISTRO_NAME_NO_CAP;`. - *Yocto Project "Master" or OpenEmbedded "Master":* This release causes your Toaster Projects to build against the head of the master branch, which is where active development takes place, at - https://git.yoctoproject.org/cgit/cgit.cgi/poky/log/ or - http://git.openembedded.org/openembedded-core/log/. + :yocto_git:`/poky/log/` or :oe_git:`/openembedded-core/log/`. - *Local Yocto Project or Local OpenEmbedded:* This release causes your Toaster Projects to build against the head of the ``poky`` or diff --git a/documentation/toaster-manual/toaster-manual-setup-and-use.rst b/documentation/toaster-manual/toaster-manual-setup-and-use.rst index b73caac375..6e2ba02531 100644 --- a/documentation/toaster-manual/toaster-manual-setup-and-use.rst +++ b/documentation/toaster-manual/toaster-manual-setup-and-use.rst @@ -561,8 +561,8 @@ the same clone you are using to run Toaster. Unless you manually update this clone, your builds will always use the same Git revision. If you select any of the other release options, Toaster will fetch the -tip of your selected release from the upstream `Yocto Project -repository `__ every time you run a build. +tip of your selected release from the upstream :yocto_git:`Yocto Project +repository <>` every time you run a build. Fetching this tip effectively means that if your selected release is updated upstream, the Git revision you are using for your builds will change. If you are doing development locally, you might not want this -- cgit v1.2.3-54-g00ecf