* [PATCH 01/53] transitioning-to-a-custom-environment.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 9:58 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 02/53] dev-manual/start.rst: " Antonin Godard
` (51 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
- Use :term: for Poky.
- Mention use of fragments instead of local.conf.
- Remove Yocto < 2.4 reference.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 02/53] dev-manual/start.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
2025-12-24 16:31 ` [PATCH 01/53] transitioning-to-a-custom-environment.rst: remove " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 10:46 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 03/53] dev-manual/poky-manual-setup.rst: " Antonin Godard
` (50 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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.
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
documentation/bsp-guide/bsp.rst | 5 +-
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 | 25 +-
6 files changed, 48 insertions(+), 368 deletions(-)
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index a6444d9af..74912cdd6 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -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..ca6753c94 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 only a point that can be used to try the Yocto
+ Project. It should not be used in production environments! 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 you current shell and change its 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 There
+----------------------
- $ 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 a42cbc31b..33787a225 100644
--- a/documentation/sdk-manual/appendix-obtain.rst
+++ b/documentation/sdk-manual/appendix-obtain.rst
@@ -85,34 +85,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::
-
- $ 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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 02/53] dev-manual/start.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 02/53] dev-manual/start.rst: " Antonin Godard
@ 2026-01-13 10:46 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 10:46 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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.
>
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
> documentation/bsp-guide/bsp.rst | 5 +-
> 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 | 25 +-
> 6 files changed, 48 insertions(+), 368 deletions(-)
>
> diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
> index a6444d9af..74912cdd6 100644
> --- a/documentation/bsp-guide/bsp.rst
> +++ b/documentation/bsp-guide/bsp.rst
> @@ -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..ca6753c94 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 only a point that can be used to try the Yocto
I don't know what you wanted to convey with "a point" here, but I don't
think it works?
What about something like
"""
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.
"""
> + Project. It should not be used in production environments! 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 you current shell and change its current working directory to
s/you/your/
s/its/the/
> +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 There
s/There/Here/ ?
More generally, I'm confused as to why we are removing mentions to the
tarball setup as that still exists and is possible?
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 03/53] dev-manual/poky-manual-setup.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
2025-12-24 16:31 ` [PATCH 01/53] transitioning-to-a-custom-environment.rst: remove " Antonin Godard
2025-12-24 16:31 ` [PATCH 02/53] dev-manual/start.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 10:52 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 04/53] bsp-guide/bsp.rst: " Antonin Godard
` (49 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 | 28 +++++++++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/documentation/dev-manual/poky-manual-setup.rst b/documentation/dev-manual/poky-manual-setup.rst
index 7ee084007..c4e36ce8b 100644
--- a/documentation/dev-manual/poky-manual-setup.rst
+++ b/documentation/dev-manual/poky-manual-setup.rst
@@ -13,8 +13,15 @@ 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: cloning the repositories with Git, or
+downloading the released 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
@@ -41,6 +48,25 @@ 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 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;/>`.
+
+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.
+
+.. note::
+
+ 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.
+
Building Your Image
===================
--
2.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 03/53] dev-manual/poky-manual-setup.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 03/53] dev-manual/poky-manual-setup.rst: " Antonin Godard
@ 2026-01-13 10:52 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 10:52 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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.
>
Do the opposite? Have this commit before we remove the important parts
in the commit you mention? So that no information is temporarily lost?
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
> documentation/dev-manual/poky-manual-setup.rst | 28 +++++++++++++++++++++++++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/documentation/dev-manual/poky-manual-setup.rst b/documentation/dev-manual/poky-manual-setup.rst
> index 7ee084007..c4e36ce8b 100644
> --- a/documentation/dev-manual/poky-manual-setup.rst
> +++ b/documentation/dev-manual/poky-manual-setup.rst
> @@ -13,8 +13,15 @@ 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: cloning the repositories with Git, or
> +downloading the released archives.
> +
suggestion: Use cross-reference links for both (linking to "Use Git to
Clone the Layers and 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
> @@ -41,6 +48,25 @@ 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 on :yocto_dl:`/releases/yocto/`. Then, choose the subdirectory
s/on/at/ ?
> +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 individual components (if you wish
> +to use them individually), and of the corresponding Poky release bundling
> +a selection of these components.
> +
Where it this poky bundle, I cannot find it here:
https://downloads.yoctoproject.org/releases/yocto/yocto-5.3/
> +.. note::
> +
> + The recommended method for accessing Yocto Project components is to
> + use Git to clone the upstream repository and work from within that
suggestion: Use a cross-reference link pointing at the section above
this one.
> + locally cloned repository.
> +
s/that locally cloned repository/the locally cloned repositories/
(no combo layer anymore!).
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 04/53] bsp-guide/bsp.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (2 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 03/53] dev-manual/poky-manual-setup.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 11:10 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 05/53] kernel-dev/advanced.rst: " Antonin Godard
` (48 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 | 151 +++++++++++++---------------------------
1 file changed, 48 insertions(+), 103 deletions(-)
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index 74912cdd6..2a451b213 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.
@@ -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
@@ -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 directory where the
+ different layers are cloned, 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
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.
+ ``build``. After the script runs, your current working directory is set to
+ the ``build`` 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
@@ -767,19 +766,22 @@ workflow.
.. note::
- There are three hardware reference BSPs in the Yocto
- Project release, located in the ``poky/meta-yocto-bsp``
+ 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 platforma (``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 ``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,7 @@ 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 ``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 +872,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 +1169,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 +1187,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 +1235,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 +1254,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 +1345,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 +1383,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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 04/53] bsp-guide/bsp.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 04/53] bsp-guide/bsp.rst: " Antonin Godard
@ 2026-01-13 11:10 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 11:10 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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>
> ---
> documentation/bsp-guide/bsp.rst | 151 +++++++++++++---------------------------
> 1 file changed, 48 insertions(+), 103 deletions(-)
>
> diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
> index 74912cdd6..2a451b213 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.
>
> @@ -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`
Commits must be bisectable. This should be in the commit removing the
section.
> section in the Yocto Project Development Tasks Manual.
>
> The BSP layer's base directory (``meta-bsp_root_name``) is the root
> @@ -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 directory where the
> + different layers are cloned, run the :ref:`ref-manual/structure:``oe-init-build-env```
I don't think you need to be "in the directory where the different
layers are cloned" to be able to run the script?
This actually gives an advice we usually don't recommend. In order to be
"in the directory where the different layers are cloned" and be able to
"source oe-init-build-env" you would need to clone all the layers while
being within OE-Core git repo.
What are you trying to convey here?
> + 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
>
> 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.
> + ``build``. After the script runs, your current working directory is set to
> + the ``build`` directory.
> +
:term:`Build 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>`
>
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?
Also, i've stumbled upon
bitbake-layers layerindex-fetch -b master meta-rockchip
which does a lot of automagic things (fetching dependent layers if they
are on the layerindex). We should think about documenting this if that's
not already the case, it's quite helpful.
> 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
> @@ -767,19 +766,22 @@ workflow.
> .. note::
>
> - There are three hardware reference BSPs in the Yocto
Not three anymore with the addition below.
> - Project release, located in the ``poky/meta-yocto-bsp``
> + 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 platforma (``genericarm64``)
> +
s/platforma/platform/
> 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 ``meta-intel`` layer.
>
Use a yocto_git reference here maybe?
> #. *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,7 @@ 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 ``meta`` directory of :term:`OpenEmbedded-Core (OE-Core)`.
>
Maybe use
oe_git:`meta</openembedded-core/tree/meta>` directory...
to not lose information we used to have.
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 05/53] kernel-dev/advanced.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (3 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 04/53] bsp-guide/bsp.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 11:12 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 06/53] contributor-guide/submit-changes.rst: " Antonin Godard
` (47 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 05/53] kernel-dev/advanced.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 05/53] kernel-dev/advanced.rst: " Antonin Godard
@ 2026-01-13 11:12 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 11:12 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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>
> ---
> 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
Maybe we can also think about update the recipe filename since it
doesn't exist anymore :)
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 06/53] contributor-guide/submit-changes.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (4 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 05/53] kernel-dev/advanced.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 11:25 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 07/53] dev-manual/building.rst: " Antonin Godard
` (46 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 | 29 +++++++++-------------
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst
index 6306ed45b..d282cdf75 100644
--- a/documentation/contributor-guide/submit-changes.rst
+++ b/documentation/contributor-guide/submit-changes.rst
@@ -429,11 +429,7 @@ 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:
+The upstream location used for submitting changes varies by component:
- *Core Metadata:* Send your patches to the
:oe_lists:`openembedded-core </g/openembedded-core>`
@@ -620,7 +616,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 +641,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 +655,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 +668,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 +677,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 +852,14 @@ 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.
+- *meta-yocto "master-next" branch:* This branch is part of the
+ :yocto_git:`meta-yocto </meta-yocto/>` repository and combines 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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 06/53] contributor-guide/submit-changes.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 06/53] contributor-guide/submit-changes.rst: " Antonin Godard
@ 2026-01-13 11:25 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 11:25 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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 | 29 +++++++++-------------
> 1 file changed, 12 insertions(+), 17 deletions(-)
>
> diff --git a/documentation/contributor-guide/submit-changes.rst b/documentation/contributor-guide/submit-changes.rst
> index 6306ed45b..d282cdf75 100644
> --- a/documentation/contributor-guide/submit-changes.rst
> +++ b/documentation/contributor-guide/submit-changes.rst
> @@ -429,11 +429,7 @@ 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:
> +The upstream location used for submitting changes varies by component:
>
Everything below needs to be reworded as well as it was written with the
poky combo layer in mind. Now it should be much simpler as what's within
a repo can be contributed following the README from the repo?
I would also add a note for the stable releases maybe? Since those
aren't covered by these new rules and you need to know about those
limitations (so maybe a link to that section in the older releases would
be enough).
> - *Core Metadata:* Send your patches to the
> :oe_lists:`openembedded-core </g/openembedded-core>`
> @@ -620,7 +616,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 +641,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 +655,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 +668,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 +677,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 +852,14 @@ 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.
> +- *meta-yocto "master-next" branch:* This branch is part of the
> + :yocto_git:`meta-yocto </meta-yocto/>` repository and combines proposed
s/combines/contains/
> + changes to meta-yocto.
>
We also have master-next for BitBake which was handled by the poky combo
layer before, so we should mention it as well.
Wondering if we want to add yocto-docs there as well maybe? Not sure
it's as important as the other three though.
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 07/53] dev-manual/building.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (5 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 06/53] contributor-guide/submit-changes.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 11:30 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 08/53] dev-manual/debugging.rst: " Antonin Godard
` (45 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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/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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 07/53] dev-manual/building.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 07/53] dev-manual/building.rst: " Antonin Godard
@ 2026-01-13 11:30 ` Quentin Schulz
2026-01-26 13:08 ` Antonin Godard
0 siblings, 1 reply; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 11:30 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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/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
Unrelated to this, but I'm very confused as to why we enforce a MACHINE
when one is set with the fragments (which is the default). I don't think
there's a reason for that and it makes it "painful" for me to build
multiple machines within the same setup. Let me pass MACHINE= on the
command line? We don't even tell users they can simply remove the
machine fragment to then pass MACHINE from the CLI, which I believe ends
up encouraging users to have completely separate setups when the only
thing that changes is MACHINE.
In any case, this is unrelated, so
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [docs] [PATCH 07/53] dev-manual/building.rst: remove obsolete poky repo references
2026-01-13 11:30 ` [docs] " Quentin Schulz
@ 2026-01-26 13:08 ` Antonin Godard
0 siblings, 0 replies; 112+ messages in thread
From: Antonin Godard @ 2026-01-26 13:08 UTC (permalink / raw)
To: quentin.schulz, docs; +Cc: Thomas Petazzoni
Hi,
On Tue Jan 13, 2026 at 12:30 PM CET, Quentin Schulz via lists.yoctoproject.org wrote:
> Hi Antonin,
>
> On 12/24/25 5:31 PM, 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/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
>
> Unrelated to this, but I'm very confused as to why we enforce a MACHINE
> when one is set with the fragments (which is the default). I don't think
> there's a reason for that and it makes it "painful" for me to build
> multiple machines within the same setup. Let me pass MACHINE= on the
> command line? We don't even tell users they can simply remove the
> machine fragment to then pass MACHINE from the CLI, which I believe ends
> up encouraging users to have completely separate setups when the only
> thing that changes is MACHINE.
I agree and think this is a regression compared to what was possible before. I
would suggest bringing this up in the bitbake mailing list to open the
discussion.
I usually end up removing the fragment definition entirely and use local.conf to
set my MACHINE.
Antonin
--
Antonin Godard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 08/53] dev-manual/debugging.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (6 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 07/53] dev-manual/building.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 11:32 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 09/53] dev-manual/error-reporting-tool.rst: " Antonin Godard
` (44 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Remove references to the Poky repository, replace by OpenEmbedded-Core.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 09/53] dev-manual/error-reporting-tool.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (7 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 08/53] dev-manual/debugging.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 11:34 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 10/53] dev-manual/external-toolchain.rst: " Antonin Godard
` (43 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Remove the single poky repository reference in this document, after the
poky repository was obsoleted.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 10/53] dev-manual/external-toolchain.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (8 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 09/53] dev-manual/error-reporting-tool.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 11:36 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 11/53] dev-manual/layers.rst: " Antonin Godard
` (42 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Remove the single poky repository reference in this document, after the
poky repository was obsoleted.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 10/53] dev-manual/external-toolchain.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 10/53] dev-manual/external-toolchain.rst: " Antonin Godard
@ 2026-01-13 11:36 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 11:36 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, Antonin Godard via lists.yoctoproject.org wrote:
> Remove the single poky repository reference in this document, after the
> poky repository was obsoleted.
>
> 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)`.
Only one tcmode-*.inc in that path. Odd.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 11/53] dev-manual/layers.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (9 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 10/53] dev-manual/external-toolchain.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 12:05 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 12/53] " Antonin Godard
` (41 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 | 266 +++++++--------------
documentation/kernel-dev/common.rst | 6 +-
.../transitioning-to-a-custom-environment.rst | 3 +-
6 files changed, 99 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 2a451b2139..8e332aec07 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -1154,7 +1154,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..15d54cc021 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,23 @@ 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 form to create a
+ layer. The command creates a layer whose name corresponds to
+ "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 +59,84 @@ 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
+
+ $ 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 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 ``conf/layer.conf`` configuration file with default definitions.
+
+ 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.
+
+ - 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.
- .. note::
- 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.
+ 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 --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 +871,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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 11/53] dev-manual/layers.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 11/53] dev-manual/layers.rst: " Antonin Godard
@ 2026-01-13 12:05 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 12:05 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, Antonin Godard via lists.yoctoproject.org wrote:
> 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 | 266 +++++++--------------
> documentation/kernel-dev/common.rst | 6 +-
> .../transitioning-to-a-custom-environment.rst | 3 +-
> 6 files changed, 99 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 2a451b2139..8e332aec07 100644
> --- a/documentation/bsp-guide/bsp.rst
> +++ b/documentation/bsp-guide/bsp.rst
> @@ -1154,7 +1154,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..15d54cc021 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,23 @@ 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 form to create a
> + layer. The command creates a layer whose name corresponds to
> + "your_layer_name" in the current directory:
> +
suggestion:
"""
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 +59,84 @@ 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
> +
> + $ 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 OpenEmbedded build system, you
:term:`OpenEmbedded Build System`
> + 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.
> +
Maybe hint at bitbake-layers add-layer meta-scottrif as returned by the
command just above?
> + 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 layer configuration file:
"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,
Please use cross-references for include and require statements (also,
include_all applies here as well).
> + 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.
> +
Please point at the bitbake documentation for this where we have nice
examples of how to locate an include'd/require'd/include_all'd file.
> + - :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
: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".
> +
Should we specify that this name is then used by other layers when
specifying their dependencies via :term:`LAYERDEPENDS`?
> + - :term:`BBFILE_PATTERN`: Expands immediately during parsing to provide
> + the directory of the layer.
> +
I think we need to explain this better (not necessarily in this patch)
as it's the first time I pay attention to it. Is this why we can use
${LAYERDIR} in BBFILES and it points to the proper absolute paths in the
variable afterwards?
> + - :term:`BBFILE_PRIORITY`: Establishes a priority to use for recipes in
> + the layer when the OpenEmbedded build finds recipes of the same name in
:term:`OpenEmbedded Build System` (missing "system" if you don't want to
be using the cross-reference).
> + 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).
> +
Please specify this will try to find a layer whose BBFILE_COLLECTIONS
contains this string (I believe that is the logic, but I'm not sure).
E.g. you would depend on yoctobsp and not meta-yocto-bsp if you wanted
to depend on meta-yocto-bsp?
> + - :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.
> +
Specify that this is the release *names* (all lowercase) and not the
release version?
> + - 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.
>
> - .. note::
>
> - 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.
> + 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 --help``.
>
``bitbake-layers create-layer --help`` rather no?
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 12/53] dev-manual/layers.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (10 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 11/53] dev-manual/layers.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 12:57 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 13/53] dev-manual/libraries.rst: " Antonin Godard
` (40 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 15d54cc02..49e17c0fb 100644
--- a/documentation/dev-manual/layers.rst
+++ b/documentation/dev-manual/layers.rst
@@ -279,7 +279,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
=======================================================
@@ -518,10 +518,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"
@@ -598,8 +598,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``::
@@ -886,7 +886,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...
@@ -894,14 +896,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/project/layers/openembedded-core/meta 5
+ meta-poky /home/scottrif/project/layers/meta-yocto/meta-poky 5
+ meta-yocto-bsp /home/scottrif/project/layers/meta-yocto/meta-yocto-bsp 5
+ workspace /home/scottrif/project/build/workspace 99
+ meta-scottrif /home/scottrif/project/build/meta-scottrif 6
Adding the layer to this file
enables the build system to locate the layer during the build.
--
2.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 12/53] dev-manual/layers.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 12/53] " Antonin Godard
@ 2026-01-13 12:57 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 12:57 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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/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 15d54cc02..49e17c0fb 100644
> --- a/documentation/dev-manual/layers.rst
> +++ b/documentation/dev-manual/layers.rst
> @@ -279,7 +279,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
> =======================================================
> @@ -518,10 +518,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"
> @@ -598,8 +598,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``::
>
> @@ -886,7 +886,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...
> @@ -894,14 +896,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/project/layers/openembedded-core/meta 5
> + meta-poky /home/scottrif/project/layers/meta-yocto/meta-poky 5
> + meta-yocto-bsp /home/scottrif/project/layers/meta-yocto/meta-yocto-bsp 5
> + workspace /home/scottrif/project/build/workspace 99
> + meta-scottrif /home/scottrif/project/build/meta-scottrif 6
>
s/project/yocto/ ?
Regardless of your choice,
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 13/53] dev-manual/libraries.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (11 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 12/53] " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 12:59 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 14/53] dev-manual/new-recipe.rst: " Antonin Godard
` (39 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Remove references to the Poky repository, replace by OpenEmbedded-Core.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 14/53] dev-manual/new-recipe.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (12 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 13/53] dev-manual/libraries.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 13:09 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 15/53] dev-manual/securing-images.rst: " Antonin Godard
` (38 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/documentation/dev-manual/new-recipe.rst b/documentation/dev-manual/new-recipe.rst
index ee0f6aaf6..38485da7e 100644
--- a/documentation/dev-manual/new-recipe.rst
+++ b/documentation/dev-manual/new-recipe.rst
@@ -224,14 +224,14 @@ 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 ``work``, a default :term:`Build Directory` at
+``project/build``, and a ``qemux86-poky-linux`` machine target system.
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
+ project/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
Inside this directory you can find sub-directories such as ``image``,
``packages-split``, and ``temp``. After the build, you can examine these
@@ -240,7 +240,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. ``project/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0/temp``).
Log files are named ``log.taskname`` (e.g. ``log.do_configure``,
``log.do_fetch``, and ``log.do_compile``).
@@ -830,7 +830,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 +974,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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 14/53] dev-manual/new-recipe.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 14/53] dev-manual/new-recipe.rst: " Antonin Godard
@ 2026-01-13 13:09 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 13:09 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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/dev-manual/new-recipe.rst | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/documentation/dev-manual/new-recipe.rst b/documentation/dev-manual/new-recipe.rst
> index ee0f6aaf6..38485da7e 100644
> --- a/documentation/dev-manual/new-recipe.rst
> +++ b/documentation/dev-manual/new-recipe.rst
> @@ -224,14 +224,14 @@ 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 ``work``, a default :term:`Build Directory` at
> +``project/build``, and a ``qemux86-poky-linux`` machine target system.
Uuuuuuuh. Is it really qemux86-poky-linux machine target system? (I
don't understand what "machine target system" even means).
Should that rather be
``qemux86`` :term:`MACHINE`, ``poky`` :term:`DISTRO` and ``linux`` as
:term:`TARGET_OS` (c.f. :term:`MULTIMACH_TARGET_SYS`).
> 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
> + project/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
>
Ah, then maybe we want this root directory be the same as in the
previous commit (where I commented maybe we want to do s/project/yocto/).
Also, isn't that the case only if PACKAGE_ARCH=MACHINE_ARCH for foo?
Otherwise it's TUNE_PKGARCH-DISTRO-linux by default?
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 15/53] dev-manual/securing-images.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (13 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 14/53] dev-manual/new-recipe.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 13:11 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 16/53] dev-manual/temporary-source-code.rst: " Antonin Godard
` (37 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Remove references to the Poky repository, replace by OpenEmbedded-Core.
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
documentation/dev-manual/securing-images.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/documentation/dev-manual/securing-images.rst b/documentation/dev-manual/securing-images.rst
index f4b528e55..31c945367 100644
--- a/documentation/dev-manual/securing-images.rst
+++ b/documentation/dev-manual/securing-images.rst
@@ -66,7 +66,7 @@ more secure:
- Regularly scan and apply fixes for CVE security issues affecting
all software components in the product, see ":ref:`dev-manual/vulnerabilities:checking for vulnerabilities`".
-- Regularly update your version of Poky and OE-Core from their upstream
+- Regularly update your version of :term:`Poky` and :term:`OpenEmbedded-Core (OE-Core)` from their upstream
developers, e.g. to apply updates and security fixes from stable
and :term:`LTS` branches.
@@ -88,7 +88,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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 15/53] dev-manual/securing-images.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 15/53] dev-manual/securing-images.rst: " Antonin Godard
@ 2026-01-13 13:11 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 13:11 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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/dev-manual/securing-images.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/documentation/dev-manual/securing-images.rst b/documentation/dev-manual/securing-images.rst
> index f4b528e55..31c945367 100644
> --- a/documentation/dev-manual/securing-images.rst
> +++ b/documentation/dev-manual/securing-images.rst
> @@ -66,7 +66,7 @@ more secure:
> - Regularly scan and apply fixes for CVE security issues affecting
> all software components in the product, see ":ref:`dev-manual/vulnerabilities:checking for vulnerabilities`".
>
> -- Regularly update your version of Poky and OE-Core from their upstream
> +- Regularly update your version of :term:`Poky` and :term:`OpenEmbedded-Core (OE-Core)` from their upstream
This excludes BitBake but probably shouldn't. Should we simply say
something along the lines of "BitBake and your layers (e.g. oe-core,
meta-yocto, ...)"?
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 16/53] dev-manual/temporary-source-code.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (14 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 15/53] dev-manual/securing-images.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 13:11 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 17/53] dev-manual/wayland.rst: " Antonin Godard
` (36 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Remove references to the Poky repository, replace by OpenEmbedded-Core.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 17/53] dev-manual/wayland.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (15 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 16/53] dev-manual/temporary-source-code.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 13:12 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 18/53] dev-manual/wic.rst: " Antonin Godard
` (35 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Remove references to the Poky repository, replace by OpenEmbedded-Core.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 18/53] dev-manual/wic.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (16 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 17/53] dev-manual/wayland.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 13:19 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 19/53] kernel-dev/common.rst: " Antonin Godard
` (34 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Remove references to the Poky repository, replace by OpenEmbedded-Core.
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..a7c4ca06a 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
+ meta-yocto/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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 18/53] dev-manual/wic.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 18/53] dev-manual/wic.rst: " Antonin Godard
@ 2026-01-13 13:19 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 13:19 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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/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..a7c4ca06a 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
> + meta-yocto/scripts/lib/wic/canned-wks
>
s/meta-yocto/openembedded-core/
With that,
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 19/53] kernel-dev/common.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (17 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 18/53] dev-manual/wic.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 13:25 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 20/53] migration-guides/migration-1.4.rst: " Antonin Godard
` (33 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 | 107 ++++++++++++++++--------------------
1 file changed, 46 insertions(+), 61 deletions(-)
diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst
index 2142d31c0..ba3a09942 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. ``project/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 project/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 project/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. ``project/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 project/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 project/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 project/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 project/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 project/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 project/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
+ ``project/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 project/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...
+ project/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/project/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/project/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg
+ /home/scottrif/project/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/project/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg
+ /home/scottrif/project/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/bsp/common-pc/common-pc.cfg
+ /home/scottrif/project/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/project/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg
+ /home/scottrif/project/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig
Requested value: CONFIG_SCHED_SMT=y
Actual value:
@@ -1461,9 +1447,9 @@ 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>`.
+You can find this recipe in :term:`OpenEmbedded-Core (OE-Core)`:
+:oe_git:`meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
+</openembedded-core/tree/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb>`.
Here are some basic steps you can use to work with your own sources:
@@ -1600,10 +1586,9 @@ 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>`.
+This template recipe is located in :term:`OpenEmbedded-Core (OE-Core)`:
+:oe_git:`meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
+</openembedded-core/tree/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb>`.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 19/53] kernel-dev/common.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 19/53] kernel-dev/common.rst: " Antonin Godard
@ 2026-01-13 13:25 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 13:25 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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 | 107 ++++++++++++++++--------------------
> 1 file changed, 46 insertions(+), 61 deletions(-)
>
> diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst
> index 2142d31c0..ba3a09942 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. ``project/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 project/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 project/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. ``project/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 project/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 project/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 project/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 project/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 project/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 project/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
> + ``project/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 project/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
Why suddenly work? SHouldn't it be project?
Comment to follow below. Be aware that on Thunderbird, everything below
here got collapsed automatically so you may want to expand :)
> + $ 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...
> + project/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/project/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/project/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg
> + /home/scottrif/project/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/project/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg
> + /home/scottrif/project/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/bsp/common-pc/common-pc.cfg
> + /home/scottrif/project/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/project/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/cfg/smp.cfg
> + /home/scottrif/project/build/tmp/work-shared/qemux86/kernel-source/.kernel-meta/configs/standard/defconfig
> Requested value: CONFIG_SCHED_SMT=y
> Actual value:
>
> @@ -1461,9 +1447,9 @@ 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>`.
> +You can find this recipe in :term:`OpenEmbedded-Core (OE-Core)`:
> +:oe_git:`meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb
> +</openembedded-core/tree/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb>`.
>
suggestion: We could also simply make "linux-yocto custom recipe" a link
instead of needing two sentences to convey that information?
> Here are some basic steps you can use to work with your own sources:
>
> @@ -1600,10 +1586,9 @@ 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>`.
> +This template recipe is located in :term:`OpenEmbedded-Core (OE-Core)`:
> +:oe_git:`meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
> +</openembedded-core/tree/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb>`.
>
suggestion: Ditto.
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 20/53] migration-guides/migration-1.4.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (18 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 19/53] kernel-dev/common.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 13:26 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 21/53] overview-manual/concepts.rst: " Antonin Godard
` (32 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Remove references to the Poky repository, replace by OpenEmbedded-Core.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 20/53] migration-guides/migration-1.4.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 20/53] migration-guides/migration-1.4.rst: " Antonin Godard
@ 2026-01-13 13:26 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 13:26 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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/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
suggestion: Make "``init-ifupdown`` recipe" a link to the recipe?
Regardless,
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 21/53] overview-manual/concepts.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (19 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 20/53] migration-guides/migration-1.4.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 13:31 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 22/53] overview-manual/development-environment.rst: " Antonin Godard
` (31 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 | 75 +++++++++---------------------
1 file changed, 21 insertions(+), 54 deletions(-)
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 04a08b7db..ec56031c4 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -211,62 +211,29 @@ 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. For this discussion, the cloned repository uses the default
+name ``work``.
-.. 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 +338,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 +807,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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 21/53] overview-manual/concepts.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 21/53] overview-manual/concepts.rst: " Antonin Godard
@ 2026-01-13 13:31 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 13:31 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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 | 75 +++++++++---------------------
> 1 file changed, 21 insertions(+), 54 deletions(-)
>
> diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
> index 04a08b7db..ec56031c4 100644
> --- a/documentation/overview-manual/concepts.rst
> +++ b/documentation/overview-manual/concepts.rst
> @@ -211,62 +211,29 @@ 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. For this discussion, the cloned repository uses the default
> +name ``work``.
>
Why? As far as I could tell, we named it "project" in this patch series
until now (or until the previous patch actually)?
> -.. 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
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
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:
s/a list of a few/a non-exhaustive list/ ?
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 22/53] overview-manual/development-environment.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (20 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 21/53] overview-manual/concepts.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 13:49 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 23/53] overview-manual/yp-intro.rst: " Antonin Godard
` (30 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 | 74 ++++++++++------------
1 file changed, 35 insertions(+), 39 deletions(-)
diff --git a/documentation/overview-manual/development-environment.rst b/documentation/overview-manual/development-environment.rst
index ab9bd084c..7eb57f12f 100644
--- a/documentation/overview-manual/development-environment.rst
+++ b/documentation/overview-manual/development-environment.rst
@@ -148,38 +148,35 @@ 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 clones 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
+item from the "SOFTWARE" 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 and 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 ``meta-yocto``, Yocto
+ documentation, metadata layers. You can create local copies of Git
+ repositories for each of these areas.
.. image:: figures/source-repos.png
:width: 100%
@@ -230,11 +227,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 an upstream
+contribution Git repository 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 +320,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 +374,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 +387,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 +406,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 +429,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 +445,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 +592,7 @@ 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 ``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 +613,8 @@ 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 ``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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 22/53] overview-manual/development-environment.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 22/53] overview-manual/development-environment.rst: " Antonin Godard
@ 2026-01-13 13:49 ` Quentin Schulz
2026-01-26 14:57 ` Antonin Godard
0 siblings, 1 reply; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 13:49 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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 | 74 ++++++++++------------
> 1 file changed, 35 insertions(+), 39 deletions(-)
>
> diff --git a/documentation/overview-manual/development-environment.rst b/documentation/overview-manual/development-environment.rst
> index ab9bd084c..7eb57f12f 100644
> --- a/documentation/overview-manual/development-environment.rst
> +++ b/documentation/overview-manual/development-environment.rst
> @@ -148,38 +148,35 @@ 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 clones of
s/clones/clone/?
> +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
> +item from the "SOFTWARE" menu and get a released tarball of the
> +repositories, any supported BSP tarball, or Yocto Project tools. Unpacking
Improper instructions, the SOFTWARE menu doesn't exist anymore.
I'm assuming we want to link at
https://www.yoctoproject.org/development/releases/?
> 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 and the :term:`OpenEmbedded-Core (OE-Core)` and
Replace first "and " with ", "
> + :term:`BitBake` repositories. For example, if you have checked out the "&DISTRO_NAME_NO_CAP;"
Do not use this branch as it will never exist as it points to the name
of the not-yet-released version. You want to use
DISTRO_NAME_NO_CAP_MINUS_ONE likely (or DISTRO_NAME_NO_CAP_LTS).
> + 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``.
>
Same here ^.
> 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 ``meta-yocto``, Yocto
> + documentation, metadata layers. You can create local copies of Git
If you remove the Linux kernel (why?), then add " and" before "metadata
layers".
> + repositories for each of these areas.
>
> .. image:: figures/source-repos.png
> :width: 100%
> @@ -230,11 +227,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 an upstream
> +contribution Git repository suffixed with ``-contrib``. You can see all the
> branches in this repository using the web interface of the
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.
> -: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 +320,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 +374,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 +387,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
DISTRO_NAME_NO_CAP is wrong here, it's the not-yet-released version. We
shouldn't be using that (or set_versions.py doesn't work right now). Or
is it just wrong for the "master" branch of the docs maybe? Still,
people will likely reach the official docs through the master branch?
Should we show a warning on the docs for the master branch stating this
applies only to unreleased software?
> 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 +406,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;
>
This for sure won't work as the branch doesn't exist. Won't repeat the
same argument throughout this file, but there are many other instances.
> 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 +429,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 +445,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 +592,7 @@ 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 ``meta/files/common-licenses``. Once the
suggestion: Provide an :oe_git: link to it?
> 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 +613,8 @@ 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 ``meta/files/common-licenses`` directory in
suggestion: DItto.
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [docs] [PATCH 22/53] overview-manual/development-environment.rst: remove obsolete poky repo references
2026-01-13 13:49 ` [docs] " Quentin Schulz
@ 2026-01-26 14:57 ` Antonin Godard
2026-01-26 15:18 ` Quentin Schulz
0 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2026-01-26 14:57 UTC (permalink / raw)
To: Quentin Schulz, docs; +Cc: Thomas Petazzoni
Hi,
On Tue Jan 13, 2026 at 2:49 PM CET, Quentin Schulz wrote:
[...]
>> + :term:`BitBake` repositories. For example, if you have checked out the "&DISTRO_NAME_NO_CAP;"
>
> Do not use this branch as it will never exist as it points to the name
> of the not-yet-released version. You want to use
> DISTRO_NAME_NO_CAP_MINUS_ONE likely (or DISTRO_NAME_NO_CAP_LTS).
No? This is true for the dev version of the docs, but once the docs are
released, this equals to the current version of the docs you are reading.
[...]
>> 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
>
> DISTRO_NAME_NO_CAP is wrong here, it's the not-yet-released version. We
> shouldn't be using that (or set_versions.py doesn't work right now). Or
> is it just wrong for the "master" branch of the docs maybe? Still,
> people will likely reach the official docs through the master branch?
> Should we show a warning on the docs for the master branch stating this
> applies only to unreleased software?
No, docs.yoctoproject.org shows the latest released version of the docs, which
is the tip of the whinlatter branch right now. The master version of the docs is
docs.yoctoproject.org/dev, and the master-next version of the docs is
docs.yoctoproject.org/next.
Antonin
--
Antonin Godard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [docs] [PATCH 22/53] overview-manual/development-environment.rst: remove obsolete poky repo references
2026-01-26 14:57 ` Antonin Godard
@ 2026-01-26 15:18 ` Quentin Schulz
2026-01-26 15:22 ` Antonin Godard
0 siblings, 1 reply; 112+ messages in thread
From: Quentin Schulz @ 2026-01-26 15:18 UTC (permalink / raw)
To: Antonin Godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 1/26/26 3:57 PM, Antonin Godard wrote:
> Hi,
>
> On Tue Jan 13, 2026 at 2:49 PM CET, Quentin Schulz wrote:
> [...]
>>> + :term:`BitBake` repositories. For example, if you have checked out the "&DISTRO_NAME_NO_CAP;"
>>
>> Do not use this branch as it will never exist as it points to the name
>> of the not-yet-released version. You want to use
>> DISTRO_NAME_NO_CAP_MINUS_ONE likely (or DISTRO_NAME_NO_CAP_LTS).
>
> No? This is true for the dev version of the docs, but once the docs are
> released, this equals to the current version of the docs you are reading.
>
> [...]
>>> 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
>>
>> DISTRO_NAME_NO_CAP is wrong here, it's the not-yet-released version. We
>> shouldn't be using that (or set_versions.py doesn't work right now). Or
>> is it just wrong for the "master" branch of the docs maybe? Still,
>> people will likely reach the official docs through the master branch?
>> Should we show a warning on the docs for the master branch stating this
>> applies only to unreleased software?
>
> No, docs.yoctoproject.org shows the latest released version of the docs, which
> is the tip of the whinlatter branch right now. The master version of the docs is
> docs.yoctoproject.org/dev, and the master-next version of the docs is
> docs.yoctoproject.org/next.
>
Ack. FYI, the version is invalid though, c.f.
https://docs.yoctoproject.org/ref-manual/system-requirements.html#supported-linux-distributions
search for 5.3.999. So we should be wary of using that.
All good, got confused, sorry for the noise.
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* Re: [docs] [PATCH 22/53] overview-manual/development-environment.rst: remove obsolete poky repo references
2026-01-26 15:18 ` Quentin Schulz
@ 2026-01-26 15:22 ` Antonin Godard
0 siblings, 0 replies; 112+ messages in thread
From: Antonin Godard @ 2026-01-26 15:22 UTC (permalink / raw)
To: Quentin Schulz, docs; +Cc: Thomas Petazzoni
Hi,
On Mon Jan 26, 2026 at 4:18 PM CET, Quentin Schulz wrote:
> Hi Antonin,
>
> On 1/26/26 3:57 PM, Antonin Godard wrote:
>> Hi,
>>
>> On Tue Jan 13, 2026 at 2:49 PM CET, Quentin Schulz wrote:
>> [...]
>>>> + :term:`BitBake` repositories. For example, if you have checked out the "&DISTRO_NAME_NO_CAP;"
>>>
>>> Do not use this branch as it will never exist as it points to the name
>>> of the not-yet-released version. You want to use
>>> DISTRO_NAME_NO_CAP_MINUS_ONE likely (or DISTRO_NAME_NO_CAP_LTS).
>>
>> No? This is true for the dev version of the docs, but once the docs are
>> released, this equals to the current version of the docs you are reading.
>>
>> [...]
>>>> 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
>>>
>>> DISTRO_NAME_NO_CAP is wrong here, it's the not-yet-released version. We
>>> shouldn't be using that (or set_versions.py doesn't work right now). Or
>>> is it just wrong for the "master" branch of the docs maybe? Still,
>>> people will likely reach the official docs through the master branch?
>>> Should we show a warning on the docs for the master branch stating this
>>> applies only to unreleased software?
>>
>> No, docs.yoctoproject.org shows the latest released version of the docs, which
>> is the tip of the whinlatter branch right now. The master version of the docs is
>> docs.yoctoproject.org/dev, and the master-next version of the docs is
>> docs.yoctoproject.org/next.
>>
>
> Ack. FYI, the version is invalid though, c.f.
> https://docs.yoctoproject.org/ref-manual/system-requirements.html#supported-linux-distributions
> search for 5.3.999. So we should be wary of using that.
Correct, I'm also not a fan of that and find it confusing (a lot of people do)…
At the same time I wonder what else we could do/show when we're pointing to a
branch tip.
"5.3.999" -> "5.3 (latest)"?
> All good, got confused, sorry for the noise.
No worries!
Antonin
--
Antonin Godard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 23/53] overview-manual/yp-intro.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (21 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 22/53] overview-manual/development-environment.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 13:55 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 24/53] ref-manual/classes.rst: " Antonin Godard
` (29 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 ec56031c4b..ab414c90c4 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -337,7 +337,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 dc4d5125d7..117a8b55b3 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
======================================
@@ -868,21 +759,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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 23/53] overview-manual/yp-intro.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 23/53] overview-manual/yp-intro.rst: " Antonin Godard
@ 2026-01-13 13:55 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 13:55 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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.
>
> 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(-)
[...]
> - - 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.
>
It shouldn't be modified or extended though but taken as inspiration for
your own distro, no?
Unrelated, so
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 24/53] ref-manual/classes.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (22 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 23/53] overview-manual/yp-intro.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 14:00 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 25/53] ref-manual/images.rst: " Antonin Godard
` (28 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Remove references to the Poky repository, replace by OpenEmbedded-Core.
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 eae15fd62..bc98e2575 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 inherit 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 reference 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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 24/53] ref-manual/classes.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 24/53] ref-manual/classes.rst: " Antonin Godard
@ 2026-01-13 14:00 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 14:00 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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/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 eae15fd62..bc98e2575 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 inherit globally (in every recipe)
s/inherit/inherited/
> +with the :term:`INHERIT` variable.
>
This also has nothing to do with what the commit log says it's doing.
> 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 reference the ``.bbclass`` files
Is this supposed to be "refer to" instead of "reference". Triggered my
"doesn't sound English to me" spider sense but no clue if it's actually
correct.
With the first reported typo,
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 25/53] ref-manual/images.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (23 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 24/53] ref-manual/classes.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 14:04 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 26/53] ref-manual/structure.rst: " Antonin Godard
` (27 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Remove references to the Poky repository, replace by OpenEmbedded-Core.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 25/53] ref-manual/images.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 25/53] ref-manual/images.rst: " Antonin Godard
@ 2026-01-13 14:04 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 14:04 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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/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
>
This lists the image recipes, not the directories that contain image
recipe files.
Also, one could simply run:
bitbake-layers show-recipes --inherits image
to know about all possible image recipes one can build.
This is unrelated, so
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 26/53] ref-manual/structure.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (24 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 25/53] ref-manual/images.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 14:16 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 27/53] ref-manual/tasks.rst: " Antonin Godard
` (26 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 | 150 +++++++++++++++++++--------------
documentation/ref-manual/terms.rst | 2 +-
3 files changed, 90 insertions(+), 66 deletions(-)
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index 8e332aec0..9da8400d2 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 directory where the
- different layers are cloned, run the :ref:`ref-manual/structure:``oe-init-build-env```
+ different layers are cloned, 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..3b8fb0263 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,22 @@ 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`.
+
.. _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 +113,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 +134,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 +164,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 +197,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 +207,30 @@ 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:
+.. _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``.
+
+.. _structure-core-meta-yocto-bsp:
-These files are standard top-level files.
+``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 +279,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,9 +297,9 @@ 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``
@@ -298,8 +320,8 @@ 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
+ ``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 ``meta-poky/conf/templates/default`` directory.
.. _structure-build-conf-bblayers.conf:
@@ -319,9 +341,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,12 +351,12 @@ 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
+ script in the :term:`Source Directory`. You can find the :term:`Poky`
version of the ``bblayers.conf.sample`` file in the ``meta-poky/conf/templates/default``
directory.
@@ -351,8 +373,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 +780,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 ea674eff6..729c9746c 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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 26/53] ref-manual/structure.rst: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 26/53] ref-manual/structure.rst: " Antonin Godard
@ 2026-01-13 14:16 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 14:16 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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 | 150 +++++++++++++++++++--------------
> documentation/ref-manual/terms.rst | 2 +-
> 3 files changed, 90 insertions(+), 66 deletions(-)
>
> diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
> index 8e332aec0..9da8400d2 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 directory where the
> - different layers are cloned, run the :ref:`ref-manual/structure:``oe-init-build-env```
> + different layers are cloned, 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..3b8fb0263 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/``
> +----------------------
>
May I suggest adding a link to the upstream git repo for each layer?
[...]
> @@ -298,8 +320,8 @@ 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
> + ``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 ``meta-poky/conf/templates/default`` directory.
Should we be using the "real" path here and add layers/meta-yocto/?
>
> .. _structure-build-conf-bblayers.conf:
> @@ -319,9 +341,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
Should we be using the "real" path here and add layers/meta-yocto/?
> +:term:`Poky` reference distro, and to ``meta/conf/templates/default`` when you are
Should we be using the "real" path here and add layers/openembedded-core/?
> +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,12 +351,12 @@ 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
> + script in the :term:`Source Directory`. You can find the :term:`Poky`
The script is in oe-core, not the source directory? Should we be using
the "real" path here and add layers/openembedded-core/?
> version of the ``bblayers.conf.sample`` file in the ``meta-poky/conf/templates/default``
Should we be using the "real" path here and add layers/meta-yocto/?
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 27/53] ref-manual/tasks.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (25 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 26/53] ref-manual/structure.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 14:17 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 28/53] ref-manual/variables.rst: " Antonin Godard
` (25 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Remove references to the Poky repository, replace by OpenEmbedded-Core.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 28/53] ref-manual/variables.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (26 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 27/53] ref-manual/tasks.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 14:22 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 29/53] sdk-manual/appendix-obtain.rst: " Antonin Godard
` (24 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 ee776c110..b994c62a2 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/project/layers/meta \
+ /home/scottrif/project/layers/meta-poky \
+ /home/scottrif/project/layers/meta-yocto-bsp \
+ /home/scottrif/project/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.
@@ -1611,8 +1612,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.
@@ -1621,8 +1622,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.
@@ -1631,8 +1632,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`
@@ -1757,8 +1758,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
@@ -1928,15 +1929,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
@@ -2425,8 +2419,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::
@@ -2442,7 +2436,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.
@@ -2561,7 +2556,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::
@@ -2576,7 +2571,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.
@@ -2594,7 +2590,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"
@@ -3156,7 +3152,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.
@@ -3273,8 +3269,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)}"
@@ -3329,7 +3325,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.
@@ -3632,7 +3628,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"
@@ -4494,7 +4490,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
@@ -4712,7 +4709,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>`,
@@ -4726,7 +4723,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.
@@ -4745,8 +4742,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.
@@ -4768,14 +4765,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.
@@ -4835,7 +4832,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.
@@ -5849,7 +5846,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
@@ -6363,8 +6360,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`
@@ -6443,7 +6440,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`
@@ -6713,7 +6710,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.
@@ -7671,8 +7668,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"
@@ -8318,11 +8315,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 ``project`` and a default :term:`Build Directory` at
+ ``project/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
+ project/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.
@@ -8574,7 +8571,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
@@ -8620,7 +8617,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`"
@@ -9294,8 +9291,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)}"
@@ -10000,8 +9997,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
@@ -10402,10 +10399,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.
@@ -10536,8 +10533,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
@@ -10639,7 +10636,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::
@@ -10655,7 +10652,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`
@@ -11298,8 +11295,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
@@ -11448,13 +11445,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"
@@ -11580,13 +11577,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
+ ``project``, a default :term:`Build Directory` at ``project/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
+ project/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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 29/53] sdk-manual/appendix-obtain.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (27 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 28/53] ref-manual/variables.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 14:23 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 30/53] sdk-manual/intro.rst: " Antonin Godard
` (23 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 33787a225..cc11c97df 100644
--- a/documentation/sdk-manual/appendix-obtain.rst
+++ b/documentation/sdk-manual/appendix-obtain.rst
@@ -149,7 +149,7 @@ build the SDK installer. Follow these steps:
#. *Run the Installer:* You can now run the SDK installer from
``tmp/deploy/sdk`` in the :term:`Build Directory`. Here is an example::
- $ cd poky/build/tmp/deploy/sdk
+ $ cd project/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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 30/53] sdk-manual/intro.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (28 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 29/53] sdk-manual/appendix-obtain.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 14:24 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 31/53] test-manual/runtime-testing.rst: " Antonin Godard
` (22 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Remove the mention of the Poky git repository. Refer to the existing
setup instructions.
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 fbfc8c2ac..68be2ca5d 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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 31/53] test-manual/runtime-testing.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (29 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 30/53] sdk-manual/intro.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 14:24 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 32/53] toaster-manual: " Antonin Godard
` (21 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Remove reference to the Poky repository, replace by OpenEmbedded-Core.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 32/53] toaster-manual: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (30 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 31/53] test-manual/runtime-testing.rst: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 14:41 ` [docs] " Quentin Schulz
2025-12-24 16:31 ` [PATCH 33/53] README: " Antonin Godard
` (20 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Adapt the Toaster documentation after the Poky became obsolete.
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
---
documentation/toaster-manual/reference.rst | 12 +++---
documentation/toaster-manual/setup-and-use.rst | 56 ++++++++++++++------------
documentation/toaster-manual/start.rst | 6 +--
3 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/documentation/toaster-manual/reference.rst b/documentation/toaster-manual/reference.rst
index 3050b5d0f5..4dbcda37ff 100644
--- a/documentation/toaster-manual/reference.rst
+++ b/documentation/toaster-manual/reference.rst
@@ -161,16 +161,15 @@ As shipped, Toaster is configured to work with the following releases:
- *Yocto Project &DISTRO; "&DISTRO_NAME;" or OpenEmbedded "&DISTRO_NAME;":*
This release causes your Toaster projects to build against the head
of the &DISTRO_NAME_NO_CAP; branch at
- :yocto_git:`/poky/log/?h=&DISTRO_NAME_NO_CAP;` or
:oe_git:`/openembedded-core/commit/?h=&DISTRO_NAME_NO_CAP;`.
- *Yocto Project "Master" or OpenEmbedded "Master":* This release
causes your Toaster Projects to build against the head of the master
branch, which is where active development takes place, at
- :yocto_git:`/poky/log/` or :oe_git:`/openembedded-core/log/`.
+ :oe_git:`/openembedded-core/log/`.
- *Local Yocto Project or Local OpenEmbedded:* This release causes your
- Toaster Projects to build against the head of the ``poky`` or
+ Toaster Projects to build against the head of the
``openembedded-core`` clone you have local to the machine running
Toaster.
@@ -277,7 +276,7 @@ release selection:
<!-- Bitbake versions which correspond to the metadata release -->
<object model="orm.bitbakeversion" pk="1">
<field type="CharField" name="name">&DISTRO_NAME_NO_CAP;</field>
- <field type="CharField" name="giturl">git://git.yoctoproject.org/poky</field>
+ <field type="CharField" name="giturl">git://git.openembedded.org/bitbake</field>
<field type="CharField" name="branch">&DISTRO_NAME_NO_CAP;</field>
<field type="CharField" name="dirpath">bitbake</field>
</object>
@@ -513,8 +512,7 @@ at the
`Django <https://docs.djangoproject.com/en/2.2/topics/settings/>`__
site. However, several ``manage.py`` commands have been created that are
specific to Toaster and are used to control configuration and back-end
-tasks. You can locate these commands in the
-:term:`Source Directory` (e.g. ``poky``) at
+tasks. You can locate these commands in :term:`BitBake` at
``bitbake/lib/manage.py``. This section documents those commands.
.. note::
@@ -551,7 +549,7 @@ example that assumes default repository and :term:`Build Directory` names:
.. code-block:: shell
- $ cd poky/build
+ $ cd project/build
$ python ../bitbake/lib/toaster/manage.py buildslist
If your Toaster database had only one build, the above
diff --git a/documentation/toaster-manual/setup-and-use.rst b/documentation/toaster-manual/setup-and-use.rst
index a0c27499ba..6ca5d252a3 100644
--- a/documentation/toaster-manual/setup-and-use.rst
+++ b/documentation/toaster-manual/setup-and-use.rst
@@ -15,15 +15,15 @@ Toaster`" chapter, you are ready to start
Toaster.
Navigate to the root of your
-:term:`Source Directory` (e.g. ``poky``)::
+:term:`Source Directory` (e.g. ``project``)::
- $ cd poky
+ $ cd project
Once in that directory, source the build environment script::
- $ source oe-init-build-env
+ $ source layers/openembedded-core/oe-init-build-env
-Next, from the :term:`Build Directory` (e.g. ``poky/build``), start Toaster
+Next, from the :term:`Build Directory` (e.g. ``project/build``), start Toaster
using this command::
$ source toaster start
@@ -112,8 +112,8 @@ This example binds to a specific IP address on the host's NIC::
The Directory for Cloning Layers
================================
-Toaster creates a ``_toaster_clones`` directory inside your Source
-Directory (i.e. ``poky``) to clone any layers needed for your builds.
+Toaster creates a ``_toaster_clones`` directory inside your :term:`Source
+Directory` to clone any layers needed for your builds.
Alternatively, if you would like all of your Toaster related files and
directories to be in a particular location other than the default, you
@@ -124,8 +124,8 @@ causes Toaster to create and use ``$TOASTER_DIR./_toaster_clones``.
The Build Directory
===================
-Toaster creates a :term:`Build Directory` within your Source Directory (e.g.
-``poky``) to execute the builds.
+Toaster creates a :term:`Build Directory` within your :term:`Source Directory`
+to execute the builds.
Alternatively, if you would like all of your Toaster related files and
directories to be in a particular location, you can set the
@@ -155,8 +155,8 @@ superuser by following these steps:
is the :term:`Build Directory`, invoke the ``createsuperuser`` command from
``manage.py``::
- $ cd poky/build
- $ ../bitbake/lib/toaster/manage.py createsuperuser
+ $ cd project/build
+ $ ../layers/bitbake/lib/toaster/manage.py createsuperuser
#. Django prompts you for the username, which you need to provide.
@@ -233,17 +233,21 @@ Perform the following steps to install Toaster:
$ sudo /usr/sbin/useradd toaster -md /var/www/toaster -s /bin/false
$ sudo su - toaster -s /bin/bash
-#. Checkout a copy of ``poky`` into the web server directory. You will
+#. Checkout a copy of :term:`BitBake` into the web server directory. You will
be using ``/var/www/toaster``::
- $ git clone git://git.yoctoproject.org/poky
- $ git checkout &DISTRO_NAME_NO_CAP;
+ $ git clone git://git.openembedded.org/bitbake
+
+#. Checkout a version of :term:`BitBake` matching the current Yocto Project
+ &DISTRO_NAME; release::
+
+ $ git checkout &BITBAKE_SERIES;
#. Install Toaster dependencies using the ``--user`` flag which keeps the
Python packages isolated from your system-provided packages::
$ cd /var/www/toaster/
- $ pip3 install --user -r ./poky/bitbake/toaster-requirements.txt
+ $ pip3 install --user -r ./bitbake/toaster-requirements.txt
$ pip3 install --user mysqlclient
.. note::
@@ -253,7 +257,7 @@ Perform the following steps to install Toaster:
manager to install the packages.
#. Configure Toaster by editing
- ``/var/www/toaster/poky/bitbake/lib/toaster/toastermain/settings.py``
+ ``/var/www/toaster/bitbake/lib/toaster/toastermain/settings.py``
as follows:
- Edit the
@@ -298,9 +302,9 @@ Perform the following steps to install Toaster:
#. Get Toaster to create the database schema, default data, and gather
the statically-served files::
- $ cd /var/www/toaster/poky/
+ $ cd /var/www/toaster/
$ ./bitbake/lib/toaster/manage.py migrate
- $ TOASTER_DIR=`pwd\` TEMPLATECONF='poky' \
+ $ TOASTER_DIR=`pwd` TEMPLATECONF='poky' \
./bitbake/lib/toaster/manage.py checksettings
$ ./bitbake/lib/toaster/manage.py collectstatic
@@ -322,12 +326,12 @@ Perform the following steps to install Toaster:
directory is created on the file system. In the example above,
``TOASTER_DIR`` is set as follows::
- /var/www/toaster/poky
+ /var/www/toaster/
This setting causes the Toaster :term:`Build Directory` to be::
- /var/www/toaster/poky/build
+ /var/www/toaster/build
Finally, the ``collectstatic`` command is a Django framework command
that collects all the statically served files into a designated
@@ -380,14 +384,14 @@ Perform the following steps to install Toaster:
</IfModule>
</Directory>
- <Directory /var/www/toaster/poky/bitbake/lib/toaster/toastermain>
+ <Directory /var/www/toaster/bitbake/lib/toaster/toastermain>
<Files "wsgi.py">
Require all granted
</Files>
</Directory>
- WSGIDaemonProcess toaster_wsgi python-path=/var/www/toaster/poky/bitbake/lib/toaster:/var/www/toaster/.local/lib/python3.4/site-packages
- WSGIScriptAlias / "/var/www/toaster/poky/bitbake/lib/toaster/toastermain/wsgi.py"
+ WSGIDaemonProcess toaster_wsgi python-path=/var/www/toaster/bitbake/lib/toaster:/var/www/toaster/.local/lib/python3.4/site-packages
+ WSGIScriptAlias / "/var/www/toaster/bitbake/lib/toaster/toastermain/wsgi.py"
<Location />
WSGIProcessGroup toaster_wsgi
</Location>
@@ -419,16 +423,16 @@ Perform the following steps to install Toaster:
[Service]
Type=forking User=toaster
- ExecStart=/usr/bin/screen -d -m -S runbuilds /var/www/toaster/poky/bitbake/lib/toaster/runbuilds-service.sh start
+ ExecStart=/usr/bin/screen -d -m -S runbuilds /var/www/toaster/bitbake/lib/toaster/runbuilds-service.sh start
ExecStop=/usr/bin/screen -S runbuilds -X quit
- WorkingDirectory=/var/www/toaster/poky
+ WorkingDirectory=/var/www/toaster
[Install]
WantedBy=multi-user.target
Prepare the ``runbuilds-service.sh`` script that you need to place in the
- ``/var/www/toaster/poky/bitbake/lib/toaster/`` directory by setting
+ ``/var/www/toaster/bitbake/lib/toaster/`` directory by setting
up executable permissions::
#!/bin/bash
@@ -436,7 +440,7 @@ Perform the following steps to install Toaster:
#export http_proxy=http://proxy.host.com:8080
#export https_proxy=http://proxy.host.com:8080
#export GIT_PROXY_COMMAND=$HOME/bin/gitproxy
- cd poky/
+ cd /var/www/toaster/
source ./oe-init-build-env build
source ../bitbake/bin/toaster $1 noweb
[ "$1" == 'start' ] && /bin/bash
diff --git a/documentation/toaster-manual/start.rst b/documentation/toaster-manual/start.rst
index 2d6474852a..ed7b0e1644 100644
--- a/documentation/toaster-manual/start.rst
+++ b/documentation/toaster-manual/start.rst
@@ -25,10 +25,8 @@ Establishing Toaster System Dependencies
Toaster requires extra Python dependencies in order to run. A Toaster
requirements file named ``toaster-requirements.txt`` defines the Python
-dependencies. The requirements file is located in the ``bitbake``
-directory, which is located in the root directory of the
-:term:`Source Directory` (e.g.
-``poky/bitbake/toaster-requirements.txt``). The dependencies appear in a
+dependencies. The requirements file is located in the :term:`BitBake`
+repository, (``bitbake/toaster-requirements.txt``). The dependencies appear in a
``pip``, install-compatible format.
Install Toaster Packages
--
2.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 32/53] toaster-manual: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 32/53] toaster-manual: " Antonin Godard
@ 2026-01-13 14:41 ` Quentin Schulz
2026-01-26 15:39 ` Antonin Godard
0 siblings, 1 reply; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 14:41 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, Antonin Godard via lists.yoctoproject.org wrote:
> Adapt the Toaster documentation after the Poky became obsolete.
>
> Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
> ---
> documentation/toaster-manual/reference.rst | 12 +++---
> documentation/toaster-manual/setup-and-use.rst | 56 ++++++++++++++------------
> documentation/toaster-manual/start.rst | 6 +--
> 3 files changed, 37 insertions(+), 37 deletions(-)
>
> diff --git a/documentation/toaster-manual/reference.rst b/documentation/toaster-manual/reference.rst
> index 3050b5d0f5..4dbcda37ff 100644
> --- a/documentation/toaster-manual/reference.rst
> +++ b/documentation/toaster-manual/reference.rst
> @@ -161,16 +161,15 @@ As shipped, Toaster is configured to work with the following releases:
> - *Yocto Project &DISTRO; "&DISTRO_NAME;" or OpenEmbedded "&DISTRO_NAME;":*
> This release causes your Toaster projects to build against the head
> of the &DISTRO_NAME_NO_CAP; branch at
> - :yocto_git:`/poky/log/?h=&DISTRO_NAME_NO_CAP;` or
> :oe_git:`/openembedded-core/commit/?h=&DISTRO_NAME_NO_CAP;`.
>
> - *Yocto Project "Master" or OpenEmbedded "Master":* This release
> causes your Toaster Projects to build against the head of the master
> branch, which is where active development takes place, at
> - :yocto_git:`/poky/log/` or :oe_git:`/openembedded-core/log/`.
> + :oe_git:`/openembedded-core/log/`.
>
> - *Local Yocto Project or Local OpenEmbedded:* This release causes your
> - Toaster Projects to build against the head of the ``poky`` or
> + Toaster Projects to build against the head of the
> ``openembedded-core`` clone you have local to the machine running
> Toaster.
>
I've never used Toaster, but isn't that a selection? E.g. Yocto Project
is for setting up like how it used to be with poky, and OpenEmbedded
only with oe-core + bitbake?
I'm not sure it's as simple as removing mentions to poky/rename them to
oe-core?
> @@ -277,7 +276,7 @@ release selection:
> <!-- Bitbake versions which correspond to the metadata release -->
> <object model="orm.bitbakeversion" pk="1">
> <field type="CharField" name="name">&DISTRO_NAME_NO_CAP;</field>
> - <field type="CharField" name="giturl">git://git.yoctoproject.org/poky</field>
> + <field type="CharField" name="giturl">git://git.openembedded.org/bitbake</field>
> <field type="CharField" name="branch">&DISTRO_NAME_NO_CAP;</field>
> <field type="CharField" name="dirpath">bitbake</field>
Uuuuh... Is this correct? I would assume this is the way to find where
bitbake is. But that's how it used to be for poky (where bitbake was in
a bitbake/ subdir?), so not sure what there should be in dirpath for
example (or if this code-block is enough?).
> </object>
> @@ -513,8 +512,7 @@ at the
> `Django <https://docs.djangoproject.com/en/2.2/topics/settings/>`__
> site. However, several ``manage.py`` commands have been created that are
> specific to Toaster and are used to control configuration and back-end
> -tasks. You can locate these commands in the
> -:term:`Source Directory` (e.g. ``poky``) at
> +tasks. You can locate these commands in :term:`BitBake` at
> ``bitbake/lib/manage.py``. This section documents those commands.
I'm getting confused now as whether we should be prefixing the paths
with the name of the root directory or not. Here since we say in
BitBake, I would assume we should only need lib/manage.py?
>
> .. note::
> @@ -551,7 +549,7 @@ example that assumes default repository and :term:`Build Directory` names:
>
> .. code-block:: shell
>
> - $ cd poky/build
> + $ cd project/build
> $ python ../bitbake/lib/toaster/manage.py buildslist
>
> If your Toaster database had only one build, the above
> diff --git a/documentation/toaster-manual/setup-and-use.rst b/documentation/toaster-manual/setup-and-use.rst
> index a0c27499ba..6ca5d252a3 100644
> --- a/documentation/toaster-manual/setup-and-use.rst
> +++ b/documentation/toaster-manual/setup-and-use.rst
> @@ -15,15 +15,15 @@ Toaster`" chapter, you are ready to start
> Toaster.
>
> Navigate to the root of your
> -:term:`Source Directory` (e.g. ``poky``)::
> +:term:`Source Directory` (e.g. ``project``)::
>
> - $ cd poky
> + $ cd project
>
> Once in that directory, source the build environment script::
>
> - $ source oe-init-build-env
> + $ source layers/openembedded-core/oe-init-build-env
>
> -Next, from the :term:`Build Directory` (e.g. ``poky/build``), start Toaster
> +Next, from the :term:`Build Directory` (e.g. ``project/build``), start Toaster
> using this command::
>
> $ source toaster start
> @@ -112,8 +112,8 @@ This example binds to a specific IP address on the host's NIC::
> The Directory for Cloning Layers
> ================================
>
> -Toaster creates a ``_toaster_clones`` directory inside your Source
> -Directory (i.e. ``poky``) to clone any layers needed for your builds.
> +Toaster creates a ``_toaster_clones`` directory inside your :term:`Source
> +Directory` to clone any layers needed for your builds.
>
> Alternatively, if you would like all of your Toaster related files and
> directories to be in a particular location other than the default, you
> @@ -124,8 +124,8 @@ causes Toaster to create and use ``$TOASTER_DIR./_toaster_clones``.
> The Build Directory
> ===================
>
> -Toaster creates a :term:`Build Directory` within your Source Directory (e.g.
> -``poky``) to execute the builds.
> +Toaster creates a :term:`Build Directory` within your :term:`Source Directory`
> +to execute the builds.
>
> Alternatively, if you would like all of your Toaster related files and
> directories to be in a particular location, you can set the
> @@ -155,8 +155,8 @@ superuser by following these steps:
> is the :term:`Build Directory`, invoke the ``createsuperuser`` command from
> ``manage.py``::
>
> - $ cd poky/build
> - $ ../bitbake/lib/toaster/manage.py createsuperuser
> + $ cd project/build
> + $ ../layers/bitbake/lib/toaster/manage.py createsuperuser
>
> #. Django prompts you for the username, which you need to provide.
>
> @@ -233,17 +233,21 @@ Perform the following steps to install Toaster:
> $ sudo /usr/sbin/useradd toaster -md /var/www/toaster -s /bin/false
> $ sudo su - toaster -s /bin/bash
>
> -#. Checkout a copy of ``poky`` into the web server directory. You will
> +#. Checkout a copy of :term:`BitBake` into the web server directory. You will
> be using ``/var/www/toaster``::
>
> - $ git clone git://git.yoctoproject.org/poky
> - $ git checkout &DISTRO_NAME_NO_CAP;
> + $ git clone git://git.openembedded.org/bitbake
> +
> +#. Checkout a version of :term:`BitBake` matching the current Yocto Project
> + &DISTRO_NAME; release::
Where do I find this information? **I** know I can get it from
https://wiki.yoctoproject.org/wiki/Releases but we don't usually
recommend going to the wiki because it may end up unmaintained/outdated
(though if there's one page that is rarely outdated for long it's this
one :) ).
> +
> + $ git checkout &BITBAKE_SERIES;
>
> #. Install Toaster dependencies using the ``--user`` flag which keeps the
> Python packages isolated from your system-provided packages::
>
> $ cd /var/www/toaster/
> - $ pip3 install --user -r ./poky/bitbake/toaster-requirements.txt
> + $ pip3 install --user -r ./bitbake/toaster-requirements.txt
> $ pip3 install --user mysqlclient
>
> .. note::
> @@ -253,7 +257,7 @@ Perform the following steps to install Toaster:
> manager to install the packages.
>
> #. Configure Toaster by editing
> - ``/var/www/toaster/poky/bitbake/lib/toaster/toastermain/settings.py``
> + ``/var/www/toaster/bitbake/lib/toaster/toastermain/settings.py``
> as follows:
>
> - Edit the
> @@ -298,9 +302,9 @@ Perform the following steps to install Toaster:
> #. Get Toaster to create the database schema, default data, and gather
> the statically-served files::
>
> - $ cd /var/www/toaster/poky/
> + $ cd /var/www/toaster/
> $ ./bitbake/lib/toaster/manage.py migrate
> - $ TOASTER_DIR=`pwd\` TEMPLATECONF='poky' \
> + $ TOASTER_DIR=`pwd` TEMPLATECONF='poky' \
> ./bitbake/lib/toaster/manage.py checksettings
> $ ./bitbake/lib/toaster/manage.py collectstatic
>
> @@ -322,12 +326,12 @@ Perform the following steps to install Toaster:
> directory is created on the file system. In the example above,
> ``TOASTER_DIR`` is set as follows::
>
> - /var/www/toaster/poky
> + /var/www/toaster/
>
>
> This setting causes the Toaster :term:`Build Directory` to be::
>
> - /var/www/toaster/poky/build
> + /var/www/toaster/build
>
> Finally, the ``collectstatic`` command is a Django framework command
> that collects all the statically served files into a designated
> @@ -380,14 +384,14 @@ Perform the following steps to install Toaster:
> </IfModule>
> </Directory>
>
> - <Directory /var/www/toaster/poky/bitbake/lib/toaster/toastermain>
> + <Directory /var/www/toaster/bitbake/lib/toaster/toastermain>
> <Files "wsgi.py">
> Require all granted
> </Files>
> </Directory>
>
> - WSGIDaemonProcess toaster_wsgi python-path=/var/www/toaster/poky/bitbake/lib/toaster:/var/www/toaster/.local/lib/python3.4/site-packages
> - WSGIScriptAlias / "/var/www/toaster/poky/bitbake/lib/toaster/toastermain/wsgi.py"
> + WSGIDaemonProcess toaster_wsgi python-path=/var/www/toaster/bitbake/lib/toaster:/var/www/toaster/.local/lib/python3.4/site-packages
> + WSGIScriptAlias / "/var/www/toaster/bitbake/lib/toaster/toastermain/wsgi.py"
> <Location />
> WSGIProcessGroup toaster_wsgi
> </Location>
> @@ -419,16 +423,16 @@ Perform the following steps to install Toaster:
>
> [Service]
> Type=forking User=toaster
> - ExecStart=/usr/bin/screen -d -m -S runbuilds /var/www/toaster/poky/bitbake/lib/toaster/runbuilds-service.sh start
> + ExecStart=/usr/bin/screen -d -m -S runbuilds /var/www/toaster/bitbake/lib/toaster/runbuilds-service.sh start
> ExecStop=/usr/bin/screen -S runbuilds -X quit
> - WorkingDirectory=/var/www/toaster/poky
> + WorkingDirectory=/var/www/toaster
>
> [Install]
> WantedBy=multi-user.target
>
>
> Prepare the ``runbuilds-service.sh`` script that you need to place in the
> - ``/var/www/toaster/poky/bitbake/lib/toaster/`` directory by setting
> + ``/var/www/toaster/bitbake/lib/toaster/`` directory by setting
> up executable permissions::
>
> #!/bin/bash
> @@ -436,7 +440,7 @@ Perform the following steps to install Toaster:
> #export http_proxy=http://proxy.host.com:8080/
> #export https_proxy=http://proxy.host.com:8080/
> #export GIT_PROXY_COMMAND=$HOME/bin/gitproxy
> - cd poky/
> + cd /var/www/toaster/
> source ./oe-init-build-env build
Is this correct? I believe we need to cd into openembedded-core for this
to work no?
> source ../bitbake/bin/toaster $1 noweb
> [ "$1" == 'start' ] && /bin/bash
> diff --git a/documentation/toaster-manual/start.rst b/documentation/toaster-manual/start.rst
> index 2d6474852a..ed7b0e1644 100644
> --- a/documentation/toaster-manual/start.rst
> +++ b/documentation/toaster-manual/start.rst
> @@ -25,10 +25,8 @@ Establishing Toaster System Dependencies
>
> Toaster requires extra Python dependencies in order to run. A Toaster
> requirements file named ``toaster-requirements.txt`` defines the Python
> -dependencies. The requirements file is located in the ``bitbake``
> -directory, which is located in the root directory of the
> -:term:`Source Directory` (e.g.
> -``poky/bitbake/toaster-requirements.txt``). The dependencies appear in a
> +dependencies. The requirements file is located in the :term:`BitBake`
> +repository, (``bitbake/toaster-requirements.txt``). The dependencies appear in a
"bitbake/" prefix or no prefix, that is the question.
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 33/53] README: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (31 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 32/53] toaster-manual: " Antonin Godard
@ 2025-12-24 16:31 ` Antonin Godard
2026-01-13 14:44 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 34/53] contributor-guide/identify-component.rst: " Antonin Godard
` (19 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:31 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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..58b00ff5c 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 project-&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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 33/53] README: remove obsolete poky repo references
2025-12-24 16:31 ` [PATCH 33/53] README: " Antonin Godard
@ 2026-01-13 14:44 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 14:44 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:31 PM, 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/README | 39 ++++++++++-----------------------------
> 1 file changed, 10 insertions(+), 29 deletions(-)
>
> diff --git a/documentation/README b/documentation/README
> index 56eac7ca1..58b00ff5c 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 project-&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;
YOCTO_GIT_URL doesn't exist anymore, please send a follow-up patch to
fix that oversight.
Same for the nested variable, but you can replace with
YOCTO_RELEASE_DL_URL and YOCTO_DL_URL for example.
These are unrelated to the patch, so
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 34/53] contributor-guide/identify-component.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (32 preceding siblings ...)
2025-12-24 16:31 ` [PATCH 33/53] README: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 14:45 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 35/53] dev-manual/build-quality.rst: " Antonin Godard
` (18 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Refresh the document now that the Poky repository is obsolete.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 35/53] dev-manual/build-quality.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (33 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 34/53] contributor-guide/identify-component.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 14:46 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 36/53] dev-manual/custom-distribution.rst: " Antonin Godard
` (17 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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..8867f6dcb 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^
+ $ project/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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 36/53] dev-manual/custom-distribution.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (34 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 35/53] dev-manual/build-quality.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 14:49 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 37/53] dev-manual/custom-template-configuration-directory.rst: " Antonin Godard
` (16 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Refresh the document now that the Poky repository is obsolete.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 37/53] dev-manual/custom-template-configuration-directory.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (35 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 36/53] dev-manual/custom-distribution.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 14:50 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 38/53] dev-manual/init-manager.rst: " Antonin Godard
` (15 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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..0750420abf 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/project/layers/meta-alex/conf/templates/test-1
+ Please review the files in there, and particularly provide a configuration description in /srv/project/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/project/layers/meta-alex/conf/templates/test-1 . /srv/project/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/project/layers/meta-alex/conf/templates/test-1 . /srv/project/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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 38/53] dev-manual/init-manager.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (36 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 37/53] dev-manual/custom-template-configuration-directory.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 14:50 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 39/53] dev-manual/licenses.rst: " Antonin Godard
` (14 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Refresh the document now that the Poky repository is obsolete.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 39/53] dev-manual/licenses.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (37 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 38/53] dev-manual/init-manager.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 15:04 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 40/53] dev-manual/packages.rst: " Antonin Godard
` (13 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 | 28 +++++++++++-----------------
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/documentation/dev-manual/licenses.rst b/documentation/dev-manual/licenses.rst
index 7d6636eef..edd503bd6 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/gst-plugins-ugly`` of
+:term:`OpenEmbedded-Core (OE-Core)` recipe 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/gst-plugins-ugly`` of
+:term:`OpenEmbedded-Core (OE-Core)` package, 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 ?= ""
@@ -464,18 +465,11 @@ those 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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 39/53] dev-manual/licenses.rst: remove obsolete poky repo references
2025-12-24 16:32 ` [PATCH 39/53] dev-manual/licenses.rst: " Antonin Godard
@ 2026-01-13 15:04 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 15:04 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:32 PM, 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 | 28 +++++++++++-----------------
> 1 file changed, 11 insertions(+), 17 deletions(-)
>
> diff --git a/documentation/dev-manual/licenses.rst b/documentation/dev-manual/licenses.rst
> index 7d6636eef..edd503bd6 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/gst-plugins-ugly`` of
> +:term:`OpenEmbedded-Core (OE-Core)` recipe contains the following statement::
"recipe" should be before "of OE-Core".
>
> 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/gst-plugins-ugly`` of
> +:term:`OpenEmbedded-Core (OE-Core)` package, you
"package" should be before "of OE-Core".
Isn't the package named gstreamer1.0-plugins-ugly? c.f. recipe
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.26.9.bb
BTW, there's a "those those" (newline between both) in the file,
https://git.yoctoproject.org/yocto-docs/tree/documentation/dev-manual/licenses.rst#n462,
needs fixing.
> 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 ?= ""
> @@ -464,18 +465,11 @@ those 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 {} \;
>
We should probably recommend using git-archive instead of removing the
.git directory as that is destructive.
find . -name ".git" -type d -exec sh -c 'PROJ=$(basename "$(dirname
"$0")"); git archive -C "$0" --format=tar.gz -o ../"$PROJ".tar.gz
--prefix "$PROJ"/ HEAD' {} ';'
(not tested).
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 40/53] dev-manual/packages.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (38 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 39/53] dev-manual/licenses.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 15:05 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 41/53] dev-manual/python-development-shell.rst: " Antonin Godard
` (12 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/documentation/dev-manual/packages.rst b/documentation/dev-manual/packages.rst
index 8bd48c8e8..a27c076c3 100644
--- a/documentation/dev-manual/packages.rst
+++ b/documentation/dev-manual/packages.rst
@@ -362,7 +362,7 @@ 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
+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 +543,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``).
+ ``project/build/conf/local.conf``).
#. Select the desired package format as follows::
@@ -637,10 +637,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 ``project/build``
and a :term:`PACKAGE_CLASSES` setting of ":ref:`ref-classes-package_rpm`"::
- $ cd poky/build/tmp/deploy/rpm
+ $ cd project/build/tmp/deploy/rpm
$ python3 -m http.server
Target Setup
--
2.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 40/53] dev-manual/packages.rst: remove obsolete poky repo references
2025-12-24 16:32 ` [PATCH 40/53] dev-manual/packages.rst: " Antonin Godard
@ 2026-01-13 15:05 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 15:05 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:32 PM, 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/packages.rst | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/documentation/dev-manual/packages.rst b/documentation/dev-manual/packages.rst
> index 8bd48c8e8..a27c076c3 100644
> --- a/documentation/dev-manual/packages.rst
> +++ b/documentation/dev-manual/packages.rst
> @@ -362,7 +362,7 @@ 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/``
Maybe provide a link to connman.inc?
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 41/53] dev-manual/python-development-shell.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (39 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 40/53] dev-manual/packages.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 15:06 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 42/53] dev-manual/qemu.rst: " Antonin Godard
` (11 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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..e03d2a6032 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/project/build/tmp/sysroots'
pydevshell> d.getVar("STAGING_DIR", False)
'${TMPDIR}/sysroots'
pydevshell> d.setVar("FOO", "bar")
--
2.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 42/53] dev-manual/qemu.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (40 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 41/53] dev-manual/python-development-shell.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 15:08 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 43/53] dev-manual/upgrading-recipes.rst: " Antonin Godard
` (10 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 9e0b8b813..2442b6dac 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`, use ``bitbake-setup`` or source
+ the environment setup script manually::
- $ cd poky
- $ source oe-init-build-env
+ .. code-block:: console
+
+ $ cd project
+ $ 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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 42/53] dev-manual/qemu.rst: remove obsolete poky repo references
2025-12-24 16:32 ` [PATCH 42/53] dev-manual/qemu.rst: " Antonin Godard
@ 2026-01-13 15:08 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 15:08 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:32 PM, 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/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 9e0b8b813..2442b6dac 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`, use ``bitbake-setup`` or source
+either?
Either use ``bitbake-setup`` or source
> + the environment setup script manually::
+with? which highlights (I find) that this applies to the latter part of
the sentence and not bitbake-setup.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 43/53] dev-manual/upgrading-recipes.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (41 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 42/53] dev-manual/qemu.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 15:09 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 44/53] dev-manual/vulnerabilities.rst: " Antonin Godard
` (9 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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..f86f515f7 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/project/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/project/build/workspace/sources/nano
+ NOTE: New recipe is /home/scottrif/project/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/project/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/project/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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 44/53] dev-manual/vulnerabilities.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (42 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 43/53] dev-manual/upgrading-recipes.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 15:11 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 45/53] ref-manual/devtool-reference.rst: " Antonin Godard
` (8 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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/dev-manual/vulnerabilities.rst | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/documentation/dev-manual/vulnerabilities.rst b/documentation/dev-manual/vulnerabilities.rst
index 6eaf75758..e6135a525 100644
--- a/documentation/dev-manual/vulnerabilities.rst
+++ b/documentation/dev-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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 45/53] ref-manual/devtool-reference.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (43 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 44/53] dev-manual/vulnerabilities.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 15:13 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 46/53] ref-manual/faq.rst: " Antonin Godard
` (7 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/documentation/ref-manual/devtool-reference.rst b/documentation/ref-manual/devtool-reference.rst
index 5ac567591..69288744a 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,7 +390,7 @@ 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>`
+See :oe_git:`base-passwd.bb </openembedded-core/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb?h=kirkstone>`
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/project/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/project/build/workspace/sources/mtr (/home/scottrif/project/build/workspace/recipes/mtr/mtr_0.86.bb)
$
.. _devtool-search-for-available-target-recipes:
--
2.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 45/53] ref-manual/devtool-reference.rst: remove obsolete poky repo references
2025-12-24 16:32 ` [PATCH 45/53] ref-manual/devtool-reference.rst: " Antonin Godard
@ 2026-01-13 15:13 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 15:13 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:32 PM, 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/devtool-reference.rst | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/documentation/ref-manual/devtool-reference.rst b/documentation/ref-manual/devtool-reference.rst
> index 5ac567591..69288744a 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,7 +390,7 @@ 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>`
> +See :oe_git:`base-passwd.bb </openembedded-core/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb?
h=kirkstone>`
It's 3.5.52 now. But maybe we should just point at the parent directory
so it's never outdated?
With that,
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 46/53] ref-manual/faq.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (44 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 45/53] ref-manual/devtool-reference.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 15:16 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 47/53] ref-manual/features.rst: " Antonin Godard
` (6 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 406b2c388..cd4801baa 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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 46/53] ref-manual/faq.rst: remove obsolete poky repo references
2025-12-24 16:32 ` [PATCH 46/53] ref-manual/faq.rst: " Antonin Godard
@ 2026-01-13 15:16 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 15:16 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:32 PM, 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.
>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 47/53] ref-manual/features.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (45 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 46/53] ref-manual/faq.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 15:17 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 48/53] ref-manual/release-process.rst: " Antonin Godard
` (5 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Refresh the document now that the Poky repository is obsolete.
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 40651a4c9..d59c53b0f 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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 48/53] ref-manual/release-process.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (46 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 47/53] ref-manual/features.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 15:19 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 49/53] ref-manual/system-requirements.rst: " Antonin Godard
` (4 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Refresh the document now that the Poky repository is obsolete.
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 826354844..7b428efad 100644
--- a/documentation/ref-manual/release-process.rst
+++ b/documentation/ref-manual/release-process.rst
@@ -193,10 +193,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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 48/53] ref-manual/release-process.rst: remove obsolete poky repo references
2025-12-24 16:32 ` [PATCH 48/53] ref-manual/release-process.rst: " Antonin Godard
@ 2026-01-13 15:19 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 15:19 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:32 PM, 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/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 826354844..7b428efad 100644
> --- a/documentation/ref-manual/release-process.rst
> +++ b/documentation/ref-manual/release-process.rst
> @@ -193,10 +193,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
"in the" is repeated twice (start of this line and end of the previous
one), a follow-up patch would be nice.
Unrelated though, so
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 49/53] ref-manual/system-requirements.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (47 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 48/53] ref-manual/release-process.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 15:21 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 50/53] ref-manual/yocto-project-supported-features.rst: remove obsolete poky repo reference Antonin Godard
` (3 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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..e8d6830b1 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/project
+ $ ./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/project/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/project
$ 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/project
$ 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/project/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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 49/53] ref-manual/system-requirements.rst: remove obsolete poky repo references
2025-12-24 16:32 ` [PATCH 49/53] ref-manual/system-requirements.rst: " Antonin Godard
@ 2026-01-13 15:21 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 15:21 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:32 PM, 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..e8d6830b1 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/project
> + $ ./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/project/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/project
> $ scripts/install-buildtools
uuuuuh... Shouldn't this be
./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/project
> $ scripts/install-buildtools --make-only
>
Ditto.
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 50/53] ref-manual/yocto-project-supported-features.rst: remove obsolete poky repo reference
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (48 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 49/53] ref-manual/system-requirements.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 15:21 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 51/53] test-manual/reproducible-builds.rst: remove obsolete poky repo references Antonin Godard
` (2 subsequent siblings)
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Poky -> meta-yocto link replacement.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 51/53] test-manual/reproducible-builds.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (49 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 50/53] ref-manual/yocto-project-supported-features.rst: remove obsolete poky repo reference Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 15:22 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 52/53] test-manual/understand-autobuilder.rst: " Antonin Godard
2025-12-24 16:32 ` [PATCH 53/53] what-i-wish-id-known.rst: " Antonin Godard
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, Antonin Godard
Refresh the document now that the Poky repository is obsolete.
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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* [PATCH 52/53] test-manual/understand-autobuilder.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (50 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 51/53] test-manual/reproducible-builds.rst: remove obsolete poky repo references Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 15:23 ` [docs] " Quentin Schulz
2025-12-24 16:32 ` [PATCH 53/53] what-i-wish-id-known.rst: " Antonin Godard
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/documentation/test-manual/understand-autobuilder.rst b/documentation/test-manual/understand-autobuilder.rst
index 23b3ef7d7..2b5eb144f 100644
--- a/documentation/test-manual/understand-autobuilder.rst
+++ b/documentation/test-manual/understand-autobuilder.rst
@@ -104,7 +104,7 @@ roughly consist of:
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
+ :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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 52/53] test-manual/understand-autobuilder.rst: remove obsolete poky repo references
2025-12-24 16:32 ` [PATCH 52/53] test-manual/understand-autobuilder.rst: " Antonin Godard
@ 2026-01-13 15:23 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 15:23 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:32 PM, 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/test-manual/understand-autobuilder.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/documentation/test-manual/understand-autobuilder.rst b/documentation/test-manual/understand-autobuilder.rst
> index 23b3ef7d7..2b5eb144f 100644
> --- a/documentation/test-manual/understand-autobuilder.rst
> +++ b/documentation/test-manual/understand-autobuilder.rst
> @@ -104,7 +104,7 @@ roughly consist of:
> 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
> + :term:`OpenEmbedded-Core (OE-Core)` repository, as well as additional layers. It will use the data
We already listed OE-Core as "might clone" in the previous sentence.
Just merge both, into
"""
It might clone the BitBake repository, :term:`OpenEmbedded-Core
(OE-Core)` repository, as well as additional layers.
"""
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
* [PATCH 53/53] what-i-wish-id-known.rst: remove obsolete poky repo references
2025-12-24 16:31 [PATCH 00/53] Remove obsolete poky repo references Antonin Godard
` (51 preceding siblings ...)
2025-12-24 16:32 ` [PATCH 52/53] test-manual/understand-autobuilder.rst: " Antonin Godard
@ 2025-12-24 16:32 ` Antonin Godard
2026-01-13 15:25 ` [docs] " Quentin Schulz
52 siblings, 1 reply; 112+ messages in thread
From: Antonin Godard @ 2025-12-24 16:32 UTC (permalink / raw)
To: docs; +Cc: Thomas Petazzoni, 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..a381a6fdf 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:`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.51.0
^ permalink raw reply related [flat|nested] 112+ messages in thread* Re: [docs] [PATCH 53/53] what-i-wish-id-known.rst: remove obsolete poky repo references
2025-12-24 16:32 ` [PATCH 53/53] what-i-wish-id-known.rst: " Antonin Godard
@ 2026-01-13 15:25 ` Quentin Schulz
0 siblings, 0 replies; 112+ messages in thread
From: Quentin Schulz @ 2026-01-13 15:25 UTC (permalink / raw)
To: antonin.godard, docs; +Cc: Thomas Petazzoni
Hi Antonin,
On 12/24/25 5:32 PM, 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/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..a381a6fdf 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:`OpenEmbedded-Core (OE-Core)` and
> + possibly :yocto_git:`meta-yocto </meta-yocto>`. Never. Ever. When you update
Please also mention not modifying Bitbake git repo. For that matter, you
shouldn't modify any layer you are not the maintainer of :)
Cheers,
Quentin
^ permalink raw reply [flat|nested] 112+ messages in thread
