diff options
Diffstat (limited to 'poky/documentation')
40 files changed, 561 insertions, 124 deletions
diff --git a/poky/documentation/Makefile b/poky/documentation/Makefile index 33bbca0bab..9fb6814c8f 100644 --- a/poky/documentation/Makefile +++ b/poky/documentation/Makefile @@ -47,9 +47,11 @@ clean: @rm -rf $(BUILDDIR) $(PNGs) $(PDFs) poky.yaml sphinx-static/switchers.js epub: $(PNGs) + $(SOURCEDIR)/set_versions.py @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) latexpdf: $(PDFs) + $(SOURCEDIR)/set_versions.py @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) all: html epub latexpdf diff --git a/poky/documentation/brief-yoctoprojectqs/index.rst b/poky/documentation/brief-yoctoprojectqs/index.rst index 12cab1db76..7179f25022 100644 --- a/poky/documentation/brief-yoctoprojectqs/index.rst +++ b/poky/documentation/brief-yoctoprojectqs/index.rst @@ -424,9 +424,9 @@ information including the website, wiki pages, and user manuals: development documentation, and access to a rich Yocto Project Development Community into which you can tap. -- **Video Seminar:** The `Introduction to the Yocto Project and Bitbake, Part 1 +- **Video Seminar:** The `Introduction to the Yocto Project and BitBake, Part 1 <https://youtu.be/yuE7my3KOpo>`__ and - `Introduction to the Yocto Project and Bitbake, Part 2 + `Introduction to the Yocto Project and BitBake, Part 2 <https://youtu.be/iZ05TTyzGHk>`__ videos offer a video seminar introducing you to the most important aspects of developing a custom embedded Linux distribution with the Yocto Project. diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst index 8ec7f2957e..280b160807 100644 --- a/poky/documentation/bsp-guide/bsp.rst +++ b/poky/documentation/bsp-guide/bsp.rst @@ -725,6 +725,7 @@ workflow. .. image:: figures/bsp-dev-flow.png :align: center + :width: 70% #. *Set up Your Host Development System to Support Development Using the Yocto Project*: See the ":ref:`dev-manual/start:preparing the build host`" diff --git a/poky/documentation/conf.py b/poky/documentation/conf.py index a7cdf415f8..baf550e3e3 100644 --- a/poky/documentation/conf.py +++ b/poky/documentation/conf.py @@ -19,7 +19,7 @@ try: import yaml except ImportError: sys.stderr.write("The Yocto Project Sphinx documentation requires PyYAML.\ - \nPlease make sure to install pyyaml python package.\n") + \nPlease make sure to install pyyaml Python package.\n") sys.exit(1) # current_version = "dev" @@ -108,7 +108,7 @@ extlinks = { 'oe_layer': ('https://layers.openembedded.org/layerindex/branch/master/layer%s', None), } -# Intersphinx config to use cross reference with Bitbake user manual +# Intersphinx config to use cross reference with BitBake user manual intersphinx_mapping = { 'bitbake': ('https://docs.yoctoproject.org/bitbake/' + bitbake_version, None) } @@ -129,7 +129,7 @@ try: } except ImportError: sys.stderr.write("The Sphinx sphinx_rtd_theme HTML theme was not found.\ - \nPlease make sure to install the sphinx_rtd_theme python package.\n") + \nPlease make sure to install the sphinx_rtd_theme Python package.\n") sys.exit(1) html_logo = 'sphinx-static/YoctoProject_Logo_RGB.jpg' diff --git a/poky/documentation/dev-manual/common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst index b228c75aab..ca6d594386 100644 --- a/poky/documentation/dev-manual/common-tasks.rst +++ b/poky/documentation/dev-manual/common-tasks.rst @@ -1125,6 +1125,7 @@ The remainder of the section provides details for the steps. .. image:: figures/recipe-workflow.png :align: center + :width: 50% Locate or Automatically Create a Base Recipe -------------------------------------------- @@ -3618,7 +3619,7 @@ Yocto Project Overview and Concepts Manual. The following figure and list overviews the build process: .. image:: figures/bitbake-build-flow.png - :align: center + :width: 100% 1. *Set up Your Host Development System to Support Development Using the Yocto Project*: See the ":doc:`start`" section for options on how to get a @@ -3736,6 +3737,7 @@ Follow these steps to set up and execute multiple configuration builds: .. image:: figures/multiconfig_files.png :align: center + :width: 50% The reason for this required file hierarchy is because the :term:`BBPATH` variable is not constructed until the layers are parsed. @@ -4826,7 +4828,7 @@ configuration would be as follows:: require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE:virtclass-multilib-lib32 = "x86" - IMAGE_INSTALL:append = "lib32-glib-2.0" + IMAGE_INSTALL:append = " lib32-glib-2.0" This example enables an additional library named ``lib32`` alongside the normal target packages. When combining these @@ -5392,7 +5394,7 @@ create the properly partitioned image. The ``wic`` command generates partitioned images from existing OpenEmbedded build artifacts. Image generation is driven by partitioning -commands contained in an Openembedded kickstart file (``.wks``) +commands contained in an OpenEmbedded kickstart file (``.wks``) specified either directly on the command line or as one of a selection of canned kickstart files as shown with the ``wic list images`` command in the @@ -5464,7 +5466,7 @@ system needs to meet the following requirements: - You need to have the build artifacts already available, which typically means that you must have already created an image using the - Openembedded build system (e.g. ``core-image-minimal``). While it + OpenEmbedded build system (e.g. ``core-image-minimal``). While it might seem redundant to generate an image in order to create an image using Wic, the current version of Wic requires the artifacts in the form generated by the OpenEmbedded build system. @@ -5479,7 +5481,9 @@ system needs to meet the following requirements: variable. - Include the name of the :ref:`wic kickstart file <openembedded-kickstart-wks-reference>` - as part of the :term:`WKS_FILE` variable + as part of the :term:`WKS_FILE` variable. If multiple candidate files can + be provided by different layers, specify all the possible names through the + :term:`WKS_FILES` variable instead. Getting Help ------------ @@ -5546,7 +5550,7 @@ Operational Modes ----------------- You can use Wic in two different modes, depending on how much control -you need for specifying the Openembedded build artifacts that are used +you need for specifying the OpenEmbedded build artifacts that are used for creating the image: Raw and Cooked: - *Raw Mode:* You explicitly specify build artifacts through Wic @@ -5880,7 +5884,7 @@ Directory onto a USB stick, or whatever media for which you built your image, and boot from the media. You can write the image by using ``bmaptool`` or ``dd``:: - $ oe-run-native bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX + $ oe-run-native bmap-tools-native bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX or :: @@ -6432,10 +6436,10 @@ files (i.e. ``local.conf`` and ``bblayers.conf``) that are created in a new build directory. The OpenEmbedded build system uses the environment variable -``TEMPLATECONF`` to locate the directory from which it gathers +:term:`TEMPLATECONF` to locate the directory from which it gathers configuration information that ultimately ends up in the :term:`Build Directory` ``conf`` directory. -By default, ``TEMPLATECONF`` is set as follows in the ``poky`` +By default, :term:`TEMPLATECONF` is set as follows in the ``poky`` repository:: TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf} @@ -6450,7 +6454,7 @@ list of BitBake targets when running the setup script. To override these default configuration files with configurations you want used within every new Build Directory, simply set the -``TEMPLATECONF`` variable to your directory. The ``TEMPLATECONF`` +:term:`TEMPLATECONF` variable to your directory. The :term:`TEMPLATECONF` variable is set in the ``.templateconf`` file, which is in the top-level :term:`Source Directory` folder (e.g. ``poky``). Edit the ``.templateconf`` so that it can locate your @@ -6490,7 +6494,7 @@ either of the setup scripts:: Changing the listed common targets is as easy as editing your version of ``conf-notes.txt`` in your custom template configuration directory and -making sure you have ``TEMPLATECONF`` set to your directory. +making sure you have :term:`TEMPLATECONF` set to your directory. Conserving Disk Space ===================== @@ -7691,7 +7695,7 @@ On a browser, go to ``http://192.168.7.2:3000`` and you see the following: .. image:: figures/cute-files-npm-example.png - :align: center + :width: 100% You can find the recipe in ``workspace/recipes/cute-files``. You can use the recipe in any layer you choose. @@ -8215,6 +8219,7 @@ variable. Here is an example abbreviated listing: .. image:: figures/buildhistory.png :align: center + :width: 50% At the top level, there is a ``metadata-revs`` file that lists the revisions of the repositories for the enabled layers when the build was @@ -8555,7 +8560,7 @@ instruction in the ``README`` file Here is a sample screenshot of the interface: .. image:: figures/buildhistory-web.png - :align: center + :width: 100% Performing Automated Runtime Testing ==================================== @@ -9214,7 +9219,7 @@ section: to run specific tasks in the build chain. It can be useful to run tasks "out-of-order" when trying isolate build issues. -- ":ref:`dev-manual/common-tasks:general bitbake problems`" describes how +- ":ref:`dev-manual/common-tasks:general BitBake problems`" describes how to use BitBake's ``-D`` debug output option to reveal more about what BitBake is doing during the build. @@ -9409,7 +9414,7 @@ format and can be converted to images (e.g. using the ``dot`` tool from - DOT files use a plain text format. The graphs generated using the ``bitbake -g`` command are often so large as to be difficult to - read without special pruning (e.g. with Bitbake's ``-I`` option) + read without special pruning (e.g. with BitBake's ``-I`` option) and processing. Despite the form and size of the graphs, the corresponding ``.dot`` files can still be possible to read and provide useful information. @@ -10177,10 +10182,9 @@ debugger. 2. *Configure the system to include gdbserver in the target filesystem:* - Make the following addition in either your ``local.conf`` file or in - an image recipe:: + Make the following addition in your ``local.conf`` file:: - IMAGE_INSTALL:append = " gdbserver" + EXTRA_IMAGE_FEATURES:append = " tools-debug" The change makes sure the ``gdbserver`` package is included. @@ -10227,14 +10231,14 @@ debugger. $ mkdir debugfs $ cd debugfs - $ tar xvfj build-dir/tmp-glibc/deploy/images/machine/image.rootfs.tar.bz2 - $ tar xvfj build-dir/tmp-glibc/deploy/images/machine/image-dbg.rootfs.tar.bz2 + $ tar xvfj build-dir/tmp/deploy/images/machine/image.rootfs.tar.bz2 + $ tar xvfj build-dir/tmp/deploy/images/machine/image-dbg.rootfs.tar.bz2 5. *Set up GDB:* Install the SDK (if you built one) and then source the correct environment file. Sourcing the environment file puts the SDK in your - ``PATH`` environment variable. + ``PATH`` environment variable and sets ``$GDB`` to the SDK's debugger. If you are using the build system, Gdb is located in `build-dir`\ ``/tmp/sysroots/``\ `host`\ ``/usr/bin/``\ `architecture`\ ``/``\ `architecture`\ ``-gdb`` @@ -10313,24 +10317,20 @@ debug on the target hardware. To support this kind of debugging, you need do the following: -- Ensure that GDB is on the target. You can do this by adding "gdb" to - :term:`IMAGE_INSTALL`:: - - IMAGE_INSTALL:append = " gdb" - - Alternatively, you can add "tools-debug" to :term:`IMAGE_FEATURES`:: +- Ensure that GDB is on the target. You can do this by making + the following addition to your ``local.conf`` file:: - IMAGE_FEATURES:append = " tools-debug" + EXTRA_IMAGE_FEATURES:append = " tools-debug" -- Ensure that debug symbols are present. You can make sure these - symbols are present by installing ``-dbg``:: +- Ensure that debug symbols are present. You can do so by adding the + corresponding ``-dbg`` package to :term:`IMAGE_INSTALL`:: - IMAGE_INSTALL:append = "packagename-dbg" + IMAGE_INSTALL:append = " packagename-dbg" - Alternatively, you can do the following to include + Alternatively, you can add the following to ``local.conf`` to include all the debug symbols:: - IMAGE_FEATURES:append = " dbg-pkgs" + EXTRA_IMAGE_FEATURES:append = " dbg-pkgs" .. note:: @@ -10565,7 +10565,7 @@ used testing branches for OpenEmbedded-Core are as follows: - *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. + changes to BitBake, the core metadata and the poky distro. Similarly, stable branches maintained by the project may have corresponding ``-next`` branches which collect proposed changes. For example, @@ -11442,7 +11442,7 @@ this function, you have to follow the following steps: Please choose one that you want to use and enable the spdx task. You have to add some config options in ``local.conf`` file in your :term:`Build Directory`. Here is an example showing how to generate spdx files - during bitbake using the fossology-python.bbclass:: + during BitBake using the fossology-python.bbclass:: # Select fossology-python.bbclass. INHERIT += "fossology-python" diff --git a/poky/documentation/dev-manual/start.rst b/poky/documentation/dev-manual/start.rst index 96fabac1aa..8cf3ebe316 100644 --- a/poky/documentation/dev-manual/start.rst +++ b/poky/documentation/dev-manual/start.rst @@ -496,7 +496,7 @@ your Yocto Project build host: 6. *Optimize your WSLv2 storage often:* Due to the way storage is handled on WSLv2, the storage space used by the undelying Linux - distribution is not reflected immedately, and since bitbake heavily + distribution is not reflected immedately, and since BitBake heavily uses storage, after several builds, you may be unaware you are running out of space. WSLv2 uses a VHDX file for storage, this issue can be easily avoided by manually optimizing this file often, this diff --git a/poky/documentation/kernel-dev/common.rst b/poky/documentation/kernel-dev/common.rst index a5dd02ccf2..dc3345a520 100644 --- a/poky/documentation/kernel-dev/common.rst +++ b/poky/documentation/kernel-dev/common.rst @@ -1062,7 +1062,7 @@ Section. contents:: FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:" - SRC_URI:append = "file://0001-calibrate.c-Added-some-printk-statements.patch" + SRC_URI:append = " file://0001-calibrate.c-Added-some-printk-statements.patch" The :term:`FILESEXTRAPATHS` and :term:`SRC_URI` statements enable the OpenEmbedded build system to find the patch file. @@ -1560,7 +1560,7 @@ source directory. Follow these steps to clean up the version string: on building the kernel image when using ``devtool``, see the ":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`" section. For - information on building the kernel image when using Bitbake, see the + information on building the kernel image when using BitBake, see the ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`" section. diff --git a/poky/documentation/kernel-dev/concepts-appx.rst b/poky/documentation/kernel-dev/concepts-appx.rst index 910318e0f9..b3a2f3abbf 100644 --- a/poky/documentation/kernel-dev/concepts-appx.rst +++ b/poky/documentation/kernel-dev/concepts-appx.rst @@ -221,7 +221,7 @@ the line-by-line code ``diff`` level is now a trivial operation. The following illustration shows the conceptual Yocto Linux kernel. .. image:: figures/kernel-architecture-overview.png - :align: center + :width: 100% In the illustration, the "Kernel.org Branch Point" marks the specific spot (or Linux kernel release) from which the Yocto Linux kernel is @@ -318,12 +318,13 @@ tree specific to your kernel from which to generate the new kernel image. The following figure shows the temporary file structure created on your -host system when you build the kernel using Bitbake. This +host system when you build the kernel using BitBake. This :term:`Build Directory` contains all the source files used during the build. .. image:: figures/kernel-overview-2-generic.png :align: center + :width: 70% Again, for additional information on the Yocto Project kernel's architecture and its branching strategy, see the diff --git a/poky/documentation/kernel-dev/intro.rst b/poky/documentation/kernel-dev/intro.rst index e406f6e47f..b9ce7f241c 100644 --- a/poky/documentation/kernel-dev/intro.rst +++ b/poky/documentation/kernel-dev/intro.rst @@ -106,7 +106,7 @@ modification workflow. The illustration and accompanying list provide general information and references for further information. .. image:: figures/kernel-dev-flow.png - :align: center + :width: 100% 1. *Set up Your Host Development System to Support Development Using the Yocto Project*: See the ":doc:`/dev-manual/start`" section in diff --git a/poky/documentation/migration-guides/migration-2.2.rst b/poky/documentation/migration-guides/migration-2.2.rst index 10aa2d0684..fe7bc2cf55 100644 --- a/poky/documentation/migration-guides/migration-2.2.rst +++ b/poky/documentation/migration-guides/migration-2.2.rst @@ -70,7 +70,7 @@ Metadata Must Now Use Python 3 Syntax The metadata is now required to use Python 3 syntax. For help preparing metadata, see any of the many Python 3 porting guides available. -Alternatively, you can reference the conversion commits for Bitbake and +Alternatively, you can reference the conversion commits for BitBake and you can use :term:`OpenEmbedded-Core (OE-Core)` as a guide for changes. Following are particular areas of interest: diff --git a/poky/documentation/migration-guides/migration-2.7.rst b/poky/documentation/migration-guides/migration-2.7.rst index ae70353bf7..1b8f1ce1bb 100644 --- a/poky/documentation/migration-guides/migration-2.7.rst +++ b/poky/documentation/migration-guides/migration-2.7.rst @@ -15,7 +15,7 @@ The following changes have been made to BitBake: functions (e.g. ``def funcname:``) in the metadata for tab indentation. If found, BitBake produces a warning. -- Bitbake now checks +- BitBake now checks :term:`BBFILE_COLLECTIONS` for duplicate entries and triggers an error if any are found. diff --git a/poky/documentation/migration-guides/migration-3.0.rst b/poky/documentation/migration-guides/migration-3.0.rst index 50d6758e71..1219edf921 100644 --- a/poky/documentation/migration-guides/migration-3.0.rst +++ b/poky/documentation/migration-guides/migration-3.0.rst @@ -152,7 +152,7 @@ by ``CVE_CHECK_WHITELIST`` (replaced by :term:`CVE_CHECK_IGNORE` in version 3.5) .. _migration-3.0-bitbake-changes: -Bitbake Changes +BitBake Changes --------------- The following BitBake changes have occurred. diff --git a/poky/documentation/migration-guides/migration-3.2.rst b/poky/documentation/migration-guides/migration-3.2.rst index d593effe97..a376eced52 100644 --- a/poky/documentation/migration-guides/migration-3.2.rst +++ b/poky/documentation/migration-guides/migration-3.2.rst @@ -86,7 +86,7 @@ value to be explicitly prepended to package names being added as dependencies (e.g. in :term:`RDEPENDS` and :term:`RRECOMMENDS` values) where the dependency is conditionally added. -If you have anonymous python or in-line python conditionally adding +If you have anonymous Python or in-line Python conditionally adding dependencies in your custom recipes, and you intend for those recipes to work with multilib, then you will need to ensure that ``${MLPREFIX}`` is prefixed on the package names in the dependencies, for example @@ -149,7 +149,7 @@ the upstream documentation for ``dhcpcd`` and ``kea`` for further details. Packaging changes ----------------- -- ``python3``: the ``urllib`` python package has now moved into the core package, as it is used more commonly than just netclient (e.g. email, xml, mimetypes, pydoc). In addition, the ``pathlib`` module is now also part of the core package. +- ``python3``: the ``urllib`` Python package has now moved into the core package, as it is used more commonly than just netclient (e.g. email, xml, mimetypes, pydoc). In addition, the ``pathlib`` module is now also part of the core package. - ``iptables``: ``iptables-apply`` and ``ip6tables-apply`` have been split out to their own package to avoid a bash dependency in the main ``iptables`` package @@ -283,7 +283,7 @@ Image artifact name variables now centralised in image-artifact-names class --------------------------------------------------------------------------- The defaults for the following image artifact name variables have been moved -from bitbake.conf to a new ``image-artifact-names`` class: +from ``bitbake.conf`` to a new ``image-artifact-names`` class: - :term:`IMAGE_BASENAME` - :term:`IMAGE_LINK_NAME` diff --git a/poky/documentation/migration-guides/migration-3.3.rst b/poky/documentation/migration-guides/migration-3.3.rst index 1eb494c286..22562dacd4 100644 --- a/poky/documentation/migration-guides/migration-3.3.rst +++ b/poky/documentation/migration-guides/migration-3.3.rst @@ -76,7 +76,7 @@ Some example recipes where this change has been made: ``gpgme``, ``libcap-ng``, .. _migration-3.3-distutils-path: -``setup.py`` path for python modules +``setup.py`` path for Python modules ------------------------------------ In a Python module, sometimes ``setup.py`` can be buried deep in the @@ -133,7 +133,7 @@ unless you want to take advantage of the improved granularity: - ``procps``: split ``ps`` and ``sysctl`` into their own packages - ``rpm``: split build and extra functionality into separate packages - ``sudo``: split ``sudo`` binary into ``sudo-sudo`` and libs into ``sudo-lib`` -- ``systemtap``: examples, python scripts and runtime material split out +- ``systemtap``: examples, Python scripts and runtime material split out - ``util-linux``: ``libuuid`` has been split out to its own ``util-linux-libuuid`` recipe (and corresponding packages) to avoid circular dependencies if ``libgcrypt`` support is enabled in ``util-linux``. diff --git a/poky/documentation/migration-guides/migration-3.4.rst b/poky/documentation/migration-guides/migration-3.4.rst index d57c955eb4..8db43a1454 100644 --- a/poky/documentation/migration-guides/migration-3.4.rst +++ b/poky/documentation/migration-guides/migration-3.4.rst @@ -233,7 +233,7 @@ Image / SDK generation changes Miscellaneous ~~~~~~~~~~~~~ -- Certificates are now properly checked when bitbake fetches sources +- Certificates are now properly checked when BitBake fetches sources over HTTPS. If you receive errors as a result for your custom recipes, you will need to use a mirror or address the issue with the operators of the server in question. diff --git a/poky/documentation/migration-guides/release-3.4.rst b/poky/documentation/migration-guides/release-3.4.rst index 81476c4adb..66023108c7 100644 --- a/poky/documentation/migration-guides/release-3.4.rst +++ b/poky/documentation/migration-guides/release-3.4.rst @@ -7,4 +7,6 @@ Release 3.4 (honister) release-notes-3.4 release-notes-3.4.1 release-notes-3.4.2 + release-notes-3.4.3 + release-notes-3.4.4 diff --git a/poky/documentation/migration-guides/release-notes-3.4.1.rst b/poky/documentation/migration-guides/release-notes-3.4.1.rst index b122887661..0503f29b2c 100644 --- a/poky/documentation/migration-guides/release-notes-3.4.1.rst +++ b/poky/documentation/migration-guides/release-notes-3.4.1.rst @@ -46,7 +46,7 @@ Fixes in 3.4.1 - bitbake: tests/fetch: Update pcre.org address after github changes - bitbake: tests/runqueue: Ensure hashserv exits before deleting files - bitbake: utils: Handle lockfile filenames that are too long for filesystems -- bootchart2: Don't compile python modules +- bootchart2: Don't compile Python modules - build-appliance-image: Update to honister head revision - buildhistory: Fix package output files for SDKs - busybox: 1.34.0 -> 1.34.1 diff --git a/poky/documentation/migration-guides/release-notes-3.4.3.rst b/poky/documentation/migration-guides/release-notes-3.4.3.rst new file mode 100644 index 0000000000..5e118d9b02 --- /dev/null +++ b/poky/documentation/migration-guides/release-notes-3.4.3.rst @@ -0,0 +1,197 @@ +Release notes for 3.4.3 (honister) +---------------------------------- + +Security Fixes in 3.4.3 +~~~~~~~~~~~~~~~~~~~~~~~ + +- ghostscript: fix :cve:`2021-3781` +- ghostscript: fix :cve:`2021-45949` +- tiff: Add backports for two CVEs from upstream (:cve:`2022-0561` & :cve:`2022-0562`) +- gcc : Fix :cve:`2021-46195` +- virglrenderer: fix `CVE-2022-0135 <https://security-tracker.debian.org/tracker/CVE-2022-0135>`__ and `CVE-2022-0175 <https://security-tracker.debian.org/tracker/CVE-2022-0175>`__ +- binutils: Add fix for :cve:`2021-45078` + + +Fixes in 3.4.3 +~~~~~~~~~~~~~~ + +- Revert "cve-check: add lockfile to task" +- asciidoc: update git repository +- bitbake: build: Tweak exception handling for setscene tasks +- bitbake: contrib: Fix hash server Dockerfile dependencies +- bitbake: cooker: Improve parsing failure from handled exception usability +- bitbake: data_smart: Fix overrides file/line message additions +- bitbake: fetch2: ssh: username and password are optional +- bitbake: tests/fetch: Handle upstream master -> main branch change +- bitbake: utils: Ensure shell function failure in python logging is correct +- build-appliance-image: Update to honister head revision +- build-appliance-image: Update to honister head revision +- coreutils: remove obsolete ignored CVE list +- crate-fetch: fix setscene failures +- cups: Add --with-dbusdir to EXTRA_OECONF for deterministic build +- cve-check: create directory of CVE_CHECK_MANIFEST before copy +- cve-check: get_cve_info should open the database read-only +- default-distrovars.inc: Switch connectivity check to a yoctoproject.org page +- depmodwrapper-cross: add config directory option +- devtool: deploy-target: Remove stripped binaries in pseudo context +- devtool: explicitly set main or master branches in upgrades when available +- docs: fix hardcoded link warning messages +- documentation: conf.py: update for 3.4.2 +- documentation: prepare for 3.4.3 release +- expat: Upgrade to 2.4.7 +- gcc-target: fix glob to remove gcc-<version> binary +- gcsections: add nativesdk-cairo to exclude list +- go: update to 1.16.15 +- gst-devtools: 1.18.5 -> 1.18.6 +- gst-examples: 1.18.5 -> 1.18.6 +- gstreamer1.0-libav: 1.18.5 -> 1.18.6 +- gstreamer1.0-omx: 1.18.5 -> 1.18.6 +- gstreamer1.0-plugins-bad: 1.18.5 -> 1.18.6 +- gstreamer1.0-plugins-base: 1.18.5 -> 1.18.6 +- gstreamer1.0-plugins-good: 1.18.5 -> 1.18.6 +- gstreamer1.0-plugins-ugly: 1.18.5 -> 1.18.6 +- gstreamer1.0-python: 1.18.5 -> 1.18.6 +- gstreamer1.0-rtsp-server: 1.18.5 -> 1.18.6 +- gstreamer1.0-vaapi: 1.18.5 -> 1.18.6 +- gstreamer1.0: 1.18.5 -> 1.18.6 +- harfbuzz: upgrade 2.9.0 -> 2.9.1 +- initramfs-framework: unmount automounts before switch_root +- kernel-devsrc: do not copy Module.symvers file during install +- libarchive : update to 3.5.3 +- libpcap: Disable DPDK explicitly +- libxml-parser-perl: Add missing RDEPENDS +- linux-firmware: upgrade 20211216 -> 20220209 +- linux-yocto/5.10: Fix ramoops/ftrace +- linux-yocto/5.10: features/zram: remove CONFIG_ZRAM_DEF_COMP +- linux-yocto/5.10: fix dssall build error with binutils 2.3.8 +- linux-yocto/5.10: ppc/riscv: fix build with binutils 2.3.8 +- linux-yocto/5.10: update genericx86* machines to v5.10.99 +- linux-yocto/5.10: update to v5.10.103 +- mc: fix build if ncurses have been configured without wide characters +- oeqa/buildtools: Switch to our webserver instead of example.com +- patch.py: Prevent git repo reinitialization +- perl: Improve and update module RPDEPENDS +- poky.conf: bump version for 3.4.3 honister release +- qemuboot: Fix build error if UNINATIVE_LOADER is unset +- quilt: Disable external sendmail for deterministic build +- recipetool: Fix circular reference in SRC_URI +- releases: update to include 3.3.5 +- releases: update to include 3.4.2 +- rootfs-postcommands: amend systemd_create_users add user to group check +- ruby: update 3.0.2 -> 3.0.3 +- scripts/runqemu-ifdown: Don't treat the last iptables command as special +- sdk: fix search for dynamic loader +- selftest: recipetool: Correct the URI for socat +- sstate: inside the threadedpool don't write to the shared localdata +- uninative: Upgrade to 3.5 +- util-linux: upgrade to 2.37.4 +- vim: Update to 8.2.4524 for further CVE fixes +- wic: Use custom kernel path if provided +- wireless-regdb: upgrade 2021.08.28 -> 2022.02.18 +- zip: modify when match.S is built + +Contributors to 3.4.3 +~~~~~~~~~~~~~~~~~~~~~ + +- Alexander Kanavin +- Anuj Mittal +- Bill Pittman +- Bruce Ashfield +- Chee Yang Lee +- Christian Eggers +- Daniel Gomez +- Daniel Müller +- Daniel Wagenknecht +- Florian Amstutz +- Joe Slater +- Jose Quaresma +- Justin Bronder +- Lee Chee Yang +- Michael Halstead +- Michael Opdenacker +- Oleksandr Ocheretnyi +- Oleksandr Suvorov +- Pavel Zhukov +- Peter Kjellerstedt +- Richard Purdie +- Robert Yang +- Ross Burton +- Sakib Sajal +- Saul Wold +- Sean Anderson +- Stefan Herbrechtsmeier +- Tamizharasan Kumar +- Tean Cunningham +- Zoltán Böszörményi +- pgowda +- wangmy + +Repositories / Downloads for 3.4.3 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +poky + +- Repository Location: https://git.yoctoproject.org/poky/ +- Branch: :yocto_git:`honister </poky/log/?h=honister>` +- Tag: `yocto-3.4.3 <https://git.yoctoproject.org/poky/tag/?h=yocto-3.4.3>`__ +- Git Revision: :yocto_git:`ee68ae307fd951b9de6b31dc6713ea29186b7749 </poky/commit/?id=ee68ae307fd951b9de6b31dc6713ea29186b7749>` +- Release Artefact: poky-ee68ae307fd951b9de6b31dc6713ea29186b7749 +- sha: 92c3d73c3e74f0e1d5c2ab2836ce3a3accbe47772cea70df3755845e0db1379b +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.3/poky-ee68ae307fd951b9de6b31dc6713ea29186b7749.tar.bz2, + http://mirrors.kernel.org/yocto/yocto/yocto-3.4.3/poky-ee68ae307fd951b9de6b31dc6713ea29186b7749.tar.bz2 + +openembedded-core + +- Repository Location: :oe_git:`/openembedded-core` +- Branch: :oe_git:`honister </openembedded-core/log/?h=honister>` +- Tag: :oe_git:`yocto-3.4.3 </openembedded-core/tag/?h=yocto-3.4.3>` +- Git Revision: :oe_git:`ebca8f3ac9372b7ebb3d39e8f7f930b63b481448 </openembedded-core/commit/?id=ebca8f3ac9372b7ebb3d39e8f7f930b63b481448>` +- Release Artefact: oecore-ebca8f3ac9372b7ebb3d39e8f7f930b63b481448 +- sha: f28e503f6f6c0bcd9192dbd528f8e3c7bcea504c089117e0094d9a4f315f4b9f +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.3/oecore-ebca8f3ac9372b7ebb3d39e8f7f930b63b481448.tar.bz2, + http://mirrors.kernel.org/yocto/yocto/yocto-3.4.3/oecore-ebca8f3ac9372b7ebb3d39e8f7f930b63b481448.tar.bz2 + +meta-mingw + +- Repository Location: https://git.yoctoproject.org/meta-mingw +- Branch: :yocto_git:`honister </meta-mingw/log/?h=honister>` +- Tag: :yocto_git:`yocto-3.4.3 </meta-mingw/tag/?h=yocto-3.4.3>` +- Git Revision: :yocto_git:`f5d761cbd5c957e4405c5d40b0c236d263c916a8 </meta-mingw/commit/?id=f5d761cbd5c957e4405c5d40b0c236d263c916a8>` +- Release Artefact: meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8 +- sha: d4305d638ef80948584526c8ca386a8cf77933dffb8a3b8da98d26a5c40fcc11 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.3/meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8.tar.bz2, + http://mirrors.kernel.org/yocto/yocto/yocto-3.4.3/meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8.tar.bz2 + +meta-gplv2 + +- Repository Location: https://git.yoctoproject.org/meta-gplv2 +- Branch: :yocto_git:`honister </meta-gplv2/log/?h=honister>` +- Tag: :yocto_git:`yocto-3.4.3 </meta-gplv2/tag/?h=yocto-3.4.3>` +- Git Revision: :yocto_git:`f04e4369bf9dd3385165281b9fa2ed1043b0e400 </meta-gplv2/commit/?id=f04e4369bf9dd3385165281b9fa2ed1043b0e400>` +- Release Artefact: meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400 +- sha: ef8e2b1ec1fb43dbee4ff6990ac736315c7bc2d8c8e79249e1d337558657d3fe +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.3/meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400.tar.bz2, + http://mirrors.kernel.org/yocto/yocto/yocto-3.4.3/meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400.tar.bz2 + +bitbake + +- Repository Location: :oe_git:`/bitbake` +- Branch: :oe_git:`1.52 </bitbake/log/?h=1.52>` +- Tag: :oe_git:`yocto-3.4.3 </bitbake/tag/?h=yocto-3.4.3>` +- Git Revision: :oe_git:`43dcb2b2a2b95a5c959be57bca94fb7190ea6257 </bitbake/commit/?id=43dcb2b2a2b95a5c959be57bca94fb7190ea6257>` +- Release Artefact: bitbake-43dcb2b2a2b95a5c959be57bca94fb7190ea6257 +- sha: 92497ff97fed81dcc6d3e202969fb63ca983a8f5d9d91cafc6aee88312f79cf9 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.3/bitbake-43dcb2b2a2b95a5c959be57bca94fb7190ea6257.tar.bz2, + http://mirrors.kernel.org/yocto/yocto/yocto-3.4.3/bitbake-43dcb2b2a2b95a5c959be57bca94fb7190ea6257.tar.bz2 + +yocto-docs + +- Repository Location: https://git.yoctoproject.org/yocto-docs +- Branch: :yocto_git:`honister </yocto-docs/log/?h=honister>` +- Tag: :yocto_git:`yocto-3.4.3 </yocto-docs/tag/?h=yocto-3.4.3>` +- Git Revision: :yocto_git:`15f46f97d9cad558c19fc1dc19cfbe3720271d04 </yocto-docs/commit/?15f46f97d9cad558c19fc1dc19cfbe3720271d04>` diff --git a/poky/documentation/migration-guides/release-notes-3.4.4.rst b/poky/documentation/migration-guides/release-notes-3.4.4.rst new file mode 100644 index 0000000000..91beba0062 --- /dev/null +++ b/poky/documentation/migration-guides/release-notes-3.4.4.rst @@ -0,0 +1,155 @@ +Release notes for 3.4.4 (honister) +---------------------------------- + +Security Fixes in 3.4.4 +~~~~~~~~~~~~~~~~~~~~~~~ + +- tiff: fix :cve:`2022-0865`, :cve:`2022-0891`, :cve:`2022-0907`, :cve:`2022-0908`, :cve:`2022-0909` and :cve:`2022-0924` +- xz: fix `CVE-2022-1271 <https://security-tracker.debian.org/tracker/CVE-2022-1271>`__ +- unzip: fix `CVE-2021-4217 <https://security-tracker.debian.org/tracker/CVE-2021-4217>`__ +- zlib: fix :cve:`2018-25032` +- grub: ignore :cve:`2021-46705` + +Fixes in 3.4.4 +~~~~~~~~~~~~~~ + +- alsa-tools: Ensure we install correctly +- bitbake.conf: mark all directories as safe for git to read +- bitbake: knotty: display active tasks when printing keepAlive() message +- bitbake: knotty: reduce keep-alive timeout from 5000s (83 minutes) to 10 minutes +- bitbake: server/process: Disable gc around critical section +- bitbake: server/xmlrpcserver: Add missing xmlrpcclient import +- bitbake: toaster: Fix IMAGE_INSTALL issues with _append vs :append +- bitbake: toaster: fixtures replace gatesgarth +- build-appliance-image: Update to honister head revision +- conf.py/poky.yaml: Move version information to poky.yaml and read in conf.py +- conf/machine: fix QEMU x86 sound options +- devupstream: fix handling of SRC_URI +- documentation: update for 3.4.4 release +- externalsrc/devtool: Fix to work with fixed export funcition flags handling +- gmp: add missing COPYINGv3 +- gnu-config: update SRC_URI +- libxml2: fix CVE-2022-23308 regression +- libxml2: move to gitlab.gnome.org +- libxml2: update to 2.9.13 +- libxshmfence: Correct LICENSE to HPND +- license_image.bbclass: close package.manifest file +- linux-firmware: correct license for ar3k firmware +- linux-firmware: upgrade 20220310 -> 20220411 +- linux-yocto-rt/5.10: update to -rt61 +- linux-yocto/5.10: cfg/debug: add configs for kcsan +- linux-yocto/5.10: split vtpm for more granular inclusion +- linux-yocto/5.10: update to v5.10.109 +- linux-yocto: nohz_full boot arg fix +- oe-pkgdata-util: Adapt to the new variable override syntax +- oeqa/selftest/devtool: ensure Git username is set before upgrade tests +- poky.conf: bump version for 3.4.4 release +- pseudo: Add patch to workaround paths with crazy lengths +- pseudo: Fix handling of absolute links +- sanity: Add warning for local hasheqiv server with remote sstate mirrors +- scripts/runqemu: Fix memory limits for qemux86-64 +- shadow-native: Simplify and fix syslog disable patch +- tiff: Add marker for CVE-2022-1056 being fixed +- toaster: Fix broken overrides usage +- u-boot: Inherit pkgconfig +- uninative: Upgrade to 3.6 with gcc 12 support +- vim: Upgrade 8.2.4524 -> 8.2.4681 +- virglrenderer: update SRC_URI +- webkitgtk: update to 2.32.4 +- wireless-regdb: upgrade 2022.02.18 -> 2022.04.08 + +Known Issues +~~~~~~~~~~~~ + +There were a couple of known autobuilder intermittent bugs that occurred during release testing but these are not regressions in the release. + +Contributors to 3.4.4 +~~~~~~~~~~~~~~~~~~~~~ + +- Alexandre Belloni +- Anuj Mittal +- Bruce Ashfield +- Chee Yang Lee +- Dmitry Baryshkov +- Joe Slater +- Konrad Weihmann +- Martin Jansa +- Michael Opdenacker +- Minjae Kim +- Peter Kjellerstedt +- Ralph Siemsen +- Richard Purdie +- Ross Burton +- Tim Orling +- wangmy +- zhengruoqin + +Repositories / Downloads for 3.4.4 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +poky + +- Repository Location: https://git.yoctoproject.org/poky/ +- Branch: :yocto_git:`honister </poky/log/?h=honister>` +- Tag: `yocto-3.4.4 <https://git.yoctoproject.org/poky/tag/?h=yocto-3.4.4>`__ +- Git Revision: :yocto_git:`780eeec8851950ee6ac07a2a398ba937206bd2e4 </poky/commit/?id=780eeec8851950ee6ac07a2a398ba937206bd2e4>` +- Release Artefact: poky-780eeec8851950ee6ac07a2a398ba937206bd2e4 +- sha: 09558927064454ec2492da376156b716d9fd14aae57196435d742db7bfdb4b95 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.4/poky-780eeec8851950ee6ac07a2a398ba937206bd2e4.tar.bz2, + http://mirrors.kernel.org/yocto/yocto/yocto-3.4.4/poky-780eeec8851950ee6ac07a2a398ba937206bd2e4.tar.bz2 + +openembedded-core + +- Repository Location: :oe_git:`/openembedded-core` +- Branch: :oe_git:`honister </openembedded-core/log/?h=honister>` +- Tag: :oe_git:`yocto-3.4.4 </openembedded-core/tag/?h=yocto-3.4.4>` +- Git Revision: :oe_git:`1a6f5e27249afb6fb4d47c523b62b5dd2482a69d </openembedded-core/commit/?id=1a6f5e27249afb6fb4d47c523b62b5dd2482a69d>` +- Release Artefact: oecore-1a6f5e27249afb6fb4d47c523b62b5dd2482a69d +- sha: b8354ca457756384139a579b9e51f1ba854013c99add90c0c4c6ef68421fede5 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.4/oecore-1a6f5e27249afb6fb4d47c523b62b5dd2482a69d.tar.bz2, + http://mirrors.kernel.org/yocto/yocto/yocto-3.4.4/oecore-1a6f5e27249afb6fb4d47c523b62b5dd2482a69d.tar.bz2 + +meta-mingw + +- Repository Location: https://git.yoctoproject.org/meta-mingw +- Branch: :yocto_git:`honister </meta-mingw/log/?h=honister>` +- Tag: :yocto_git:`yocto-3.4.4 </meta-mingw/tag/?h=yocto-3.4.4>` +- Git Revision: :yocto_git:`f5d761cbd5c957e4405c5d40b0c236d263c916a8 </meta-mingw/commit/?id=f5d761cbd5c957e4405c5d40b0c236d263c916a8>` +- Release Artefact: meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8 +- sha: d4305d638ef80948584526c8ca386a8cf77933dffb8a3b8da98d26a5c40fcc11 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.4/meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-3.4.4/meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8.tar.bz2 + +meta-gplv2 + +- Repository Location: https://git.yoctoproject.org/meta-gplv2 +- Branch: :yocto_git:`honister </meta-gplv2/log/?h=honister>` +- Tag: :yocto_git:`yocto-3.4.4 </meta-gplv2/tag/?h=yocto-3.4.4>` +- Git Revision: :yocto_git:`f04e4369bf9dd3385165281b9fa2ed1043b0e400 </meta-gplv2/commit/?id=f04e4369bf9dd3385165281b9fa2ed1043b0e400>` +- Release Artefact: meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400 +- sha: ef8e2b1ec1fb43dbee4ff6990ac736315c7bc2d8c8e79249e1d337558657d3fe +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.4/meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400.tar.bz2, + http://mirrors.kernel.org/yocto/yocto/yocto-3.4.4/meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400.tar.bz2 + +bitbake + +- Repository Location: :oe_git:`/bitbake` +- Branch: :oe_git:`1.52 </bitbake/log/?h=1.52>` +- Tag: :oe_git:`yocto-3.4.4 </bitbake/tag/?h=yocto-3.4.3>` +- Git Revision: :oe_git:`c2d8f9b2137bd4a98eb0f51519493131773e7517 </bitbake/commit/?id=c2d8f9b2137bd4a98eb0f51519493131773e7517>` +- Release Artefact: bitbake-c2d8f9b2137bd4a98eb0f51519493131773e7517 +- sha: a8b6217f2d63975bbf49f430e11046608023ee2827faa893b15d9a0d702cf833 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.4/bitbake-c2d8f9b2137bd4a98eb0f51519493131773e7517.tar.bz2, + http://mirrors.kernel.org/yocto/yocto/yocto-3.4.4/bitbake-c2d8f9b2137bd4a98eb0f51519493131773e7517.tar.bz2 + +yocto-docs + +- Repository Location: https://git.yoctoproject.org/yocto-docs +- Branch: :yocto_git:`honister </yocto-docs/log/?h=honister>` +- Tag: :yocto_git:`yocto-3.4.4 </yocto-docs/tag/?h=yocto-3.4.4>` +- Git Revision: :yocto_git:`5ead7d39aaf9044078dff27f462e29a8e31d89e4 </yocto-docs/commit/?5ead7d39aaf9044078dff27f462e29a8e31d89e4>` diff --git a/poky/documentation/overview-manual/concepts.rst b/poky/documentation/overview-manual/concepts.rst index 6c341976f9..016577e07e 100644 --- a/poky/documentation/overview-manual/concepts.rst +++ b/poky/documentation/overview-manual/concepts.rst @@ -166,7 +166,7 @@ remainder of this section expands on the fundamental input, output, process, and metadata logical blocks that make up the workflow. .. image:: figures/YP-flow-diagram.png - :align: center + :width: 100% In general, the build's workflow consists of several functional areas: @@ -209,7 +209,7 @@ Configuration" box of the :ref:`general workflow figure <overview-manual/concepts:openembedded build system concepts>`: .. image:: figures/user-configuration.png - :align: center + :width: 100% BitBake needs some basic configuration files in order to complete a build. These files are ``*.conf`` files. The minimally necessary ones @@ -313,7 +313,7 @@ section in the Yocto Project Development Tasks Manual. The files ``site.conf`` and ``auto.conf`` are not created by the environment initialization script. If you want the ``site.conf`` file, -you need to create that yourself. The ``auto.conf`` file is typically +you need to create it yourself. The ``auto.conf`` file is typically created by an autobuilder: - *site.conf:* You can use the ``conf/site.conf`` configuration @@ -321,17 +321,7 @@ created by an autobuilder: you had several build environments and they shared some common features. You can set these default build properties here. A good example is perhaps the packaging format to use through the - :term:`PACKAGE_CLASSES` - variable. - - One useful scenario for using the ``conf/site.conf`` file is to - extend your :term:`BBPATH` variable - to include the path to a ``conf/site.conf``. Then, when BitBake looks - for Metadata using :term:`BBPATH`, it finds the ``conf/site.conf`` file - and applies your common configurations found in the file. To override - configurations in a particular build directory, alter the similar - configurations within that build directory's ``conf/local.conf`` - file. + :term:`PACKAGE_CLASSES` variable. - *auto.conf:* The file is usually created and written to by an autobuilder. The settings put into the file are typically the same as @@ -401,6 +391,7 @@ layers from the :ref:`general workflow figure .. image:: figures/layer-input.png :align: center + :width: 70% In general, all layers have a similar structure. They all contain a licensing file (e.g. ``COPYING.MIT``) if the layer is to be distributed, @@ -551,6 +542,7 @@ area of the :ref:`general workflow figure <overview-manual/concepts:openembedded .. image:: figures/source-input.png :align: center + :width: 70% Upstream Project Releases ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -629,7 +621,7 @@ This section looks a little closer into the package feeds area used by the build system. Here is a more detailed look at the area: .. image:: figures/package-feeds.png - :align: center + :width: 100% Package feeds are an intermediary step in the build process. The OpenEmbedded build system provides classes to generate different package @@ -702,7 +694,7 @@ The first stages of building a recipe are to fetch and unpack the source code: .. image:: figures/source-fetching.png - :align: center + :width: 100% The :ref:`ref-tasks-fetch` and :ref:`ref-tasks-unpack` tasks fetch @@ -790,7 +782,7 @@ Once source code is fetched and unpacked, BitBake locates patch files and applies them to the source files: .. image:: figures/patching.png - :align: center + :width: 100% The :ref:`ref-tasks-patch` task uses a recipe's :term:`SRC_URI` statements @@ -831,7 +823,7 @@ compile the source code. Once compilation occurs, the files are copied to a holding area (staged) in preparation for packaging: .. image:: figures/configuration-compile-autoreconf.png - :align: center + :width: 100% This step in the build process consists of the following tasks: @@ -889,7 +881,7 @@ After source code is configured, compiled, and staged, the build system analyzes the results and splits the output into packages: .. image:: figures/analysis-for-package-splitting.png - :align: center + :width: 100% The :ref:`ref-tasks-package` and :ref:`ref-tasks-packagedata` @@ -968,7 +960,7 @@ Once packages are split and stored in the Package Feeds area, the build system uses BitBake to generate the root filesystem image: .. image:: figures/image-generation.png - :align: center + :width: 100% The image generation process consists of several stages and depends on several tasks and variables. The @@ -1086,7 +1078,7 @@ Development Kit (SDK) installer scripts for both the standard SDK and the extensible SDK (eSDK): .. image:: figures/sdk-generation.png - :align: center + :width: 100% .. note:: @@ -1262,6 +1254,7 @@ this output: .. image:: figures/images.png :align: center + :width: 75% .. note:: @@ -1321,7 +1314,7 @@ SDK (e.g. ``bitbake -c populate_sdk_ext`` imagename) or a standard SDK closer look at this output: .. image:: figures/sdk.png - :align: center + :width: 100% The specific form of this output is a set of files that includes a self-extracting SDK installer (``*.sh``), host and target manifest @@ -1439,7 +1432,7 @@ The following figure shows a high-level build environment regarding toolchain construction and use. .. image:: figures/cross-development-toolchains.png - :align: center + :width: 100% Most of the work occurs on the Build Host. This is the machine used to build images and generally work within the the Yocto Project @@ -2146,7 +2139,7 @@ dependencies, you must manually declare the dependencies. By default, ``foo-dev`` also has an :term:`RDEPENDS`-style dependency on ``foo``, because the default value of ``RDEPENDS:${PN}-dev`` (set in - bitbake.conf) includes "${PN}". + ``bitbake.conf``) includes "${PN}". To ensure that the dependency chain is never broken, ``-dev`` and ``-dbg`` packages are always generated by default, even if the diff --git a/poky/documentation/overview-manual/development-environment.rst b/poky/documentation/overview-manual/development-environment.rst index e171d7aaa3..f1001e0bd3 100644 --- a/poky/documentation/overview-manual/development-environment.rst +++ b/poky/documentation/overview-manual/development-environment.rst @@ -176,7 +176,7 @@ development: repositories for each of these areas. .. image:: figures/source-repos.png - :align: center + :width: 100% For steps on how to view and access these upstream Git repositories, see the ":ref:`dev-manual/start:accessing source repositories`" @@ -191,6 +191,7 @@ development: .. image:: figures/index-downloads.png :align: center + :width: 50% For steps on how to view and access these files, see the ":ref:`dev-manual/start:accessing index of releases`" @@ -205,7 +206,7 @@ development: :yocto_dl:`Index of /releases: </releases>` area. .. image:: figures/yp-download.png - :align: center + :width: 100% For steps on how to use the "DOWNLOADS" page, see the ":ref:`dev-manual/start:using the downloads page`" diff --git a/poky/documentation/overview-manual/yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst index e574dfa5b8..a2e0862459 100644 --- a/poky/documentation/overview-manual/yp-intro.rst +++ b/poky/documentation/overview-manual/yp-intro.rst @@ -24,7 +24,7 @@ software customizations and build interchange for multiple hardware platforms as well as software stacks that can be maintained and scaled. .. image:: figures/key-dev-elements.png - :align: center + :width: 100% For further introductory information on the Yocto Project, you might be interested in this @@ -638,7 +638,7 @@ these items that make up the Poky repository in the The following figure illustrates what generally comprises Poky: .. image:: figures/poky-reference-distribution.png - :align: center + :width: 100% - BitBake is a task executor and scheduler that is the heart of the OpenEmbedded build system. @@ -688,8 +688,8 @@ 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 -`layers <overview-manual/yp-intro:the yocto project layer model>` that extend +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 @@ -720,7 +720,7 @@ accomplish image and SDK generation. The following figure overviews that workflow: .. image:: figures/YP-flow-diagram.png - :align: center + :width: 100% Following is a brief summary of the "workflow": diff --git a/poky/documentation/profile-manual/usage.rst b/poky/documentation/profile-manual/usage.rst index fb1553d70d..0ff9d921fd 100644 --- a/poky/documentation/profile-manual/usage.rst +++ b/poky/documentation/profile-manual/usage.rst @@ -197,6 +197,7 @@ in an interactive UI:: .. image:: figures/perf-wget-flat-stripped.png :align: center + :width: 70% The above screenshot displays a 'flat' profile, one entry for each 'bucket' corresponding to the functions that were profiled during the @@ -230,6 +231,7 @@ but the entire callchain to the sampled function as well:: .. image:: figures/perf-wget-g-copy-to-user-expanded-stripped.png :align: center + :width: 70% Using the callgraph view, we can actually see not only which functions took the most time, but we can also see a summary of how those functions @@ -266,6 +268,7 @@ busybox. .. image:: figures/perf-wget-g-copy-from-user-expanded-stripped.png :align: center + :width: 70% The above screenshot shows the other half of the journey for the data - from the wget program's userspace buffers to disk. To get the buffers to @@ -283,6 +286,7 @@ let's expand the first entry containing BusyBox: .. image:: figures/perf-wget-busybox-expanded-stripped.png :align: center + :width: 70% Again, before we expanded we saw that the function was labeled with a hex value instead of a symbol as with most of the kernel entries. @@ -330,6 +334,7 @@ their functions symbolically: .. image:: figures/perf-wget-busybox-debuginfo.png :align: center + :width: 70% If we expand one of the entries and press 'enter' on a leaf node, we're presented with a menu of actions we can take to get more information @@ -337,6 +342,7 @@ related to that entry: .. image:: figures/perf-wget-busybox-dso-zoom-menu.png :align: center + :width: 70% One of these actions allows us to show a view that displays a busybox-centric view of the profiled functions (in this case we've also @@ -344,6 +350,7 @@ expanded all the nodes using the 'E' key): .. image:: figures/perf-wget-busybox-dso-zoom.png :align: center + :width: 70% Finally, we can see that now that the BusyBox debuginfo is installed, the previously unresolved symbol in the ``sys_clock_gettime()`` entry @@ -354,6 +361,7 @@ function: .. image:: figures/perf-wget-g-copy-to-user-expanded-debuginfo.png :align: center + :width: 70% At the lowest level of detail, we can dive down to the assembly level and see which instructions caused the most overhead in a function. @@ -362,6 +370,7 @@ with a menu: .. image:: figures/perf-wget-busybox-annotate-menu.png :align: center + :width: 70% Selecting 'Annotate udhcpc_main', we get a detailed listing of percentages by instruction for the udhcpc_main function. From the @@ -370,6 +379,7 @@ taken up by a couple tests and the move of a constant (1) to a register: .. image:: figures/perf-wget-busybox-annotate-udhcpc.png :align: center + :width: 70% As a segue into tracing, let's try another profile using a different counter, something other than the default 'cycles'. @@ -593,6 +603,7 @@ and tell perf to do a profile using it as the sampling event:: .. image:: figures/sched-wakeup-profile.png :align: center + :width: 70% The screenshot above shows the results of running a profile using sched:sched_switch tracepoint, which shows the relative costs of various @@ -740,7 +751,7 @@ entry/exit events we recorded:: root@crownbay:~# perf script -g python generated Python script: perf-script.py -The skeleton script simply creates a python function for each event type in the +The skeleton script simply creates a Python function for each event type in the perf.data file. The body of each function simply prints the event name along with its parameters. For example: @@ -859,7 +870,7 @@ goes a little way to support the idea mentioned previously that given the right kind of trace data, higher-level profiling-type summaries can be derived from it. -Documentation on using the `'perf script' python +Documentation on using the `'perf script' Python binding <https://linux.die.net/man/1/perf-script-python>`__. System-Wide Tracing and Profiling @@ -894,6 +905,7 @@ other processes running on the system as well: .. image:: figures/perf-systemwide.png :align: center + :width: 70% In the snapshot above, we can see callchains that originate in libc, and a callchain from Xorg that demonstrates that we're using a proprietary X @@ -911,6 +923,7 @@ record a profile:: .. image:: figures/perf-report-cycles-u.png :align: center + :width: 70% Notice in the screenshot above, we see only userspace entries ([.]) @@ -921,6 +934,7 @@ the entries associated with the libc-xxx.so DSO. .. image:: figures/perf-systemwide-libc.png :align: center + :width: 70% We can also use the system-wide -a switch to do system-wide tracing. Here we'll trace a couple of scheduler events:: @@ -1116,6 +1130,7 @@ callgraphs from starting a few programs during those 30 seconds: .. image:: figures/perf-probe-do_fork-profile.png :align: center + :width: 70% .. admonition:: Tying it Together @@ -1149,7 +1164,7 @@ section can be found here: - The `'perf script' manpage <https://linux.die.net/man/1/perf-script>`__. -- Documentation on using the `'perf script' python +- Documentation on using the `'perf script' Python binding <https://linux.die.net/man/1/perf-script-python>`__. - The top-level `perf(1) manpage <https://linux.die.net/man/1/perf>`__. @@ -1684,6 +1699,7 @@ events (or even one or more complete subsystems) to trace: .. image:: figures/kernelshark-choose-events.png :align: center + :width: 70% Note that these are exactly the same sets of events described in the previous trace events subsystem section, and in fact is where trace-cmd @@ -1699,6 +1715,7 @@ will turn into the 'Stop' button after the trace has started): .. image:: figures/kernelshark-output-display.png :align: center + :width: 70% Notice that the right-hand pane shows the exact trace-cmd command-line that's used to run the trace, along with the results of the trace-cmd @@ -1710,12 +1727,14 @@ detailed event listing below that: .. image:: figures/kernelshark-i915-display.png :align: center + :width: 70% Here's another example, this time a display resulting from tracing 'all events': .. image:: figures/kernelshark-all.png :align: center + :width: 70% The tool is pretty self-explanatory, but for more detailed information on navigating through the data, see the `kernelshark @@ -1974,6 +1993,7 @@ with profiling data: .. image:: figures/sysprof-copy-to-user.png :align: center + :width: 70% The left pane shows a list of functions and processes. Selecting one of those expands that function in the right pane, showing all its callees. @@ -1988,6 +2008,7 @@ in the perf display shown in the perf section of this page. .. image:: figures/sysprof-copy-from-user.png :align: center + :width: 70% Similarly, the above is a snapshot of the Sysprof display of a copy-from-user callchain. @@ -1999,6 +2020,7 @@ left pane. In this case, the lower pane is showing all the callers of .. image:: figures/sysprof-callers.png :align: center + :width: 70% Double-clicking on one of those functions will in turn change the focus to the selected function, and so on. diff --git a/poky/documentation/ref-manual/devtool-reference.rst b/poky/documentation/ref-manual/devtool-reference.rst index a1a8bcdc98..10ca70a2b3 100644 --- a/poky/documentation/ref-manual/devtool-reference.rst +++ b/poky/documentation/ref-manual/devtool-reference.rst @@ -126,8 +126,7 @@ common working area used across the tool. The following figure shows the workspace structure: .. image:: figures/build-workspace-directory.png - :align: center - :scale: 70% + :scale: 100% .. code-block:: none diff --git a/poky/documentation/ref-manual/structure.rst b/poky/documentation/ref-manual/structure.rst index 262b041ea6..12a085552f 100644 --- a/poky/documentation/ref-manual/structure.rst +++ b/poky/documentation/ref-manual/structure.rst @@ -261,7 +261,7 @@ OpenEmbedded build system creates it from ``local.conf.sample`` when you :ref:`structure-core-script`. The source ``local.conf.sample`` file used depends on the -``$TEMPLATECONF`` script variable, which defaults to ``meta-poky/conf/`` +:term:`TEMPLATECONF` script variable, which defaults to ``meta-poky/conf/`` when you are building from the Yocto Project development environment, and to ``meta/conf/`` when you are building from the OpenEmbedded-Core environment. Because the script variable points to the source of the @@ -278,7 +278,7 @@ file, it uses ``sed`` to substitute final .. note:: - You can see how the ``TEMPLATECONF`` variable is used by looking at the + You can see how the :term:`TEMPLATECONF` variable is used by looking at the ``scripts/oe-setup-builddir`` script in the :term:`Source Directory`. You can find the Yocto Project version of the ``local.conf.sample`` file in the ``meta-poky/conf`` directory. @@ -300,7 +300,7 @@ you ``source`` the top-level build environment setup script (i.e. :ref:`structure-core-script`). As with the ``local.conf`` file, the source ``bblayers.conf.sample`` -file used depends on the ``$TEMPLATECONF`` script variable, which +file used depends on the :term:`TEMPLATECONF` script variable, which defaults to ``meta-poky/conf/`` when you are building from the Yocto Project development environment, and to ``meta/conf/`` when you are building from the OpenEmbedded-Core environment. Because the script @@ -315,7 +315,7 @@ Once the build process gets the sample file, it uses ``sed`` to substitute final .. note:: - You can see how the ``TEMPLATECONF`` variable ``scripts/oe-setup-builddir`` + You can see how the :term:`TEMPLATECONF` variable is defined by the ``scripts/oe-setup-builddir`` script in the :term:`Source Directory`. You can find the Yocto Project version of the ``bblayers.conf.sample`` file in the ``meta-poky/conf/`` directory. diff --git a/poky/documentation/ref-manual/tasks.rst b/poky/documentation/ref-manual/tasks.rst index a2b8763e7c..cb08a75c90 100644 --- a/poky/documentation/ref-manual/tasks.rst +++ b/poky/documentation/ref-manual/tasks.rst @@ -522,7 +522,7 @@ scratch is guaranteed. Starts a shell in which an interactive Python interpreter allows you to interact with the BitBake build environment. From within this shell, you can directly examine and set bits from the data store and execute -functions as if within the BitBake environment. See the ":ref:`dev-manual/common-tasks:using a python development shell`" section in +functions as if within the BitBake environment. See the ":ref:`dev-manual/common-tasks:using a Python development shell`" section in the Yocto Project Development Tasks Manual for more information about using ``pydevshell``. diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst index f8808cc052..367b4674e2 100644 --- a/poky/documentation/ref-manual/variables.rst +++ b/poky/documentation/ref-manual/variables.rst @@ -3551,7 +3551,7 @@ system and gives an overview of their function and contents. For more information on :term:`INHERIT`, see the :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` configuration directive`" - section in the Bitbake User Manual. + section in the BitBake User Manual. :term:`INHERIT_DISTRO` Lists classes that will be inherited at the distribution level. It is @@ -4064,10 +4064,10 @@ system and gives an overview of their function and contents. statements add specific configurations to targeted machine types:: KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc" - KERNEL_FEATURES:append = "${KERNEL_EXTRA_FEATURES}" - KERNEL_FEATURES:append:qemuall = "cfg/virtio.scc" - KERNEL_FEATURES:append:qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc" - KERNEL_FEATURES:append:qemux86-64 = "cfg/sound.scc" + KERNEL_FEATURES:append = " ${KERNEL_EXTRA_FEATURES}" + KERNEL_FEATURES:append:qemuall = " cfg/virtio.scc" + KERNEL_FEATURES:append:qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc" + KERNEL_FEATURES:append:qemux86-64 = " cfg/sound.scc" :term:`KERNEL_FIT_LINK_NAME` The link name of the kernel flattened image tree (FIT) image. This @@ -4255,7 +4255,7 @@ system and gives an overview of their function and contents. SRCREV_machine:core2-32-intel-common = "43b9eced9ba8a57add36af07736344dcc383f711" KMACHINE:core2-32-intel-common = "intel-core2-32" KBRANCH:core2-32-intel-common = "standard/base" - KERNEL_FEATURES:append:core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON}" + KERNEL_FEATURES:append:core2-32-intel-common = " ${KERNEL_FEATURES_INTEL_COMMON}" The :term:`KMACHINE` statement says that the kernel understands the machine name as "intel-core2-32". @@ -7899,6 +7899,21 @@ system and gives an overview of their function and contents. toolchain. You can use ``meta-sourcery`` as a template for adding support for other external toolchains. + :term:`TEMPLATECONF` + Specifies the directory used by the build system to find templates + from which to build the ``bblayers.conf`` and ``local.conf`` files. + Use this variable if you wish to customize such files, and the default + BitBake targets shown when sourcing the ``oe-init-build-env`` script. + + For details, see the + :ref:`dev-manual/common-tasks:creating a custom template configuration directory` + section in the Yocto Project Development Tasks manual. + + .. note:: + + You must set this variable in the external environment in order + for it to work. + :term:`TEST_EXPORT_DIR` The location the OpenEmbedded build system uses to export tests when the :term:`TEST_EXPORT_ONLY` variable is set @@ -8752,6 +8767,19 @@ system and gives an overview of their function and contents. previous example, some-native-tool would be replaced with an actual native tool on which the build would depend. + :term:`WKS_FILES` + Specifies a list of candidate Wic kickstart files to be used by the + OpenEmbedded build system to create a partitioned image. Only the + first one that is found, from left to right, will be used. + + This is only useful when there are multiple ``.wks`` files that can be + used to produce an image. A typical case is when multiple layers are + used for different hardware platforms, each supplying a different + ``.wks`` file. In this case, you specify all possible ones through + :term:`WKS_FILES`. + + If only one ``.wks`` file is used, set :term:`WKS_FILE` instead. + :term:`WORKDIR` The pathname of the work directory in which the OpenEmbedded build system builds a recipe. This directory is located within the diff --git a/poky/documentation/releases.rst b/poky/documentation/releases.rst index cfc3a7b1de..08984b2b6b 100644 --- a/poky/documentation/releases.rst +++ b/poky/documentation/releases.rst @@ -16,6 +16,7 @@ Release Series 4.0 (kirkstone) ****************************** - :yocto_docs:`4.0 Documentation </4.0>` +- :yocto_docs:`4.0.1 Documentation </4.0.1>` ****************************** Release Series 3.4 (honister) @@ -25,6 +26,7 @@ Release Series 3.4 (honister) - :yocto_docs:`3.4.1 Documentation </3.4.1>` - :yocto_docs:`3.4.2 Documentation </3.4.2>` - :yocto_docs:`3.4.3 Documentation </3.4.3>` +- :yocto_docs:`3.4.4 Documentation </3.4.4>` ****************************** Release Series 3.3 (hardknott) @@ -58,6 +60,7 @@ Release Series 3.1 (dunfell) - :yocto_docs:`3.1.13 Documentation </3.1.13>` - :yocto_docs:`3.1.14 Documentation </3.1.14>` - :yocto_docs:`3.1.15 Documentation </3.1.15>` +- :yocto_docs:`3.1.16 Documentation </3.1.16>` ========================== Outdated Release Manuals diff --git a/poky/documentation/sdk-manual/appendix-obtain.rst b/poky/documentation/sdk-manual/appendix-obtain.rst index 841abac5aa..ece378c75e 100644 --- a/poky/documentation/sdk-manual/appendix-obtain.rst +++ b/poky/documentation/sdk-manual/appendix-obtain.rst @@ -265,8 +265,7 @@ install the Standard SDK by running the ``*.sh`` SDK installation script: .. image:: figures/sdk-installed-standard-sdk-directory.png - :scale: 80% - :align: center + :scale: 100% The installed SDK consists of an environment setup script for the SDK, a configuration file for the target, a version file for the target, and diff --git a/poky/documentation/sdk-manual/extensible.rst b/poky/documentation/sdk-manual/extensible.rst index c5970f74fa..6bb262273d 100644 --- a/poky/documentation/sdk-manual/extensible.rst +++ b/poky/documentation/sdk-manual/extensible.rst @@ -233,7 +233,7 @@ shows common development flows you would use with the ``devtool add`` command: .. image:: figures/sdk-devtool-add-flow.png - :align: center + :width: 100% 1. *Generating the New Recipe*: The top part of the flow shows three scenarios by which you could use ``devtool add`` to generate a recipe @@ -401,7 +401,7 @@ diagram shows common development flows for the ``devtool modify`` command: .. image:: figures/sdk-devtool-modify-flow.png - :align: center + :width: 100% 1. *Preparing to Modify the Code*: The top part of the flow shows three scenarios by which you could use ``devtool modify`` to prepare to @@ -620,7 +620,7 @@ The following diagram shows the common development flow used with the ``devtool upgrade`` command: .. image:: figures/sdk-devtool-upgrade-flow.png - :align: center + :width: 100% 1. *Initiate the Upgrade*: The top part of the flow shows the typical scenario by which you use the ``devtool upgrade`` command. The diff --git a/poky/documentation/sdk-manual/intro.rst b/poky/documentation/sdk-manual/intro.rst index 802d3f3d42..ce00538b2a 100644 --- a/poky/documentation/sdk-manual/intro.rst +++ b/poky/documentation/sdk-manual/intro.rst @@ -149,7 +149,7 @@ SDK Development Model Fundamentally, the SDK fits into the development process as follows: .. image:: figures/sdk-environment.png - :align: center + :width: 100% The SDK is installed on any machine and can be used to develop applications, images, and kernels. An SDK can even be used by a QA Engineer or Release diff --git a/poky/documentation/sdk-manual/working-projects.rst b/poky/documentation/sdk-manual/working-projects.rst index 276daa9bb6..efef5c8bd2 100644 --- a/poky/documentation/sdk-manual/working-projects.rst +++ b/poky/documentation/sdk-manual/working-projects.rst @@ -19,6 +19,7 @@ The following figure presents a simple Autotools workflow. .. image:: figures/sdk-autotools-flow.png :align: center + :width: 70% Follow these steps to create a simple Autotools-based "Hello World" project: @@ -168,6 +169,7 @@ variables and Makefile variables during development. .. image:: figures/sdk-makefile-flow.png :align: center + :width: 70% The main point of this section is to explain the following three cases regarding variable behavior: diff --git a/poky/documentation/set_versions.py b/poky/documentation/set_versions.py index cd02cc739e..c409d5ea86 100755 --- a/poky/documentation/set_versions.py +++ b/poky/documentation/set_versions.py @@ -23,7 +23,7 @@ ourversion = None if len(sys.argv) == 2: ourversion = sys.argv[1] -activereleases = ["kirkstone", "honister", "hardknott", "dunfell"] +activereleases = ["kirkstone", "honister", "dunfell"] devbranch = "langdale" ltsseries = ["kirkstone", "dunfell"] @@ -211,7 +211,7 @@ with open("sphinx-static/switchers.js.in", "r") as r, open("sphinx-static/switch w.write(str(list(release_series.keys()))) continue if "VERSIONS_PLACEHOLDER" in line: - w.write(" 'dev': { 'title': 'dev (%s)', 'obsolete': false,},\n" % release_series[devbranch]) + w.write(" 'dev': { 'title': 'Unstable (dev)', 'obsolete': false,},\n") for branch in activereleases + ([ourseries] if ourseries not in activereleases else []): if branch == devbranch: continue @@ -223,9 +223,9 @@ with open("sphinx-static/switchers.js.in", "r") as r, open("sphinx-static/switch if branch_versions[-1] != "0": version = version + "." + branch_versions[-1] versions.append(version) - w.write(" '%s': {'title': '%s', 'obsolete': %s,},\n" % (version, version, str(branch not in activereleases).lower())) + w.write(" '%s': {'title': '%s (%s)', 'obsolete': %s,},\n" % (version, branch.capitalize(), version, str(branch not in activereleases).lower())) if ourversion not in versions and ourseries != devbranch: - w.write(" '%s': {'title': '%s', 'obsolete': %s,},\n" % (ourversion, ourversion, str(ourseries not in activereleases).lower())) + w.write(" '%s': {'title': '%s (%s)', 'obsolete': %s,},\n" % (ourversion, ourseries.capitalize(), ourversion, str(ourseries not in activereleases).lower())) else: w.write(line) diff --git a/poky/documentation/sphinx/yocto-vars.py b/poky/documentation/sphinx/yocto-vars.py index 8795eee0a0..643c0df904 100644 --- a/poky/documentation/sphinx/yocto-vars.py +++ b/poky/documentation/sphinx/yocto-vars.py @@ -13,7 +13,7 @@ try: import yaml except ImportError: sys.stderr.write("The Yocto Project Sphinx documentation requires PyYAML.\ - \nPlease make sure to install pyyaml python package.\n") + \nPlease make sure to install pyyaml Python package.\n") sys.exit(1) __version__ = '1.0' diff --git a/poky/documentation/standards.md b/poky/documentation/standards.md index a2274f6d6e..81aff5f193 100644 --- a/poky/documentation/standards.md +++ b/poky/documentation/standards.md @@ -7,7 +7,29 @@ It is currently a work in progress. ## Text standards -This section has not been filled yet +### Project names + +Project names should be capitalized in the same +way they are on Wikipedia, in particular: + +* BitBake +* OpenEmbedded + +There are exceptions in which such names can be used +in lower case: + +* When referring to a package name +* When referring to the corresponding command name +* When used in a cross-reference title. Such + titles are usually in lower case. + +### File names + +File names should be quoted as in the below example: + + ``conf/local.conf`` + +Using "conf/local/conf" would be wrong. ## ReStructured Text Syntax standards @@ -26,8 +48,14 @@ To include a screenshot in PNG format: .. image:: figures/user-configuration.png :align: center -Depending on the size of the image, you may also shrink it -to prevent it from filling the whole page width: +A diagram with many details usually needs to use +the whole page width to be readable on all media. +In this case, the `:align:` directive is unnecessary: + + :scale: 100% + +Conversely, you may also shrink some images to +to prevent them from filling the whole page width: :scale: 50% diff --git a/poky/documentation/test-manual/intro.rst b/poky/documentation/test-manual/intro.rst index 9c1a93cd40..eb9ebe2d5f 100644 --- a/poky/documentation/test-manual/intro.rst +++ b/poky/documentation/test-manual/intro.rst @@ -72,7 +72,7 @@ simple JSON files. .. note:: The project uses Buildbot for historical reasons but also because - many of the project developers have knowledge of python. It is + many of the project developers have knowledge of Python. It is possible to use the outer layers from another Continuous Integration (CI) system such as `Jenkins <https://en.wikipedia.org/wiki/Jenkins_(software)>`__ @@ -83,6 +83,7 @@ topology that includes a controller and a cluster of workers: .. image:: figures/ab-test-cluster.png :align: center + :width: 70% Yocto Project Tests - Types of Testing Overview =============================================== @@ -335,12 +336,12 @@ A simple test example from ``lib/bb/tests/data.py`` is:: self.assertEqual(str(val), "value_of_foo") In this example, a ``DataExpansions`` class of tests is created, -derived from standard python unittest. The class has a common ``setUp`` +derived from standard Python unittest. The class has a common ``setUp`` function which is shared by all the tests in the class. A simple test is then added to test that when a variable is expanded, the correct value is found. -Bitbake selftests are straightforward python unittest. Refer to the +BitBake selftests are straightforward Python unittest. Refer to the Python unittest documentation for additional information on writing these tests at: https://docs.python.org/3/library/unittest.html. @@ -468,7 +469,7 @@ following:: In this example, if nativesdk-python3-core has been installed into the SDK, the code runs the python3 interpreter with a basic command to check it is working -correctly. The test would only run if python3 is installed in the SDK. +correctly. The test would only run if Python3 is installed in the SDK. ``oe-build-perf-test`` ---------------------- diff --git a/poky/documentation/toaster-manual/intro.rst b/poky/documentation/toaster-manual/intro.rst index 57e5b2bb7b..a324744b7d 100644 --- a/poky/documentation/toaster-manual/intro.rst +++ b/poky/documentation/toaster-manual/intro.rst @@ -92,6 +92,7 @@ suited for a single user developing on a single build host. .. image:: figures/simple-configuration.png :align: center + :width: 70% Toaster as a hosted service is suited for multiple users developing across several build hosts. When Toaster is set up as a hosted service, @@ -99,3 +100,4 @@ its components can be spread across several machines: .. image:: figures/hosted-service.png :align: center + :width: 50% diff --git a/poky/documentation/toaster-manual/setup-and-use.rst b/poky/documentation/toaster-manual/setup-and-use.rst index 1e1a314d66..72a15b5f2d 100644 --- a/poky/documentation/toaster-manual/setup-and-use.rst +++ b/poky/documentation/toaster-manual/setup-and-use.rst @@ -311,7 +311,7 @@ Perform the following steps to install Toaster: migrations). The next line sets the Toaster root directory ``TOASTER_DIR`` and the location of the Toaster configuration file ``TOASTER_CONF``, which is relative to ``TOASTER_DIR``. The - ``TEMPLATECONF`` value reflects the contents of + :term:`TEMPLATECONF` value reflects the contents of ``poky/.templateconf``, and by default, should include the string "poky". For more information on the Toaster configuration file, see the ":ref:`toaster-manual/reference:Configuring Toaster`" section. diff --git a/poky/documentation/toaster-manual/start.rst b/poky/documentation/toaster-manual/start.rst index cab5d1f673..2d6474852a 100644 --- a/poky/documentation/toaster-manual/start.rst +++ b/poky/documentation/toaster-manual/start.rst @@ -40,7 +40,7 @@ command:: $ pip3 install --user -r bitbake/toaster-requirements.txt The previous command installs the necessary Toaster modules into a local -python 3 cache in your ``$HOME`` directory. The caches is actually +Python 3 cache in your ``$HOME`` directory. The caches is actually located in ``$HOME/.local``. To see what packages have been installed into your ``$HOME`` directory, do the following:: diff --git a/poky/documentation/what-i-wish-id-known.rst b/poky/documentation/what-i-wish-id-known.rst index dec5617173..46c5cf19f9 100644 --- a/poky/documentation/what-i-wish-id-known.rst +++ b/poky/documentation/what-i-wish-id-known.rst @@ -98,6 +98,7 @@ contact us with other suggestions. be going wrong. .. image:: figures/yp-how-it-works-new-diagram.png + :width: 100% #. **Know that you can generate a dependency graph and learn how to do it:** A dependency graph shows dependencies between recipes, tasks, and targets. @@ -179,7 +180,7 @@ contact us with other suggestions. * understand devtool and how it simplifies your workflow * improve build speeds with shared downloads and shared state cache * generate and understand a dependency graph - * generate and understand bitbake environment + * generate and understand BitBake environment * build an Extensible SDK for applications development #. **Depending on what you primary interests are with the Yocto Project, you |