diff options
author | Andrew Geissler <geissonator@yahoo.com> | 2020-12-13 17:44:15 +0300 |
---|---|---|
committer | Andrew Geissler <geissonator@yahoo.com> | 2020-12-15 21:53:47 +0300 |
commit | 09209eec235a35b7089db987561c12e9bd023237 (patch) | |
tree | 2d3580484ffacafe11b72e9abaab50a428dd617d /poky/documentation/overview-manual | |
parent | f7ba29eda266e04f867e4338b6b8b10c1969419c (diff) | |
download | openbmc-09209eec235a35b7089db987561c12e9bd023237.tar.xz |
poky: subtree update:0ac99625bf..796be0593a
Alexander Kanavin (31):
netbase: upgrade 6.1 -> 6.2
meson: upgrade 0.55.1 -> 0.56.0
vulkan-samples: update to latest revision
libcap: update 2.44 -> 2.45
bind: upgrade 9.16.7 -> 9.16.9
quota: upgrade 4.05 -> 4.06
pango: upgrade 1.46.2 -> 1.48.0
elfutils: upgrade 0.181 -> 0.182
ifupdown: upgrade 0.8.35 -> 0.8.36
createrepo-c: upgrade 0.16.1 -> 0.16.2
acpica: upgrade 20200925 -> 20201113
grep: upgrade 3.5 -> 3.6
man-pages: upgrade 5.08 -> 5.09
stress-ng: upgrade 0.11.23 -> 0.11.24
libhandy: upgrade 1.0.1 -> 1.0.2
piglit: upgrade to latest revision
xkbcomp: upgrade 1.4.3 -> 1.4.4
lz4: upgrade 1.9.2 -> 1.9.3
bison: upgrade 3.7.3 -> 3.7.4
python3-setuptools-scm: fix upstream version check
cantarell-fonts: update 0.0.25 -> 0.201
meta/lib/oe/reproducible.py: gitsm:// works just as fine as git:// for timestamps
llvm: fix reproducibility
ruby: fix reproducibility
webkitgtk: fix reproducibility
ffmpeg: fix reproducibility
piglit: fix reproducibility
serf: do not install the static library
llvm: sort the lists in generated source reproducibibly
kea: fix reproducibility
poky.conf: do not write current date into distro version, use git hash instead
Andrej Valek (1):
kernel-dummy: fix executing unexpected tasks
Anuj Mittal (1):
releases.rst: add gatesgarth to current releases
Brett Warren (1):
libffi: add patch to revert clang VFP workaround
Chandana kalluri (1):
populate_sdk_ext: use SDK_CUSTOM_TEPLATECONF variable to enable custom templateconf.cfg
Changqing Li (1):
buildtools-tarball: add wic dependency into extended buildtools
Diego Sueiro (2):
modutils-initscripts: Fix modules.dep creation when USE_DEPMOD="0"
initscripts: Change execution order between checkroot and modutils
Dmitry Baryshkov (2):
linux-firmware: upgrade 20201022 -> 20201118
linux-firmware: package ath11k firmware
Fabio Berton (1):
mesa: Update 20.2.1 -> 20.2.4
Gratian Crisan (1):
kernel-module-split.bbclass: fix kernel modules getting marked as CONFFILES
Jack Mitchell (3):
Revert "connman: set service to conflict with systemd-networkd"
systemd-conf: add PACKAGECONFIG to enable/disable auto ethernet DHCP
systemd-conf: match ethernet interfaces by type rather than globbing
Joshua Watt (2):
bitbake: hashserv: client: Fix AF_UNIX path length limits
bitbake: hashserv: Fix broken AF_UNIX path length limit
Kai Kang (2):
systemd-systemctl-native: capable to call without argument
systemd.bbclass: update command to check systemctl available
Kevin Hao (1):
tune-octeontx2.inc: Add tune for Marvell OCTEON TX2 core
Li Wang (2):
qemu: CVE-2020-29129 CVE-2020-29130
qemu: CVE-2020-25624
Luca Boccassi (1):
dbus: move messagebus user to dbus-common package
Michael Halstead (1):
releases: conf: add link to 3.1.4, update to include 3.1.4
Nicolas Dechesne (19):
sphinx: add .vscode in .gitignore
{dev,kernel,sdk}-manual: replace hardcoded release version with &DISTRO;
sphinx: replace bitbake labels with references to corresponding title
brief-yoctoprojectqs: replace labels with references to section title
dev-manual: replace labels with references to section title
ref-manual: replace labels with references to section title
sdk-manual: replace labels with references to section title
overview-manual: remove unused labels
dev-manual: remove unused labels
sphinx: rename top level document in each manual
sphinx: use absolute paths for :doc: references
test-manual: remove 'test-manual' from filenames
toaster-manual: remove 'toaster-manual' from filenames
dev-manual: remove 'dev-manual' from filenames
kernel-dev: remove 'kernel-dev' from filenames
profile-manual: remove 'profile-manual' from filenames
overview-manual: remove 'overview-manual' from filenames
sdk-manual: remove 'sdk' from filenames
ref-manual: remove 'ref' from filenames
Paul Barker (5):
documentation: Simplify yocto_wiki links
documentation: Simplify yocto_git links
ref-manual: Simplify oe_git links
poky.conf: Add opensuseleap-15.2 and fedora-33 to tested distros
poky.conf: Drop fedora-30 from tested distros
Peter Kjellerstedt (2):
pseudo: Simplify pseudo_client_ignore_path_chroot()
bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS
Richard Purdie (8):
lz4: Use the new branch naming from upstream
Revert "bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS"
build-appliance-image: Update to master head revision
bitbake: Revert "fetch2: use relative symlinks for anything pulled from PREMIRRORS"
build-appliance-image: Update to master head revision
metadata_scm: Fix signature handling of METADATA_REVISION and METADATA_BRANCH
poky: Set SDK_VERSION explicitly
build-appliance-image: Update to master head revision
Ross Burton (9):
oeqa/devtool: use Yocto mirror for pv-1.5.3 tarball
image_types: remove obsolete tar comment
image_types: sort tarball file listings
package_manager/ipk: neaten OPKGLIBDIR logic
ldconfig-native: don't write auxiliary cache
package_manager/ipk: improve remove_packaging_data
oeqa/selftest/containerimage: update for improved cleanup
coreutils: add SUSE-specific issues to CVE whitelist
bitbake: msg: use safe YAML loader
Sinan Kaya (1):
poky-tiny: enable section removal
Tomasz Dziendzielski (1):
pseudo: Update to print PSEUDO_LOGFILE in abort message on path mismatches
sangeeta jain (1):
meta/lib/oeqa/manual/oe-core.json: Update test_bitbake_devshell
zangrc (3):
libinput: upgrade 1.16.3 -> 1.16.4
lighttpd: upgrade 1.4.55 -> 1.4.56
sysstat: upgrade 12.4.0 -> 12.4.1
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I65f2f1c9d44433f3e62609240012c42256679b51
Diffstat (limited to 'poky/documentation/overview-manual')
-rw-r--r-- | poky/documentation/overview-manual/concepts.rst (renamed from poky/documentation/overview-manual/overview-manual-concepts.rst) | 109 | ||||
-rw-r--r-- | poky/documentation/overview-manual/development-environment.rst (renamed from poky/documentation/overview-manual/overview-manual-development-environment.rst) | 47 | ||||
-rw-r--r-- | poky/documentation/overview-manual/index.rst (renamed from poky/documentation/overview-manual/overview-manual.rst) | 8 | ||||
-rw-r--r-- | poky/documentation/overview-manual/intro.rst (renamed from poky/documentation/overview-manual/overview-manual-intro.rst) | 16 | ||||
-rw-r--r-- | poky/documentation/overview-manual/yp-intro.rst (renamed from poky/documentation/overview-manual/overview-manual-yp-intro.rst) | 76 |
5 files changed, 90 insertions, 166 deletions
diff --git a/poky/documentation/overview-manual/overview-manual-concepts.rst b/poky/documentation/overview-manual/concepts.rst index 736fd9591..8fbbabbac 100644 --- a/poky/documentation/overview-manual/overview-manual-concepts.rst +++ b/poky/documentation/overview-manual/concepts.rst @@ -34,17 +34,15 @@ itself is of various types: BitBake knows how to combine multiple data sources together and refers to each data source as a layer. For information on layers, see the -":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`" +":ref:`dev-manual/common-tasks:understanding and creating layers`" section of the Yocto Project Development Tasks Manual. Following are some brief details on these core components. For additional information on how these components interact during a build, see the -":ref:`overview-manual/overview-manual-concepts:openembedded build system concepts`" +":ref:`overview-manual/concepts:openembedded build system concepts`" section. -.. _usingpoky-components-bitbake: - BitBake ------- @@ -78,7 +76,7 @@ versions of ``matchbox-desktop`` might exist. BitBake chooses the one selected by the distribution configuration. You can get more details about how BitBake chooses between different target versions and providers in the -":ref:`Preferences <bitbake:bb-bitbake-preferences>`" section +":ref:`Preferences <bitbake:bitbake-user-manual/bitbake-user-manual-execution:preferences>`" section of the BitBake User Manual. BitBake also tries to execute any dependent tasks first. So for example, @@ -92,8 +90,6 @@ occurs, the target that failed and those that depend on it cannot be remade. However, when you use this option other dependencies can still be processed. -.. _overview-components-recipes: - Recipes ------- @@ -109,8 +105,6 @@ the word "package" is used for the packaged output from the OpenEmbedded build system (i.e. ``.ipk`` or ``.deb`` files), this document avoids using the term "package" when referring to recipes. -.. _overview-components-classes: - Classes ------- @@ -118,12 +112,10 @@ Class files (``.bbclass``) contain information that is useful to share between recipes files. An example is the :ref:`autotools <ref-classes-autotools>` class, which contains common settings for any application that Autotools uses. -The ":ref:`ref-manual/ref-classes:Classes`" chapter in the +The ":ref:`ref-manual/classes:Classes`" chapter in the Yocto Project Reference Manual provides details about classes and how to use them. -.. _overview-components-configurations: - Configurations -------------- @@ -135,8 +127,6 @@ common configuration options, and user configuration options in ``conf/local.conf``, which is found in the :term:`Build Directory`. -.. _overview-layers: - Layers ====== @@ -163,11 +153,9 @@ Conforming to a known structure allows BitBake to make assumptions during builds on where to find types of metadata. You can find procedures and learn about tools (i.e. ``bitbake-layers``) for creating layers suitable for the Yocto Project in the -":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`" +":ref:`dev-manual/common-tasks:understanding and creating layers`" section of the Yocto Project Development Tasks Manual. -.. _openembedded-build-system-build-concepts: - OpenEmbedded Build System Concepts ================================== @@ -285,7 +273,7 @@ The ``local.conf`` file provides many basic variables that define a build environment. Here is a list of a few. To see the default configurations in a ``local.conf`` file created by the build environment script, see the -:yocto_git:`local.conf.sample </cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample>` +:yocto_git:`local.conf.sample </poky/tree/meta-poky/conf/local.conf.sample>` in the ``meta-poky`` layer: - *Target Machine Selection:* Controlled by the @@ -329,7 +317,7 @@ during the build. By default, the layers listed in this file include layers minimally needed by the build system. However, you must manually add any custom layers you have created. You can find more information on working with the ``bblayers.conf`` file in the -":ref:`dev-manual/dev-manual-common-tasks:enabling your layer`" +":ref:`dev-manual/common-tasks:enabling your layer`" section in the Yocto Project Development Tasks Manual. The files ``site.conf`` and ``auto.conf`` are not created by the @@ -405,17 +393,17 @@ figure <#general-workflow-figure>`__: configurations. This type of information is specific to a particular target architecture. A good example of a BSP layer from the `Poky Reference Distribution <#gs-reference-distribution-poky>`__ is the - :yocto_git:`meta-yocto-bsp </cgit/cgit.cgi/poky/tree/meta-yocto-bsp>` + :yocto_git:`meta-yocto-bsp </poky/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 </cgit/cgit.cgi/poky/tree/meta-poky>` + :yocto_git:`meta-poky </poky/tree/meta-poky>` layer. Within the distro layer is a ``conf/distro`` directory that contains distro configuration files (e.g. - :yocto_git:`poky.conf </cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky.conf>` + :yocto_git:`poky.conf </poky/tree/meta-poky/conf/distro/poky.conf>` that contain many policy configurations for the Poky distribution. The following figure shows an expanded representation of these three @@ -430,7 +418,7 @@ a ``README`` file as good practice and especially if the layer is to be distributed, a configuration directory, and recipe directories. You can learn about the general structure for layers used with the Yocto Project in the -":ref:`dev-manual/dev-manual-common-tasks:creating your own layer`" +":ref:`dev-manual/common-tasks:creating your own layer`" section in the Yocto Project Development Tasks Manual. For a general discussion on layers and the many layers from which you can draw, see the @@ -439,9 +427,8 @@ Model <#the-yocto-project-layer-model>`__" sections both earlier in this manual. If you explored the previous links, you discovered some areas where many -layers that work with the Yocto Project exist. The `Source -Repositories <http://git.yoctoproject.org/>`__ also shows layers -categorized under "Yocto Metadata Layers." +layers that work with the Yocto Project exist. The :yocto_git:`Source +Repositories <>` also shows layers categorized under "Yocto Metadata Layers." .. note:: @@ -469,7 +456,7 @@ typically find in the distribution layer: can be shared among recipes in the distribution. When your recipes inherit a class, they take on the settings and functions for that class. You can read more about class files in the - ":ref:`ref-manual/ref-classes:Classes`" chapter of the Yocto + ":ref:`ref-manual/classes:Classes`" chapter of the Yocto Reference Manual. - *conf:* This area holds configuration files for the layer @@ -494,7 +481,7 @@ The BSP Layer provides machine configurations that target specific hardware. Everything in this layer is specific to the machine for which you are building the image or the SDK. A common structure or form is defined for BSP layers. You can learn more about this structure in the -:doc:`../bsp-guide/bsp-guide`. +:doc:`/bsp-guide/index`. .. note:: @@ -527,8 +514,6 @@ their respective layers. This layer contains any recipes, append files, and patches, that your project needs. -.. _sources-dev-environment: - Sources ------- @@ -601,13 +586,11 @@ class to include that local project. You use either the ``local.conf`` or a recipe's append file to override or set the recipe to point to the local directory on your disk to pull in the whole source tree. -.. _scms: - Source Control Managers (Optional) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Another place from which the build system can get source files is with -:ref:`fetchers <bitbake:bb-fetchers>` employing various Source +:ref:`fetchers <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` employing various Source Control Managers (SCMs) such as Git or Subversion. In such cases, a repository is cloned or checked out. The :ref:`ref-tasks-fetch` task inside @@ -644,8 +627,6 @@ Regular mirrors can be any site across the Internet that is used as an alternative location for source code should the primary site not be functioning for some reason or another. -.. _package-feeds-dev-environment: - Package Feeds ------------- @@ -709,8 +690,6 @@ qemux86 exist. Packages for the i586 architecture are placed in ``build/tmp/deploy/ipk/i586``, while packages for the qemux86 architecture are placed in ``build/tmp/deploy/ipk/qemux86``. -.. _bitbake-dev-environment: - BitBake Tool ------------ @@ -727,8 +706,6 @@ those areas. BitBake User Manual for reference material on BitBake. -.. _source-fetching-dev-environment: - Source Fetching ~~~~~~~~~~~~~~~ @@ -819,8 +796,6 @@ Build Directory's hierarchy: what the OpenEmbedded build system is using as a build target (e.g. general architecture, a build host, an SDK, or a specific machine). -.. _patching-dev-environment: - Patching ~~~~~~~~ @@ -852,17 +827,15 @@ For more information on how the source directories are created, see the "`Source Fetching <#source-fetching-dev-environment>`__" section. For more information on how to create patches and how the build system processes patches, see the -":ref:`dev-manual/dev-manual-common-tasks:patching code`" +":ref:`dev-manual/common-tasks:patching code`" section in the Yocto Project Development Tasks Manual. You can also see the -":ref:`sdk-manual/sdk-extensible:use \`\`devtool modify\`\` to modify the source of an existing component`" +":ref:`sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component`" section in the Yocto Project Application Development and the Extensible Software Development Kit (SDK) manual and the -":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`" +":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`" section in the Yocto Project Linux Kernel Development Manual. -.. _configuration-compilation-and-staging-dev-environment: - Configuration, Compilation, and Staging ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -905,7 +878,7 @@ This step in the build process consists of the following tasks: variables. For information on how this variable works within that class, see the :ref:`autotools <ref-classes-autotools>` class - :yocto_git:`here </cgit/cgit.cgi/poky/tree/meta/classes/autotools.bbclass>`. + :yocto_git:`here </poky/tree/meta/classes/autotools.bbclass>`. - *do_compile*: Once a configuration task has been satisfied, BitBake compiles the source using the @@ -922,8 +895,6 @@ This step in the build process consists of the following tasks: variable. Packaging occurs later using files from this holding directory. -.. _package-splitting-dev-environment: - Package Splitting ~~~~~~~~~~~~~~~~~ @@ -985,7 +956,7 @@ The :term:`FILES` variable defines the files that go into each package in :term:`PACKAGES`. If you want details on how this is accomplished, you can look at -:yocto_git:`package.bbclass </cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass>`. +:yocto_git:`package.bbclass </poky/tree/meta/classes/package.bbclass>`. Depending on the type of packages being created (RPM, DEB, or IPK), the :ref:`do_package_write_* <ref-tasks-package_write_deb>` @@ -1004,8 +975,6 @@ that part of the build process. functionality is highly distribution-specific and thus is not provided out of the box. -.. _image-generation-dev-environment: - Image Generation ~~~~~~~~~~~~~~~~ @@ -1060,7 +1029,7 @@ stage of package installation, post installation scripts that are part of the packages are run. Any scripts that fail to run on the build host are run on the target when the target system is first booted. If you are using a -:ref:`read-only root filesystem <dev-manual/dev-manual-common-tasks:creating a read-only root filesystem>`, +:ref:`read-only root filesystem <dev-manual/common-tasks:creating a read-only root filesystem>`, all the post installation scripts must succeed on the build host during the package installation phase since the root filesystem on the target is read-only. @@ -1127,8 +1096,6 @@ build system has created the final image output files. Pseudo. Running under Pseudo ensures that the files in the root filesystem have correct ownership. -.. _sdk-generation-dev-environment: - SDK Generation ~~~~~~~~~~~~~~ @@ -1142,10 +1109,10 @@ the extensible SDK (eSDK): .. note:: For more information on the cross-development toolchain generation, - see the ":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`" + see the ":ref:`overview-manual/concepts:cross-development toolchain generation`" section. For information on advantages gained when building a cross-development toolchain using the do_populate_sdk task, see the - ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`" section in + ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" section in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual. @@ -1225,7 +1192,7 @@ varflag. If some other task depends on such a task, then that task will also always be considered out of date, which might not be what you want. For details on how to view information about a task's signature, see the -":ref:`dev-manual/dev-manual-common-tasks:viewing task variable dependencies`" +":ref:`dev-manual/common-tasks:viewing task variable dependencies`" section in the Yocto Project Development Tasks Manual. Setscene Tasks and Shared State @@ -1303,8 +1270,6 @@ variable is the function that determines whether a given dependency needs to be followed, and whether for any given relationship the function needs to be passed. The function returns a True or False value. -.. _images-dev-environment: - Images ------ @@ -1320,7 +1285,7 @@ this output: .. note:: For a list of example images that the Yocto Project provides, see the - ":doc:`../ref-manual/ref-images`" chapter in the Yocto Project Reference + ":doc:`/ref-manual/images`" chapter in the Yocto Project Reference Manual. The build process writes images out to the :term:`Build Directory` @@ -1363,8 +1328,6 @@ current configuration. These links might be useful for external scripts that need to obtain the latest version of each file. -.. _sdk-dev-environment: - Application Development SDK --------------------------- @@ -1403,7 +1366,7 @@ can initialize the environment before using the tools. section. - For information on setting up a cross-development environment, see - the :doc:`../sdk-manual/sdk-manual` manual. + the :doc:`/sdk-manual/index` manual. All the output files for an SDK are written to the ``deploy/sdk`` folder inside the :term:`Build Directory` as @@ -1480,10 +1443,10 @@ Cross-Development Toolchain Generation ====================================== The Yocto Project does most of the work for you when it comes to -creating :ref:`sdk-manual/sdk-intro:the cross-development toolchain`. This +creating :ref:`sdk-manual/intro:the cross-development toolchain`. This section provides some technical background on how cross-development toolchains are created and used. For more information on toolchains, you -can also see the :doc:`../sdk-manual/sdk-manual` manual. +can also see the :doc:`/sdk-manual/index` manual. In the Yocto Project development environment, cross-development toolchains are used to build images and applications that run on the @@ -1610,7 +1573,7 @@ Here is the bootstrap process for the relocatable toolchain: For information on advantages gained when building a cross-development toolchain installer, see the - ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`" appendix + ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" appendix in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual. @@ -1663,22 +1626,20 @@ them if they are deemed to be valid. the shared state packages. Consequently, considerations exist that affect maintaining shared state feeds. For information on how the build system works with packages and can track incrementing ``PR`` - information, see the ":ref:`dev-manual/dev-manual-common-tasks:automatically incrementing a package version number`" + information, see the ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`" section in the Yocto Project Development Tasks Manual. - The code in the build system that supports incremental builds is not simple code. For techniques that help you work around issues related to shared state code, see the - ":ref:`dev-manual/dev-manual-common-tasks:viewing metadata used to create the input signature of a shared state task`" + ":ref:`dev-manual/common-tasks:viewing metadata used to create the input signature of a shared state task`" and - ":ref:`dev-manual/dev-manual-common-tasks:invalidating shared state to force a task to run`" + ":ref:`dev-manual/common-tasks:invalidating shared state to force a task to run`" sections both in the Yocto Project Development Tasks Manual. The rest of this section goes into detail about the overall incremental build architecture, the checksums (signatures), and shared state. -.. _concepts-overall-architecture: - Overall Architecture -------------------- @@ -1697,8 +1658,6 @@ specific tasks. This methodology does not scale well and does not allow users to easily add new tasks in layers or as external recipes without touching the packaged-staging core. -.. _overview-checksums: - Checksums (Signatures) ---------------------- @@ -1949,7 +1908,7 @@ The following list explains the previous example: extra metadata to the `stamp file <#stamp-files-and-the-rerunning-of-tasks>`__. In this case, the metadata makes the task specific to a machine's architecture. See - ":ref:`bitbake:ref-bitbake-tasklist`" + ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:the task list`" section in the BitBake User Manual for more information on the ``stamp-extra-info`` flag. diff --git a/poky/documentation/overview-manual/overview-manual-development-environment.rst b/poky/documentation/overview-manual/development-environment.rst index 4bedd6df6..9a2997d9f 100644 --- a/poky/documentation/overview-manual/overview-manual-development-environment.rst +++ b/poky/documentation/overview-manual/development-environment.rst @@ -45,8 +45,6 @@ also find helpful information on how to participate in the Linux Community `here <https://www.kernel.org/doc/html/latest/process/index.html>`__. -.. _gs-the-development-host: - The Development Host ==================== @@ -68,7 +66,7 @@ to set up a CROPS machine, you effectively have access to a shell environment that is similar to what you see when using a Linux-based development host. For the steps needed to set up a system using CROPS, see the -":ref:`dev-manual/dev-manual-start:setting up to use cross platforms (crops)`" +":ref:`dev-manual/start:setting up to use cross platforms (crops)`" section in the Yocto Project Development Tasks Manual. @@ -79,7 +77,7 @@ distribution on the system is one that supports the Yocto Project. You also need to be sure that the correct set of host packages are installed that allow development using the Yocto Project. For the steps needed to set up a development host that runs Linux, see the -":ref:`dev-manual/dev-manual-start:setting up a native linux host`" +":ref:`dev-manual/start:setting up a native linux host`" section in the Yocto Project Development Tasks Manual. Once your development host is set up to use the Yocto Project, several @@ -96,7 +94,7 @@ methods exist for you to do work in the Yocto Project environment: through your Linux distribution and the Yocto Project. For a general flow of the build procedures, see the - ":ref:`dev-manual/dev-manual-common-tasks:building a simple image`" + ":ref:`dev-manual/common-tasks:building a simple image`" section in the Yocto Project Development Tasks Manual. - *Board Support Package (BSP) Development:* Development of BSPs @@ -105,7 +103,7 @@ methods exist for you to do work in the Yocto Project environment: hardware. To development BSPs, you need to take some additional steps beyond what was described in setting up a development host. - The :doc:`../bsp-guide/bsp-guide` provides BSP-related development + The :doc:`/bsp-guide/index` provides BSP-related development information. For specifics on development host preparation, see the ":ref:`bsp-guide/bsp:preparing your build host to work with bsp layers`" section in the Yocto Project Board Support Package (BSP) Developer's @@ -116,10 +114,10 @@ methods exist for you to do work in the Yocto Project environment: using ``devtool`` makes kernel development quicker by reducing iteration cycle times. - The :doc:`../kernel-dev/kernel-dev` provides kernel-related + The :doc:`/kernel-dev/index` provides kernel-related development information. For specifics on development host preparation, see the - ":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`" + ":ref:`kernel-dev/common:preparing the build host to work on the kernel`" section in the Yocto Project Linux Kernel Development Manual. - *Using Toaster:* The other Yocto Project development method that @@ -132,9 +130,7 @@ methods exist for you to do work in the Yocto Project environment: For steps that show you how to set up your development host to use Toaster and on how to use Toaster in general, see the - :doc:`../toaster-manual/toaster-manual`. - -.. _yocto-project-repositories: + :doc:`/toaster-manual/index`. Yocto Project Source Repositories ================================= @@ -182,7 +178,7 @@ development: :align: center For steps on how to view and access these upstream Git repositories, - see the ":ref:`dev-manual/dev-manual-start:accessing source repositories`" + see the ":ref:`dev-manual/start:accessing source repositories`" Section in the Yocto Project Development Tasks Manual. - :yocto_dl:`Index of /releases: </releases>` This is an index @@ -196,7 +192,7 @@ development: :align: center For steps on how to view and access these files, see the - ":ref:`dev-manual/dev-manual-start:accessing index of releases`" + ":ref:`dev-manual/start:accessing index of releases`" section in the Yocto Project Development Tasks Manual. - *"DOWNLOADS" page for the* :yocto_home:`Yocto Project Website <>` *:* @@ -211,11 +207,9 @@ development: :align: center For steps on how to use the "DOWNLOADS" page, see the - ":ref:`dev-manual/dev-manual-start:using the downloads page`" + ":ref:`dev-manual/start:using the downloads page`" section in the Yocto Project Development Tasks Manual. -.. _gs-git-workflows-and-the-yocto-project: - Git Workflows and the Yocto Project =================================== @@ -248,7 +242,7 @@ and so forth. For information on finding out who is responsible for (maintains) a particular area of code in the Yocto Project, see the - ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`" + ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" section of the Yocto Project Development Tasks Manual. The Yocto Project ``poky`` Git repository also has an upstream @@ -280,7 +274,7 @@ push them into the "contrib" area and subsequently request that the maintainer include them into an upstream branch. This process is called "submitting a patch" or "submitting a change." For information on submitting patches and changes, see the -":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`" +":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" section in the Yocto Project Development Tasks Manual. In summary, a single point of entry exists for changes into a "master" @@ -347,7 +341,7 @@ Book <http://book.git-scm.com>`__. the ``scripts`` folder of the :term:`Source Directory`. For information on how to use these scripts, see the - ":ref:`dev-manual/dev-manual-common-tasks:using scripts to push a change upstream and request a pull`" + ":ref:`dev-manual/common-tasks:using scripts to push a change upstream and request a pull`" section in the Yocto Project Development Tasks Manual. - *Patch Workflow:* This workflow allows you to notify the maintainer @@ -356,7 +350,7 @@ Book <http://book.git-scm.com>`__. this type of change, you format the patch and then send the email using the Git commands ``git format-patch`` and ``git send-email``. For information on how to use these scripts, see the - ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`" + ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" section in the Yocto Project Development Tasks Manual. Git @@ -382,7 +376,7 @@ commands. page, see http://git-scm.com/download. - For information beyond the introductory nature in this section, - see the ":ref:`dev-manual/dev-manual-start:locating yocto project source files`" + see the ":ref:`dev-manual/start:locating yocto project source files`" section in the Yocto Project Development Tasks Manual. Repositories, Tags, and Branches @@ -414,7 +408,7 @@ You can create a local copy of any repository by "cloning" it with the 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/dev-manual-start:locating yocto project source files`" +":ref:`dev-manual/start:locating yocto project source files`" section in the Yocto Project Development Tasks Manual. It is important to understand that Git tracks content change and not @@ -422,7 +416,7 @@ files. Git uses "branches" to organize different development efforts. For example, the ``poky`` repository has several branches that include the current "&DISTRO_NAME_NO_CAP;" branch, the "master" branch, and many branches for past Yocto Project releases. You can see all the branches -by going to https://git.yoctoproject.org/cgit.cgi/poky/ and clicking on the +by going to :yocto_git:`/poky/` and clicking on the ``[...]`` link beneath the "Branch" heading. Each of these branches represents a specific area of development. The @@ -467,9 +461,8 @@ Yocto Project Release. Git uses "tags" to mark specific changes in a repository branch structure. Typically, a tag is used to mark a special point such as the final change (or commit) before a project is released. You can see the -tags used with the ``poky`` Git repository by going to -https://git.yoctoproject.org/cgit.cgi/poky/ and clicking on the ``[...]`` link -beneath the "Tag" heading. +tags used with the ``poky`` Git repository by going to :yocto_git:`/poky/` +and clicking on the ``[...]`` link beneath the "Tag" heading. Some key tags for the ``poky`` repository are ``jethro-14.0.3``, ``morty-16.0.1``, ``pyro-17.0.0``, and @@ -668,5 +661,5 @@ Project uses in the ``meta/files/common-licenses`` directory in your For information that can help you maintain compliance with various open source licensing during the lifecycle of a product created using the Yocto Project, see the -":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`" +":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`" section in the Yocto Project Development Tasks Manual. diff --git a/poky/documentation/overview-manual/overview-manual.rst b/poky/documentation/overview-manual/index.rst index f20b20e32..123aed9b8 100644 --- a/poky/documentation/overview-manual/overview-manual.rst +++ b/poky/documentation/overview-manual/index.rst @@ -10,10 +10,10 @@ Yocto Project Overview and Concepts Manual :caption: Table of Contents :numbered: - overview-manual-intro - overview-manual-yp-intro - overview-manual-development-environment - overview-manual-concepts + intro + yp-intro + development-environment + concepts history .. include:: /boilerplate.rst diff --git a/poky/documentation/overview-manual/overview-manual-intro.rst b/poky/documentation/overview-manual/intro.rst index 8885eb89f..bd247dd45 100644 --- a/poky/documentation/overview-manual/overview-manual-intro.rst +++ b/poky/documentation/overview-manual/intro.rst @@ -4,8 +4,6 @@ The Yocto Project Overview and Concepts Manual ********************************************** -.. _overview-manual-welcome: - Welcome ======= @@ -30,7 +28,7 @@ The following list describes what you can get from this manual: Yocto Project source repositories, workflows using Git and the Yocto Project, a Git primer, and information about licensing. -- :doc:`overview-manual-concepts` *:* This +- :doc:`/overview-manual/concepts` *:* This chapter presents various concepts regarding the Yocto Project. You can find conceptual information about components, development, cross-toolchains, and so forth. @@ -39,17 +37,17 @@ This manual does not give you the following: - *Step-by-step Instructions for Development Tasks:* Instructional procedures reside in other manuals within the Yocto Project - documentation set. For example, the :doc:`../dev-manual/dev-manual` + documentation set. For example, the :doc:`/dev-manual/index` provides examples on how to perform various development tasks. As another example, the - :doc:`../sdk-manual/sdk-manual` manual contains detailed + :doc:`/sdk-manual/index` manual contains detailed instructions on how to install an SDK, which is used to develop applications for target hardware. - *Reference Material:* This type of material resides in an appropriate reference manual. For example, system variables are documented in the - :doc:`../ref-manual/ref-manual`. As another - example, the :doc:`../bsp-guide/bsp-guide` contains reference information on + :doc:`/ref-manual/index`. As another + example, the :doc:`/bsp-guide/index` contains reference information on BSPs. - *Detailed Public Information Not Specific to the Yocto Project:* For @@ -57,8 +55,6 @@ This manual does not give you the following: Manager Git is better covered with Internet searches and official Git Documentation than through the Yocto Project documentation. -.. _overview-manual-other-information: - Other Information ================= @@ -67,7 +63,7 @@ supplemental information is recommended for full comprehension. For additional introductory information on the Yocto Project, see the :yocto_home:`Yocto Project Website <>`. If you want to build an image with no knowledge of Yocto Project as a way of quickly testing it out, -see the :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document. +see the :doc:`/brief-yoctoprojectqs/index` document. For a comprehensive list of links and other documentation, see the ":ref:`Links and Related Documentation <resources-links-and-related-documentation>`" diff --git a/poky/documentation/overview-manual/overview-manual-yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst index 9073582ac..66a88c952 100644 --- a/poky/documentation/overview-manual/overview-manual-yp-intro.rst +++ b/poky/documentation/overview-manual/yp-intro.rst @@ -35,8 +35,6 @@ by Drew Moseley and in this short introductory The remainder of this section overviews advantages and challenges tied to the Yocto Project. -.. _gs-features: - Features -------- @@ -113,7 +111,7 @@ Project: development. - *Releases According to a Strict Schedule:* Major releases occur on a - :doc:`six-month cycle <../ref-manual/ref-release-process>` + :doc:`six-month cycle </ref-manual/release-process>` predictably in October and April. The most recent two releases support point releases to address common vulnerabilities and exposures. This predictability is crucial for projects based on the @@ -132,12 +130,10 @@ Project: arbitrarily include packages. - *License Manifest:* The Yocto Project provides a :ref:`license - manifest <dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle>` + manifest <dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle>` for review by people who need to track the use of open source licenses (e.g. legal teams). -.. _gs-challenges: - Challenges ---------- @@ -232,7 +228,7 @@ your Metadata, the easier it is to cope with future changes. - Layers support the inclusion of technologies, hardware components, and software components. The :ref:`Yocto Project - Compatible <dev-manual/dev-manual-common-tasks:making sure your layer is compatible with yocto project>` + Compatible <dev-manual/common-tasks:making sure your layer is compatible with yocto project>` designation provides a minimum level of standardization that contributes to a strong ecosystem. "YP Compatible" is applied to appropriate products and software components such as BSPs, other @@ -255,7 +251,7 @@ accomplish this through a recipe that is a BitBake append .. note:: For general information on BSP layer structure, see the - :doc:`../bsp-guide/bsp-guide` + :doc:`/bsp-guide/index` . The :term:`Source Directory` @@ -271,15 +267,14 @@ with the string ``meta-``. , but it is a commonly accepted standard in the Yocto Project community. -For example, if you were to examine the `tree -view <https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/>`__ of the -``poky`` repository, you will see several layers: ``meta``, +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 layer. For procedures on how to create layers, see the -":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`" +":ref:`dev-manual/common-tasks:understanding and creating layers`" section in the Yocto Project Development Tasks Manual. Components and Tools @@ -296,8 +291,6 @@ components and tools are downloaded separately. This section provides brief overviews of the components and tools associated with the Yocto Project. -.. _gs-development-tools: - Development Tools ----------------- @@ -334,7 +327,7 @@ applications using the Yocto Project: You can read about the ``devtool`` workflow in the Yocto Project Application Development and Extensible Software Development Kit (eSDK) Manual in the - ":ref:`sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow`" + ":ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`" section. - *Extensible Software Development Kit (eSDK):* The eSDK provides a @@ -346,14 +339,12 @@ applications using the Yocto Project: experience supplemented with the powerful set of ``devtool`` commands tailored for the Yocto Project environment. - For information on the eSDK, see the :doc:`../sdk-manual/sdk-manual` Manual. + For information on the eSDK, see the :doc:`/sdk-manual/index` Manual. - *Toaster:* Toaster is a web interface to the Yocto Project OpenEmbedded build system. Toaster allows you to configure, run, and view information about builds. For information on Toaster, see the - :doc:`../toaster-manual/toaster-manual`. - -.. _gs-production-tools: + :doc:`/toaster-manual/index`. Production Tools ---------------- @@ -366,7 +357,7 @@ activities using the Yocto Project: (BitBake and OE-Core) automatically generates upgrades for recipes that are based on new versions of the recipes published upstream. See - :ref:`dev-manual/dev-manual-common-tasks:using the auto upgrade helper (auh)` + :ref:`dev-manual/common-tasks:using the auto upgrade helper (auh)` for how to set it up. - *Recipe Reporting System:* The Recipe Reporting System tracks recipe @@ -401,7 +392,7 @@ activities using the Yocto Project: benefit of the development community. You can learn more about the AutoBuilder used by the Yocto Project - Autobuilder :doc:`here <../test-manual/test-manual-understand-autobuilder>`. + Autobuilder :doc:`here </test-manual/understand-autobuilder>`. - *Cross-Prelink:* Prelinking is the process of pre-computing the load addresses and link tables generated by the dynamic linker as compared @@ -450,8 +441,6 @@ activities using the Yocto Project: You can read more about Pseudo in the "`Fakeroot and Pseudo <#fakeroot-and-pseudo>`__" section. -.. _gs-openembedded-build-system: - Open-Embedded Build System Components ------------------------------------- @@ -477,7 +466,7 @@ The following list consists of components associated with the OpenEmbedded-derived systems, which includes the Yocto Project. The Yocto Project and the OpenEmbedded Project both maintain the OpenEmbedded-Core. You can find the OE-Core metadata in the Yocto - Project :yocto_git:`Source Repositories </cgit/cgit.cgi/poky/tree/meta>`. + Project :yocto_git:`Source Repositories </poky/tree/meta>`. Historically, the Yocto Project integrated the OE-Core metadata throughout the Yocto Project source repository reference system @@ -496,8 +485,6 @@ The following list consists of components associated with the components such as BitBake, OE-Core, script "glue", and documentation for its build system. -.. _gs-reference-distribution-poky: - Reference Distribution (Poky) ----------------------------- @@ -520,8 +507,6 @@ To use the Yocto Project tools and components, you can download You can read more about Poky in the "`Reference Embedded Distribution (Poky) <#reference-embedded-distribution>`__" section. -.. _gs-packages-for-finished-targets: - Packages for Finished Targets ----------------------------- @@ -560,8 +545,6 @@ targets: You can find the opkg source in the Yocto Project :yocto_git:`Source Repositories <>`. -.. _gs-archived-components: - Archived Components ------------------- @@ -588,8 +571,6 @@ Linux. using the Yocto Project on a system not native to Linux is with `CROPS <#gs-crops-overview>`__. -.. _gs-development-methods: - Development Methods =================== @@ -608,7 +589,7 @@ Project. .. note:: For additional detail about the Yocto Project development - environment, see the ":doc:`overview-manual-development-environment`" + environment, see the ":doc:`/overview-manual/development-environment`" chapter. - *Native Linux Host:* By far the best option for a Build Host. A @@ -620,7 +601,7 @@ Project. For information on how to set up a Build Host on a system running Linux as its native operating system, see the - ":ref:`dev-manual/dev-manual-start:setting up a native linux host`" + ":ref:`dev-manual/start:setting up a native linux host`" section in the Yocto Project Development Tasks Manual. - *CROss PlatformS (CROPS):* Typically, you use @@ -640,7 +621,7 @@ Project. system natively running Linux. For information on how to set up a Build Host with CROPS, see the - ":ref:`dev-manual/dev-manual-start:setting up to use cross platforms (crops)`" + ":ref:`dev-manual/start:setting up to use cross platforms (crops)`" section in the Yocto Project Development Tasks Manual. - *Windows Subsystem For Linux (WSLv2):* You may use Windows Subsystem @@ -657,7 +638,7 @@ Project. virtualization technology. For information on how to set up a Build Host with WSLv2, see the - ":ref:`dev-manual/dev-manual-start:setting up to use windows subsystem for linux (wslv2)`" + ":ref:`dev-manual/start:setting up to use windows subsystem for linux (wslv2)`" section in the Yocto Project Development Tasks Manual. - *Toaster:* Regardless of what your Build Host is running, you can use @@ -669,9 +650,7 @@ Project. configure and start builds on multiple remote build servers. For information about and how to use Toaster, see the - :doc:`../toaster-manual/toaster-manual`. - -.. _reference-embedded-distribution: + :doc:`/toaster-manual/index`. Reference Embedded Distribution (Poky) ====================================== @@ -691,13 +670,13 @@ 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 </cgit/cgit.cgi/poky/tree/>`. +: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/ref-structure:top-level core components`" + 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: @@ -741,7 +720,7 @@ 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/ref-release-process`" chapter in the +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 @@ -776,8 +755,6 @@ operators, see the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:appending and prepending (override style syntax)`" section in the BitBake User's Manual. -.. _openembedded-build-system-workflow: - The OpenEmbedded Build System Workflow ====================================== @@ -821,7 +798,7 @@ Some Basic Terms It helps to understand some basic fundamental terms when learning the Yocto Project. Although a list of terms exists in the ":doc:`Yocto Project -Terms <../ref-manual/ref-terms>`" section of the Yocto Project +Terms </ref-manual/terms>`" section of the Yocto Project Reference Manual, this section provides the definitions of some terms helpful for getting started: @@ -835,7 +812,7 @@ helpful for getting started: application developers. This eSDK allows developers to incorporate their library and programming changes back into the image to make their code available to other application developers. For information - on the eSDK, see the :doc:`../sdk-manual/sdk-manual` manual. + on the eSDK, see the :doc:`/sdk-manual/index` manual. - *Layer:* A collection of related recipes. Layers allow you to consolidate related metadata to customize your build. Layers also @@ -847,7 +824,7 @@ helpful for getting started: Project. For more detailed information on layers, see the - ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`" + ":ref:`dev-manual/common-tasks:understanding and creating layers`" section in the Yocto Project Development Tasks Manual. For a discussion specifically on BSP Layers, see the ":ref:`bsp-guide/bsp:bsp layers`" section in the Yocto @@ -892,8 +869,7 @@ helpful for getting started: set of recipes. You can see the Metadata in the ``meta`` directory of the Yocto - Project `Source - Repositories <http://git.yoctoproject.org/cgit/cgit.cgi>`__. + Project :yocto_git:`Source Repositories <>`. - *Packages:* In the context of the Yocto Project, this term refers to a recipe's packaged output produced by BitBake (i.e. a "baked @@ -903,7 +879,7 @@ helpful for getting started: It is worth noting that the term "package" can, in general, have subtle meanings. For example, the packages referred to in the - ":ref:`ref-manual/ref-system-requirements:required packages for the build host`" + ":ref:`ref-manual/system-requirements:required packages for the build host`" section in the Yocto Project Reference Manual are compiled binaries that, when installed, add functionality to your Linux distribution. |