| Message ID | 20251224-remove-poky-references-v1-22-658a5f4dbde2@bootlin.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Remove obsolete poky repo references | expand |
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
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
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
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
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
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(-)