[PATCH v2 00/56] Remove obsolete poky repo references

[PATCH v2 00/56] Remove obsolete poky repo references

[Antonin Godard]

The Poky repository's master branch is no longer updated:
https://git.yoctoproject.org/poky/tree/README

Many places in the documentation were still making references to Poky as
in the repository. Migrate the documentation in two steps:

Check all occurrences of "poky" or "source directory"
(case-insensitive/multiline match), and reformulate/adapt.

Most of the occurrences will usually be a path in Poky that can be
replaced by OE-Core/meta-yocto.

Some others are more tricky, and needed some re-organization / rework.
For that reason, patch were split by files, to make reviewing/merging
easier and incremental.

This series depends on the "Redefine terms now that the Poky repository is
obsolete" series which redefines terms used to replaces occurrences
here.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
Changes in v2:
- Rename "project" to "bitbake-builds" across the whole series, to match
  the default naming of bitbake-setup.
- Apply Reviewed-by trailers from Quentin on patches with no
  modifications. Reviewed-by trailers on modified patches were not
  applied.
- Apply the suggestions from Quentin on the v1. Thanks a lot Quentin for
  the thorough review.
- Link to v1: https://patch.msgid.link/20251224-remove-poky-references-v1-0-658a5f4dbde2@bootlin.com

---
Antonin Godard (56):
      transitioning-to-a-custom-environment.rst: remove obsolete poky repo references
      dev-manual/poky-manual-setup.rst: remove obsolete poky repo references
      dev-manual/start.rst: remove obsolete poky repo references
      bsp-guide/bsp.rst: remove obsolete poky repo references
      kernel-dev/advanced.rst: remove obsolete poky repo references
      contributor-guide/submit-changes.rst: remove obsolete poky repo references
      dev-manual/building.rst: remove obsolete poky repo references
      dev-manual/debugging.rst: remove obsolete poky repo references
      dev-manual/error-reporting-tool.rst: remove obsolete poky repo references
      dev-manual/external-toolchain.rst: remove obsolete poky repo references
      dev-manual/layers.rst: remove obsolete poky repo references
      dev-manual/layers.rst: remove obsolete poky repo references
      dev-manual/libraries.rst: remove obsolete poky repo references
      dev-manual/new-recipe.rst: remove obsolete poky repo references
      dev-manual/securing-images.rst: remove obsolete poky repo references
      dev-manual/temporary-source-code.rst: remove obsolete poky repo references
      dev-manual/wayland.rst: remove obsolete poky repo references
      dev-manual/wic.rst: remove obsolete poky repo references
      kernel-dev/common.rst: remove obsolete poky repo references
      migration-guides/migration-1.4.rst: remove obsolete poky repo references
      overview-manual/concepts.rst: remove obsolete poky repo references
      overview-manual/development-environment.rst: remove obsolete poky repo references
      overview-manual/yp-intro.rst: remove obsolete poky repo references
      ref-manual/classes.rst: remove obsolete poky repo references
      ref-manual/images.rst: remove obsolete poky repo references
      ref-manual/structure.rst: remove obsolete poky repo references
      ref-manual/tasks.rst: remove obsolete poky repo references
      ref-manual/variables.rst: remove obsolete poky repo references
      sdk-manual/appendix-obtain.rst: remove obsolete poky repo references
      sdk-manual/intro.rst: remove obsolete poky repo references
      test-manual/runtime-testing.rst: remove obsolete poky repo references
      README: remove obsolete poky repo references
      README: replace obsolete substitution variables
      contributor-guide/identify-component.rst: remove obsolete poky repo references
      dev-manual/build-quality.rst: remove obsolete poky repo references
      dev-manual/custom-distribution.rst: remove obsolete poky repo references
      dev-manual/custom-template-configuration-directory.rst: remove obsolete poky repo references
      dev-manual/init-manager.rst: remove obsolete poky repo references
      dev-manual/licenses.rst: remove obsolete poky repo references
      dev-manual/licenses.rst: instruct to use git-archive instead of removing .git
      dev-manual/packages.rst: remove obsolete poky repo references
      dev-manual/python-development-shell.rst: remove obsolete poky repo references
      dev-manual/qemu.rst: remove obsolete poky repo references
      dev-manual/upgrading-recipes.rst: remove obsolete poky repo references
      dev-manual/vulnerabilities.rst: remove obsolete poky repo references
      ref-manual/devtool-reference.rst: remove obsolete poky repo references
      ref-manual/faq.rst: remove obsolete poky repo references
      ref-manual/features.rst: remove obsolete poky repo references
      ref-manual/release-process.rst: remove obsolete poky repo references
      ref-manual/release-process.rst: remove repeated "in the"
      ref-manual/system-requirements.rst: remove obsolete poky repo references
      ref-manual/system-requirements.rst: fix wrong path to install-buildtools
      ref-manual/yocto-project-supported-features.rst: remove obsolete poky repo reference
      test-manual/reproducible-builds.rst: remove obsolete poky repo references
      test-manual/understand-autobuilder.rst: remove obsolete poky repo references
      what-i-wish-id-known.rst: remove obsolete poky repo references

 documentation/README                               |  43 +--
 documentation/brief-yoctoprojectqs/index.rst       |   2 +-
 documentation/bsp-guide/bsp.rst                    | 165 ++++-------
 .../contributor-guide/identify-component.rst       |   9 -
 documentation/contributor-guide/submit-changes.rst |  57 +---
 documentation/dev-manual/build-quality.rst         |   2 +-
 documentation/dev-manual/building.rst              |  40 +--
 documentation/dev-manual/custom-distribution.rst   |   8 +-
 .../custom-template-configuration-directory.rst    |   8 +-
 documentation/dev-manual/debugging.rst             |  16 +-
 documentation/dev-manual/error-reporting-tool.rst  |   3 +-
 documentation/dev-manual/external-toolchain.rst    |   2 +-
 documentation/dev-manual/init-manager.rst          |   6 +-
 documentation/dev-manual/layers.rst                | 308 ++++++++------------
 documentation/dev-manual/libraries.rst             |   8 +-
 documentation/dev-manual/licenses.rst              |  32 +-
 documentation/dev-manual/new-recipe.rst            |  25 +-
 documentation/dev-manual/packages.rst              |  11 +-
 documentation/dev-manual/poky-manual-setup.rst     |  29 +-
 .../dev-manual/python-development-shell.rst        |   2 +-
 documentation/dev-manual/qemu.rst                  |  11 +-
 documentation/dev-manual/start.rst                 | 324 +++------------------
 documentation/dev-manual/temporary-source-code.rst |   4 +-
 documentation/dev-manual/upgrading-recipes.rst     |  22 +-
 documentation/dev-manual/wayland.rst               |   2 +-
 documentation/dev-manual/wic.rst                   |  20 +-
 documentation/kernel-dev/advanced.rst              |  12 +-
 documentation/kernel-dev/common.rst                | 154 ++++------
 documentation/migration-guides/migration-1.4.rst   |   2 +-
 documentation/overview-manual/concepts.rst         |  76 ++---
 .../overview-manual/development-environment.rst    | 104 +++----
 .../figures/poky-reference-distribution.png        | Bin 23784 -> 0 bytes
 documentation/overview-manual/yp-intro.rst         | 155 ++--------
 documentation/ref-manual/classes.rst               |  34 ++-
 documentation/ref-manual/devtool-reference.rst     |  10 +-
 documentation/ref-manual/faq.rst                   |  43 ++-
 documentation/ref-manual/features.rst              |   2 +-
 documentation/ref-manual/fragments.rst             |   2 +
 documentation/ref-manual/images.rst                |   5 +-
 documentation/ref-manual/release-process.rst       |   8 +-
 documentation/ref-manual/structure.rst             | 174 ++++++-----
 documentation/ref-manual/system-requirements.rst   |  16 +-
 documentation/ref-manual/tasks.rst                 |  10 +-
 documentation/ref-manual/terms.rst                 |   2 +-
 documentation/ref-manual/variables.rst             | 149 +++++-----
 .../yocto-project-supported-features.rst           |   2 +-
 documentation/sdk-manual/appendix-obtain.rst       |  29 +-
 documentation/sdk-manual/intro.rst                 |   8 +-
 documentation/security-manual/securing-images.rst  |   9 +-
 documentation/security-manual/vulnerabilities.rst  |  20 +-
 documentation/test-manual/reproducible-builds.rst  |   8 +-
 documentation/test-manual/runtime-testing.rst      |   4 +-
 .../test-manual/understand-autobuilder.rst         |   6 +-
 .../transitioning-to-a-custom-environment.rst      |  21 +-
 documentation/what-i-wish-id-known.rst             |   5 +-
 55 files changed, 807 insertions(+), 1422 deletions(-)
---
base-commit: f43bb42123928181d76f81c0343ece777ac143d0
change-id: 20251224-remove-poky-references-316294b3557f
prerequisite-change-id: 20251224-terms-refresh-cdcd529ee508:v3
prerequisite-patch-id: 28a8d58b852a13391a97f6488bc59721f5efda86
prerequisite-patch-id: 39e885d60801727fff2c835f0c1904287a8223ad
prerequisite-patch-id: 60b57a0baefe0536612ed8c9dff680234c52eed6
prerequisite-patch-id: ef2fccb1181fd736f5713197040c52667c4b469e
prerequisite-patch-id: d641f824c2d4e7ff9506f9007102ebf3b112564f

[PATCH v2 01/56] transitioning-to-a-custom-environment.rst: remove obsolete poky repo references

[Antonin Godard]

- Use :term: for Poky.
- Mention use of fragments instead of local.conf.
- Remove Yocto < 2.4 reference.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 .../transitioning-to-a-custom-environment.rst          | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/documentation/transitioning-to-a-custom-environment.rst b/documentation/transitioning-to-a-custom-environment.rst
index a5f55c567..e292399f4 100644
--- a/documentation/transitioning-to-a-custom-environment.rst
+++ b/documentation/transitioning-to-a-custom-environment.rst
@@ -39,7 +39,7 @@ Transitioning to a custom environment for systems development
    that you've downloaded. Be aware that some BSPs may not be immediately
    supported on the very latest release, but they will be eventually.
 
-   You might want to start with the build specification that Poky provides
+   You might want to start with the build specification that :term:`Poky` provides
    (which is reference embedded distribution) and then add your newly chosen
    layers to that. Here is the information :ref:`about adding layers
    <dev-manual/layers:Understanding and Creating Layers>`.
@@ -48,16 +48,14 @@ Transitioning to a custom environment for systems development
    configuration**.
    For instance, you've chosen a machine type and added in the corresponding BSP
    layer. You'll then need to change the value of the :term:`MACHINE` variable in your
-   configuration file (build/local.conf) to point to that same machine
-   type. There could be other layer-specific settings you need to change as
-   well. Each layer has a ``README`` document that you can look at for this type of
-   usage information.
+   configuration (using the :ref:`ref-fragments-builtin-core-machine`
+   fragment) to point to that same machine type. There could be other
+   layer-specific settings you need to change as well. Each layer has a
+   ``README`` document that you can look at for this type of usage information.
 
 #. **Add a new layer for any custom recipes and metadata you create**.
-   Use the ``bitbake-layers create-layer`` tool for Yocto Project 2.4+
-   releases. If you are using a Yocto Project release earlier than 2.4, use the
-   ``yocto-layer create`` tool. The ``bitbake-layers`` tool also provides a number
-   of other useful layer-related commands. See
+   Use the ``bitbake-layers create-layer`` command. The ``bitbake-layers`` tool
+   also provides a number of other useful layer-related commands. See
    :ref:`dev-manual/layers:creating a general layer using the
    \`\`bitbake-layers\`\` script` section.
 
@@ -99,7 +97,7 @@ Transitioning to a custom environment for systems development
 
    Distribution settings define the packaging back-end (e.g. rpm or other) as
    well as the package feed and possibly the update solution. You would create
-   your own distribution in a new layer inheriting from Poky but overriding what
+   your own distribution in a new layer inheriting from :term:`Poky` but overriding what
    needs to change for your distribution. If you find yourself adding a lot of
    configuration to your local.conf file aside from paths and other typical
    local settings, it's time to :ref:`consider creating your own distribution

-- 
2.52.0

[PATCH v2 02/56] dev-manual/poky-manual-setup.rst: remove obsolete poky repo references

[Antonin Godard]

The commit "dev-manual/start.rst: simplify the document after poky
obsolescence" removed some of the information related to source archives
published on downloads.yoctoproject.org. Mention it in this document as
it makes sense to use those when manually setting up a Poky build.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/poky-manual-setup.rst | 29 +++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/documentation/dev-manual/poky-manual-setup.rst b/documentation/dev-manual/poky-manual-setup.rst
index 4bc9b97b6..2b1c3f63d 100644
--- a/documentation/dev-manual/poky-manual-setup.rst
+++ b/documentation/dev-manual/poky-manual-setup.rst
@@ -13,8 +13,17 @@ document guides through this setup step-by-step.
    :doc:`/brief-yoctoprojectqs/index`, which shows how to setup :term:`Poky`
    with ``bitbake-setup``.
 
+Obtaining The Source Repositories
+=================================
+
+You can obtain the source repositories required to build the Poky reference
+distro in two ways described below: :ref:`cloning the repositories with Git
+<dev-manual/poky-manual-setup:Use Git to Clone The Layers>`, or
+:ref:`downloading the released archives <dev-manual/poky-manual-setup:Using the
+Source Archives>`.
+
 Use Git to Clone The Layers
-===========================
+---------------------------
 
 Go to the :yocto_home:`Releases </development/releases/>` page, and choose a release
 (such as ``&DISTRO_REL_LATEST_TAG;``), corresponding to either the latest stable
@@ -42,6 +51,24 @@ following commands:
    $ git clone -b &DISTRO_REL_LATEST_TAG; https://git.openembedded.org/openembedded-core ./layers/openembedded-core
    $ git clone -b &DISTRO_REL_LATEST_TAG; https://git.yoctoproject.org/meta-yocto ./layers/meta-yocto
 
+
+Using the Source Archives
+-------------------------
+
+The Yocto Project also provides source archives of its releases, which
+are available at :yocto_dl:`/releases/yocto/`. Then, choose the subdirectory
+containing the release you wish to use, for example
+:yocto_dl:`&DISTRO_REL_LATEST_TAG; </releases/yocto/&DISTRO_REL_LATEST_TAG;/>`.
+
+You will find there source archives of :term:`OpenEmbedded-Core (OE-Core)`,
+:term:`BitBake`, and :yocto_git:`meta-yocto </meta-yocto>`.
+
+.. note::
+
+   The recommended method for accessing Yocto Project components is to :ref:`use
+   Git to clone the upstream repository <dev-manual/poky-manual-setup:Use Git to
+   Clone The Layers>` and work from within the locally cloned repositories.
+
 Building Your Image
 ===================
 

-- 
2.52.0

[PATCH v2 03/56] dev-manual/start.rst: remove obsolete poky repo references

[Antonin Godard]

The Poky repository has stopped being updated in favor of bitbake-setup
or manual clones of the required repositories. Simplify the document by
making references to these guides as well as removing sections that
are covered in the references documents.

Keep a "Initializing the Build Environment" as this task is common and
referenced in different places in the documentation.

Remove the tarball instructions as those will be moved in the
poky-manual-setup document.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/bsp-guide/bsp.rst                    |   7 +-
 documentation/dev-manual/start.rst                 | 324 +++------------------
 documentation/kernel-dev/common.rst                |  36 +--
 .../overview-manual/development-environment.rst    |  21 +-
 documentation/ref-manual/structure.rst             |   5 -
 documentation/sdk-manual/appendix-obtain.rst       |  27 +-
 6 files changed, 49 insertions(+), 371 deletions(-)

diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index a6444d9af..056f69249 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -72,7 +72,7 @@ For information on typical BSP development workflow, see the
 section. For more
 information on how to set up a local copy of source files from a Git
 repository, see the
-:ref:`dev-manual/start:locating yocto project source files`
+:doc:`/dev-manual/poky-manual-setup`
 section in the Yocto Project Development Tasks Manual.
 
 The BSP layer's base directory (``meta-bsp_root_name``) is the root
@@ -204,10 +204,7 @@ section.
       .. note::
 
          To see the available branch names in a cloned repository, use the ``git
-         branch -a`` command. See the
-         ":ref:`dev-manual/start:checking out by branch in poky`"
-         section in the Yocto Project Development Tasks Manual for more
-         information.
+         branch -a`` command.
 
 #. *Optionally Set Up an Alternative BSP Layer:* If your hardware can be
    more closely leveraged to an existing BSP not within the
diff --git a/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst
index b21cd4f0f..51ec05347 100644
--- a/documentation/dev-manual/start.rst
+++ b/documentation/dev-manual/start.rst
@@ -76,7 +76,7 @@ particular working environment and set of practices.
     :term:`Metadata` (i.e. recipes,
     configuration files, classes, and so forth) and any software you are
     developing under the control of an SCM system that is compatible
-    with the OpenEmbedded build system is advisable. Of all of the SCMs
+    with the :term:`OpenEmbedded build system` is advisable. Of all of the SCMs
     supported by BitBake, the Yocto Project team strongly recommends using
     :ref:`overview-manual/development-environment:git`.
     Git is a distributed system
@@ -218,7 +218,7 @@ particular working environment and set of practices.
        repositories. See the ":ref:`overview-manual/development-environment:yocto project source repositories`"
        section in the Yocto Project Overview and Concepts Manual for
        information on these repositories. See the
-       ":ref:`dev-manual/start:locating yocto project source files`"
+       ":doc:`/dev-manual/poky-manual-setup`"
        section for information on how to set up local Git repositories
        for related upstream Yocto Project Git repositories.
 
@@ -338,7 +338,7 @@ Project Build Host:
 Once you have completed the previous steps, you are ready to continue
 using a given development path on your native Linux machine. If you are
 going to use BitBake, see the
-":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
+":ref:`dev-manual/start:preparing the poky reference distro`"
 section. If you are going
 to use the Extensible SDK, see the ":doc:`/sdk-manual/extensible`" Chapter in the Yocto
 Project Application Development and the Extensible Software Development
@@ -433,7 +433,7 @@ as your Yocto Project build host:
 Once you have a container set up, everything is in place to develop just
 as if you were running on a native Linux machine. If you are going to
 use the Poky container, see the
-":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
+":ref:`dev-manual/start:preparing the Poky reference distro`"
 section. If you are going to use the Extensible SDK container, see the
 ":doc:`/sdk-manual/extensible`" Chapter in the Yocto
 Project Application Development and the Extensible Software Development
@@ -576,302 +576,60 @@ the `Yocto Project BitBake
 <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__
 extension accordingly.
 
-Locating Yocto Project Source Files
-===================================
+Preparing the Poky Reference Distro
+-----------------------------------
 
-This section shows you how to locate, fetch, unpack, patch and configure the source
-files you'll need to work with the Yocto Project.
+Now that the :term:`Build Host` has been prepared to build images, the next step
+can be to build the :term:`Poky` reference distro. There are two ways of setting
+up the :term:`Poky` reference distro:
 
-.. note::
-
-   -  For concepts and introductory information about Git as it is used
-      in the Yocto Project, see the ":ref:`overview-manual/development-environment:git`"
-      section in the Yocto Project Overview and Concepts Manual.
-
-   -  For concepts on Yocto Project source repositories, see the
-      ":ref:`overview-manual/development-environment:yocto project source repositories`"
-      section in the Yocto Project Overview and Concepts Manual."
-
-Accessing Source Repositories
------------------------------
-
-Working from a copy of the upstream :ref:`dev-manual/start:accessing source repositories` is the
-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:`/poky`.
-
-Use the following procedure to locate the latest upstream copy of the
-``poky`` Git repository:
-
-#. *Access Repositories:* Open a browser and go to
-   :yocto_git:`/` to access the GUI-based interface into the
-   Yocto Project source repositories.
+-  Using the ``bitbake-setup`` command-line utility from :term:`BitBake`.
+   Follow:
 
-#. *Select the Repository:* Click on the repository in which you are
-   interested (e.g. ``poky``).
+   :doc:`Setting Up The Environment With bitbake-setup <bitbake:bitbake-user-manual/bitbake-user-manual-environment-setup>`
 
-#. *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:`/poky`).
+-  Manually cloning the required repositories. Follow:
 
-   .. note::
+   :doc:`/dev-manual/poky-manual-setup`
 
-      For information on cloning a repository, see the
-      ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" section.
+.. note::
 
-Accessing Source Archives
--------------------------
+   The :term:`Poky` distro is a reference distro. It can be used to try the
+   Yocto Project but should not be used in a production environment. Instead, it
+   is recommended to create your own distro, see the
+   :doc:`/dev-manual/custom-distribution` section of the Yocto Project
+   Development Tasks Manual.
 
-The Yocto Project also provides source archives of its releases, which
-are available on :yocto_dl:`/releases/yocto/`. Then, choose the subdirectory
-containing the release you wish to use, for example
-:yocto_dl:`&DISTRO_REL_LATEST_TAG; </releases/yocto/&DISTRO_REL_LATEST_TAG;/>`.
+Initializing the Build Environment
+----------------------------------
 
-You will find there source archives of individual components (if you wish
-to use them individually), and of the corresponding Poky release bundling
-a selection of these components.
+Initializing the build environment is a common task, as it needs to be done for
+each new instance of the shell where the :term:`Poky` reference was set up:
 
-.. note::
+-  If ``bitbake-setup`` was used to setup the :term:`Poky` reference distro, you
+   need to source the ``init-build-env`` file of the :term:`bitbake:Setup`
+   directory that was created after the :ref:`bitbake:ref-bbsetup-command-init`
+   command execution:
 
-   The recommended method for accessing Yocto Project components is to
-   use Git to clone the upstream repository and work from within that
-   locally cloned repository.
-
-Using the Downloads Page
-------------------------
-
-The :yocto_home:`Yocto Project Website <>` uses a "RELEASES" page
-from which you can locate and download tarballs of any Yocto Project
-release. Rather than Git repositories, these files represent snapshot
-tarballs similar to the tarballs located in the Index of Releases
-described in the ":ref:`dev-manual/start:accessing source archives`" section.
-
-#. *Go to the Yocto Project Website:* Open The
-   :yocto_home:`Yocto Project Website <>` in your browser.
-
-#. *Get to the Downloads Area:* Select the "RELEASES" item from the
-   pull-down "DEVELOPMENT" tab menu near the top of the page.
-
-#. *Select a Yocto Project Release:* On the top of the "RELEASES" page, currently
-   supported releases are displayed; further down, past supported Yocto Project
-   releases are visible. The "Download" links in the rows of the table there
-   will lead to the download tarballs for the release.
-
-   .. note::
-
-      For a "map" of Yocto Project releases to version numbers, see the
-      :yocto_home:`Releases </development/releases/>` page.
-
-   You can use the "RELEASE ARCHIVE" link to reveal a menu of all Yocto
-   Project releases.
-
-#. *Download Tools or Board Support Packages (BSPs):* Next to the tarballs you
-   will find download tools or BSPs as well. Just select a Yocto Project
-   release and look for what you need.
-
-Cloning and Checking Out Branches
-=================================
-
-To use the Yocto Project for development, you need a release locally
-installed on your development system. This locally installed set of
-files is referred to as the :term:`Source Directory`
-in the Yocto Project documentation.
-
-The preferred method of creating your Source Directory is by using
-:ref:`overview-manual/development-environment:git` to clone a local copy of the upstream
-``poky`` repository. Working from a cloned copy of the upstream
-repository allows you to contribute back into the Yocto Project or to
-simply work with the latest software on a development branch. Because
-Git maintains and creates an upstream repository with a complete history
-of changes and you are working with a local clone of that repository,
-you have access to all the Yocto Project development branches and tag
-names used in the upstream repository.
-
-Cloning the ``poky`` Repository
--------------------------------
-
-Follow these steps to create a local version of the upstream
-:term:`Poky` Git repository.
-
-#. *Set Your Directory:* Change your working directory to where you want
-   to create your local copy of ``poky``.
-
-#. *Clone the Repository:* The following example command clones the
-   ``poky`` repository and uses the default name "poky" for your local
-   repository::
-
-      $ git clone git://git.yoctoproject.org/poky
-      Cloning into 'poky'...
-      remote: Counting objects: 432160, done.
-      remote: Compressing objects: 100% (102056/102056), done.
-      remote: Total 432160 (delta 323116), reused 432037 (delta 323000)
-      Receiving objects: 100% (432160/432160), 153.81 MiB | 8.54 MiB/s, done.
-      Resolving deltas: 100% (323116/323116), done.
-      Checking connectivity... done.
-
-   Unless you
-   specify a specific development branch or tag name, Git clones the
-   "master" branch, which results in a snapshot of the latest
-   development changes for "master". For information on how to check out
-   a specific development branch or on how to check out a local branch
-   based on a tag name, see the
-   ":ref:`dev-manual/start:checking out by branch in poky`" and
-   ":ref:`dev-manual/start:checking out by tag in poky`" sections, respectively.
-
-   Once the local repository is created, you can change to that
-   directory and check its status. The ``master`` branch is checked out
-   by default::
-
-      $ cd poky
-      $ git status
-      On branch master
-      Your branch is up-to-date with 'origin/master'.
-      nothing to commit, working directory clean
-      $ git branch
-      * master
-
-   Your local repository of poky is initially identical to the
-   upstream poky repository from which it was cloned. As you
-   work with the local branch, you can periodically use the
-   ``git pull`` command to be sure you stay up-to-date
-   with the upstream poky branch.
-
-Checking Out by Branch in Poky
-------------------------------
+   .. code-block:: console
 
-When you clone the upstream poky repository, you have access to all its
-development branches. Each development branch in a repository is unique
-as it forks off the "master" branch. To see and use the files of a
-particular development branch locally, you need to know the branch name
-and then specifically check out that development branch.
+      $ source <setup-dir>/build/init-build-env
 
-.. note::
 
-   Checking out an active development branch by branch name gives you a
-   snapshot of that particular branch at the time you check it out.
-   Further development on top of the branch that occurs after check it
-   out can occur.
-
-#. *Switch to the Poky Directory:* If you have a local poky Git
-   repository, switch to that directory. If you do not have the local
-   copy of poky, see the
-   ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
-   section.
-
-#. *Determine Existing Branch Names:*
-   ::
-
-      $ git branch -a
-      * master
-      remotes/origin/1.1_M1
-      remotes/origin/1.1_M2
-      remotes/origin/1.1_M3
-      remotes/origin/1.1_M4
-      remotes/origin/1.2_M1
-      remotes/origin/1.2_M2
-      remotes/origin/1.2_M3
-      . . .
-      remotes/origin/thud
-      remotes/origin/thud-next
-      remotes/origin/warrior
-      remotes/origin/warrior-next
-      remotes/origin/zeus
-      remotes/origin/zeus-next
-      ... and so on ...
-
-#. *Check out the Branch:* Check out the development branch in which you
-   want to work. For example, to access the files for the Yocto Project
-   &DISTRO; Release (&DISTRO_NAME;), use the following command::
-
-      $ git checkout -b &DISTRO_NAME_NO_CAP; origin/&DISTRO_NAME_NO_CAP;
-      Branch &DISTRO_NAME_NO_CAP; set up to track remote branch &DISTRO_NAME_NO_CAP; from origin.
-      Switched to a new branch '&DISTRO_NAME_NO_CAP;'
-
-   The previous command checks out the "&DISTRO_NAME_NO_CAP;" development
-   branch and reports that the branch is tracking the upstream
-   "origin/&DISTRO_NAME_NO_CAP;" branch.
-
-   The following command displays the branches that are now part of your
-   local poky repository. The asterisk character indicates the branch
-   that is currently checked out for work::
-
-      $ git branch
-        master
-        * &DISTRO_NAME_NO_CAP;
-
-Checking Out by Tag in Poky
----------------------------
-
-Similar to branches, the upstream repository uses tags to mark specific
-commits associated with significant points in a development branch (i.e.
-a release point or stage of a release). You might want to set up a local
-branch based on one of those points in the repository. The process is
-similar to checking out by branch name except you use tag names.
+-  If the :term:`Poky` distro was setup using manual clones of the layers, you
+   need to source the ``oe-init-build-env`` script present in the
+   :term:`OpenEmbedded-Core (OE-Core)` layer:
 
-.. note::
+   .. code-block:: console
 
-   Checking out a branch based on a tag gives you a stable set of files
-   not affected by development on the branch above the tag.
-
-#. *Switch to the Poky Directory:* If you have a local poky Git
-   repository, switch to that directory. If you do not have the local
-   copy of poky, see the
-   ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
-   section.
-
-#. *Fetch the Tag Names:* To checkout the branch based on a tag name,
-   you need to fetch the upstream tags into your local repository::
-
-      $ git fetch --tags
-      $
-
-#. *List the Tag Names:* You can list the tag names now::
-
-      $ git tag
-      1.1_M1.final
-      1.1_M1.rc1
-      1.1_M1.rc2
-      1.1_M2.final
-      1.1_M2.rc1
-         .
-         .
-         .
-      yocto-2.5
-      yocto-2.5.1
-      yocto-2.5.2
-      yocto-2.5.3
-      yocto-2.6
-      yocto-2.6.1
-      yocto-2.6.2
-      yocto-2.7
-      yocto_1.5_M5.rc8
-
-
-#. *Check out the Branch:*
-   ::
-
-      $ git checkout tags/yocto-&DISTRO; -b my_yocto_&DISTRO;
-      Switched to a new branch 'my_yocto_&DISTRO;'
-      $ git branch
-        master
-      * my_yocto_&DISTRO;
-
-   The previous command creates and
-   checks out a local branch named "my_yocto_&DISTRO;", which is based on
-   the commit in the upstream poky repository that has the same tag. In
-   this example, the files you have available locally as a result of the
-   ``checkout`` command are a snapshot of the "&DISTRO_NAME_NO_CAP;"
-   development branch at the point where Yocto Project &DISTRO; was
-   released.
+      $ source openembedded-core/oe-init-build-env
 
-Initializing the Build Environment
-==================================
+This will setup your current shell and change the current working directory to
+the :term:`Build Directory`.
 
-Before you can use Yocto you need to setup the build environment.
-From within the ``poky`` directory, source the :ref:`ref-manual/structure:``oe-init-build-env``` environment
-setup script to define Yocto Project's build environment on your build host::
+Where To Go From Here
+---------------------
 
-   $ source oe-init-build-env
+-  Configure your build: follow :ref:`overview-manual/concepts:User Configuration`.
 
-Note, that this step will have to be repeated every time you open a new shell.
+-  Learn how and what to build with :term:`BitBake`: follow :doc:`/dev-manual/building`.
diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst
index c0df39e39..1e098c158 100644
--- a/documentation/kernel-dev/common.rst
+++ b/documentation/kernel-dev/common.rst
@@ -22,21 +22,13 @@ Preparing the Build Host to Work on the Kernel
 Before you can do any kernel development, you need to be sure your build
 host is set up to use the Yocto Project. For information on how to get
 set up, see the ":doc:`/dev-manual/start`" section in
-the Yocto Project Development Tasks Manual. Part of preparing the system
-is creating a local Git repository of the
-:term:`Source Directory` (``poky``) on your system. Follow the steps in the
-":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
-section in the Yocto Project Development Tasks Manual to set up your
-Source Directory.
+the Yocto Project Development Tasks Manual.
 
 .. note::
 
    Be sure you check out the appropriate development branch or you
    create your local branch by checking out a specific tag to get the
-   desired version of Yocto Project. See the
-   ":ref:`dev-manual/start:checking out by branch in poky`" and
-   ":ref:`dev-manual/start:checking out by tag in poky`"
-   sections in the Yocto Project Development Tasks Manual for more information.
+   desired version of Yocto Project.
 
 Kernel development is best accomplished using
 :ref:`devtool <sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow>`
@@ -158,28 +150,8 @@ this procedure leaves you ready to make modifications to the kernel
 source as described in the ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
 section:
 
-#. *Initialize the BitBake Environment:* Before you can do anything
-   using BitBake, you need to initialize the BitBake build environment
-   by sourcing the build environment script (i.e.
-   :ref:`structure-core-script`).
-   Also, for this example, be sure that the local branch you have
-   checked out for ``poky`` is the Yocto Project &DISTRO_NAME; branch. If
-   you need to checkout out the &DISTRO_NAME; branch, see the
-   ":ref:`dev-manual/start:checking out by branch in poky`"
-   section in the Yocto Project Development Tasks Manual::
-
-      $ cd poky
-      $ git branch
-      master
-      * &DISTRO_NAME_NO_CAP;
-      $ source oe-init-build-env
-
-   .. note::
-
-      The previous commands assume the
-      :ref:`overview-manual/development-environment:yocto project source repositories`
-      (i.e. ``poky``) have been cloned using Git and the local repository is named
-      "poky".
+#. *Initialize the BitBake Environment:* Follow the steps in the
+   :doc:`/dev-manual/start` section of the Yocto Project Development Tasks Manual.
 
 #. *Prepare Your local.conf File:* By default, the :term:`MACHINE` variable is
    set to "qemux86-64", which is fine if you are building for the QEMU emulator
diff --git a/documentation/overview-manual/development-environment.rst b/documentation/overview-manual/development-environment.rst
index 066d78431..ab9bd084c 100644
--- a/documentation/overview-manual/development-environment.rst
+++ b/documentation/overview-manual/development-environment.rst
@@ -184,15 +184,6 @@ development:
    .. image:: figures/source-repos.png
       :width: 100%
 
-   For steps on how to view and access these upstream Git repositories,
-   see the ":ref:`dev-manual/start:accessing source repositories`"
-   Section in the Yocto Project Development Tasks Manual.
-
--  :yocto_dl:`Yocto release archives: </releases/yocto>` This is where you can
-   download tarballs corresponding to each Yocto Project release. Downloading
-   and extracting these files does not produce a local copy of a Git repository
-   but rather a snapshot corresponding to a particular release.
-
 -  :yocto_home:`DOWNLOADS page </software-overview/downloads/>`:
    The :yocto_home:`Yocto Project website <>` includes a "DOWNLOADS" page accessible
    through the "SOFTWARE" menu that allows you to download any Yocto
@@ -203,10 +194,6 @@ development:
    .. image:: figures/yp-download.png
       :width: 100%
 
-   For steps on how to use the "DOWNLOADS" page, see the
-   ":ref:`dev-manual/start:using the downloads page`"
-   section in the Yocto Project Development Tasks Manual.
-
 Git Workflows and the Yocto Project
 ===================================
 
@@ -372,10 +359,6 @@ commands.
       Ubuntu, use the Ubuntu Software feature). For the Git download
       page, see https://git-scm.com/download.
 
-   -  For information beyond the introductory nature in this section,
-      see the ":ref:`dev-manual/start:locating yocto project source files`"
-      section in the Yocto Project Development Tasks Manual.
-
 Repositories, Tags, and Branches
 --------------------------------
 
@@ -403,9 +386,7 @@ You can create a local copy of any repository by "cloning" it with the
 ``git clone`` command. When you clone a Git repository, you end up with
 an identical copy of the repository on your development system. Once you
 have a local copy of a repository, you can take steps to develop
-locally. For examples on how to clone Git repositories, see the
-":ref:`dev-manual/start:locating yocto project source files`"
-section in the Yocto Project Development Tasks Manual.
+locally.
 
 It is important to understand that Git tracks content change and not
 files. Git uses "branches" to organize different development efforts.
diff --git a/documentation/ref-manual/structure.rst b/documentation/ref-manual/structure.rst
index c0eae9b7b..d567cade0 100644
--- a/documentation/ref-manual/structure.rst
+++ b/documentation/ref-manual/structure.rst
@@ -10,11 +10,6 @@ contents is key to using the Yocto Project effectively. This chapter
 describes the Source Directory and gives information about those files
 and directories.
 
-For information on how to establish a local Source Directory on your
-development system, see the
-":ref:`dev-manual/start:locating yocto project source files`"
-section in the Yocto Project Development Tasks Manual.
-
 .. note::
 
    The OpenEmbedded build system does not support file or directory
diff --git a/documentation/sdk-manual/appendix-obtain.rst b/documentation/sdk-manual/appendix-obtain.rst
index 83eefecd6..fb2326fac 100644
--- a/documentation/sdk-manual/appendix-obtain.rst
+++ b/documentation/sdk-manual/appendix-obtain.rst
@@ -94,36 +94,11 @@ As an alternative to locating and downloading an SDK installer, you can
 build the SDK installer. Follow these steps:
 
 #. *Set Up the Build Environment:* Be sure you are set up to use BitBake
-   in a shell. See the ":ref:`dev-manual/start:preparing the build host`" section
+   in a shell. See the ":doc:`/dev-manual/start`" section
    in the Yocto Project Development Tasks Manual for information on how
    to get a build host ready that is either a native Linux machine or a
    machine that uses CROPS.
 
-#. *Clone the ``poky`` Repository:* You need to have a local copy of the
-   Yocto Project :term:`Source Directory`
-   (i.e. a local
-   ``poky`` repository). See the ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" and
-   possibly the ":ref:`dev-manual/start:checking out by branch in poky`" and
-   ":ref:`dev-manual/start:checking out by tag in poky`" sections
-   all in the Yocto Project Development Tasks Manual for information on
-   how to clone the ``poky`` repository and check out the appropriate
-   branch for your work.
-
-#. *Initialize the Build Environment:* While in the root directory of
-   the Source Directory (i.e. ``poky``), run the
-   :ref:`structure-core-script` environment
-   setup script to define the OpenEmbedded build environment on your
-   build host:
-
-   .. code-block:: console
-
-      $ source oe-init-build-env
-
-   Among other things, the script creates the :term:`Build Directory`, which
-   is ``build`` in this case and is located in the Source Directory. After
-   the script runs, your current working directory is set to the ``build``
-   directory.
-
 #. *Make Sure You Are Building an Installer for the Correct Machine:*
    Check to be sure that your :term:`MACHINE` variable in the ``local.conf``
    file in your :term:`Build Directory` matches the architecture

-- 
2.52.0

[PATCH v2 04/56] bsp-guide/bsp.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core
in most cases, and refer to bitbake-setup or the manual setup in the
intro.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/bsp-guide/bsp.rst | 154 +++++++++++++---------------------------
 1 file changed, 50 insertions(+), 104 deletions(-)

diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index 056f69249..49527f45d 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -62,8 +62,8 @@ Here is an example that clones the Raspberry Pi BSP layer::
 
    $ git clone git://git.yoctoproject.org/meta-raspberrypi
 
-In addition to BSP layers, the ``meta-yocto-bsp`` layer is part of the
-shipped ``poky`` repository. The ``meta-yocto-bsp`` layer maintains
+In addition to BSP layers, the ``meta-yocto-bsp`` layer is part of
+:yocto_git:`meta-yocto </meta-yocto>`. The ``meta-yocto-bsp`` layer maintains
 several "reference" BSPs including the ARM-based Beaglebone and generic
 versions of both 32-bit and 64-bit IA machines.
 
@@ -150,24 +150,23 @@ section.
    to get a build host ready that is either a native Linux machine or a machine
    that uses CROPS.
 
-#. *Clone the poky Repository:* You need to have a local copy of the
-   Yocto Project :term:`Source Directory` (i.e. a local
-   ``poky`` repository). See the
-   ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" and
-   possibly the
-   ":ref:`dev-manual/start:checking out by branch in poky`" or
-   ":ref:`dev-manual/start:checking out by tag in poky`"
-   sections
-   all in the Yocto Project Development Tasks Manual for information on
-   how to clone the ``poky`` repository and check out the appropriate
-   branch for your work.
+#. *Prepare the Source Repositories*:
+
+   There are two ways of setting up the :term:`Poky` reference distro:
+
+   -  Using the ``bitbake-setup`` command-line utility from :term:`BitBake`.
+      Follow:
+
+      :doc:`Setting Up The Environment With bitbake-setup <bitbake:bitbake-user-manual/bitbake-user-manual-environment-setup>`
+
+   -  Manually cloning the required repositories. Follow:
+
+      :doc:`/dev-manual/poky-manual-setup`
 
 #. *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
-   :yocto_dl:`index of machines </releases/yocto/&DISTRO_REL_LATEST_TAG;/machines>`
-   for the release.
+   to contain several BSPs. The :oe_layerindex:`Layer Index <>` can help finding
+   BSP layers to use.
 
 #. *Optionally Clone the meta-intel BSP Layer:* If your hardware is
    based on current Intel CPUs and devices, you can leverage this BSP
@@ -175,10 +174,7 @@ section.
    :yocto_git:`README </meta-intel/tree/README.md>` file.
 
    #. *Navigate to Your Source Directory:* Typically, you set up the
-      ``meta-intel`` Git repository inside the :term:`Source Directory` (e.g.
-      ``poky``). ::
-
-         $ cd /home/you/poky
+      ``meta-intel`` Git repository next to the other layers in your build.
 
    #. *Clone the Layer:* ::
 
@@ -224,18 +220,21 @@ section.
       Resolving deltas: 100% (2447/2447), done.
       Checking connectivity... done.
 
-#. *Initialize the Build Environment:* While in the root directory of
-   the Source Directory (i.e. ``poky``), run the
-   :ref:`ref-manual/structure:``oe-init-build-env``` environment
-   setup script to define the OpenEmbedded build environment on your
-   build host. ::
+#. *Initialize the Build Environment:* While in the :term:`Source Directory`,
+run the :ref:`ref-manual/structure:``oe-init-build-env``` environment setup
+script located in :term:`OpenEmbedded-Core (OE-Core)` to define the OpenEmbedded
+build environment on your build host. ::
 
-      $ source oe-init-build-env
+      $ source layers/openembedded-core/oe-init-build-env
 
    Among other things, the script creates the :term:`Build Directory`, which is
-   ``build`` in this case and is located in the :term:`Source Directory`.  After
-   the script runs, your current working directory is set to the ``build``
-   directory.
+   :term:`Build Directory`. After the script runs, your current working directory is set to
+   the :term:`Build Directory` directory.
+
+   .. note::
+
+      Alternatively, you can source the ``init-build-env`` file provided by
+      :doc:`bitbake-setup <bitbake:bitbake-user-manual/bitbake-user-manual-environment-setup>` 
 
 Example Filesystem Layout
 =========================
@@ -597,10 +596,10 @@ optimization flags, which are carefully chosen to give best performance
 on a given processor.
 
 Tuning files are found in the ``meta/conf/machine/include`` directory
-within the :term:`Source Directory`.
+within :term:`OpenEmbedded-Core (OE-Core)`.
 For example, many ``tune-*`` files (e.g. ``tune-arm1136jf-s.inc``,
 ``tune-1586-nlp.inc``, and so forth) reside in the
-``poky/meta/conf/machine/include`` directory.
+``meta/conf/machine/include`` directory.
 
 To use an include file, you simply include them in the machine
 configuration file. For example, the Raspberry Pi BSP
@@ -636,7 +635,7 @@ directory. Here is the ``machconfig`` file for the Raspberry Pi BSP::
    according to the formfactor configuration file that is installed by
    the main formfactor recipe
    ``meta/recipes-bsp/formfactor/formfactor_0.0.bb``, which is found in
-   the :term:`Source Directory`.
+   :term:`OpenEmbedded-Core (OE-Core)`.
 
 Display Support Files
 ---------------------
@@ -664,7 +663,7 @@ types of files although, in practice, it is likely that you would have
 one or the other.
 
 For your BSP, you typically want to use an existing Yocto Project kernel
-recipe found in the :term:`Source Directory`
+recipe found in :term:`OpenEmbedded-Core (OE-Core)`
 at
 ``meta/recipes-kernel/linux``. You can append machine-specific changes
 to the kernel recipe by using a similarly named append file, which is
@@ -766,20 +765,23 @@ workflow.
 
    .. note::
 
-      -  There are three hardware reference BSPs in the Yocto
-         Project release, located in the ``poky/meta-yocto-bsp``
+      -  There are four hardware reference BSPs in the Yocto
+         Project release, located in the :yocto_git:`meta-yocto-bsp
+         </meta-yocto/tree/meta-yocto-bsp>`
          BSP layer:
 
          -  Texas Instruments Beaglebone (``beaglebone-yocto``)
 
          -  Two generic IA platforms (``genericx86`` and ``genericx86-64``)
 
+         -  A generic ARM 64 platform (``genericarm64``)
+
    When you set up a layer for a new BSP, you should follow a standard
    layout. This layout is described in the ":ref:`bsp-guide/bsp:example filesystem layout`"
    section. In the standard layout, notice
    the suggested structure for recipes and configuration information.
    You can see the standard layout for a BSP by examining any supported
-   BSP found in the ``meta-intel`` layer inside the Source Directory.
+   BSP found in the :yocto_git:`meta-intel </meta-intel>` layer.
 
 #. *Make Configuration Changes to Your New BSP Layer:* The standard BSP
    layer structure organizes the files you need to edit in ``conf`` and
@@ -861,9 +863,8 @@ The requirements for a released BSP that conform to the Yocto Project are:
 
 -  *File System Layout:* When possible, use the same directory names in
    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
-   :oe_git:`/openembedded-core/tree/meta`.
+   in :oe_git:`meta </openembedded-core/tree/meta>` directory of
+   :term:`OpenEmbedded-Core (OE-Core)`.
 
    You should place recipes (``*.bb`` files) and recipe modifications
    (``*.bbappend`` files) into ``recipes-*`` subdirectories by
@@ -872,8 +873,8 @@ The requirements for a released BSP that conform to the Yocto Project are:
    up your own ``recipes-*`` subdirectory.
 
    Within any particular ``recipes-*`` category, the layout should match
-   what is found in the OpenEmbedded-Core Git repository
-   (``openembedded-core``) or the Source Directory (``poky``). In other
+   what is found in the :term:`OpenEmbedded-Core (OE-Core)` Git repository.
+   In other
    words, make sure you place related files in appropriately-related
    ``recipes-*`` subdirectories specific to the recipe's function, or
    within a subdirectory containing a set of closely-related recipes.
@@ -1169,7 +1170,7 @@ Use these steps to create a BSP layer:
 
 -  *Create a Machine Configuration File:* Create a
    ``conf/machine/bsp_root_name.conf`` file. See
-   :yocto_git:`meta-yocto-bsp/conf/machine </poky/tree/meta-yocto-bsp/conf/machine>`
+   :yocto_git:`meta-yocto-bsp/conf/machine </meta-yocto/tree/meta-yocto-bsp/conf/machine>`
    for sample ``bsp_root_name.conf`` files. There are other samples such as
    :yocto_git:`meta-ti </meta-ti/tree/meta-ti-bsp/conf/machine>`
    and
@@ -1187,7 +1188,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 </poky/tree/meta-yocto-bsp>`
+:yocto_git:`meta-yocto-bsp </meta-yocto/tree/meta-yocto-bsp>`
 layer.
 
 BSP Layer Configuration Example
@@ -1235,63 +1236,8 @@ There are one or more machine configuration files in the
 
 For example, the machine configuration file for the `BeagleBone and
 BeagleBone Black development boards <https://beagleboard.org/bone>`__ is
-located in :yocto_git:`poky/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
-</poky/tree/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf>`::
-
-   #@TYPE: Machine
-   #@NAME: Beaglebone-yocto machine
-   #@DESCRIPTION: Reference machine configuration for http://beagleboard.org/bone and http://beagleboard.org/black boards
-
-   PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
-
-   MACHINE_EXTRA_RRECOMMENDS = "kernel-modules"
-
-   EXTRA_IMAGEDEPENDS += "virtual/bootloader"
-
-   DEFAULTTUNE ?= "cortexa8hf-neon"
-   include conf/machine/include/arm/armv7a/tune-cortexa8.inc
-
-   IMAGE_FSTYPES += "tar.bz2 jffs2 wic wic.bmap"
-   EXTRA_IMAGECMD:jffs2 = "-lnp "
-   WKS_FILE ?= "beaglebone-yocto.wks"
-   MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-image kernel-devicetree"
-   do_image_wic[depends] += "mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot virtual/bootloader:do_deploy"
-
-   SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0 115200;ttyAMA0"
-
-   PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-   PREFERRED_VERSION_linux-yocto ?= "6.12%"
-
-   KERNEL_IMAGETYPE = "zImage"
-   DTB_FILES = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
-   KERNEL_DEVICETREE = '${@' '.join('ti/omap/%s' % d for d in '${DTB_FILES}'.split())}'
-
-   PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
-
-   SPL_BINARY = "MLO"
-   UBOOT_SUFFIX = "img"
-   UBOOT_MACHINE = "am335x_evm_defconfig"
-
-   MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
-
-   IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY} ${KERNEL_IMAGETYPE} ${DTB_FILES}"
-
-   # support runqemu
-   EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
-   IMAGE_CLASSES += "qemuboot"
-   QB_DEFAULT_FSTYPE = "wic"
-   QB_FSINFO = "wic:no-kernel-in-fs"
-   QB_KERNEL_ROOT = "/dev/vda2"
-   QB_SYSTEM_NAME = "qemu-system-arm"
-   QB_MACHINE = "-machine virt"
-   QB_CPU = "-cpu cortex-a15"
-   QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0 systemd.mask=systemd-networkd"
-   QB_OPT_APPEND = "-device virtio-rng-device"
-   QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
-   QB_NETWORK_DEVICE = "-device virtio-net-device,netdev=net0,mac=@MAC@"
-   QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0"
-   QB_SERIAL_OPT = ""
-   QB_TCPSERIAL_OPT = "-device virtio-serial-device -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device virtconsole,chardev=virtcon"
+located in :yocto_git:`/meta-yocto/tree/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
+</meta-yocto/tree/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf>`.
 
 The variables used to configure the machine define machine-specific properties; for
 example, machine-dependent packages, machine tunings, the type of kernel
@@ -1309,7 +1255,7 @@ Project Reference Manual.
    The recipe that provides "virtual/xserver" when more than one
    provider is found. In this case, the recipe that provides
    "virtual/xserver" is "xserver-xorg", available in
-   ``poky/meta/recipes-graphics/xorg-xserver``.
+   ``meta/recipes-graphics/xorg-xserver`` in :term:`OpenEmbedded-Core (OE-Core)`.
 
 -  :term:`MACHINE_EXTRA_RRECOMMENDS`:
    A list of machine-dependent packages not essential for booting the
@@ -1400,7 +1346,7 @@ Project Reference Manual.
    .. note::
 
       For more information on how the SPL variables are used, see the
-      :yocto_git:`u-boot.inc </poky/tree/meta/recipes-bsp/u-boot/u-boot.inc>`
+      :oe_git:`u-boot.inc </openembedded-core/tree/meta/recipes-bsp/u-boot/u-boot.inc>`
       include file.
 
 -  :term:`UBOOT_* <UBOOT_ENTRYPOINT>`: Defines
@@ -1438,7 +1384,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_6.1.bbappend``) is used to override an established
 kernel recipe (i.e. ``linux-yocto_6.1.bb``), which is located in
-:yocto_git:`/poky/tree/meta/recipes-kernel/linux`.
+:oe_git:`/openembedded-core/tree/meta/recipes-kernel/linux`.
 
 The contents of the append file are::
 

-- 
2.52.0

[PATCH v2 05/56] kernel-dev/advanced.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core
in most cases, and refer to bitbake-setup or the manual setup in the
intro.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/kernel-dev/advanced.rst | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/documentation/kernel-dev/advanced.rst b/documentation/kernel-dev/advanced.rst
index 4c463503f6..97cb663222 100644
--- a/documentation/kernel-dev/advanced.rst
+++ b/documentation/kernel-dev/advanced.rst
@@ -24,9 +24,8 @@ grouped under the "Yocto Linux Kernel" heading in the
 Kernel development tools ("kern-tools") are also available in the Yocto Project
 Source Repositories under the "Yocto Linux Kernel" heading in the
 ``yocto-kernel-tools`` Git repository. The recipe that builds these
-tools is ``meta/recipes-kernel/kern-tools/kern-tools-native_git.bb`` in
-the :term:`Source Directory` (e.g.
-``poky``).
+tools is ``recipes-kernel/kern-tools/kern-tools-native_git.bb`` in
+:term:`OpenEmbedded-Core (OE-Core)`.
 
 Using Kernel Metadata in a Recipe
 =================================
@@ -357,9 +356,9 @@ kernel of a specific type (e.g. a real-time kernel). Syntactically, kernel
 types are no different than features as described in the
 ":ref:`kernel-dev/advanced:features`" section. The :term:`LINUX_KERNEL_TYPE`
 variable in the kernel recipe selects the kernel type. For example, in the
-``linux-yocto_4.12.bb`` kernel recipe found in ``poky/meta/recipes-kernel/linux``, a
+``linux-yocto_4.12.bb`` kernel recipe found in ``meta/recipes-kernel/linux``, a
 :ref:`require <bitbake-user-manual/bitbake-user-manual-metadata:\`\`require\`\` directive>`
-directive includes the ``poky/meta/recipes-kernel/linux/linux-yocto.inc`` file,
+directive includes the ``meta/recipes-kernel/linux/linux-yocto.inc`` file,
 which has the following statement that defines the default kernel type::
 
    LINUX_KERNEL_TYPE ??= "standard"
@@ -373,8 +372,7 @@ type as follows::
 .. note::
 
    You can find kernel recipes in the ``meta/recipes-kernel/linux`` directory
-   of the :ref:`overview-manual/development-environment:yocto project source repositories`
-   (e.g. ``poky/meta/recipes-kernel/linux/linux-yocto_4.12.bb``). See the
+   of the :ref:`overview-manual/development-environment:yocto project source repositories`. See the
    ":ref:`kernel-dev/advanced:using kernel metadata in a recipe`"
    section for more information.
 

-- 
2.52.0

[PATCH v2 06/56] contributor-guide/submit-changes.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core
in most cases.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/contributor-guide/submit-changes.rst | 57 ++++++----------------
 1 file changed, 14 insertions(+), 43 deletions(-)

diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst
index 07989d7b6..4a4c60b41 100644
--- a/documentation/contributor-guide/submit-changes.rst
+++ b/documentation/contributor-guide/submit-changes.rst
@@ -429,37 +429,6 @@ and then based on successful testing, merges them.
 In general, each component (e.g. layer) should have a ``README`` file
 that indicates where to send the changes and which process to follow.
 
-The "poky" repository, which is the Yocto Project's reference build
-environment, is a hybrid repository that contains several individual
-pieces (e.g. BitBake, Metadata, documentation, and so forth) built using
-the combo-layer tool. The upstream location used for submitting changes
-varies by component:
-
--  *Core Metadata:* Send your patches to the
-   :oe_lists:`openembedded-core </g/openembedded-core>`
-   mailing list. For example, a change to anything under the ``meta`` or
-   ``scripts`` directories should be sent to this mailing list.
-
--  *BitBake:* For changes to BitBake (i.e. anything under the
-   ``bitbake`` directory), send your patches to the
-   :oe_lists:`bitbake-devel </g/bitbake-devel>`
-   mailing list.
-
--  *meta-poky* and *meta-yocto-bsp* trees: These trees contain Metadata. Use the
-   :yocto_lists:`poky </g/poky>` mailing list.
-
--  *Documentation*: For changes to the Yocto Project documentation, use the
-   :yocto_lists:`docs </g/docs>` mailing list.
-
-For changes to other layers and tools hosted in the Yocto Project source
-repositories (i.e. :yocto_git:`git.yoctoproject.org <>`), use the
-:yocto_lists:`yocto-patches </g/yocto-patches/>` general mailing list.
-
-For changes to other layers hosted in the OpenEmbedded source
-repositories (i.e. :oe_git:`git.openembedded.org <>`), use
-the :oe_lists:`openembedded-devel </g/openembedded-devel>`
-mailing list, unless specified otherwise in the layer's ``README`` file.
-
 If you intend to submit a new recipe that neither fits into the core Metadata,
 nor into :oe_git:`meta-openembedded </meta-openembedded/>`, you should
 look for a suitable layer in https://layers.openembedded.org. If similar
@@ -620,7 +589,7 @@ have been followed:
    methods to find out:
 
    -  *Maintenance File:* Examine the ``maintainers.inc`` file, which is
-      located in the :term:`Source Directory` at
+      located in :term:`OpenEmbedded-Core (OE-Core)` at
       ``meta/conf/distro/include``, to see who is responsible for code.
 
    -  *Search by File:* Using :ref:`overview-manual/development-environment:git`, you can
@@ -645,9 +614,8 @@ have been followed:
    The Yocto Project provides two scripts that conveniently let you
    generate and send pull requests to the Yocto Project. These scripts
    are ``create-pull-request`` and ``send-pull-request``. You can find
-   these scripts in the ``scripts`` directory within the
-   :term:`Source Directory` (e.g.
-   ``poky/scripts``).
+   these scripts in the ``scripts`` directory within
+   :term:`OpenEmbedded-Core (OE-Core)`.
 
    Using these scripts correctly formats the requests without
    introducing any whitespace or HTML formatting. The maintainer that
@@ -660,7 +628,7 @@ have been followed:
    directory into which you pushed the change, and provides a subject
    line in the created patch files::
 
-      $ poky/scripts/create-pull-request -u meta-intel-contrib -s "Updated Manual Section Reference in README"
+      $ ./scripts/create-pull-request -u meta-intel-contrib -s "Updated Manual Section Reference in README"
 
    Running this script forms ``*.patch`` files in a folder named
    ``pull-``\ `PID` in the current directory. One of the patch files is a
@@ -673,7 +641,7 @@ have been followed:
    and email address. In this example, the email address is a mailing
    list::
 
-      $ poky/scripts/send-pull-request -p ~/meta-intel/pull-10565 -t meta-intel@lists.yoctoproject.org
+      $ ./scripts/send-pull-request -p ~/meta-intel/pull-10565 -t meta-intel@lists.yoctoproject.org
 
    You need to follow the prompts as the script is interactive.
 
@@ -682,8 +650,8 @@ have been followed:
       For help on using these scripts, simply provide the ``-h``
       argument as follows::
 
-              $ poky/scripts/create-pull-request -h
-              $ poky/scripts/send-pull-request -h
+              $ ./scripts/create-pull-request -h
+              $ ./scripts/send-pull-request -h
 
 Submitting Changes to Stable Release Branches
 =============================================
@@ -857,14 +825,17 @@ used testing branches for OpenEmbedded-Core are as follows:
    :oe_git:`openembedded-core </openembedded-core/>` repository and contains
    proposed changes to the core metadata.
 
--  *poky "master-next" branch:* This branch is part of the
-   :yocto_git:`poky </poky/>` repository and combines proposed
-   changes to BitBake, the core metadata and the poky distro.
+- *bitbake "master-next" branch:* This branch is part of the :oe_git:`bitbake
+  </bitbake/>` repository and contains changes to :term:`BitBake`.
+
+-  *meta-yocto "master-next" branch:* This branch is part of the
+   :yocto_git:`meta-yocto </meta-yocto/>` repository and contains proposed
+   changes to meta-yocto.
 
 Similarly, stable branches maintained by the project may have corresponding
 ``-next`` branches which collect proposed changes. For example,
 ``&DISTRO_NAME_NO_CAP;-next`` and ``&DISTRO_NAME_NO_CAP_MINUS_ONE;-next``
-branches in both the "openembdedded-core" and "poky" repositories.
+branches in both the "openembedded-core" and "meta-yocto" repositories.
 
 Other layers may have similar testing branches but there is no formal
 requirement or standard for these so please check the documentation for the

-- 
2.52.0

[PATCH v2 07/56] dev-manual/building.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core
in most cases.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/building.rst  | 40 +++++++---------------------------
 documentation/ref-manual/fragments.rst |  2 ++
 2 files changed, 10 insertions(+), 32 deletions(-)

diff --git a/documentation/dev-manual/building.rst b/documentation/dev-manual/building.rst
index 60ad11f52..c153eb9de 100644
--- a/documentation/dev-manual/building.rst
+++ b/documentation/dev-manual/building.rst
@@ -51,32 +51,9 @@ The following figure and list overviews the build process:
    Yocto Project*: See the ":doc:`/dev-manual/start`" section for options on how to get a
    build host ready to use the Yocto Project.
 
-#. *Initialize the Build Environment:* Initialize the build environment
-   by sourcing the build environment script (i.e.
-   :ref:`structure-core-script`)::
-
-      $ source oe-init-build-env [build_dir]
-
-   When you use the initialization script, the OpenEmbedded build system
-   uses ``build`` as the default :term:`Build Directory` in your current work
-   directory. You can use a `build_dir` argument with the script to
-   specify a different :term:`Build Directory`.
-
-   .. note::
-
-      A common practice is to use a different :term:`Build Directory` for
-      different targets; for example, ``~/build/x86`` for a ``qemux86``
-      target, and ``~/build/arm`` for a ``qemuarm`` target. In any
-      event, it's typically cleaner to locate the :term:`Build Directory`
-      somewhere outside of your source directory.
-
-#. *Make Sure Your* ``local.conf`` *File is Correct*: Ensure the
-   ``conf/local.conf`` configuration file, which is found in the
-   :term:`Build Directory`, is set up how you want it. This file defines many
-   aspects of the build environment including the target machine architecture
-   through the :term:`MACHINE` variable, the packaging format used during
-   the build (:term:`PACKAGE_CLASSES`), and a centralized tarball download
-   directory through the :term:`DL_DIR` variable.
+#. *Make Sure Your Configuration is Correct*: Use :ref:`bitbake-config-build <ref-bitbake-config-build-qf>` to
+   define the :term:`MACHINE` or :term:`DISTRO`, and open your
+   :ref:`structure-build-conf-site.conf` file to set site-specific settings.
 
 #. *Build the Image:* Build the image using the ``bitbake`` command::
 
@@ -88,8 +65,8 @@ The following figure and list overviews the build process:
 
    The target is the name of the recipe you want to build. Common
    targets are the images in ``meta/recipes-core/images``,
-   ``meta/recipes-sato/images``, and so forth all found in the
-   :term:`Source Directory`. Alternatively, the target
+   ``meta/recipes-sato/images``, and so forth all found in
+   :term:`OpenEmbedded-Core (OE-Core)`. Alternatively, the target
    can be the name of a recipe for a specific piece of software such as
    BusyBox. For more details about the images the OpenEmbedded build
    system supports, see the
@@ -127,7 +104,7 @@ Follow these steps to create an :term:`Initramfs` image:
 
 #. *Create the Initramfs Image Recipe:* You can reference the
    ``core-image-minimal-initramfs.bb`` recipe found in the
-   ``meta/recipes-core`` directory of the :term:`Source Directory`
+   ``meta/recipes-core`` directory in :term:`OpenEmbedded-Core (OE-Core)`
    as an example from which to work. The ``core-image-minimal-initramfs`` recipe
    is based on the :ref:`initramfs-framework <dev-manual/building:Customizing an
    Initramfs using \`\`initramfs-framework\`\`>` recipe described below.
@@ -366,9 +343,8 @@ memory used for decompressing the kernel and for the ``__init__``
 functions.
 
 To help you see where you currently are with kernel and root filesystem
-sizes, you can use two tools found in the :term:`Source Directory`
-in the
-``scripts/tiny/`` directory:
+sizes, you can use two tools found in :term:`OpenEmbedded-Core (OE-Core)`
+in the ``scripts/tiny/`` directory:
 
 -  ``ksize.py``: Reports component sizes for the kernel build objects.
 
diff --git a/documentation/ref-manual/fragments.rst b/documentation/ref-manual/fragments.rst
index 42fba41e9..9449f4648 100644
--- a/documentation/ref-manual/fragments.rst
+++ b/documentation/ref-manual/fragments.rst
@@ -22,6 +22,8 @@ System` core repositories.
    :doc:`/dev-manual/creating-fragments` section of the Yocto Project Development
    Tasks Manual.
 
+.. _ref-bitbake-config-build-qf:
+
 ``bitbake-config-build`` Quick Reference
 ========================================
 

-- 
2.52.0

[PATCH v2 08/56] dev-manual/debugging.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/debugging.rst | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst
index 0202f1b32..21fb10537 100644
--- a/documentation/dev-manual/debugging.rst
+++ b/documentation/dev-manual/debugging.rst
@@ -439,7 +439,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 </poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54>`.
+   :oe_git:`commit </openembedded-core/commit/meta/classes/package.bbclass?id=30064a98dc9049db4a37f119d15fbb59aa3c8377>`.
 
 Running Specific Tasks
 ======================
@@ -522,7 +522,7 @@ task dependency mechanisms.
 
    .. code-block:: none
 
-      WARNING: /home/ulf/poky/meta/recipes-sato/matchbox-desktop/matchbox-desktop_2.1.bb.do_compile is tainted from a forced run
+      WARNING: /home/ulf/openembedded-core/meta/recipes-sato/matchbox-desktop/matchbox-desktop_2.1.bb.do_compile is tainted from a forced run
 
 
    The purpose of the warning is to let you know that the work directory
@@ -615,7 +615,7 @@ The same logging functions are also available in shell functions, under
 the names ``bbplain``, ``bbnote``, ``bbdebug``, ``bbwarn``, ``bberror``,
 and ``bbfatal``. The :ref:`ref-classes-logging` class
 implements these functions. See that class in the ``meta/classes``
-folder of the :term:`Source Directory` for information.
+folder of :term:`OpenEmbedded-Core (OE-Core)` for information.
 
 Logging With Python
 -------------------
@@ -852,10 +852,10 @@ patch::
    Refreshed patch patches/parallelmake.patch
 
 Once the patch file is created, you need to add it back to the originating
-recipe folder. Here is an example assuming a top-level
-:term:`Source Directory` named ``poky``::
+recipe folder. Here is an example assuming :term:`OpenEmbedded-Core (OE-Core)`
+is named ``openembedded-core``::
 
-   $ cp patches/parallelmake.patch poky/meta/recipes-connectivity/neard/neard
+   $ cp patches/parallelmake.patch openembedded-core/meta/recipes-connectivity/neard/neard
 
 The final thing you need to do to implement the fix in the build is to
 update the "neard" recipe (i.e. ``neard-0.14.bb``) so that the
@@ -940,7 +940,9 @@ debug symbols from the server.
 To run a ``debuginfod`` server, you need to do the following:
 
 -  Ensure that ``debuginfod`` is present in :term:`DISTRO_FEATURES`
-   (it already is in ``OpenEmbedded-core`` defaults and ``poky`` reference distribution).
+   (it already is in :term:`OpenEmbedded-Core (OE-Core)` defaults and
+   :term:`Poky` reference distribution).
+
    If not, set in your distro config file or in ``local.conf``::
 
       DISTRO_FEATURES:append = " debuginfod"

-- 
2.52.0

[PATCH v2 09/56] dev-manual/error-reporting-tool.rst: remove obsolete poky repo references

[Antonin Godard]

Remove the single poky repository reference in this document, after the
poky repository was obsoleted.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/error-reporting-tool.rst | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/documentation/dev-manual/error-reporting-tool.rst b/documentation/dev-manual/error-reporting-tool.rst
index 84f3d9cd1e..30d1ce2b31 100644
--- a/documentation/dev-manual/error-reporting-tool.rst
+++ b/documentation/dev-manual/error-reporting-tool.rst
@@ -7,8 +7,7 @@ The error reporting tool allows you to submit errors encountered during
 builds to a central database. Outside of the build environment, you can
 use a web interface to browse errors, view statistics, and query for
 errors. The tool works using a client-server system where the client
-portion is integrated with the installed Yocto Project
-:term:`Source Directory` (e.g. ``poky``).
+portion is integrated in :term:`OpenEmbedded-Core (OE-Core)`.
 The server receives the information collected and saves it in a
 database.
 

-- 
2.52.0

[PATCH v2 10/56] dev-manual/external-toolchain.rst: remove obsolete poky repo references

[Antonin Godard]

Remove the single poky repository reference in this document, after the
poky repository was obsoleted.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/external-toolchain.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/dev-manual/external-toolchain.rst b/documentation/dev-manual/external-toolchain.rst
index 238f8cf467..29459ea120 100644
--- a/documentation/dev-manual/external-toolchain.rst
+++ b/documentation/dev-manual/external-toolchain.rst
@@ -21,7 +21,7 @@ follows:
 The toolchain configuration is very flexible and customizable. It
 is primarily controlled with the :term:`TCMODE` variable. This variable
 controls which ``tcmode-*.inc`` file to include from the
-``meta/conf/distro/include`` directory within the :term:`Source Directory`.
+``meta/conf/distro/include`` directory within :term:`OpenEmbedded-Core (OE-Core)`.
 
 The default value of :term:`TCMODE` is "default", which tells the
 OpenEmbedded build system to use its internally built toolchain (i.e.

-- 
2.52.0

[PATCH v2 11/56] dev-manual/layers.rst: remove obsolete poky repo references

[Antonin Godard]

The first section of the layers document shows how to manually create a
layer step-by-step, and references bitbake-layers create-layer at the
end. Change the approach of this section to show how to use the
bitbake-layers create-layer command to create a layer, and then explain
how a layer is organized and configured. This avoids repetition, and we
should encourage users to use pre-built tools when they can do things in
a less error-prone way.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/brief-yoctoprojectqs/index.rst       |   2 +-
 documentation/bsp-guide/bsp.rst                    |   2 +-
 documentation/dev-manual/custom-distribution.rst   |   2 +-
 documentation/dev-manual/layers.rst                | 277 ++++++++-------------
 documentation/kernel-dev/common.rst                |   6 +-
 .../transitioning-to-a-custom-environment.rst      |   3 +-
 6 files changed, 110 insertions(+), 182 deletions(-)

diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst
index 84eb63c937..903dc242eb 100644
--- a/documentation/brief-yoctoprojectqs/index.rst
+++ b/documentation/brief-yoctoprojectqs/index.rst
@@ -452,7 +452,7 @@ The following commands run the tool to create a layer named
 
 For more information
 on layers and how to create them, see the
-:ref:`dev-manual/layers:creating a general layer using the \`\`bitbake-layers\`\` script`
+:ref:`dev-manual/layers:Creating Your Own Layer`
 section in the Yocto Project Development Tasks Manual.
 
 Where To Go Next
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index 49527f45d1..4c0939ab0b 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -1155,7 +1155,7 @@ Use these steps to create a BSP layer:
    ``create-layer`` subcommand to create a new general layer. For
    instructions on how to create a general layer using the
    ``bitbake-layers`` script, see the
-   ":ref:`dev-manual/layers:creating a general layer using the \`\`bitbake-layers\`\` script`"
+   ":ref:`dev-manual/layers:Creating Your Own Layer`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *Create a Layer Configuration File:* Every layer needs a layer
diff --git a/documentation/dev-manual/custom-distribution.rst b/documentation/dev-manual/custom-distribution.rst
index 0bc386d606..55854f00ea 100644
--- a/documentation/dev-manual/custom-distribution.rst
+++ b/documentation/dev-manual/custom-distribution.rst
@@ -27,7 +27,7 @@ layer. The following steps provide some more detail:
    just placing configurations in a ``local.conf`` configuration file
    makes it easier to reproduce the same build configuration when using
    multiple build machines. See the
-   ":ref:`dev-manual/layers:creating a general layer using the \`\`bitbake-layers\`\` script`"
+   ":ref:`dev-manual/layers:Creating Your Own Layer`"
    section for information on how to quickly set up a layer.
 
 -  *Create the distribution configuration file:* The distribution
diff --git a/documentation/dev-manual/layers.rst b/documentation/dev-manual/layers.rst
index 667708e32b..456e72f4f3 100644
--- a/documentation/dev-manual/layers.rst
+++ b/documentation/dev-manual/layers.rst
@@ -14,18 +14,6 @@ section in the Yocto Project Overview and Concepts Manual.
 Creating Your Own Layer
 =======================
 
-.. note::
-
-   It is very easy to create your own layers to use with the OpenEmbedded
-   build system, as the Yocto Project ships with tools that speed up creating
-   layers. This section describes the steps you perform by hand to create
-   layers so that you can better understand them. For information about the
-   layer-creation tools, see the
-   ":ref:`bsp-guide/bsp:creating a new bsp layer using the \`\`bitbake-layers\`\` script`"
-   section in the Yocto Project Board Support Package (BSP) Developer's
-   Guide and the ":ref:`dev-manual/layers:creating a general layer using the \`\`bitbake-layers\`\` script`"
-   section further down in this manual.
-
 Follow these general steps to create your layer without using tools:
 
 #. *Check Existing Layers:* Before creating a new layer, you should be
@@ -35,10 +23,22 @@ Follow these general steps to create your layer without using tools:
    the Yocto Project. You could find a layer that is identical or close
    to what you need.
 
-#. *Create a Directory:* Create the directory for your layer. When you
-   create the layer, be sure to create the directory in an area not
-   associated with the Yocto Project :term:`Source Directory`
-   (e.g. the cloned ``poky`` repository).
+   .. note::
+
+      For information on BSP layers, see the ":ref:`bsp-guide/bsp:bsp layers`"
+      section in the Yocto Project Board Specific (BSP) Developer's Guide.
+
+#. *Create a new Layer:* Create the directory for your layer. The
+   ``bitbake-layers`` script with the ``create-layer`` subcommand simplifies
+   creating a new general layer. Place it next to the other layers in your
+   :term:`Source Directory`.
+
+   In its simplest form, you can use the following command to create a
+   layer named "your_layer_name" in the current directory.
+
+   .. code-block:: console
+
+      $ bitbake-layers create-layer your_layer_name
 
    While not strictly required, prepend the name of the directory with
    the string "meta-". For example::
@@ -58,88 +58,96 @@ Follow these general steps to create your layer without using tools:
    "meta-" string are appended to several variables used in the
    configuration.
 
-#. *Create a Layer Configuration File:* Inside your new layer folder,
-   you need to create a ``conf/layer.conf`` file. It is easiest to take
-   an existing layer configuration file and copy that to your layer's
-   ``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 </poky/tree/meta-yocto-bsp/conf>`
-   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")::
-
-      # We have a conf and classes directory, add to BBPATH
-      BBPATH .= ":${LAYERDIR}"
-
-      # We have recipes-* directories, add to BBFILES
-      BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
-                  ${LAYERDIR}/recipes-*/*/*.bbappend"
-
-      BBFILE_COLLECTIONS += "yoctobsp"
-      BBFILE_PATTERN_yoctobsp = "^${LAYERDIR}/"
-      BBFILE_PRIORITY_yoctobsp = "5"
-      LAYERVERSION_yoctobsp = "4"
-      LAYERSERIES_COMPAT_yoctobsp = "walnascar"
-
-   Here is an explanation of the layer configuration file:
-
-   -  :term:`BBPATH`: Adds the layer's
-      root directory to BitBake's search path. Through the use of the
-      :term:`BBPATH` variable, BitBake locates class files (``.bbclass``),
-      configuration files, and files that are included with ``include``
-      and ``require`` statements. For these cases, BitBake uses the
-      first file that matches the name found in :term:`BBPATH`. This is
-      similar to the way the ``PATH`` variable is used for binaries. It
-      is recommended, therefore, that you use unique class and
-      configuration filenames in your custom layer.
-
-   -  :term:`BBFILES`: Defines the
-      location for all recipes in the layer.
-
-   -  :term:`BBFILE_COLLECTIONS`:
-      Establishes the current layer through a unique identifier that is
-      used throughout the OpenEmbedded build system to refer to the
-      layer. In this example, the identifier "yoctobsp" is the
-      representation for the container layer named "meta-yocto-bsp".
-
-   -  :term:`BBFILE_PATTERN`:
-      Expands immediately during parsing to provide the directory of the
-      layer.
-
-   -  :term:`BBFILE_PRIORITY`:
-      Establishes a priority to use for recipes in the layer when the
-      OpenEmbedded build finds recipes of the same name in different
-      layers.
-
-   -  :term:`LAYERVERSION`:
-      Establishes a version number for the layer. You can use this
-      version number to specify this exact version of the layer as a
-      dependency when using the
-      :term:`LAYERDEPENDS`
-      variable.
-
-   -  :term:`LAYERDEPENDS`:
-      Lists all layers on which this layer depends (if any).
-
-   -  :term:`LAYERSERIES_COMPAT`:
-      Lists the :yocto_home:`Yocto Project releases </development/releases/>`
-      for which the current version is compatible. This variable is a good
-      way to indicate if your particular layer is current.
+   As an example, the following command creates a layer named ``meta-scottrif``
+   in your home directory:
 
+   .. code-block:: console
 
-   .. note::
+      $ bitbake-layers create-layer meta-scottrif
+      NOTE: Starting bitbake server...
+      Add your new layer with 'bitbake-layers add-layer meta-scottrif'
+
+   In order to use a layer with the :term:`OpenEmbedded Build System`, you
+   need to add the layer to your ``bblayers.conf`` configuration
+   file, as hinted by the previous command. See the
+   ":ref:`dev-manual/layers:adding a layer using the \`\`bitbake-layers\`\`
+   script`" section for more information.
+
+   The default mode of the script's operation with this subcommand is to
+   create a layer with the following:
+
+   -  A ``conf/layer.conf`` configuration file with default definitions.
+
+      Here is an explanation of the typical content of the layer configuration file:
+
+      -  :term:`BBPATH`: Adds the layer's root directory to BitBake's search
+         path. Through the use of the :term:`BBPATH` variable, BitBake locates
+         class files (``.bbclass``), configuration files, and files that are
+         included with ``include`` and ``require`` statements. For these cases,
+         BitBake uses the first file that matches the name found in
+         :term:`BBPATH`. This is similar to the way the ``PATH`` variable is
+         used for binaries. It is recommended, therefore, that you use unique
+         class and configuration filenames in your custom layer.
+
+         See the :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:Locating Include
+         Files` section of the BitBake User Manual for more details on how
+         files are included with :term:`BitBake`.
+
+      -  :term:`BBFILES`: Defines the location for all recipes in the layer.
+
+      -  :term:`BBFILE_COLLECTIONS`: Establishes the current layer through a
+         unique identifier that is used throughout the :term:`OpenEmbedded Build
+         System` to refer to the layer. In this example, the identifier
+         "yoctobsp" is the representation for the container layer named
+         "meta-yocto-bsp".
+
+         This name is used by other layers when specifying the layer
+         dependencies via the :term:`LAYERDEPENDS` variable.
+
+      -  :term:`BBFILE_PATTERN`: Expands immediately during parsing to provide
+         the directory of the layer.
+
+      -  :term:`BBFILE_PRIORITY`: Establishes a priority to use for recipes in
+         the layer when the :term:`OpenEmbedded Build System` finds recipes of
+         the same name in different layers.
+
+      -  :term:`LAYERVERSION`: Establishes a version number for the layer. You
+         can use this version number to specify this exact version of the layer
+         as a dependency when using the :term:`LAYERDEPENDS` variable.
+
+      -  :term:`LAYERDEPENDS`: Lists all layers on which this layer depends (if
+         any). It uses the layer names specified by the
+         :term:`BBFILE_COLLECTIONS` variable.
+
+      -  :term:`LAYERSERIES_COMPAT`: Lists the :yocto_home:`Yocto Project
+         releases </development/releases/>` codenames (in lowercase) for which
+         the current version is compatible. For example: "&DISTRO_NAME_NO_CAP;".
+
+         This variable is a good way to indicate if your particular layer is
+         current. 
+
+   -  A ``recipes-example`` subdirectory that contains a further
+      subdirectory named ``example``, which contains an ``example.bb``
+      recipe file.
+
+   -  A ``COPYING.MIT``, which is the license statement for the layer. The
+      script assumes you want to use the MIT license, which is typical for
+      most layers, for the contents of the layer itself.
 
-      A layer does not have to contain only recipes ``.bb`` or append files
-      ``.bbappend``. Generally, developers create layers using
-      ``bitbake-layers create-layer``.
-      See ":ref:`dev-manual/layers:creating a general layer using the \`\`bitbake-layers\`\` script`",
-      explaining how the ``layer.conf`` file is created from a template located in
-      ``meta/lib/bblayers/templates/layer.conf``.
-      In fact, none of the variables set in ``layer.conf`` are mandatory,
-      except when :term:`BBFILE_COLLECTIONS` is present. In this case
-      :term:`LAYERSERIES_COMPAT` and :term:`BBFILE_PATTERN` have to be
-      defined too.
+   -  A ``README`` file, which is a file describing the contents of your
+      new layer.
+
+
+   If you want to set the priority of the layer to other than the default value
+   of "6", you can either use the ``--priority`` option or you can edit the
+   :term:`BBFILE_PRIORITY` value in the ``conf/layer.conf`` after the script
+   creates it. Furthermore, if you want to give the example recipe file some
+   name other than the default, you can use the ``--example-recipe-name``
+   option.
+
+   The easiest way to see how the ``bitbake-layers create-layer`` command
+   works is to experiment with the script. You can also read the usage
+   information by running ``bitbake-layers create-layer --help``.
 
 #. *Add Content:* Depending on the type of layer, add the content. If
    the layer adds support for a machine, add the machine configuration
@@ -874,85 +882,6 @@ The following list describes the available commands:
 
 -  ``show-machines``: Lists the machines available in the currently configured layers.
 
-Creating a General Layer Using the ``bitbake-layers`` Script
-============================================================
-
-The ``bitbake-layers`` script with the ``create-layer`` subcommand
-simplifies creating a new general layer.
-
-.. note::
-
-   -  For information on BSP layers, see the ":ref:`bsp-guide/bsp:bsp layers`"
-      section in the Yocto
-      Project Board Specific (BSP) Developer's Guide.
-
-   -  In order to use a layer with the OpenEmbedded build system, you
-      need to add the layer to your ``bblayers.conf`` configuration
-      file. See the ":ref:`dev-manual/layers:adding a layer using the \`\`bitbake-layers\`\` script`"
-      section for more information.
-
-The default mode of the script's operation with this subcommand is to
-create a layer with the following:
-
--  A layer priority of 6.
-
--  A ``conf`` subdirectory that contains a ``layer.conf`` file.
-
--  A ``recipes-example`` subdirectory that contains a further
-   subdirectory named ``example``, which contains an ``example.bb``
-   recipe file.
-
--  A ``COPYING.MIT``, which is the license statement for the layer. The
-   script assumes you want to use the MIT license, which is typical for
-   most layers, for the contents of the layer itself.
-
--  A ``README`` file, which is a file describing the contents of your
-   new layer.
-
-In its simplest form, you can use the following command form to create a
-layer. The command creates a layer whose name corresponds to
-"your_layer_name" in the current directory::
-
-   $ bitbake-layers create-layer your_layer_name
-
-As an example, the following command creates a layer named ``meta-scottrif``
-in your home directory::
-
-   $ cd /usr/home
-   $ bitbake-layers create-layer meta-scottrif
-   NOTE: Starting bitbake server...
-   Add your new layer with 'bitbake-layers add-layer meta-scottrif'
-
-If you want to set the priority of the layer to other than the default
-value of "6", you can either use the ``--priority`` option or you
-can edit the
-:term:`BBFILE_PRIORITY` value
-in the ``conf/layer.conf`` after the script creates it. Furthermore, if
-you want to give the example recipe file some name other than the
-default, you can use the ``--example-recipe-name`` option.
-
-The easiest way to see how the ``bitbake-layers create-layer`` command
-works is to experiment with the script. You can also read the usage
-information by entering the following::
-
-   $ bitbake-layers create-layer --help
-   NOTE: Starting bitbake server...
-   usage: bitbake-layers create-layer [-h] [--priority PRIORITY]
-                                      [--example-recipe-name EXAMPLERECIPE]
-                                      layerdir
-
-   Create a basic layer
-
-   positional arguments:
-     layerdir              Layer directory to create
-
-   optional arguments:
-     -h, --help            show this help message and exit
-     --priority PRIORITY, -p PRIORITY
-                           Layer directory to create
-     --example-recipe-name EXAMPLERECIPE, -e EXAMPLERECIPE
-                           Filename of the example recipe
-
 Adding a Layer Using the ``bitbake-layers`` Script
 ==================================================
 
diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst
index 1e098c158f..2142d31c09 100644
--- a/documentation/kernel-dev/common.rst
+++ b/documentation/kernel-dev/common.rst
@@ -95,7 +95,7 @@ section:
       Support (BSP) Developer's Guide, respectively. For information on how to
       use the ``bitbake-layers create-layer`` command to quickly set up a layer,
       see the
-      ":ref:`dev-manual/layers:creating a general layer using the \`\`bitbake-layers\`\` script`"
+      ":ref:`dev-manual/layers:Creating Your Own Layer`"
       section in the Yocto Project Development Tasks Manual.
 
 #. *Inform the BitBake Build Environment About Your Layer:* As directed
@@ -190,7 +190,7 @@ section:
       Support (BSP) Developer's Guide, respectively. For information on how to
       use the ``bitbake-layers create-layer`` command to quickly set up a layer,
       see the
-      ":ref:`dev-manual/layers:creating a general layer using the \`\`bitbake-layers\`\` script`"
+      ":ref:`dev-manual/layers:Creating Your Own Layer`"
       section in the Yocto Project Development Tasks Manual.
 
 #. *Inform the BitBake Build Environment About Your Layer:* As directed
@@ -276,7 +276,7 @@ section in the Yocto Project Development Tasks Manual.
    The Yocto Project comes with many tools that simplify tasks you need
    to perform. One such tool is the ``bitbake-layers create-layer``
    command, which simplifies creating a new layer. See the
-   ":ref:`dev-manual/layers:creating a general layer using the \`\`bitbake-layers\`\` script`"
+   ":ref:`dev-manual/layers:Creating Your Own Layer`"
    section in the Yocto Project Development Tasks Manual for
    information on how to use this script to quick set up a new layer.
 
diff --git a/documentation/transitioning-to-a-custom-environment.rst b/documentation/transitioning-to-a-custom-environment.rst
index e292399f43..bc37345b98 100644
--- a/documentation/transitioning-to-a-custom-environment.rst
+++ b/documentation/transitioning-to-a-custom-environment.rst
@@ -56,8 +56,7 @@ Transitioning to a custom environment for systems development
 #. **Add a new layer for any custom recipes and metadata you create**.
    Use the ``bitbake-layers create-layer`` command. The ``bitbake-layers`` tool
    also provides a number of other useful layer-related commands. See
-   :ref:`dev-manual/layers:creating a general layer using the
-   \`\`bitbake-layers\`\` script` section.
+   :ref:`dev-manual/layers:Creating Your Own Layer` section.
 
 #. **Create your own layer for the BSP you're going to use**.
    It is not common that you would need to create an entire BSP from scratch

-- 
2.52.0

[PATCH v2 12/56] dev-manual/layers.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/layers.rst | 31 ++++++++++++++++---------------
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/documentation/dev-manual/layers.rst b/documentation/dev-manual/layers.rst
index 456e72f4f..ab5c258f1 100644
--- a/documentation/dev-manual/layers.rst
+++ b/documentation/dev-manual/layers.rst
@@ -290,7 +290,7 @@ following list:
    repository that use the ``meta-layer_name`` format.
 
 -  *Group Your Layers Locally:* Clone your repository alongside other
-   cloned ``meta`` directories from the :term:`Source Directory`.
+   layers in your :term:`Source Directory`.
 
 Making Sure Your Layer is Compatible With Yocto Project
 =======================================================
@@ -529,10 +529,10 @@ possible.
 Overlaying a File Using Your Layer
 ----------------------------------
 
-As an example, consider the main formfactor recipe and a corresponding
-formfactor append file both from the :term:`Source Directory`.
+As an example, consider the main ``formfactor`` recipe and a corresponding
+``formfactor`` append file both from :term:`OpenEmbedded-Core (OE-Core)`.
 Here is the main
-formfactor recipe, which is named ``formfactor_0.0.bb`` and located in
+``formfactor`` recipe, which is named ``formfactor_0.0.bb`` and located in
 the "meta" layer at ``meta/recipes-bsp/formfactor``::
 
    SUMMARY = "Device formfactor information"
@@ -609,8 +609,8 @@ Installing Additional Files Using Your Layer
 --------------------------------------------
 
 As another example, consider the main ``xserver-xf86-config`` recipe and a
-corresponding ``xserver-xf86-config`` append file both from the :term:`Source
-Directory`.  Here is the main ``xserver-xf86-config`` recipe, which is named
+corresponding ``xserver-xf86-config`` append file both from
+:term:`OpenEmbedded-Core (OE-Core)`.  Here is the main ``xserver-xf86-config`` recipe, which is named
 ``xserver-xf86-config_0.1.bb`` and located in the "meta" layer at
 ``meta/recipes-graphics/xorg-xserver``::
 
@@ -897,7 +897,9 @@ Add your layer by using the ``bitbake-layers add-layer`` command::
 Here is an example that adds a
 layer named ``meta-scottrif`` to the configuration file. Following the
 command that adds the layer is another ``bitbake-layers`` command that
-shows the layers that are in your ``bblayers.conf`` file::
+shows the layers that are in your ``bblayers.conf`` file:
+
+.. code-block:: console
 
    $ bitbake-layers add-layer meta-scottrif
    NOTE: Starting bitbake server...
@@ -905,14 +907,13 @@ shows the layers that are in your ``bblayers.conf`` file::
    Parsing of 1441 .bb files complete (0 cached, 1441 parsed). 2055 targets, 56 skipped, 0 masked, 0 errors.
    $ bitbake-layers show-layers
    NOTE: Starting bitbake server...
-   layer                 path                                      priority
-   ==========================================================================
-   meta                  /home/scottrif/poky/meta                  5
-   meta-poky             /home/scottrif/poky/meta-poky             5
-   meta-yocto-bsp        /home/scottrif/poky/meta-yocto-bsp        5
-   workspace             /home/scottrif/poky/build/workspace       99
-   meta-scottrif         /home/scottrif/poky/build/meta-scottrif   6
-
+   layer                 path                                                            priority
+   ==============================================================================================
+   meta                  /home/scottrif/bitbake-builds/layers/openembedded-core/meta           5
+   meta-poky             /home/scottrif/bitbake-builds/layers/meta-yocto/meta-poky             5
+   meta-yocto-bsp        /home/scottrif/bitbake-builds/layers/meta-yocto/meta-yocto-bsp        5
+   workspace             /home/scottrif/bitbake-builds/build/workspace                         99
+   meta-scottrif         /home/scottrif/bitbake-builds/build/meta-scottrif                     6
 
 Adding the layer to this file
 enables the build system to locate the layer during the build.

-- 
2.52.0

[PATCH v2 13/56] dev-manual/libraries.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/libraries.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/documentation/dev-manual/libraries.rst b/documentation/dev-manual/libraries.rst
index a8c38128e..697ea48e4 100644
--- a/documentation/dev-manual/libraries.rst
+++ b/documentation/dev-manual/libraries.rst
@@ -68,8 +68,8 @@ libraries and other binaries to use a different set of libraries. The
 libraries could differ in architecture, compiler options, or other
 optimizations.
 
-There are several examples in the ``meta-skeleton`` layer found in the
-:term:`Source Directory`:
+There are several examples in the ``meta-skeleton`` layer found in
+:term:`OpenEmbedded-Core (OE-Core)`:
 
 -  :oe_git:`conf/multilib-example.conf </openembedded-core/tree/meta-skeleton/conf/multilib-example.conf>`
    configuration file.
@@ -90,8 +90,8 @@ meet your needs.
 In order to enable Multilib, you first need to ensure your recipe is
 extended to support multiple libraries. Many standard recipes are
 already extended and support multiple libraries. You can check in the
-``meta/conf/multilib.conf`` configuration file in the
-:term:`Source Directory` to see how this is
+``meta/conf/multilib.conf`` configuration file in
+:term:`OpenEmbedded-Core (OE-Core)` to see how this is
 done using the
 :term:`BBCLASSEXTEND` variable.
 Eventually, all recipes will be covered and this list will not be

-- 
2.52.0

[PATCH v2 14/56] dev-manual/new-recipe.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/new-recipe.rst | 25 +++++++++++++++++--------
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/documentation/dev-manual/new-recipe.rst b/documentation/dev-manual/new-recipe.rst
index ee0f6aaf6..5e9498afc 100644
--- a/documentation/dev-manual/new-recipe.rst
+++ b/documentation/dev-manual/new-recipe.rst
@@ -224,14 +224,23 @@ is to use the ``bitbake-getvar`` utility::
 
    $ bitbake-getvar -r basename WORKDIR
 
-As an example, assume a Source Directory
-top-level folder named ``poky``, a default :term:`Build Directory` at
-``poky/build``, and a ``qemux86-poky-linux`` machine target system.
+As an example, assume a :term:`Source Directory`
+top-level folder named ``bitbake-builds``, a default :term:`Build Directory` at
+``bitbake-builds/build``, a ``cortexa57`` :term:`PACKAGE_ARCH`, ``poky``
+:term:`DISTRO` and ``linux`` as :term:`TARGET_OS`.
+
 Furthermore, suppose your recipe is named ``foo_1.3.0.bb``. In this
 case, the work directory the build system uses to build the package
 would be as follows::
 
-   poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
+   bitbake-builds/build/tmp/work/cortexa57-poky-linux/foo/1.3.0
+
+.. note::
+
+   This covers the case when the :term:`PACKAGE_ARCH` variable is set to its
+   default value, :term:`TUNE_PKGARCH`. This variable is sometimes set to
+   :term:`MACHINE_ARCH`. See the documentation of the :term:`PACKAGE_ARCH`
+   variable for more information.
 
 Inside this directory you can find sub-directories such as ``image``,
 ``packages-split``, and ``temp``. After the build, you can examine these
@@ -240,7 +249,7 @@ to determine how well the build went.
 .. note::
 
    You can find log files for each task in the recipe's ``temp``
-   directory (e.g. ``poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0/temp``).
+   directory (e.g. ``bitbake-builds/build/tmp/work/cortexa57-poky-linux/foo/1.3.0/temp``).
    Log files are named ``log.taskname`` (e.g. ``log.do_configure``,
    ``log.do_fetch``, and ``log.do_compile``).
 
@@ -830,7 +839,7 @@ different ways:
 
    To enable a service using systemd, your recipe needs to inherit the
    :ref:`ref-classes-systemd` class. See the ``systemd.bbclass`` file
-   located in your :term:`Source Directory` section for more information.
+   located in :term:`OpenEmbedded-Core (OE-Core)` section for more information.
 
 Packaging
 =========
@@ -974,8 +983,8 @@ 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 :yocto_git:`x86-base.inc
-</poky/tree/meta/conf/machine/include/x86/x86-base.inc>` include file, which is a
+an example, consider the :oe_git:`x86-base.inc
+</openembedded-core/tree/meta/conf/machine/include/x86/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::

-- 
2.52.0

[PATCH v2 15/56] dev-manual/securing-images.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/security-manual/securing-images.rst | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/documentation/security-manual/securing-images.rst b/documentation/security-manual/securing-images.rst
index cc6f95003..e502f83e3 100644
--- a/documentation/security-manual/securing-images.rst
+++ b/documentation/security-manual/securing-images.rst
@@ -50,9 +50,10 @@ more secure:
 -  Regularly scan and apply fixes for CVE security issues affecting
    all software components in the product, see ":ref:`security-manual/vulnerabilities:checking for vulnerabilities`".
 
--  Regularly update your version of Poky and OE-Core from their upstream
-   developers, e.g. to apply updates and security fixes from stable
-   and :term:`LTS` branches.
+-  Regularly update your version of :term:`BitBake` and your layers (e.g.
+   :term:`OpenEmbedded-Core (OE-Core)`, :yocto_git:`meta-yocto </meta-yocto/>`,
+   ...) from their upstream developers, e.g. to apply updates and security fixes
+   from stable and :term:`LTS` branches.
 
 -  Ensure you remove or disable debugging functionality before producing
    the final image. For information on how to do this, see the
@@ -72,7 +73,7 @@ Security Flags
 The Yocto Project has security flags that you can enable that help make
 your build output more secure. The security flags are in the
 ``meta/conf/distro/include/security_flags.inc`` file in your
-:term:`Source Directory` (e.g. ``poky``).
+:term:`OpenEmbedded-Core (OE-Core)`.
 
 .. note::
 

-- 
2.52.0

[PATCH v2 16/56] dev-manual/temporary-source-code.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/temporary-source-code.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/documentation/dev-manual/temporary-source-code.rst b/documentation/dev-manual/temporary-source-code.rst
index 977edbc3f..aecd34099 100644
--- a/documentation/dev-manual/temporary-source-code.rst
+++ b/documentation/dev-manual/temporary-source-code.rst
@@ -15,8 +15,8 @@ your changes in the form of patches.
 During a build, the unpacked temporary source code used by recipes to
 build packages is available in the :term:`Build Directory` as defined by the
 :term:`S` variable. Below is the default value for the :term:`S` variable as
-defined in the ``meta/conf/bitbake.conf`` configuration file in the
-:term:`Source Directory`::
+defined in the ``meta/conf/bitbake.conf`` configuration file in
+:term:`OpenEmbedded-Core (OE-Core)`::
 
    S = "${UNPACKDIR}/${BP}"
 

-- 
2.52.0

[PATCH v2 17/56] dev-manual/wayland.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/wayland.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/dev-manual/wayland.rst b/documentation/dev-manual/wayland.rst
index 097be9cbde..18d1bfb0a6 100644
--- a/documentation/dev-manual/wayland.rst
+++ b/documentation/dev-manual/wayland.rst
@@ -14,7 +14,7 @@ might otherwise achieve.
 The Yocto Project provides the Wayland protocol libraries and the
 reference :wikipedia:`Weston <Wayland_(display_server_protocol)#Weston>`
 compositor as part of its release. You can find the integrated packages
-in the ``meta`` layer of the :term:`Source Directory`.
+in the ``meta`` layer of :term:`OpenEmbedded-Core (OE-Core)`.
 Specifically, you
 can find the recipes that build both Wayland and Weston at
 ``meta/recipes-graphics/wayland``.

-- 
2.52.0

[PATCH v2 18/56] dev-manual/wic.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/wic.rst | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/documentation/dev-manual/wic.rst b/documentation/dev-manual/wic.rst
index 07170537b..60b08f834 100644
--- a/documentation/dev-manual/wic.rst
+++ b/documentation/dev-manual/wic.rst
@@ -276,8 +276,8 @@ existing file provided by the Wic installation. As shipped, kickstart
 files can be found in the :ref:`overview-manual/development-environment:yocto project source repositories` in the
 following two locations::
 
-   poky/meta-yocto-bsp/wic
-   poky/scripts/lib/wic/canned-wks
+   meta-yocto/meta-yocto-bsp/wic
+   openembedded-core/scripts/lib/wic/canned-wks
 
 Use the following command to list the available kickstart files::
 
@@ -342,12 +342,12 @@ 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 </poky/tree/scripts/lib/wic/plugins/source>`.
+:oe_git:`here </openembedded-core/tree/scripts/lib/wic/plugins/source>`.
 Each of these plugin files contains source plugins that are designed to
 populate a specific Wic image partition.
 
 Source plugins are subclasses of the ``SourcePlugin`` class, which is
-defined in the ``poky/scripts/lib/wic/pluginbase.py`` file. For example,
+defined in the ``openembedded-core/scripts/lib/wic/pluginbase.py`` file. For example,
 the ``BootimgEFIPlugin`` source plugin found in the ``bootimg_efi.py``
 file is a subclass of the ``SourcePlugin`` class, which is found in the
 ``pluginbase.py`` file.
@@ -527,8 +527,8 @@ This next example demonstrates that through modification of the
 As mentioned earlier, you can use the command ``wic list images`` to
 show the list of existing kickstart files. The directory in which the
 ``directdisk-gpt.wks`` file resides is
-``scripts/lib/image/canned-wks/``, which is located in the
-:term:`Source Directory` (e.g. ``poky``).
+``scripts/lib/image/canned-wks/``, which is located in
+:term:`OpenEmbedded-Core (OE-Core)`.
 Because available files reside in this directory, you can create and add
 your own custom files to the directory. Subsequent use of the
 ``wic list images`` command would then include your kickstart files.
@@ -542,8 +542,8 @@ The example begins by making a copy of the ``directdisk-gpt.wks`` file
 in the ``scripts/lib/image/canned-wks`` directory and then by changing
 the lines that specify the target disk from which to boot::
 
-   $ cp /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisk-gpt.wks \
-        /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks
+   $ cp /home/stephano/yocto/openembedded-core/scripts/lib/wic/canned-wks/directdisk-gpt.wks \
+        /home/stephano/yocto/openembedded-core/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks
 
 Next, the example modifies the ``directdisksdb-gpt.wks`` file and
 changes all instances of "``--ondisk sda``" to "``--ondisk sdb``". The
@@ -580,7 +580,7 @@ Computing (nuc) :term:`MACHINE` the
      NATIVE_SYSROOT:               /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native
 
    INFO: The image(s) were created using OE kickstart file:
-     /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks
+     /home/stephano/yocto/openembedded-core/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks
 
 Continuing with the example, you can now directly ``dd`` the image to a
 USB stick, or whatever media for which you built your image, and boot
@@ -717,7 +717,7 @@ the existing kernel, and then inserts a new kernel:
    kernel::
 
       $ wic cp poky_sdk/tmp/work/qemux86-poky-linux/linux-yocto/4.12.12+git999-r0/linux-yocto-4.12.12+git999/arch/x86/boot/bzImage \
-               poky/build/tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1/vmlinuz
+               build/tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1/vmlinuz
 
    Once the new kernel is added back into the image, you can use the
    ``dd`` command or :ref:`bmaptool

-- 
2.52.0

[PATCH v2 19/56] kernel-dev/common.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/kernel-dev/common.rst | 112 +++++++++++++++---------------------
 1 file changed, 46 insertions(+), 66 deletions(-)

diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst
index 2142d31c0..a653d897c 100644
--- a/documentation/kernel-dev/common.rst
+++ b/documentation/kernel-dev/common.rst
@@ -44,25 +44,15 @@ image and ready to make modifications as described in the
 ":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
 section:
 
-#. *Initialize the BitBake Environment:*
-   you need to initialize the BitBake build environment by sourcing
-   the build environment script (i.e. :ref:`structure-core-script`)::
-
-      $ cd poky
-      $ source oe-init-build-env
-
-   .. note::
-
-      The previous commands assume the
-      :ref:`overview-manual/development-environment:yocto project source repositories`
-      (i.e. ``poky``) have been cloned using Git and the local repository is named
-      "poky".
+#. *Initialize the Build Environment:* Follow the :doc:`/dev-manual/start`
+   section of the Yocto Project Development Tasks Manual in order to have a
+   ready-to-use shell that can execute ``devtool``.
 
 #. *Prepare Your local.conf File:* By default, the :term:`MACHINE` variable
    is set to "qemux86-64", which is fine if you are building for the QEMU
    emulator in 64-bit mode. However, if you are not, you need to set the
    :term:`MACHINE` variable appropriately in your ``conf/local.conf`` file
-   found in the :term:`Build Directory` (i.e.  ``poky/build`` in this example).
+   found in the :term:`Build Directory` (i.e.  ``bitbake-builds/build`` in this example).
 
    Also, since you are preparing to work on the kernel image, you need
    to set the :term:`MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS` variable to include
@@ -79,7 +69,7 @@ section:
    patches created for the kernel image. You can use the
    ``bitbake-layers create-layer`` command as follows::
 
-      $ cd poky/build
+      $ cd bitbake-builds/build
       $ bitbake-layers create-layer ../../meta-mylayer
       NOTE: Starting bitbake server...
       Add your new layer with 'bitbake-layers add-layer ../../meta-mylayer'
@@ -103,7 +93,7 @@ section:
    :term:`BBLAYERS` variable in the
    ``bblayers.conf`` file as follows::
 
-      $ cd poky/build
+      $ cd bitbake-builds/build
       $ bitbake-layers add-layer ../../meta-mylayer
       NOTE: Starting bitbake server...
       $
@@ -157,7 +147,7 @@ section:
    set to "qemux86-64", which is fine if you are building for the QEMU emulator
    in 64-bit mode. However, if you are not, you need to set the :term:`MACHINE`
    variable appropriately in your ``conf/local.conf`` file found in the
-   :term:`Build Directory` (i.e.  ``poky/build`` in this example).
+   :term:`Build Directory` (i.e.  ``bitbake-builds/build`` in this example).
 
    Also, since you are preparing to work on the kernel image, you need
    to set the
@@ -175,7 +165,7 @@ section:
    patches created for the kernel image. You can use the
    ``bitbake-layers create-layer`` command as follows::
 
-      $ cd poky/build
+      $ cd bitbake-builds/build
       $ bitbake-layers create-layer ../../meta-mylayer
       NOTE: Starting bitbake server...
       Add your new layer with 'bitbake-layers add-layer ../../meta-mylayer'
@@ -198,7 +188,7 @@ section:
    :term:`BBLAYERS` variable in the
    ``bblayers.conf`` file as follows::
 
-      $ cd poky/build
+      $ cd bitbake-builds/build
       $ bitbake-layers add-layer ../../meta-mylayer
       NOTE: Starting bitbake server ...
       $
@@ -210,8 +200,7 @@ section:
 
    For simplicity, it is recommended that you create your copy of the
    kernel Git repository outside of the
-   :term:`Source Directory`, which is
-   usually named ``poky``. Also, be sure you are in the
+   :term:`Source Directory`. Also, be sure you are in the
    ``standard/base`` branch.
 
    The following commands show how to create a local copy of the
@@ -237,8 +226,7 @@ section:
 #. *Create a Local Copy of the Kernel Cache Git Repository:* For
    simplicity, it is recommended that you create your copy of the kernel
    cache Git repository outside of the
-   :term:`Source Directory`, which is
-   usually named ``poky``. Also, for this example, be sure you are in
+   :term:`Source Directory`. Also, for this example, be sure you are in
    the ``yocto-4.12`` branch.
 
    The following commands show how to create a local copy of the
@@ -334,8 +322,7 @@ Modifying an Existing Recipe
 In many cases, you can customize an existing linux-yocto recipe to meet
 the needs of your project. Each release of the Yocto Project provides a
 few Linux kernel recipes from which you can choose. These are located in
-the :term:`Source Directory` in
-``meta/recipes-kernel/linux``.
+:term:`OpenEmbedded-Core (OE-Core)` in ``meta/recipes-kernel/linux``.
 
 Modifying an existing recipe can consist of the following:
 
@@ -430,9 +417,8 @@ Although this particular example does not use it, the
 :term:`KERNEL_FEATURES`
 variable could be used to enable features specific to the kernel. The
 append file points to specific commits in the
-:term:`Source Directory` Git repository and
-the ``meta`` Git repository branches to identify the exact kernel needed
-to build the BSP.
+:term:`OpenEmbedded-Core (OE-Core)` Git repository branches to identify the
+exact kernel needed to build the BSP.
 
 One thing missing in this particular BSP, which you will typically need
 when developing a BSP, is the kernel configuration file (``.config``)
@@ -677,7 +663,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using ``devtool```" Sectio
 
               ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus
                      be3a89ce7c47178880ba7bf6293d7404 for
-                     /path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack
+                     /path/to/esdk/layers/openembedded-core/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack
 
 
       You can safely ignore these messages. The source code is correctly
@@ -688,11 +674,11 @@ the ":ref:`kernel-dev/common:getting ready to develop using ``devtool```" Sectio
 
    #. *Change the working directory*: In the previous step, the output
       noted where you can find the source files (e.g.
-      ``poky_sdk/workspace/sources/linux-yocto``). Change to where the
+      ``build/workspace/sources/linux-yocto``). Change to where the
       kernel source code is before making your edits to the
       ``calibrate.c`` file::
 
-         $ cd poky_sdk/workspace/sources/linux-yocto
+         $ cd build/workspace/sources/linux-yocto
 
    #. *Edit the source file*: Edit the ``init/calibrate.c`` file to have
       the following changes::
@@ -758,7 +744,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using ``devtool```" Sectio
    your working directory to where you modified the ``calibrate.c`` file
    and use these Git commands to stage and commit your changes::
 
-      $ cd poky_sdk/workspace/sources/linux-yocto
+      $ cd build/workspace/sources/linux-yocto
       $ git status
       $ git add init/calibrate.c
       $ git commit -m "calibrate: Add printk example"
@@ -784,7 +770,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using ``devtool```" Sectio
    command from your :term:`Build Directory` in the terminal
    set up to run BitBake::
 
-      $ cd poky/build
+      $ cd bitbake-builds/build
       $ bitbake core-image-minimal
 
 Using Traditional Kernel Development to Patch the Kernel
@@ -868,7 +854,7 @@ Section.
    :term:`SRCREV` statements similar
    to the following to your ``local.conf``::
 
-      $ cd poky/build/conf
+      $ cd bitbake-builds/build/conf
 
    Add the following to the ``local.conf``::
 
@@ -888,14 +874,14 @@ Section.
    committed, and the ``local.conf`` file pointing to the kernel files,
    you can now use BitBake to build the image::
 
-      $ cd poky/build
+      $ cd bitbake-builds/build
       $ bitbake core-image-minimal
 
 #. *Boot the image*: Boot the modified image in the QEMU emulator using
    this command. When prompted to login to the QEMU console, use "root"
    with no password::
 
-      $ cd poky/build
+      $ cd bitbake-builds/build
       $ runqemu qemux86
 
 #. *Look for Your Changes:* As QEMU booted, you might have seen your
@@ -959,14 +945,14 @@ Section.
 
       To build ``core-image-minimal`` again and see the effects of your patch,
       you can essentially eliminate the temporary source files saved in
-      ``poky/build/tmp/work/...`` and residual effects of the build by entering
+      ``bitbake-builds/build/tmp/work/...`` and residual effects of the build by entering
       the following sequence of commands::
 
-              $ cd poky/build
-              $ bitbake -c cleanall linux-yocto
-              $ bitbake core-image-minimal -c cleanall
-              $ bitbake core-image-minimal
-              $ runqemu qemux86
+         $ cd bitbake-builds/build
+         $ bitbake -c cleanall linux-yocto
+         $ bitbake core-image-minimal -c cleanall
+         $ bitbake core-image-minimal
+         $ runqemu qemux86
 
 
 Configuring the Kernel
@@ -1013,10 +999,10 @@ environment, you must do the following:
 The following commands initialize the BitBake environment, run the
 :ref:`ref-tasks-kernel_configme`
 task, and launch ``menuconfig``. These commands assume the Source
-Directory's top-level folder is ``poky``::
+Directory's top-level folder is ``work``::
 
-   $ cd poky
-   $ source oe-init-build-env
+   $ cd work
+   $ source layers/openembedded-core/oe-init-build-env
    $ bitbake linux-yocto -c kernel_configme -f
    $ bitbake linux-yocto -c menuconfig
 
@@ -1063,7 +1049,7 @@ the ``.config`` file would be:
 
 .. code-block:: none
 
-   poky/build/tmp/work/qemux86-poky-linux/linux-yocto/4.12.12+gitAUTOINC+eda4d18...
+   bitbake-builds/build/tmp/work/qemux86-poky-linux/linux-yocto/4.12.12+gitAUTOINC+eda4d18...
    ...967-r0/linux-qemux86-standard-build/.config
 
 .. note::
@@ -1279,32 +1265,32 @@ Here is sample output from the :ref:`ref-tasks-kernel_configcheck` task:
 
    ---------- CONFIG_X86_TSC -----------------
    Config: CONFIG_X86_TSC
-   From: /home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/bsp/common-pc/common-pc-cpu.cfg
+   From: /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/bsp/common-pc/common-pc-cpu.cfg
    Requested value:  CONFIG_X86_TSC=y
    Actual value:
 
 
    ---------- CONFIG_X86_BIGSMP -----------------
    Config: CONFIG_X86_BIGSMP
-   From: /home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg
-         /home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig
+   From: /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg
+         /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig
    Requested value:  # CONFIG_X86_BIGSMP is not set
    Actual value:
 
 
    ---------- CONFIG_NR_CPUS -----------------
    Config: CONFIG_NR_CPUS
-   From: /home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg
-         /home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/bsp/common-pc/common-pc.cfg
-         /home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig
+   From: /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg
+         /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/bsp/common-pc/common-pc.cfg
+         /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig
    Requested value:  CONFIG_NR_CPUS=8
    Actual value:     CONFIG_NR_CPUS=1
 
 
    ---------- CONFIG_SCHED_SMT -----------------
    Config: CONFIG_SCHED_SMT
-   From: /home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg
-         /home/scottrif/poky/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig
+   From: /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg
+         /home/scottrif/bitbake-builds/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig
    Requested value:  CONFIG_SCHED_SMT=y
    Actual value:
 
@@ -1459,11 +1445,9 @@ Maintaining format compatibility facilitates converging with linux-yocto
 on a future, mutually-supported kernel version.
 
 To help you use your own sources, the Yocto Project provides a
-linux-yocto custom recipe that uses ``kernel.org`` sources and
-the Yocto Project Linux kernel tools for managing kernel Metadata.
-You can find this recipe in the ``poky`` Git repository:
-:yocto_git:`meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
-</poky/tree/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb>`.
+:oe_git:`linux-yocto custom recipe </openembedded-core/tree/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb>`
+that uses ``kernel.org`` sources and the Yocto Project Linux kernel tools for
+managing kernel Metadata.
 
 Here are some basic steps you can use to work with your own sources:
 
@@ -1597,13 +1581,9 @@ Incorporating Out-of-Tree Modules
 
 While it is always preferable to work with sources integrated into the
 Linux kernel sources, if you need an external kernel module, the
-``hello-mod.bb`` recipe is available as a template from which you can
-create your own out-of-tree Linux kernel module recipe.
-
-This template recipe is located in the ``poky`` Git repository of the
-Yocto Project:
-:yocto_git:`meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
-</poky/tree/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb>`.
+:oe_git:`hello-mod </openembedded-core/tree/meta-skeleton/recipes-kernel/hello-mod/>`
+recipe is available as a template from which you can create your own out-of-tree
+Linux kernel module recipe.
 
 To get started, copy this recipe to your layer and give it a meaningful
 name (e.g. ``mymodule_1.0.bb``). In the same directory, create a new

-- 
2.52.0

[PATCH v2 20/56] migration-guides/migration-1.4.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/migration-guides/migration-1.4.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/migration-guides/migration-1.4.rst b/documentation/migration-guides/migration-1.4.rst
index 6db2a035b8..5d8d0ffde8 100644
--- a/documentation/migration-guides/migration-1.4.rst
+++ b/documentation/migration-guides/migration-1.4.rst
@@ -82,7 +82,7 @@ Custom Interfaces File (netbase change)
 If you have created your own custom ``etc/network/interfaces`` file by
 creating an append file for the ``netbase`` recipe, you now need to
 create an append file for the ``init-ifupdown`` recipe instead, which
-you can find in the :term:`Source Directory` at
+you can find in :term:`OpenEmbedded-Core (OE-Core)` at
 ``meta/recipes-core/init-ifupdown``. For information on how to use
 append files, see the
 ":ref:`dev-manual/layers:appending other layers metadata with your layer`"

-- 
2.52.0

[PATCH v2 21/56] overview-manual/concepts.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/overview-manual/concepts.rst | 74 ++++++++----------------------
 1 file changed, 20 insertions(+), 54 deletions(-)

diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 9ca188960..757ea05cb 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -211,62 +211,28 @@ figure <overview-manual/concepts:openembedded build system concepts>`:
 BitBake needs some basic configuration files in order to complete a
 build. These files are ``*.conf`` files. The minimally necessary ones
 reside as example files in the ``build/conf`` directory of the
-:term:`Source Directory`. For simplicity,
-this section refers to the Source Directory as the "Poky Directory."
+:term:`Build Directory`.
 
-When you clone the :term:`Poky` Git repository
-or you download and unpack a Yocto Project release, you can set up the
-Source Directory to be named anything you want. For this discussion, the
-cloned repository uses the default name ``poky``.
+When you :ref:`initialize the build environment <dev-manual/start:Initializing
+the Build Environment>`, you can set up the :term:`Source Directory` to be named
+anything you want.
 
-.. note::
-
-   The Poky repository is primarily an aggregation of existing
-   repositories. It is not a canonical upstream source.
-
-The ``meta-poky`` layer inside Poky contains a ``conf`` directory that
-has example configuration files. These example files are used as a basis
-for creating actual configuration files when you source
-:ref:`structure-core-script`, which is the
-build environment script.
-
-Sourcing the build environment script creates a :term:`Build Directory`
+Setting up the build environment creates a :term:`Build Directory`
 if one does not already exist. BitBake uses the :term:`Build Directory`
 for all its work during builds. The Build Directory has a ``conf`` directory
 that contains default versions of your ``local.conf`` and ``bblayers.conf``
-configuration files. These default configuration files are created only
-if versions do not already exist in the :term:`Build Directory` at the time you
-source the build environment setup script.
-
-Because the Poky repository is fundamentally an aggregation of existing
-repositories, some users might be familiar with running the
-:ref:`structure-core-script` script in the context of separate
-:term:`OpenEmbedded-Core (OE-Core)` and BitBake
-repositories rather than a single Poky repository. This discussion
-assumes the script is executed from within a cloned or unpacked version
-of Poky.
-
-Depending on where the script is sourced, different sub-scripts are
-called to set up the :term:`Build Directory` (Yocto or OpenEmbedded).
-Specifically, the script ``scripts/oe-setup-builddir`` inside the poky
-directory sets up the :term:`Build Directory` and seeds the directory (if
-necessary) with configuration files appropriate for the Yocto Project
-development environment.
-
-.. note::
+configuration files. These default :term:`configuration files <Configuration
+File>` are created only if versions do not already exist in the :term:`Build
+Directory` at the time you source the build environment setup script.
 
-   The
-   ``scripts/oe-setup-builddir``
-   script uses the
-   ``$TEMPLATECONF``
-   variable to determine which sample configuration files to locate.
+:term:`Configuration files <Configuration File>` provide many basic variables
+that define a build environment.  To see a list of possible variables to
+configure from :term:`configuration files <Configuration File>`, see the
+:yocto_git:`local.conf.sample
+</meta-yocto/tree/meta-poky/conf/templates/default/local.conf.sample>` in the
+``meta-poky`` layer:
 
-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 </poky/tree/meta-poky/conf/templates/default/local.conf.sample>`
-in the ``meta-poky`` layer:
+Here is a list of a few:
 
 -  *Target Machine Selection:* Controlled by the
    :term:`MACHINE` variable.
@@ -371,18 +337,18 @@ figure <overview-manual/concepts:openembedded build system concepts>`:
    configurations. This type of information is specific to a particular
    target architecture. A good example of a BSP layer from the
    :ref:`overview-manual/yp-intro:reference distribution (poky)` is the
-   :yocto_git:`meta-yocto-bsp </poky/tree/meta-yocto-bsp>`
+   :yocto_git:`meta-yocto-bsp </meta-yocto/tree/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 </poky/tree/meta-poky>`
+   :yocto_git:`meta-poky </meta-yocto/tree/meta-poky>`
    layer. Within the distro layer is a ``conf/distro`` directory that
    contains distro configuration files (e.g.
-   :yocto_git:`poky.conf </poky/tree/meta-poky/conf/distro/poky.conf>`
-   that contain many policy configurations for the Poky distribution.
+   :yocto_git:`poky.conf </meta-yocto/tree/meta-poky/conf/distro/poky.conf>`
+   that contain many policy configurations for the :term:`Poky` distribution.
 
 The following figure shows an expanded representation of these three
 layers from the :ref:`general workflow figure
@@ -840,7 +806,7 @@ This step in the build process consists of the following tasks:
    :term:`PACKAGECONFIG_CONFARGS`
    variables. For information on how this variable works within that
    class, see the :ref:`ref-classes-autotools` class
-   :yocto_git:`here </poky/tree/meta/classes-recipe/autotools.bbclass>`.
+   :oe_git:`here </openembedded-core/tree/meta/classes-recipe/autotools.bbclass>`.
 
 -  *do_compile*: Once a configuration task has been satisfied,
    BitBake compiles the source using the

-- 
2.52.0

[PATCH v2 22/56] overview-manual/development-environment.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core.
Replace the poky examples for the Git section by yocto-docs.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 .../overview-manual/development-environment.rst    | 83 +++++++++++-----------
 1 file changed, 41 insertions(+), 42 deletions(-)

diff --git a/documentation/overview-manual/development-environment.rst b/documentation/overview-manual/development-environment.rst
index ab9bd084c..0402e3456 100644
--- a/documentation/overview-manual/development-environment.rst
+++ b/documentation/overview-manual/development-environment.rst
@@ -148,44 +148,42 @@ code browser is organized into categories by function such as IDE
 Plugins, Matchbox, Poky, Yocto Linux Kernel, and so forth. From the
 interface, you can click on any particular item in the "Name" column and
 see the URL at the bottom of the page that you need to clone a Git
-repository for that particular item. Having a local Git repository of
-the :term:`Source Directory`, which
-is usually named "poky", allows you to make changes, contribute to the
+repository for that particular item. Having a local Git clone of
+these repositories allows you to make changes, contribute to the
 history, and ultimately enhance the Yocto Project's tools, Board Support
 Packages, and so forth.
 
 For any supported release of Yocto Project, you can also go to the
-:yocto_home:`Yocto Project Website <>` and select the "DOWNLOADS"
-item from the "SOFTWARE" menu and get a released tarball of the ``poky``
-repository, any supported BSP tarball, or Yocto Project tools. Unpacking
+:yocto_home:`Yocto Project Website <>` and select the "RELEASES"
+item from the "DEVELOPMENT" menu and get a released tarball of the
+repositories, any supported BSP tarball, or Yocto Project tools. Unpacking
 these tarballs gives you a snapshot of the released files.
 
 .. note::
 
    -  The recommended method for setting up the Yocto Project
-      :term:`Source Directory` and the files
-      for supported BSPs (e.g., ``meta-intel``) is to use
-      :ref:`overview-manual/development-environment:git`
+      is to use :ref:`overview-manual/development-environment:git`
       to create a local copy of the upstream repositories.
 
    -  Be sure to always work in matching branches for both the selected
-      BSP repository and the Source Directory (i.e. ``poky``)
-      repository. For example, if you have checked out the "&DISTRO_NAME_NO_CAP;"
-      branch of ``poky`` and you are going to use ``meta-intel``, be
+      BSP repository, the :term:`OpenEmbedded-Core (OE-Core)` and
+      :term:`BitBake` repositories. For example, if you have checked out the "&DISTRO_NAME_NO_CAP;"
+      branch of :term:`OpenEmbedded-Core (OE-Core)` and you are going to use ``meta-intel``, be
       sure to checkout the "&DISTRO_NAME_NO_CAP;" branch of ``meta-intel``.
 
 In summary, here is where you can get the project files needed for
 development:
 
--  :yocto_git:`Source Repositories: <>` This area contains Poky, Yocto
-   documentation, metadata layers, and Linux kernel. You can create local
-   copies of Git repositories for each of these areas.
+-  :yocto_git:`Source Repositories: <>` This area contains :term:`BitBake`,
+   :term:`OpenEmbedded-Core (OE-Core)`, Yocto documentation and other metadata
+   layers. You can create local copies of Git repositories for each of these
+   areas.
 
    .. image:: figures/source-repos.png
       :width: 100%
 
--  :yocto_home:`DOWNLOADS page </software-overview/downloads/>`:
-   The :yocto_home:`Yocto Project website <>` includes a "DOWNLOADS" page accessible
+-  :yocto_home:`RELEASES page </development/releases/>`:
+   The :yocto_home:`Yocto Project website <>` includes a "RELEASES" page accessible
    through the "SOFTWARE" menu that allows you to download any Yocto
    Project release, tool, and Board Support Package (BSP) in tarball
    form. The hyperlinks point to the tarballs under
@@ -230,11 +228,11 @@ and so forth.
    ":doc:`/contributor-guide/identify-component`"
    section of the Yocto Project and OpenEmbedded Contributor Guide.
 
-The Yocto Project ``poky`` Git repository also has an upstream
-contribution Git repository named ``poky-contrib``. You can see all the
+The Yocto Project Git repositories may also have upstream
+contribution Git repositories suffixed with ``-contrib``. You can see all the
 branches in this repository using the web interface of the
-:yocto_git:`Source Repositories <>` organized within the "Poky Support"
-area. These branches hold changes (commits) to the project that have
+:yocto_git:`Source Repositories <>`.
+These branches hold changes (commits) to the project that have
 been submitted or committed by the Yocto Project development team and by
 community members who contribute to the project. The maintainer
 determines if the changes are qualified to be moved from the "contrib"
@@ -323,7 +321,7 @@ Book <https://book.git-scm.com>`__.
    software on which to develop. The Yocto Project has two scripts named
    ``create-pull-request`` and ``send-pull-request`` that ship with the
    release to facilitate this workflow. You can find these scripts in
-   the ``scripts`` folder of the :term:`Source Directory`. For information
+   the ``scripts`` folder of :term:`OpenEmbedded-Core (OE-Core)`. For information
    on how to use these scripts, see the
    ":ref:`contributor-guide/submit-changes:using scripts to push a change upstream and request a pull`"
    section in the Yocto Project and OpenEmbedded Contributor Guide.
@@ -377,7 +375,7 @@ local experimentation on projects as you develop changes or new
 features.
 
 A Git repository represents all development efforts for a given project.
-For example, the Git repository ``poky`` contains all changes and
+For example, the Git repository :yocto_git:`yocto-docs </yocto-docs>` contains all changes and
 developments for that repository over the course of its entire life.
 That means that all changes that make up all releases are captured. The
 repository maintains a complete history of changes.
@@ -390,10 +388,10 @@ locally.
 
 It is important to understand that Git tracks content change and not
 files. Git uses "branches" to organize different development efforts.
-For example, the ``poky`` repository has several branches that include
+For example, the :yocto_git:`yocto-docs </yocto-docs>` 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 :yocto_git:`/poky/` and clicking on the
+by going to :yocto_git:`yocto-docs </yocto-docs/>` and clicking on the
 ``[...]`` link beneath the "Branch" heading.
 
 Each of these branches represents a specific area of development. The
@@ -409,15 +407,15 @@ development branch in the repository. To help illustrate, consider the
 following example Git commands::
 
    $ cd ~
-   $ git clone git://git.yoctoproject.org/poky -b &DISTRO_NAME_NO_CAP;
+   $ git clone git://git.yoctoproject.org/yocto-docs -b &DISTRO_NAME_NO_CAP;
 
 In the previous example
 after moving to the home directory, the ``git clone`` command creates a
-local copy of the upstream ``poky`` Git repository and checks out a
+local copy of the upstream ``yocto-docs`` Git repository and checks out a
 local branch named "&DISTRO_NAME_NO_CAP;", which tracks the upstream
 "origin/&DISTRO_NAME_NO_CAP;" branch. Changes you make while in this
 branch would ultimately affect the upstream "&DISTRO_NAME_NO_CAP;" branch
-of the ``poky`` repository.
+of the ``yocto-docs`` repository.
 
 It is important to understand that when you create and checkout a local
 working branch based on a branch name, your local environment matches
@@ -432,13 +430,12 @@ 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 :yocto_git:`/poky/`
+tags used with the ``yocto-docs`` Git repository by going to :yocto_git:`/yocto-docs/`
 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
-``&DISTRO_NAME_NO_CAP;-&DISTRO;``. These tags represent Yocto Project
-releases.
+Some key tags for the ``yocto-docs`` repository are ``kirkstone-4.0.30``,
+``scarthgap-5.0.1``, and ``&DISTRO_NAME_NO_CAP;-&DISTRO;``. These tags represent
+Yocto Project releases.
 
 When you create a local copy of the Git repository, you also have access
 to all the tags in the upstream repository. Similar to branches, you can
@@ -449,19 +446,19 @@ The most common use is to checkout a working branch that matches a
 specific Yocto Project release. Here is an example::
 
    $ cd ~
-   $ git clone git://git.yoctoproject.org/poky
-   $ cd poky
+   $ git clone git://git.yoctoproject.org/yocto-docs
+   $ cd yocto-docs
    $ git fetch --tags
-   $ git checkout tags/rocko-18.0.0 -b my_rocko-18.0.0
+   $ git checkout tags/&DISTRO_NAME_NO_CAP;-&DISTRO; -b my_&DISTRO_NAME_NO_CAP;-&DISTRO;
 
 In this example, the name
 of the top-level directory of your local Yocto Project repository is
-``poky``. After moving to the ``poky`` directory, the ``git fetch``
+``yocto-docs``. After moving to the ``yocto-docs`` directory, the ``git fetch``
 command makes all the upstream tags available locally in your
 repository. Finally, the ``git checkout`` command creates and checks out
-a branch named "my-rocko-18.0.0" that is based on the upstream branch
+a branch named "my_&DISTRO_NAME_NO_CAP;-&DISTRO;" that is based on the upstream branch
 whose "HEAD" matches the commit in the repository associated with the
-"rocko-18.0.0" tag. The files in your repository now exactly match that
+"&DISTRO_NAME_NO_CAP;-&DISTRO;" tag. The files in your repository now exactly match that
 particular Yocto Project release as it is tagged in the upstream Git
 repository. It is important to understand that when you create and
 checkout a local working branch based on a tag, your environment matches
@@ -596,7 +593,8 @@ MIT license :wikipedia:`here <MIT_License>`.
 
 When you build an image using the Yocto Project, the build process uses
 a known list of licenses to ensure compliance. You can find this list in
-the :term:`Source Directory` at ``meta/files/common-licenses``. Once the
+:term:`OpenEmbedded-Core (OE-Core)` at :oe_git:`meta/files/common-licenses
+</openembedded-core/tree/meta/files/common-licenses>`. Once the
 build completes, the list of all licenses found and used during that build
 are kept in the :term:`Build Directory` at ``tmp/deploy/licenses``.
 
@@ -617,8 +615,9 @@ Source Definition and the effort for reviewing and approving licenses
 that conform to the Open Source Definition (OSD).
 
 You can find a list of the combined SPDX and OSI licenses that the Yocto
-Project uses in the ``meta/files/common-licenses`` directory in your
-:term:`Source Directory`.
+Project uses in the :oe_git:`meta/files/common-licenses
+</openembedded-core/tree/meta/files/common-licenses>` directory in
+:term:`OpenEmbedded-Core (OE-Core)`.
 
 For information that can help you maintain compliance with various open
 source licensing during the lifecycle of a product created using the

-- 
2.52.0

[PATCH v2 23/56] overview-manual/yp-intro.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository. This document had a lot of
reference to it, so a lot was removed. The "Reference Distribution
(Poky)" section was removed as there already was a "Reference Embedded
Distribution (Poky)" below. This section was simplified as now Poky is
just a distro, not a repo. The historical section was also updated to
mention the obsolete Poky repo.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/overview-manual/concepts.rst         |   2 +-
 .../figures/poky-reference-distribution.png        | Bin 23784 -> 0 bytes
 documentation/overview-manual/yp-intro.rst         | 155 +++------------------
 3 files changed, 21 insertions(+), 136 deletions(-)

diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 757ea05cb8..86bcd5743c 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -336,7 +336,7 @@ figure <overview-manual/concepts:openembedded build system concepts>`:
    "BSP Layer" in the following figure) providing machine-specific
    configurations. This type of information is specific to a particular
    target architecture. A good example of a BSP layer from the
-   :ref:`overview-manual/yp-intro:reference distribution (poky)` is the
+   :ref:`overview-manual/yp-intro:reference embedded distribution (Poky)` is the
    :yocto_git:`meta-yocto-bsp </meta-yocto/tree/meta-yocto-bsp>`
    layer.
 
diff --git a/documentation/overview-manual/figures/poky-reference-distribution.png b/documentation/overview-manual/figures/poky-reference-distribution.png
deleted file mode 100644
index 1be89ae68e36c6e37a4903d0688d5bd1ad36b87a..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 23784
zcmeAS@N?(olHy`uVBq!ia0y~yV7kk|z-Yt4#K6EXdFd>91_lP^VkgfK4i1jn5B(o7
zFfd4#xJHx&=ckpFCl;kLr03=5rs@_a7p11=6=&p^yl38T$H1V#;OXKRQZeVv-O?D5
zpVI6f($mT#cLfSK23RfSIl^?*VM9Ruj2kPKCsp5jIrrYnh4b#-TbYnJx0AK&u7X;J
zuBM{w?a#lPZ_S7m;Qm;-{~dpR`LpQV2K<{he^%7!Vrmg^;#kPm@aGz{1BYUZz^ax~
zPA3k<7AdYZ-U3b>idO;>Vw*rp+L&Gofz+CcL`+v`5pY_u@W3t>#TEf4Ue;@>Ae~tn
z8}uAG6k7tE8_|t0NR{6u_5aDg?mz48ML>r9wcwa^arNG{Q#<>PG;i8j8@o)F<I9!6
zB%%1i9FSSRHl~O=dg=W!z8?O^an@&527?R1;l7ggk3be&m_BI+pLLR*hi%7EcB;FT
z3f@IE!h`Gk!%hF9e0TSBX)bwno#Fr4RetZH)~3xpAy|8FqG=T<I4_iUf3{gOd3RWF
z`QwQf-?uU_9D2ijSm(~xS-W=YduuH}6+h>O&7Nxg!^_@9`QDzfWv)Tx>Al};KK}hV
z^ZGYmS%V9EcJ2-f?oT`C-2SKR+0pjhi=%dBn@;_!U+~r2?#ewi28Jp2v(nV}<-4>0
zw=c8N5Ibp?`sQ-li?$Ue8`VTg0=MS(KW3d$BK|JQw_3mAM5xKunATun<x~4Mr9^8<
zu(y<5Q4-PlG->kWr@oV~CfzXM4?8*asC9fXV=W6PnY`G&G{-deZw7b6q|b@_W6p?o
za_Q@Fc5AU^7$%)A`Fwr$vMuvBe7>?+=F*vShvU|NdHc6^zyB+XuSv@`B&GkGU0ZyM
zZQae<$FcKPt?XW%DtvEsaWwy3?cmKt+Y2{rFWQh5RM--bo%k>z|LKFQ%Ra6Dw@foz
zx>0w|o?AC(YEEB%&(^T`!KBObE|2_63(T*JiKxZ*NPNA#v*(o94*A=xnO80yym#v0
zy;BRf)^eK$UA%Hi)W`QvhK7&z-tSE8KEHn7)Y6W5a#D9j(Q;3-w?+$?x#Qkiep#@l
zZv8v{uAgh!8w8wI{0o`up3iA{zc%~W#GA8!>8d}M(_=80vm<ei_r=zIiTytq!Y-E|
z`}byvBZsk{?i&L=tKT<1i6+}#uUOGhq<22DV6VV|1^+kQ__}YI7lVko={v*t`*|-G
z?%mH2Ab;-bhTmWLUhv(L*>^5hlA&d0AS2i9DYElU&$$}-cMEI&x3aA5W*eWp`<O0M
ze|^?+zwg2IJMB)?zLY-rdI`_IdSf;Y<K$;rFAg=PvEKT#?{AEKuG5=|RX)B=8vl=7
zRAK1-W~X+FOZ;Z++pBVwm)|V#%DDY~ThnR(_46wZX1`wZC3F2}{wLknRhOzpe$@Bg
zU!u>k(9J(Q`ustk*U|lp9x8^|rs>Zs$oli`%j3h%j0`<)|Gs%kZ{5UgSpJhC!9I6O
zGaDmAPuf1^HYxXfpYyvVCLjB{;fbA1aW6B&wc`4ZhHEV{gmQ%W%UNTm+O1sbYxXv8
z(WfuR&lfW=+?aLh(Q;LduKC{|xhgVj(0S7vS^A=Bo!-vP1v$U3@-QfDxxL=nU~#Y3
zl$t+RR0@pq_AX-JiS1pjrjkC9v+q!*(binus}C~2?R}C|aBX$=d;2~5anp0`r~lJ)
zU$R{7_eW(Xj@p*zJDct|-4Js#s=xd114r+*{p+L)j6S@mX1MVE{+I6AVv48EXg*+U
z=xW^P7OHvRirHmGkM>31k2(oVefFe~!QtkHseFs`{&sj}XHGu$w)5^5^|0Q{g&!=c
zQx~k7|7smG1B2Gu_IEdK9PS95u9wjl8S-uSk{kwx1W8dYZK<C(R(c9ec{YWip=({1
zuc+(x6I{zV84d(o4Q15OJ*UfjVAqm$`zm55MW2y)HSylM)Q8jGaVTEd;cJ_8;NjKJ
zy9Ik?7hcVK!E$=BcbvoNz{7jDcrpYSUkGD*F!g!bln#fvEDQo7`%benTrjzkz_2oH
z!D^lZ5BJp1)&CN>{`AM$Yu5To<#4O_FUwIiwLQJfF1gA2wg&T*aJ!|~ZmnjXC^2_J
z_`eTvF>Kq*jnx9H#h-49-EzCk@l)}fDj#2==Cw<i4m=ep)NFXwmMIo_(S(tqWsZ^_
z!-|Z{^F5rleApG<B9O)6!N$noV05yJdF3qU?Pfj<6`K@oR<<xPJpA4L``dEnhIQrJ
zpXD%=E{}^l#V}!y(VL*EqmsE@(*@=K?~2L$7@j?QQ_Qn9eO9}k-k4_}{^!b7x7bG=
zk1bw)cV4bs{ymKO)zMdy?DIapy4kv>%Ey;!_e^(gh7*-@PEM|Is+yQRbJ>O`S5GG~
z#HxFr-Nh@z2rhMdg$}Ry{b}bnpN8~ox0@AxZ{9u5xBvBqo#F4k&ChqOVqmzr<n<~0
zTdSE<WM}3-H`uWHK1ca-y={BV@90gd{;+QA*?#$@aqC$Z=P*3@c~3OFdqq`gVfw=x
z-{!Jye{HfO_W8!o@26eQ&k9=n>P0%=g!<Rds^i{9pLP|sxBkuJaCz^1)4Cr&1VQ!S
zLO0KwiMOUnN4tM3yYP6g-=5zp?nkd!W;|T>dUnn1(7J~6S(Zg#_cmW{+iHGQuddu)
zPjha@#pFi{<-V-PTcd9O$?#hH>+daR(FH#;Zmhii=hm(T8eL2b3Z9F8^{`I;tEc(1
zH0aaoCF%b2#JOHun-;E_#{B<!Tg&tI<oj3t-}2D<|E*J7#(?Wje6&sMC&P|Y;*mbn
zGuf5Ww+99Pvr#>*zgzBGsn5aJ-U3eZGhR(Bdt5DHy=BGq`%hN{KG@gs;?>rNni)KH
zWxwS8uj=0r4y~#!tKYx($c)LyuWeZy?%vcRTl@QL&5J$nu3bx*ToqgQo7uysUDi<k
z-^|zA{}k@+XHjekI2>M9dv1r|?)lFd9VX{3mf2rW>9wLXqU^=XFGfMD_kEX5eDO2i
z`rh27xpzdmC-paj8Vw8E{Ac|Clq$Dk>z7x?`frx=Nx8hOu90e5d-qPr@8ECwm-gIz
zE`5%l1>6+jo!|C<<L(N_1N{u^t6j0TJiv*9V<9Dt7raJ%IV_yg!v2e0?u-xvLqO~G
zX}c=&E5H0pTA%jrY|if4(PbN7@3&KPSJ~J8;qc$B!fiKim258hSpNS1^?B*3SDwp>
zgihIE{U>jm0E5Gf%021JOZ#^ycyxaGcyrznVQJ5+!CfLDXO3P!bZvL*>z4aTpIaCd
z&UF8MtuDU%U0C0~X>yP2cSnb9mHa#9Xs2C_-244@`~G}Bv*q29>n@C}*^73xTIoJ}
zF1`H6wE3&E84jN2Ro=UO*~i!0%|nZ-Z$|9C#yD^C`X{Gq|Ej8K{GPYu(|Z3`+wJzP
zsZ$0w>}H&8Yva}XQGNGjjNla2b-z>>y5G=nPgU4z?Q*BLa&n2qnFl2=W-Xbu*x>!y
zwuPVlX87;_^W)IxmgMJRR?||ao%}Bw=fCLD5!;7_mQD-|ZFS2-XR}3WT-|RPwA=Z}
z-51k6#UD+7DHl`p$yEN-`~108cWMr={d``2e!Y<C^7)*bvy69XdJF97x-<8Y{Q=LV
z{~oWD|7aTMaIom=##aB3?{TZP|M@cg$L9xo?$uA)_~TIL?Ag|@PiqTk2=4c|$igYx
z-?^@^-u?O2_w7xQ>-P#ctq2U<B(W#$!i$Ng^Ipx)v43i2eJysX#;U5mmG5t^uDtk8
zM$X}A<BmTM|GjOkRZ8EMd5Vc)*}m-goeT<Eowqk-T-tUdsVntb{ke6nb9s!EYX5&<
zur>79(H$kHY@f`3xbyV%Ii4qiUhl5^Ty*=zyua&bT5sa&{$wOEPkX!nmrIHZZ9eu-
zte@kdtE(Gc#5vPkqcA@vC~(95wQ6#gzx(;lHhp@xYsSkmhLD?|&nCCs_c^1Ne=+~}
zxe4E{7B8?kIq|gfwWCizxMuk|Mw{~#UsOm@^ZIDPv~1lxDbA)tYlN<DI~(H3kYK*G
zh_Qj`q~`k_-&X%WpT2oUPQp&zTYL8Q$2~3VnqT#2$Aa%=&eI<Gxw>8tKR0uSdhF2?
zhc4@U-FSP~iwVzkW-@XHJy~~2D}L+rN4@J`&y@_@tTvH5^m?fN^(9OH`)mnY{VH-s
z_12=Do0N9*?|J*+n8(=@KB*;lHWYg_R&aaE8mY3sSNSjdN%a`#qCcNQqor=_{3zTJ
zYIu3>4Wrub{f26~f72J4T89?JJye`0rD`62R$6}EqMVeA2lq@Vnw;S<qd58DjHky}
z$Dg|Q=J%xcp~`7b%haFg*?xL<cd6pzBsCq0*}Gq=pZs3@y>WZa90gPVqmJe~tD35v
z8XoQ8oNuJ{%P%Xl`@o02iu0m!vhCZiCvM-&TqRxi=O#a>fy%*fgKzTl?_Xv<h`*Kk
ze5sjL(taP!yjwf}2bIj_UEL?XXixgdR9*EM-g5R9{^e~hFZB1<9E<+>bXDEL;^evI
zw;0UdZoT)cgZ*3O?O%WLD~{Zm(Y^f3`}J?Wyq-BF*C)<z-QPcZH|Ho+9^NrA+bTXT
zY55^D{-5RFopi-Q|Gd~<H=8@0ueg5B=5Jq8s#OKjmR&8GGHcDgs{ebp9hs}TxIXIg
z(^pGQ9p8EWyRT)!u78)5+^2qG*FN6<?n~Fays*E|x373`OyYdps-{EVUDJ&He@YlO
z6v-R<n5?b6{W;cZSLN^T(hrkYX<4S~nx1<aR)1`6QIP1zu2Yg%y`4mDcE==q+pHK|
zxO~oWYiIwP?{@6ms{6CV^ZUn`lgdjiDp!A5WcgnG<FUhg&z+Nh_s?Q?lCMLE-nN+R
zf7~~0Hc6f}obX@qe%ZM`-nBojr}M;@C7v+cD7NFI^%A!FvJH#2pLi~>zVh<oEbrO;
z$N#qNS^PfYQSZiQ`y0+WFMTFz`((q{dn^CX%-^~3WOvPv)#V)SNn2fS8tz^sn;qwM
z@3L>u`>S{NMX@j#@ch!7U;pmh{@T9WPnFy6Wv}`2d*<}H$+q@M-AgAK{Pp;=`V=Qu
zP+URq{MGBaJMJH|H?Dhf>4oBQwwIc-cbnCU{@$}^`@&g^RF}4bY7s^TfmdaZ-L~{p
z8E@I`_%zXZN`3N<+2*s8%s%tnGP>&(S(EMcs!Ax(?@n#v^~ia<R2bK?@tfVK*PNQn
zob&ly?b{Gev6qh)<X>FYtl6!g6K$^Dd0KSF=ID|adFxmh((K+!Y?e#seiIeIy8Zh4
zh|-UH13FLChu&~L_mned^E&4k6Az&nChLvQY|hOJ2$b(EdLL6cC&p@Lybh;BVOM4D
zXV!q==@V|rmfefF9_u`%zBso3q;yrxoa=tKYa?^M?5Hl+i`^|~nVRur%H8MgUOttN
zk8FxpYxPa}^5*jC<NNm(er5Q<I<r;FcgxH!Ytg57>K#gEzFy-gkRbXZzsmF9snd~5
ztJmkLpEl8R)7Thed;jyonQvCICCuLTI_D5m!j^(ddNt7+AJ$Z!e8IN<gt+W-B_my)
ztJ7zN*SUEzRh<8LLCtdm|Et@NmL2)GWZPcu>d3F&nJ%B>zFwX5C!p`y-!oeo%eueW
zEi;if-FS94UrC6%=fcU$9UtCyVtk>waqCw__0@BjOm9vu+X}8mv?lsYO1bh!O10GL
z&EC!HcC#^jm~_o|!`*p@(xY`Pwwawc7FC-3C)@A%wNsyND{(M2Bxo6G%}ScUW7f=|
z;KAk?D8iungj<7w!AnCRh=HMXdbobYm6s_c^~GWL4*pBd_n2;1GM6EQf4Y$1uYLRH
z+<&lYRR(|1^3wEhzZ+Y5>a4xR46a0P`<!|6T=jzDec3nO_AK;0x{QY*Bq!(lY4JRl
zzm{opum9@iUZc$ys}kL+dggKGt9zNbn<s4cQkr?J_2v3i-zP<_o2`_0X_qGRw&fpg
zhJD^%eSOQhgs>?yRXhWfI!&j_?lA~HC)urUe2(?_wZ2t{9V3>pdX>d7usE;$wAWk9
za7h-U=<|~sH{M+pcWSGkTafT-=a&uwA`AzE(k|tC8))xRk?>*C5}Wy`xTR>@I^MYN
zT>?&9gEr0mmw)N<i|OCZ`!WxP6!J+e7d1`(de_H};ppidl@+;X*kjAXk1Y*0|LhWS
z^R#n&(VN{fH2y7~@%vp+O3g%%5Sj89T>E>Ih1HH~Ybx^k@=S4<Q2F`5<f4RCn|81+
zHB$H8k*_bmCtgQrs*23cQ=bb=R#=2EWnNg<{A}rm!}%2q3K|u)_N~t0*8@~fZhw6G
zOY}>F9r^3$?fT!y&ai0H^zWBfE^C{`)2VyfIOy}%HB~&ae~<G#Kh(12)2e4Ps>F1E
z<_DkF{N=}5`90~~K0W0xv2$IfFP0bSTrugn`=TK2{p$jM=EUyX>++()!<=u;E7OUQ
zdK<52Y}t6nSvv4?(;-pel=-oH|5nU;B&;#t>YSnOjHJgCuW!xa-sHh-F8=A+TJso&
zxU?LfRZp&0Er~nDQ)>S5`zoJCU#Sy&<{#a@P;#4!<Ga^9y4Ihormn8o$D-I`H!0|J
z=I{SaKeMfFrxtlG>x=zfdHVN?sGgfvMHgN4?=yAf3R>9TiJp8S;7Z%3m9pjD9jBLk
zzca1z|GQ0rj7@h-WB%Vg{hLMV)ykLVrb)t5=MKv%xs`BSc)#Ppm70yRzH7YA{Yz#}
zIchBb<Gh}<=(*2b$8VY~F4K>ZG}>@JUW7S9t@+xYw@FdO8Y_P^xXl#cidgpdf5ffm
z`Ah6lWPVp3-LhSV$z|0w+yD0-EOn0&mR1NYu&+7szWg(T%PFzP*S20=`R{W0)v5)-
z-%c)1t=)Si!|H17&cbKA%9fY=7s>42_I-|F?w=dSro~-rd!^+g#9$G6ewLSr<CchP
zM!nk$CEtC>KRU}rcUr`{U3-fhUR~KzkT$pEx1a9nZIAc&+m+m1^nb>#Ek89MuaWDY
zS1lfzaG})qMd{kwWjXB+uHF^z`MN(jWx=}S1=>F&yT5p6zPJ$fYp>Sj1)KIR`o8&x
z(Y!gT)-r){hh*c9bFO{$_3NT8;Vz+FKGp)3yQj|j^xSglr_<}&Yh{CPZPodsvsSUC
zE+V*pi}d}&Hx?cZ|6lY<T*0IBjp43}$2U2*-Tza)@M}<2`O^RAwz+RBxfEJ5FD@d^
zPjj^a=egIsjm7u%?(IJ1d+>Q2FZchi{|;*N{J;4|_xtWmy&GSjcl%+NbYsyUd$ZQ4
zQ+15qPDxg8I(~jQ9~1wP{bLQM6UV~-#m~&jKA!$zBlkkf!e8-EL6zH!_<qYjL5-gO
zD|d^;_FR6jA&Sp-+t>Ejzls-neV)R0PAWUlJ5Y%qG{X61tD$eRUfiE+%|AqV?)EwF
zzP`<O@`1I#nfIS62xxZ7xW&r5>i@g@?<<u+Bb=sYpm9CeFzJ`WzZr{u|9P|QxJdmw
zMWrvS39(HAzaIW&*jYPYSXHR*n-<SPEs%x)*S!0;T~FuTyS44ll-qAA->ou@Z&=H*
z(fia&JI}z0x3`DcY+t|H&N)PAd*-tCV1H@%|MR-nrExh-5PJF6GC%DDM>>1{@(0f4
zdO30zR`&1wI^n`+`5l@QWACc<bI!9XIMDH}d0WhRaYlwI>i-NiPV9|sSX=zyg6?;}
zmbbm$Rzh#g59K??)V;eJ8O*o;31i69Z##GXy7l#b%+6%iuE~4q3$Jhc$G5I7xB0u8
z$m#X6N33tnit+j=rz?4<w3thtq2c#~?+5Qi2mdr$%NeA!yUJ&_Nm<l<#{IGtHMx!T
z4Y9Ks^>W*Kx_^DRnQin%`7mezd4bXP_s4Sn%bpd}U*VlMUphB0{>D>d&+@R+-Lhup
z+a|2?sN%l+O(F67lQUlrE6-ZLuj19myzQ&&=X(k==&N6^`*-Sp-#d=?CE3?zr9Taj
zJTF%MJLS<=S26c8k$$;ndD0SfRp(!(zMJ((cB$HG|C>en?_Tgd_r9!M#?mm0WA9}D
zNBsGlt*w)vTg#nLym#@T>Hk!t+_rCGvX;M_*aK$mFpjDYY1r7Y&NQy9@9Urai~DrH
z)d>l{{gHm>?qbgE-`Bib)yppQMe^bI7C|SD2fNR{J-sqIZ$8URnH>}TY@1A-zpM4l
znqK~6R^)^AZ4;^+)h@5I+U9G-es0D#;g(nIpnmMCFO|i=AFO`zEp&Bti<~c?%;uHx
z8v-4U@a~?Ya{S_FUJsAynZ6S~tpV#>r*?^dp?~}G`vO@8UH89~MyyWUogT|o7kB@{
z74_}@AOHI956qK4ak5dFcNfpL{hLbe1yAREYuXtVHCg&)`-SDd&z+mTr2EZvH|d(!
zfeYAr876M`O!EJIC*Ow8?^($F=7*J6|DQK1-8$=I@p41HoIlwQc7LyZ_KnrDJV}^g
zL5gWvl*28ql`<AiyT6_=J7fKe`R<jM(Zwb!^L*--$UDt{V}1JV?P(8ws(7D2dUMG)
z-;4cTCmzq~@amW~=|k`Fz|iR%&i2}rxMuoqzE{L>MdzFQ@1LhnTWQx_-u|~UV&T2{
z&)a>?kG^u1diJe0a?bPmFMsB4)veiAdRS68>xq<SUc4|fZ@T-QGh8Q+>g!tyeqGD1
zc<kx&2IIY<ESewVY}ctyTP9Pj_#ywaR`ujPPtHeI=ZT3hF3irf%X7P48Ebl^pY6~0
z^XmMT#R{_@8eXlBak_HkHPi8*i`VyDN(!8_IryJ!jpqXc{U2Ey%4~}_3QRguD`r>l
z;@_UU{d2b*S;SJCd_O+6>B4vSBmVwpPBJniWN8U6`ePp4KF>CU;gy*#`-|u9vGseC
zit;j_bZiI<o&9{@-0z=fGT-F+zOwPSbI*#|YfaXx+uQy5b2flq+wWRqHB*Dy!Mi3K
zHGbBaZn<N(&9~sn-v{}&TrCWs0k(ZxZg1X}c`LtY&PN^gh7F~1>1R*u6)a!EaNxkt
zBmWvY-a3CPOJ)>lZBL&T@-A@0*X5J{FEO}N$7Lg!w8XP%TJ-CKzZllfldIF#@vSOb
z$#UT2#_fXtJ}9+FDcZz0U6_8<%slII%gQCI(q5(+eyd-bGsX2}W~vf{K~~l&HiZb?
zw^trI)n%r6cCL7IiZjv8j$!vrj{j=2M7OqkP2SiT^*>MdM!nMM)jwkG1m3pKFi);I
zY^m6CVR}<3r&Ij2)BcRht5<i#zVvz}v3k-3{i^wMPi;0%`F!6_o0Y*-xwLfCBkhG*
zwtHtjPYQN!PVVI^f4$b7!C=jAYwNtdzkYn!sv5x7^DNnFRbph5K-QEGAqGzIk_+EI
zHFMxr`0aQ<QN7ujkGK07V@97u=8CYLjhn8YVYIGV<?!tC|K7cot7kAVOxt)h#hj_j
z=)G8DP_(+d?Vq@3>8`WY&jfC1ueh;ZiM7kAbLkaL$sN<~t=zNOm}mC4zsiB{Y+s1>
z$C#~;IB4;bO{ZdK;*#&zOzPfFUZL`<pmNXuUq6Z%7#z>deX7hJZT)4#rthzfo<8`i
zB=~m8ia)O>|61Fxzq(ld#cps2NUywHba|hg;@d4Nj$HpAdp0;T)h;{v!Tfbzrd!#(
zlP_#y^o}xK@ua$Txr)tG27@crtg}}#F&OM-oB84~|GVd^>i!XoA2-Awec{~sQmOK_
zoRrS?@>LIR-AfS;KX~&0y;It&U)dE^+L_*oNP5>4K5=*OA9jnC3?JgwOK&r{mV5E8
z`}6tsH%$HiK6v2y+=#_wvQmkS+OA`NW#_hkm(Q8<;kvX_eA}jrZPE*mdM-2+l7AEu
zl$*M{==zH@OD;TGa^cE~efxiBY+`gc{O8Ez3y+ovUiS5LI-212<jSKZ7v9`m_w5t|
z!>)DP@>CkUx(nq@co+Gr%vFD*)is@moo$s(=KK7)vDMZUEL$YEl|G&{Yr}n|nJS4=
zKDFoL&VD|({(XSx$!d+Q0a^Nqr5PJ?j5ajgJ8C8P^j^0|S;Uv)4&QcOKEH#3;m(q?
z^Xl4zSQ!rZ$Jw5#{`~lI;?|xRt@RPRTGwXEY%F-Zs;@h5-JF#C_s_58Ui;;~ROEt>
zqfOtBfU3~QBmTB^F&B2vR^(pr=ionC*V?c)i;Rg3Yt(G(`En<3_<g~;@y!y38`tXi
z)_=cy?%1IvhKF8z3uJw8x$|Rke}8;kjW3Ju?_H%=eqDQ<IR|y*K+99wS?SC4c)Q1I
z{}hGpzp!)Tx&Jd{BsRNkd2mLv-g#1VfQrVoey?+J)m5AJ3Kht$pMI-i`}%1iZzDv#
z-gw5<<bnINLeD=|>7U$NW*L?jGnHr0iNK|Q4xakB(0cEpn)9b$$M$IaKJ`&t@36I{
zdHrIsUG{}V+2SWpBr_<K);#Aguh%JmVx8MC8FdIj)ojJLt&eSPntrwatZQyoIg!8q
zE8oK%jQ(j{>A%B|2)gG8?snx0{qUx!@#gt9ABMoVPoIrGe@qK?R=W~iX7Hy#d+Ox5
z-o~1##n+duPntjd`?`NWgiWO)rYl@|!0Da5JwE<7+n2kyTH2)^zJI9iqT?@7v}nnp
z#`{a7?rVLYck}E7MuwbR-L%ZFbtRsM_C;MSUn<J4de6%D=l1DUcFVlBR2OQ$7P^`8
zfd6IrldpPiKOR2XXVU-DFG?r%f8#4=K9%XaEi`RZ{mj{<U+#Id#&PSqIU4GAjC-C}
zWK34M!TvS3P}s%N=;5)NjTVox{xqF&nyPl|6Q2vq$p)L7o+}vya&l`=oYY$Gz<XZK
z4Ak_x@?c}h^EsSzKd*KFs6646@VbwI$L*YwvNr}K2`q65bN{4u!&^-<Vv1N?_4Y$+
zqy@hl$@TJQI5Kf~afkTX{WyDassiUk4;BUoPS&leBEpxHl^GWJ=?d^HJ=Ll_Re~jU
z$HoeoLeoiW4+%Z{=)&OeDk^$qo>#@`w=a&cF)Z+kyMM;?-6}D4>y_VDF^J4pp0a()
zi{EY6rz^Bf5V_=FC3EA<lDW&X-aO=f&&nX8u0Q|q3clY{@9vnUl4uz_W5eqClg@p5
z`ttPKy|XlopQTjI_tlR(GWC1-HwNfhfPLP5wbN@#c7D8T%YQ1uO3mu$`Cv<iKWnn5
zU)sUI;(hVNO{2=AXL*-IFPPaqo4fM!HEBHtePc7VsoW`(ceP3zf7OZlbbr~jV1@;k
ztTMLzTDdcNzDO6t56kC=&Gx-9-FWx1#!XMg28HjXZPVuN)QVmF!n(bb(}}|~c$@s@
z(v){G`tjV`XBy@{U;p7+$Tqo;`5GG+EuX(O+u`_2!<n=64$D4rE8%!y@YgIn?eVTZ
zqWZU483PL2nsSY^z8_NC&Him;;mfBFq|0=s9-nr<I#q4egTFIR_-sE|CMEj+w8<O8
zfY+b)sV`-lTlaFh+1~Rv8YW81zj~#?IKgUb&mN=oH<rGi!5(}4?1sRpnT=_Bd<R$W
zKHmS8U(%xLurqV4Due1w%?s<BR(*9?{${iPX$FQVQD<*#-|=|w(cC#T(KEi!nqd0v
z#(On${tG^<BwQ*v%PVAeZ#iTz|JaM)r-jdn&HVZ<@qc8LbFa|;Jx|VyKHpb6&*0Y`
zso;4Ay7#(e?@c}#o9-6<&*P%|((>?M?{lhCywx|($PG-a`ElW*;kw(~bo17G7HbIY
z>zCN3@xR}9q5TyvQ@36fe+k7FDfxGw?=m<0na$s}@hE@UiqK-|-9J)m<oHXn_u05)
z?d-Muo6)l;cEu%|rHz}9Mg2+8{(2ZZgtE_e+tm{*eoVYyC32t1dHdrF@8q|#FU%AV
z`Mtg6!gsFq`k+M-SXNzt`WQ}E5ANSLjc?zy+~YnsD!$j=RW4M$YAg0*^MteP%RcGz
zm%dB6vug6fg}cLo&!?@mlDyq}`-|7bnk;!^<T-+Cic{TcLP}3+tUFe{bG7sDP|m3<
zo99#)Gh5|&tbFg?xX&BZcM)(%{gD5qTm8AbyzKQiSN`nNUcISa+U#acg46QT|JuVZ
z#~;1->+Z3fE8D`?uUn@6&wA<A<+atVpR4|R9(%;Co|pGd$NXHBj>eD6!QHR>^;S#P
zx`SrY6boB6ZG3)yHTwsp@5iT}diJR3Q9bXQZ~1Ku3=Q8?UOwo1J!!sI>i@9Gp07oh
zxRjO7wo$A2b%0U%7XPgx+jtd^&M)8Qm>XBLY;N8j{9&QBxEcS8E649tdA#_^?=)fh
zDeKy-6KCoe9rOO0-`6=|E$=p8cTIwXNq>movpW$F<P)x^HF(cfe7wl6W0jn(Vfo96
z=Ka%nB+VZl=)S#a@+2-Uv8Ud>UEne3Q%6tUK2`tutdpQ`!X_t^#jBFz41e(@#x@1i
z1{{sttsK1B{&K#(W0ceNf7@SIERwEe%?TFg{&)L1>!MW|_Ypmj>eCMA7yVzijFVwU
zKHvOcz74x<Vw0N7uj(s5e|c^K$KMU7(<i-K^Qz1`Coe~l^}y+qTj%fpw12VnA?v%d
zwmy?&Z<zfpO26cGbIaYy#@G4#Gxq&@wDS1wyX*edK9iMCsj5HD{-FNE_PLw?{5UE5
z`i!1V_rhK0<=-KCN+rb;W!)_A9$;W_m?FDb`_{+vJ9fJZ=e>`-8@l@w$3cS^yKCz1
zi{&LAFI%(S{`cfJOEwj+dH!Fv^iBVQXFLoHLCf2ptk|*ge5iU}SN(_kuhi0~yFH(N
z`i%F(>i8+j##*<gPLyN&W%ux}x4<g?K+muvjY8KO)qFpQCoFbh3}8^0()sOd`mJx@
zbUCdjn`QW1yji^J?!R+8K5T!&7Md>qWXacUFD~4T;bb^dbIUNz_8b@6w#w)G%2u&-
zmlR&uo^ko$6jy<1YiCbA@|4RZ=T=DE<+8cH5ez+Iez#ilxmo9Rr7NA9CU<Oih<0V*
zu_fT~%^NOm=k4~^{JAZCdYf8$&?U!%K{uYovRkd1yyU{k%L_i_-uqqjvXb+_nxy)b
z(LaK}ES}UGv+TUK+kNFV-U6#sJiK3+*&SXQ`mmMVHRSa-YqsfaYkhXjUwkG1X2aFk
zoBI97{O-(~c6f2f+vxo0wC{DXHFt{Ntyr+#H^xeC&e|<yMQ1*i#A&v_G}`sNFVOeM
z;_IxLoOj*!nr%-Nn>J<H<h1(rdG`Y+i*JAZ=Satzq^`tg*Hx4Jyqj0`o{qPdvwu6Y
zG4^Ne>;~@SEs+Wy5gY5>CO6DT$lbI3>GdO?z7;D|^46Z6aP}zc1KxLWW`FNUfA5ig
z)wtS6LVT&2K-#{=`BM}a8iYQviZC#!iiE_lIT}pW>WZG^Xmo>zsX;+fR8Vot$~^}X
z!sZ-P@N5#Q{WDc$(?i=N!$Vr<CMPHFj@?(F{OY{n>pj=vV-jLd=l<tpVtCS~5}to_
zO^39agb$O;l#aAe?TK1aUUSStC$=owR3mr0ajllE)@iF}qKn@P*7Y?9@Wwr3-`m;P
zugC6ta-Z3khHJAHC(qBzs!P4RS^VU8b=k|2^)+WM-<WuN?c{VBjrUe}&)z+ysZ{jh
zX1uS-)Drcz+`H=Q&TPJXSJyA*x4!qUfP=pS((LcP&-gLn?!5PDd1v)J_E|q%aO;!s
z<4KGE?mm9>+|DS$tzJ{@>J5r+dG|l9J*;*!X!)eL4-BU^mBj_|zFXPqdNSN)>hilB
zvn!{3-LGJ7dNU)QkJT%T*{bl{|J{%F9Gfujm|IbE@zW(=_w5#uj8_p7JubWJQ2yf^
zAs6qrZP|M|;ba=Ox5*_JGwH~@DTbl*CeB))dNujQ3;Q$+akV8=y}vJ4V2fm0m=VIm
znt7O~cDdiG@84s7D=<7rzt^>6`MsOI?drCxcCF?4WoLSBm&*)cX~RRc3t~?*mYGdn
z_V4$iZQZLxPTHHTT^VJ*dD-5xv%i_;n-$&5?R&H?*v$9Ut}nT<`XUdOuX}Hic{;ms
zk^8Gn;tUNh4sShCIIr>AGUhqC?qBBCsjXac@A5LcIZ>~^dk0xM{M(qxmbKSy{`v?f
zt@lrAgiYT!rh8?6*Xpw0`?{!3cY4f;xeFfMUAd<?k#WD;)Y>OLc9SM$uHJXeizWE%
zRkyQ;uAiC0nx#8ia{9CVUDaQIxITI!_}iM-%0_oq@Vr1h!@9(uZ*v3Z{(kpXLZ<pn
z?m_37tNo_Tnq6w1%4BfHYFmO@ippJo@v57ZuLN4U?oFtB<-bn6fT3lk=i=r2KK<H#
z-lSS}+se`nzfRkpXKnr1ziyV*x4fo$<~rU*f20rJ-E($rt<10Y9^Zezei9Qcx+^1|
zAz<69i>v=Q^=ymRS7v+5CYmAKJk|H@j%cTtsPD4hZ>0a_kxp%O4!Tfb`mrYAR!zvw
z#1$ua9hPyuYv+IW;QfPl?|05HFRP1|ow<G99Em6W(o+|0N!<4I%~@y5de+EWrJFzf
zZJ+h&xsUa-H!EIkGJ0WsRl@%GL)&g1sp9qLA9ir?mnI%N8(($yzi0LDa}Ild#j!iQ
z_!3d|J|nvKyw!>GebZ|cGJagu6TH2><YMYa?nnGb_vtUpx%!enV@d!EPtd!Aee<`~
z`=%Y(KTV54Mq%shm+J4TgI?T@ljh2Q<85vpFmbbTXvzOG>q=%P#+JO=dZnvey~LWo
zAX=)>?)UkB@gFpN4J1VEg;bhTv?j7JI8I`5?bJB5Aba}@gXE3HU*%VQ*V<G0_4$#o
z<$TsNHlO0_u_*~w@wrvE<^MaTd6N$63)Z>|GB_nZU0FRbK%rV{E(3$Y)-ShSJ&Enr
zpO>(B^`Q$dgqPfWen9&79i8P1*0J?|KHtvfcKdlwn#^6{oYRW?<7AY6&Y1LcQFUSW
zle`P>?_BMwU$OiD7OQ{DXQ{I=w5)o%WUlu0@OajR!X+P*j_#jg8z$4cO6ttY+jd1#
z>+j7ok=y#%ih+UW@ADS{vnCp!b^d0@!oaXH@dO`F&#Gg0(l1`MGs$gSb$Z(F*)P7E
zu9cf4F>T_F6}L|I%}fi`7L+>Yth~;{$D=tdge#1#_P*3ZeVcR5yz1R;zVn|f^kdpE
zYwQ2YnP=}_6%YP-Xo|1mx;k$+-Wj*=XO}#f#9pbi;MBdhvn3uSS})mJ`eDV_lSii*
zqy~4~ZkQ^}e)iqvGMD>D`?)gT$*cI>G+BA~gX!WuZMRJMrMA93*?P3t>K02x<r=%`
zp*u@&K0dtIx~ITU`cAoFuD*g+#g;|i1)^UI-gD-&(OJfjA-D2$+@sBPJ04aX+%R+V
zt{0ma8kW8_%W(*I4hosFrSOACdsySQZNcL6PFC&JJhC?a#)~@RU;X`_y3_LZOTGX4
zG`VK|JGH5<tGgEG&klc{CmyiqPD}IqyT5OT{BxTsm6&*L?S`+Op8xgUJvFU8w?CTc
zc3(!a_=^{xPETupDsq>Fae+;p``5JD>tlYd&iX!o{j@Io(2GnfX8fvL@_zS>@b+q}
z+Ps#&?wQBFR<{SUFeqr8>Gl_9=sx;r+VoBah6>e~MV-?cg*Z0dldCw!o^ZoY;?J93
zE!Q{xJw9s!!vWt~(Vr8vg$f_{?SHmg;^r>1^cep=GyMaf?qu(uZc%a}j7=eAc3a-3
zQk%-6I~Sew1lZ!v@tNzL^E8|HU|~<Xw}6v<-?8xN9NqJ5AI+#XUH$9K<O>^e@0vV*
zX|2cbVe{swbNBZ@x^eWrb!^1$XO5nq+MZ6Fwt2mZoKHu5LV3d1KJglcgY7b(cmDp@
zx69)8pBw8wTZ%ADt*=|yy>b82jr*5AowHZdi6Jg(QP_)}wfyVZ(*Er-*z>ff+mroU
z$)5e69Mt3)8m9jWc)Hwp_hWh8oZ2MOSpB8`VQXxXjNgY{diQv9i157v#tNhU52@d@
zCf{^Ry5`AmscS9iU3ckp^{$%8ipwj*<7M`hZ#cX5g0K1MA2(+%vzL!4u327wGwtTi
z@C97*M?@oTONGT>T5v6ELin?TuURdppL_nJWb2wY&Q&eDKiNL>-@H}!`|X>rUr%HI
zn}2+(ZMiW2{X0oT8Fe|!0?L{g7;<JaUY#w=r!D(A`02a)(jejbR~P==@KI#g5MA|h
zpVj|&(RW^Vr9RwOzOCxVin(F2|2ImPe2myN;fk4D;%u`u*Zt13zMm17%bpVRNxHV?
z!~B=NFV~4DnCG9mS$bsW>2-#k)1;kdWkgr!$Ol<1KmTo--SS0u_k@?NT4N(2b&Pv^
zN$$4iN3Lu>%5*kO`L4&^cYS$T@s;ada3{@Ti``>!P;9?Z(}bGdkHs=kA`A_aX6E0X
zc8cM`n%Vrx&)#m=T^y$-uFr4b$H1_?;kubS#{r|Sg@%Dl2@+N>r|vl`%phQ8`%mDv
zjQb2GFWuiI+rrf&mTYZa=qVkqtjeTwTY5^2wm^d-!|65a*LRCKHhopFKbCVdZj;@S
zyDanfzuoG|bf@ae<_eZYOgG)%dAy&hy|?#`%+hlUIX=I?D^R(<;EF2ehS&e>7k}Pf
zboI=x?U@JJ1fF?spRdfay35NYU_#KUTRyRG)*jp@eaEWw=hNglPV)_f%W6^|8|hw&
zDN_9LA?5Cwz2ZTxUM?3`*PK67^u4{LdHS6-dw--#Uef)rU?$hWYuA?<eLAHX@LMTe
zV8+>4J=xWNmLJbw>=*tg__WchJ*o^2`}3y%>dZeUw=M0;hE@L~_e2Le*)CjUpISS=
z*VJ8k+wU6<EgO@fL(13QPI|g=A_K#mIji-rw5>Oq@b?gt6NhP1?|Qw&j9V5P&0~C@
zf7uko#;~AENIpf<a(e<ZgX#lr?fnan3kNxLdd!uRHqZI8YTp;18J`#=)^weg=3u>l
zFnPo3eb<jCY?#U5AmDRrE$4!iD#5h3DjrL_)^9%f*ZuA{q1jv4Zr*fbO=cjAqd}<F
zw<&Y0O((5AC6e;_sGXkTl()MpZRdXz*M705H7F}I+eo+Ll92Ylz@pT9%iQZ$>-Xdx
zJJt8{_S=aai)OF<lE#1ZmDVmX1`WCJ6-WLt?&CO7TbO^~NDKem+Qm_i?gk1t*-tz6
z-I7mZ`#hlq8}sizyY1@45O=G0slEEHvmeY-85#cHJ^8tib;=5Zmk%->XO}&jXB(0n
z9$Rymks<Nl=5)=}`A=u3{n@U*_`P`0qD4;*FK3l|n_BfSYj?Gfxn4>EV}<7TMe&~-
zrqsGDk6l~sdG6NF<@=(3hppc=<uvmGi=F1%-}j%p_T__8@^_na!hxy&$$Tl>vX+OJ
zdZfSb+8%FQ-Zrn<(B9HJ$#BZq<Nqx49vbZryITM0^40}Q&OLcn*dnrj#{`p{rE6IZ
z^~`vozLbGScGkhuImbehi#}U8?OM*j;4owMjMZ;%y{WctJdpFQ=w-z2eyh^++rC)H
zT0i`jpH|fDaUnf?=I!fu?`-Oh{r}a_vUE?M=ZB)h9`Dy?mU2!L?%%Z9ecS!%9*-xV
z{j)e+G%F+V_1#0Ihw?X8ZmJIX?s|RY7p<$-SKlYcFWa@gICeTyZDsHK8qS7EcQ2ff
z{UbTq?dH=?hn1PzBTt*NzcO~<SdjAS)a^UP5gt<OpYDi19KHJWExkyS>d5-ru_DY7
zYiq8_Z82Dy*?-FZe|K`QDiedl*4Ovu?!SI*e`oQ}WAhHHE&F)pW%b5ybBr&SKM~sB
z{fjMX7MpJbgBRbW{tY?lS9VQLS#S2=dIS5jbF&j>A5xE$`qsF38h`M%IlB|C+(@05
zc65r@XUA-@(u&`=`%cZToAu3iHQ$d_e)s$&!{<*cc^C0nR%M#!`~!sy3|H?9EX!P&
z+aAYvT6}Byg*@wfpa1qqGW%}5!c#hXCBt17Mvk}Z?8`ej*52#6ka7QX;@d^vzTJ|&
zzCKpzqX+{-N7uXKpZ3-n9y|Z+;&jKX@{S#w*X{N?ck<+6=j%U?=x$!WXQ_m$5Yx#Y
zPd=A`S1I1ibG~ho$l$#H@+x1M&;6Cg;Y&U;a@@<|efPcU-doYWt#>}YQEp!n@$^wf
zN6~rR4^c%$6~`02Pu_QwH(k8zyLP!sY4yxkcB}j)g?{bP%G1(VczO%-#LdwwHS6c?
zzfyPe>xT8oUc0Alxxe~<#%&>+&8}&Ct8ZLSj!!(bY`&Z58SDSul5#h)g6qn^osqqF
zdi%F!`%Mp;EBe^Vnyf2$xpLvOt$XVJe41n*KBs%uqz|RXTKCOb>3*yCed3!7k1q2c
zFX7VrRXL9byufB^b<UjA?*#d;rLytuNqx++QeNWPwneL#Pwv*77Wv<Dw^*r>Qg`0E
zS>|>&t~XCCYOcJMyuI|I;#pVE*}KnOv#&_nz&UyT9;=E;uReVi{u=j=n>(`hJ#+KQ
ztgF>Ce(k*9FCJ+jY5sA>zVfW73lqw<la^U;^m?>SXVw<ojk^k)drrJ#&bQuS7-Vb|
zEGcW=(q56(`QL2aD(^#Q=6k)%aPcy~s`7lteXz#c;&&q~(tdu_QIn3y>o&`Ozu29r
zLF50KFBcE<h4N{B@}K=Yh}S4p+<iu2&Aj*T&INi0wV#_j<IT){g@3hvom&0oN~h~)
zFP)in-&^)@@KilXoGw_azIBUh!jF3b{=RWVPd-g3EwrqeI4k(VHQvK9CLOopm)WdM
ze4Q3OFUn^#(?#K%?yAxu&s9SAn_N5m?d^wJ!{{8%Cn~%P&+8e=mK~}2k-l#IkLKQw
zHJravwDOA8_v{Ee!R&i0+Om#2B$Lm$z%{<REhr@DXk_)G3S0L2i8XVq%=A3GU)W9E
z{qw=`T8|cy#XB;e|MR|BY8KMw69<|=?l7IRHZIwFT6`R0{@^z6;pP9*_dPwPrvK^T
z`g@8p=D(IzoG<H-RE{cmHf6u!NnH&gk=O33>FaH6Z^m)9%*+(M9n$hjcYn>YT_5L~
ziJq*nHrw(je!gK%<d+GPo4=&|_nC6HaCczK73JMp!TGB${qVC~*;V2CwCB_{txI3!
z!udKsSM0s=Zg=h0RsRhHMej&FzUdtr@MGVJoM)Qy&TbWJwNF-V>aLrr@>_Jto(Ie9
z!ehk+_xIMP{W-DpqH~{x?EInwC4ZN?_Gvxk59{N<`%=_4_SbpOo6|G9mkNO<Hg<_V
zP<uaH^Jc=7_mv-~yB)cdrD>+}CHJpGDd*vmQ`5ZfR|(wbb`zeS$h`lnf{MVbb+&Bv
zuN^ynF4|cu!S%y8<j(u4zJ{|a*>Y#*9o6$o*q-q|`P7-4`m?L2Gu$h-+2Semruo;l
z9h%GczOmkZYHxa(aS8)Nbac08@$3{!!-}AjH4D^>*ZkR&S@T8t;g77)`LmU_TEE$|
zbKUMXjsMSf$xSvdxf}7iSIyP(V`-#nL%-)&=AHVJh5ja4F*O)GUl-CWe@Qi7is1ma
zw^X0}3Oz@UjrtRAt5^Iee^L_rU*aRnzKL4=s?NWAJnAk@ywMpQWN+Xh%6<LB)@%B!
zr1S6Q)ooTcK59N~O~{H*b9yg-zwe{>(4_pvzI}U_f4IB;a#H{E30?;Z=G!K8-z|<`
zdBWjs+vk%p&Cah%Zd9koeqY7BZb5{fOswm_IYCdS@}yj~Z-CE37|Bn#9_ZRKFU2T+
z?yO&XGHWL7?p7>~DldE55_|SVMEl80YlYsHmHK^c-nHK+DR=_sPvNDlr{#HnUHec}
z-;!1H?vCBEw+_-1Q<&xlsBP*0tfW_=ZTkDbjOB*Oc`Y|h(pP?2k@Y7c;TO-Wmi<z9
zzR2`$WPYsQbL-`YqFdM2OgUYC{`R-7e!jX2y^P-JT$;j?KXmiFzVDsvyUN(Ouvjtw
zUe#gN2dT%7EeWf+-Mln;(d7R&Q<)E(-&LmB%bha0Y~HGk?fQGf83N|)so`@rJGE||
zVa2A!zjQKdl3rGsC@<XooFQ~ljrBgC`^%=ze3J6=T5sOelwVVqYFzdIIO{~DkK5#J
zLA;;7sK(DKn)pa@;rdmE*HnKVUnaTg>n5|;`MGc2Un-8y*~Z~8Mbd8T<EH03lTH?t
z%s%<6LuTJD(+I;!;&*1%cT7CF<@bpz4lDI89RKxZXRX&I&YB5-9kjOS+nfH2t#p5$
z=j*|ckgd7;%AbHBBWZDuy^J@Oi8;&MP&rw~nQ_vq;{0}_FgtPUf9rQJ7cTV?6<VUq
zZ2U2M!dHjM)z1a??5h3~@qa?&Vsjgl3u}LLG@88l;=O;%%i3dXJ$HTtgu8P(oUA&s
zf8mj?d3D>?G0HAKo|1LR<>pmGw)K9CfBi7A`&eST?$E@LnyO2Oc6ER4h|c{#<Non&
z-B(gF-8{B?ZTedmv+BP4I?toFlW%Oh#Jfo~epX51+mG!pR%gzc|5)IbZQcIzEo<9W
zJb1IBaR2+4cMGR=#=V!Ey<2LU`+8yTw#7H!Tz>TA^(BRs*Q<{`TX*(VO=hTV5VQR@
z?vS_KPrkAK@K*b<)T{hw;A3IceETo<A6*<yPP<Vit0%jCPtDV}C$F|&+xAx4*h9-m
z;N<eR#a0*H|1hTc%FOi%lFg_(ceA3nFNJ%F+wY&ZA3yiDNi$D6xmD2gf3~9726g@0
z{yJ>y)t>s*#LPGD^;e4Z-*!-|WMP}p<lMNM;ib#BtaiEl{`it#npHCyJYI@Em|CNe
zn7v|x$;0j-ecpzNbAC8~*=l<1v#O~J6W{!W*F#!aF18zItF5=)?4u*umuI}7vwQWC
z+Kr#h*U#JieqX(|{=2?)j&+wFZQQ#(m6M_2d*0ONOLW&)%AZ>^bC2&Meumb@nxKqH
ztgb)#4_EPR+${OfxZvrHYl=y+7jkr@**mhnYwoP&Imu$T$TNH81v^>ca^tJn{Q4=~
z3=Nax<J6cIZ7RIkTRL~C5MywhT+JEL&K;cU@t<RQOp3TZna=tmaU<=e%Hl=GTc1uT
zNl}RN=&qBw^L#h^pZ6)BAKs0sxg|g6g?9Fw=iV!tK6~Ga)ZqSPFA~Yu{c8E~6&=R|
z3+EW0{g(Ob%;x>ugP2a(tL=_-opdKcS9R5oZ`&GvZmeBg#l+BYN_hJpyQgbDKT~GD
zG22O5H$DDl*217)HLdSg$=aH?MQwcYJ$m~7fYnBC7sZ^2p1u3avt8cjRR8~R5>GZ`
zWLRakKQ`vpN~OpTkLHB!X<rz(`&@fV<odtAr<^`?JN@m+9rd*}m6LXR=kB?qS+n!c
zN9D>0v3J$!@$(F_o(Cy3EVcd7&k%0@Sa4f;``25U7w$d(vS%AJ-?3l4*RBKyPd@ur
z*<^NaiSqjwVQL>VK^@4Vx|;cKSw$`%x?f$co|<|o_xX_<oXzEDR3)>_^4PCiMrVYZ
z-dlJ1m13vy5wmGldk>lA1#NoV@%c^Cyp@;tOY`g~*XN6yIEh^$>2-f}+A3$2FgLby
zn$NZs+}gPC<n*0i*`0U=Z)c^1>{;|c>xzNtxm_(6-fevG?cz46LyM&M`_0|5;qOw@
zveMgU8dZhG(-{tZIbq)v{pD_X%7(o~el2%)Sl?n>n=QY_AU;uHeooecluZeFekXMo
zozC+1ZDLS=&%nKM^4cKj=hL*M{`0@{e)_GDOI7HH$IJ_M2{(D)6~;b_zA!7PH`*gl
z$MC`F=P@dBpWfE_zF~81GP!xep+z9;f>e5JQ0u~%kJ1lw`g%OSskzH;ahmbwa+AVB
z9$o9|zfXQ|5BhyGTB~FC;@k^T9s-=&`+U`fPINPd2%K=gT_Zb*^=VGb_K%CtvkCtY
zaC))W<lSrU6`Rt<C!gY({W@$~yi4kaIeX4ZY$+^U@b1(8yV1IQ{Bcr0{haIW$mZ_%
zxf?dCvVW5W!=5cI-uW+-wq+Q<ebslREZaTS>dzhzm#H>gwo46;cB}Dy`0OI8RJkvg
zDc)9zS<val?W{Sao<~h3|4nmiJe(}^FXr~bS2G-5l)QLaP#ReMdt<Qvv<o@MF1-6y
zJpGEKG26HQKcBx2Ei7bU;91L;{C)kk`(_1iKOgKCGwptrFa09NaLMm4-kLT?{|d3y
zCI8wVdv*8iGlKhVuNy9~wO#teAbr{UtEzQ-pY=uka8jGFUdeRB_R7omp7}B#KXT%p
z;iR_~<;(8>Jt`M=_|NpGw`Z(cwLxUh3Z2`M-cS1F7s}66cz*8F#OAfKRS}k7KF<4h
ze{mAmk)$+xy>DS&2VL!Vzcf5LzkJVpKQ*48tCxS}vcD5=oj7Byuer8({r7+MZ!50_
z{0ll%@i6}d`>D6tdsyxid3m<F7R-~C5ty>`iQ5Y6x4A;~A~SAZkEp$Q$L`+i&|0TO
zf5YTwy;`7p#_o5vM@HC*sj~an-uHiznYP!gYSY)>C*&4)o6nmYaQ(CYqmSE6GmGaZ
zub8iSU&7%-(cu}KYf_(UKl<X3Ge^r(U7i1bWPPdb!c%|tEI)7YjPGnnwseod-XclW
zOX(H)*M9k1Tugo0cr$m_CYGJw&;Jd-krxyGx9!8kSbt|z1_qgAPZ!4!^}h`lpSSI-
z?VV!qyXr;52X`4q&HX1EuI}Ic=YlJz)7RjC3IF>R*|9sxZ1G^&<avI+^IfYP>rdyl
zKAp9<(9`u`-FBWF8P+*}K4>n^O3L5rvA`ne<o3Rw?7PB`-_HACyTbCW<2K~&OEb58
zncw+r{XYr2*#GZeoLr{!!0t!w5ud}M&()>&OuJunA?g0|{cEP2V_%kebJkp~$$o1B
zmBc<rdtGefGx};<ZK{83Ztygro6(L@`Jh#%_ttjIe78hpFW;oby?@m+=B|iv`?%%a
zr}p35#lLmVxw%Y}n_<SUb+u|t4IOF;H^0~OM@6T`^ms47<NQx@-tL-{Gh1}F?t5*n
zzrFX}&HuA@DzDz4q2K&)XVGsL{k5BJeV&>6sY~`VzempI*Y&K4)vMX}l(UsD&5<(x
zm9#<c=Rd<)KXZ1!4gOuW!mL%ls>I@NKyYX;OTgt%a&LYf*APCO|3!I`LQupX&BSYy
z;~swsmwWl*PQs-5`~4T~dGb8<+2gaTrcDgUzqv5;+*^~Yo}q@Duf12cuD&bSzt`5(
zqyK-+{E$y?XZ{P2&DY*;zOC}a{@vnP8&^DX-~ToGbNqp4|9Ri)&MNqJbVp~|pCfZG
z-dfxz(LL||r29t3#s6DOH~l<NqRY?vvgFa>Yt`Aj&g=YMr(RcFE6%XP=(U3Ajnn$q
zEPjM&tqq^@U1#T-r!2)Mx9jB|Fd}86(tP=nh1Y7H9X6^wn*Pf>PuTcLgzugW8pZ!v
zW|^dYIhqjL6u=vFy5{@OefwS=I9c=i`WKD=iyFhzOn$1VFA#Cz>b5_6A$Mn5>j4>m
z(|W~8^NYNX-4o+-Q2*YS^GP@4=<QSLIy?5(9bMJ^zSYa+-|9p2-v3mdTg8&y_Rd$v
zRR8@4)6ECsc@@7mEt>Z98T08aHX-p^b1m!_y9AzD9}=~`=xyd+28BtH?ff&hrfY_;
z*>I(mrDWqVvjb-D?_BqrnlMq1@0VDv)r?IXhc=aNp0p#T(Q>zI`@3ge3<=LJ_Zhyv
zxLIuLGvnv!7oUipPO+#C<6o(ldFDm&p<OJBQm5R~xTjgj%GcZHC7t&>b;qKW^MGLR
z>0^HvmKChutm!;s&(jAkqWd@Bjr+bT*`#pB>|jTy?H4t_opZVMdy&Ydr^|fb+FrGI
zzFN6;u1w5*TdQc<FdL`GT@h10{`=T!{Os9!n@bmGs@i%q`^-!;HSmd$3%Y*GD;2uW
zg@GaD<LcLuzhqTTbFaJ+-KDldj79VOlVi8TH23VOI=I+Reev(vn?Lb=ldleTVZ>Ms
z9DZZdo|=SN(;ThlMiicT@4obF*maSwTyIoMbJv6(y*5YA(c$Q+@HdAQBy-pp9VYa2
ztyb1l+;5cWs38!fP`fwfsDf&^gW39s37>o%+lp&1&A6z3z&MEGVzRmUHjyW``b#Xf
zsxe&tD{<9yRz<xWf5ZInwC|JeckXRApRq5ZYNe0MH5ab=u^G}@a$$28-*L7%wPTg_
zO~;^3XX}n${rzsm7Cx!Pf~M)G7uP5<=)eAQ$+U2tGW#qe(PL*Ov3>R2x3of4b;-ic
zMj;NPe7TCCxSJu<4}J@ucCPxB(ZaoIf!?P-eQL~%o+i2Z&y4t15f;AFePLD`rt5i2
zhRkU`mg#ynqSkyezr#nPJh?dO&yLIeHXbwG@m|mMn0Tkl(Zcq1A8uRR+_tjxyVc&T
zr1iV+n52DaeehGL<;emqzsKP%zskN{QRKKFeaXM}{?|Vt-Q`bZt;5wBoW;)G3%z(`
z$?D!&t*d8ha(7HS+v6P^fApzM-ND&5k61Y!3N2%{7cn*jeHNQL+mOK{xcccKkv@hi
zS$2B`r`^9-_VRu9Q75s9|EFCxj<z_{khaFCS?58-C6jLXA19Vx$vU=Abx)-CtsCN8
zoYOk}KRoo^=f=YzJN+Tw|GpOj3!cAP$+9cRdSkBJ+qfM@DGBrUYp`wbVO#t2_QjTc
zm4W|y6`uR$FfmM7bIgz1Bl@EHg#drw{VM~XJ{4^#dp$9CM)?=^T`RBOGD6)j68fB3
zxGMJe*ZX^8R;9i)v}RfVZePNh|FX)=rLrey#2=mV_IQr$&WuIV^BIqB<Cr7=Zms7N
z2iH$a-eknuxc`y<b^XY^x?)e&(%*s;Z(E1yEUr7wntpBT<yA4Cr(OQ`pY`+gl5MA-
zO!AT4{qFO$?}3{qyi|35xWWfK#j3XV`8J+E<<on&P0L)nTl?z6Q03Ke<$wF^-@lPF
zo|m@uB6yAP7mJrK^&@s&-kMU!dGcSF633!fNAgpv-XC`n=DxJ4QAOK7SeQk1l7+ag
za9GUti{bN@O~0)(>1fWYpQq!_$1jmfJ$dX**YQ86*sgXRy&bmr<YV3m_u3|xeVzI5
zL+-TD`GOi5GfgH<=J(0k{kQJTgeS=+FOL)@*S(&3&D%Q4HS(0{+t<}+{*?dsIm!N%
zT}QimjfGUG>6PH^wJe$wp)-`%r-YZDN)Owx?dt80z3<+>ygcLL^v3y*6<ikEJboMB
zEw}O4?p-Ud&0{!o{mM1X6P^zlK6I~-(+{agnxi&r#<rLhT_V$Xwbxa8)fCTk%u2p;
zpuFX`&Yu3~{^_@UB$q#kw&CSj_H~gy%lYXFA<iKm(q?=Q3l;L<m7RaEE^zVe6-*9m
zIS*v#)P1eCs(i8VneWw}t)U|F5h;s1=f2SUpuSqU_3oU%oAf)|MX%djy{Dd4_4L~&
z!=o<G(&J>lJl&AnwD=u+{p-M*Ic*cJX%||tn~GKJ55IEb!QVLP)%w-@!&@$dyI1cI
z|0BbWd4|uz{=Q3VdwoLmomS+5S70$PfH!T=F!yXf%;VR-&U4XTZAqsW-iJXOIF5w4
zyi|KS<vH4FDGk3*|BlAq{$;)6*H+$pvjcnzC!1COlJyd0V6d<JYVdw-W=-J5vr{L(
zdHeUyuCr19S4?4I2=u(OY^I!_ZLZAUYQ0^vG=E&%?7ZS2*p{pi*Oz9xT{lIMw_e1G
z%GP}H{PQrkEIs{Ajrwm%-tQ;Zfj68MzPfiY;cJTtAH#RdHB<NQ@+ltu@K2RPkwrmv
zY4%+cR~y%B9cES$s~X=_tXvTnxGl$O-FmUQi;{}05dY8Ah`k`_KQVUq?wKVVy5Dcg
zI;jXTG6Xm|9-X^D#Pusv$g;;uEg}cb7YaCeObhACX{(BUDG;@+uhZ|}=MX*y``5RY
zn&?gNU9!09q?-K9zHWg-pH(>&RlKb>Z(q4~dPz#&Z@>LttUm_N-+0XJ*V)q2DK8dP
z-P|O(=YCZZhiL(5aovQRDSEzX>vK}_pj~Vw>8skZ`P~9R9QMcYEdb<z9)7Uu+}qDv
zOFnGPu}(X5Z1?;9vCrf}r|bZoJ+NWg@|Ky$tIMLkcl@5}-hN>^WD{-3vv02ZD~kSo
zyjXbF@9g{CpJuy$@9Yx(-g5lug{!KM{0+ZYuf1h*!s(@UKi@)qZqQa1A$JYw>VJEx
z81#$kV>Dww$c4_^@_qZcb$exPm~Qdd|M;@8q$<ABYsvQKduAR~o+G<wZWI6Aof|40
zmfJnM=InI7Uf@*Af5^t6`BFxk;~geM|37Qa?W%CfUVfXo-b;@S_c`|Obgz>Yd2&zh
zz%|Q)7uTKyExZxT{peHi`g602eyH}RO)xpD^kwdW-=MX&Cfinav(~@<%rx=%>$!@8
zzfSAV{}@)cb5;C{I}y+8efWBihFBjhc|ZB?+}Yov@{5l!|Ng(d{P{z}yT6%_+o!7;
zM^2oep{TN=<AOJ5mT%_Kuv1&N><_w<8@gU=-QHc5TcSc-m%duG<(B*@*SFT8u5Wk$
zSZOv%Als}n$GG^Nyod5+!I%0kYd+T5{+ng|{P$m;dFuJkd!DPDd-uiZ{d)J@d%JFZ
zzc6Lm<Lh(R&atg1oGN+y{@T~`3R6z4cHW=0Z{6xAG5%bVmhV5mvfSPF^<PHt`cT_b
zu01dBe)uu<W%hlJ(vv%?7N0(1r1tmN#_#j~zp<aYze4l-gvd3VAGdEiZ8Nj}#QH4J
z4LbjMjxsmuF)~>1>d;f#w)&_1o^m_83V*lP56_1fbakvQm-N(lkaK-OSZr2xhMMzV
zt9_<YrmK@KZ8`q>=kmAq+rRhxJ^VjrwMnLEf{<ZY?ICMbwWCT;dv<b1PX2yw#-Eqh
zyu&t6E74necj=tza+~j;tvj*fOcblmX<m67ffqsyC-jZqeOUi&K|=m+Z=P@b_b&64
z`M(!Fd$eY?E{|LD#j7hiGuRd{du<l|ul;{y(&D2pin67f9WUo@58t7hdVEXa@u+pT
zu9%*fvSZ2XhP&JLu*>c?UGg}UacW^AKf|X>#*ga%Rs1Nr%&l+s!Q{u&`VVnePx;QO
z%8B0fbdsyfc^{umQ%-*Wvak9=&7n{Bf7Ty}x!@zWY|WFB)$`^~OIsoEAYIJ+(7U7R
zMxSI({Vw~hSZSpomk^`R$RH>fed+vO=`G(b90{=6P&(gpHCyYB?vA_7-|zI)KI5Bf
zvLW_(Alv5fjQOs`x1U#6-M5|5^!r)$kNCR{O!v}0th~Sb+#S2KyMCCxyZG?Z6TiFK
zQ$ByGU9%{Ap7Y$==$`1>=NE1AzWKB7i8!<0@<6=X<+pn8TlpjRWVn?2Z-2CN%BOFC
z7RSCiX0~!#kk0C}c6YvX>27d#$=JB2tv$%k?beZ#(%1fc-msb7(XhHWa&ow`*434-
z-o0^T5a|yVPr3K(b+Oylv%i(T7cww3XuS|(U|7Jli-mz<MUx&Q1H-BX-n15u@v3T8
zsJ}nc+V<J|%U!9a+l^9dPK%%Rs>n!vB4J$A!z^xI_)S40?PX+CCja8i%NYVTdF}E3
zwdGrWr1|O{VbSH6X2r#1KU94BYSGSJ5^c8eH*YpCm{GY)N^7dIbu|}*>gprAk6c}H
z^-H<-x~p}6OqKWEP-5p-Z+0}6SR(QN8Y9C$qniD6_3)ectccY~&pZErzusSDzl!~5
z*xE<0-e@k^@<k`QYT4SeKQhw!nHV&VH1w5z+8g9B-KTc()p(;b^96VQ`f>D%Pr5(j
z(#oAP_uTQltz2zYEx_O~u~43!jxja>i3G*Uo#M7%AKdzBJ!#Fkd4~<NbFM5{Zr^iq
z-}&v&kDSdg%(#|6t$J^feL5pUfYOUe)fa>L*UsLr9QaU=k>Nq&rxT@}re;|Ilkd&{
zn)}awtM>jI<=;AW<$H1hR~Mh%kSVQq`^)U-`=x(WMR=^QI{5e3Ig80frRR?u`^}&C
z+wu3a{NB4W=M@&jeLq$!b@g4`_J6lG_oclkU!U!5YrFaR>C#o@{JfQ)=aydAN$Tyb
z`g^iZ_*a?q)vcBP-wF4r+)}y!%e*8z=gMo|UA~exl3kV`tKC&optJPBcMF*x*RGlO
z>%YCf#{chud9ijH1>zf3<!9en817Lp|Jq(L`MnFfMLwMRJBO9QfwTI_E*F<gkNu}g
z?s~X;vGs2Cp89mht%=e8`f)cNU6^uoqq_b7l#7p*>uk0@`EamstGNH{`Bw_gOqejC
ze$V#0@Fz>A&0Dv1*V*5h5BCLom!IeQQFmrr%kFiHQs)18vY54h@6OL}F8%eEdMo+s
z=QWpDmFK6PW+neC|J1ei{q{RXe>W><roW4;zjsqc@buT!j*Iur-j(*cV}a;r^SHBm
zFKqkR{7wi8p6s)JWmj?6oV|Z<@cVXu?pvyVk37*loz;7<_}A>I|36v$sh;Ms?XI@v
z_d+oS2Gz4iZ!%jn?u=R<wlHqiNr9N<P7aH=iJqNh^KVN0t#d#2y4TqjKc0L}+f?wR
z*SWl!uj{^Sh_M&6{Bv8k&}{RxD!rANPTPL$zHgc4d+Yz^wO^m?O68q(rS4m6m-P1e
zr}+en6K)^7ddKC+|CwgT9#$u<TDvj+e#lbazYLo@HXagwdMRmL>}ib$wtQ^=G;b=2
zy7)B4-nyp0SW;z&yZd8~-?4h}_8X#a`S5-<%ebWQ=%>{2Bhym8dwtSxoyW@H&{-|A
z+oflno1mbfM6X-8xZp(-ao_DP&6@p>oH?IvR=)eQTlAlmcP3w|laVc5^LUHy-@m@$
zX62R7X6S0CRXv}$`Fzx!c`x>V`hD!@whJbL7j-SeVqILer$v`;jK42c?b5R>`fvuD
z@Aj8`_Z}xC?Dk*Q`B(4S>G({x&D~|$!kfF*7J2>)fA?I6fx+w6;tKiWjB7&{bM)uV
z&--f|?6Su5;>C^TrJJXFhb1iwb@?(!TC<Jo>fW<Sdv{b`?ko{3esJNexBu}q7JF6|
zhnmmd@T@JDyI=j*m)Yv(`hF|q;_m89Dz3YFjQQj)-KSqBZJp-k&uY3g+WtQe+kCaw
zed_z?%m|&$xAeufE5_c}qYk|(Klv%|M#%5V(?@kCzPa&tcHL>Q=D*ryzi-V42b9YC
z=@t)!Y;q3mR<?U3WfX7TwX$mVOYbIW^X&NNlgsCGea$mW{?)SaVLZR=x9?i1HriAE
zKIS`@`|LvC<6nF~R%AZly}P%l|NOoD$BSb{il?e?-k<UP((8{mul_TvbF^K*N%7~k
z^?|DYd6rH1V|-)3`u}T;^`~dte7Cgm<4s4__d<6{o_yG*@Bd=Q)$8khGWUN{6D*$l
zXZ?-$+4Z0_=zIAq`^)+$mvwe^hNhdHT~=&n*PLT&mQ`^7$wle=d?wb_Q`~!0Pa73}
zYI{4;cCIZ4!-5k#`k5IRLJro>nUu8V)A`8Tb8T4|82CljO=n<W2)&@nz~CTS!pXo8
zz#7ZMz!2g{gz!mcmD0Z*T=O2*@lO9UFZj!3<3-1>aeV(=llNiW86}xt!mAk>9tgx1
z$$$B>L;ha<a^GGK`|}0+gJcgY+5LNT{B`{!_xgoK-~84-m3%k-d-&NEizQVz2s1Ef
zJ=$5@dg@2+v*Pu>KaMIrlKYX8d%oqx<lSa_u0Nc<`2M+{i&n4S=(5cugojh>wUSa2
z->MgpM%4@q3*^>K7dbR-L(Q=z@j6POZF$k#-Y?fLbE*Fy`u&oU=jrzPVvWD&)=s`~
zQhwjBs14ye=EuLUGhP&&tE99jeO|QL>h!&SPi+tX-Lrdpee%_h(z~AA%jKN=>Ei-(
zC$HAuKll77y0Wvx_WiQ0_BSlbkKe1b{&w#6mKD*wo0qJUeDz%N-S_R16P?+ve&PAf
zFK1d?e&-wK;rSZE@19?OzIA=l`(2SqJ9pK+nQ-A!Wm};^XT;?CSr(h-mG6kZDPHAk
zH7Vol=8nbAebaV*&thP>Bfe{ifaLN2#YXNfQu{u5%~-Ccq_;1(ecNgkrSNb0r~b;h
zpV@Wv`l~Osdkb4<f6PAKSDPNbORwtDvP{|EdN=E~UD?cBy;o#f<%8FmbJ=tD&-s1X
zD(&rbb?ve@QFrIe-B5SsO6tdLHnZo+++SAT-S#)i<jwueHz#NB)c?Qh&*QaGy$;TP
zfA;aue|uf~Rh2`m{7%X3NjJW1o&LGx?9Ej9T*LOQTn6{$)XpAM`E^xZ?fc9v|DF1x
zJyuK2y#K%Y=hQo@GP1jlx9>U*@`?JcC--tBudjRF(NXQXKd8KJeaxxQFM@)e`=`__
zH#)U#_TGXMJ666w|1LI4CG+YXWAogTx9x8i#i~45yD|9qUJJXd0O7?;*2Zp8`*%(=
zZtb&mQubd@C)(D!s^sPSgw2cns-2#^$p5&@{C|Hx%-mwX&U%OW%+JYJKIQ*^r?2$r
zZvNBh+1K~~oin}T>7Rc$-q@eh6Wy0^d<yI8MPemiMLeTSpFe10Qt$M>Wt^VBt0RBE
z|FyL<cGSGye`w2{zroygORWC|^!YI|Ea3Q2cXF@fo!ZkgU5bqKV!bzaPIq)UGO0q-
z)8)wKrtN`w9UUF<Q$MX!O45qI?5<+^)+s2>Z|4nfGr`VonNKb$?~1N3(!am+NRXw)
ziD2Q?(UJZWv#0rZ-;=g1{U`go@_JGIp9KHCwO$zonP*=-eXOb!w6b!;ZVB5{l^sj&
z*6yl5>)`Ke(!b!>zD-KDZx1cKFU&nlMN#$lEMFHb^DpJ%hQC;@YU=;i@9yX@{p-}&
zzQ$apZiN>g*yS%KIqkUqHtcrl<G|DZR6p}?mAZVvd2`HtqvXS^f|~N*awd2_a&dWb
z=w-3_7b!dQ^RhdXl;Wn=-0@k;EN6ToGJ5I1#mh@H%U`cvy~}mA#2c;Mt}ZUdQZ6oA
zlw!gP40mTJ&05yk@hqwAOM3aoH$O}Ey3OqQ?7ptEBYY`W<FY0-&W}H@UROxkU8i?b
zsjlrz_VdZ_*Cc#d6Y@YYS+iaK)J07O1`)>CAP(oFdCqR<E8iYwHoP45HR7hig~vf(
zI=RCH-|Gd()m;kCtN*F|c6oSIe~sCLPs?&8mF~@r<NRh&Ve|Le<<#=ry&DQHZqHkr
zwR`z-_xU#p7u|aEH*qTW{Vz{`nEhS8v!f&99`Evh20Owgy6xMzH~#gObglS%TTEk*
z?7rN<CTPw*XG!8@#$KDUcfH+n3?i~0R~P);b|>01>SYsu=Dj|<DTjj@7&Msn#RqBh
zzsg@b*StDnvsHiU|FREHI=k~i=XF(-f4viVxAuR>uH(D=vnOxOcaQ0tUH_Y3-8bju
z%FeKLe@~cxuC|NS&HTHjHF){jdj+Rd*Mx6gweI`o)OX*#ll<P>&kwrt|Hh|^?}q;A
z|2Em0{r+YUw~y6-(bV@=zg`FW|B`+b=J)?$M#AroO*_3UtV;U%OZ%@fFzoQ3weEH6
zes9T%tNY`9&b|>4eD%ihoky(wqO|YK*Csgr{`Q5-$g*0hqa$LIj<9<E4Y`|_Z#FY9
zboIPOD)aAG|NXCdx9-)_l5~DXh6Bz`$dW`?2qaY>dgtU8Wbi26jI_+uG@onBaV7QS
zHmhnDh6D4zG?aR}>^-%3-yO^6cS6(onU-$l<u3Wg!O&pue7W@QO=AWIhK>(^K^;Io
fk~)B0|C#J21=sCy5{Y17U|{fc^>bP0l+XkKwQa?z

diff --git a/documentation/overview-manual/yp-intro.rst b/documentation/overview-manual/yp-intro.rst
index fe80e18796..85e78dc574 100644
--- a/documentation/overview-manual/yp-intro.rst
+++ b/documentation/overview-manual/yp-intro.rst
@@ -264,10 +264,9 @@ with the string ``meta-``.
    ``meta-``, but it is a commonly accepted standard in the Yocto Project
    community.
 
-For example, if you were to examine the :yocto_git:`tree view </poky/tree/>`
-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
+For example, if you were to examine the :oe_git:`tree view </openembedded-core/tree/>`
+of the ``openembedded-core`` repository, you will see several layers: ``meta``,
+``meta-skeleton``, and ``meta-selftest``. Each of these repositories represents a distinct
 layer.
 
 For procedures on how to create layers, see the
@@ -385,7 +384,8 @@ Yocto Project:
 
 -  *AutoBuilder:* AutoBuilder is a project that automates build tests
    and quality assurance (QA). By using the public AutoBuilder, anyone
-   can determine the status of the current development branch of Poky.
+   can determine the status of the current development branch of the core
+   repositories (:term:`OpenEmbedded-Core (OE-Core)` and :term:`BitBake`).
 
    .. note::
 
@@ -437,12 +437,12 @@ Here are components associated with the :term:`OpenEmbedded Build System`:
    You can learn more about BitBake in the :doc:`BitBake User
    Manual <bitbake:index>`.
 
--  *OpenEmbedded-Core:* OpenEmbedded-Core (OE-Core) is a common layer of
+-  *OpenEmbedded-Core:* :term:`OpenEmbedded-Core (OE-Core)` is a common layer of
    metadata (i.e. recipes, classes, and associated files) used by
    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 </poky/tree/meta>`.
+   OpenEmbedded-Core. You can find the OE-Core metadata in the OpenEmbedded
+   :oe_git:`Source Repositories </openembedded-core/>`.
 
    Historically, the Yocto Project integrated the OE-Core metadata
    throughout the Yocto Project source repository reference system
@@ -455,34 +455,10 @@ Here are components associated with the :term:`OpenEmbedded Build System`:
    Project objective of achieving a smaller number of fully featured
    tools as compared to many different ones.
 
-   Sharing a core set of metadata results in Poky as an integration
-   layer on top of OE-Core. You can see that in this
-   :ref:`figure <overview-manual/yp-intro:what is the yocto project?>`.
-   The Yocto Project combines various components such as BitBake, OE-Core,
-   script "glue", and documentation for its build system.
-
-Reference Distribution (Poky)
------------------------------
-
-Poky is the Yocto Project reference distribution. It contains the
-:term:`OpenEmbedded Build System`
-(BitBake and OE-Core) as well as a set of metadata to get you started
-building your own distribution. See the figure in
-":ref:`overview-manual/yp-intro:what is the yocto project?`"
-section for an illustration that shows Poky and its relationship with
-other parts of the Yocto Project.
-
-To use the Yocto Project tools and components, you can download
-(``clone``) Poky and use it to bootstrap your own distribution.
-
-.. note::
-
-   Poky does not contain binary files. It is a working example of how to
-   build your own custom Linux distribution from source.
-
-You can read more about Poky in the
-":ref:`overview-manual/yp-intro:reference embedded distribution (poky)`"
-section.
+   Nowadays, the :term:`Poky` **repository** is no longer updated as
+   :doc:`bitbake-setup <bitbake:bitbake-user-manual/bitbake-user-manual-environment-setup>`
+   became the preferred way of setting up the repositories in order to build the
+   :term:`Poky` distro.
 
 Packages for Finished Targets
 -----------------------------
@@ -631,103 +607,18 @@ Reference Embedded Distribution (Poky)
 ======================================
 
 "Poky", which is pronounced *Pock*-ee, is the name of the Yocto
-Project's reference distribution or Reference OS Kit. Poky contains the
-:term:`OpenEmbedded Build System` (:term:`BitBake` and
-:term:`OpenEmbedded-Core (OE-Core)`) as well as a set of
-:term:`Metadata` to get you started building your own distro. In other
-words, Poky is a base specification of the functionality needed for a
-typical embedded system as well as the components from the Yocto Project
-that allow you to build a distribution into a usable binary image.
-
-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 </poky/tree/>`.
-
-.. note::
-
-   If you are interested in all the contents of the
-   poky
-   Git repository, see the ":ref:`ref-manual/structure:top-level core components`"
-   section in the Yocto Project Reference Manual.
-
-The following figure illustrates what generally comprises Poky:
-
-.. image:: figures/poky-reference-distribution.png
-    :width: 100%
+Project's reference distribution or Reference OS Kit. This reference
+distribution is represented by a :term:`DISTRO` configuration file found in
+:yocto_git:`meta-poky </meta-yocto>`.
 
--  BitBake is a task executor and scheduler that is the heart of the
-   OpenEmbedded build system.
-
--  ``meta-poky``, which is Poky-specific metadata.
-
--  ``meta-yocto-bsp``, which are Yocto Project-specific Board Support
-   Packages (BSPs).
-
--  OpenEmbedded-Core (OE-Core) metadata, which includes shared
-   configurations, global variable definitions, shared classes,
-   packaging, and recipes. Classes define the encapsulation and
-   inheritance of build logic. Recipes are the logical units of software
-   and images to be built.
-
--  Documentation, which contains the Yocto Project source files used to
-   make the set of user manuals.
-
-.. note::
+.. warning::
 
    While Poky is a "complete" distribution specification and is tested
    and put through QA, you cannot use it as a product "out of the box"
    in its current form.
 
-To use the Yocto Project tools, you can use Git to clone (download) the
-Poky repository then use your local copy of the reference distribution
-to bootstrap your own distribution.
-
-.. note::
-
-   Poky does not contain binary files. It is a working example of how to
-   build your own custom Linux distribution from source.
-
-Poky has a regular, well established, six-month release cycle under its
-own version. Major releases occur at the same time major releases (point
-releases) occur for the Yocto Project, which are typically in the Spring
-and Fall. For more information on the Yocto Project release schedule and
-cadence, see the ":doc:`/ref-manual/release-process`" chapter in the
-Yocto Project Reference Manual.
-
-Much has been said about Poky being a "default configuration". A default
-configuration provides a starting image footprint. You can use Poky out
-of the box to create an image ranging from a shell-accessible minimal
-image all the way up to a Linux Standard Base-compliant image that uses
-a GNOME Mobile and Embedded (GMAE) based reference user interface called
-Sato.
-
-One of the most powerful properties of Poky is that every aspect of a
-build is controlled by the metadata. You can use metadata to augment
-these base image types by adding metadata :ref:`layers
-<overview-manual/yp-intro:the yocto project layer model>` that extend
-functionality.
-These layers can provide, for example, an additional software stack for
-an image type, add a board support package (BSP) for additional
-hardware, or even create a new image type.
-
-Metadata is loosely grouped into configuration files or package recipes.
-A recipe is a collection of non-executable metadata used by BitBake to
-set variables or define additional build-time tasks. A recipe contains
-fields such as the recipe description, the recipe version, the license
-of the package and the upstream source repository. A recipe might also
-indicate that the build process uses autotools, make, distutils or any
-other build process, in which case the basic functionality can be
-defined by the classes it inherits from the OE-Core layer's class
-definitions in ``./meta/classes``. Within a recipe you can also define
-additional tasks as well as task prerequisites. Recipe syntax through
-BitBake also supports both ``:prepend`` and ``:append`` operators as a
-method of extending task functionality. These operators inject code into
-the beginning or end of a task. For information on these BitBake
-operators, see the
-":ref:`bitbake-user-manual/bitbake-user-manual-metadata:appending and prepending (override style syntax)`"
-section in the BitBake User's Manual.
+Poky has a regular, well established, six-month release cycle detailed in the
+:doc:`/ref-manual/release-process` of the Yocto Project Reference Manual.
 
 The OpenEmbedded Build System Workflow
 ======================================
@@ -869,21 +760,15 @@ helpful for getting started:
 -  *Poky:* Poky is a reference embedded distribution and a reference
    test configuration. Poky provides the following:
 
-   -  A base-level functional distro used to illustrate how to customize
-      a distribution.
+   -  A base-level functional distro (:term:`DISTRO`) used to illustrate how to
+      customize a distribution.
 
    -  A means by which to test the Yocto Project components (i.e. Poky
       is used to validate the Yocto Project).
 
-   -  A vehicle through which you can download the Yocto Project.
-
    Poky is not a product level distro. Rather, it is a good starting
    point for customization.
 
-   .. note::
-
-      Poky is an integration layer on top of OE-Core.
-
 -  *Recipe:* The most common form of metadata. A recipe contains a list
    of settings and tasks (i.e. instructions) for building packages that
    are then used to build the binary image. A recipe describes where you

-- 
2.52.0

[PATCH v2 24/56] ref-manual/classes.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/ref-manual/classes.rst | 34 ++++++++++++++++++----------------
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index 2e219a59c..ef05372f0 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -9,12 +9,13 @@ amongst multiple recipe (``.bb``) files. To use a class file, you simply
 make sure the recipe inherits the class. In most cases, when a recipe
 inherits a class it is enough to enable its features. There are cases,
 however, where in the recipe you might need to set variables or override
-some default behavior.
+some default behavior. A class can also be inherited globally (in every recipe)
+with the :term:`INHERIT` variable.
 
 Any :term:`Metadata` usually found in a recipe can also be
 placed in a class file. Class files are identified by the extension
-``.bbclass`` and are usually placed in one of a set of subdirectories
-beneath the ``meta*/`` directory found in the :term:`Source Directory`:
+``.bbclass`` and are usually placed in one of the following subdirectories
+of a :term:`layer`:
 
   - ``classes-recipe/`` - classes intended to be inherited by recipes
     individually
@@ -28,9 +29,9 @@ in :term:`BBPATH` using the same method by which ``.conf``
 files are searched.
 
 This chapter discusses only the most useful and important classes. Other
-classes do exist within the ``meta/classes*`` directories in the Source
-Directory. You can reference the ``.bbclass`` files directly for more
-information.
+classes do exist within the ``meta/classes*`` directories of
+:term:`OpenEmbedded-Core (OE-Core)`. You can refer to the ``.bbclass`` files
+directly for more information.
 
 .. _ref-classes-allarch:
 
@@ -338,8 +339,8 @@ The :ref:`ref-classes-cargo_c` class can be inherited by a recipe to generate
 a Rust library that can be called by C/C++ code. The recipe which inherits this
 class has to only replace ``inherit cargo`` by ``inherit cargo_c``.
 
-See the :yocto_git:`rust-c-lib-example_git.bb
-</poky/tree/meta-selftest/recipes-devtools/rust/rust-c-lib-example_git.bb>`
+See the :oe_git:`rust-c-lib-example_git.bb
+</openembedded-core/tree/meta-selftest/recipes-devtools/rust/rust-c-lib-example_git.bb>`
 example recipe.
 
 .. _ref-classes-cargo_common:
@@ -602,8 +603,9 @@ inherited globally from a configuration file::
 
    INHERIT += "cve-check"
 
-To filter out obsolete CVE database entries which are known not to impact software from Poky and OE-Core,
-add following line to the build configuration file::
+To filter out obsolete CVE database entries which are known not to impact
+software from :term:`OpenEmbedded-Core (OE-Core)`, add the following line to the
+build configuration file::
 
    include cve-extra-exclusions.inc
 
@@ -827,7 +829,7 @@ See these variables for more information:
 :term:`PV`,
 
 For more information on the :ref:`ref-classes-externalsrc` class, see the comments in
-``meta/classes/externalsrc.bbclass`` in the :term:`Source Directory`.
+``meta/classes/externalsrc.bbclass`` in :term:`OpenEmbedded-Core (OE-Core)`.
 For information on how to use the :ref:`ref-classes-externalsrc` class, see the
 ":ref:`dev-manual/building:building software from an external source`"
 section in the Yocto Project Development Tasks Manual.
@@ -1009,7 +1011,7 @@ this class is controlled by the mandatory :term:`GO_IMPORT` variable, and
 by the optional :term:`GO_INSTALL` and :term:`GO_INSTALL_FILTEROUT` ones.
 
 To build a Go program with the Yocto Project, you can use the
-:yocto_git:`go-helloworld_0.1.bb </poky/tree/meta/recipes-extended/go-examples/go-helloworld_0.1.bb>`
+:oe_git:`go-helloworld_0.1.bb </openembedded-core/tree/meta/recipes-extended/go-examples/go-helloworld_0.1.bb>`
 recipe as an example.
 
 .. _ref-classes-go-mod:
@@ -3471,10 +3473,10 @@ is one reason we don't use static linking for our :ref:`ref-classes-native`
 binaries.
 
 With this class enabled, a tarball containing a pre-built C library is
-downloaded at the start of the build. In the Poky reference distribution this is
+downloaded at the start of the build. In :term:`OpenEmbedded-Core (OE-Core)` this is
 enabled by default through :oe_git:`meta/conf/distro/include/yocto-uninative.inc
 </openembedded-core/tree/meta/conf/distro/include/yocto-uninative.inc>`. Other distributions that do
-not derive from Poky can also "``require conf/distro/include/yocto-uninative.inc``"
+not derive from :term:`Poky` can also "``require conf/distro/include/yocto-uninative.inc``"
 to use this. Alternatively if you prefer, you can build the uninative-tarball
 recipe yourself, publish the resulting tarball (e.g. via HTTP) and set
 :term:`UNINATIVE_URL` and :term:`UNINATIVE_CHECKSUM` appropriately. For an
@@ -3516,7 +3518,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 </poky/tree/meta/classes-recipe/update-alternatives.bbclass>`
+:oe_git:`update-alternatives.bbclass </openembedded-core/tree/meta/classes-recipe/update-alternatives.bbclass>`
 file.
 
 .. note::
@@ -3549,7 +3551,7 @@ that contain system services that should be run under their own user or
 group, you can use these classes to enable creation of the user or
 group. The :oe_git:`meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
 </openembedded-core/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb>`
-recipe in the :term:`Source Directory` provides a simple
+recipe in :term:`OpenEmbedded-Core (OE-Core)` provides a simple
 example that shows how to add three users and groups to two packages.
 
 The :ref:`useradd_base <ref-classes-useradd>` class provides basic functionality for user or

-- 
2.52.0

[PATCH v2 25/56] ref-manual/images.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/ref-manual/images.rst | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/documentation/ref-manual/images.rst b/documentation/ref-manual/images.rst
index c9d898926..94e412de3 100644
--- a/documentation/ref-manual/images.rst
+++ b/documentation/ref-manual/images.rst
@@ -26,9 +26,8 @@ image you want.
 
        INCOMPATIBLE_LICENSE:pn-your-image-name = "GPL-3.0* LGPL-3.0*"
 
-From within the ``poky`` Git repository, you can use the following
-command to display the list of directories within the :term:`Source Directory`
-that contain image recipe files::
+From within the :term:`OpenEmbedded-Core (OE-Core)` Git repository, you can use the following
+command to display the list of directories that contain image recipe files::
 
    $ ls meta*/recipes*/images/*.bb
 

-- 
2.52.0

[PATCH v2 26/56] ref-manual/structure.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core
in most cases.

Add a introductory directory layout at the top that is reflected in the
following section. This document no longer uses Poky as its source
directory, so all paths are explicitly mentioned, to highlight the
separation between core components. This lead to some re-organization of
some sections.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/bsp-guide/bsp.rst        |   4 +-
 documentation/ref-manual/structure.rst | 169 ++++++++++++++++++++-------------
 documentation/ref-manual/terms.rst     |   2 +-
 3 files changed, 105 insertions(+), 70 deletions(-)

diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index 4c0939ab0..67f61b7b2 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -81,7 +81,7 @@ directory of that Layer. This directory is what you add to the
 ``conf/bblayers.conf`` file found in your
 :term:`Build Directory`, which is
 established after you run the OpenEmbedded build environment setup
-script (i.e. :ref:`ref-manual/structure:``oe-init-build-env```).
+script (i.e. :ref:`structure-core-script`).
 Adding the root directory allows the :term:`OpenEmbedded Build System`
 to recognize the BSP
 layer and from it build an image. Here is an example::
@@ -221,7 +221,7 @@ section.
       Checking connectivity... done.
 
 #. *Initialize the Build Environment:* While in the :term:`Source Directory`,
-run the :ref:`ref-manual/structure:``oe-init-build-env``` environment setup
+run the :ref:`structure-core-script` environment setup
 script located in :term:`OpenEmbedded-Core (OE-Core)` to define the OpenEmbedded
 build environment on your build host. ::
 
diff --git a/documentation/ref-manual/structure.rst b/documentation/ref-manual/structure.rst
index d567cade0..86f3109e1 100644
--- a/documentation/ref-manual/structure.rst
+++ b/documentation/ref-manual/structure.rst
@@ -16,6 +16,19 @@ and directories.
    names that contain spaces. Be sure that the Source Directory you use
    does not contain these types of names.
 
+For the following sections, we assume the core components of the :term:`Source
+Directory` are organized as follows:
+
+.. code-block:: text
+
+   ├── build/
+   │   └── ...
+   └── layers/
+       ├── bitbake/
+       ├── meta-yocto/
+       ├── openembedded-core/
+       └── yocto-docs/
+
 .. _structure-core:
 
 Top-Level Core Components
@@ -67,8 +80,8 @@ about the contents of the :term:`Build Directory`.
 
 .. _handbook:
 
-``documentation/``
-------------------
+``layers/yocto-docs/``
+----------------------
 
 This directory holds the source for the Yocto Project documentation as
 well as templates and tools that allow you to generate PDF and HTML
@@ -76,37 +89,28 @@ versions of the manuals. Each manual is contained in its own sub-folder;
 for example, the files for this reference manual reside in the
 ``ref-manual/`` directory.
 
+This directory is not mandatory for building with :term:`BitBake`.
+
+``layers/openembedded-core/``
+-----------------------------
+
+The :term:`OpenEmbedded-Core (OE-Core)` repository is hosted at
+:oe_git:`/openembedded-core`.
+
 .. _structure-core-meta:
 
-``meta/``
----------
+``layers/openembedded-core/meta/``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This directory contains the minimal, underlying OpenEmbedded-Core
 metadata. The directory holds recipes, common classes, and machine
 configuration for strictly emulated targets (``qemux86``, ``qemuarm``,
 and so forth.)
 
-.. _structure-core-meta-poky:
-
-``meta-poky/``
---------------
-
-Designed above the ``meta/`` content, this directory adds just enough
-metadata to define the Poky reference distribution.
-
-.. _structure-core-meta-yocto-bsp:
-
-``meta-yocto-bsp/``
--------------------
-
-This directory contains the Yocto Project reference hardware Board
-Support Packages (BSPs). For more information on BSPs, see the
-:doc:`/bsp-guide/index`.
-
 .. _structure-meta-selftest:
 
-``meta-selftest/``
-------------------
+``layers/openembedded-core/meta-selftest/``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This directory adds additional recipes and append files used by the
 OpenEmbedded selftests to verify the behavior of the build system. You
@@ -115,15 +119,15 @@ want to run the selftests.
 
 .. _structure-meta-skeleton:
 
-``meta-skeleton/``
-------------------
+``layers/openembedded-core/meta-skeleton/``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This directory contains template recipes for BSP and kernel development.
 
 .. _structure-core-scripts:
 
-``scripts/``
-------------
+``layers/openembedded-core/scripts/``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This directory contains various integration scripts that implement extra
 functionality in the Yocto Project environment (e.g. QEMU scripts). The
@@ -136,8 +140,8 @@ back to the Yocto Project, such as ``create-pull-request`` and
 
 .. _structure-core-script:
 
-``oe-init-build-env``
----------------------
+``layers/openembedded-core/oe-init-build-env``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This script sets up the OpenEmbedded build environment. Running this
 script with the ``source`` command in a shell makes changes to ``PATH``
@@ -166,16 +170,27 @@ targets to build. Here is an example::
 
    You can also run generated QEMU images with a command like 'runqemu qemux86-64'
 
+.. note::
+
+   When using :doc:`bitbake-setup <bitbake:bitbake-user-manual/bitbake-user-manual-environment-setup>`,
+   this script is indirectly sourced when sourcing the ``init-build-env``
+   located in the :term:`bitbake:Setup`'s build directory. However, compared to
+   ``oe-init-build-env``, the bitbake-setup ``init-build-env`` does not take any
+   argument, as it is already located in a :term:`Build Directory`.
+
+   See :doc:`bitbake:bitbake-user-manual/bitbake-user-manual-environment-setup`
+   for more information.
+
 The default output of the ``oe-init-build-env`` script is from the
-``conf-summary.txt`` and ``conf-notes.txt`` files, which are found in the ``meta-poky`` directory
-within the :term:`Source Directory`. If you design a
-custom distribution, you can include your own versions of these
-configuration files where you can provide a brief summary and detailed usage
-notes, such as a list of the targets defined by your distribution.
-See the
-":ref:`dev-manual/custom-template-configuration-directory:creating a custom template configuration directory`"
-section in the Yocto Project Development Tasks Manual for more
-information.
+``conf-summary.txt`` and ``conf-notes.txt`` files, which are found in the
+``meta/conf/templates/default`` directory of :term:`OpenEmbedded-Core
+(OE-Core)`. If you design a custom distribution, you can include your own
+versions of these configuration files where you can provide a brief summary and
+detailed usage notes, such as a list of the targets defined by your
+distribution. See the
+":ref:`dev-manual/custom-template-configuration-directory:creating a custom
+template configuration directory`" section in the Yocto Project Development
+Tasks Manual for more information.
 
 By default, running this script without a :term:`Build Directory` argument
 creates the ``build/`` directory in your current working directory. If
@@ -188,8 +203,8 @@ your choice. For example, the following command creates a
    $ source oe-init-build-env ~/mybuilds
 
 The OpenEmbedded build system uses the template configuration files, which
-are found by default in the ``meta-poky/conf/templates/default`` directory in the Source
-Directory. See the
+are found by default in the ``meta/conf/templates/default`` directory in
+:term:`OpenEmbedded-Core (OE-Core)`. See the
 ":ref:`dev-manual/custom-template-configuration-directory:creating a custom template configuration directory`"
 section in the Yocto Project Development Tasks Manual for more
 information.
@@ -198,17 +213,35 @@ information.
 
    The OpenEmbedded build system does not support file or directory
    names that contain spaces. If you attempt to run the ``oe-init-build-env``
-   script from a Source Directory that contains spaces in either the
+   script from a :term:`Source Directory` that contains spaces in either the
    filenames or directory names, the script returns an error indicating
-   no such file or directory. Be sure to use a Source Directory free of
+   no such file or directory. Be sure to use a :term:`Source Directory` free of
    names containing spaces.
 
-.. _structure-basic-top-level:
+``layers/meta-yocto/``
+----------------------
+
+The ``meta-yocto`` repository is hosted at :yocto_git:`/meta-yocto`.
+
+.. _structure-core-meta-poky:
+
+``layers/meta-yocto/meta-poky/``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Dependent on the :term:`OpenEmbedded-Core (OE-Core)` metadata, this directory
+adds just enough metadata to define the Poky reference distribution.
 
-``LICENSE, README, and README.hardware``
-----------------------------------------
+Namely, it contains the distro :term:`configuration file` for Poky:
+``conf/distro/poky.conf``.
 
-These files are standard top-level files.
+.. _structure-core-meta-yocto-bsp:
+
+``layers/meta-yocto/meta-yocto-bsp/``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This directory contains the Yocto Project reference hardware Board
+Support Packages (BSPs). For more information on BSPs, see the
+:doc:`/bsp-guide/index`.
 
 .. _structure-build:
 
@@ -257,7 +290,7 @@ This directory should not be shared between builds.
    you need to share the :ref:`overview-manual/concepts:Hash Equivalence`
    database, don't share this file and instead refer to the
    :doc:`/dev-manual/hashequivserver` document of the Yocto Project Development
-   Tasks Manual to setup Hash Equivalence server.
+   Tasks Manual to setup a Hash Equivalence server.
 
 .. _structure-build-conf-local.conf:
 
@@ -275,14 +308,14 @@ file, it is recommended to put them into a distro :term:`configuration file`, or
 to create layer :term:`configuration fragments <Configuration Fragment>` from
 changes made here.
 
-The :term:`OpenEmbedded Build System` can create it from a ``local.conf.sample``
-file when you ``source`` the top-level build environment setup script
-:ref:`structure-core-script`.
+The :term:`OpenEmbedded Build System` can create the ``local.conf`` file from a
+``local.conf.sample`` file when you ``source`` the top-level build environment
+setup script :ref:`structure-core-script`.
 
 The source ``local.conf.sample`` file used depends on the
-:term:`TEMPLATECONF` script variable, which defaults to ``meta-poky/conf/templates/default``
+:term:`TEMPLATECONF` script variable, which defaults to ``layers/meta-yocto/meta-poky/conf/templates/default``
 when you are building from the Yocto Project development environment,
-and to ``meta/conf/templates/default`` when you are building from the OpenEmbedded-Core
+and to ``layers/openembedded-core/meta/conf/templates/default`` when you are building from the OpenEmbedded-Core
 environment. Because the script variable points to the source of the
 ``local.conf.sample`` file, this implies that you can configure your
 build environment from any layer by setting the variable in the
@@ -298,9 +331,9 @@ file, it uses ``sed`` to substitute final
 .. note::
 
    You can see how the :term:`TEMPLATECONF` variable is used by looking at the
-   ``scripts/oe-setup-builddir`` script in the :term:`Source Directory`.
-   You can find the Yocto Project version of the ``local.conf.sample`` file in
-   the ``meta-poky/conf/templates/default`` directory.
+   ``layers/openembedded-core/scripts/oe-setup-builddir`` script in :term:`OpenEmbedded-Core (OE-Core)`.
+   You can find the :term:`Poky` version of the ``local.conf.sample`` file in
+   the ``layers/meta-yocto/meta-poky/conf/templates/default`` directory.
 
 .. _structure-build-conf-bblayers.conf:
 
@@ -319,9 +352,9 @@ when you ``source`` the top-level build environment setup script (i.e.
 
 As with the :ref:`structure-build-conf-local.conf` file, the source ``bblayers.conf.sample``
 file used depends on the :term:`TEMPLATECONF` script variable, which
-defaults to ``meta-poky/conf/templates/default`` when you are building from the Yocto
-Project development environment, and to ``meta/conf/templates/default`` when you are
-building from the OpenEmbedded-Core environment. Because the script
+defaults to ``meta-poky/conf/templates/default`` when you are building using the
+:term:`Poky` reference distro, and to ``meta/conf/templates/default`` when you are
+building from the OpenEmbedded-Core environment (default). Because the script
 variable points to the source of the ``bblayers.conf.sample`` file, this
 implies that you can base your build from any layer by setting the
 variable in the top-level build environment setup script as follows::
@@ -329,13 +362,13 @@ variable in the top-level build environment setup script as follows::
    TEMPLATECONF=your_layer/conf/templates/your_template_name
 
 Once the build process gets the sample file, it uses ``sed`` to substitute final
-``${``\ :term:`OEROOT`\ ``}`` values for all ``##OEROOT##`` values.
+``${``\ :term:`OEROOT`\ ``}`` values for all ``##OEROOT##`` occurrences.
 
 .. note::
 
    You can see how the :term:`TEMPLATECONF` variable is defined by the ``scripts/oe-setup-builddir``
-   script in the :term:`Source Directory`. You can find the Yocto Project
-   version of the ``bblayers.conf.sample`` file in the ``meta-poky/conf/templates/default``
+   script in :term:`OpenEmbedded-Core (OE-Core)`. You can find the :term:`Poky`
+   version of the ``bblayers.conf.sample`` file in the ``layers/meta-yocto/meta-poky/conf/templates/default``
    directory.
 
 .. _structure-build-conf-site.conf:
@@ -351,8 +384,9 @@ You could for example edit this file to limit the number of threads used by
 want to access downloaded files (:term:`DL_DIR`).
 
 This file can be shared for multiple build directories. For example,
-``bitbake-setup`` makes the :ref:`structure-build-conf-site.conf` file a
-symbolic link to a common ``site.conf`` file::
+:doc:`bitbake-setup <bitbake:bitbake-user-manual/bitbake-user-manual-environment-setup>`
+makes the :ref:`structure-build-conf-site.conf` file a symbolic link to a common
+``site.conf`` file::
 
    ├── poky-master-poky-distro_poky-machine_qemux86-64/
    │   └── build/
@@ -757,11 +791,12 @@ space if they were to be shared with the standard :term:`Sysroot` mechanism.
 
 .. _structure-meta:
 
-The Metadata --- ``meta/``
-==========================
+The OpenEmbedded-Core (OE-Core) Metadata --- ``meta/``
+======================================================
 
-As mentioned previously, :term:`Metadata` is the core of the
-Yocto Project. Metadata has several important subdivisions:
+As mentioned previously, the :term:`OpenEmbedded-Core (OE-Core)`
+:term:`metadata` is the core of the Yocto Project. This metadata has several
+important subdivisions:
 
 .. _structure-meta-classes:
 
diff --git a/documentation/ref-manual/terms.rst b/documentation/ref-manual/terms.rst
index 22f2c4f79..cbe7c88e6 100644
--- a/documentation/ref-manual/terms.rst
+++ b/documentation/ref-manual/terms.rst
@@ -63,7 +63,7 @@ universal, the list includes them just in case:
       This term refers to the area used by the OpenEmbedded build system for
       builds. The area is created when you ``source`` the setup environment
       script that is found in the Source Directory
-      (i.e. :ref:`ref-manual/structure:``oe-init-build-env```, or
+      (i.e. :ref:`structure-core-script`, or
       ``init-build-env`` when using :doc:`bitbake-setup
       <bitbake:bitbake-user-manual/bitbake-user-manual-environment-setup>`). The
       :term:`TOPDIR` variable points to the :term:`Build Directory`.

-- 
2.52.0

[PATCH v2 27/56] ref-manual/tasks.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/ref-manual/tasks.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index 8651f219f..e6301e708 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -191,7 +191,7 @@ that either directly or indirectly depend on the installed files (e.g.
 
    -  The ``tar`` command with the ``--no-same-owner`` option. See the
       ``bin_package.bbclass`` file in the ``meta/classes-recipe``
-      subdirectory of the :term:`Source Directory` for an example.
+      subdirectory of :term:`OpenEmbedded-Core (OE-Core)` for an example.
 
 .. _ref-tasks-install_ptest_base:
 
@@ -288,14 +288,14 @@ 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 </poky/tree/meta/recipes-connectivity/bluez5>`
-recipe from the OE-Core layer (i.e. ``poky/meta``)::
+:oe_git:`bluez5 </openembedded-core/tree/meta/recipes-connectivity/bluez5>`
+recipe from the :term:`OpenEmbedded-Core (OE-Core)` layer::
 
-   poky/meta/recipes-connectivity/bluez5
+   meta/recipes-connectivity/bluez5
 
 This recipe has two patch files located here::
 
-   poky/meta/recipes-connectivity/bluez5/bluez5
+   meta/recipes-connectivity/bluez5/bluez5
 
 In the ``bluez5`` recipe, the :term:`SRC_URI` statements point to the source
 and patch files needed to build the package.

-- 
2.52.0

[PATCH v2 28/56] ref-manual/variables.rst: remove obsolete poky repo references

[Antonin Godard]

Remove references to the Poky repository, replace by OpenEmbedded-Core
in most cases.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/ref-manual/variables.rst | 149 ++++++++++++++++-----------------
 1 file changed, 73 insertions(+), 76 deletions(-)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 4d8a35473..8eece1bb7 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -168,7 +168,8 @@ system and gives an overview of their function and contents.
          ARCHIVER_MODE[srpm] = "1"                         # Uses RPM package files.
 
       For information on how the variable works, see the
-      ``meta/classes/archiver.bbclass`` file in the :term:`Source Directory`.
+      ``meta/classes/archiver.bbclass`` file in :term:`OpenEmbedded-Core
+      (OE-Core)`.
 
    :term:`AS`
       Minimal command and arguments needed to run the :manpage:`assembler
@@ -343,7 +344,7 @@ system and gives an overview of their function and contents.
       on Multilib.
 
       The :term:`BASE_LIB` variable is defined in the machine include files in
-      the :term:`Source Directory`. If Multilib is not
+      :term:`OpenEmbedded-Core (OE-Core)`. If Multilib is not
       being used, the value defaults to "lib".
 
    :term:`BASE_WORKDIR`
@@ -889,10 +890,10 @@ system and gives an overview of their function and contents.
       Here is an example::
 
          BBLAYERS = " \
-             /home/scottrif/poky/meta \
-             /home/scottrif/poky/meta-poky \
-             /home/scottrif/poky/meta-yocto-bsp \
-             /home/scottrif/poky/meta-mykernel \
+             /home/scottrif/bitbake-builds/layers/meta \
+             /home/scottrif/bitbake-builds/layers/meta-poky \
+             /home/scottrif/bitbake-builds/layers/meta-yocto-bsp \
+             /home/scottrif/bitbake-builds/layers/meta-mykernel \
              "
 
       This example enables four layers, one of which is a custom,
@@ -1007,8 +1008,8 @@ system and gives an overview of their function and contents.
          and `glob <https://docs.python.org/3/library/glob.html>`__.
 
       For more information on how this variable works, see
-      ``meta/classes-recipe/binconfig.bbclass`` in the :term:`Source Directory`.
-      You can also find general
+      ``meta/classes-recipe/binconfig.bbclass`` in :term:`OpenEmbedded-Core
+      (OE-Core)`. You can also find general
       information on the class in the
       ":ref:`ref-classes-binconfig`" section.
 
@@ -1617,8 +1618,8 @@ system and gives an overview of their function and contents.
       Bluetooth but you do not ever intend to use it.
 
    :term:`COMMERCIAL_AUDIO_PLUGINS`
-      This variable is specific to the :yocto_git:`GStreamer recipes
-      </poky/tree/meta/recipes-multimedia/gstreamer/gstreamer1.0-meta-base.bb>`.
+      This variable is specific to the :oe_git:`GStreamer recipes
+      </openembedded-core/tree/meta/recipes-multimedia/gstreamer/>`.
       It allows to build the GStreamer `"ugly"
       <https://github.com/GStreamer/gst-plugins-ugly>`__ and
       `"bad" <https://github.com/GStreamer/gst-plugins-bad>`__ audio plugins.
@@ -1627,8 +1628,8 @@ system and gives an overview of their function and contents.
       section for usage details.
 
    :term:`COMMERCIAL_VIDEO_PLUGINS`
-      This variable is specific to the :yocto_git:`GStreamer recipes
-      </poky/tree/meta/recipes-multimedia/gstreamer/gstreamer1.0-meta-base.bb>`.
+      This variable is specific to the :oe_git:`GStreamer recipes
+      </openembedded-core/tree/meta/recipes-multimedia/gstreamer/>`.
       It allows to build the GStreamer `"ugly"
       <https://github.com/GStreamer/gst-plugins-ugly>`__ and
       `"bad" <https://github.com/GStreamer/gst-plugins-bad>`__ video plugins.
@@ -1637,8 +1638,8 @@ system and gives an overview of their function and contents.
       section for usage details.
 
    :term:`COMMON_LICENSE_DIR`
-      Points to ``meta/files/common-licenses`` in the
-      :term:`Source Directory`, which is where generic license
+      Points to ``meta/files/common-licenses`` in
+      :term:`OpenEmbedded-Core (OE-Core)`, which is where generic license
       files reside.
 
    :term:`COMPATIBLE_HOST`
@@ -1763,8 +1764,8 @@ system and gives an overview of their function and contents.
          good practice to use appropriate path variables.
          For example, ``${sysconfdir}`` rather than ``/etc`` or ``${bindir}``
          rather than ``/usr/bin``. You can find a list of these variables at
-         the top of the ``meta/conf/bitbake.conf`` file in the
-         :term:`Source Directory`.
+         the top of the ``meta/conf/bitbake.conf`` file in
+         :term:`OpenEmbedded-Core (OE-Core)`.
 
    :term:`CONFIG_INITRAMFS_SOURCE`
       Identifies the initial RAM filesystem (:term:`Initramfs`) source files. The
@@ -1934,15 +1935,8 @@ system and gives an overview of their function and contents.
       supported.
 
    :term:`COREBASE`
-      Specifies the parent directory of the OpenEmbedded-Core Metadata
-      layer (i.e. ``meta``).
-
-      It is an important distinction that :term:`COREBASE` points to the parent
-      of this layer and not the layer itself. Consider an example where you
-      have cloned the Poky Git repository and retained the ``poky`` name
-      for your local copy of the repository. In this case, :term:`COREBASE`
-      points to the ``poky`` folder because it is the parent directory of
-      the ``poky/meta`` layer.
+      Specifies the parent directory of the :term:`OpenEmbedded-Core (OE-Core)`
+      metadata layer (i.e. ``meta``).
 
    :term:`COREBASE_FILES`
       Lists files from the :term:`COREBASE` directory that
@@ -2431,8 +2425,8 @@ system and gives an overview of their function and contents.
       file whose root name is the same as the variable's argument and whose
       filename extension is ``.conf``. For example, the distribution
       configuration file for the Poky distribution is named ``poky.conf``
-      and resides in the ``meta-poky/conf/distro`` directory of the
-      :term:`Source Directory`.
+      and resides in the ``meta-poky/conf/distro`` directory of
+      :yocto_git:`meta-poky </meta-yocto/tree/meta-poky>`.
 
       Within that ``poky.conf`` file, the :term:`DISTRO` variable is set as
       follows::
@@ -2448,7 +2442,8 @@ system and gives an overview of their function and contents.
 
          If the :term:`DISTRO` variable is blank, a set of default configurations
          are used, which are specified within
-         ``meta/conf/distro/defaultsetup.conf`` also in the Source Directory.
+         ``meta/conf/distro/defaultsetup.conf`` also in :term:`OpenEmbedded-Core
+         (OE-Core)`.
 
    :term:`DISTRO_CODENAME`
       Specifies a codename for the distribution being built.
@@ -2567,7 +2562,7 @@ system and gives an overview of their function and contents.
       argument and whose filename extension is ``.conf``. For example, the
       distribution configuration file for the Poky distribution is named
       ``poky.conf`` and resides in the ``meta-poky/conf/distro`` directory
-      of the :term:`Source Directory`.
+      of :yocto_git:`meta-poky </meta-yocto/tree/meta-poky>`.
 
       Within that ``poky.conf`` file, the :term:`DISTRO_NAME` variable is set
       as follows::
@@ -2582,7 +2577,8 @@ system and gives an overview of their function and contents.
 
          If the :term:`DISTRO_NAME` variable is blank, a set of default
          configurations are used, which are specified within
-         ``meta/conf/distro/defaultsetup.conf`` also in the Source Directory.
+         ``meta/conf/distro/defaultsetup.conf`` also in :term:`OpenEmbedded-Core
+         (OE-Core)`.
 
    :term:`DISTRO_VERSION`
       The version of the distribution.
@@ -2600,7 +2596,7 @@ system and gives an overview of their function and contents.
       :term:`OVERRIDES`.
 
       Here is an example from :yocto_git:`meta-poky/conf/distro/poky-tiny.conf
-      </poky/tree/meta-poky/conf/distro/poky-tiny.conf>`::
+      </meta-yocto/tree/meta-poky/conf/distro/poky-tiny.conf>`::
 
          DISTROOVERRIDES = "poky:poky-tiny"
 
@@ -3162,7 +3158,7 @@ system and gives an overview of their function and contents.
             use ``${sysconfdir}`` rather than ``/etc``, or ``${bindir}``
             rather than ``/usr/bin``. You can find a list of these
             variables at the top of the ``meta/conf/bitbake.conf`` file in
-            the :term:`Source Directory`. You will also
+            :term:`OpenEmbedded-Core (OE-Core)`. You will also
             find the default values of the various ``FILES:*`` variables in
             this file.
 
@@ -3279,8 +3275,8 @@ system and gives an overview of their function and contents.
       :term:`SRC_URI` statements.
 
       The default value for the :term:`FILESPATH` variable is defined in the
-      :ref:`ref-classes-base` class found in ``meta/classes-global`` in the
-      :term:`Source Directory`::
+      :ref:`ref-classes-base` class found in ``meta/classes-global`` in
+      :term:`OpenEmbedded-Core (OE-Core)`::
 
          FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \
              "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
@@ -3335,7 +3331,7 @@ system and gives an overview of their function and contents.
 
       By default, the OpenEmbedded build system uses the ``fs-perms.txt``,
       ``fs-perms-volatile-log.txt`` and ``fs-perms-volatile-tmp.txt`` which are
-      located in the ``meta/files`` folder in the :term:`Source Directory`. If
+      located in the ``meta/files`` folder in :term:`OpenEmbedded-Core (OE-Core)`. If
       you create your own permission setting table files, you should place
       those in your layer.
 
@@ -3638,7 +3634,7 @@ system and gives an overview of their function and contents.
       Other Go programs importing this package will use this path.
 
       Here is an example setting from the
-      :yocto_git:`go-helloworld_0.1.bb </poky/tree/meta/recipes-extended/go-examples/go-helloworld_0.1.bb>`
+      :oe_git:`go-helloworld_0.1.bb </openembedded-core/tree/meta/recipes-extended/go-examples/go-helloworld_0.1.bb>`
       recipe::
 
           GO_IMPORT = "golang.org/x/example"
@@ -4500,7 +4496,8 @@ system and gives an overview of their function and contents.
       - wic.zst
 
       For more information about these types of images, see
-      ``meta/classes-recipe/image_types*.bbclass`` in the :term:`Source Directory`.
+      ``meta/classes-recipe/image_types*.bbclass`` in :term:`OpenEmbedded-Core
+      (OE-Core)`.
 
    :term:`IMAGE_VERSION_SUFFIX`
       Version suffix that is part of the default :term:`IMAGE_NAME` and
@@ -4718,7 +4715,7 @@ system and gives an overview of their function and contents.
 
       With ``sysvinit``, the init manager is set to
       :wikipedia:`SysVinit <Init#SysV-style>`, the traditional UNIX init
-      system. This is the default choice in the Poky distribution, together with
+      system. This is the default choice in the :term:`Poky` distribution, together with
       the Udev device manager (see the ":ref:`device-manager`" section).
 
       With ``systemd``, the init manager becomes :wikipedia:`systemd <Systemd>`,
@@ -4732,7 +4729,7 @@ system and gives an overview of their function and contents.
       More concretely, this is used to include
       ``conf/distro/include/init-manager-${INIT_MANAGER}.inc`` into the global
       configuration. You can have a look at the
-      :yocto_git:`meta/conf/distro/include/init-manager-*.inc </poky/tree/meta/conf/distro/include>`
+      :oe_git:`meta/conf/distro/include/init-manager-*.inc </openembedded-core/tree/meta/conf/distro/include>`
       files for more information, and also the ":ref:`init-manager`"
       section in the Yocto Project Development Tasks Manual.
 
@@ -4751,8 +4748,8 @@ system and gives an overview of their function and contents.
       :term:`IMAGE_FSTYPES` variable.
 
       The default value of this variable, which is set in the
-      ``meta/conf/bitbake.conf`` configuration file in the
-      :term:`Source Directory`, is "cpio.gz". The Linux kernel's
+      ``meta/conf/bitbake.conf`` configuration file in
+      :term:`OpenEmbedded-Core (OE-Core)`, is "cpio.gz". The Linux kernel's
       :term:`Initramfs` mechanism, as opposed to the initial RAM filesystem
       :wikipedia:`initrd <Initrd>` mechanism, expects
       an optionally compressed cpio archive.
@@ -4774,14 +4771,14 @@ system and gives an overview of their function and contents.
       .. note::
 
          See the ``meta/recipes-core/images/core-image-minimal-initramfs.bb``
-         recipe in the :term:`Source Directory`
+         recipe in :term:`OpenEmbedded-Core (OE-Core)`
          for an example :term:`Initramfs` recipe. To select this sample recipe as
          the one built to provide the :term:`Initramfs` image, set :term:`INITRAMFS_IMAGE`
          to "core-image-minimal-initramfs".
 
       You can also find more information by referencing the
-      ``meta-poky/conf/templates/default/local.conf.sample.extended``
-      configuration file in the Source Directory, the :ref:`ref-classes-image`
+      ``conf/templates/default/local.conf.sample.extended``
+      configuration file in :yocto_git:`meta-poky <meta-yocto/tree/meta-poky>`, the :ref:`ref-classes-image`
       class, and the :ref:`ref-classes-kernel` class to see how to use the
       :term:`INITRAMFS_IMAGE` variable.
 
@@ -4841,7 +4838,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 </poky/tree/meta-poky/conf/templates/default/local.conf.sample.extended>`
+      :yocto_git:`local.conf.sample.extended </meta-yocto/tree/meta-poky/conf/templates/default/local.conf.sample.extended>`
       file for additional information. Also, for information on creating an
       :term:`Initramfs`, see the ":ref:`dev-manual/building:building an initial ram filesystem (Initramfs) image`" section
       in the Yocto Project Development Tasks Manual.
@@ -5855,7 +5852,7 @@ system and gives an overview of their function and contents.
       name, through which machine-specific configurations are set. Thus,
       when :term:`MACHINE` is set to "qemux86", the corresponding
       ``qemux86.conf`` machine configuration file can be found in
-      the :term:`Source Directory` in
+      :term:`OpenEmbedded-Core (OE-Core)` in
       ``meta/conf/machine``.
 
       The list of machines supported by the Yocto Project as shipped
@@ -6369,8 +6366,8 @@ system and gives an overview of their function and contents.
       ``sysroots/`` directory so that all builds that use the script will
       use the correct directories for the cross compiling layout.
 
-      See the ``meta/classes-recipe/binconfig.bbclass`` in the
-      :term:`Source Directory` for details on how this class
+      See the ``meta/classes-recipe/binconfig.bbclass`` in
+      :term:`OpenEmbedded-Core (OE-Core)` for details on how this class
       applies these additional sed command arguments.
 
    :term:`OE_FRAGMENTS`
@@ -6449,7 +6446,7 @@ system and gives an overview of their function and contents.
 
    :term:`OEQA_REPRODUCIBLE_TEST_PACKAGE`
       Set the package manager(s) for build reproducibility testing.
-      See :yocto_git:`reproducible.py </poky/tree/meta/lib/oeqa/selftest/cases/reproducible.py>`
+      See :oe_git:`reproducible.py </openembedded-core/tree/meta/lib/oeqa/selftest/cases/reproducible.py>`
       and :doc:`/test-manual/reproducible-builds`.
 
    :term:`OEQA_REPRODUCIBLE_TEST_SSTATE_TARGETS`
@@ -6719,7 +6716,7 @@ system and gives an overview of their function and contents.
          ``*-dbg`` package as with the ``.debug`` value, while source is
          placed in a separate ``*-src`` package, which can be installed
          independently.  This is the default setting for this variable,
-         as defined in Poky's ``bitbake.conf`` file.
+         as defined in :term:`OE-Core <OpenEmbedded-Core (OE-Core)>`'s ``bitbake.conf`` file.
 
       -  "``debug-without-src``": The same behavior as with the ``.debug``
          setting, but no source is packaged at all.
@@ -7677,8 +7674,8 @@ system and gives an overview of their function and contents.
       The network based :term:`PR` service host and port.
 
       The ``conf/templates/default/local.conf.sample.extended`` configuration
-      file in the :term:`Source Directory` shows how the :term:`PRSERV_HOST`
-      variable is set::
+      file in :yocto_git:`meta-poky </meta-yocto/tree/meta-poky>` shows how the
+      :term:`PRSERV_HOST` variable is set::
 
          PRSERV_HOST = "localhost:0"
 
@@ -8324,11 +8321,11 @@ system and gives an overview of their function and contents.
       to find the unpacked source.
 
       As an example, assume a :term:`Source Directory`
-      top-level folder named ``poky`` and a default :term:`Build Directory` at
-      ``poky/build``. In this case, the work directory the build system
+      top-level folder named ``bitbake-builds`` and a default :term:`Build Directory` at
+      ``bitbake-builds/build``. In this case, the work directory the build system
       uses to keep the unpacked recipe for ``db`` is the following::
 
-         poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/sources/db-5.1.19
+         bitbake-builds/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/sources/db-5.1.19
 
       The unpacked source code resides in the ``db-5.1.19`` folder.
 
@@ -8580,7 +8577,7 @@ system and gives an overview of their function and contents.
 
          SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK"
 
-      For the default distribution "poky",
+      For the :term:`poky` reference distribution,
       :term:`SDK_TITLE` is set to "Poky (Yocto Project Reference Distro)".
 
       For information on how to change this default title, see the
@@ -8626,7 +8623,7 @@ system and gives an overview of their function and contents.
          SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk"
 
       For the
-      default distribution "poky", the :term:`SDKEXTPATH` is set to "poky_sdk".
+      :term:`Poky` reference distro, the :term:`SDKEXTPATH` is set to "poky_sdk".
 
       For information on how to change this default directory, see the
       ":ref:`sdk-manual/appendix-customizing:changing the default sdk installation directory`"
@@ -9300,8 +9297,8 @@ system and gives an overview of their function and contents.
       .. note::
 
          The :term:`SRCPV` variable used to be defined in the
-         ``meta/conf/bitbake.conf`` configuration file in the :term:`Source
-         Directory` as follows::
+         ``meta/conf/bitbake.conf`` configuration file in
+         :term:`OpenEmbedded-Core (OE-Core)` as follows::
 
             SRCPV = "${@bb.fetch2.get_srcrev(d)}"
 
@@ -10006,8 +10003,8 @@ system and gives an overview of their function and contents.
       compatible with the kernel compilation. The :term:`TARGET_CC_KERNEL_ARCH`
       variable allows the kernel (and associated modules) to use a
       different configuration. See the
-      ``meta/conf/machine/include/arm/feature-arm-thumb.inc`` file in the
-      :term:`Source Directory` for an example.
+      ``meta/conf/machine/include/arm/feature-arm-thumb.inc`` file in
+      :term:`OpenEmbedded-Core (OE-Core)` for an example.
 
    :term:`TARGET_CFLAGS`
       Specifies the flags to pass to the C compiler when building for the
@@ -10408,10 +10405,10 @@ system and gives an overview of their function and contents.
       ``tmp`` within the :term:`Build Directory`.
 
       If you want to establish this directory in a location other than the
-      default, you can uncomment and edit the following statement in the
-      ``conf/local.conf`` file in the :term:`Source Directory`::
+      default, you can set it to another value in your
+      :ref:`structure-build-conf-site.conf` configuration file::
 
-         #TMPDIR = "${TOPDIR}/tmp"
+         TMPDIR = "/another/location"
 
       An example use for this scenario is to set :term:`TMPDIR` to a local disk,
       which does not use NFS, while having the :term:`Build Directory` use NFS.
@@ -10542,8 +10539,8 @@ system and gives an overview of their function and contents.
       definitions can be a single static definition, or can be dynamically
       adjusted. You can see details for a given CPU family by looking at
       the architecture's ``README`` file. For example, the
-      ``meta/conf/machine/include/mips/README`` file in the
-      :term:`Source Directory` provides information for
+      ``meta/conf/machine/include/mips/README`` file in
+      :term:`OpenEmbedded-Core (OE-Core)` provides information for
       :term:`TUNE_ARCH` specific to the ``mips`` architecture.
 
       :term:`TUNE_ARCH` is tied closely to
@@ -10645,7 +10642,7 @@ system and gives an overview of their function and contents.
       that conflict with feature.
 
       Known tuning conflicts are specified in the machine include files in
-      the :term:`Source Directory`. Here is an example from
+      :term:`OpenEmbedded-Core (OE-Core)`. Here is an example from
       the ``meta/conf/machine/include/mips/arch-mips.inc`` include file
       that lists the "o32" and "n64" features as conflicting with the "n32"
       feature::
@@ -10661,7 +10658,7 @@ system and gives an overview of their function and contents.
 
          TUNEVALID[bigendian] = "Enable big-endian mode."
 
-      See the machine include files in the :term:`Source Directory`
+      See the machine include files in :term:`OpenEmbedded-Core (OE-Core)`
       for these features.
 
    :term:`UBOOT_BINARY`
@@ -11350,8 +11347,8 @@ system and gives an overview of their function and contents.
          USER_CLASSES ?= "buildstats"
 
       For more information, see
-      ``meta-poky/conf/templates/default/local.conf.sample`` in the
-      :term:`Source Directory`.
+      ``conf/templates/default/local.conf.sample`` in
+      :yocto_git:`meta-poky <meta-yocto/tree/meta-poky>`.
 
    :term:`USERADD_DEPENDS`
       Specifies a list of recipes that create users / groups (via
@@ -11500,13 +11497,13 @@ system and gives an overview of their function and contents.
          VIRTUAL-RUNTIME_base-utils = "packagegroup-core-base-utils"
 
       Here are two examples using this virtual runtime package. The
-      first one is in :yocto_git:`initramfs-framework_1.0.bb
-      </poky/tree/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb?h=scarthgap>`::
+      first one is in :oe_git:`initramfs-framework_1.0.bb
+      </openembedded-core/tree/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb>`::
 
          RDEPENDS:${PN} += "${VIRTUAL-RUNTIME_base-utils}"
 
-      The second example is in the :yocto_git:`core-image-initramfs-boot
-      </poky/tree/meta/recipes-core/images/core-image-initramfs-boot.bb?h=scarthgap>`
+      The second example is in the :oe_git:`core-image-initramfs-boot
+      </openembedded-core/tree/meta/recipes-core/images/core-image-initramfs-boot.bb>`
       image definition::
 
          PACKAGE_INSTALL = "${INITRAMFS_SCRIPTS} ${VIRTUAL-RUNTIME_base-utils} base-passwd"
@@ -11632,13 +11629,13 @@ system and gives an overview of their function and contents.
       -  :term:`PR`: The recipe revision
 
       As an example, assume a Source Directory top-level folder name
-      ``poky``, a default :term:`Build Directory` at ``poky/build``, and a
+      ``bitbake-builds``, a default :term:`Build Directory` at ``bitbake-builds/build``, and a
       ``qemux86-poky-linux`` machine target system. Furthermore, suppose
       your recipe is named ``foo_1.3.0-r0.bb``. In this case, the work
       directory the build system uses to build the package would be as
       follows::
 
-         poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
+         bitbake-builds/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
 
    :term:`XSERVER`
       Specifies the packages that should be installed to provide an X

-- 
2.52.0

[PATCH v2 29/56] sdk-manual/appendix-obtain.rst: remove obsolete poky repo references

[Antonin Godard]

Rename the source directory to project, as specified in its new
definition in terms.rst.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/sdk-manual/appendix-obtain.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/sdk-manual/appendix-obtain.rst b/documentation/sdk-manual/appendix-obtain.rst
index fb2326fac..a6f2da052 100644
--- a/documentation/sdk-manual/appendix-obtain.rst
+++ b/documentation/sdk-manual/appendix-obtain.rst
@@ -166,7 +166,7 @@ build the SDK installer. Follow these steps:
 
    .. code-block:: console
 
-      $ cd poky/build/tmp/deploy/sdk
+      $ cd bitbake-builds/build/tmp/deploy/sdk
       $ ./poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
 
    During execution of the script, you choose the root location for the

-- 
2.52.0

[PATCH v2 30/56] sdk-manual/intro.rst: remove obsolete poky repo references

[Antonin Godard]

Remove the mention of the Poky git repository. Refer to the existing
setup instructions.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/sdk-manual/intro.rst | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/documentation/sdk-manual/intro.rst b/documentation/sdk-manual/intro.rst
index c96e58dd7..dd2902cc4 100644
--- a/documentation/sdk-manual/intro.rst
+++ b/documentation/sdk-manual/intro.rst
@@ -133,12 +133,8 @@ your application or image. QEMU is not part of the SDK but is
 automatically installed and available if you have done any one of
 the following:
 
--  cloned the ``poky`` Git repository to create a
-   :term:`Source Directory` and sourced the environment setup script.
-
--  downloaded a Yocto Project release and unpacked it to
-   create a Source Directory and sourced the environment setup
-   script.
+-  Setup your :term:`Build Host` as described in the :doc:`/dev-manual/start`
+   section of the Yocto Project Development Tasks Manual.
 
 -  installed the cross-toolchain tarball and
    sourced the toolchain's setup environment script.

-- 
2.52.0

[PATCH v2 31/56] test-manual/runtime-testing.rst: remove obsolete poky repo references

[Antonin Godard]

Remove reference to the Poky repository, replace by OpenEmbedded-Core.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/test-manual/runtime-testing.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/documentation/test-manual/runtime-testing.rst b/documentation/test-manual/runtime-testing.rst
index 909448ab2..a64a97c80 100644
--- a/documentation/test-manual/runtime-testing.rst
+++ b/documentation/test-manual/runtime-testing.rst
@@ -338,8 +338,8 @@ You can start the tests automatically or manually:
 
       bitbake -c testimage image
 
-All test files reside in ``meta/lib/oeqa/runtime/cases`` in the
-:term:`Source Directory`. A test name maps
+All test files reside in ``meta/lib/oeqa/runtime/cases`` in
+:term:`OpenEmbedded-Core (OE-Core)`. A test name maps
 directly to a Python module. Each test module may contain a number of
 individual tests. Tests are usually grouped together by the area tested
 (e.g tests for systemd reside in ``meta/lib/oeqa/runtime/cases/systemd.py``).

-- 
2.52.0

[PATCH v2 32/56] README: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/README | 39 ++++++++++-----------------------------
 1 file changed, 10 insertions(+), 29 deletions(-)

diff --git a/documentation/README b/documentation/README
index 56eac7ca1..5516d71a6 100644
--- a/documentation/README
+++ b/documentation/README
@@ -1,33 +1,14 @@
 documentation
 =============
 
-This is the directory that contains the Yocto Project documentation.  The Yocto
-Project source repositories at https://git.yoctoproject.org/cgit.cgi have two
-instances of the "documentation" directory.  You should understand each of
-these instances.
-
-  poky/documentation - The directory within the poky Git repository containing
-                       the set of Yocto Project manuals.  When you clone the
-                       poky Git repository, the documentation directory
-                       contains the manuals.  The state of the manuals in this
-                       directory is guaranteed to reflect the latest Yocto
-                       Project release.  The manuals at the tip of this
-                       directory will also likely contain most manual
-                       development changes.
-
-  yocto-docs/documentation - The Git repository for the Yocto Project manuals.
-                             This repository is where manual development
-                             occurs.  If you plan on contributing back to the
-                             Yocto Project documentation, you should set up
-                             a local Git repository based on this upstream
-                             repository as follows:
-
-                               git clone git://git.yoctoproject.org/yocto-docs
-
-                             Changes and patches are first pushed to the
-                             yocto-docs Git repository.  Later, they make it
-                             into the poky Git repository found at
-                             git://git.yoctoproject.org/poky.
+This is the directory that contains the Yocto Project documentation. The Yocto
+Project documentation is hosted at https://git.yoctoproject.org/yocto-docs:
+
+This repository is where manual development occurs. If you plan on contributing
+back to the Yocto Project documentation, you should set up a local Git
+repository based on this upstream repository as follows:
+
+  git clone git://git.yoctoproject.org/yocto-docs
 
 Manual Organization
 ===================
@@ -261,9 +242,9 @@ For example, the following .rst content will produce the 'expected'
 content:
 
   .. code-block::
-      $ mkdir poky-&DISTRO;
+      $ mkdir bitbake-builds-&DISTRO;
       or
-      $ git clone &YOCTO_GIT_URL;/git/poky -b &DISTRO_NAME_NO_CAP;
+      $ git clone &YOCTO_GIT_URL;/git/yocto-docs -b &DISTRO_NAME_NO_CAP;
 
 Variables can be nested, like it was the case for DocBook:
 

-- 
2.52.0

[PATCH v2 33/56] README: replace obsolete substitution variables

[Antonin Godard]

Replace obsolete substitution variables by current ones from
poky.yaml.in.

Suggested-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/README | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/documentation/README b/documentation/README
index 5516d71a6..7c4472c73 100644
--- a/documentation/README
+++ b/documentation/README
@@ -244,12 +244,12 @@ content:
   .. code-block::
       $ mkdir bitbake-builds-&DISTRO;
       or
-      $ git clone &YOCTO_GIT_URL;/git/yocto-docs -b &DISTRO_NAME_NO_CAP;
+      $ git clone https://git.yoctoproject.org/yocto-docs -b &DISTRO_NAME_NO_CAP;
 
 Variables can be nested, like it was the case for DocBook:
 
-  YOCTO_HOME_URL : "https://www.yoctoproject.org"
-  YOCTO_DOCS_URL : "&YOCTO_HOME_URL;/docs"
+  DISTRO : "5.2"
+  DISTRO_REL_TAG : "yocto-$DISTRO;"
 
 Note directive
 ==============

-- 
2.52.0

[PATCH v2 34/56] contributor-guide/identify-component.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/contributor-guide/identify-component.rst | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/documentation/contributor-guide/identify-component.rst b/documentation/contributor-guide/identify-component.rst
index a28391a66a..6cf8ed9858 100644
--- a/documentation/contributor-guide/identify-component.rst
+++ b/documentation/contributor-guide/identify-component.rst
@@ -20,12 +20,3 @@ If the issue is in the core metadata layer (OpenEmbedded-Core) or in BitBake,
 issues can be reported in the :yocto_bugs:`Yocto Project Bugzilla <>`. The
 :yocto_lists:`yocto </g/yocto>` mailing list is a general “catch-all” location
 where questions can be sent if you can’t work out where something should go.
-
-:term:`Poky` is a commonly used “combination” repository where multiple
-components have been combined (:oe_git:`bitbake </bitbake>`,
-:oe_git:`openembedded-core </openembedded-core>`,
-:yocto_git:`meta-yocto </meta-yocto>` and
-:yocto_git:`yocto-docs </yocto-docs>`). Patches should be submitted against the
-appropriate individual component rather than :term:`Poky` itself as detailed in
-the appropriate ``README`` file.
-

-- 
2.52.0

[PATCH v2 35/56] dev-manual/build-quality.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/build-quality.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/dev-manual/build-quality.rst b/documentation/dev-manual/build-quality.rst
index fbe5fb6f0..163d8832e 100644
--- a/documentation/dev-manual/build-quality.rst
+++ b/documentation/dev-manual/build-quality.rst
@@ -372,7 +372,7 @@ There is a command-line tool called ``buildhistory-diff``, though,
 that queries the Git repository and prints just the differences that
 might be significant in human-readable form. Here is an example::
 
-   $ poky/poky/scripts/buildhistory-diff . HEAD^
+   $ bitbake-builds/layers/openembedded-core/scripts/buildhistory-diff . HEAD^
    Changes to images/qemux86_64/glibc/core-image-minimal (files-in-image.txt):
       /etc/anotherpkg.conf was added
       /sbin/anotherpkg was added

-- 
2.52.0

[PATCH v2 36/56] dev-manual/custom-distribution.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/custom-distribution.rst | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/documentation/dev-manual/custom-distribution.rst b/documentation/dev-manual/custom-distribution.rst
index 55854f00e..4dafd2725 100644
--- a/documentation/dev-manual/custom-distribution.rst
+++ b/documentation/dev-manual/custom-distribution.rst
@@ -3,8 +3,10 @@
 Creating Your Own Distribution
 ******************************
 
-When you build an image using the Yocto Project and do not alter any
-distribution :term:`Metadata`, you are using the Poky distribution.
+When you build an image using the Yocto Project and follow the default setup
+showcased in :doc:`/dev-manual/start`, you are using the :term:`Poky` reference
+distribution.
+
 Poky is explicitly a *reference* distribution for testing and
 development purposes. It enables most hardware and software features
 so that they can be tested, but this also means that from a security

-- 
2.52.0

[PATCH v2 37/56] dev-manual/custom-template-configuration-directory.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete. Adapt
paths to match to encouraged Source Directory layout.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 .../dev-manual/custom-template-configuration-directory.rst        | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/documentation/dev-manual/custom-template-configuration-directory.rst b/documentation/dev-manual/custom-template-configuration-directory.rst
index 06fcada822..8bf763569d 100644
--- a/documentation/dev-manual/custom-template-configuration-directory.rst
+++ b/documentation/dev-manual/custom-template-configuration-directory.rst
@@ -15,10 +15,10 @@ This can be done by using ``bitbake-layers save-build-conf``::
 
    $ bitbake-layers save-build-conf ../../meta-alex/ test-1
    NOTE: Starting bitbake server...
-   NOTE: Configuration template placed into /srv/work/alex/meta-alex/conf/templates/test-1
-   Please review the files in there, and particularly provide a configuration description in /srv/work/alex/meta-alex/conf/templates/test-1/conf-notes.txt
+   NOTE: Configuration template placed into /srv/bitbake-builds/layers/meta-alex/conf/templates/test-1
+   Please review the files in there, and particularly provide a configuration description in /srv/bitbake-builds/meta-alex/conf/templates/test-1/conf-notes.txt
    You can try out the configuration with
-   TEMPLATECONF=/srv/work/alex/meta-alex/conf/templates/test-1 . /srv/work/alex/poky/oe-init-build-env build-try-test-1
+   TEMPLATECONF=/srv/bitbake-builds/layers/meta-alex/conf/templates/test-1 . /srv/bitbake-builds/layers/openembedded-core/oe-init-build-env build-try-test-1
 
 The above command takes the config files from the currently active :term:`Build Directory` under ``conf``,
 replaces site-specific paths in ``bblayers.conf`` with ``##OECORE##``-relative paths, and copies
@@ -27,7 +27,7 @@ the config files into a specified layer under a specified template name.
 To use those saved templates as a starting point for a build, users should point
 to one of them with :term:`TEMPLATECONF` environment variable::
 
-   TEMPLATECONF=/srv/work/alex/meta-alex/conf/templates/test-1 . /srv/work/alex/poky/oe-init-build-env build-try-test-1
+   TEMPLATECONF=/srv/bitbake-builds/layers/meta-alex/conf/templates/test-1 . /srv/bitbake-builds/layers/openembedded-core/oe-init-build-env build-try-test-1
 
 The OpenEmbedded build system uses the environment variable
 :term:`TEMPLATECONF` to locate the directory from which it gathers

-- 
2.52.0

[PATCH v2 38/56] dev-manual/init-manager.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/init-manager.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/documentation/dev-manual/init-manager.rst b/documentation/dev-manual/init-manager.rst
index d0fdfdf77..670810310 100644
--- a/documentation/dev-manual/init-manager.rst
+++ b/documentation/dev-manual/init-manager.rst
@@ -54,7 +54,7 @@ Using SysVinit with udev
 =========================
 
 SysVinit with the udev device manager corresponds to the
-default setting in Poky. This corresponds to setting::
+default setting in :term:`Poky`. This corresponds to setting::
 
    INIT_MANAGER = "sysvinit"
 
@@ -77,8 +77,8 @@ for more complex systems::
    INIT_MANAGER = "systemd"
 
 This will enable systemd and remove sysvinit components from the image.
-See :yocto_git:`meta/conf/distro/include/init-manager-systemd.inc
-</poky/tree/meta/conf/distro/include/init-manager-systemd.inc>` for exact
+See :oe_git:`meta/conf/distro/include/init-manager-systemd.inc
+</openembedded-core/tree/meta/conf/distro/include/init-manager-systemd.inc>` for exact
 details on what this does.
 
 Controling systemd from the target command line

-- 
2.52.0

[PATCH v2 39/56] dev-manual/licenses.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/licenses.rst | 30 ++++++++++++------------------
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/documentation/dev-manual/licenses.rst b/documentation/dev-manual/licenses.rst
index 7d6636eef..1887e8e35 100644
--- a/documentation/dev-manual/licenses.rst
+++ b/documentation/dev-manual/licenses.rst
@@ -112,8 +112,8 @@ commercial or other special licensing requirements. Such requirements
 are defined on a recipe-by-recipe basis through the
 :term:`LICENSE_FLAGS` variable
 definition in the affected recipe. For instance, the
-``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` recipe
-contains the following statement::
+``meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly`` recipe of
+:term:`OpenEmbedded-Core (OE-Core)` contains the following statement::
 
    LICENSE_FLAGS = "commercial"
 
@@ -136,7 +136,8 @@ needs to have a matching entry in the global
 :term:`LICENSE_FLAGS_ACCEPTED`
 variable, which is a variable typically defined in your ``local.conf``
 file. For example, to enable the
-``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` package, you
+``meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly`` package of
+:term:`OpenEmbedded-Core (OE-Core)`, you
 could add either the string "commercial_gst-plugins-ugly" or the more
 general string "commercial" to :term:`LICENSE_FLAGS_ACCEPTED`. See the
 ":ref:`dev-manual/licenses:license flag matching`" section for a full
@@ -244,7 +245,7 @@ Other Variables Related to Commercial Licenses
 
 There are other helpful variables related to commercial license handling,
 defined in the
-``poky/meta/conf/distro/include/default-distrovars.inc`` file::
+``meta/conf/distro/include/default-distrovars.inc`` file in :term:`OpenEmbedded-Core (OE-Core)`::
 
    COMMERCIAL_AUDIO_PLUGINS ?= ""
    COMMERCIAL_VIDEO_PLUGINS ?= ""
@@ -460,22 +461,15 @@ and the source code modifications in one step.
 
 If the deployment team has a :ref:`overview-manual/concepts:bsp layer`
 and a distro layer, and those
-those layers are used to patch, compile, package, or modify (in any way)
+layers are used to patch, compile, package, or modify (in any way)
 any open source software included in your released images, you might be
 required to release those layers under section 3 of GPLv2 or section 1
 of GPLv3. One way of doing that is with a clean checkout of the version
-of the Yocto Project and layers used during your build. Here is an
-example:
+of the Yocto Project and layers used during your build. Removing the Git
+objects can be done like so:
 
-.. code-block:: shell
+.. code-block:: console
 
-   # We built using the dunfell branch of the poky repo
-   $ git clone -b dunfell git://git.yoctoproject.org/poky
-   $ cd poky
-   # We built using the release_branch for our layers
-   $ git clone -b release_branch git://git.mycompany.com/meta-my-bsp-layer
-   $ git clone -b release_branch git://git.mycompany.com/meta-my-software-layer
-   # clean up the .git repos
    $ find . -name ".git" -type d -exec rm -rf {} \;
 
 One thing a development organization might want to consider for end-user
@@ -494,9 +488,9 @@ automatically::
 
    BBLAYERS ?= " \
      ##OEROOT##/meta \
-     ##OEROOT##/meta-poky \
-     ##OEROOT##/meta-yocto-bsp \
-     ##OEROOT##/meta-mylayer \
+     ##OEROOT##/../meta-poky \
+     ##OEROOT##/../meta-yocto-bsp \
+     ##OEROOT##/../meta-mylayer \
      "
 
 Creating and

-- 
2.52.0

[PATCH v2 40/56] dev-manual/licenses.rst: instruct to use git-archive instead of removing .git

[Antonin Godard]

Removing .git directories is destructive. Instruct to use git archive
instead.

Suggested-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/licenses.rst | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/documentation/dev-manual/licenses.rst b/documentation/dev-manual/licenses.rst
index 1887e8e35..3d0167e75 100644
--- a/documentation/dev-manual/licenses.rst
+++ b/documentation/dev-manual/licenses.rst
@@ -465,12 +465,8 @@ layers are used to patch, compile, package, or modify (in any way)
 any open source software included in your released images, you might be
 required to release those layers under section 3 of GPLv2 or section 1
 of GPLv3. One way of doing that is with a clean checkout of the version
-of the Yocto Project and layers used during your build. Removing the Git
-objects can be done like so:
-
-.. code-block:: console
-
-   $ find . -name ".git" -type d -exec rm -rf {} \;
+of the Yocto Project and layers used during your build. Archiving a Git
+repository can be done with the :manpage:`git-archive <git-archive(1)>` command.
 
 One thing a development organization might want to consider for end-user
 convenience is to modify

-- 
2.52.0

[PATCH v2 41/56] dev-manual/packages.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/packages.rst | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/documentation/dev-manual/packages.rst b/documentation/dev-manual/packages.rst
index 8bd48c8e8..ebed8f076 100644
--- a/documentation/dev-manual/packages.rst
+++ b/documentation/dev-manual/packages.rst
@@ -361,8 +361,9 @@ package. It is also perfectly acceptable to call ``do_split_packages``
 multiple times if you have more than one set of modules to package.
 
 For more examples that show how to use ``do_split_packages``, see the
-``connman.inc`` file in the ``meta/recipes-connectivity/connman/``
-directory of the ``poky`` :ref:`source repository <overview-manual/development-environment:yocto project source repositories>`. You can
+``connman.inc`` file in the :oe_git:`meta/recipes-connectivity/connman/
+</openembedded-core/tree/meta/recipes-connectivity/connman/>`
+directory of :term:`OpenEmbedded-Core (OE-Core)`. You can
 also find examples in ``meta/classes-recipe/kernel.bbclass``.
 
 Here is a reference that shows ``do_split_packages`` mandatory and
@@ -543,7 +544,7 @@ to use. In your configuration, you use the
 variable to specify the format:
 
 #. Open the ``local.conf`` file inside your :term:`Build Directory` (e.g.
-   ``poky/build/conf/local.conf``).
+   ``bitbake-builds/build/conf/local.conf``).
 
 #. Select the desired package format as follows::
 
@@ -637,10 +638,10 @@ Lighttpd, or Nginx), take the appropriate steps to do so.
 
 From within the :term:`Build Directory` where you have built an image based on
 your packaging choice (i.e. the :term:`PACKAGE_CLASSES` setting), simply start
-the server. The following example assumes a :term:`Build Directory` of ``poky/build``
+the server. The following example assumes a :term:`Build Directory` of ``bitbake-builds/build``
 and a :term:`PACKAGE_CLASSES` setting of ":ref:`ref-classes-package_rpm`"::
 
-   $ cd poky/build/tmp/deploy/rpm
+   $ cd bitbake-builds/build/tmp/deploy/rpm
    $ python3 -m http.server
 
 Target Setup

-- 
2.52.0

[PATCH v2 42/56] dev-manual/python-development-shell.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/python-development-shell.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/dev-manual/python-development-shell.rst b/documentation/dev-manual/python-development-shell.rst
index 81a5c43472..0756304323 100644
--- a/documentation/dev-manual/python-development-shell.rst
+++ b/documentation/dev-manual/python-development-shell.rst
@@ -16,7 +16,7 @@ the following are useful when exploring the data store and running
 functions::
 
    pydevshell> d.getVar("STAGING_DIR")
-   '/media/build1/poky/build/tmp/sysroots'
+   '/media/build1/bitbake-builds/build/tmp/sysroots'
    pydevshell> d.getVar("STAGING_DIR", False)
    '${TMPDIR}/sysroots'
    pydevshell> d.setVar("FOO", "bar")

-- 
2.52.0

[PATCH v2 43/56] dev-manual/qemu.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/qemu.rst | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/documentation/dev-manual/qemu.rst b/documentation/dev-manual/qemu.rst
index 442fdced3..e40660a96 100644
--- a/documentation/dev-manual/qemu.rst
+++ b/documentation/dev-manual/qemu.rst
@@ -53,12 +53,13 @@ available. Follow these general steps to run QEMU:
 #. *Setting Up the Environment:* How you set up the QEMU environment
    depends on how you installed QEMU:
 
-   -  If you cloned the ``poky`` repository or you downloaded and
-      unpacked a Yocto Project release tarball, you can source the build
-      environment script (i.e. :ref:`structure-core-script`)::
+   -  If you followed :doc:`/dev-manual/start`, either use ``bitbake-setup`` or source
+      the environment setup script manually::
 
-         $ cd poky
-         $ source oe-init-build-env
+      .. code-block:: console
+
+         $ cd bitbake-builds
+         $ source layers/openembedded-core/oe-init-build-env
 
    -  If you installed a cross-toolchain, you can run the script that
       initializes the toolchain. For example, the following commands run

-- 
2.52.0

[PATCH v2 44/56] dev-manual/upgrading-recipes.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/dev-manual/upgrading-recipes.rst | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/documentation/dev-manual/upgrading-recipes.rst b/documentation/dev-manual/upgrading-recipes.rst
index 2e6567867..c4199d160 100644
--- a/documentation/dev-manual/upgrading-recipes.rst
+++ b/documentation/dev-manual/upgrading-recipes.rst
@@ -84,12 +84,12 @@ The following steps describe how to set up the AUH utility:
    AUH is not part of the :term:`OpenEmbedded-Core (OE-Core)` or
    :term:`Poky` repositories.
 
-#. *Create a Dedicated Build Directory:* Run the :ref:`structure-core-script`
+#. *Create a Dedicated Build Directory:* Create a new :term:`bitbake:Setup` with
+   ``bitbake-setup`` or manually run the :ref:`structure-core-script`
    script to create a fresh :term:`Build Directory` that you use exclusively
    for running the AUH utility::
 
-      $ cd poky
-      $ source oe-init-build-env your_AUH_build_directory
+      $ source layers/openembedded-core/oe-init-build-env your_AUH_build_directory
 
    Re-using an existing :term:`Build Directory` and its configurations is not
    recommended as existing settings could cause AUH to fail or behave
@@ -121,7 +121,7 @@ The following steps describe how to set up the AUH utility:
 
       .. note::
 
-         If your distro does not enable by default ptest, which Poky
+         If your distro does not enable by default ptest, which :term:`Poky`
          does, you need the following in your ``local.conf`` file::
 
                  DISTRO_FEATURES:append = " ptest"
@@ -143,7 +143,7 @@ The following steps describe how to set up the AUH utility:
    described earlier, you must enable it in ``upgrade-helper.conf``.
 
    Also, if you are using the default ``maintainers.inc`` file supplied
-   with Poky and located in ``meta-yocto`` and you do not set a
+   in :term:`OpenEmbedded-Core (OE-Core)` and you do not set a
    "maintainers_whitelist" or "global_maintainer_override" in the
    ``upgrade-helper.conf`` configuration, and you specify "-e all" on
    the AUH command-line, the utility automatically sends out emails to
@@ -263,7 +263,7 @@ directory automatically upgrades the recipe for you::
 
    $ devtool upgrade nano -V 2.9.3
    NOTE: Starting bitbake server...
-   NOTE: Creating workspace layer in /home/scottrif/poky/build/workspace
+   NOTE: Creating workspace layer in /home/scottrif/bitbake-builds/build/workspace
    Parsing recipes: 100% |##########################################| Time: 0:00:46
    Parsing of 1431 .bb files complete (0 cached, 1431 parsed). 2040 targets, 56 skipped, 0 masked, 0 errors.
    NOTE: Extracting current version source...
@@ -275,8 +275,8 @@ directory automatically upgrades the recipe for you::
    NOTE: Executing RunQueue Tasks
    NOTE: Tasks Summary: Attempted 74 tasks of which 72 didn't need to be rerun and all succeeded.
    Adding changed files: 100% |#####################################| Time: 0:00:00
-   NOTE: Upgraded source extracted to /home/scottrif/poky/build/workspace/sources/nano
-   NOTE: New recipe is /home/scottrif/poky/build/workspace/recipes/nano/nano_2.9.3.bb
+   NOTE: Upgraded source extracted to /home/scottrif/bitbake-builds/build/workspace/sources/nano
+   NOTE: New recipe is /home/scottrif/bitbake-builds/build/workspace/recipes/nano/nano_2.9.3.bb
 
 .. note::
 
@@ -298,7 +298,7 @@ newly upgraded recipe::
           .
    NOTE: Executing SetScene Tasks
    NOTE: Executing RunQueue Tasks
-   NOTE: nano: compiling from external source tree /home/scottrif/poky/build/workspace/sources/nano
+   NOTE: nano: compiling from external source tree /home/scottrif/bitbake-builds/build/workspace/sources/nano
    NOTE: Tasks Summary: Attempted 520 tasks of which 304 didn't need to be rerun and all succeeded.
 
 Within the ``devtool upgrade`` workflow, you can
@@ -320,8 +320,8 @@ directory::
    NOTE: Adding new patch 0001-nano.bb-Stuff-I-changed-when-upgrading-nano.bb.patch
    NOTE: Updating recipe nano_2.9.3.bb
    NOTE: Removing file /home/scottrif/meta-openembedded/meta-oe/recipes-support/nano/nano_2.7.4.bb
-   NOTE: Moving recipe file to /home/scottrif/meta-openembedded/meta-oe/recipes-support/nano
-   NOTE: Leaving source tree /home/scottrif/poky/build/workspace/sources/nano as-is; if you no longer need it then please delete it manually
+   NOTE: Moving recipe file to /home/scottrif/layers/meta-openembedded/meta-oe/recipes-support/nano
+   NOTE: Leaving source tree /home/scottrif/bitbake-builds/build/workspace/sources/nano as-is; if you no longer need it then please delete it manually
 
 
 Using the ``devtool finish`` command cleans up the workspace and creates a patch

-- 
2.52.0

[PATCH v2 45/56] dev-manual/vulnerabilities.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete. Mention
that only vulnerabilities in OpenEmbedded-Core are tracked as that's
where the packages are.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/security-manual/vulnerabilities.rst | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/documentation/security-manual/vulnerabilities.rst b/documentation/security-manual/vulnerabilities.rst
index 6eaf75758..e6135a525 100644
--- a/documentation/security-manual/vulnerabilities.rst
+++ b/documentation/security-manual/vulnerabilities.rst
@@ -3,8 +3,8 @@
 Checking for Vulnerabilities
 ****************************
 
-Vulnerabilities in Poky and OE-Core
-===================================
+Vulnerabilities in OpenEmbedded-Core (OE-Core)
+==============================================
 
 The Yocto Project has an infrastructure to track and address unfixed
 known security vulnerabilities, as tracked by the public
@@ -13,15 +13,15 @@ database.
 
 The Yocto Project maintains a `list of known vulnerabilities
 <https://valkyrie.yocto.io/pub/non-release/patchmetrics/>`__
-for packages in Poky and OE-Core, tracking the evolution of the number of
+for packages in :term:`OpenEmbedded-Core (OE-Core)`, tracking the evolution of the number of
 unpatched CVEs and the status of patches. Such information is available for
 the current development version and for each supported release.
 
 Security is a process, not a product, and thus at any time, a number of security
-issues may be impacting Poky and OE-Core. It is up to the maintainers, users,
+issues may be impacting :term:`OpenEmbedded-Core (OE-Core)`. It is up to the maintainers, users,
 contributors and anyone interested in the issues to investigate and possibly fix them by
 updating software components to newer versions or by applying patches to address them.
-It is recommended to work with Poky and OE-Core upstream maintainers and submit
+It is recommended to work with :term:`OpenEmbedded-Core (OE-Core)` upstream maintainers and submit
 patches to fix them, see ":doc:`/contributor-guide/submit-changes`" for details.
 
 Vulnerability check at build time
@@ -34,7 +34,7 @@ add the following setting to your configuration::
    INHERIT += "cve-check"
 
 The CVE database contains some old incomplete entries which have been
-deemed not to impact Poky or OE-Core. These CVE entries can be excluded from the
+deemed not to impact :term:`OpenEmbedded-Core (OE-Core)`. These CVE entries can be excluded from the
 check using build configuration::
 
    include conf/distro/include/cve-extra-exclusions.inc
@@ -167,7 +167,7 @@ the :term:`CVE_VERSION` variable.
 
 Note that if the CVE entries in the NVD database contain bugs or have missing or incomplete
 information, it is recommended to fix the information there directly instead of working
-around the issues possibly for a long time in Poky and OE-Core side recipes. Feedback to
+around the issues possibly for a long time in :term:`OpenEmbedded-Core (OE-Core)` side recipes. Feedback to
 NVD about CVE entries can be provided through the `NVD contact form <https://nvd.nist.gov/info/contact-form>`__.
 
 Fixing vulnerabilities in recipes
@@ -175,7 +175,7 @@ Fixing vulnerabilities in recipes
 
 Suppose a CVE security issue impacts a software component. In that case, it can
 be fixed by updating to a newer version, by applying a patch, or by marking it
-as patched via :term:`CVE_STATUS` variable flag. For Poky and OE-Core master
+as patched via :term:`CVE_STATUS` variable flag. For OE-Core master
 branches, updating to a more recent software component release with fixes is
 the best option, but patches can be applied if releases are not yet available.
 
@@ -276,8 +276,8 @@ The entry should have the format like::
    CVE_STATUS[CVE-2016-10642] = "cpe-incorrect: This is specific to the npm package that installs cmake, so isn't relevant to OpenEmbedded"
 
 As mentioned previously, if data in the CVE database is wrong, it is recommended
-to fix those issues in the CVE database (NVD in the case of OE-core and Poky)
-directly.
+to fix those issues in the CVE database (NVD in the case of
+:term:`OpenEmbedded-Core (OE-Core)`) directly.
 
 Note that if there are many CVEs with the same status and reason, those can be
 shared by using the :term:`CVE_STATUS_GROUPS` variable.

-- 
2.52.0

[PATCH v2 46/56] ref-manual/devtool-reference.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/ref-manual/devtool-reference.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/documentation/ref-manual/devtool-reference.rst b/documentation/ref-manual/devtool-reference.rst
index 5ac567591..863825b06 100644
--- a/documentation/ref-manual/devtool-reference.rst
+++ b/documentation/ref-manual/devtool-reference.rst
@@ -346,7 +346,7 @@ variables in package recipes.
       mechanisms cannot find the new upstream versions.
 
    -  For the ``oe-core`` layer, recipe maintainers come from the
-      :yocto_git:`maintainers.inc </poky/tree/meta/conf/distro/include/maintainers.inc>`
+      :oe_git:`maintainers.inc </openembedded-core/tree/meta/conf/distro/include/maintainers.inc>`
       file.
 
    -  If the recipe is using the :ref:`bitbake-user-manual/bitbake-user-manual-fetching:git fetcher (\`\`git://\`\`)`
@@ -390,8 +390,8 @@ In this example, while a new version is available upstream, you do not
 want to use it because the dependency on ``cdebconf`` is not easily
 satisfied. Maintainers can explicit the reason that is shown by adding
 the :term:`RECIPE_NO_UPDATE_REASON` variable to the corresponding recipe.
-See :yocto_git:`base-passwd.bb </poky/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb?h=kirkstone>`
-for an example::
+See the :oe_git:`base-passwd_*.bb </openembedded-core/tree/meta/recipes-core/base-passwd/>`
+recipe for an example::
 
    RECIPE_NO_UPDATE_REASON = "Version 3.5.38 requires cdebconf for update-passwd utility"
 
@@ -460,7 +460,7 @@ Here is an example that resets the workspace directory that contains the
 
    $ devtool reset mtr
    NOTE: Cleaning sysroot for recipe mtr...
-   NOTE: Leaving source tree /home/scottrif/poky/build/workspace/sources/mtr as-is; if you no longer need it then please delete it manually
+   NOTE: Leaving source tree /home/scottrif/bitbake-builds/build/workspace/sources/mtr as-is; if you no longer need it then please delete it manually
    $
 
 .. _devtool-finish-working-on-a-recipe:
@@ -633,7 +633,7 @@ Here is sample output after using
 to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory::
 
    $ devtool status
-   mtr:/home/scottrif/poky/build/workspace/sources/mtr (/home/scottrif/poky/build/workspace/recipes/mtr/mtr_0.86.bb)
+   mtr:/home/scottrif/bitbake-builds/build/workspace/sources/mtr (/home/scottrif/bitbake-builds/build/workspace/recipes/mtr/mtr_0.86.bb)
    $
 
 .. _devtool-search-for-available-target-recipes:

-- 
2.52.0

[PATCH v2 47/56] ref-manual/faq.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Rework the difference between Poky and OpenEmbedded. Copy the note from
terms.rst regarding the now obsolete Poky repository.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/ref-manual/faq.rst | 43 ++++++++++++++++++++++++++++++----------
 1 file changed, 32 insertions(+), 11 deletions(-)

diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
index 6c5b9d4e7..7557a7269 100644
--- a/documentation/ref-manual/faq.rst
+++ b/documentation/ref-manual/faq.rst
@@ -12,14 +12,35 @@ General questions
 How does Poky differ from OpenEmbedded?
 ---------------------------------------
 
-The term ``Poky`` refers to the specific reference build
-system that the Yocto Project provides. Poky is based on
-:term:`OpenEmbedded-Core (OE-Core)` and :term:`BitBake`. Thus, the
-generic term used here for the build system is the "OpenEmbedded build
-system." Development in the Yocto Project using Poky is closely tied to
-OpenEmbedded, with changes always being merged to OE-Core or BitBake
-first before being pulled back into Poky. This practice benefits both
-projects immediately.
+The term :term:`Poky` refers to the reference distribution that the Yocto
+Project provides, and a reference test configuration.
+
+The :term:`Poky` distribution is built using the :term:`OpenEmbedded Build
+System` and :term:`BitBake`. The :term:`metadata` used involved to build the
+:term:`Poky` reference distribution is:
+
+-  :term:`OpenEmbedded-Core (OE-Core)`, which is hosted at
+   :oe_git:`/openembedded-core`.
+
+-  :yocto_git:`meta-poky <meta-yocto/tree/meta-poky>`, which defines the
+   ``poky`` distro configuration file (:term:`DISTRO`).
+
+.. note::
+
+   Poky also used to be a repository containing the combination of
+   :term:`BitBake`, :term:`OpenEmbedded-Core (OE-Core)`, the
+   :yocto_git:`meta-yocto </meta-yocto>` repository and the Yocto Project
+   documentation -- which were combined with the :yocto_git:`combo-layer
+   </poky-config>` tool.
+
+   This repository is still hosted at :yocto_git:`/poky` and is still
+   updated for maintained releases that are older than Whinlatter (5.3).
+   Newer releases now use ``bitbake-setup`` to clone and setup the initial
+   :term:`OpenEmbedded Build System` environment. For more information on
+   how to use ``bitbake-setup``, see the :doc:`/brief-yoctoprojectqs/index`
+   document. An alternative can be to setup the above repositories
+   manually, by following the :doc:`/dev-manual/poky-manual-setup`
+   section of the Yocto Project Development Tasks Manual.
 
 How can you claim Poky / OpenEmbedded-Core is stable?
 -----------------------------------------------------
@@ -27,7 +48,7 @@ How can you claim Poky / OpenEmbedded-Core is stable?
 There are three areas that help with stability;
 
 -  The Yocto Project team keeps :term:`OpenEmbedded-Core (OE-Core)` small and
-   focused, containing around 830 recipes as opposed to the thousands
+   focused, containing around a thousand recipes as opposed to the thousands
    available in other OpenEmbedded community layers. Keeping it small
    makes it easy to test and maintain.
 
@@ -87,8 +108,8 @@ configurable. You can setup the build system to get source code in most
 environments if HTTP transport is available.
 
 When the build system searches for source code, it first tries the local
-download directory. If that location fails, Poky tries
-:term:`PREMIRRORS`, the upstream source, and then
+download directory. If that location fails, the :term:`OpenEmbedded Build
+System` tries :term:`PREMIRRORS`, the upstream source, and then
 :term:`MIRRORS` in that order.
 
 Assuming your distribution is "poky", the OpenEmbedded build system uses

-- 
2.52.0

[PATCH v2 48/56] ref-manual/features.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/ref-manual/features.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/ref-manual/features.rst b/documentation/ref-manual/features.rst
index df3783089..be67bc0ea 100644
--- a/documentation/ref-manual/features.rst
+++ b/documentation/ref-manual/features.rst
@@ -28,7 +28,7 @@ a particular feature is contained or not is to ``grep`` through the
 discovers the recipes whose build is potentially changed based on a
 given feature::
 
-   $ cd poky
+   $ cd openembedded-core
    $ git grep 'contains.*MACHINE_FEATURES.*feature'
 
 .. _ref-features-machine:

-- 
2.52.0

[PATCH v2 49/56] ref-manual/release-process.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/ref-manual/release-process.rst | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/documentation/ref-manual/release-process.rst b/documentation/ref-manual/release-process.rst
index 165dfb86d..a75ca52cc 100644
--- a/documentation/ref-manual/release-process.rst
+++ b/documentation/ref-manual/release-process.rst
@@ -232,10 +232,12 @@ efficiently.
 
 The Yocto Project's main :yocto_ab:`Autobuilder <>` publicly tests each Yocto
 Project release's code in the :oe_git:`openembedded-core </openembedded-core>`,
-:yocto_git:`poky </poky>` and :oe_git:`bitbake </bitbake>` repositories. The
+:yocto_git:`meta-yocto </meta-yocto>` and :oe_git:`bitbake </bitbake>` repositories. The
 testing occurs for both the current state of the "master" branch and also for
 submitted patches. Testing for submitted patches usually occurs in the
-in the "master-next" branch in the :yocto_git:`poky </poky>` repository.
+in the "master-next" branch in the :oe_git:`openembedded-core
+</openembedded-core>`, :yocto_git:`meta-yocto </meta-yocto>` and
+:oe_git:`bitbake </bitbake>` repository.
 
 .. note::
 

-- 
2.52.0

[PATCH v2 50/56] ref-manual/release-process.rst: remove repeated "in the"

[Antonin Godard]

Reported-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/ref-manual/release-process.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/ref-manual/release-process.rst b/documentation/ref-manual/release-process.rst
index a75ca52cc..a55187c14 100644
--- a/documentation/ref-manual/release-process.rst
+++ b/documentation/ref-manual/release-process.rst
@@ -234,7 +234,7 @@ The Yocto Project's main :yocto_ab:`Autobuilder <>` publicly tests each Yocto
 Project release's code in the :oe_git:`openembedded-core </openembedded-core>`,
 :yocto_git:`meta-yocto </meta-yocto>` and :oe_git:`bitbake </bitbake>` repositories. The
 testing occurs for both the current state of the "master" branch and also for
-submitted patches. Testing for submitted patches usually occurs in the
+submitted patches. Testing for submitted patches usually occurs
 in the "master-next" branch in the :oe_git:`openembedded-core
 </openembedded-core>`, :yocto_git:`meta-yocto </meta-yocto>` and
 :oe_git:`bitbake </bitbake>` repository.

-- 
2.52.0

[PATCH v2 51/56] ref-manual/system-requirements.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/ref-manual/system-requirements.rst | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst
index a56e683ca..9b681290e 100644
--- a/documentation/ref-manual/system-requirements.rst
+++ b/documentation/ref-manual/system-requirements.rst
@@ -405,8 +405,8 @@ installer and automatically installs the tools for you:
 
 #. Execute the ``install-buildtools`` script. Here is an example::
 
-      $ cd poky
-      $ scripts/install-buildtools \
+      $ cd /path/to/bitbake-builds
+      $ ./layers/openembedded-core/scripts/install-buildtools \
         --without-extended-buildtools \
         --base-url &YOCTO_DL_URL;/releases/yocto \
         --release yocto-&DISTRO; \
@@ -420,26 +420,26 @@ installer and automatically installs the tools for you:
    To avoid the need of ``sudo`` privileges, the ``install-buildtools``
    script will by default tell the installer to install in::
 
-      /path/to/poky/buildtools
+      /path/to/bitbake-builds/buildtools
 
    If your host development system needs the additional tools provided
    in the :term:`buildtools-extended` tarball, you can instead execute the
    ``install-buildtools`` script with the default parameters::
 
-      $ cd poky
+      $ cd /path/to/bitbake-builds
       $ scripts/install-buildtools
 
    Alternatively if your host development system has a broken ``make``
    version such that you only need a known good version of ``make``,
    you can use the ``--make-only`` option::
 
-      $ cd poky
+      $ cd /path/to/bitbake-builds
       $ scripts/install-buildtools --make-only
 
 #. Source the tools environment setup script by using a command like the
    following::
 
-      $ source /path/to/poky/buildtools/environment-setup-x86_64-pokysdk-linux
+      $ source /path/to/bitbake-builds/buildtools/environment-setup-x86_64-pokysdk-linux
 
    After you have sourced the setup script, the tools are added to
    ``PATH`` and any other environment variables required to run the

-- 
2.52.0

[PATCH v2 52/56] ref-manual/system-requirements.rst: fix wrong path to install-buildtools

[Antonin Godard]

Reported-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/ref-manual/system-requirements.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst
index 9b681290e..f9f32f2a8 100644
--- a/documentation/ref-manual/system-requirements.rst
+++ b/documentation/ref-manual/system-requirements.rst
@@ -427,14 +427,14 @@ installer and automatically installs the tools for you:
    ``install-buildtools`` script with the default parameters::
 
       $ cd /path/to/bitbake-builds
-      $ scripts/install-buildtools
+      $ ./layers/openembedded-core/scripts/install-buildtools
 
    Alternatively if your host development system has a broken ``make``
    version such that you only need a known good version of ``make``,
    you can use the ``--make-only`` option::
 
       $ cd /path/to/bitbake-builds
-      $ scripts/install-buildtools --make-only
+      $ ./layers/openembedded-core/scripts/install-buildtools --make-only
 
 #. Source the tools environment setup script by using a command like the
    following::

-- 
2.52.0

[PATCH v2 53/56] ref-manual/yocto-project-supported-features.rst: remove obsolete poky repo reference

[Antonin Godard]

Poky -> meta-yocto link replacement.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/ref-manual/yocto-project-supported-features.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/ref-manual/yocto-project-supported-features.rst b/documentation/ref-manual/yocto-project-supported-features.rst
index eeae6b24a..021fca36b 100644
--- a/documentation/ref-manual/yocto-project-supported-features.rst
+++ b/documentation/ref-manual/yocto-project-supported-features.rst
@@ -59,7 +59,7 @@ Below is a list of primary tested features, their maintainer(s) and builder(s):
        qemuarm64-ptest,
        qemuarm64-tc,
        qemuarmv5
-   * - :yocto_git:`Beaglebone </poky/tree/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf>`
+   * - :yocto_git:`Beaglebone </meta-yocto/tree/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf>`
      - Beaglebone image and SDK build testing
      - Collective effort
      - beaglebone,

-- 
2.52.0

[PATCH v2 54/56] test-manual/reproducible-builds.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/test-manual/reproducible-builds.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/documentation/test-manual/reproducible-builds.rst b/documentation/test-manual/reproducible-builds.rst
index 336bb7f26..84523ff13 100644
--- a/documentation/test-manual/reproducible-builds.rst
+++ b/documentation/test-manual/reproducible-builds.rst
@@ -81,10 +81,10 @@ it always depends upon the paths it is built in.
 
 .. note::
 
-   Only BitBake and :term:`OpenEmbedded-Core (OE-Core)`, which is the ``meta``
-   layer in Poky, guarantee complete reproducibility. The moment you add
-   another layer, this warranty is voided, because of additional configuration
-   files, ``bbappend`` files, overridden classes, etc.
+   Only BitBake and :term:`OpenEmbedded-Core (OE-Core)` guarantee complete
+   reproducibility. The moment you add another layer, this warranty is voided,
+   because of additional configuration files, ``bbappend`` files, overridden
+   classes, etc.
 
 To run our automated selftest, as we use in our CI on the Autobuilder, you can
 run::

-- 
2.52.0

[PATCH v2 55/56] test-manual/understand-autobuilder.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/test-manual/understand-autobuilder.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/documentation/test-manual/understand-autobuilder.rst b/documentation/test-manual/understand-autobuilder.rst
index 23b3ef7d7..0015c2e57 100644
--- a/documentation/test-manual/understand-autobuilder.rst
+++ b/documentation/test-manual/understand-autobuilder.rst
@@ -102,9 +102,9 @@ roughly consist of:
 #. *Call scripts/shared-repo-unpack*
 
    This is a call into the Helper scripts to set up a checkout of all
-   the pieces this build might need. It might clone the BitBake
-   repository and the OpenEmbedded-Core repository. It may clone the
-   Poky repository, as well as additional layers. It will use the data
+   the pieces this build might need. It might clone the :term:`BitBake`
+   repository, the :term:`OpenEmbedded-Core (OE-Core)` repository as well as
+   additional layers. It will use the data
    from the ``layerinfo.json`` file to help understand the
    configuration. It will also use a local cache of repositories to
    speed up the clone checkouts. For additional information, see

-- 
2.52.0

[PATCH v2 56/56] what-i-wish-id-known.rst: remove obsolete poky repo references

[Antonin Godard]

Refresh the document now that the Poky repository is obsolete.

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
 documentation/what-i-wish-id-known.rst | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/documentation/what-i-wish-id-known.rst b/documentation/what-i-wish-id-known.rst
index ddee6ad74..36cf715fa 100644
--- a/documentation/what-i-wish-id-known.rst
+++ b/documentation/what-i-wish-id-known.rst
@@ -60,8 +60,9 @@ contact us with other suggestions.
    layers, on the other hand, helps keep simplify future customizations and
    reuse.
 
-#. **Never modify the POKY layer. Never. Ever. When you update to the next
-   release, you'll lose all of your work. ALL OF IT.**
+#. **Never modify the core layers** (:term:`BitBake`, :term:`OpenEmbedded-Core
+   (OE-Core)` and possibly :yocto_git:`meta-yocto </meta-yocto>`). Never. Ever.
+   When you update to the next release, you'll lose all of your work. ALL OF IT.**
 
 #. **Don't be fooled by documentation searching results:**
    Yocto Project documentation is always being updated. Unfortunately, when you

-- 
2.52.0

Re: [docs] [PATCH v2 02/56] dev-manual/poky-manual-setup.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:18 AM, Antonin Godard via lists.yoctoproject.org wrote:
> The commit "dev-manual/start.rst: simplify the document after poky
> obsolescence" removed some of the information related to source archives
> published on downloads.yoctoproject.org. Mention it in this document as
> it makes sense to use those when manually setting up a Poky build.
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 03/56] dev-manual/start.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:18 AM, Antonin Godard via lists.yoctoproject.org wrote:
> The Poky repository has stopped being updated in favor of bitbake-setup
> or manual clones of the required repositories. Simplify the document by
> making references to these guides as well as removing sections that
> are covered in the references documents.
> 
> Keep a "Initializing the Build Environment" as this task is common and
> referenced in different places in the documentation.
> 
> Remove the tarball instructions as those will be moved in the
> poky-manual-setup document.
> 

Weren't they moved in the previous patch?

> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---

[...]

> -You will find there source archives of individual components (if you wish
> -to use them individually), and of the corresponding Poky release bundling
> -a selection of these components.
> +Initializing the build environment is a common task, as it needs to be done for
> +each new instance of the shell where the :term:`Poky` reference was set up:

+distro?

With that,

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 04/56] bsp-guide/bsp.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:18 AM, Antonin Godard via lists.yoctoproject.org wrote:
[...]
> diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
> index 056f69249..49527f45d 100644
> --- a/documentation/bsp-guide/bsp.rst
> +++ b/documentation/bsp-guide/bsp.rst
[...]
> @@ -224,18 +220,21 @@ section.
>         Resolving deltas: 100% (2447/2447), done.
>         Checking connectivity... done.
>   
> -#. *Initialize the Build Environment:* While in the root directory of
> -   the Source Directory (i.e. ``poky``), run the
> -   :ref:`ref-manual/structure:``oe-init-build-env``` environment
> -   setup script to define the OpenEmbedded build environment on your
> -   build host. ::
> +#. *Initialize the Build Environment:* While in the :term:`Source Directory`,
> +run the :ref:`ref-manual/structure:``oe-init-build-env``` environment setup
> +script located in :term:`OpenEmbedded-Core (OE-Core)` to define the OpenEmbedded
> +build environment on your build host. ::
>   

Shouldn't the three lines above be prefixed by three whitespaces?

Actually, probably should be 4 and have two spaces between #. and 
*Initialize* since that's the rule we have for lists. I see most of the 
lists in the diff in this patch don't follow the rule so I guess that's 
not a blocker :)

> -      $ source oe-init-build-env
> +      $ source layers/openembedded-core/oe-init-build-env
>   
>      Among other things, the script creates the :term:`Build Directory`, which is
> -   ``build`` in this case and is located in the :term:`Source Directory`.  After
> -   the script runs, your current working directory is set to the ``build``
> -   directory.
> +   :term:`Build Directory`. After the script runs, your current working directory 

s/:term:`Build Directory`/"build"/

otherwise this says "Build Directory, which is Build Directory".

is set to
> +   the :term:`Build Directory` directory.
> +
> +   .. note::
> +
> +      Alternatively, you can source the ``init-build-env`` file provided by
> +      :doc:`bitbake-setup <bitbake:bitbake-user-manual/bitbake-user-manual-environment-setup>`
>   

You didn't answer the question on v1 so posting it here again:

Can we set up using bitbake-setup and then source oe-init-buildenv from
oe-core? Or vice-versa. The wording seems to imply that.

Isn't most the above not applicable if we use bitbake-setup anyway?

With the three whitespaces and sed command above,

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Please consider answering the question even if merging the patch with 
the few requested changes.

Thanks!
Quentin

Re: [docs] [PATCH v2 05/56] kernel-dev/advanced.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Remove references to the Poky repository, replace by OpenEmbedded-Core
> in most cases, and refer to bitbake-setup or the manual setup in the
> intro.
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>

This patch seems unchanged since v1 and had given my R-b back then, so 
adding it again:

Reviewed-by: Quentin Schulz <quentin.schuzl@cherry.de>

Minor comment below.

> ---
>   documentation/kernel-dev/advanced.rst | 12 +++++-------
>   1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/documentation/kernel-dev/advanced.rst b/documentation/kernel-dev/advanced.rst
> index 4c463503f6..97cb663222 100644
> --- a/documentation/kernel-dev/advanced.rst
> +++ b/documentation/kernel-dev/advanced.rst
> @@ -24,9 +24,8 @@ grouped under the "Yocto Linux Kernel" heading in the
>   Kernel development tools ("kern-tools") are also available in the Yocto Project
>   Source Repositories under the "Yocto Linux Kernel" heading in the
>   ``yocto-kernel-tools`` Git repository. The recipe that builds these
> -tools is ``meta/recipes-kernel/kern-tools/kern-tools-native_git.bb`` in
> -the :term:`Source Directory` (e.g.
> -``poky``).
> +tools is ``recipes-kernel/kern-tools/kern-tools-native_git.bb`` in

Could use a oe_git link here.

Thanks!
Quentin

Re: [docs] [PATCH v2 06/56] contributor-guide/submit-changes.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Remove references to the Poky repository, replace by OpenEmbedded-Core
> in most cases.
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   documentation/contributor-guide/submit-changes.rst | 57 ++++++----------------
>   1 file changed, 14 insertions(+), 43 deletions(-)
> 
> diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst
> index 07989d7b6..4a4c60b41 100644
> --- a/documentation/contributor-guide/submit-changes.rst
> +++ b/documentation/contributor-guide/submit-changes.rst
> @@ -429,37 +429,6 @@ and then based on successful testing, merges them.
>   In general, each component (e.g. layer) should have a ``README`` file
>   that indicates where to send the changes and which process to follow.
>   
> -The "poky" repository, which is the Yocto Project's reference build
> -environment, is a hybrid repository that contains several individual
> -pieces (e.g. BitBake, Metadata, documentation, and so forth) built using
> -the combo-layer tool. The upstream location used for submitting changes
> -varies by component:
> -
> --  *Core Metadata:* Send your patches to the
> -   :oe_lists:`openembedded-core </g/openembedded-core>`
> -   mailing list. For example, a change to anything under the ``meta`` or
> -   ``scripts`` directories should be sent to this mailing list.
> -
> --  *BitBake:* For changes to BitBake (i.e. anything under the
> -   ``bitbake`` directory), send your patches to the
> -   :oe_lists:`bitbake-devel </g/bitbake-devel>`
> -   mailing list.
> -
> --  *meta-poky* and *meta-yocto-bsp* trees: These trees contain Metadata. Use the
> -   :yocto_lists:`poky </g/poky>` mailing list.
> -
> --  *Documentation*: For changes to the Yocto Project documentation, use the
> -   :yocto_lists:`docs </g/docs>` mailing list.
> -
> -For changes to other layers and tools hosted in the Yocto Project source
> -repositories (i.e. :yocto_git:`git.yoctoproject.org <>`), use the
> -:yocto_lists:`yocto-patches </g/yocto-patches/>` general mailing list.
> -
> -For changes to other layers hosted in the OpenEmbedded source
> -repositories (i.e. :oe_git:`git.openembedded.org <>`), use
> -the :oe_lists:`openembedded-devel </g/openembedded-devel>`
> -mailing list, unless specified otherwise in the layer's ``README`` file.
> -
>   If you intend to submit a new recipe that neither fits into the core Metadata,

In this patch, we just removed what we meant by Core Metadata, so now 
this can be quite confusing. Should we simply state OpenEmbedded-Core?

Also, how does one knows if the recipe can fit into OE-Core? (we do have 
some rules as to what's acceptable, must be a direct and default 
dependency of some other recipe in OE-Core, or with a demonstrable 
valuable benefit for OE-Core).

[...]

> @@ -857,14 +825,17 @@ used testing branches for OpenEmbedded-Core are as follows:
>      :oe_git:`openembedded-core </openembedded-core/>` repository and contains
>      proposed changes to the core metadata.
>   
> --  *poky "master-next" branch:* This branch is part of the
> -   :yocto_git:`poky </poky/>` repository and combines proposed
> -   changes to BitBake, the core metadata and the poky distro.
> +- *bitbake "master-next" branch:* This branch is part of the :oe_git:`bitbake
> +  </bitbake/>` repository and contains changes to :term:`BitBake`.
> +

Missing a (second) whitespace after - in the first line and a third 
whitespace in the second line.

Cheers,
Quentin

Re: [docs] [PATCH v2 11/56] dev-manual/layers.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
[...]
> -#. *Create a Directory:* Create the directory for your layer. When you
> -   create the layer, be sure to create the directory in an area not
> -   associated with the Yocto Project :term:`Source Directory`
> -   (e.g. the cloned ``poky`` repository).
> +   .. note::
> +
> +      For information on BSP layers, see the ":ref:`bsp-guide/bsp:bsp layers`"
> +      section in the Yocto Project Board Specific (BSP) Developer's Guide.
> +
> +#. *Create a new Layer:* Create the directory for your layer. The
> +   ``bitbake-layers`` script with the ``create-layer`` subcommand simplifies
> +   creating a new general layer. Place it next to the other layers in your
> +   :term:`Source Directory`.
> +
> +   In its simplest form, you can use the following command to create a
> +   layer named "your_layer_name" in the current directory.
> +

suggestion: s/./:/

[...]
> +   The default mode of the script's operation with this subcommand is to

suggestion: to make it a bit easier to read:

By default, the ``bitbake-layers create-layer`` command creates a layer 
with the following:

> +   create a layer with the following:
> +
> +   -  A ``conf/layer.conf`` configuration file with default definitions.
> +
> +      Here is an explanation of the typical content of the layer configuration file:
> +
> +      -  :term:`BBPATH`: Adds the layer's root directory to BitBake's search
> +         path. Through the use of the :term:`BBPATH` variable, BitBake locates
> +         class files (``.bbclass``), configuration files, and files that are
> +         included with ``include`` and ``require`` statements. For these cases,

suggestion: cross-reference include and require directive? (separate 
patch/series)

> +         BitBake uses the first file that matches the name found in
> +         :term:`BBPATH`. This is similar to the way the ``PATH`` variable is
> +         used for binaries. It is recommended, therefore, that you use unique
> +         class and configuration filenames in your custom layer.
> +
> +         See the :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:Locating Include
> +         Files` section of the BitBake User Manual for more details on how
> +         files are included with :term:`BitBake`.
> +
> +      -  :term:`BBFILES`: Defines the location for all recipes in the layer.
> +

suggestion: mention bbappend as well (separate patch/series)

> +      -  :term:`BBFILE_COLLECTIONS`: Establishes the current layer through a
> +         unique identifier that is used throughout the :term:`OpenEmbedded Build
> +         System` to refer to the layer. In this example, the identifier
> +         "yoctobsp" is the representation for the container layer named
> +         "meta-yocto-bsp".
> +

suggestion: :yocto_git: link (separate patch/series)

> +         This name is used by other layers when specifying the layer
> +         dependencies via the :term:`LAYERDEPENDS` variable.
> +
> +      -  :term:`BBFILE_PATTERN`: Expands immediately during parsing to provide
> +         the directory of the layer.
> +
> +      -  :term:`BBFILE_PRIORITY`: Establishes a priority to use for recipes in
> +         the layer when the :term:`OpenEmbedded Build System` finds recipes of
> +         the same name in different layers.
> +
> +      -  :term:`LAYERVERSION`: Establishes a version number for the layer. You
> +         can use this version number to specify this exact version of the layer
> +         as a dependency when using the :term:`LAYERDEPENDS` variable.
> +
> +      -  :term:`LAYERDEPENDS`: Lists all layers on which this layer depends (if
> +         any). It uses the layer names specified by the
> +         :term:`BBFILE_COLLECTIONS` variable.
> +
> +      -  :term:`LAYERSERIES_COMPAT`: Lists the :yocto_home:`Yocto Project
> +         releases </development/releases/>` codenames (in lowercase) for which

s/releases/release/

suggestion: s/for which the current version is compatible/this layer is 
compatible with.

> +         the current version is compatible. For example: "&DISTRO_NAME_NO_CAP;".
> +
> +         This variable is a good way to indicate if your particular layer is

suggestion: s/your/a/

> +         current.
> +
> +   -  A ``recipes-example`` subdirectory that contains a further

suggestion: s/contains a further/itself contains a/

With the s/releases/release/ change:

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 12/56] dev-manual/layers.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Remove references to the Poky repository, replace by OpenEmbedded-Core.
> 

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 14/56] dev-manual/new-recipe.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Remove references to the Poky repository, replace by OpenEmbedded-Core.
> 

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 15/56] dev-manual/securing-images.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Remove references to the Poky repository, replace by OpenEmbedded-Core.
> 

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Minor comment below.

> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   documentation/security-manual/securing-images.rst | 9 +++++----
>   1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/documentation/security-manual/securing-images.rst b/documentation/security-manual/securing-images.rst
> index cc6f95003..e502f83e3 100644
> --- a/documentation/security-manual/securing-images.rst
> +++ b/documentation/security-manual/securing-images.rst
> @@ -50,9 +50,10 @@ more secure:
>   -  Regularly scan and apply fixes for CVE security issues affecting
>      all software components in the product, see ":ref:`security-manual/vulnerabilities:checking for vulnerabilities`".
>   
> --  Regularly update your version of Poky and OE-Core from their upstream
> -   developers, e.g. to apply updates and security fixes from stable
> -   and :term:`LTS` branches.
> +-  Regularly update your version of :term:`BitBake` and your layers (e.g.
> +   :term:`OpenEmbedded-Core (OE-Core)`, :yocto_git:`meta-yocto </meta-yocto/>`,
> +   ...) from their upstream developers, e.g. to apply updates and security fixes

I find the wording a bit odd "update your version [...] from their 
upstream developers".

Maybe we can simply remove the "from their upstream developers" part?

Thanks!
Quentin

Re: [docs] [PATCH v2 19/56] kernel-dev/common.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Remove references to the Poky repository, replace by OpenEmbedded-Core.
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   documentation/kernel-dev/common.rst | 112 +++++++++++++++---------------------
>   1 file changed, 46 insertions(+), 66 deletions(-)
> 
> diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst
> index 2142d31c0..a653d897c 100644
> --- a/documentation/kernel-dev/common.rst
> +++ b/documentation/kernel-dev/common.rst
> @@ -44,25 +44,15 @@ image and ready to make modifications as described in the
>   ":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
>   section:
>   
> -#. *Initialize the BitBake Environment:*
> -   you need to initialize the BitBake build environment by sourcing
> -   the build environment script (i.e. :ref:`structure-core-script`)::
> -
> -      $ cd poky
> -      $ source oe-init-build-env
> -
> -   .. note::
> -
> -      The previous commands assume the
> -      :ref:`overview-manual/development-environment:yocto project source repositories`
> -      (i.e. ``poky``) have been cloned using Git and the local repository is named
> -      "poky".
> +#. *Initialize the Build Environment:* Follow the :doc:`/dev-manual/start`
> +   section of the Yocto Project Development Tasks Manual in order to have a
> +   ready-to-use shell that can execute ``devtool``.
>   
>   #. *Prepare Your local.conf File:* By default, the :term:`MACHINE` variable
>      is set to "qemux86-64", which is fine if you are building for the QEMU
>      emulator in 64-bit mode. However, if you are not, you need to set the
>      :term:`MACHINE` variable appropriately in your ``conf/local.conf`` file
> -   found in the :term:`Build Directory` (i.e.  ``poky/build`` in this example).
> +   found in the :term:`Build Directory` (i.e.  ``bitbake-builds/build`` in this example).
>   

I... just realized that bitbake-setup init actually creates an 
additional directory. It is bitbake-builds/poky-master/build actually. Sigh.

>      Also, since you are preparing to work on the kernel image, you need
>      to set the :term:`MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS` variable to include
> @@ -79,7 +69,7 @@ section:
>      patches created for the kernel image. You can use the
>      ``bitbake-layers create-layer`` command as follows::
>   
> -      $ cd poky/build
> +      $ cd bitbake-builds/build
>         $ bitbake-layers create-layer ../../meta-mylayer

I would suggest to change this path to ../layers/meta-mylayer such that 
it follows our recommendation of having all the layers in the same 
place. In a separate patch/series is fine.

This patch looks fine though,

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 21/56] overview-manual/concepts.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Remove references to the Poky repository, replace by OpenEmbedded-Core.
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   documentation/overview-manual/concepts.rst | 74 ++++++++----------------------
>   1 file changed, 20 insertions(+), 54 deletions(-)
> 
> diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
> index 9ca188960..757ea05cb 100644
> --- a/documentation/overview-manual/concepts.rst
> +++ b/documentation/overview-manual/concepts.rst
> @@ -211,62 +211,28 @@ figure <overview-manual/concepts:openembedded build system concepts>`:
>   BitBake needs some basic configuration files in order to complete a
>   build. These files are ``*.conf`` files. The minimally necessary ones
>   reside as example files in the ``build/conf`` directory of the

s;build/;;

as conf is a directory of :term:`Build Directory`

> -:term:`Source Directory`. For simplicity,
> -this section refers to the Source Directory as the "Poky Directory."
> +:term:`Build Directory`.
>   
> -When you clone the :term:`Poky` Git repository
> -or you download and unpack a Yocto Project release, you can set up the
> -Source Directory to be named anything you want. For this discussion, the
> -cloned repository uses the default name ``poky``.
> +When you :ref:`initialize the build environment <dev-manual/start:Initializing
> +the Build Environment>`, you can set up the :term:`Source Directory` to be named
> +anything you want.
>   

Oof, I don't think that's true. Spaces probably aren't supported for 
example, I vaguely remember some bug report.

Maybe something a bit less extreme like

you can specify which directory will be the :term:`Source Directory`.

> -.. note::
> -
> -   The Poky repository is primarily an aggregation of existing
> -   repositories. It is not a canonical upstream source.
> -
> -The ``meta-poky`` layer inside Poky contains a ``conf`` directory that
> -has example configuration files. These example files are used as a basis
> -for creating actual configuration files when you source
> -:ref:`structure-core-script`, which is the
> -build environment script.
> -
> -Sourcing the build environment script creates a :term:`Build Directory`
> +Setting up the build environment creates a :term:`Build Directory`
>   if one does not already exist. BitBake uses the :term:`Build Directory`
>   for all its work during builds. The Build Directory has a ``conf`` directory
>   that contains default versions of your ``local.conf`` and ``bblayers.conf``
> -configuration files. These default configuration files are created only
> -if versions do not already exist in the :term:`Build Directory` at the time you
> -source the build environment setup script.
> -
> -Because the Poky repository is fundamentally an aggregation of existing
> -repositories, some users might be familiar with running the
> -:ref:`structure-core-script` script in the context of separate
> -:term:`OpenEmbedded-Core (OE-Core)` and BitBake
> -repositories rather than a single Poky repository. This discussion
> -assumes the script is executed from within a cloned or unpacked version
> -of Poky.
> -
> -Depending on where the script is sourced, different sub-scripts are
> -called to set up the :term:`Build Directory` (Yocto or OpenEmbedded).
> -Specifically, the script ``scripts/oe-setup-builddir`` inside the poky
> -directory sets up the :term:`Build Directory` and seeds the directory (if
> -necessary) with configuration files appropriate for the Yocto Project
> -development environment.
> -
> -.. note::
> +configuration files. These default :term:`configuration files <Configuration
> +File>` are created only if versions do not already exist in the :term:`Build

Reported on v1:

s/versions/they/?

> +Directory` at the time you source the build environment setup script.
>   
> -   The
> -   ``scripts/oe-setup-builddir``
> -   script uses the
> -   ``$TEMPLATECONF``
> -   variable to determine which sample configuration files to locate.
> +:term:`Configuration files <Configuration File>` provide many basic variables
> +that define a build environment.  To see a list of possible variables to

Reported on v1:

s/see/show/ to avoid using "see" twice in the same sentence.

s/  / /

> +configure from :term:`configuration files <Configuration File>`, see the
> +:yocto_git:`local.conf.sample
> +</meta-yocto/tree/meta-poky/conf/templates/default/local.conf.sample>` in the
> +``meta-poky`` layer:
>   
> -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 </poky/tree/meta-poky/conf/templates/default/local.conf.sample>`
> -in the ``meta-poky`` layer:
> +Here is a list of a few:
>   

Reported on v1:

s/a list of a few/a non-exhaustive list/ ?

Cheers,
Quentin

Re: [docs] [PATCH v2 22/56] overview-manual/development-environment.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Remove references to the Poky repository, replace by OpenEmbedded-Core.
> Replace the poky examples for the Git section by yocto-docs.
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   .../overview-manual/development-environment.rst    | 83 +++++++++++-----------
>   1 file changed, 41 insertions(+), 42 deletions(-)
> 
> diff --git a/documentation/overview-manual/development-environment.rst b/documentation/overview-manual/development-environment.rst
> index ab9bd084c..0402e3456 100644
> --- a/documentation/overview-manual/development-environment.rst
> +++ b/documentation/overview-manual/development-environment.rst
> @@ -148,44 +148,42 @@ code browser is organized into categories by function such as IDE
>   Plugins, Matchbox, Poky, Yocto Linux Kernel, and so forth. From the
>   interface, you can click on any particular item in the "Name" column and
>   see the URL at the bottom of the page that you need to clone a Git
> -repository for that particular item. Having a local Git repository of
> -the :term:`Source Directory`, which
> -is usually named "poky", allows you to make changes, contribute to the
> +repository for that particular item. Having a local Git clone of
> +these repositories allows you to make changes, contribute to the
>   history, and ultimately enhance the Yocto Project's tools, Board Support
>   Packages, and so forth.
>   
>   For any supported release of Yocto Project, you can also go to the
> -:yocto_home:`Yocto Project Website <>` and select the "DOWNLOADS"
> -item from the "SOFTWARE" menu and get a released tarball of the ``poky``
> -repository, any supported BSP tarball, or Yocto Project tools. Unpacking
> +:yocto_home:`Yocto Project Website <>` and select the "RELEASES"
> +item from the "DEVELOPMENT" menu and get a released tarball of the

Why making it harder to maintain by telling the user where to click 
instead of just providing a direct link which we can check with 
linkcheck if we want to?

s/RELEASES/Releases/

s/DEVELOPMENT/Development/

[...]

> --  :yocto_home:`DOWNLOADS page </software-overview/downloads/>`:
> -   The :yocto_home:`Yocto Project website <>` includes a "DOWNLOADS" page accessible
> +-  :yocto_home:`RELEASES page </development/releases/>`:
> +   The :yocto_home:`Yocto Project website <>` includes a "RELEASES" page accessible
>      through the "SOFTWARE" menu that allows you to download any Yocto

through the "Development" menu.

Also, they all are capitalized but not uppercase, i.e. Releases and not 
RELEASES.

>      Project release, tool, and Board Support Package (BSP) in tarball
>      form. The hyperlinks point to the tarballs under
> @@ -230,11 +228,11 @@ and so forth.
>      ":doc:`/contributor-guide/identify-component`"
>      section of the Yocto Project and OpenEmbedded Contributor Guide.
>   
> -The Yocto Project ``poky`` Git repository also has an upstream
> -contribution Git repository named ``poky-contrib``. You can see all the
> +The Yocto Project Git repositories may also have upstream
> +contribution Git repositories suffixed with ``-contrib``. You can see all the
>   branches in this repository using the web interface of the

Reported in v1:

You mention there can be multiple repositories but here you say "this
repository" which is confusing. Maybe use one of the contrib git repos
as example.

[...]

> @@ -449,19 +446,19 @@ The most common use is to checkout a working branch that matches a
>   specific Yocto Project release. Here is an example::
>   
>      $ cd ~
> -   $ git clone git://git.yoctoproject.org/poky
> -   $ cd poky
> +   $ git clone git://git.yoctoproject.org/yocto-docs
> +   $ cd yocto-docs
>      $ git fetch --tags
> -   $ git checkout tags/rocko-18.0.0 -b my_rocko-18.0.0
> +   $ git checkout tags/&DISTRO_NAME_NO_CAP;-&DISTRO; -b my_&DISTRO_NAME_NO_CAP;-&DISTRO;
>   
>   In this example, the name
>   of the top-level directory of your local Yocto Project repository is
> -``poky``. After moving to the ``poky`` directory, the ``git fetch``
> +``yocto-docs``. After moving to the ``yocto-docs`` directory, the ``git fetch``
>   command makes all the upstream tags available locally in your
>   repository. Finally, the ``git checkout`` command creates and checks out
> -a branch named "my-rocko-18.0.0" that is based on the upstream branch
> +a branch named "my_&DISTRO_NAME_NO_CAP;-&DISTRO;" that is based on the upstream branch
>   whose "HEAD" matches the commit in the repository associated with the
> -"rocko-18.0.0" tag. The files in your repository now exactly match that
> +"&DISTRO_NAME_NO_CAP;-&DISTRO;" tag. The files in your repository now exactly match that

Technicality but I believe this is incorrect in git. The only thing that 
matters is you check out a tag. The tag may not necessarily be on a 
branch (it is for us, but it doesn't *have* to be). Also, HEAD of 
whinlatter may not be the latest release tag so that is actually incorrect.

I guess we could make this a bit more palatable (and proper) by 
rewording to:

that is based on the upstream tag in the repository.

Maybe? Separate patch/series though, not a blocker here.

Cheers,
Quentin

Re: [docs] [PATCH v2 23/56] overview-manual/yp-intro.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Remove references to the Poky repository. This document had a lot of
> reference to it, so a lot was removed. The "Reference Distribution
> (Poky)" section was removed as there already was a "Reference Embedded
> Distribution (Poky)" below. This section was simplified as now Poky is
> just a distro, not a repo. The historical section was also updated to
> mention the obsolete Poky repo.
> 

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

(already given in v1 and no changes between v1 and v2)

Cheers,
Quentin

Re: [docs] [PATCH v2 26/56] ref-manual/structure.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Remove references to the Poky repository, replace by OpenEmbedded-Core
> in most cases.
> 
> Add a introductory directory layout at the top that is reflected in the
> following section. This document no longer uses Poky as its source
> directory, so all paths are explicitly mentioned, to highlight the
> separation between core components. This lead to some re-organization of
> some sections.
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   documentation/bsp-guide/bsp.rst        |   4 +-
>   documentation/ref-manual/structure.rst | 169 ++++++++++++++++++++-------------
>   documentation/ref-manual/terms.rst     |   2 +-
>   3 files changed, 105 insertions(+), 70 deletions(-)
> 
> diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
> index 4c0939ab0..67f61b7b2 100644
> --- a/documentation/bsp-guide/bsp.rst
> +++ b/documentation/bsp-guide/bsp.rst
> @@ -81,7 +81,7 @@ directory of that Layer. This directory is what you add to the
>   ``conf/bblayers.conf`` file found in your
>   :term:`Build Directory`, which is
>   established after you run the OpenEmbedded build environment setup
> -script (i.e. :ref:`ref-manual/structure:``oe-init-build-env```).
> +script (i.e. :ref:`structure-core-script`).
>   Adding the root directory allows the :term:`OpenEmbedded Build System`
>   to recognize the BSP
>   layer and from it build an image. Here is an example::
> @@ -221,7 +221,7 @@ section.
>         Checking connectivity... done.
>   
>   #. *Initialize the Build Environment:* While in the :term:`Source Directory`,
> -run the :ref:`ref-manual/structure:``oe-init-build-env``` environment setup
> +run the :ref:`structure-core-script` environment setup
>   script located in :term:`OpenEmbedded-Core (OE-Core)` to define the OpenEmbedded
>   build environment on your build host. ::
>   
> diff --git a/documentation/ref-manual/structure.rst b/documentation/ref-manual/structure.rst
> index d567cade0..86f3109e1 100644
> --- a/documentation/ref-manual/structure.rst
> +++ b/documentation/ref-manual/structure.rst
> @@ -16,6 +16,19 @@ and directories.
>      names that contain spaces. Be sure that the Source Directory you use
>      does not contain these types of names.
>   
> +For the following sections, we assume the core components of the :term:`Source
> +Directory` are organized as follows:
> +
> +.. code-block:: text
> +
> +   ├── build/
> +   │   └── ...
> +   └── layers/
> +       ├── bitbake/
> +       ├── meta-yocto/
> +       ├── openembedded-core/
> +       └── yocto-docs/
> +
>   .. _structure-core:
>   
>   Top-Level Core Components
> @@ -67,8 +80,8 @@ about the contents of the :term:`Build Directory`.
>   
>   .. _handbook:
>   
> -``documentation/``
> -------------------
> +``layers/yocto-docs/``
> +----------------------
>   

suggestion:

+The Yocto documentation repository is hosted at
+:yocto_git:`/yocto-docs`.


>   This directory holds the source for the Yocto Project documentation as
>   well as templates and tools that allow you to generate PDF and HTML
> @@ -76,37 +89,28 @@ versions of the manuals. Each manual is contained in its own sub-folder;
>   for example, the files for this reference manual reside in the
>   ``ref-manual/`` directory.
>   
> +This directory is not mandatory for building with :term:`BitBake`.
> +
> +``layers/openembedded-core/``
> +-----------------------------
> +
> +The :term:`OpenEmbedded-Core (OE-Core)` repository is hosted at
> +:oe_git:`/openembedded-core`.
> +
>   .. _structure-core-meta:
>   
> -``meta/``
> ----------
> +``layers/openembedded-core/meta/``
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   
>   This directory contains the minimal, underlying OpenEmbedded-Core

suggestion: :term:`OpenEmbedded-Core (OE-Core)`

>   metadata. The directory holds recipes, common classes, and machine
>   configuration for strictly emulated targets (``qemux86``, ``qemuarm``,
>   and so forth.)
>   
> -.. _structure-core-meta-poky:
> -
> -``meta-poky/``
> ---------------
> -
> -Designed above the ``meta/`` content, this directory adds just enough
> -metadata to define the Poky reference distribution.
> -
> -.. _structure-core-meta-yocto-bsp:
> -
> -``meta-yocto-bsp/``
> --------------------
> -
> -This directory contains the Yocto Project reference hardware Board
> -Support Packages (BSPs). For more information on BSPs, see the
> -:doc:`/bsp-guide/index`.
> -
>   .. _structure-meta-selftest:
>   
> -``meta-selftest/``
> -------------------
> +``layers/openembedded-core/meta-selftest/``
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   
>   This directory adds additional recipes and append files used by the
>   OpenEmbedded selftests to verify the behavior of the build system. You
> @@ -115,15 +119,15 @@ want to run the selftests.
>   
>   .. _structure-meta-skeleton:
>   
> -``meta-skeleton/``
> -------------------
> +``layers/openembedded-core/meta-skeleton/``
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   
>   This directory contains template recipes for BSP and kernel development.
>   
>   .. _structure-core-scripts:
>   
> -``scripts/``
> -------------
> +``layers/openembedded-core/scripts/``
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   
>   This directory contains various integration scripts that implement extra
>   functionality in the Yocto Project environment (e.g. QEMU scripts). The
> @@ -136,8 +140,8 @@ back to the Yocto Project, such as ``create-pull-request`` and
>   
>   .. _structure-core-script:
>   
> -``oe-init-build-env``
> ----------------------
> +``layers/openembedded-core/oe-init-build-env``
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For this one and all the others (above and below): watch out, this will 
switch the cross-reference default string from oe-init-build-env to 
layers/openembedded-core/oe-init-build-env, is this what we want? Do we 
need to change the cross-reference string everywhere?

[...]

Cheers,
Quentin

Re: [docs] [PATCH v2 28/56] ref-manual/variables.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Remove references to the Poky repository, replace by OpenEmbedded-Core
> in most cases.
> 

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 29/56] sdk-manual/appendix-obtain.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Rename the source directory to project, as specified in its new
> definition in terms.rst.
> 

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 32/56] README: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Refresh the document now that the Poky repository is obsolete.
> 

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 35/56] dev-manual/build-quality.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Refresh the document now that the Poky repository is obsolete.
> 

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 37/56] dev-manual/custom-template-configuration-directory.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Refresh the document now that the Poky repository is obsolete. Adapt
> paths to match to encouraged Source Directory layout.
> 

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 39/56] dev-manual/licenses.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Refresh the document now that the Poky repository is obsolete.
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   documentation/dev-manual/licenses.rst | 30 ++++++++++++------------------
>   1 file changed, 12 insertions(+), 18 deletions(-)
> 
> diff --git a/documentation/dev-manual/licenses.rst b/documentation/dev-manual/licenses.rst
> index 7d6636eef..1887e8e35 100644
> --- a/documentation/dev-manual/licenses.rst
> +++ b/documentation/dev-manual/licenses.rst
> @@ -112,8 +112,8 @@ commercial or other special licensing requirements. Such requirements
>   are defined on a recipe-by-recipe basis through the
>   :term:`LICENSE_FLAGS` variable
>   definition in the affected recipe. For instance, the
> -``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` recipe
> -contains the following statement::
> +``meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly`` recipe of
> +:term:`OpenEmbedded-Core (OE-Core)` contains the following statement::
>   
>      LICENSE_FLAGS = "commercial"
>   
> @@ -136,7 +136,8 @@ needs to have a matching entry in the global
>   :term:`LICENSE_FLAGS_ACCEPTED`
>   variable, which is a variable typically defined in your ``local.conf``
>   file. For example, to enable the
> -``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` package, you
> +``meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly`` package of
> +:term:`OpenEmbedded-Core (OE-Core)`, you
>   could add either the string "commercial_gst-plugins-ugly" or the more
>   general string "commercial" to :term:`LICENSE_FLAGS_ACCEPTED`. See the
>   ":ref:`dev-manual/licenses:license flag matching`" section for a full
> @@ -244,7 +245,7 @@ Other Variables Related to Commercial Licenses
>   
>   There are other helpful variables related to commercial license handling,
>   defined in the
> -``poky/meta/conf/distro/include/default-distrovars.inc`` file::
> +``meta/conf/distro/include/default-distrovars.inc`` file in :term:`OpenEmbedded-Core (OE-Core)`::
>   
>      COMMERCIAL_AUDIO_PLUGINS ?= ""
>      COMMERCIAL_VIDEO_PLUGINS ?= ""
> @@ -460,22 +461,15 @@ and the source code modifications in one step.
>   
>   If the deployment team has a :ref:`overview-manual/concepts:bsp layer`
>   and a distro layer, and those
> -those layers are used to patch, compile, package, or modify (in any way)
> +layers are used to patch, compile, package, or modify (in any way)
>   any open source software included in your released images, you might be
>   required to release those layers under section 3 of GPLv2 or section 1
>   of GPLv3. One way of doing that is with a clean checkout of the version
> -of the Yocto Project and layers used during your build. Here is an
> -example:
> +of the Yocto Project and layers used during your build. Removing the Git
> +objects can be done like so:
>   
> -.. code-block:: shell
> +.. code-block:: console
>   
> -   # We built using the dunfell branch of the poky repo
> -   $ git clone -b dunfell git://git.yoctoproject.org/poky
> -   $ cd poky
> -   # We built using the release_branch for our layers
> -   $ git clone -b release_branch git://git.mycompany.com/meta-my-bsp-layer
> -   $ git clone -b release_branch git://git.mycompany.com/meta-my-software-layer
> -   # clean up the .git repos
>      $ find . -name ".git" -type d -exec rm -rf {} \;
>   
>   One thing a development organization might want to consider for end-user
> @@ -494,9 +488,9 @@ automatically::
>   
>      BBLAYERS ?= " \
>        ##OEROOT##/meta \
> -     ##OEROOT##/meta-poky \
> -     ##OEROOT##/meta-yocto-bsp \
> -     ##OEROOT##/meta-mylayer \
> +     ##OEROOT##/../meta-poky \
> +     ##OEROOT##/../meta-yocto-bsp \

Aren't the two above supposed to be

../meta-yocto/meta-poky
../meta-yocto/meta-yocto-bsp

With this fixed:

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [PATCH v2 40/56] dev-manual/licenses.rst: instruct to use git-archive instead of removing .git

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard wrote:
> Removing .git directories is destructive. Instruct to use git archive
> instead.
> 
> Suggested-by: Quentin Schulz <quentin.schulz@cherry.de>

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 41/56] dev-manual/packages.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Refresh the document now that the Poky repository is obsolete.
> 

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 42/56] dev-manual/python-development-shell.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Refresh the document now that the Poky repository is obsolete.
> 

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 43/56] dev-manual/qemu.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Refresh the document now that the Poky repository is obsolete.
> 

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 44/56] dev-manual/upgrading-recipes.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Refresh the document now that the Poky repository is obsolete.
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   documentation/dev-manual/upgrading-recipes.rst | 22 +++++++++++-----------
>   1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/documentation/dev-manual/upgrading-recipes.rst b/documentation/dev-manual/upgrading-recipes.rst
> index 2e6567867..c4199d160 100644
> --- a/documentation/dev-manual/upgrading-recipes.rst
> +++ b/documentation/dev-manual/upgrading-recipes.rst
> @@ -84,12 +84,12 @@ The following steps describe how to set up the AUH utility:
>      AUH is not part of the :term:`OpenEmbedded-Core (OE-Core)` or
>      :term:`Poky` repositories.
>   
> -#. *Create a Dedicated Build Directory:* Run the :ref:`structure-core-script`
> +#. *Create a Dedicated Build Directory:* Create a new :term:`bitbake:Setup` with
> +   ``bitbake-setup`` or manually run the :ref:`structure-core-script`
>      script to create a fresh :term:`Build Directory` that you use exclusively
>      for running the AUH utility::
>   
> -      $ cd poky
> -      $ source oe-init-build-env your_AUH_build_directory
> +      $ source layers/openembedded-core/oe-init-build-env your_AUH_build_directory
>   
>      Re-using an existing :term:`Build Directory` and its configurations is not
>      recommended as existing settings could cause AUH to fail or behave
> @@ -121,7 +121,7 @@ The following steps describe how to set up the AUH utility:
>   
>         .. note::
>   
> -         If your distro does not enable by default ptest, which Poky
> +         If your distro does not enable by default ptest, which :term:`Poky`
>            does, you need the following in your ``local.conf`` file::
>   
>                    DISTRO_FEATURES:append = " ptest"
> @@ -143,7 +143,7 @@ The following steps describe how to set up the AUH utility:
>      described earlier, you must enable it in ``upgrade-helper.conf``.
>   
>      Also, if you are using the default ``maintainers.inc`` file supplied
> -   with Poky and located in ``meta-yocto`` and you do not set a
> +   in :term:`OpenEmbedded-Core (OE-Core)` and you do not set a
>      "maintainers_whitelist" or "global_maintainer_override" in the
>      ``upgrade-helper.conf`` configuration, and you specify "-e all" on
>      the AUH command-line, the utility automatically sends out emails to
> @@ -263,7 +263,7 @@ directory automatically upgrades the recipe for you::
>   
>      $ devtool upgrade nano -V 2.9.3
>      NOTE: Starting bitbake server...
> -   NOTE: Creating workspace layer in /home/scottrif/poky/build/workspace
> +   NOTE: Creating workspace layer in /home/scottrif/bitbake-builds/build/workspace
>      Parsing recipes: 100% |##########################################| Time: 0:00:46
>      Parsing of 1431 .bb files complete (0 cached, 1431 parsed). 2040 targets, 56 skipped, 0 masked, 0 errors.
>      NOTE: Extracting current version source...
> @@ -275,8 +275,8 @@ directory automatically upgrades the recipe for you::
>      NOTE: Executing RunQueue Tasks
>      NOTE: Tasks Summary: Attempted 74 tasks of which 72 didn't need to be rerun and all succeeded.
>      Adding changed files: 100% |#####################################| Time: 0:00:00
> -   NOTE: Upgraded source extracted to /home/scottrif/poky/build/workspace/sources/nano
> -   NOTE: New recipe is /home/scottrif/poky/build/workspace/recipes/nano/nano_2.9.3.bb
> +   NOTE: Upgraded source extracted to /home/scottrif/bitbake-builds/build/workspace/sources/nano
> +   NOTE: New recipe is /home/scottrif/bitbake-builds/build/workspace/recipes/nano/nano_2.9.3.bb
>   
>   .. note::
>   
> @@ -298,7 +298,7 @@ newly upgraded recipe::
>             .
>      NOTE: Executing SetScene Tasks
>      NOTE: Executing RunQueue Tasks
> -   NOTE: nano: compiling from external source tree /home/scottrif/poky/build/workspace/sources/nano
> +   NOTE: nano: compiling from external source tree /home/scottrif/bitbake-builds/build/workspace/sources/nano
>      NOTE: Tasks Summary: Attempted 520 tasks of which 304 didn't need to be rerun and all succeeded.
>   
>   Within the ``devtool upgrade`` workflow, you can
> @@ -320,8 +320,8 @@ directory::
>      NOTE: Adding new patch 0001-nano.bb-Stuff-I-changed-when-upgrading-nano.bb.patch
>      NOTE: Updating recipe nano_2.9.3.bb
>      NOTE: Removing file /home/scottrif/meta-openembedded/meta-oe/recipes-support/nano/nano_2.7.4.bb

We should probably update the meta-oe layer addition to follow the new 
layout (/home/scottrif/bitbake-builds/layers/).

Can be done in a separate patch/series though, so

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 45/56] dev-manual/vulnerabilities.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Refresh the document now that the Poky repository is obsolete. Mention
> that only vulnerabilities in OpenEmbedded-Core are tracked as that's
> where the packages are.
> 

As far as I could tell, no changes since v1 and there I had

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 46/56] ref-manual/devtool-reference.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Refresh the document now that the Poky repository is obsolete.
> 

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 47/56] ref-manual/faq.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Refresh the document now that the Poky repository is obsolete.
> 
> Rework the difference between Poky and OpenEmbedded. Copy the note from
> terms.rst regarding the now obsolete Poky repository.
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   documentation/ref-manual/faq.rst | 43 ++++++++++++++++++++++++++++++----------
>   1 file changed, 32 insertions(+), 11 deletions(-)
> 
> diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
> index 6c5b9d4e7..7557a7269 100644
> --- a/documentation/ref-manual/faq.rst
> +++ b/documentation/ref-manual/faq.rst
> @@ -12,14 +12,35 @@ General questions
>   How does Poky differ from OpenEmbedded?
>   ---------------------------------------
>   
> -The term ``Poky`` refers to the specific reference build
> -system that the Yocto Project provides. Poky is based on
> -:term:`OpenEmbedded-Core (OE-Core)` and :term:`BitBake`. Thus, the
> -generic term used here for the build system is the "OpenEmbedded build
> -system." Development in the Yocto Project using Poky is closely tied to
> -OpenEmbedded, with changes always being merged to OE-Core or BitBake
> -first before being pulled back into Poky. This practice benefits both
> -projects immediately.
> +The term :term:`Poky` refers to the reference distribution that the Yocto
> +Project provides, and a reference test configuration.
> +
> +The :term:`Poky` distribution is built using the :term:`OpenEmbedded Build
> +System` and :term:`BitBake`. The :term:`metadata` used involved to build the

"used involved" sounds wrong to my ears.

Also I believe it should "involved in building" or "used to build".

Up to you, either works.

> +:term:`Poky` reference distribution is:
> +
> +-  :term:`OpenEmbedded-Core (OE-Core)`, which is hosted at
> +   :oe_git:`/openembedded-core`.
> +
> +-  :yocto_git:`meta-poky <meta-yocto/tree/meta-poky>`, which defines the
> +   ``poky`` distro configuration file (:term:`DISTRO`).
> +
> +.. note::
> +
> +   Poky also used to be a repository containing the combination of
> +   :term:`BitBake`, :term:`OpenEmbedded-Core (OE-Core)`, the
> +   :yocto_git:`meta-yocto </meta-yocto>` repository and the Yocto Project
> +   documentation -- which were combined with the :yocto_git:`combo-layer
> +   </poky-config>` tool.
> +
> +   This repository is still hosted at :yocto_git:`/poky` and is still
> +   updated for maintained releases that are older than Whinlatter (5.3).
> +   Newer releases now use ``bitbake-setup`` to clone and setup the initial
> +   :term:`OpenEmbedded Build System` environment. For more information on
> +   how to use ``bitbake-setup``, see the :doc:`/brief-yoctoprojectqs/index`
> +   document. An alternative can be to setup the above repositories
> +   manually, by following the :doc:`/dev-manual/poky-manual-setup`
> +   section of the Yocto Project Development Tasks Manual.
>   
>   How can you claim Poky / OpenEmbedded-Core is stable?
>   -----------------------------------------------------
> @@ -27,7 +48,7 @@ How can you claim Poky / OpenEmbedded-Core is stable?
>   There are three areas that help with stability;
>   
>   -  The Yocto Project team keeps :term:`OpenEmbedded-Core (OE-Core)` small and
> -   focused, containing around 830 recipes as opposed to the thousands
> +   focused, containing around a thousand recipes as opposed to the thousands
>      available in other OpenEmbedded community layers. Keeping it small
>      makes it easy to test and maintain.
>   
> @@ -87,8 +108,8 @@ configurable. You can setup the build system to get source code in most
>   environments if HTTP transport is available.
>   
>   When the build system searches for source code, it first tries the local
> -download directory. If that location fails, Poky tries
> -:term:`PREMIRRORS`, the upstream source, and then
> +download directory. If that location fails, the :term:`OpenEmbedded Build

Suggestion: Would "download directory" be :term:`DL_DIR` here? Maybe we 
could specify it.

> +System` tries :term:`PREMIRRORS`, the upstream source, and then

Suggestion: I guess upstream source would be :term:`SRC_URI` here? "as 
listed in :term:`SRC_URI`" maybe?

Suggestions done in a separate patch/series is fine, so

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [PATCH v2 50/56] ref-manual/release-process.rst: remove repeated "in the"

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard wrote:
> Reported-by: Quentin Schulz <quentin.schulz@cherry.de>

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 51/56] ref-manual/system-requirements.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Refresh the document now that the Poky repository is obsolete.
> 
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
>   documentation/ref-manual/system-requirements.rst | 12 ++++++------
>   1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst
> index a56e683ca..9b681290e 100644
> --- a/documentation/ref-manual/system-requirements.rst
> +++ b/documentation/ref-manual/system-requirements.rst
> @@ -405,8 +405,8 @@ installer and automatically installs the tools for you:
>   
>   #. Execute the ``install-buildtools`` script. Here is an example::
>   
> -      $ cd poky
> -      $ scripts/install-buildtools \
> +      $ cd /path/to/bitbake-builds
> +      $ ./layers/openembedded-core/scripts/install-buildtools \
>           --without-extended-buildtools \
>           --base-url &YOCTO_DL_URL;/releases/yocto \
>           --release yocto-&DISTRO; \
> @@ -420,26 +420,26 @@ installer and automatically installs the tools for you:
>      To avoid the need of ``sudo`` privileges, the ``install-buildtools``
>      script will by default tell the installer to install in::
>   
> -      /path/to/poky/buildtools
> +      /path/to/bitbake-builds/buildtools
>   
>      If your host development system needs the additional tools provided
>      in the :term:`buildtools-extended` tarball, you can instead execute the
>      ``install-buildtools`` script with the default parameters::
>   
> -      $ cd poky
> +      $ cd /path/to/bitbake-builds
>         $ scripts/install-buildtools
>   

This doesn't exist. With bitbake-setup, I get:

poky-master/layers/oe-scripts/install-buildtools
poky-master/layers/oe-init-build-env-dir/scripts/install-buildtools
poky-master/layers/openembedded-core/scripts/install-buildtools

the first two are symlinks to the last one, so I assume we want

./layers/openembedded-core/scripts/install-buildtools

>      Alternatively if your host development system has a broken ``make``
>      version such that you only need a known good version of ``make``,
>      you can use the ``--make-only`` option::
>   
> -      $ cd poky
> +      $ cd /path/to/bitbake-builds
>         $ scripts/install-buildtools --make-only

Ditto.

With those fixed:

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [PATCH v2 52/56] ref-manual/system-requirements.rst: fix wrong path to install-buildtools

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard wrote:
> Reported-by: Quentin Schulz <quentin.schulz@cherry.de>

Ah, well, I had forgotten about that one :)

Please ignore the feedback on patch 51 then (keep the R-b)!

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 55/56] test-manual/understand-autobuilder.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Refresh the document now that the Poky repository is obsolete.
> 

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 56/56] what-i-wish-id-known.rst: remove obsolete poky repo references

[Quentin Schulz]

Hi Antonin,

On 1/27/26 9:19 AM, Antonin Godard via lists.yoctoproject.org wrote:
> Refresh the document now that the Poky repository is obsolete.
> 

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [docs] [PATCH v2 04/56] bsp-guide/bsp.rst: remove obsolete poky repo references

[Antonin Godard]

Hi,

On Tue Jan 27, 2026 at 12:27 PM CET, Quentin Schulz wrote:
[...]
> Actually, probably should be 4 and have two spaces between #. and 
> *Initialize* since that's the rule we have for lists. I see most of the 
> lists in the diff in this patch don't follow the rule so I guess that's 
> not a blocker :)

I actually think it makes more sense to have one space for "#.", as this way it
aligns with bullet lists "-  ":

#. foo
-  bar

>> -      $ source oe-init-build-env
>> +      $ source layers/openembedded-core/oe-init-build-env
>>   
>>      Among other things, the script creates the :term:`Build Directory`, which is
>> -   ``build`` in this case and is located in the :term:`Source Directory`.  After
>> -   the script runs, your current working directory is set to the ``build``
>> -   directory.
>> +   :term:`Build Directory`. After the script runs, your current working directory 
>
> s/:term:`Build Directory`/"build"/
>
> otherwise this says "Build Directory, which is Build Directory".
>
> is set to
>> +   the :term:`Build Directory` directory.
>> +
>> +   .. note::
>> +
>> +      Alternatively, you can source the ``init-build-env`` file provided by
>> +      :doc:`bitbake-setup <bitbake:bitbake-user-manual/bitbake-user-manual-environment-setup>`
>>   
>
> You didn't answer the question on v1 so posting it here again:
>
> Can we set up using bitbake-setup and then source oe-init-buildenv from
> oe-core? Or vice-versa. The wording seems to imply that.

I mean you could but probably you wouldn't want to?

> Isn't most the above not applicable if we use bitbake-setup anyway?

As you have seen from this series, for now, it doesn't force you into setting
things one way or another. A further step to this series would be to locate and
replace these with bitbake-setup specific instructions, dropping the manual
setup anywhere.

Thanks,
Antonin

-- 
Antonin Godard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH v2 26/56] ref-manual/structure.rst: remove obsolete poky repo references

[Antonin Godard]

Hi,

On Wed Jan 28, 2026 at 12:48 PM CET, Quentin Schulz via lists.yoctoproject.org wrote:
[...]
>> -``oe-init-build-env``
>> ----------------------
>> +``layers/openembedded-core/oe-init-build-env``
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> For this one and all the others (above and below): watch out, this will 
> switch the cross-reference default string from oe-init-build-env to 
> layers/openembedded-core/oe-init-build-env, is this what we want? Do we 
> need to change the cross-reference string everywhere?

Good point!

Since this section and the others are subsections of
``layers/openembedded-core/``, I've renamed them to remove the leading
"layers/openembedded-core". Same for subsections of ``layers/meta-yocto/``.

Thanks,
Antonin

-- 
Antonin Godard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com