diff options
| author | Andrew Geissler <geissonator@yahoo.com> | 2021-04-15 23:55:55 +0300 |
|---|---|---|
| committer | Brad Bishop <bradleyb@fuzziesquirrel.com> | 2021-04-19 16:32:18 +0300 |
| commit | 3b8a17c1d70bac29dd3f1fb727716b7c2151b64a (patch) | |
| tree | cc03ed84987f273db964a019f862b08a131d67fa /poky | |
| parent | e34f89623c246d261efb7fd0f2ce4a30b10bd59d (diff) | |
| download | openbmc-3b8a17c1d70bac29dd3f1fb727716b7c2151b64a.tar.xz | |
poky: subtree update:7d0988966c..1203d1f24d
Alexander Kanavin (5):
mesa: update 21.0.0 -> 21.0.1
runqemu: do not stop processing graphical options after nographic
mesa: gallium option requires libdrm
mesa: enable dri in native/nativesdk through gallium drivers
ptest-runner: correct version check
Alistair Francis (2):
conf/machine: Enable bochs-display on RISC-V machines
conf/machine: Enable keyboard and mouse on RISC-V machines
Anibal Limon (1):
ptest-runner: Upgrade to 2.4.1
Awais Belal (2):
perl: allow empty lines and comments in perl-rdepends.txt
perl: fix creation and generate new perl-rdepends.txt
Bruce Ashfield (1):
perf-tests: add bash into RDEPENDS (v5.12-rc5+)
Chen Qi (1):
apt: Fix do_compile error when enable ccache
Denys Dmytriyenko (1):
make-mod-scripts: pass CROSS_COMPILE to configure and build
Guillaume Champagne (1):
image-live.bbclass: optional depends when ROOTFS empty
Janne Kiiskila (1):
poky.yaml: Use git instead of git-core for Ubunti
Joshua Watt (1):
bitbake.conf: Limit the number of OpenMP threads
Khem Raj (3):
mesa-gl: Use swrast gallium driver
binutils: Fix a missing break in case statement
webkitgtk: Drop include_array.patch
Klaus Heinrich Kiwi (6):
uboot: Deploy default symlinks with fitImage
u-boot: Move definitions to common locations
u-boot: Add infrastructure to SPL verified boot
u-boot: Use a different Key for SPL signing
oe-selftest: Add U-Boot fitImage signing testcases
uboot: Fixes SPL verified boot on corner cases
Matt Madison (1):
libxcb: use PN for naming dynamic packages
Michael Halstead (1):
releases: update to include 3.2.3
Michael Opdenacker (7):
manuals: Spellcheck and capitalization fixes
SDK manual: fix reference to appendix
Quick build: checkout a branch instead of a fixed tag
manuals: Fix typos and spacing
overview-manual: style improvements
ref-manual: fix typo
manuals: fix suspicious newlines
Nicolas Dechesne (1):
docs: add a top level page for bitbake documentation
Paul Eggleton (16):
bitbake: bitbake-user-manual: document no support for using passwords in git URLs
bitbake: bitbake-user-manual: add REQUIRED_VERSION and adjust PREFERRED_VERSION entry
ref-manual: add METADATA_REVISION and METADATA_BRANCH
Use variables for minimum host versions and bump Python to 3.6
ref-manual: update/fix text for SDK_VERSION
overview-manual: fix git command line
ref-manual: and SDK_CUSTOM_TEMPLATECONF to glossary
ref-manual: add REQUIRED_VERSION and adjust PREFERRED_VERSION entry
ref-manual: add python3targetconfig class and remove python 2 references
ref-manual: add passwd-expire to EXTRA_USERS_PARAMS
ref-manual: add FIT_KERNEL_COMP_ALG*
ref-manual: fix reference to build-essential
ref-manual: tweak buildtools section
ref-manual: add migration section for 3.3 release
ref-manual: migration guide: add release codenames
ref-manual: add mention of DISTUTILS_SETUP_PATH
Quentin Schulz (1):
docs: replace anchor links
Richard Purdie (9):
oeqa/concurrencytest: Rename variables to improve the code
oeqa/concurrencytest: Fix display of test stdout/stderr
diffoscope: Upgrade 168 -> 172
oeqa/runqemu: Support RUNQEMU_TMPFS_DIR as a location to copy snapshot images to
bitbake: runqueue: Further fixes for confused setscene tasks
documentation/poky.yaml: Fix latest 3.2 series tag reference
poky.conf: Bump version for 3.3 hardknott release
build-appliance-image: Update to master head revision
bitbake: bitbake: Update version to 1.50.0 stable release series
Ross Burton (2):
poky.yaml: change gcc-multilib to gcc
oeqa/selftest: add test case for SRC_URI dependency sniffing
Ulrich Ölmann (1):
sdk-manual: fix typo
Yann Dirson (1):
kernel-yocto: fix do_kernel_configme indentation
Yi Fan Yu (2):
python3: Skip failing ptests due to load variability
valgrind: print failed ptest details
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: Id57d0682ec91b67b90fac931313457f5ed6f3d5c
Diffstat (limited to 'poky')
103 files changed, 2062 insertions, 881 deletions
diff --git a/poky/bitbake/bin/bitbake b/poky/bitbake/bin/bitbake index bc762bfc1..712755087 100755 --- a/poky/bitbake/bin/bitbake +++ b/poky/bitbake/bin/bitbake @@ -26,7 +26,7 @@ from bb.main import bitbake_main, BitBakeConfigParameters, BBMainException if sys.getfilesystemencoding() != "utf-8": sys.exit("Please use a locale setting which supports UTF-8 (such as LANG=en_US.UTF-8).\nPython can't change the filesystem locale after loading so we need a UTF-8 when Python starts or things won't work.") -__version__ = "1.49.2" +__version__ = "1.50.0" if __name__ == "__main__": if __version__ != bb.__version__: diff --git a/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst b/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst index e9a5f336d..bd6cc0ef2 100644 --- a/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst +++ b/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst @@ -441,6 +441,15 @@ Here are some example URLs: :: SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1" SRC_URI = "git://git.oe.handhelds.org/git/vip.git;protocol=http" +.. note:: + + Specifying passwords directly in ``git://`` urls is not supported. + There are several reasons: ``SRC_URI`` is often written out to logs and + other places, and that could easily leak passwords; it is also all too + easy to share metadata without removing passwords. SSH keys, ``~/.netrc`` + and ``~/.ssh/config`` files can be used as alternatives. + + .. _gitsm-fetcher: Git Submodule Fetcher (``gitsm://``) diff --git a/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst b/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst index 1528b0406..489fa15fa 100644 --- a/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst +++ b/poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst @@ -1096,8 +1096,8 @@ overview of their function and contents. PREFERRED_PROVIDER_aaa = "bbb" :term:`PREFERRED_VERSION` - If there are multiple versions of recipes available, this variable - determines which recipe should be given preference. You must always + If there are multiple versions of a recipe available, this variable + determines which version should be given preference. You must always suffix the variable with the :term:`PN` you want to select, and you should set :term:`PV` accordingly for precedence. @@ -1117,6 +1117,10 @@ overview of their function and contents. end of the string. You cannot use the wildcard character in any other location of the string. + If a recipe with the specified version is not available, a warning + message will be shown. See :term:`REQUIRED_VERSION` if you want this + to be an error instead. + :term:`PREMIRRORS` Specifies additional paths from which BitBake gets source code. When the build system searches for source code, it first tries the local @@ -1227,6 +1231,16 @@ overview of their function and contents. The directory in which a local copy of a ``google-repo`` directory is stored when it is synced. + :term:`REQUIRED_VERSION` + If there are multiple versions of a recipe available, this variable + determines which version should be given preference. ``REQUIRED_VERSION`` + works in exactly the same manner as :term:`PREFERRED_VERSION`, except + that if the specified version is not available then an error message + is shown and the build fails immediately. + + If both ``REQUIRED_VERSION`` and ``PREFERRED_VERSION`` are set for + the same recipe, the ``REQUIRED_VERSION`` value applies. + :term:`RPROVIDES` A list of package name aliases that a package also provides. These aliases are useful for satisfying runtime dependencies of other diff --git a/poky/bitbake/lib/bb/__init__.py b/poky/bitbake/lib/bb/__init__.py index afce5ccb8..9f61dae14 100644 --- a/poky/bitbake/lib/bb/__init__.py +++ b/poky/bitbake/lib/bb/__init__.py @@ -9,7 +9,7 @@ # SPDX-License-Identifier: GPL-2.0-only # -__version__ = "1.49.2" +__version__ = "1.50.0" import sys if sys.version_info < (3, 5, 0): diff --git a/poky/bitbake/lib/bb/runqueue.py b/poky/bitbake/lib/bb/runqueue.py index 80d7f6ca6..cd56a5547 100644 --- a/poky/bitbake/lib/bb/runqueue.py +++ b/poky/bitbake/lib/bb/runqueue.py @@ -2457,6 +2457,9 @@ class RunQueueExecute: if dep in self.scenequeue_covered or dep in self.scenequeue_notcovered: # dependency could be already processed, e.g. noexec setscene task continue + noexec, stamppresent = check_setscene_stamps(dep, self.rqdata, self.rq, self.stampcache) + if noexec or stamppresent: + continue logger.debug2("%s was unavailable and is a hard dependency of %s so skipping" % (task, dep)) self.sq_task_failoutright(dep) continue @@ -2795,6 +2798,26 @@ def build_scenequeue_data(sqdata, rqdata, rq, cooker, stampcache, sqrq): event = bb.event.StaleSetSceneTasks(found[mc]) bb.event.fire(event, cooker.databuilder.mcdata[mc]) +def check_setscene_stamps(tid, rqdata, rq, stampcache, noexecstamp=False): + + (mc, fn, taskname, taskfn) = split_tid_mcfn(tid) + + taskdep = rqdata.dataCaches[mc].task_deps[taskfn] + + if 'noexec' in taskdep and taskname in taskdep['noexec']: + bb.build.make_stamp(taskname + "_setscene", rqdata.dataCaches[mc], taskfn) + return True, False + + if rq.check_stamp_task(tid, taskname + "_setscene", cache=stampcache): + logger.debug2('Setscene stamp current for task %s', tid) + return False, True + + if rq.check_stamp_task(tid, taskname, recurse = True, cache=stampcache): + logger.debug2('Normal stamp current for task %s', tid) + return False, True + + return False, False + def update_scenequeue_data(tids, sqdata, rqdata, rq, cooker, stampcache, sqrq, summary=True): tocheck = set() @@ -2805,24 +2828,14 @@ def update_scenequeue_data(tids, sqdata, rqdata, rq, cooker, stampcache, sqrq, s if tid in sqdata.valid: sqdata.valid.remove(tid) - (mc, fn, taskname, taskfn) = split_tid_mcfn(tid) - - taskdep = rqdata.dataCaches[mc].task_deps[taskfn] + noexec, stamppresent = check_setscene_stamps(tid, rqdata, rq, stampcache, noexecstamp=True) - if 'noexec' in taskdep and taskname in taskdep['noexec']: + if noexec: sqdata.noexec.add(tid) sqrq.sq_task_skip(tid) - bb.build.make_stamp(taskname + "_setscene", rqdata.dataCaches[mc], taskfn) - continue - - if rq.check_stamp_task(tid, taskname + "_setscene", cache=stampcache): - logger.debug2('Setscene stamp current for task %s', tid) - sqdata.stamppresent.add(tid) - sqrq.sq_task_skip(tid) continue - if rq.check_stamp_task(tid, taskname, recurse = True, cache=stampcache): - logger.debug2('Normal stamp current for task %s', tid) + if stamppresent: sqdata.stamppresent.add(tid) sqrq.sq_task_skip(tid) continue diff --git a/poky/documentation/README b/poky/documentation/README index 159ec9460..176c6db35 100644 --- a/poky/documentation/README +++ b/poky/documentation/README @@ -109,7 +109,7 @@ obvious reasons, we will only support building the Yocto Project documentation with Python3. Sphinx might be available in your Linux distro packages repositories, -however it is not recommend to use distro packages, as they might be +however it is not recommended to use distro packages, as they might be old versions, especially if you are using an LTS version of your distro. The recommended method to install Sphinx and all required dependencies is to use the Python Package Index (pip). @@ -259,6 +259,9 @@ websites. More information can be found here: https://sublime-and-sphinx-guide.readthedocs.io/en/latest/references.html. +Anchor (<#link>) links are forbidden as they are not checked by Sphinx during +the build and may be broken without knowing about it. + References ========== diff --git a/poky/documentation/bitbake.rst b/poky/documentation/bitbake.rst new file mode 100644 index 000000000..7702f9322 --- /dev/null +++ b/poky/documentation/bitbake.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK + +===================== +BitBake Documentation +===================== + +| + +BitBake was originally a part of the OpenEmbedded project. It was inspired by +the Portage package management system used by the Gentoo Linux distribution. In +2004, the OpenEmbedded project was split the project into two distinct pieces: + +- BitBake, a generic task executor +- OpenEmbedded, a metadata set utilized by BitBake + +Today, BitBake is the primary build tool of OpenEmbedded based projects, such as +the Yocto Project. + +The BitBake documentation can be found :doc:`here <bitbake:index>`. diff --git a/poky/documentation/boilerplate.rst b/poky/documentation/boilerplate.rst index 2ad60eb8b..baccc9fe4 100644 --- a/poky/documentation/boilerplate.rst +++ b/poky/documentation/boilerplate.rst @@ -14,5 +14,5 @@ Commons. To report any inaccuracies or problems with this (or any other Yocto Project) manual, or to send additions or changes, please send email/patches to the Yocto Project documentation mailing list at ``docs@lists.yoctoproject.org`` or -log into the freenode ``#yocto`` channel. +log into the Freenode ``#yocto`` channel. diff --git a/poky/documentation/brief-yoctoprojectqs/index.rst b/poky/documentation/brief-yoctoprojectqs/index.rst index 4ac222c7e..974ae5ebc 100644 --- a/poky/documentation/brief-yoctoprojectqs/index.rst +++ b/poky/documentation/brief-yoctoprojectqs/index.rst @@ -60,10 +60,10 @@ following requirements: - - - Git 1.8.3.1 or greater - - tar 1.28 or greater - - Python 3.5.0 or greater. - - gcc 5.0 or greater. + - Git &MIN_GIT_VERSION; or greater + - tar &MIN_TAR_VERSION; or greater + - Python &MIN_PYTHON_VERSION; or greater. + - gcc &MIN_GCC_VERSION; or greater. If your build host does not meet any of these three listed version requirements, you can take steps to prepare the system so that you @@ -106,42 +106,57 @@ commands to clone the Poky repository. Resolving deltas: 100% (323116/323116), done. Checking connectivity... done. -Move to the ``poky`` directory and take a look at the tags: +Go to :yocto_wiki:`Releases wiki page </Releases>`, and choose a release +codename (such as ``&DISTRO_NAME_NO_CAP;``), corresponding to either the +latest stable release or a Long Term Support release. + +Then move to the ``poky`` directory and take a look at existing branches: .. code-block:: shell $ cd poky - $ git fetch --tags - $ git tag - 1.1_M1.final - 1.1_M1.rc1 - 1.1_M1.rc2 - 1.1_M2.final - 1.1_M2.rc1 + $ git branch -a + . + . + . + remotes/origin/HEAD -> origin/master + remotes/origin/dunfell + remotes/origin/dunfell-next + . + . + . + remotes/origin/gatesgarth + remotes/origin/gatesgarth-next + . . . + remotes/origin/master + remotes/origin/master-next . - yocto-2.5 - yocto-2.5.1 - yocto-2.5.2 - yocto-2.6 - yocto-2.6.1 - yocto-2.6.2 - yocto-2.7 - yocto_1.5_M5.rc8 - -For this example, check out the branch based on the -``&DISTRO_REL_TAG;`` release: + . + . + + +For this example, check out the ``&DISTRO_NAME_NO_CAP;`` branch based on the +``&DISTRO_NAME;`` release: .. code-block:: shell - $ git checkout tags/&DISTRO_REL_TAG; -b my-&DISTRO_REL_TAG; - Switched to a new branch 'my-&DISTRO_REL_TAG;' + $ git checkout -t origin/&DISTRO_NAME_NO_CAP; -b my-&DISTRO_NAME_NO_CAP; + Branch 'my-&DISTRO_NAME_NO_CAP;' set up to track remote branch '&DISTRO_NAME_NO_CAP;' from 'origin'. + Switched to a new branch 'my-&DISTRO_NAME_NO_CAP;' The previous Git checkout command creates a local branch named -``my-&DISTRO_REL_TAG;``. The files available to you in that branch exactly -match the repository's files in the ``&DISTRO_NAME_NO_CAP;`` development -branch at the time of the Yocto Project &DISTRO_REL_TAG; release. +``my-&DISTRO_NAME_NO_CAP;``. The files available to you in that branch +exactly match the repository's files in the ``&DISTRO_NAME_NO_CAP;`` +release branch. + +Note that you can regularly type the following command in the same directory +to keep your local files in sync with the release branch: + +.. code-block:: shell + + $ git pull For more options and information about accessing Yocto Project related repositories, see the @@ -204,7 +219,7 @@ an entire Linux distribution, including the toolchain, from source. meta-toolchain meta-ide-support - You can also run generated qemu images with a command like 'runqemu qemux86-64' + You can also run generated QEMU images with a command like 'runqemu qemux86-64' Among other things, the script creates the :term:`Build Directory`, which is ``build`` in this case and is located in the :term:`Source Directory`. After diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst index 93e918249..89f156442 100644 --- a/poky/documentation/bsp-guide/bsp.rst +++ b/poky/documentation/bsp-guide/bsp.rst @@ -250,7 +250,7 @@ standardization of software support for hardware. The proposed form described in this section does have elements that are specific to the OpenEmbedded build system. It is intended that developers can use this structure with other build systems besides the -OpenEmbedded build system. It is also intended that it will be be simple +OpenEmbedded build system. It is also intended that it will be simple to extract information and convert it to other formats if required. The OpenEmbedded build system, through its standard :ref:`layers mechanism <overview-manual/yp-intro:the yocto project layer model>`, can @@ -289,7 +289,7 @@ individual BSPs could differ. :: meta-bsp_root_name/recipes-kernel/linux/linux-yocto_kernel_rev.bbappend Below is an example of the Raspberry Pi BSP layer that is available from -the :yocto_git:`Source Respositories <>`: +the :yocto_git:`Source Repositories <>`: .. code-block:: none @@ -1036,7 +1036,7 @@ the following: to reside in a machine-specific directory. Following is a specific example to help you better understand the -process. This example customizes customizes a recipe by adding a +process. This example customizes a recipe by adding a BSP-specific configuration file named ``interfaces`` to the ``init-ifupdown_1.0.bb`` recipe for machine "xyz" where the BSP layer also supports several other machines: diff --git a/poky/documentation/dev-manual/common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst index 4313d905c..176025f9e 100644 --- a/poky/documentation/dev-manual/common-tasks.rst +++ b/poky/documentation/dev-manual/common-tasks.rst @@ -155,8 +155,8 @@ Follow these general steps to create your layer without using tools: 5. *Optionally Test for Compatibility:* If you want permission to use the Yocto Project Compatibility logo with your layer or application that uses your layer, perform the steps to apply for compatibility. - See the "`Making Sure Your Layer is Compatible With Yocto - Project <#making-sure-your-layer-is-compatible-with-yocto-project>`__" + See the + ":ref:`dev-manual/common-tasks:making sure your layer is compatible with yocto project`" section for more information. Following Best Practices When Creating Layers @@ -282,9 +282,8 @@ following list: - *Perform Steps to Apply for Yocto Project Compatibility:* If you want permission to use the Yocto Project Compatibility logo with your layer or application that uses your layer, perform the steps to apply - for compatibility. See the "`Making Sure Your Layer is Compatible - With Yocto - Project <#making-sure-your-layer-is-compatible-with-yocto-project>`__" + for compatibility. See the + ":ref:`dev-manual/common-tasks:making sure your layer is compatible with yocto project`" section for more information. - *Follow the Layer Naming Convention:* Store custom layers in a Git @@ -1247,8 +1246,7 @@ the recipe. your layer such that it can be found. You can find more information on how layers are structured in the - "`Understanding and Creating - Layers <#understanding-and-creating-layers>`__" section. + ":ref:`dev-manual/common-tasks:understanding and creating layers`" section. - *Naming Your Recipe:* When you name your recipe, you need to follow this naming convention: @@ -1364,7 +1362,7 @@ extension (e.g. ``.tar``, ``.tar.gz``, ``.tar.bz2``, ``.zip``, and so forth), are automatically extracted during the :ref:`ref-tasks-unpack` task. For another example that specifies these types of files, see the -"`Autotooled Package <#new-recipe-autotooled-package>`__" section. +":ref:`dev-manual/common-tasks:autotooled package`" section. Another way of specifying source is from an SCM. For Git repositories, you must specify :term:`SRCREV` and @@ -1445,15 +1443,14 @@ and searches specific directories in a certain order: ``${``\ :term:`BPN`\ ``}``, and ``files``. The directories are assumed to be subdirectories of the directory in which the recipe or append file resides. For another -example that specifies these types of files, see the "`Single .c File -Package (Hello -World!) <#new-recipe-single-c-file-package-hello-world>`__" section. +example that specifies these types of files, see the +":ref:`dev-manual/common-tasks:single .c file package (hello world!)`" section. The previous example also specifies a patch file. Patch files are files whose names usually end in ``.patch`` or ``.diff`` but can end with compressed suffixes such as ``diff.gz`` and ``patch.bz2``, for example. The build system automatically applies patches as described in the -"`Patching Code <#new-recipe-patching-code>`__" section. +":ref:`dev-manual/common-tasks:patching code`" section. Unpacking Code -------------- @@ -1543,7 +1540,7 @@ variables: appropriate files in the ``LIC_FILES_CHKSUM`` variable with incorrect md5 strings, attempt to build the software, and then note the resulting error messages that will report the correct md5 strings. - See the "`Fetching Code <#new-recipe-fetching-code>`__" section for + See the ":ref:`dev-manual/common-tasks:fetching code`" section for additional information. Here is an example that assumes the software has a ``COPYING`` file: @@ -1787,8 +1784,8 @@ Here are some common issues that cause failures. PARALLEL_MAKE = "" - For information on parallel Makefile issues, see the "`Debugging - Parallel Make Races <#debugging-parallel-make-races>`__" section. + For information on parallel Makefile issues, see the + ":ref:`dev-manual/common-tasks:debugging parallel make races`" section. - *Improper host path usage:* This failure applies to recipes building for the target or ``nativesdk`` only. The failure occurs when the @@ -1854,8 +1851,7 @@ the software being built: ``PREFIX=${D}``, ``INSTALLROOT=${D}``, and so forth). For an example recipe using ``make install``, see the - "`Makefile-Based Package <#new-recipe-makefile-based-package>`__" - section. + ":ref:`dev-manual/common-tasks:makefile-based package`" section. - *Manual:* You need to define a ``do_install`` function in your recipe. The function must first use ``install -d`` to create the @@ -1990,14 +1986,13 @@ take. The following list describes the process: ``do_install(_append)``, and so forth as needed. - *Splitting an Application into Multiple Packages*: If you need to - split an application into several packages, see the "`Splitting an - Application into Multiple - Packages <#splitting-an-application-into-multiple-packages>`__" + split an application into several packages, see the + ":ref:`dev-manual/common-tasks:splitting an application into multiple packages`" section for an example. - *Installing a Post-Installation Script*: For an example showing how - to install a post-installation script, see the "`Post-Installation - Scripts <#new-recipe-post-installation-scripts>`__" section. + to install a post-installation script, see the + ":ref:`dev-manual/common-tasks:post-installation scripts`" section. - *Marking Package Architecture*: Depending on what your recipe is building and how it is configured, it might be important to mark the @@ -2061,16 +2056,12 @@ sysroot are cataloged in manifests in order to ensure the files can be removed later when a recipe is either modified or removed. Thus, the sysroot is able to remain free from stale files. -A subset of the files installed by the -:ref:`ref-tasks-install` task are -used by the -:ref:`ref-tasks-populate_sysroot` -task as defined by the the -:term:`SYSROOT_DIRS` variable to -automatically populate the sysroot. It is possible to modify the list of -directories that populate the sysroot. The following example shows how -you could add the ``/opt`` directory to the list of directories within a -recipe: +A subset of the files installed by the :ref:`ref-tasks-install` task are +used by the :ref:`ref-tasks-populate_sysroot` task as defined by the the +:term:`SYSROOT_DIRS` variable to automatically populate the sysroot. It +is possible to modify the list of directories that populate the sysroot. +The following example shows how you could add the ``/opt`` directory to +the list of directories within a recipe: :: SYSROOT_DIRS += "/opt" @@ -2081,8 +2072,7 @@ recipe: that are not included in the target filesystem, allowing them to share these artifacts without needing to use the ``DEPLOY_DIR``. -For a more complete description of the -:ref:`ref-tasks-populate_sysroot` +For a more complete description of the :ref:`ref-tasks-populate_sysroot` task and its associated functions, see the :ref:`staging <ref-classes-staging>` class. @@ -2177,9 +2167,8 @@ Properly Versioning Pre-Release Recipes Sometimes the name of a recipe can lead to versioning problems when the recipe is upgraded to a final release. For example, consider the ``irssi_0.8.16-rc1.bb`` recipe file in the list of example recipes in -the "`Storing and Naming the -Recipe <#new-recipe-storing-and-naming-the-recipe>`__" section. This -recipe is at a release candidate stage (i.e. "rc1"). When the recipe is +the ":ref:`dev-manual/common-tasks:storing and naming the recipe`" section. +This recipe is at a release candidate stage (i.e. "rc1"). When the recipe is released, the recipe filename becomes ``irssi_0.8.16.bb``. The version change from ``0.8.16-rc1`` to ``0.8.16`` is seen as a decrease by the build system and package managers, so the resulting packages will not @@ -2263,8 +2252,7 @@ software you built runs correctly. To accomplish runtime testing, add the build's output packages to your image and test them on the target. For information on how to customize your image by adding specific -packages, see the "`Customizing -Images <#usingpoky-extend-customimage>`__" section. +packages, see ":ref:`dev-manual/common-tasks:customizing images`" section. Examples -------- @@ -2314,8 +2302,8 @@ directory BitBake uses for the build. By default, the ``helloworld``, ``helloworld-dbg``, and ``helloworld-dev`` packages are built. For information on how to -customize the packaging process, see the "`Splitting an Application into -Multiple Packages <#splitting-an-application-into-multiple-packages>`__" +customize the packaging process, see the +":ref:`dev-manual/common-tasks:splitting an application into multiple packages`" section. Autotooled Package @@ -3428,9 +3416,8 @@ Follow these general steps: 1. *Find the Source Code:* Temporary source code used by the OpenEmbedded build system is kept in the :term:`Build Directory`. See the - "`Finding Temporary Source - Code <#finding-the-temporary-source-code>`__" section to learn how to - locate the directory that has the temporary source code for a + ":ref:`dev-manual/common-tasks:finding temporary source code`" section to + learn how to locate the directory that has the temporary source code for a particular package. 2. *Change Your Working Directory:* You need to be in the directory that @@ -3999,24 +3986,21 @@ perform to create distributions with smaller root filesystems, achieve faster boot times, maintain your critical functionality, and avoid initial RAM disks: -- `Determine your goals and guiding - principles. <#goals-and-guiding-principles>`__ +- :ref:`Determine your goals and guiding principles + <dev-manual/common-tasks:goals and guiding principles>` -- `Understand what contributes to your image - size. <#understand-what-gives-your-image-size>`__ +- :ref:`dev-manual/common-tasks:understand what contributes to your image size` -- `Reduce the size of the root - filesystem. <#trim-the-root-filesystem>`__ +- :ref:`Reduce the size of the root filesystem + <dev-manual/common-tasks:trim the root filesystem>` -- `Reduce the size of the kernel. <#trim-the-kernel>`__ +- :ref:`Reduce the size of the kernel <dev-manual/common-tasks:trim the kernel>` -- `Eliminate packaging - requirements. <#remove-package-management-requirements>`__ +- :ref:`dev-manual/common-tasks:remove package management requirements` -- `Look for other ways to minimize - size. <#look-for-other-ways-to-minimize-size>`__ +- :ref:`dev-manual/common-tasks:look for other ways to minimize size` -- `Iterate on the process. <#iterate-on-the-process>`__ +- :ref:`dev-manual/common-tasks:iterate on the process` Goals and Guiding Principles ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -4036,8 +4020,8 @@ very small distributions: - Leverage the device-specific options. - Work in a separate layer so that you keep changes isolated. For - information on how to create layers, see the "`Understanding and - Creating Layers <#understanding-and-creating-layers>`__" section. + information on how to create layers, see the + ":ref:`dev-manual/common-tasks:understanding and creating layers`" section. Understand What Contributes to Your Image Size ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -4581,17 +4565,17 @@ directory: If you do have recipes that use ``AUTOREV``, you can take steps to still use the recipes in an offline build. Do the following: - 1. Use a configuration generated by enabling `build - history <#maintaining-build-output-quality>`__. + 1. Use a configuration generated by enabling :ref:`build + history <dev-manual/common-tasks:maintaining build output quality>`. 2. Use the ``buildhistory-collect-srcrevs`` command to collect the stored ``SRCREV`` values from the build's history. For more - information on collecting these values, see the "`Build History - Package Information <#build-history-package-information>`__" + information on collecting these values, see the + ":ref:`dev-manual/common-tasks:build history package information`" section. 3. Once you have the correct source revisions, you can modify - those recipes to to set ``SRCREV`` to specific versions of the + those recipes to set ``SRCREV`` to specific versions of the software. Speeding Up a Build @@ -4711,16 +4695,16 @@ Libraries are an integral part of your system. This section describes some common practices you might find helpful when working with libraries to build your system: -- `How to include static library - files <#including-static-library-files>`__ +- :ref:`How to include static library files + <dev-manual/common-tasks:including static library files>` -- `How to use the Multilib feature to combine multiple versions of - library files into a single - image <#combining-multiple-versions-library-files-into-one-image>`__ +- :ref:`How to use the Multilib feature to combine multiple versions of + library files into a single image + <dev-manual/common-tasks:combining multiple versions of library files into one image>` -- `How to install multiple versions of the same library in parallel on - the same - system <#installing-multiple-versions-of-the-same-library>`__ +- :ref:`How to install multiple versions of the same library in parallel on + the same system + <dev-manual/common-tasks:installing multiple versions of the same library>` Including Static Library Files ------------------------------ @@ -5058,7 +5042,7 @@ because the library is produced for the target architecture, but its code needs to be executed on the build host. This problem is solved with the OpenEmbedded build system by running the code through QEMU, which allows precisely that. Unfortunately, QEMU does not always work -perfectly as mentioned in the "`Known Issues <#known-issues>`__" +perfectly as mentioned in the ":ref:`dev-manual/common-tasks:known issues`" section. Enabling the Generation of Introspection Data @@ -5230,11 +5214,11 @@ OpenEmbedded build artifacts. Image generation is driven by partitioning 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 "`Using an Existing Kickstart -File <#using-a-provided-kickstart-file>`__" section. When you apply the -command to a given set of build artifacts, the result is an image or set -of images that can be directly written onto media and used on a -particular system. +in the +":ref:`dev-manual/common-tasks:generate an image using an existing kickstart file`" +section. When you apply the command to a given set of build artifacts, the +result is an image or set of images that can be directly written onto media and +used on a particular system. .. note:: @@ -5245,8 +5229,8 @@ particular system. The ``wic`` command and the infrastructure it is based on is by definition incomplete. The purpose of the command is to allow the generation of customized images, and as such, was designed to be -completely extensible through a plugin interface. See the "`Using the -Wic PlugIn Interface <#wic-using-the-wic-plugin-interface>`__" section +completely extensible through a plugin interface. See the +":ref:`dev-manual/common-tasks:using the wic plugin interface`" section for information on these plugins. This section provides some background information on Wic, describes what @@ -5362,7 +5346,7 @@ command to return the available Wic images as follows: genericx86 Create an EFI disk image for genericx86* beaglebone-yocto Create SD card image for Beaglebone edgerouter Create SD card image for Edgerouter - qemux86-directdisk Create a qemu machine 'pcbios' direct disk image + qemux86-directdisk Create a QEMU machine 'pcbios' direct disk image directdisk-gpt Create a 'pcbios' direct disk image mkefidisk Create an EFI disk image directdisk Create a 'pcbios' direct disk image @@ -5509,7 +5493,7 @@ Use the following command to list the available kickstart files: genericx86 Create an EFI disk image for genericx86* beaglebone-yocto Create SD card image for Beaglebone edgerouter Create SD card image for Edgerouter - qemux86-directdisk Create a qemu machine 'pcbios' direct disk image + qemux86-directdisk Create a QEMU machine 'pcbios' direct disk image directdisk-gpt Create a 'pcbios' direct disk image mkefidisk Create an EFI disk image directdisk Create a 'pcbios' direct disk image @@ -5683,7 +5667,7 @@ Wic Examples This section provides several examples that show how to use the Wic utility. All the examples assume the list of requirements in the -"`Requirements <#wic-requirements>`__" section have been met. The +":ref:`dev-manual/common-tasks:requirements`" section have been met. The examples assume the previously generated image is ``core-image-minimal``. @@ -6098,8 +6082,7 @@ more secure: - Ensure you remove or disable debugging functionality before producing the final image. For information on how to do this, see the - "`Considerations Specific to the OpenEmbedded Build - System <#considerations-specific-to-the-openembedded-build-system>`__" + ":ref:`dev-manual/common-tasks:considerations specific to the openembedded build system`" section. - Ensure you have no network services listening that are not needed. @@ -6280,17 +6263,17 @@ layer. The following steps provide some more detail: distro-specific configuration files that are included by an existing recipe, you should add an append file (``.bbappend``) for those. For general information and recommendations on how to add - recipes to your layer, see the "`Creating Your Own - Layer <#creating-your-own-layer>`__" and "`Following Best - Practices When Creating - Layers <#best-practices-to-follow-when-creating-layers>`__" + recipes to your layer, see the + ":ref:`dev-manual/common-tasks:creating your own layer`" and + ":ref:`dev-manual/common-tasks:following best practices when creating layers`" sections. - Add any image recipes that are specific to your distribution. - Add a ``psplash`` append file for a branded splash screen. For - information on append files, see the "`Using .bbappend Files in - Your Layer <#using-bbappend-files>`__" section. + information on append files, see the + ":ref:`dev-manual/common-tasks:using .bbappend files in your layer`" + section. - Add any other append files to make custom changes that are specific to individual recipes. @@ -6388,29 +6371,22 @@ Working with Packages This section describes a few tasks that involve packages: -- `Excluding packages from an - image <#excluding-packages-from-an-image>`__ +- :ref:`dev-manual/common-tasks:excluding packages from an image` -- `Incrementing a binary package - version <#incrementing-a-binary-package-version>`__ +- :ref:`dev-manual/common-tasks:incrementing a package version` -- `Handling optional module - packaging <#handling-optional-module-packaging>`__ +- :ref:`dev-manual/common-tasks:handling optional module packaging` -- `Using runtime package - management <#using-runtime-package-management>`__ +- :ref:`dev-manual/common-tasks:using runtime package management` -- `Generating and using signed - packages <#generating-and-using-signed-packages>`__ +- :ref:`dev-manual/common-tasks:generating and using signed packages` -- `Setting up and running package test - (ptest) <#testing-packages-with-ptest>`__ +- :ref:`Setting up and running package test + (ptest) <dev-manual/common-tasks:testing packages with ptest>` -- `Creating node package manager (NPM) - packages <#creating-node-package-manager-npm-packages>`__ +- :ref:`dev-manual/common-tasks:creating node package manager (npm) packages` -- `Adding custom metadata to - packages <#adding-custom-metadata-to-packages>`__ +- :ref:`dev-manual/common-tasks:adding custom metadata to packages` Excluding Packages from an Image -------------------------------- @@ -6499,9 +6475,8 @@ much preferred over a manual system. In either system, the main requirement is that binary package version numbering increases in a linear fashion and that a number of version components exist that support that linear progression. For information on how to ensure -package revisioning remains linear, see the "`Automatically Incrementing -a Binary Package Revision -Number <#automatically-incrementing-a-binary-package-revision-number>`__" +package revisioning remains linear, see the +":ref:`dev-manual/common-tasks:automatically incrementing a package version number`" section. The following three sections provide related information on the PR @@ -6592,14 +6567,14 @@ each building system's ``local.conf`` file: BUILDHISTORY_COMMIT = "1" For information on build -history, see the "`Maintaining Build Output -Quality <#maintaining-build-output-quality>`__" section. +history, see the +":ref:`dev-manual/common-tasks:maintaining build output quality`" section. .. note:: The OpenEmbedded build system does not maintain ``PR`` information as part of the shared state (sstate) packages. If you maintain an sstate - feed, its expected that either all your building systems that + feed, it's expected that either all your building systems that contribute to the sstate feed use a shared PR Service, or you do not run a PR Service on any of your building systems. Having some systems use a PR Service while others do not leads to obvious problems. @@ -7070,7 +7045,7 @@ runtime package management of RPM packages. In order to use DNF for runtime package management, you must perform an initial setup on the target machine for cases where the ``PACKAGE_FEED_*`` variables were not set as part of the image that is running on the target. This means if -you built your image and did not not use these variables as part of the +you built your image and did not use these variables as part of the build and your image is now running on the target, you need to perform the steps in this section if you want to use runtime package management. @@ -8522,7 +8497,7 @@ In order to run tests, you need to do the following: - Ubuntu and Debian: ``sysstat`` and ``iproute2`` - - OpenSUSE: ``sysstat`` and ``iproute2`` + - openSUSE: ``sysstat`` and ``iproute2`` - Fedora: ``sysstat`` and ``iproute`` @@ -8596,8 +8571,8 @@ options exist: it the same IP address for each reboot. If you choose "SystemdbootTarget", there are additional requirements - and considerations. See the "`Selecting - SystemdbootTarget <#selecting-systemdboottarget>`__" section, which + and considerations. See the + ":ref:`dev-manual/common-tasks:selecting systemdboottarget`" section, which follows, for more information. - *"BeagleBoneTarget":* Choose "BeagleBoneTarget" if you are deploying @@ -8629,7 +8604,7 @@ Selecting SystemdbootTarget If you did not set ``TEST_TARGET`` to "SystemdbootTarget", then you do not need any information in this section. You can skip down to the -"`Running Tests <#qemu-image-running-tests>`__" section. +":ref:`dev-manual/common-tasks:running tests`" section. If you did set ``TEST_TARGET`` to "SystemdbootTarget", you also need to perform a one-time setup of your master image by doing the following: @@ -8648,7 +8623,7 @@ perform a one-time setup of your master image by doing the following: - Inherits ``core-image`` so that kernel modules are installed. - - Installs normal linux utilities not busybox ones (e.g. ``bash``, + - Installs normal linux utilities not BusyBox ones (e.g. ``bash``, ``coreutils``, ``tar``, ``gzip``, and ``kmod``). - Uses a custom Initial RAM Disk (initramfs) image with a custom @@ -9095,13 +9070,11 @@ situations. The following list shows the debugging topics in the remainder of this section: -- "`Viewing Logs from Failed - Tasks <#dev-debugging-viewing-logs-from-failed-tasks>`__" describes +- ":ref:`dev-manual/common-tasks:viewing logs from failed tasks`" describes how to find and view logs from tasks that failed during the build process. -- "`Viewing Variable - Values <#dev-debugging-viewing-variable-values>`__" describes how to +- ":ref:`dev-manual/common-tasks:viewing variable values`" describes how to use the BitBake ``-e`` option to examine variable values after a recipe has been parsed. @@ -9110,51 +9083,47 @@ section: :term:`PKGDATA_DIR` and display package-related information for built packages. -- "`Viewing Dependencies Between Recipes and - Tasks <#dev-viewing-dependencies-between-recipes-and-tasks>`__" +- ":ref:`dev-manual/common-tasks:viewing dependencies between recipes and tasks`" describes how to use the BitBake ``-g`` option to display recipe dependency information used during the build. -- "`Viewing Task Variable - Dependencies <#dev-viewing-task-variable-dependencies>`__" describes +- ":ref:`dev-manual/common-tasks:viewing task variable dependencies`" describes how to use the ``bitbake-dumpsig`` command in conjunction with key subdirectories in the :term:`Build Directory` to determine variable dependencies. -- "`Running Specific Tasks <#dev-debugging-taskrunning>`__" describes +- ":ref:`dev-manual/common-tasks:running specific tasks`" describes how to use several BitBake options (e.g. ``-c``, ``-C``, and ``-f``) to run specific tasks in the build chain. It can be useful to run tasks "out-of-order" when trying isolate build issues. -- "`General BitBake Problems <#dev-debugging-bitbake>`__" 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. -- "`Building with No Dependencies <#dev-debugging-buildfile>`__" +- ":ref:`dev-manual/common-tasks:building with no dependencies`" describes how to use the BitBake ``-b`` option to build a recipe while ignoring dependencies. -- "`Recipe Logging Mechanisms <#recipe-logging-mechanisms>`__" +- ":ref:`dev-manual/common-tasks:recipe logging mechanisms`" describes how to use the many recipe logging functions to produce debugging output and report errors and warnings. -- "`Debugging Parallel Make Races <#debugging-parallel-make-races>`__" +- ":ref:`dev-manual/common-tasks:debugging parallel make races`" describes how to debug situations where the build consists of several parts that are run simultaneously and when the output or result of one part is not ready for use with a different part of the build that depends on that output. -- "`Debugging With the GNU Project Debugger (GDB) - Remotely <#platdev-gdb-remotedebug>`__" describes how to use GDB to - allow you to examine running programs, which can help you fix - problems. +- ":ref:`dev-manual/common-tasks:debugging with the gnu project debugger (gdb) remotely`" + describes how to use GDB to allow you to examine running programs, which can + help you fix problems. -- "`Debugging with the GNU Project Debugger (GDB) on the - Target <#debugging-with-the-gnu-project-debugger-gdb-on-the-target>`__" +- ":ref:`dev-manual/common-tasks:debugging with the gnu project debugger (gdb) on the target`" describes how to use GDB directly on target hardware for debugging. -- "`Other Debugging Tips <#dev-other-debugging-others>`__" describes +- ":ref:`dev-manual/common-tasks:other debugging tips`" describes miscellaneous debugging tips that can be useful. Viewing Logs from Failed Tasks @@ -9462,8 +9431,8 @@ state (sstate) task can be a useful debugging aid. This information is available in signature information (``siginfo``) files in :term:`SSTATE_DIR`. For information on how to view and interpret information in ``siginfo`` -files, see the "`Viewing Task Variable -Dependencies <#dev-viewing-task-variable-dependencies>`__" section. +files, see the +":ref:`dev-manual/common-tasks:viewing task variable dependencies`" section. For conceptual information on shared state, see the ":ref:`overview-manual/concepts:shared state`" @@ -9882,9 +9851,8 @@ Once the local build for "neard" completes, start a ``devshell`` build: $ bitbake neard -c devshell -For information on how to use a -``devshell``, see the "`Using a Development -Shell <#platdev-appdev-devshell>`__" section. +For information on how to use a ``devshell``, see the +":ref:`dev-manual/common-tasks:using a development shell`" section. In the ``devshell``, do the following: :: @@ -9926,7 +9894,7 @@ to patch the ``Makefile.am`` file, which is generated from File Makefile.am added to patch patches/parallelmake.patch For more information on using Quilt, see the -"`Using Quilt in Your Workflow <#using-a-quilt-workflow>`__" section. +":ref:`dev-manual/common-tasks:using quilt in your workflow`" section. At this point you need to make the edits to ``Makefile.am`` to add the missing dependency. For our example, you have to add the following line @@ -9992,9 +9960,9 @@ The build should work without issue. As with all solved problems, if they originated upstream, you need to submit the fix for the recipe in OE-Core and upstream so that the -problem is taken care of at its source. See the "`Submitting a Change to -the Yocto Project <#how-to-submit-a-change>`__" section for more -information. +problem is taken care of at its source. See the +":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" +section for more information. Debugging With the GNU Project Debugger (GDB) Remotely ------------------------------------------------------ @@ -10368,8 +10336,9 @@ Here are some other tips that you might find useful: :yocto_bugs:`Bugzilla <>`. For information on how to submit a bug against the Yocto Project, see the Yocto Project Bugzilla :yocto_wiki:`wiki page </Bugzilla_Configuration_and_Bug_Tracking>` - and the "`Submitting a Defect Against the Yocto - Project <#submitting-a-defect-against-the-yocto-project>`__" section. + and the + ":ref:`dev-manual/common-tasks:submitting a defect against the yocto project`" + section. .. note:: @@ -10624,8 +10593,9 @@ Using Email to Submit a Patch Depending on the components changed, you need to submit the email to a specific mailing list. For some guidance on which mailing list to use, -see the `list <#figuring-out-the-mailing-list-to-use>`__ at the -beginning of this section. For a description of all the available +see the +:ref:`list <dev-manual/common-tasks:submitting a change to the yocto project>` +at the beginning of this section. For a description of all the available mailing lists, see the ":ref:`Mailing Lists <resources-mailinglist>`" section in the Yocto Project Reference Manual. @@ -11039,7 +11009,7 @@ file. For example, to enable the ``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` package, you could add either the string "commercial_gst-plugins-ugly" or the more general string "commercial" to ``LICENSE_FLAGS_WHITELIST``. See the -"`License Flag Matching <#license-flag-matching>`__" section for a full +":ref:`dev-manual/common-tasks:license flag matching`" section for a full explanation of how ``LICENSE_FLAGS`` matching works. Here is the example: :: diff --git a/poky/documentation/dev-manual/qemu.rst b/poky/documentation/dev-manual/qemu.rst index c6bb9e977..92799d6d2 100644 --- a/poky/documentation/dev-manual/qemu.rst +++ b/poky/documentation/dev-manual/qemu.rst @@ -306,8 +306,8 @@ present, the toolchain is also automatically used. tarball by using the ``runqemu-extract-sdk`` command. After running the command, you must then point the ``runqemu`` script to the extracted directory instead of a root filesystem image file. - See the "`Running Under a Network File System (NFS) - Server <#qemu-running-under-a-network-file-system-nfs-server>`__" + See the + ":ref:`dev-manual/qemu:running under a network file system (nfs) server`" section for more information. QEMU Command-Line Syntax @@ -452,7 +452,7 @@ command line: or "qemux86-64" QEMU architectures. For KVM with VHOST to work, the following conditions must be met: - - `kvm <#kvm-cond>`__ option conditions must be met. + - ``kvm`` option conditions defined above must be met. - Your build host has to have virtio net device, which are ``/dev/vhost-net``. diff --git a/poky/documentation/dev-manual/start.rst b/poky/documentation/dev-manual/start.rst index efe369c75..84abf4c51 100644 --- a/poky/documentation/dev-manual/start.rst +++ b/poky/documentation/dev-manual/start.rst @@ -230,8 +230,8 @@ particular working environment and set of practices. - Separate the project's Metadata and code by using separate Git repositories. See the ":ref:`overview-manual/development-environment:yocto project source repositories`" section in the Yocto Project Overview and Concepts Manual for - information on these repositories. See the "`Locating Yocto - Project Source Files <#locating-yocto-project-source-files>`__" + information on these repositories. See the + ":ref:`dev-manual/start:locating yocto project source files`" section for information on how to set up local Git repositories for related upstream Yocto Project Git repositories. @@ -314,13 +314,13 @@ Project Build Host: should be able to run on any modern distribution that has the following versions for Git, tar, Python and gcc. - - Git 1.8.3.1 or greater + - Git &MIN_GIT_VERSION; or greater - - tar 1.28 or greater + - tar &MIN_TAR_VERSION; or greater - - Python 3.5.0 or greater. + - Python &MIN_PYTHON_VERSION; or greater. - - gcc 5.0 or greater. + - gcc &MIN_GCC_VERSION; or greater. If your build host does not meet any of these three listed version requirements, you can take steps to prepare the system so that you @@ -655,8 +655,7 @@ The :yocto_home:`Yocto Project Website <>` uses a "DOWNLOADS" page from which you can locate and download tarballs of any Yocto Project release. Rather than Git repositories, these files represent snapshot tarballs similar to the tarballs located in the Index of Releases -described in the "`Accessing Index of -Releases <#accessing-index-of-releases>`__" section. +described in the ":ref:`dev-manual/start:accessing index of releases`" section. .. note:: @@ -759,9 +758,9 @@ Follow these steps to create a local version of the upstream "master" branch, which results in a snapshot of the latest development changes for "master". For information on how to check out a specific development branch or on how to check out a local branch - based on a tag name, see the "`Checking Out By Branch in - Poky <#checking-out-by-branch-in-poky>`__" and `Checking Out By Tag - in Poky <#checkout-out-by-tag-in-poky>`__" sections, respectively. + based on a tag name, see the + ":ref:`dev-manual/start:checking out by branch in poky`" and + ":ref:`dev-manual/start:checking out by tag in poky`" sections, respectively. Once the local repository is created, you can change to that directory and check its status. Here, the single "master" branch diff --git a/poky/documentation/index.rst b/poky/documentation/index.rst index 9f41daf4b..6aeeb2197 100644 --- a/poky/documentation/index.rst +++ b/poky/documentation/index.rst @@ -34,7 +34,7 @@ Welcome to the Yocto Project Documentation Application Development and the Extensible SDK (eSDK) <sdk-manual/index> Toaster Manual <toaster-manual/index> Test Environment Manual <test-manual/index> - Bitbake User Manual <https://docs.yoctoproject.org/bitbake> + bitbake .. toctree:: :maxdepth: 1 diff --git a/poky/documentation/kernel-dev/advanced.rst b/poky/documentation/kernel-dev/advanced.rst index dd0b76bc3..fb6dfca85 100644 --- a/poky/documentation/kernel-dev/advanced.rst +++ b/poky/documentation/kernel-dev/advanced.rst @@ -56,8 +56,8 @@ using the same BSP description. Multiple Corei7-based BSPs could share the same "intel-corei7-64" value for ``KMACHINE``. It is important to realize that ``KMACHINE`` is just for kernel mapping, while ``MACHINE`` is the machine type within a BSP Layer. Even with this distinction, -however, these two variables can hold the same value. See the `BSP -Descriptions <#bsp-descriptions>`__ section for more information. +however, these two variables can hold the same value. See the +":ref:`kernel-dev/advanced:bsp descriptions`" section for more information. Every linux-yocto style recipe must also indicate the Linux kernel source repository branch used to build the Linux kernel. The @@ -87,7 +87,7 @@ Together with ``KMACHINE``, ``LINUX_KERNEL_TYPE`` defines the search arguments used by the kernel tools to find the appropriate description within the kernel Metadata with which to build out the sources and configuration. The linux-yocto recipes define "standard", "tiny", and -"preempt-rt" kernel types. See the "`Kernel Types <#kernel-types>`__" +"preempt-rt" kernel types. See the ":ref:`kernel-dev/advanced:kernel types`" section for more information on kernel types. During the build, the kern-tools search for the BSP description file @@ -123,8 +123,8 @@ the entries in ``KERNEL_FEATURES`` are dependent on their location within the kernel Metadata itself. The examples here are taken from the ``yocto-kernel-cache`` repository. Each branch of this repository contains "features" and "cfg" subdirectories at the top-level. For more -information, see the "`Kernel Metadata -Syntax <#kernel-metadata-syntax>`__" section. +information, see the ":ref:`kernel-dev/advanced:kernel metadata syntax`" +section. Kernel Metadata Syntax ====================== @@ -148,7 +148,7 @@ Features aggregate sources in the form of patches and configuration fragments into a modular reusable unit. You can use features to implement conceptually separate kernel Metadata descriptions such as pure configuration fragments, simple patches, complex features, and -kernel types. `Kernel types <#kernel-types>`__ define general kernel +kernel types. :ref:`kernel-dev/advanced:kernel types` define general kernel features and policy to be reused in the BSPs. BSPs define hardware-specific features and aggregate them with kernel @@ -167,10 +167,9 @@ following Metadata file hierarchy is recommended: ktypes/ patches/ -The ``bsp`` directory contains the `BSP -descriptions <#bsp-descriptions>`__. The remaining directories all -contain "features". Separating ``bsp`` from the rest of the structure -aids conceptualizing intended usage. +The ``bsp`` directory contains the :ref:`kernel-dev/advanced:bsp descriptions`. +The remaining directories all contain "features". Separating ``bsp`` from the +rest of the structure aids conceptualizing intended usage. Use these guidelines to help place your ``scc`` description files within the structure: @@ -198,11 +197,12 @@ contain "features" as far as the kernel tools are concerned. Paths used in kernel Metadata files are relative to base, which is either :term:`FILESEXTRAPATHS` if -you are creating Metadata in `recipe-space <#recipe-space-metadata>`__, +you are creating Metadata in +:ref:`recipe-space <kernel-dev/advanced:recipe-space metadata>`, or the top level of :yocto_git:`yocto-kernel-cache </yocto-kernel-cache/tree/>` -if you are creating `Metadata outside of the -recipe-space <#metadata-outside-the-recipe-space>`__. +if you are creating +:ref:`kernel-dev/advanced:metadata outside the recipe-space`. .. [1] ``scc`` stands for Series Configuration Control, but the naming has @@ -353,9 +353,9 @@ as how an additional feature description file is included with the Typically, features are less granular than configuration fragments and are more likely than configuration fragments and patches to be the types of things you want to specify in the ``KERNEL_FEATURES`` variable of the -Linux kernel recipe. See the "`Using Kernel Metadata in a -Recipe <#using-kernel-metadata-in-a-recipe>`__" section earlier in the -manual. +Linux kernel recipe. See the +":ref:`kernel-dev/advanced:using kernel metadata in a recipe`" section earlier +in the manual. Kernel Types ------------ @@ -364,7 +364,7 @@ A kernel type defines a high-level kernel policy by aggregating non-hardware configuration fragments with patches you want to use when building a Linux kernel of a specific type (e.g. a real-time kernel). Syntactically, kernel types are no different than features as described -in the "`Features <#features>`__" section. The +in the ":ref:`kernel-dev/advanced:features`" section. The :term:`LINUX_KERNEL_TYPE` variable in the kernel recipe selects the kernel type. For example, in the ``linux-yocto_4.12.bb`` kernel recipe found in @@ -540,7 +540,7 @@ example, this is done using the following: This file aggregates all the configuration fragments, patches, and features that make up your standard kernel -policy. See the "`Kernel Types <#kernel-types>`__" section for more +policy. See the ":ref:`kernel-dev/advanced:kernel types`" section for more information. To aggregate common configurations and features specific to the kernel @@ -825,11 +825,11 @@ Given this scenario, you do not need to create any branches in the source repository. Rather, you just take the static patches you need and encapsulate them within a feature description. Once you have the feature description, you simply include that into the BSP description as -described in the "`BSP Descriptions <#bsp-descriptions>`__" section. +described in the ":ref:`kernel-dev/advanced:bsp descriptions`" section. You can find information on how to create patches and BSP descriptions -in the "`Patches <#patches>`__" and "`BSP -Descriptions <#bsp-descriptions>`__" sections. +in the ":ref:`kernel-dev/advanced:patches`" and +":ref:`kernel-dev/advanced:bsp descriptions`" sections. Machine Branches ---------------- diff --git a/poky/documentation/kernel-dev/common.rst b/poky/documentation/kernel-dev/common.rst index 0e545d1b8..56217b9d3 100644 --- a/poky/documentation/kernel-dev/common.rst +++ b/poky/documentation/kernel-dev/common.rst @@ -365,8 +365,7 @@ section: At this point, you are ready to start making modifications to the kernel using traditional kernel development steps. For a continued example, see -the "`Using Traditional Kernel Development to Patch the -Kernel <#using-traditional-kernel-development-to-patch-the-kernel>`__" +the ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`" section. Creating and Preparing a Layer @@ -463,8 +462,8 @@ Modifying an existing recipe can consist of the following: - :ref:`kernel-dev/common:changing the configuration` Before modifying an existing recipe, be sure that you have created a -minimal, custom layer from which you can work. See the "`Creating and -Preparing a Layer <#creating-and-preparing-a-layer>`__" section for +minimal, custom layer from which you can work. See the +":ref:`kernel-dev/common:creating and preparing a layer`" section for information. Creating the Append File @@ -710,7 +709,7 @@ Linux kernel, BitBake detects the change in the recipe and fetches and applies the new configuration before building the kernel. For a detailed example showing how to configure the kernel, see the -"`Configuring the Kernel <#configuring-the-kernel>`__" section. +":ref:`kernel-dev/common:configuring the kernel`" section. Using an "In-Tree"  ``defconfig`` File -------------------------------------- @@ -954,15 +953,14 @@ emulator console output at boot time through ``printk`` statements in the kernel's ``calibrate.c`` source code file. Applying the patch and booting the modified image causes the added messages to appear on the emulator's console. The example is a continuation of the setup procedure -found in the "`Getting Ready for Traditional Kernel -Development <#getting-ready-for-traditional-kernel-development>`__" +found in the +":ref:`kernel-dev/common:getting ready for traditional kernel development`" Section. 1. *Edit the Source Files* Prior to this step, you should have used Git to create a local copy of the repository for your kernel. Assuming - you created the repository as directed in the "`Getting Ready for - Traditional Kernel - Development <#getting-ready-for-traditional-kernel-development>`__" + you created the repository as directed in the + ":ref:`kernel-dev/common:getting ready for traditional kernel development`" section, use the following commands to edit the ``calibrate.c`` file: 1. *Change the working directory*: You need to locate the source @@ -1104,9 +1102,9 @@ Section. The :term:`FILESEXTRAPATHS` and :term:`SRC_URI` statements enable the OpenEmbedded build system to find the patch file. - For more information on append files and patches, see the "`Creating - the Append File <#creating-the-append-file>`__" and "`Applying - Patches <#applying-patches>`__" sections. You can also see the + For more information on append files and patches, see the + ":ref:`kernel-dev/common:creating the append file`" and + ":ref:`kernel-dev/common:applying patches`" sections. You can also see the ":ref:`dev-manual/common-tasks:using .bbappend files in your layer`" section in the Yocto Project Development Tasks Manual. @@ -1140,8 +1138,8 @@ configuration fragments, and how to interactively modify your ``.config`` file to create the leanest kernel configuration file possible. -For more information on kernel configuration, see the "`Changing the -Configuration <#changing-the-configuration>`__" section. +For more information on kernel configuration, see the +":ref:`kernel-dev/common:changing the configuration`" section. Using  ``menuconfig`` --------------------- @@ -1297,8 +1295,8 @@ created to hold the configuration changes. applies these on top of and after applying the existing ``defconfig`` file configurations. -For more information on configuring the kernel, see the "`Changing the -Configuration <#changing-the-configuration>`__" section. +For more information on configuring the kernel, see the +":ref:`kernel-dev/common:changing the configuration`" section. Creating Configuration Fragments -------------------------------- @@ -1369,8 +1367,8 @@ steps: $ bitbake linux-yocto -c diffconfig The ``diffconfig`` command creates a file that is a list of Linux kernel -``CONFIG_`` assignments. See the "`Changing the -Configuration <#changing-the-configuration>`__" section for additional +``CONFIG_`` assignments. See the +":ref:`kernel-dev/common:changing the configuration`" section for additional information on how to use the output as a configuration fragment. .. note:: @@ -1614,8 +1612,7 @@ source directory. Follow these steps to clean up the version string: ":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`" section. For information on building the kernel image when using Bitbake, see the - "`Using Traditional Kernel Development to Patch the - Kernel <#using-traditional-kernel-development-to-patch-the-kernel>`__" + ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`" section. Working With Your Own Sources @@ -1733,8 +1730,9 @@ Here are some basic steps you can use to work with your own sources: 5. *Customize Your Recipe as Needed:* Provide further customizations to your recipe as needed just as you would customize an existing - linux-yocto recipe. See the "`Modifying an Existing - Recipe <#modifying-an-existing-recipe>`__" section for information. + linux-yocto recipe. See the + ":ref:`ref-manual/devtool-reference:modifying an existing recipe`" section + for information. Working with Out-of-Tree Modules ================================ @@ -1914,7 +1912,7 @@ differences: $ git show origin/standard/base..origin/standard/emenlow Use this command to create individual patches for each change. Here is -an example that that creates patch files for each commit and places them +an example that creates patch files for each commit and places them in your ``Documents`` directory: :: diff --git a/poky/documentation/kernel-dev/intro.rst b/poky/documentation/kernel-dev/intro.rst index f6c9b9713..5592f74c8 100644 --- a/poky/documentation/kernel-dev/intro.rst +++ b/poky/documentation/kernel-dev/intro.rst @@ -90,8 +90,7 @@ understand the following documentation: - The ":ref:`dev-manual/common-tasks:understanding and creating layers`" section in the Yocto Project Development Tasks Manual. -- The "`Kernel Modification - Workflow <#kernel-modification-workflow>`__" section. +- The ":ref:`kernel-dev/intro:kernel modification workflow`" section. Kernel Modification Workflow ============================ diff --git a/poky/documentation/kernel-dev/maint-appx.rst b/poky/documentation/kernel-dev/maint-appx.rst index 89f4b4334..44c43893e 100644 --- a/poky/documentation/kernel-dev/maint-appx.rst +++ b/poky/documentation/kernel-dev/maint-appx.rst @@ -64,7 +64,7 @@ the "yocto-4.12" branch of the ``yocto-kernel-cache`` repository: kernel versions (e.g. "yocto-4.12", "yocto-4.10", "yocto-4.9", and so forth). Once you have checked out and switched to appropriate branches, you can -see a snapshot of all the kernel source files used to used to build that +see a snapshot of all the kernel source files used to build that particular Yocto Linux kernel for a particular board. To see the features and configurations for a particular Yocto Linux diff --git a/poky/documentation/overview-manual/concepts.rst b/poky/documentation/overview-manual/concepts.rst index 257de44ec..ada5143b2 100644 --- a/poky/documentation/overview-manual/concepts.rst +++ b/poky/documentation/overview-manual/concepts.rst @@ -132,7 +132,7 @@ Layers Layers are repositories that contain related metadata (i.e. sets of instructions) that tell the OpenEmbedded build system how to build a -target. Yocto Project's `layer model <#the-yocto-project-layer-model>`__ +target. :ref:`overview-manual/yp-intro:the yocto project layer model` facilitates collaboration, sharing, customization, and reuse within the Yocto Project development environment. Layers logically separate information for your project. For example, you can use a layer to hold @@ -207,8 +207,8 @@ you can tell BitBake the target architecture for which you are building the image, where to store downloaded source, and other build properties. The following figure shows an expanded representation of the "User -Configuration" box of the `general workflow -figure <#general-workflow-figure>`__: +Configuration" box of the :ref:`general workflow +figure <overview-manual/concepts:openembedded build system concepts>`: .. image:: figures/user-configuration.png :align: center @@ -374,7 +374,7 @@ provide Metadata for the software, machine, and policies. In general, three types of layer input exists. You can see them below the "User Configuration" box in the `general workflow -figure <#general-workflow-figure>`__: +figure <overview-manual/concepts:openembedded build system concepts>`: - *Metadata (.bb + Patches):* Software layers containing user-supplied recipe files, patches, and append files. A good example @@ -387,8 +387,8 @@ figure <#general-workflow-figure>`__: - *Machine BSP Configuration:* Board Support Package (BSP) layers (i.e. "BSP Layer" in the following figure) providing machine-specific configurations. This type of information is specific to a particular - target architecture. A good example of a BSP layer from the `Poky - Reference Distribution <#gs-reference-distribution-poky>`__ is the + target architecture. A good example of a BSP layer from the + :ref:`overview-manual/yp-intro:reference distribution (poky)` is the :yocto_git:`meta-yocto-bsp </poky/tree/meta-yocto-bsp>` layer. @@ -403,7 +403,8 @@ figure <#general-workflow-figure>`__: that contain many policy configurations for the Poky distribution. The following figure shows an expanded representation of these three -layers from the `general workflow figure <#general-workflow-figure>`__: +layers from the :ref:`general workflow figure +<overview-manual/concepts:openembedded build system concepts>`: .. image:: figures/layer-input.png :align: center @@ -418,9 +419,9 @@ in the 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 -"`Layers <#overview-layers>`__" and "`The Yocto Project Layer -Model <#the-yocto-project-layer-model>`__" sections both earlier in this -manual. +":ref:`overview-manual/concepts:layers`" and +":ref:`overview-manual/yp-intro: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 :yocto_git:`Source @@ -514,11 +515,12 @@ Sources ------- In order for the OpenEmbedded build system to create an image or any -target, it must be able to access source files. The `general workflow -figure <#general-workflow-figure>`__ represents source files using the -"Upstream Project Releases", "Local Projects", and "SCMs (optional)" -boxes. The figure represents mirrors, which also play a role in locating -source files, with the "Source Materials" box. +target, it must be able to access source files. The :ref:`general workflow +figure <overview-manual/concepts:openembedded build system concepts>` +represents source files using the "Upstream Project Releases", "Local +Projects", and "SCMs (optional)" boxes. The figure represents mirrors, +which also play a role in locating source files, with the "Source +Materials" box. The method by which source files are ultimately organized is a function of the project. For example, for released software, projects tend to use @@ -554,7 +556,7 @@ Directory if needed without fear of removing any downloaded source file. The remainder of this section provides a deeper look into the source files and the mirrors. Here is a more detailed look at the source file -area of the `general workflow figure <#general-workflow-figure>`__: +area of the :ref:`general workflow figure <overview-manual/concepts:openembedded build system concepts>`: .. image:: figures/source-input.png :align: center @@ -628,9 +630,9 @@ Package Feeds When the OpenEmbedded build system generates an image or an SDK, it gets the packages from a package feed area located in the -:term:`Build Directory`. The `general -workflow figure <#general-workflow-figure>`__ shows this package feeds -area in the upper-right corner. +:term:`Build Directory`. The :ref:`general workflow figure +<overview-manual/concepts:openembedded build system concepts>` +shows this package feeds area in the upper-right corner. 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: @@ -691,10 +693,10 @@ BitBake Tool The OpenEmbedded build system uses :term:`BitBake` to produce images and -Software Development Kits (SDKs). You can see from the `general workflow -figure <#general-workflow-figure>`__, the BitBake area consists of -several functional areas. This section takes a closer look at each of -those areas. +Software Development Kits (SDKs). You can see from the :ref:`general workflow +figure <overview-manual/concepts:openembedded build system concepts>`, +the BitBake area consists of several functional areas. This section takes a +closer look at each of those areas. .. note:: @@ -820,7 +822,7 @@ source files, which are located in the :term:`S` directory. For more information on how the source directories are created, see the -"`Source Fetching <#source-fetching-dev-environment>`__" section. For +":ref:`overview-manual/concepts:source fetching`" section. For more information on how to create patches and how the build system processes patches, see the ":ref:`dev-manual/common-tasks:patching code`" @@ -957,8 +959,8 @@ details on how this is accomplished, you can look at Depending on the type of packages being created (RPM, DEB, or IPK), the :ref:`do_package_write_* <ref-tasks-package_write_deb>` task creates the actual packages and places them in the Package Feed -area, which is ``${TMPDIR}/deploy``. You can see the "`Package -Feeds <#package-feeds-dev-environment>`__" section for more detail on +area, which is ``${TMPDIR}/deploy``. You can see the +":ref:`overview-manual/concepts:package feeds`" section for more detail on that part of the build process. .. note:: @@ -1119,7 +1121,7 @@ and :ref:`ref-tasks-populate_sdk_ext` tasks use these key variables to help create the list of packages to actually install. For information on the variables listed in the figure, -see the "`Application Development SDK <#sdk-dev-environment>`__" +see the ":ref:`overview-manual/concepts:application development sdk`" section. The ``do_populate_sdk`` task helps create the standard SDK and handles @@ -1147,8 +1149,8 @@ For each task that completes successfully, BitBake writes a stamp file into the :term:`STAMPS_DIR` directory. The beginning of the stamp file's filename is determined by the :term:`STAMP` variable, and the end -of the name consists of the task's name and current `input -checksum <#overview-checksums>`__. +of the name consists of the task's name and current :ref:`input +checksum <overview-manual/concepts:checksums (signatures)>`. .. note:: @@ -1165,10 +1167,10 @@ file does not exist, the task is rerun. .. note:: The stamp mechanism is more general than the shared state (sstate) - cache mechanism described in the "`Setscene Tasks and Shared - State <#setscene-tasks-and-shared-state>`__" section. BitBake avoids - rerunning any task that has a valid stamp file, not just tasks that - can be accelerated through the sstate cache. + cache mechanism described in the + ":ref:`overview-manual/concepts:setscene tasks and shared state`" section. + BitBake avoids rerunning any task that has a valid stamp file, not just + tasks that can be accelerated through the sstate cache. However, you should realize that stamp files only serve as a marker that some work has been done and that these files do not record task @@ -1271,7 +1273,8 @@ Images The images produced by the build system are compressed forms of the root filesystem and are ready to boot on a target device. You can see from -the `general workflow figure <#general-workflow-figure>`__ that BitBake +the :ref:`general workflow figure +<overview-manual/concepts:openembedded build system concepts>` that BitBake output, in part, consists of images. This section takes a closer look at this output: @@ -1327,7 +1330,8 @@ current configuration. Application Development SDK --------------------------- -In the `general workflow figure <#general-workflow-figure>`__, the +In the :ref:`general workflow figure +<overview-manual/concepts:openembedded build system concepts>`, the output labeled "Application Development SDK" represents an SDK. The SDK generation process differs depending on whether you build an extensible SDK (e.g. ``bitbake -c populate_sdk_ext`` imagename) or a standard SDK @@ -1357,8 +1361,8 @@ can initialize the environment before using the tools. your own SDK installer. - For background information on cross-development toolchains in the - Yocto Project development environment, see the "`Cross-Development - Toolchain Generation <#cross-development-toolchain-generation>`__" + Yocto Project development environment, see the + ":ref:`overview-manual/concepts:cross-development toolchain generation`" section. - For information on setting up a cross-development environment, see @@ -1773,10 +1777,10 @@ through this setting in the ``bitbake.conf`` file: BB_SIGNATURE_HANDLER ?= "OEBasicHash" The "OEBasicHash" ``BB_SIGNATURE_HANDLER`` is the same -as the "OEBasic" version but adds the task hash to the `stamp -files <#stamp-files-and-the-rerunning-of-tasks>`__. This results in any -metadata change that changes the task hash, automatically causing the -task to be run again. This removes the need to bump +as the "OEBasic" version but adds the task hash to the :ref:`stamp +files <overview-manual/concepts:stamp files and the rerunning of tasks>`. This +results in any metadata change that changes the task hash, automatically causing +the task to be run again. This removes the need to bump :term:`PR` values, and changes to metadata automatically ripple across the build. @@ -1901,9 +1905,10 @@ The following list explains the previous example: - The ``do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"`` line appends - 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 + extra metadata to the :ref:`stamp + file <overview-manual/concepts:stamp files and the rerunning of tasks>`. In + this case, the metadata makes the task specific to a machine's architecture. + See ":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. @@ -2111,8 +2116,7 @@ accomplished using fakeroot. under fakeroot. Otherwise, the task cannot run root-only operations, and cannot see the fake file ownership and permissions set by the other task. You need to also add a dependency on - virtual/fakeroot-native:do_populate_sysroot - , giving the following: + ``virtual/fakeroot-native:do_populate_sysroot``, giving the following: :: fakeroot do_mytask () { diff --git a/poky/documentation/overview-manual/development-environment.rst b/poky/documentation/overview-manual/development-environment.rst index 011a47957..a33f89e4f 100644 --- a/poky/documentation/overview-manual/development-environment.rst +++ b/poky/documentation/overview-manual/development-environment.rst @@ -157,7 +157,8 @@ these tarballs gives you a snapshot of the released files. - The recommended method for setting up the Yocto Project :term:`Source Directory` and the files - for supported BSPs (e.g., ``meta-intel``) is to use `Git <#git>`__ + for supported BSPs (e.g., ``meta-intel``) is to use + :ref:`overview-manual/development-environment:git` to create a local copy of the upstream repositories. - Be sure to always work in matching branches for both the selected @@ -214,7 +215,8 @@ Git Workflows and the Yocto Project =================================== Developing using the Yocto Project likely requires the use of -`Git <#git>`__. Git is a free, open source distributed version control +:ref:`overview-manual/development-environment:git`. +Git is a free, open source distributed version control system used as part of many collaborative design environments. This section provides workflow concepts using the Yocto Project and Git. In particular, the information covers basic practices that describe roles @@ -382,11 +384,10 @@ commands. Repositories, Tags, and Branches -------------------------------- -As mentioned briefly in the previous section and also in the "`Git -Workflows and the Yocto -Project <#gs-git-workflows-and-the-yocto-project>`__" section, the Yocto -Project maintains source repositories at :yocto_git:`/`. If you -look at this web-interface of the repositories, each item is a separate +As mentioned briefly in the previous section and also in the +":ref:`overview-manual/development-environment:git workflows and the yocto project`" +section, the Yocto Project maintains source repositories at :yocto_git:`/`. +If you look at this web-interface of the repositories, each item is a separate Git repository. Git repositories use branching techniques that track content change (not @@ -541,7 +542,7 @@ descriptions and strategies on how to use these commands: in this form assumes the local branch already exists. This command is analogous to "cd". -- *git checkout –b working-branch upstream-branch:* Creates and +- *git checkout -b working-branch upstream-branch:* Creates and checks out a working branch on your local machine. The local branch tracks the upstream branch. You can use your local branch to isolate your work. It is a good idea to use local branches when adding diff --git a/poky/documentation/overview-manual/intro.rst b/poky/documentation/overview-manual/intro.rst index bd247dd45..a2afe7756 100644 --- a/poky/documentation/overview-manual/intro.rst +++ b/poky/documentation/overview-manual/intro.rst @@ -14,17 +14,16 @@ information suitable for a new Yocto Project user. The following list describes what you can get from this manual: -- `Introducing the Yocto Project <#overview-yp>`__\ *:* This chapter - provides an introduction to the Yocto Project. You will learn about - features and challenges of the Yocto Project, the layer model, +- :ref:`overview-manual/yp-intro:introducing the yocto project`\ *:* + This chapter provides an introduction to the Yocto Project. You will learn + about features and challenges of the Yocto Project, the layer model, components and tools, development methods, the :term:`Poky` reference distribution, the OpenEmbedded build system workflow, and some basic Yocto terms. -- `The Yocto Project Development - Environment <#overview-development-environment>`__\ *:* This chapter - helps you get started understanding the Yocto Project development - environment. You will learn about open source, development hosts, +- :ref:`overview-manual/development-environment:the yocto project development environment`\ *:* + This chapter helps you get started understanding the Yocto Project + development environment. You will learn about open source, development hosts, Yocto Project source repositories, workflows using Git and the Yocto Project, a Git primer, and information about licensing. diff --git a/poky/documentation/overview-manual/yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst index 0ec7e2b96..fca02e4ce 100644 --- a/poky/documentation/overview-manual/yp-intro.rst +++ b/poky/documentation/overview-manual/yp-intro.rst @@ -41,9 +41,9 @@ Features The following list describes features and advantages of the Yocto Project: -- *Widely Adopted Across the Industry:* Semiconductor, operating - system, software, and service vendors exist whose products and - services adopt and support the Yocto Project. For a look at the Yocto +- *Widely Adopted Across the Industry:* Many semiconductor, operating + system, software, and service vendors adopt and support the Yocto + Project in their products and services. For a look at the Yocto Project community and the companies involved with the Yocto Project, see the "COMMUNITY" and "ECOSYSTEM" tabs on the :yocto_home:`Yocto Project <>` home page. @@ -53,8 +53,8 @@ Project: create and supply BSPs that support their hardware. If you have custom silicon, you can create a BSP that supports that architecture. - Aside from lots of architecture support, the Yocto Project fully - supports a wide range of device emulation through the Quick EMUlator + Aside from broad architecture support, the Yocto Project fully + supports a wide range of devices emulated by the Quick EMUlator (QEMU). - *Images and Code Transfer Easily:* Yocto Project output can easily @@ -78,10 +78,10 @@ Project: you need for embedded devices. You only add the feature support or packages that you absolutely need for the device. For devices that have display hardware, you can use available system components such - as X11, GTK+, Qt, Clutter, and SDL (among others) to create a rich - user experience. For devices that do not have a display or where you - want to use alternative UI frameworks, you can choose to not install - these components. + as X11, Wayland, GTK+, Qt, Clutter, and SDL (among others) to create + a rich user experience. For devices that do not have a display or + where you want to use alternative UI frameworks, you can choose to + not build these components. - *Comprehensive Toolchain Capabilities:* Toolchains for supported architectures satisfy most use cases. However, if your hardware @@ -96,18 +96,18 @@ Project: of your design instead of adopting decisions enforced by some system software provider. -- *Uses a Layer Model:* The Yocto Project `layer - infrastructure <#the-yocto-project-layer-model>`__ groups related - functionality into separate bundles. You can incrementally add these - grouped functionalities to your project as needed. Using layers to +- *Uses a Layer Model:* The Yocto Project :ref:`layer + infrastructure <overview-manual/yp-intro:the yocto project layer model>` + groups related functionality into separate bundles. You can incrementally + add these grouped functionalities to your project as needed. Using layers to isolate and group functionality reduces project complexity and redundancy, allows you to easily extend the system, make customizations, and keep functionality organized. - *Supports Partial Builds:* You can build and rebuild individual packages as needed. Yocto Project accomplishes this through its - `shared-state cache <#shared-state-cache>`__ (sstate) scheme. Being - able to build and debug components individually eases project + :ref:`overview-manual/concepts:shared state cache` (sstate) scheme. + Being able to build and debug components individually eases project development. - *Releases According to a Strict Schedule:* Major releases occur on a @@ -155,8 +155,9 @@ developing using the Yocto Project: documents on the Yocto Project website. - *Project Workflow Could Be Confusing:* The `Yocto Project - workflow <#overview-development-environment>`__ could be confusing if - you are used to traditional desktop and server software development. + workflow <overview-manual/development-environment:the yocto project development environment>` + could be confusing if you are used to traditional desktop and server + software development. In a desktop development environment, mechanisms exist to easily pull and install new packages, which are typically pre-compiled binaries from servers accessible over the Internet. Using the Yocto Project, @@ -262,8 +263,7 @@ with the string ``meta-``. .. note:: It is not a requirement that a layer name begin with the prefix - meta- - , but it is a commonly accepted standard in the Yocto Project + ``meta-``, but it is a commonly accepted standard in the Yocto Project community. For example, if you were to examine the :yocto_git:`tree view </poky/tree/>` @@ -272,7 +272,7 @@ of the ``poky`` repository, you will see several layers: ``meta``, ``meta-yocto-bsp``. Each of these repositories represents a distinct layer. -For procedures on how to create layers, see the +For procedures on how to create layers, see the ":ref:`dev-manual/common-tasks:understanding and creating layers`" section in the Yocto Project Development Tasks Manual. @@ -283,8 +283,7 @@ The Yocto Project employs a collection of components and tools used by the project itself, by project developers, and by those using the Yocto Project. These components and tools are open source projects and metadata that are separate from the reference distribution -(:term:`Poky`) and the -:term:`OpenEmbedded Build System`. Most of the +(:term:`Poky`) and the :term:`OpenEmbedded Build System`. Most of the components and tools are downloaded separately. This section provides brief overviews of the components and tools @@ -325,7 +324,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 + (eSDK) Manual in the ":ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`" section. @@ -431,13 +430,16 @@ activities using the Yocto Project: During a build, it can be necessary to perform operations that require system administrator privileges. For example, file ownership - or permissions might need definition. Pseudo is a tool that you can - either use directly or through the environment variable + or permissions might need to be defined. Pseudo is a tool that you + can either use directly or through the environment variable ``LD_PRELOAD``. Either method allows these operations to succeed as if system administrator privileges exist even when they do not. - You can read more about Pseudo in the "`Fakeroot and - Pseudo <#fakeroot-and-pseudo>`__" section. + Thanks to Pseudo, the Yocto Project never needs root privileges to + build images for your target system. + + You can read more about Pseudo in the + ":ref:`overview-manual/concepts:fakeroot and pseudo`" section. Open-Embedded Build System Components ------------------------------------- @@ -479,9 +481,9 @@ The following list consists of components associated with the Sharing a core set of metadata results in Poky as an integration layer on top of OE-Core. You can see that in this - `figure <#yp-key-dev-elements>`__. The Yocto Project combines various - components such as BitBake, OE-Core, script "glue", and documentation - for its build system. + :ref:`figure <overview-manual/yp-intro:what is the yocto project?>`. + The Yocto Project combines various components such as BitBake, OE-Core, + script "glue", and documentation for its build system. Reference Distribution (Poky) ----------------------------- @@ -489,8 +491,8 @@ Reference Distribution (Poky) Poky is the Yocto Project reference distribution. It contains the :term:`OpenEmbedded Build System` (BitBake and OE-Core) as well as a set of metadata to get you started -building your own distribution. See the -`figure <#what-is-the-yocto-project>`__ in "What is the Yocto Project?" +building your own distribution. See the figure in +":ref:`overview-manual/yp-intro:what is the yocto project?`" section for an illustration that shows Poky and its relationship with other parts of the Yocto Project. @@ -502,8 +504,9 @@ To use the Yocto Project tools and components, you can download Poky does not contain binary files. It is a working example of how to build your own custom Linux distribution from source. -You can read more about Poky in the "`Reference Embedded Distribution -(Poky) <#reference-embedded-distribution>`__" section. +You can read more about Poky in the +":ref:`overview-manual/yp-intro:reference embedded distribution (poky)`" +section. Packages for Finished Targets ----------------------------- @@ -566,19 +569,19 @@ Linux. 3. *CROPS:* The final and best solution available now for developing using the Yocto Project on a system not native to Linux is with - `CROPS <#gs-crops-overview>`__. + :ref:`CROPS <overview-manual/yp-intro:development tools>`. Development Methods =================== -The Yocto Project development environment usually involves a +The Yocto Project development environment usually involves a :term:`Build Host` and target hardware. You use the Build Host to build images and develop -applications, while you use the target hardware to test deployed +applications, while you use the target hardware to execute deployed software. This section provides an introduction to the choices or development -methods you have when setting up your Build Host. Depending on the your +methods you have when setting up your Build Host. Depending on your particular workflow preference and the type of operating system your Build Host runs, several choices exist that allow you to use the Yocto Project. @@ -593,11 +596,11 @@ Project. system running Linux as its native operating system allows you to develop software by directly using the :term:`BitBake` tool. You can - accomplish all aspects of development from a familiar shell of a + accomplish all aspects of development from a regular shell in a supported Linux distribution. For information on how to set up a Build Host on a system running - Linux as its native operating system, see the + Linux as its native operating system, see the ":ref:`dev-manual/start:setting up a native linux host`" section in the Yocto Project Development Tasks Manual. @@ -622,7 +625,7 @@ Project. section in the Yocto Project Development Tasks Manual. - *Windows Subsystem For Linux (WSLv2):* You may use Windows Subsystem - For Linux v2 to set up a build host using Windows 10. + For Linux v2 to set up a Build Host using Windows 10. .. note:: @@ -631,8 +634,7 @@ Project. still decide to use WSL please upgrade to WSLv2. The Windows Subsystem For Linux allows Windows 10 to run a real Linux - kernel inside of a lightweight utility virtual machine (VM) using - virtualization technology. + kernel inside of a lightweight virtual machine (VM). For information on how to set up a Build Host with WSLv2, see the ":ref:`dev-manual/start:setting up to use windows subsystem for linux (wslv2)`" @@ -641,12 +643,11 @@ Project. - *Toaster:* Regardless of what your Build Host is running, you can use Toaster to develop software using the Yocto Project. Toaster is a web interface to the Yocto Project's :term:`OpenEmbedded Build System`. - The interface - enables you to configure and run your builds. Information about - builds is collected and stored in a database. You can use Toaster to - configure and start builds on multiple remote build servers. + The interface allows you to configure and run your builds. Information + about builds is collected and stored in a database. You can use Toaster + to configure and start builds on multiple remote build servers. - For information about and how to use Toaster, see the + For information about and how to use Toaster, see the :doc:`/toaster-manual/index`. Reference Embedded Distribution (Poky) @@ -654,14 +655,12 @@ Reference Embedded Distribution (Poky) "Poky", which is pronounced *Pock*-ee, is the name of the Yocto Project's reference distribution or Reference OS Kit. Poky contains the -:term:`OpenEmbedded Build System` -(:term:`BitBake` and -:term:`OpenEmbedded-Core (OE-Core)`) as well as a set -of :term:`Metadata` to get you started -building your own distro. In other words, Poky is a base specification -of the functionality needed for a typical embedded system as well as the -components from the Yocto Project that allow you to build a distribution -into a usable binary image. +:term:`OpenEmbedded Build System` (:term:`BitBake` and +:term:`OpenEmbedded-Core (OE-Core)`) as well as a set of +:term:`Metadata` to get you started building your own distro. In other +words, Poky is a base specification of the functionality needed for a +typical embedded system as well as the components from the Yocto Project +that allow you to build a distribution into a usable binary image. Poky is a combined repository of BitBake, OpenEmbedded-Core (which is found in ``meta``), ``meta-poky``, ``meta-yocto-bsp``, and documentation @@ -730,7 +729,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 <#the-yocto-project-layer-model>`__ that extend functionality. +`layers <overview-manual/yp-intro:the yocto project layer model>` that extend +functionality. These layers can provide, for example, an additional software stack for an image type, add a board support package (BSP) for additional hardware, or even create a new image type. @@ -787,8 +787,8 @@ Following is a brief summary of the "workflow": 7. The build system generates the file system image and a customized Extensible SDK (eSDK) for application development in parallel. -For a very detailed look at this workflow, see the "`OpenEmbedded Build -System Concepts <#openembedded-build-system-build-concepts>`__" section. +For a very detailed look at this workflow, see the +":ref:`overview-manual/concepts:openembedded build system concepts`" section. Some Basic Terms ================ @@ -816,14 +816,14 @@ helpful for getting started: isolate information used when building for multiple architectures. Layers are hierarchical in their ability to override previous specifications. You can include any number of available layers from - the Yocto Project and customize the build by adding your layers after - them. You can search the Layer Index for layers used within Yocto - Project. + the Yocto Project and customize the build by adding your own layers + after them. You can search the Layer Index for layers used within + Yocto Project. - For more detailed information on layers, see the + For more detailed information on layers, see the ":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 + discussion specifically on BSP Layers, see the ":ref:`bsp-guide/bsp:bsp layers`" section in the Yocto Project Board Support Packages (BSP) Developer's Guide. @@ -851,7 +851,7 @@ helpful for getting started: BitBake is similar to the ``make`` tool. During a build process, the build system tracks dependencies and - performs a native or cross-compilation of the package. As a first + performs a native or cross-compilation of each package. As a first step in a cross-build setup, the framework attempts to create a cross-compiler toolchain (i.e. Extensible SDK) suited for the target platform. @@ -878,7 +878,8 @@ helpful for getting started: subtle meanings. For example, the packages referred to in the ":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. + that, when installed, add functionality to your host Linux + distribution. Another point worth noting is that historically within the Yocto Project, recipes were referred to as packages - thus, the existence diff --git a/poky/documentation/poky.yaml b/poky/documentation/poky.yaml index 3c30c4430..8ccb359e0 100644 --- a/poky/documentation/poky.yaml +++ b/poky/documentation/poky.yaml @@ -1,17 +1,17 @@ -DISTRO : "3.2.2" +DISTRO : "3.2.3" DISTRO_NAME_NO_CAP : "gatesgarth" DISTRO_NAME : "Gatesgarth" DISTRO_NAME_NO_CAP_MINUS_ONE : "dunfell" DISTRO_NAME_NO_CAP_LTS : "dunfell" -YOCTO_DOC_VERSION : "3.2.2" +YOCTO_DOC_VERSION : "3.2.3" YOCTO_DOC_VERSION_MINUS_ONE : "3.1.6" -DISTRO_REL_TAG : "yocto-3.2.2" -POKYVERSION : "24.0.2" +DISTRO_REL_TAG : "yocto-3.2.3" +POKYVERSION : "24.0.3" YOCTO_POKY : "poky-&DISTRO_NAME_NO_CAP;-&POKYVERSION;" YOCTO_DL_URL : "https://downloads.yoctoproject.org" YOCTO_AB_URL : "https://autobuilder.yoctoproject.org" YOCTO_RELEASE_DL_URL : "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;" -UBUNTU_HOST_PACKAGES_ESSENTIAL : "gawk wget git-core diffstat unzip texinfo gcc-multilib \ +UBUNTU_HOST_PACKAGES_ESSENTIAL : "gawk wget git diffstat unzip texinfo gcc \ build-essential chrpath socat cpio python3 python3-pip python3-pexpect \ xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \ pylint3 xterm python3-subunit mesa-common-dev" @@ -40,3 +40,7 @@ CENTOS8_HOST_PACKAGES_ESSENTIAL : "-y epel-release python3-GitPython python3-jinja2 python3-pexpect xz which SDL-devel xterm \ rpcgen mesa-libGL-devel" PIP3_HOST_PACKAGES_DOC : "$ sudo pip3 install sphinx sphinx_rtd_theme pyyaml" +MIN_PYTHON_VERSION : "3.6.0" +MIN_TAR_VERSION : "1.28" +MIN_GIT_VERSION : "1.8.3.1" +MIN_GCC_VERSION : "5.0" diff --git a/poky/documentation/profile-manual/usage.rst b/poky/documentation/profile-manual/usage.rst index b401cf904..c42f5b64b 100644 --- a/poky/documentation/profile-manual/usage.rst +++ b/poky/documentation/profile-manual/usage.rst @@ -100,8 +100,8 @@ Using perf to do Basic Profiling As a simple test case, we'll profile the 'wget' of a fairly large file, which is a minimally interesting case because it has both file and network I/O aspects, and at least in the case of standard Yocto images, -it's implemented as part of busybox, so the methods we use to analyze it -can be used in a very similar way to the whole host of supported busybox +it's implemented as part of BusyBox, so the methods we use to analyze it +can be used in a very similar way to the whole host of supported BusyBox applets in Yocto. :: root@crownbay:~# rm linux-2.6.19.2.tar.bz2; \ @@ -251,12 +251,12 @@ As a bit of background explanation for these callchains, think about what happens at a high level when you run wget to get a file out on the network. Basically what happens is that the data comes into the kernel via the network connection (socket) and is passed to the userspace -program 'wget' (which is actually a part of busybox, but that's not +program 'wget' (which is actually a part of BusyBox, but that's not important for now), which takes the buffers the kernel passes to it and writes it to a disk file to save it. The part of this process that we're looking at in the above call stacks -is the part where the kernel passes the data it's read from the socket +is the part where the kernel passes the data it has read from the socket down to wget i.e. a copy-to-user. Notice also that here there's also a case where the hex value is @@ -277,16 +277,16 @@ Now that we've seen the basic layout of the profile data and the basics of how to extract useful information out of it, let's get back to the task at hand and see if we can get some basic idea about where the time is spent in the program we're profiling, wget. Remember that wget is -actually implemented as an applet in busybox, so while the process name -is 'wget', the executable we're actually interested in is busybox. So -let's expand the first entry containing busybox: +actually implemented as an applet in BusyBox, so while the process name +is 'wget', the executable we're actually interested in is BusyBox. So +let's expand the first entry containing BusyBox: .. image:: figures/perf-wget-busybox-expanded-stripped.png :align: center 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. -Expanding the busybox entry doesn't make it any better. +Expanding the BusyBox entry doesn't make it any better. The problem is that perf can't find the symbol information for the busybox binary, which is actually stripped out by the Yocto build @@ -299,7 +299,7 @@ when you build the image: :: However, we already have an image with the binaries stripped, so what can we do to get perf to resolve the symbols? Basically we need to -install the debuginfo for the busybox package. +install the debuginfo for the BusyBox package. To generate the debug info for the packages in the image, we can add ``dbg-pkgs`` to :term:`EXTRA_IMAGE_FEATURES` in ``local.conf``. For example: :: @@ -314,7 +314,7 @@ in the ``local.conf`` file: :: PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory' Once we've done that, we can install the -debuginfo for busybox. The debug packages once built can be found in +debuginfo for BusyBox. The debug packages once built can be found in ``build/tmp/deploy/rpm/*`` on the host system. Find the busybox-dbg-...rpm file and copy it to the target. For example: :: @@ -325,7 +325,7 @@ Now install the debug rpm on the target: :: root@crownbay:~# rpm -i busybox-dbg-1.20.2-r2.core2_32.rpm -Now that the debuginfo is installed, we see that the busybox entries now display +Now that the debuginfo is installed, we see that the BusyBox entries now display their functions symbolically: .. image:: figures/perf-wget-busybox-debuginfo.png @@ -345,11 +345,11 @@ expanded all the nodes using the 'E' key): .. image:: figures/perf-wget-busybox-dso-zoom.png :align: center -Finally, we can see that now that the busybox debuginfo is installed, +Finally, we can see that now that the BusyBox debuginfo is installed, the previously unresolved symbol in the ``sys_clock_gettime()`` entry mentioned previously is now resolved, and shows that the sys_clock_gettime system call that was the source of 6.75% of the -copy-to-user overhead was initiated by the ``handle_input()`` busybox +copy-to-user overhead was initiated by the ``handle_input()`` BusyBox function: .. image:: figures/perf-wget-g-copy-to-user-expanded-debuginfo.png @@ -1580,7 +1580,7 @@ events in the output buffer: :: root@sugarbay:/sys/kernel/debug/tracing# echo nop > current_tracer root@sugarbay:/sys/kernel/debug/tracing# echo 1 > tracing_on -Now, if we look at the the 'trace' file, we see nothing +Now, if we look at the 'trace' file, we see nothing but the kmalloc events we just turned on: :: root@sugarbay:/sys/kernel/debug/tracing# cat trace | less @@ -1900,7 +1900,7 @@ the target: :: meta-toolchain meta-ide-support - You can also run generated qemu images with a command like 'runqemu qemux86-64' + You can also run generated QEMU images with a command like 'runqemu qemux86-64' Once you've done that, you can cd to whatever directory contains your scripts and use 'crosstap' to run the script: :: diff --git a/poky/documentation/ref-manual/TODO b/poky/documentation/ref-manual/TODO index ee0db977c..0510f5471 100644 --- a/poky/documentation/ref-manual/TODO +++ b/poky/documentation/ref-manual/TODO @@ -1,10 +1,10 @@ Handbook Todo List: - * Document adding a new IMAGE_FEATURE to the customising images section + * Document adding a new IMAGE_FEATURE to the customising images section * Add instructions about using zaurus/openmoko emulation * Add component overview/block diagrams - * Software Deevelopment intro should mention its software development for - intended target and could be a different arch etc and thus special case. + * Software Development intro should mention its software development for + intended target and could be a different arch etc and thus special case. * Expand insane.bbclass documentation to cover tests * Document remaining classes (see list in ref-classes) * Document formfactor diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst index be112e0fa..52a50faf6 100644 --- a/poky/documentation/ref-manual/classes.rst +++ b/poky/documentation/ref-manual/classes.rst @@ -501,29 +501,6 @@ Support for other version control systems such as Subversion is limited due to BitBake's automatic fetch dependencies (e.g. ``subversion-native``). -.. _ref-classes-distutils: - -``distutils*.bbclass`` -====================== - -The ``distutils*`` classes support recipes for Python version 2.x -extensions, which are simple. These recipes usually only need to point -to the source's archive and then inherit the proper class. Building is -split into two methods depending on which method the module authors -used. - -- Extensions that use an Autotools-based build system require Autotools - and the classes based on ``distutils`` in their recipes. - -- Extensions that use build systems based on ``distutils`` require the - ``distutils`` class in their recipes. - -- Extensions that use build systems based on ``setuptools`` require the - :ref:`setuptools <ref-classes-setuptools>` class in their recipes. - -The ``distutils-common-base`` class is required by some of the -``distutils*`` classes to provide common Python2 support. - .. _ref-classes-distutils3: ``distutils3*.bbclass`` @@ -542,15 +519,9 @@ used. ``distutils`` class in their recipes. - Extensions that use build systems based on ``setuptools3`` require - the :ref:`setuptools3 <ref-classes-setuptools>` class in their + the :ref:`setuptools3 <ref-classes-setuptools3>` class in their recipes. -The ``distutils3*`` classes either inherit their corresponding -``distutils*`` class or replicate them using a Python3 version instead -(e.g. ``distutils3-base`` inherits ``distutils-common-base``, which is -the same as ``distutils-base`` but inherits ``python3native`` instead of -``pythonnative``). - .. _ref-classes-externalsrc: ``externalsrc.bbclass`` @@ -1426,7 +1397,7 @@ Only a single U-boot boot script can be added to the FIT image created by The boot script is specified in the ITS file as a text file containing U-boot commands. When using a boot script the user should configure the U-boot ``do_install`` task to copy the script to sysroot. -So the script can be included in the the FIT image by the ``kernel-fitimage`` +So the script can be included in the FIT image by the ``kernel-fitimage`` class. At run-time, U-boot CONFIG_BOOTCOMMAND define can be configured to load the boot script from the FIT image and executes it. @@ -2138,13 +2109,13 @@ For information on setting up and running ptests, see the ":ref:`dev-manual/common-tasks:testing packages with ptest`" section in the Yocto Project Development Tasks Manual. -.. _ref-classes-python-dir: +.. _ref-classes-python3-dir: -``python-dir.bbclass`` -====================== +``python3-dir.bbclass`` +======================= -The ``python-dir`` class provides the base version, location, and site -package location for Python. +The ``python3-dir`` class provides the base version, location, and site +package location for Python 3. .. _ref-classes-python3native: @@ -2155,14 +2126,17 @@ The ``python3native`` class supports using the native version of Python 3 built by the build system rather than support of the version provided by the build host. -.. _ref-classes-pythonnative: +.. _ref-classes-python3targetconfig: -``pythonnative.bbclass`` -======================== +``python3targetconfig.bbclass`` +=============================== -When inherited by a recipe, the ``pythonnative`` class supports using -the native version of Python built by the build system rather than using -the version provided by the build host. +The ``python3targetconfig`` class supports using the native version of Python +3 built by the build system rather than support of the version provided +by the build host, except that the configuration for the target machine +is accessible (such as correct installation directories). This also adds a +dependency on target ``python3``, so should only be used where appropriate +in order to avoid unnecessarily lengthening builds. .. _ref-classes-qemu: @@ -2323,22 +2297,13 @@ additional configuration options you want to pass SCons command line. The ``sdl`` class supports recipes that need to build software that uses the Simple DirectMedia Layer (SDL) library. -.. _ref-classes-setuptools: - -``setuptools.bbclass`` -====================== - -The ``setuptools`` class supports Python version 2.x extensions that use -build systems based on ``setuptools``. If your recipe uses these build -systems, the recipe needs to inherit the ``setuptools`` class. - .. _ref-classes-setuptools3: ``setuptools3.bbclass`` ======================= The ``setuptools3`` class supports Python version 3.x extensions that -use build systems based on ``setuptools3``. If your recipe uses these +use build systems based on ``setuptools``. If your recipe uses these build systems, the recipe needs to inherit the ``setuptools3`` class. .. _ref-classes-sign_rpm: diff --git a/poky/documentation/ref-manual/devtool-reference.rst b/poky/documentation/ref-manual/devtool-reference.rst index 5075f0c22..629aa2ffb 100644 --- a/poky/documentation/ref-manual/devtool-reference.rst +++ b/poky/documentation/ref-manual/devtool-reference.rst @@ -178,8 +178,8 @@ resides in ``/home/user/sources/jackson``: $ devtool add jackson /home/user/sources/jackson If you add a recipe and the workspace layer does not exist, the command -creates the layer and populates it as described in "`The Workspace Layer -Structure <#devtool-the-workspace-layer-structure>`__" section. +creates the layer and populates it as described in +":ref:`devtool-the-workspace-layer-structure`" section. Running ``devtool add`` when the workspace layer exists causes the tool to add the recipe, append files, and source files into the existing diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst index 34b26ee3e..64fdfdf75 100644 --- a/poky/documentation/ref-manual/faq.rst +++ b/poky/documentation/ref-manual/faq.rst @@ -16,7 +16,7 @@ first before being pulled back into Poky. This practice benefits both projects immediately. **Q:** My development system does not meet the required Git, tar, and -Python versions. In particular, I do not have Python 3.5.0 or greater. +Python versions. In particular, I do not have Python &MIN_PYTHON_VERSION; or greater. Can I still use the Yocto Project? **A:** You can get the required tools on your host development system a @@ -449,7 +449,7 @@ variable ``bindir``. The makefile's hardcoded default value of "/usr/bin" worked most of the time, but not for the recipe's ``-native`` variant. For another example, permissions errors might be caused by a Makefile that ignores ``DESTDIR`` or uses a different name for that -environment variable. Check the the build system to see if these kinds +environment variable. Check the build system to see if these kinds of issues exist. **Q:** I'm adding a binary in a recipe but it's different in the image, what is diff --git a/poky/documentation/ref-manual/kickstart.rst b/poky/documentation/ref-manual/kickstart.rst index 472820f16..b87cdc13b 100644 --- a/poky/documentation/ref-manual/kickstart.rst +++ b/poky/documentation/ref-manual/kickstart.rst @@ -33,7 +33,7 @@ Either of these commands creates a partition on the system and uses the following syntax: :: - part [mntpoint] + part [mntpoint] partition [mntpoint] If you do not @@ -55,7 +55,7 @@ must also provide one of the ``--ondrive``, ``--ondisk``, or .. note:: The mount program must understand the PARTUUID syntax you use with - ``--use-uuid`` and non-root *mountpoint*, including swap. The busybox + ``--use-uuid`` and non-root *mountpoint*, including swap. The BusyBox versions of these application are currently excluded. Here is an example that uses "/" as the mountpoint. The command uses diff --git a/poky/documentation/ref-manual/migration-1.3.rst b/poky/documentation/ref-manual/migration-1.3.rst index 12e225b14..0929f490d 100644 --- a/poky/documentation/ref-manual/migration-1.3.rst +++ b/poky/documentation/ref-manual/migration-1.3.rst @@ -1,10 +1,10 @@ .. SPDX-License-Identifier: CC-BY-SA-2.0-UK -Moving to the Yocto Project 1.3 Release -======================================= +Moving to the Yocto Project 1.3 Release (danny) +=============================================== This section provides migration information for moving to the Yocto -Project 1.3 Release from the prior release. +Project 1.3 Release (codename "danny") from the prior release. .. _1.3-local-configuration: diff --git a/poky/documentation/ref-manual/migration-1.4.rst b/poky/documentation/ref-manual/migration-1.4.rst index 0b7e86117..f5fac7a2a 100644 --- a/poky/documentation/ref-manual/migration-1.4.rst +++ b/poky/documentation/ref-manual/migration-1.4.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 1.4 Release -======================================= +Moving to the Yocto Project 1.4 Release (dylan) +=============================================== This section provides migration information for moving to the Yocto -Project 1.4 Release from the prior release. +Project 1.4 Release (codename "dylan") from the prior release. .. _migration-1.4-bitbake: diff --git a/poky/documentation/ref-manual/migration-1.5.rst b/poky/documentation/ref-manual/migration-1.5.rst index 2716bc9cf..c772e51b5 100644 --- a/poky/documentation/ref-manual/migration-1.5.rst +++ b/poky/documentation/ref-manual/migration-1.5.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 1.5 Release -======================================= +Moving to the Yocto Project 1.5 Release (dora) +============================================== This section provides migration information for moving to the Yocto -Project 1.5 Release from the prior release. +Project 1.5 Release (codename "dora") from the prior release. .. _migration-1.5-host-dependency-changes: @@ -298,7 +298,7 @@ Removed and Renamed Recipes - ``libtool-nativesdk`` has been renamed to ``nativesdk-libtool``. - ``tinylogin`` has been removed. It has been replaced by a suid - portion of Busybox. See the "`BusyBox <#busybox>`__" + portion of Busybox. See the ":ref:`migration-1.5-busybox`" section for more information. - ``external-python-tarball`` has been renamed to diff --git a/poky/documentation/ref-manual/migration-1.6.rst b/poky/documentation/ref-manual/migration-1.6.rst index ed155d0df..4c6afab1f 100644 --- a/poky/documentation/ref-manual/migration-1.6.rst +++ b/poky/documentation/ref-manual/migration-1.6.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 1.6 Release -======================================= +Moving to the Yocto Project 1.6 Release (daisy) +=============================================== This section provides migration information for moving to the Yocto -Project 1.6 Release from the prior release. +Project 1.6 Release (codename "daisy") from the prior release. .. _migration-1.6-archiver-class: diff --git a/poky/documentation/ref-manual/migration-1.7.rst b/poky/documentation/ref-manual/migration-1.7.rst index 54544e479..9cf467f28 100644 --- a/poky/documentation/ref-manual/migration-1.7.rst +++ b/poky/documentation/ref-manual/migration-1.7.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 1.7 Release -======================================= +Moving to the Yocto Project 1.7 Release (dizzy) +=============================================== This section provides migration information for moving to the Yocto -Project 1.7 Release from the prior release. +Project 1.7 Release (codename "dizzy") from the prior release. .. _migration-1.7-changes-to-setting-qemu-packageconfig-options: @@ -12,7 +12,7 @@ Changes to Setting QEMU ``PACKAGECONFIG`` Options in ``local.conf`` The QEMU recipe now uses a number of :term:`PACKAGECONFIG` options to enable various optional features. The method used to set defaults for these options -means that existing ``local.conf`` files will need to be be modified to +means that existing ``local.conf`` files will need to be modified to append to ``PACKAGECONFIG`` for ``qemu-native`` and ``nativesdk-qemu`` instead of setting it. In other words, to enable graphical output for QEMU, you should now have these lines in ``local.conf``: diff --git a/poky/documentation/ref-manual/migration-1.8.rst b/poky/documentation/ref-manual/migration-1.8.rst index 73789bd51..ec2b13879 100644 --- a/poky/documentation/ref-manual/migration-1.8.rst +++ b/poky/documentation/ref-manual/migration-1.8.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 1.8 Release -======================================= +Moving to the Yocto Project 1.8 Release (fido) +============================================== This section provides migration information for moving to the Yocto -Project 1.8 Release from the prior release. +Project 1.8 Release (codename "fido") from the prior release. .. _migration-1.8-removed-recipes: diff --git a/poky/documentation/ref-manual/migration-2.0.rst b/poky/documentation/ref-manual/migration-2.0.rst index 4eea94887..9da60dfdc 100644 --- a/poky/documentation/ref-manual/migration-2.0.rst +++ b/poky/documentation/ref-manual/migration-2.0.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 2.0 Release -======================================= +Moving to the Yocto Project 2.0 Release (jethro) +================================================ This section provides migration information for moving to the Yocto -Project 2.0 Release from the prior release. +Project 2.0 Release (codename "jethro") from the prior release. .. _migration-2.0-gcc-5: diff --git a/poky/documentation/ref-manual/migration-2.1.rst b/poky/documentation/ref-manual/migration-2.1.rst index 861d04861..1eb9ab552 100644 --- a/poky/documentation/ref-manual/migration-2.1.rst +++ b/poky/documentation/ref-manual/migration-2.1.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 2.1 Release -======================================= +Moving to the Yocto Project 2.1 Release (krogoth) +================================================= This section provides migration information for moving to the Yocto -Project 2.1 Release from the prior release. +Project 2.1 Release (codename "krogoth") from the prior release. .. _migration-2.1-variable-expansion-in-python-functions: @@ -134,7 +134,7 @@ or that mention ``do_rootfs``, you might need to update those changes. In particular, if you had added any tasks after ``do_rootfs``, you should make edits so that those tasks are after the :ref:`ref-tasks-image-complete` task rather than -after ``do_rootfs`` so that the your added tasks run at the correct +after ``do_rootfs`` so that your added tasks run at the correct time. A minor part of this restructuring is that the post-processing @@ -179,9 +179,8 @@ The following recipes have been removed in the 2.1 release: - ``python-pygtk``: Recipe became obsolete. -- ``adt-installer``: Recipe became obsolete. See the "`ADT - Removed <#adt-removed>`__" section for more - information. +- ``adt-installer``: Recipe became obsolete. See the + ":ref:`ref-manual/migration-2.1:adt removed`" section for more information. .. _migration-2.1-class-changes: diff --git a/poky/documentation/ref-manual/migration-2.2.rst b/poky/documentation/ref-manual/migration-2.2.rst index 5c6fecf32..198181a46 100644 --- a/poky/documentation/ref-manual/migration-2.2.rst +++ b/poky/documentation/ref-manual/migration-2.2.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 2.2 Release -======================================= +Moving to the Yocto Project 2.2 Release (morty) +=============================================== This section provides migration information for moving to the Yocto -Project 2.2 Release from the prior release. +Project 2.2 Release (codename "morty") from the prior release. .. _migration-2.2-minimum-kernel-version: @@ -367,8 +367,8 @@ The following recipes have been removed: - ``sato-icon-theme``: Became obsolete. -- ``swabber-native``: Swabber has been removed. See the `entry on - Swabber <#swabber-has-been-removed>`__. +- ``swabber-native``: Swabber has been removed. See the :ref:`entry on + Swabber <ref-manual/migration-2.2:swabber has been removed>`. - ``tslib``: No longer needed and has been moved to ``meta-oe``. @@ -393,8 +393,8 @@ The following classes have been removed: - ``sip``: Mostly unused. -- ``swabber``: See the `entry on - Swabber <#swabber-has-been-removed>`__. +- ``swabber``: See the :ref:`entry on + Swabber <ref-manual/migration-2.2:swabber has been removed>`. .. _migration-2.2-minor-packaging-changes: diff --git a/poky/documentation/ref-manual/migration-2.3.rst b/poky/documentation/ref-manual/migration-2.3.rst index 04b11daa7..0541eb3e7 100644 --- a/poky/documentation/ref-manual/migration-2.3.rst +++ b/poky/documentation/ref-manual/migration-2.3.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 2.3 Release -======================================= +Moving to the Yocto Project 2.3 Release (pyro) +============================================== This section provides migration information for moving to the Yocto -Project 2.3 Release from the prior release. +Project 2.3 Release (codename "pyro") from the prior release. .. _migration-2.3-recipe-specific-sysroots: diff --git a/poky/documentation/ref-manual/migration-2.4.rst b/poky/documentation/ref-manual/migration-2.4.rst index 260b3204b..2ba17e0ed 100644 --- a/poky/documentation/ref-manual/migration-2.4.rst +++ b/poky/documentation/ref-manual/migration-2.4.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 2.4 Release -======================================= +Moving to the Yocto Project 2.4 Release (rocko) +=============================================== This section provides migration information for moving to the Yocto -Project 2.4 Release from the prior release. +Project 2.4 Release (codename "rocko") from the prior release. .. _migration-2.4-memory-resident-mode: diff --git a/poky/documentation/ref-manual/migration-2.5.rst b/poky/documentation/ref-manual/migration-2.5.rst index 9f45ffce7..9ef4b5539 100644 --- a/poky/documentation/ref-manual/migration-2.5.rst +++ b/poky/documentation/ref-manual/migration-2.5.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 2.5 Release -======================================= +Moving to the Yocto Project 2.5 Release (sumo) +============================================== This section provides migration information for moving to the Yocto -Project 2.5 Release from the prior release. +Project 2.5 Release (codename "sumo") from the prior release. .. _migration-2.5-packaging-changes: diff --git a/poky/documentation/ref-manual/migration-2.6.rst b/poky/documentation/ref-manual/migration-2.6.rst index 5d524f381..aeac50980 100644 --- a/poky/documentation/ref-manual/migration-2.6.rst +++ b/poky/documentation/ref-manual/migration-2.6.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 2.6 Release -======================================= +Moving to the Yocto Project 2.6 Release (thud) +============================================== This section provides migration information for moving to the Yocto -Project 2.6 Release from the prior release. +Project 2.6 Release (codename "thud") from the prior release. .. _migration-2.6-gcc-changes: @@ -110,7 +110,7 @@ upon the older ``*proto`` recipes need to be changed to depend on the newer ``xorgproto`` recipe instead. For names of recipes removed because of this repository change, see the -`Removed Recipes <#removed-recipes>`__ section. +:ref:`ref-manual/migration-2.6:removed recipes` section. .. _migration-2.6-distutils-distutils3-fetching-dependencies: @@ -118,7 +118,7 @@ For names of recipes removed because of this repository change, see the --------------------------------------------------------------------------------------------------- Previously, it was possible for Python recipes that inherited the -:ref:`distutils <ref-classes-distutils>` and +``distutils`` and :ref:`distutils3 <ref-classes-distutils3>` classes to fetch code during the :ref:`ref-tasks-configure` task to satisfy dependencies mentioned in ``setup.py`` if those dependencies were not diff --git a/poky/documentation/ref-manual/migration-2.7.rst b/poky/documentation/ref-manual/migration-2.7.rst index 5af5947ff..1be4d5d5b 100644 --- a/poky/documentation/ref-manual/migration-2.7.rst +++ b/poky/documentation/ref-manual/migration-2.7.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 2.7 Release -======================================= +Moving to the Yocto Project 2.7 Release (warrior) +================================================= This section provides migration information for moving to the Yocto -Project 2.7 Release from the prior release. +Project 2.7 Release (codename "warrior") from the prior release. .. _migration-2.7-bitbake-changes: diff --git a/poky/documentation/ref-manual/migration-3.0.rst b/poky/documentation/ref-manual/migration-3.0.rst index 7ef2742f8..f3d20e2ed 100644 --- a/poky/documentation/ref-manual/migration-3.0.rst +++ b/poky/documentation/ref-manual/migration-3.0.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 3.0 Release -======================================= +Moving to the Yocto Project 3.0 Release (zeus) +============================================== This section provides migration information for moving to the Yocto -Project 3.0 Release from the prior release. +Project 3.0 Release (codename "zeus") from the prior release. .. _migration-3.0-init-system-selection: diff --git a/poky/documentation/ref-manual/migration-3.1.rst b/poky/documentation/ref-manual/migration-3.1.rst index 4fcd2490d..84d32502e 100644 --- a/poky/documentation/ref-manual/migration-3.1.rst +++ b/poky/documentation/ref-manual/migration-3.1.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 3.1 Release -======================================= +Moving to the Yocto Project 3.1 Release (dunfell) +================================================= This section provides migration information for moving to the Yocto -Project 3.1 Release from the prior release. +Project 3.1 Release (codename "dunfell") from the prior release. .. _migration-3.1-minimum-system-requirements: diff --git a/poky/documentation/ref-manual/migration-3.2.rst b/poky/documentation/ref-manual/migration-3.2.rst index 65a9ff4ca..39743af70 100644 --- a/poky/documentation/ref-manual/migration-3.2.rst +++ b/poky/documentation/ref-manual/migration-3.2.rst @@ -1,8 +1,8 @@ -Moving to the Yocto Project 3.2 Release -======================================= +Moving to the Yocto Project 3.2 Release (gatesgarth) +==================================================== This section provides migration information for moving to the Yocto -Project 3.2 Release from the prior release. +Project 3.2 Release (codename "gatesgarth") from the prior release. .. _migration-3.2-minimum-system-requirements: @@ -308,6 +308,6 @@ Miscellaneous changes - Erroneous use of ``inherit +=`` (instead of ``INHERIT +=``) in a configuration file now triggers an error instead of silently being ignored. - ptest support has been removed from the ``kbd`` recipe, as upstream has moved to autotest which is difficult to work with in a cross-compilation environment. - ``oe.utils.is_machine_specific()`` and ``oe.utils.machine_paths()`` have been removed as their utility was questionable. In the unlikely event that you have references to these in your own code, then the code will need to be reworked. -- The ``i2ctransfer`` module is now disabled by default when building ``busybox`` in order to be consistent with disabling the other i2c tools there. If you do wish the i2ctransfer module to be built in busybox then add ``CONFIG_I2CTRANSFER=y`` to your custom busybox configuration. +- The ``i2ctransfer`` module is now disabled by default when building ``busybox`` in order to be consistent with disabling the other i2c tools there. If you do wish the i2ctransfer module to be built in BusyBox then add ``CONFIG_I2CTRANSFER=y`` to your custom BusyBox configuration. - In the ``Upstream-Status`` header convention for patches, ``Accepted`` has been replaced with ``Backport`` as these almost always mean the same thing i.e. the patch is already upstream and may need to be removed in a future recipe upgrade. If you are adding these headers to your own patches then use ``Backport`` to indicate that the patch has been sent upstream. - The ``tune-supersparc.inc`` tune file has been removed as it does not appear to be widely used and no longer works. diff --git a/poky/documentation/ref-manual/migration-3.3.rst b/poky/documentation/ref-manual/migration-3.3.rst new file mode 100644 index 000000000..4fb51a39d --- /dev/null +++ b/poky/documentation/ref-manual/migration-3.3.rst @@ -0,0 +1,168 @@ +Moving to the Yocto Project 3.3 Release (hardknott) +=================================================== + +This section provides migration information for moving to the Yocto +Project 3.3 Release (codename "hardknott") from the prior release. + + +.. _migration-3.3-minimum-system-requirements: + +Minimum system requirements +--------------------------- + +You will now need at least Python 3.6 installed on your build host. Most recent +distributions provide this, but should you be building on a distribution that +does not have it, you can use the ``buildtools-tarball`` (easily installable +using ``scripts/install-buildtools``) - see +:ref:`ref-manual/system-requirements:required git, tar, python and gcc versions` +for details. + + +.. _migration-3.3-removed-recipes: + +Removed recipes +--------------- + +The following recipes have been removed: + +- ``go-dep``: obsolete with the advent of go modules +- ``gst-validate``: replaced by ``gst-devtools`` +- ``linux-yocto``: removed 5.8 version recipes (5.4 / 5.10 still provided) +- ``vulkan-demos``: replaced by ``vulkan-samples`` + + +.. _migration-3.3-common-license-only-versions: + +Single version common license file naming +----------------------------------------- + +Some license files in ``meta/files/common-licenses`` have been renamed to match +current SPDX naming conventions: + +- AGPL-3.0 -> AGPL-3.0-only +- GPL-1.0 -> GPL-1.0-only +- GPL-2.0 -> GPL-2.0-only +- GPL-3.0 -> GPL-3.0-only +- LGPL-2.0 -> LGPL-2.0-only +- LGPL-2.1 -> LGPL-2.1-only +- LGPL-3.0 -> LGPL-3.0-only + +Additionally, corresponding "-or-later" suffixed files have been added e.g. +``GPL-2.0-or-later``. + +It is not required that you change :term:`LICENSE` values as there are mappings +from the original names in place; however, in rare cases where you have a recipe +which sets :term:`LIC_FILES_CHKSUM` to point to file(s) in +``meta/files/common-licenses`` (which in any case is not recommended) you will +need to update those. + + +.. _migration-3.3-python3targetconfig: + +New ``python3targetconfig`` class +--------------------------------- + +A new :ref:`python3targetconfig <ref-classes-python3targetconfig>` class has been +created for situations where you would previously have inherited the +``python3native`` class but need access to target configuration data (such as +correct installation directories). Recipes where this situation applies should +be changed to inherit ``python3targetconfig`` instead of ``python3native``. This +also adds a dependency on target ``python3``, so it should only be used where +appropriate in order to avoid unnecessarily lengthening builds. + +Some example recipes where this change has been made: ``gpgme``, ``libcap-ng``, +``python3-pycairo``. + + +.. _migration-3.3-distutils-path: + +``setup.py`` path for python modules +------------------------------------ + +In a Python module, sometimes ``setup.py`` can be buried deep in the +source tree. Previously this was handled in recipes by setting :term:`S` to +point to the subdirectory within the source where ``setup.py`` is located. +However with the recent :ref:`pseudo <overview-manual/concepts:fakeroot and pseudo>` +changes, some Python modules make changes to files beneath ``${S}``, for +example:: + + S = "${WORKDIR}/git/python/pythonmodule" + +then in ``setup.py`` it works with source code in a relative fashion, such +as ``../../src``. This causes pseudo to abort as it isn't able to track +the paths properly. This release introduces a new :term:`DISTUTILS_SETUP_PATH` +variable so that recipes can specify it explicitly, for example:: + + S = "${WORKDIR}/git" + DISTUTILS_SETUP_PATH = "${S}/python/pythonmodule" + +Recipes that inherit from :ref:`distutils3 <ref-classes-distutils3>` (or +:ref:`setuptools3 <ref-classes-setuptools3>` which itself inherits +:ref:`distutils3 <ref-classes-distutils3>`) that also set :term:`S` to +point to a Python module within a subdirectory in the aforementioned +manner should be changed to set :term:`DISTUTILS_SETUP_PATH` instead. + + +.. _migration-3.3-bitbake: + +BitBake changes +--------------- + +- BitBake is now configured to use a default ``umask`` of ``022`` for all tasks + (specified via a new :term:`BB_DEFAULT_UMASK` variable). If needed, ``umask`` can + still be set on a per-task basis via the ``umask`` varflag on the task + function, but that is unlikely to be necessary in most cases. + +- If a version specified in :term:`PREFERRED_VERSION` is not available this + will now trigger a warning instead of just a note, making such issues more + visible. + + +.. _migration-3.3-packaging: + +Packaging changes +----------------- + +The following packaging changes have been made; in all cases the main package +still depends upon the split out packages so you should not need to do anything +unless you want to take advantage of the improved granularity: + +- ``dbus``: ``-common`` and ``-tools`` split out +- ``iproute2``: split ``ip`` binary to its own package +- ``net-tools``: split ``mii-tool`` into its own package +- ``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 +- ``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``. + (``util-linux`` depends upon ``util-linux-libuuid``.) + + +.. _migration-3.3-misc: + +Miscellaneous changes +--------------------- + +- The default poky :term:`DISTRO_VERSION` value now uses the core metadata's + git hash (i.e. :term:`METADATA_REVISION`) rather than the date (i.e. + :term:`DATE`) to reduce one small source of non-reproducibility. You can + of course specify your own :term:`DISTRO_VERSION` value as desired + (particularly if you create your own custom distro configuration). +- ``adwaita-icon-theme`` version 3.34.3 has been added back, and is selected + as the default via :term:`PREFERRED_VERSION` in + ``meta/conf/distro/include/default-versions.inc`` due to newer versions + not working well with ``librsvg`` 2.40. ``librsvg`` is not practically + upgradeable at the moment as it has been ported to Rust, and Rust is not + (yet) in OE-Core, but this will change in a future release. +- ``ffmpeg`` is now configured to disable GPL-licensed portions by default + to make it harder to accidentally violate the GPL. To explicitly enable GPL + licensed portions, add ``gpl`` to :term:`PACKAGECONFIG` for ``ffmpeg`` + using a bbappend (or use ``PACKAGECONFIG_append_pn-ffmpeg = " gpl"`` in + your configuration.) +- ``connman`` is now set to conflict with ``systemd-networkd`` as they + overlap functionally and may interfere with each other at runtime. +- Canonical SPDX license names are now used in image license manifests in + order to avoid aliases of the same license from showing up together (e.g. + ``GPLv2`` and ``GPL-2.0``) diff --git a/poky/documentation/ref-manual/migration.rst b/poky/documentation/ref-manual/migration.rst index 8d64a7daa..a01d4ee14 100644 --- a/poky/documentation/ref-manual/migration.rst +++ b/poky/documentation/ref-manual/migration.rst @@ -28,4 +28,5 @@ notes for a given release. migration-3.0 migration-3.1 migration-3.2 + migration-3.3 diff --git a/poky/documentation/ref-manual/release-process.rst b/poky/documentation/ref-manual/release-process.rst index ed5a09a55..93ab6ed08 100644 --- a/poky/documentation/ref-manual/release-process.rst +++ b/poky/documentation/ref-manual/release-process.rst @@ -15,9 +15,8 @@ Major and Minor Release Cadence The Yocto Project delivers major releases (e.g. &DISTRO;) using a six month cadence roughly timed each April and October of the year. Following are examples of some major YP releases with their codenames -also shown. See the "`Major Release -Codenames <#major-release-codenames>`__" section for information on -codenames used with major releases. +also shown. See the ":ref:`ref-manual/release-process:major release codenames`" +section for information on codenames used with major releases. - 2.2 (Morty) - 2.1 (Krogoth) @@ -135,7 +134,7 @@ consists of the following pieces: - :ref:`ptest <dev-manual/common-tasks:testing packages with ptest>`: Runs tests against packages produced during the build for a given - piece of software. The test allows the packages to be be run within a + piece of software. The test allows the packages to be run within a target image. - ``oe-selftest``: Tests combination BitBake invocations. These tests diff --git a/poky/documentation/ref-manual/resources.rst b/poky/documentation/ref-manual/resources.rst index 7554164d1..663f0d96d 100644 --- a/poky/documentation/ref-manual/resources.rst +++ b/poky/documentation/ref-manual/resources.rst @@ -91,7 +91,7 @@ For more Yocto Project-related mailing lists, see the Internet Relay Chat (IRC) ========================= -Two IRC channels on freenode are available for the Yocto Project and +Two IRC channels on Freenode are available for the Yocto Project and Poky discussions: - ``#yocto`` @@ -189,7 +189,7 @@ Here is a list of resources you might find helpful: implementation of Bugzilla for logging and tracking Yocto Project defects. -- *Internet Relay Chat (IRC):* Two IRC channels on freenode are +- *Internet Relay Chat (IRC):* Two IRC channels on Freenode are available for Yocto Project and Poky discussions: ``#yocto`` and ``#poky``, respectively. diff --git a/poky/documentation/ref-manual/structure.rst b/poky/documentation/ref-manual/structure.rst index ad3f4ab44..0f2093a8d 100644 --- a/poky/documentation/ref-manual/structure.rst +++ b/poky/documentation/ref-manual/structure.rst @@ -168,7 +168,7 @@ possible targets to build. Here is an example: meta-toolchain meta-ide-support - You can also run generated qemu images with a command like 'runqemu qemux86-64' + You can also run generated QEMU images with a command like 'runqemu qemux86-64' The default output of the ``oe-init-build-env`` script is from the ``conf-notes.txt`` file, which is found in the ``meta-poky`` directory diff --git a/poky/documentation/ref-manual/system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst index c8c1381cb..80378cedb 100644 --- a/poky/documentation/ref-manual/system-requirements.rst +++ b/poky/documentation/ref-manual/system-requirements.rst @@ -59,7 +59,7 @@ distributions: - Debian GNU/Linux 10.x (Buster) -- OpenSUSE Leap 15.1 +- openSUSE Leap 15.1 .. note:: @@ -256,11 +256,11 @@ Required Git, tar, Python and gcc Versions In order to use the build system, your host development system must meet the following version requirements for Git, tar, and Python: -- Git 1.8.3.1 or greater +- Git &MIN_GIT_VERSION; or greater -- tar 1.28 or greater +- tar &MIN_TAR_VERSION; or greater -- Python 3.5.0 or greater +- Python &MIN_PYTHON_VERSION; or greater If your host development system does not meet all these requirements, you can resolve this by installing a ``buildtools`` tarball that @@ -270,11 +270,15 @@ a pre-built tarball or use BitBake to build the tarball. In addition, your host development system must meet the following version requirement for gcc: -- gcc 5.0 or greater +- gcc &MIN_GCC_VERSION; or greater If your host development system does not meet this requirement, you can resolve this by installing a ``buildtools-extended`` tarball that -contains additional tools, the equivalent of ``buildtools-essential``. +contains additional tools, the equivalent of the Debian/Ubuntu ``build-essential`` +package. + +In the sections that follow, three different methods will be described for +installing the ``buildtools`` or ``buildtools-extended`` toolset. Installing a Pre-Built ``buildtools`` Tarball with ``install-buildtools`` script -------------------------------------------------------------------------------- @@ -294,7 +298,7 @@ installer and automatically installs the tools for you: During execution, the buildtools tarball will be downloaded, the checksum of the download will be verified, the installer will be run - for you, and some basic checks will be run to to make sure the + for you, and some basic checks will be run to make sure the installation is functional. To avoid the need of ``sudo`` privileges, the ``install-buildtools`` @@ -331,8 +335,9 @@ installer and automatically installs the tools for you: Downloading a Pre-Built ``buildtools`` Tarball ---------------------------------------------- -Downloading and running a pre-built buildtools installer is the easiest -of the two methods by which you can get these tools: +If you would prefer not to use the ``install-buildtools`` script, you can instead +download and run a pre-built buildtools installer yourself with the following +steps: 1. Locate and download the ``*.sh`` at &YOCTO_RELEASE_DL_URL;/buildtools/ diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst index 0310429bd..74ac12bf9 100644 --- a/poky/documentation/ref-manual/variables.rst +++ b/poky/documentation/ref-manual/variables.rst @@ -768,9 +768,7 @@ system and gives an overview of their function and contents. .. note:: If you run BitBake from a directory outside of the - Build Directory - , you must be sure to set - BBPATH + :term:`Build Directory`, you must be sure to set ``BBPATH`` to point to the Build Directory. Set the variable as you would any environment variable and then run BitBake: :: @@ -1980,6 +1978,19 @@ system and gives an overview of their function and contents. is included in the default value of :term:`OVERRIDES`. + :term:`DISTUTILS_SETUP_PATH` + When used by recipes that inherit the + :ref:`distutils3 <ref-classes-distutils3>` or + :ref:`setuptools3 <ref-classes-setuptools3>` class, this variable should + be used to specify the directory in which the ``setup.py`` file is + located if it is not at the root of the source tree (as specified by + :term:`S`). For example, in a recipe where the sources are fetched from + a Git repository and ``setup.py`` is in a ``python/pythonmodule`` + subdirectory, you would have this:: + + S = "${WORKDIR}/git" + DISTUTILS_SETUP_PATH = "${S}/python/pythonmodule" + :term:`DL_DIR` The central download directory used by the build process to store downloads. By default, ``DL_DIR`` gets files suitable for mirroring @@ -2295,6 +2306,17 @@ system and gives an overview of their function and contents. # usermod -s /bin/sh tester; \ # " + Additionally there is a special ``passwd-expire`` command that will + cause the password for a user to be expired and thus force changing it + on first login, for example:: + + EXTRA_USERS_PARAMS += " useradd myuser; passwd-expire myuser;" + + .. note:: + + At present, ``passwd-expire`` may only work for remote logins when + using OpenSSH and not dropbear as an SSH server. + :term:`FEATURE_PACKAGES` Defines one or more packages to include in an image when a specific item is included in :term:`IMAGE_FEATURES`. @@ -2571,6 +2593,16 @@ system and gives an overview of their function and contents. :term:`FIT_HASH_ALG` Specifies the hash algorithm used in creating the FIT Image. For e.g. sha256. + :term:`FIT_KERNEL_COMP_ALG` + Compression algorithm to use for the kernel image inside the FIT Image. + At present, the only supported values are "gzip" (default) or "none" + If you set this variable to anything other than "none" you may also need + to set :term:`FIT_KERNEL_COMP_ALG_EXTENSION`. + + :term:`FIT_KERNEL_COMP_ALG_EXTENSION` + File extension corresponding to :term:`FIT_KERNEL_COMP_ALG`. The default + value is ".gz". + :term:`FIT_KEY_GENRSA_ARGS` Arguments to openssl genrsa for generating RSA private key for signing fitImage. The default value is "-F4". i.e. the public exponent 65537 to @@ -2582,7 +2614,7 @@ system and gives an overview of their function and contents. and new for generating new keys. :term:`FIT_KEY_SIGN_PKCS` - Format for public key ceritifcate used in signing fitImage. + Format for public key certificate used in signing fitImage. The default value is "x509". :term:`FIT_SIGN_ALG` @@ -2991,7 +3023,7 @@ system and gives an overview of their function and contents. :term:`IMAGE_CMD` Specifies the command to create the image file for a specific image - type, which corresponds to the value set set in + type, which corresponds to the value set in :term:`IMAGE_FSTYPES`, (e.g. ``ext3``, ``btrfs``, and so forth). When setting this variable, you should use an override for the associated type. Here is an example: @@ -3449,7 +3481,7 @@ system and gives an overview of their function and contents. It is possible to define a list of licenses that are allowed to be used instead of the licenses that are excluded. To do this, define - a variable ``COMPATIBLE_LICENSES`` with the names of the licences + a variable ``COMPATIBLE_LICENSES`` with the names of the licenses that are allowed. Then define ``INCOMPATIBLE_LICENSE`` as: :: @@ -3457,8 +3489,8 @@ system and gives an overview of their function and contents. This will result in ``INCOMPATIBLE_LICENSE`` containing the names of - all licences from :term:`AVAILABLE_LICENSES` except the ones specified - in ``COMPATIBLE_LICENSES`` , thus only allowing the latter licences to + all licenses from :term:`AVAILABLE_LICENSES` except the ones specified + in ``COMPATIBLE_LICENSES``, thus only allowing the latter licenses to be used. :term:`INHERIT` @@ -4661,6 +4693,14 @@ system and gives an overview of their function and contents. :term:`MAINTAINER` The email address of the distribution maintainer. + :term:`METADATA_BRANCH` + The branch currently checked out for the OpenEmbedded-Core layer (path + determined by :term:`COREBASE`). + + :term:`METADATA_REVISION` + The revision currently checked out for the OpenEmbedded-Core layer (path + determined by :term:`COREBASE`). + :term:`MIRRORS` Specifies additional paths from which the OpenEmbedded build system gets source code. When the build system searches for source code, it @@ -5011,7 +5051,7 @@ system and gives an overview of their function and contents. ${PN}-${PV} :term:`PACKAGE_ADD_METADATA` - This variable defines additional metdata to add to packages. + This variable defines additional metadata to add to packages. You may find you need to inject additional metadata into packages. This variable allows you to do that by setting the injected data as @@ -5792,10 +5832,11 @@ system and gives an overview of their function and contents. exclusive alternative providers. :term:`PREFERRED_VERSION` - If multiple versions of recipes exist, this variable determines which - version is given preference. You must always suffix the variable with - the :term:`PN` you want to select, and you should set the - :term:`PV` accordingly for precedence. + If there are multiple versions of a recipe available, this variable + determines which version should be given preference. You must always + suffix the variable with the :term:`PN` you want to select (`python` in + the first example below), and you should specify the :term:`PV` + accordingly (`3.4.0` in the example). The ``PREFERRED_VERSION`` variable supports limited wildcard use through the "``%``" character. You can use the character to match any @@ -5853,6 +5894,10 @@ system and gives an overview of their function and contents. The ``\_forcevariable`` override is not handled specially. This override only works because the default value of ``OVERRIDES`` includes "forcevariable". + If a recipe with the specified version is not available, a warning + message will be shown. See :term:`REQUIRED_VERSION` if you want this + to be an error instead. + :term:`PREMIRRORS` Specifies additional paths from which the OpenEmbedded build system gets source code. When the build system searches for source code, it @@ -6019,9 +6064,7 @@ system and gives an overview of their function and contents. :term:`PYTHON_ABI` When used by recipes that inherit the :ref:`distutils3 <ref-classes-distutils3>`, - :ref:`setuptools3 <ref-classes-setuptools3>`, - :ref:`distutils <ref-classes-distutils>`, or - :ref:`setuptools <ref-classes-setuptools>` classes, denotes the + :ref:`setuptools3 <ref-classes-setuptools3>` classes, denotes the Application Binary Interface (ABI) currently in use for Python. By default, the ABI is "m". You do not have to set this variable as the OpenEmbedded build system sets it for you. @@ -6030,16 +6073,14 @@ system and gives an overview of their function and contents. names used when installing the Python headers and libraries in sysroot (e.g. ``.../python3.3m/...``). - Recipes that inherit the ``distutils`` class during cross-builds also + Recipes that inherit the ``distutils3`` class during cross-builds also use this variable to locate the headers and libraries of the appropriate Python that the extension is targeting. :term:`PYTHON_PN` When used by recipes that inherit the `distutils3 <ref-classes-distutils3>`, - :ref:`setuptools3 <ref-classes-setuptools3>`, - :ref:`distutils <ref-classes-distutils>`, or - :ref:`setuptools <ref-classes-setuptools>` classes, specifies the + :ref:`setuptools3 <ref-classes-setuptools3>` classes, specifies the major Python version being built. For Python 3.x, ``PYTHON_PN`` would be "python3". You do not have to set this variable as the OpenEmbedded build system automatically sets it for you. @@ -6210,6 +6251,17 @@ system and gives an overview of their function and contents. the recipe will be skipped, and if the build system attempts to build the recipe then an error will be triggered. + :term:`REQUIRED_VERSION` + If there are multiple versions of a recipe available, this variable + determines which version should be given preference. + :term:`REQUIRED_VERSION` works in exactly the same manner as + :term:`PREFERRED_VERSION`, except that if the specified version is not + available then an error message is shown and the build fails + immediately. + + If both :term:`REQUIRED_VERSION` and :term:`PREFERRED_VERSION` are set + for the same recipe, the :term:`REQUIRED_VERSION` value applies. + :term:`RM_WORK_EXCLUDE` With ``rm_work`` enabled, this variable specifies a list of recipes whose work directories should not be removed. See the @@ -6483,6 +6535,11 @@ system and gives an overview of their function and contents. The target architecture for the SDK. Typically, you do not directly set this variable. Instead, use :term:`SDKMACHINE`. + :term:`SDK_CUSTOM_TEMPLATECONF` + When building the extensible SDK, if ``SDK_CUSTOM_TEMPLATECONF`` is set to + "1" and a ``conf/templateconf.conf`` file exists in the build directory + (:term:`TOPDIR`) then this will be copied into the SDK. + :term:`SDK_DEPLOY` The directory set up and used by the :ref:`populate_sdk_base <ref-classes-populate-sdk>` class to which @@ -6758,16 +6815,16 @@ system and gives an overview of their function and contents. Specifies the name of the SDK vendor. :term:`SDK_VERSION` - Specifies the version of the SDK. The distribution configuration file - (e.g. ``/meta-poky/conf/distro/poky.conf``) defines the + Specifies the version of the SDK. The Poky distribution configuration file + (``/meta-poky/conf/distro/poky.conf``) sets the default ``SDK_VERSION`` as follows: :: - SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}','snapshot')}" + SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${METADATA_REVISION}', 'snapshot')}" For additional information, see the :term:`DISTRO_VERSION` and - :term:`DATE` variables. + :term:`METADATA_REVISION` variables. :term:`SDKEXTPATH` The default installation directory for the Extensible SDK. By @@ -7092,7 +7149,7 @@ system and gives an overview of their function and contents. - ``git://`` - Fetches files from a Git revision control repository. - - ``osc://`` - Fetches files from an OSC (OpenSUSE Build service) + - ``osc://`` - Fetches files from an OSC (openSUSE Build service) revision control repository. - ``repo://`` - Fetches files from a repo (Git) repository. diff --git a/poky/documentation/releases.rst b/poky/documentation/releases.rst index c4865253f..6a65b9fb3 100644 --- a/poky/documentation/releases.rst +++ b/poky/documentation/releases.rst @@ -11,6 +11,7 @@ - :yocto_docs:`3.2 Documentation </3.2>` - :yocto_docs:`3.2.1 Documentation </3.2.1>` - :yocto_docs:`3.2.2 Documentation </3.2.2>` +- :yocto_docs:`3.2.3 Documentation </3.2.3>` **************************** 3.1 'dunfell' Release Series @@ -36,6 +37,7 @@ - :yocto_docs:`3.0.1 Documentation </3.0.1>` - :yocto_docs:`3.0.2 Documentation </3.0.2>` - :yocto_docs:`3.0.3 Documentation </3.0.3>` +- :yocto_docs:`3.0.4 Documentation </3.0.4>` **************************** 2.7 'warrior' Release Series diff --git a/poky/documentation/sdk-manual/appendix-customizing.rst b/poky/documentation/sdk-manual/appendix-customizing.rst index 97ade0801..8e7115046 100644 --- a/poky/documentation/sdk-manual/appendix-customizing.rst +++ b/poky/documentation/sdk-manual/appendix-customizing.rst @@ -101,17 +101,15 @@ adjustments: - Generally, you want to have a shared state mirror set up so users of the SDK can add additional items to the SDK after installation - without needing to build the items from source. See the "`Providing - Additional Installable Extensible SDK - Content <#sdk-providing-additional-installable-extensible-sdk-content>`__" + without needing to build the items from source. See the + ":ref:`sdk-manual/appendix-customizing:providing additional installable extensible sdk content`" section for information. - If you want users of the SDK to be able to easily update the SDK, you need to set the :term:`SDK_UPDATE_URL` - variable. For more information, see the "`Providing Updates to the - Extensible SDK After - Installation <#sdk-providing-updates-to-the-extensible-sdk-after-installation>`__" + variable. For more information, see the + ":ref:`sdk-manual/appendix-customizing:providing updates to the extensible sdk after installation`" section. - If you have adjusted the list of files and directories that appear in @@ -139,9 +137,9 @@ Changing the Extensible SDK Installer Title You can change the displayed title for the SDK installer by setting the :term:`SDK_TITLE` variable and then -rebuilding the the SDK installer. For information on how to build an SDK -installer, see the "`Building an SDK -Installer <#sdk-building-an-sdk-installer>`__" section. +rebuilding the SDK installer. For information on how to build an SDK +installer, see the ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" +section. By default, this title is derived from :term:`DISTRO_NAME` when it is @@ -189,9 +187,8 @@ the installed SDKs to update the installed SDKs by using the variable to point to the corresponding HTTP or HTTPS URL. Setting this variable causes any SDK built to default to that URL and thus, the user does not have to pass the URL to the ``devtool sdk-update`` - command as described in the "`Applying Updates to an Installed - Extensible - SDK <#sdk-applying-updates-to-an-installed-extensible-sdk>`__" + command as described in the + ":ref:`sdk-manual/extensible:applying updates to an installed extensible sdk`" section. 3. Build the extensible SDK normally (i.e., use the @@ -208,9 +205,9 @@ the installed SDKs to update the installed SDKs by using the Completing the above steps allows users of the existing installed SDKs to simply run ``devtool sdk-update`` to retrieve and apply the latest -updates. See the "`Applying Updates to an Installed Extensible -SDK <#sdk-applying-updates-to-an-installed-extensible-sdk>`__" section -for further information. +updates. See the +":ref:`sdk-manual/extensible:applying updates to an installed extensible sdk`" +section for further information. Changing the Default SDK Installation Directory =============================================== diff --git a/poky/documentation/sdk-manual/appendix-obtain.rst b/poky/documentation/sdk-manual/appendix-obtain.rst index 395102c3b..3c1dc52d1 100644 --- a/poky/documentation/sdk-manual/appendix-obtain.rst +++ b/poky/documentation/sdk-manual/appendix-obtain.rst @@ -38,7 +38,7 @@ Follow these steps to locate and hand-install the toolchain: "sato" or "minimal" arch is a string representing the target architecture: - "aarch64", "armv5e", "core2-64", "coretexa8hf-neon", "i586", "mips32r2", + "aarch64", "armv5e", "core2-64", "cortexa8hf-neon", "i586", "mips32r2", "mips64", or "ppc7400" release is the version of Yocto Project. @@ -68,10 +68,10 @@ Follow these steps to locate and hand-install the toolchain: $ ~/Downloads/poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh During execution of the script, you choose the root location for the - toolchain. See the "`Installed Standard SDK Directory - Structure <#sdk-installed-standard-sdk-directory-structure>`__" - section and the "`Installed Extensible SDK Directory - Structure <#sdk-installed-extensible-sdk-directory-structure>`__" + toolchain. See the + ":ref:`sdk-manual/appendix-obtain:installed standard sdk directory structure`" + section and the + ":ref:`sdk-manual/appendix-obtain:installed extensible sdk directory structure`" section for more information. Building an SDK Installer @@ -177,10 +177,10 @@ build the SDK installer. Follow these steps: $ ./poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh During execution of the script, you choose the root location for the - toolchain. See the "`Installed Standard SDK Directory - Structure <#sdk-installed-standard-sdk-directory-structure>`__" - section and the "`Installed Extensible SDK Directory - Structure <#sdk-installed-extensible-sdk-directory-structure>`__" + toolchain. See the + ":ref:`sdk-manual/appendix-obtain:installed standard sdk directory structure`" + section and the + ":ref:`sdk-manual/appendix-obtain:installed extensible sdk directory structure`" section for more information. Extracting the Root Filesystem diff --git a/poky/documentation/sdk-manual/extensible.rst b/poky/documentation/sdk-manual/extensible.rst index d2ed9a9b8..baa432ef3 100644 --- a/poky/documentation/sdk-manual/extensible.rst +++ b/poky/documentation/sdk-manual/extensible.rst @@ -21,8 +21,9 @@ hardware, and ease integration into the rest of the In addition to the functionality available through ``devtool``, you can alternatively make use of the toolchain directly, for example from -Makefile and Autotools. See the "`Using the SDK Toolchain -Directly <#sdk-working-projects>`__" chapter for more information. +Makefile and Autotools. See the +":ref:`sdk-manual/working-projects:using the sdk toolchain directly`" chapter +for more information. Why use the Extensible SDK and What is in It? ============================================= @@ -1087,12 +1088,12 @@ links created within the source tree: - ``sysroot-destdir/``: Contains a subset of files installed within ``do_install`` that have been put into the shared sysroot. For - more information, see the "`Sharing Files Between - Recipes <#sdk-sharing-files-between-recipes>`__" section. + more information, see the + ":ref:`dev-manual/common-tasks:sharing files between recipes`" section. - ``packages-split/``: Contains subdirectories for each package produced by the recipe. For more information, see the - "`Packaging <#sdk-packaging>`__" section. + ":ref:`sdk-manual/extensible:packaging`" section. You can use these links to get more information on what is happening at each build step. @@ -1271,11 +1272,9 @@ To update your installed SDK, use ``devtool`` as follows: $ devtool sdk-update The previous command assumes your SDK provider has set the -default update URL for you through the -:term:`SDK_UPDATE_URL` -variable as described in the "`Providing Updates to the Extensible SDK -After -Installation <#sdk-providing-updates-to-the-extensible-sdk-after-installation>`__" +default update URL for you through the :term:`SDK_UPDATE_URL` +variable as described in the +":ref:`sdk-manual/appendix-customizing:Providing Updates to the Extensible SDK After Installation`" section. If the SDK provider has not set that default URL, you need to specify it yourself in the command as follows: $ devtool sdk-update path_to_update_directory diff --git a/poky/documentation/sdk-manual/intro.rst b/poky/documentation/sdk-manual/intro.rst index e4b9b05ba..d966efea7 100644 --- a/poky/documentation/sdk-manual/intro.rst +++ b/poky/documentation/sdk-manual/intro.rst @@ -176,8 +176,8 @@ image. You just need to follow these general steps: 1. *Install the SDK for your target hardware:* For information on how to - install the SDK, see the "`Installing the - SDK <#sdk-installing-the-sdk>`__" section. + install the SDK, see the ":ref:`sdk-manual/using:installing the sdk`" + section. 2. *Download or Build the Target Image:* The Yocto Project supports several target architectures and has many pre-built kernel images and diff --git a/poky/documentation/sdk-manual/using.rst b/poky/documentation/sdk-manual/using.rst index 29fb50465..62967f557 100644 --- a/poky/documentation/sdk-manual/using.rst +++ b/poky/documentation/sdk-manual/using.rst @@ -16,8 +16,9 @@ standard SDK. " section. You can use a standard SDK to work on Makefile and Autotools-based -projects. See the "`Using the SDK Toolchain -Directly <#sdk-working-projects>`__" chapter for more information. +projects. See the +":ref:`sdk-manual/working-projects:using the sdk toolchain directly`" chapter +for more information. Why use the Standard SDK and What is in It? =========================================== @@ -31,9 +32,9 @@ the extensible SDK, which provides an internal build system and the The installed Standard SDK consists of several files and directories. Basically, it contains an SDK environment setup script, some configuration files, and host and target root filesystems to support -usage. You can see the directory structure in the "`Installed Standard -SDK Directory -Structure <#sdk-installed-standard-sdk-directory-structure>`__" section. +usage. You can see the directory structure in the +":ref:`sdk-manual/appendix-obtain:installed standard sdk directory structure`" +section. Installing the SDK ================== @@ -120,9 +121,9 @@ architecture. The example assumes the SDK installer is located in Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g. $ . /opt/poky/&DISTRO;/environment-setup-i586-poky-linux -Again, reference the "`Installed Standard SDK Directory -Structure <#sdk-installed-standard-sdk-directory-structure>`__" section -for more details on the resulting directory structure of the installed +Again, reference the +":ref:`sdk-manual/appendix-obtain:installed standard sdk directory structure`" +section for more details on the resulting directory structure of the installed SDK. Running the SDK Environment Setup Script @@ -147,7 +148,6 @@ script is for an IA-based target machine using i586 tuning: When you run the setup script, the same environment variables are defined as are when you -run the setup script for an extensible SDK. See the "`Running the -Extensible SDK Environment Setup -Script <#sdk-running-the-extensible-sdk-environment-setup-script>`__" +run the setup script for an extensible SDK. See the +":ref:`sdk-manual/appendix-obtain:installed extensible sdk directory structure`" section for more information. diff --git a/poky/documentation/sdk-manual/working-projects.rst b/poky/documentation/sdk-manual/working-projects.rst index bddf00a7d..f880cbe0d 100644 --- a/poky/documentation/sdk-manual/working-projects.rst +++ b/poky/documentation/sdk-manual/working-projects.rst @@ -104,10 +104,7 @@ project: .. note:: - If you get errors from - configure.ac - , which - autoreconf + If you get errors from ``configure.ac``, which ``autoreconf`` runs, that indicate missing files, you can use the "-i" option, which ensures missing auxiliary files are copied to the build host. @@ -206,9 +203,7 @@ regarding variable behavior: .. note:: Regardless of how you set your variables, if you use the "-e" option - with - make - , the variables from the SDK setup script take precedence: + with ``make``, the variables from the SDK setup script take precedence: :: $ make -e target diff --git a/poky/documentation/sphinx-static/switchers.js b/poky/documentation/sphinx-static/switchers.js index a7c348a7b..7a4edc9e7 100644 --- a/poky/documentation/sphinx-static/switchers.js +++ b/poky/documentation/sphinx-static/switchers.js @@ -3,7 +3,7 @@ var all_versions = { 'dev': 'dev (3.3)', - '3.2.2': '3.2.2', + '3.2.3': '3.2.3', '3.1.6': '3.1.6', '3.0.4': '3.0.4', '2.7.4': '2.7.4', diff --git a/poky/documentation/test-manual/intro.rst b/poky/documentation/test-manual/intro.rst index 81c24a8c3..101d28366 100644 --- a/poky/documentation/test-manual/intro.rst +++ b/poky/documentation/test-manual/intro.rst @@ -26,7 +26,7 @@ engineers: - *yocto-autobuilder2:* This :yocto_git:`README.md </yocto-autobuilder2/tree/README.md>` - is the main README which detials how to set up the Yocto Project + is the main README which details how to set up the Yocto Project Autobuilder. The ``yocto-autobuilder2`` repository represents the Yocto Project's console UI plugin to Buildbot and the configuration necessary to configure Buildbot to perform the testing the project @@ -88,7 +88,7 @@ Yocto Project Tests - Types of Testing Overview =============================================== The Autobuilder tests different elements of the project by using -thefollowing types of tests: +the following types of tests: - *Build Testing:* Tests whether specific configurations build by varying :term:`MACHINE`, @@ -124,7 +124,7 @@ thefollowing types of tests: The tests utilize the ``testsdkext`` class and the ``do_testsdkext`` task. - *Feature Testing:* Various scenario-based tests are run through the - :ref:`OpenEmbedded Self test (oe-selftest) <ref-manual/release-process:Testing and Quality Assurance>`. We test oe-selftest on each of the main distrubutions + :ref:`OpenEmbedded Self test (oe-selftest) <ref-manual/release-process:Testing and Quality Assurance>`. We test oe-selftest on each of the main distributions we support. - *Image Testing:* Image tests initiated through the following command:: @@ -474,7 +474,7 @@ correctly. The test would only run if python3 is installed in the SDK. ---------------------- The performance tests usually measure how long operations take and the -resource utilisation as that happens. An example from +resource utilization as that happens. An example from ``meta/lib/oeqa/buildperf/test_basic.py`` contains the following:: class Test3(BuildPerfTestCase): @@ -524,5 +524,5 @@ This is particularly true for oe-selftests since these can run in parallel and changing metadata leads to changing checksums, which confuses BitBake while running in parallel. If this is necessary, copy layers to a temporary location and modify them. Some tests need to -change metadata, such as the devtool tests. To prevent the metadate from +change metadata, such as the devtool tests. To protect the metadata from changes, set up temporary copies of that data first. diff --git a/poky/documentation/test-manual/test-process.rst b/poky/documentation/test-manual/test-process.rst index 8a5e29d92..4c3b32bfe 100644 --- a/poky/documentation/test-manual/test-process.rst +++ b/poky/documentation/test-manual/test-process.rst @@ -59,13 +59,13 @@ Release Builds The project typically has two major releases a year with a six month cadence in April and October. Between these there would be a number of -milestone releases (usually four) with the final one being stablization +milestone releases (usually four) with the final one being stabilization only along with point releases of our stable branches. The build and release process for these project releases is similar to -that in `Day to Day Development <#test-daily-devel>`__, in that the +that in :ref:`test-manual/test-process:day to day development`, in that the a-full target of the Autobuilder is used but in addition the form is -configured to generate and publish artefacts and the milestone number, +configured to generate and publish artifacts and the milestone number, version, release candidate number and other information is entered. The box to "generate an email to QA"is also checked. diff --git a/poky/documentation/test-manual/understand-autobuilder.rst b/poky/documentation/test-manual/understand-autobuilder.rst index 199cc97a8..c158d9ce4 100644 --- a/poky/documentation/test-manual/understand-autobuilder.rst +++ b/poky/documentation/test-manual/understand-autobuilder.rst @@ -9,14 +9,14 @@ Execution Flow within the Autobuilder The "a-full" and "a-quick" targets are the usual entry points into the Autobuilder and it makes sense to follow the process through the system -starting there. This is best visualised from the Autobuilder Console +starting there. This is best visualized from the Autobuilder Console view (:yocto_ab:`/typhoon/#/console`). Each item along the top of that view represents some "target build" and these targets are all run in parallel. The 'full' build will trigger the majority of them, the "quick" build will trigger some subset of them. The Autobuilder effectively runs whichever configuration is defined for -each of those targets on a seperate buildbot worker. To understand the +each of those targets on a separate buildbot worker. To understand the configuration, you need to look at the entry on ``config.json`` file within the ``yocto-autobuilder-helper`` repository. The targets are defined in the ‘overrides' section, a quick example could be qemux86-64 @@ -64,10 +64,10 @@ While not every detail of this is covered here, you can see how the template mechanism allows quite complex configurations to be built up yet allows duplication and repetition to be kept to a minimum. -The different build targets are designed to allow for parallelisation, +The different build targets are designed to allow for parallelization, so different machines are usually built in parallel, operations using the same machine and metadata are built sequentially, with the aim of -trying to optimise build efficiency as much as possible. +trying to optimize build efficiency as much as possible. The ``config.json`` file is processed by the scripts in the Helper repository in the ``scripts`` directory. The following section details @@ -111,7 +111,7 @@ roughly consist of: :ref:`test-manual/understand-autobuilder:Autobuilder Clone Cache`. This step has two possible modes of operation. If the build is part - of a parent build, its possible that all the repositories needed may + of a parent build, it's possible that all the repositories needed may already be available, ready in a pre-prepared directory. An "a-quick" or "a-full" build would prepare this before starting the other sub-target builds. This is done for two reasons: @@ -130,7 +130,7 @@ roughly consist of: #. *Call scripts/run-config* - This is another call into the Helper scripts where its expected that + This is another call into the Helper scripts where it's expected that the main functionality of this target will be executed. Autobuilder Technology @@ -164,7 +164,7 @@ Autobuilder Worker Janitor This is a process running on each Worker that performs two basic operations, including background file deletion at IO idle (see :ref:`test-manual/understand-autobuilder:Autobuilder Target Execution Overview`: Run clobberdir) and -maintainenance of a cache of cloned repositories to improve the speed +maintenance of a cache of cloned repositories to improve the speed the system can checkout repositories. Shared DL_DIR @@ -250,7 +250,7 @@ Deploying Yocto Autobuilder =========================== The most up to date information about how to setup and deploy your own -Autbuilder can be found in README.md in the ``yocto-autobuilder2`` +Autobuilder can be found in README.md in the ``yocto-autobuilder2`` repository. We hope that people can use the ``yocto-autobuilder2`` code directly but diff --git a/poky/documentation/toaster-manual/reference.rst b/poky/documentation/toaster-manual/reference.rst index 8ef58182e..3d4efe92d 100644 --- a/poky/documentation/toaster-manual/reference.rst +++ b/poky/documentation/toaster-manual/reference.rst @@ -208,7 +208,7 @@ Customizing Pre-Set Data ------------------------ The pre-set data for Toaster is easily customizable. You can create the -``orm/fixtures/custom.xml`` file to customize the values that go into to +``orm/fixtures/custom.xml`` file to customize the values that go into the database. Customization is additive, and can either extend or completely replace the existing values. diff --git a/poky/documentation/toaster-manual/setup-and-use.rst b/poky/documentation/toaster-manual/setup-and-use.rst index cabf0250c..8f0ec9449 100644 --- a/poky/documentation/toaster-manual/setup-and-use.rst +++ b/poky/documentation/toaster-manual/setup-and-use.rst @@ -362,7 +362,7 @@ Perform the following steps to install Toaster: /etc/httpd/conf.d/toaster.conf - If you are using OpenSUSE, put it here:: + If you are using openSUSE, put it here:: /etc/apache2/conf.d/toaster.conf @@ -380,13 +380,13 @@ Perform the following steps to install Toaster: Require all granted </IfModule> </Directory> - + <Directory /var/www/toaster/poky/bitbake/lib/toaster/toastermain> <Files "wsgi.py"> Require all granted </Files> </Directory> - + WSGIDaemonProcess toaster_wsgi python-path=/var/www/toaster/poky/bitbake/lib/toaster:/var/www/toaster/.local/lib/python3.4/site-packages WSGIScriptAlias / "/var/www/toaster/poky/bitbake/lib/toaster/toastermain/wsgi.py" <Location /> @@ -402,7 +402,7 @@ Perform the following steps to install Toaster: $ chmod +x bitbake/lib/toaster/toastermain/wsgi.py Finally, restart Apache to make sure all new configuration is loaded. For Ubuntu, - Debian, and OpenSUSE use:: + Debian, and openSUSE use:: $ sudo service apache2 restart diff --git a/poky/meta-poky/conf/distro/poky.conf b/poky/meta-poky/conf/distro/poky.conf index 4e416c0c8..c098b3026 100644 --- a/poky/meta-poky/conf/distro/poky.conf +++ b/poky/meta-poky/conf/distro/poky.conf @@ -1,7 +1,7 @@ DISTRO = "poky" DISTRO_NAME = "Poky (Yocto Project Reference Distro)" -DISTRO_VERSION = "3.2+snapshot-${METADATA_REVISION}" -DISTRO_CODENAME = "master" +DISTRO_VERSION = "3.3" +DISTRO_CODENAME = "hardknott" SDK_VENDOR = "-pokysdk" SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${METADATA_REVISION}', 'snapshot')}" SDK_VERSION[vardepvalue] = "${SDK_VERSION}" @@ -41,9 +41,8 @@ p4://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n \ svn://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \n" SANITY_TESTED_DISTROS ?= " \ - poky-3.0 \n \ - poky-3.1 \n \ poky-3.2 \n \ + poky-3.3 \n \ ubuntu-16.04 \n \ ubuntu-18.04 \n \ ubuntu-20.04 \n \ diff --git a/poky/meta/classes/image-live.bbclass b/poky/meta/classes/image-live.bbclass index 1b2183ead..8b08305cd 100644 --- a/poky/meta/classes/image-live.bbclass +++ b/poky/meta/classes/image-live.bbclass @@ -30,7 +30,7 @@ do_bootimg[depends] += "dosfstools-native:do_populate_sysroot \ virtual/kernel:do_deploy \ ${MLPREFIX}syslinux:do_populate_sysroot \ syslinux-native:do_populate_sysroot \ - ${PN}:do_image_${@d.getVar('LIVE_ROOTFS_TYPE').replace('-', '_')} \ + ${@'%s:do_image_%s' % (d.getVar('PN'), d.getVar('LIVE_ROOTFS_TYPE').replace('-', '_')) if d.getVar('ROOTFS') else ''} \ " diff --git a/poky/meta/classes/kernel-fitimage.bbclass b/poky/meta/classes/kernel-fitimage.bbclass index b9d827002..5cfd8af99 100644 --- a/poky/meta/classes/kernel-fitimage.bbclass +++ b/poky/meta/classes/kernel-fitimage.bbclass @@ -53,44 +53,13 @@ python __anonymous () { d.appendVarFlag('do_assemble_fitimage_initramfs', 'depends', ' %s:do_populate_sysroot' % uboot_pn) } -# Options for the device tree compiler passed to mkimage '-D' feature: -UBOOT_MKIMAGE_DTCOPTS ??= "" - -# fitImage Hash Algo -FIT_HASH_ALG ?= "sha256" - -# fitImage Signature Algo -FIT_SIGN_ALG ?= "rsa2048" - -# Generate keys for signing fitImage -FIT_GENERATE_KEYS ?= "0" - -# Size of private key in number of bits -FIT_SIGN_NUMBITS ?= "2048" - -# args to openssl genrsa (Default is just the public exponent) -FIT_KEY_GENRSA_ARGS ?= "-F4" - -# args to openssl req (Default is -batch for non interactive mode and -# -new for new certificate) -FIT_KEY_REQ_ARGS ?= "-batch -new" - -# Standard format for public key certificate -FIT_KEY_SIGN_PKCS ?= "-x509" # Description string -FIT_DESC ?= "U-Boot fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}" +FIT_DESC ?= "Kernel fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}" # Sign individual images as well FIT_SIGN_INDIVIDUAL ?= "0" -# mkimage command -UBOOT_MKIMAGE ?= "uboot-mkimage" -UBOOT_MKIMAGE_SIGN ?= "${UBOOT_MKIMAGE}" - -# Arguments passed to mkimage for signing -UBOOT_MKIMAGE_SIGN_ARGS ?= "" - # # Emit the fitImage ITS header # @@ -698,33 +667,6 @@ do_assemble_fitimage_initramfs() { addtask assemble_fitimage_initramfs before do_deploy after do_bundle_initramfs -do_generate_rsa_keys() { - if [ "${UBOOT_SIGN_ENABLE}" = "0" ] && [ "${FIT_GENERATE_KEYS}" = "1" ]; then - bbwarn "FIT_GENERATE_KEYS is set to 1 eventhough UBOOT_SIGN_ENABLE is set to 0. The keys will not be generated as they won't be used." - fi - - if [ "${UBOOT_SIGN_ENABLE}" = "1" ] && [ "${FIT_GENERATE_KEYS}" = "1" ]; then - - # Generate keys only if they don't already exist - if [ ! -f "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".key ] || \ - [ ! -f "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".crt]; then - - # make directory if it does not already exist - mkdir -p "${UBOOT_SIGN_KEYDIR}" - - echo "Generating RSA private key for signing fitImage" - openssl genrsa ${FIT_KEY_GENRSA_ARGS} -out \ - "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".key \ - "${FIT_SIGN_NUMBITS}" - - echo "Generating certificate for signing fitImage" - openssl req ${FIT_KEY_REQ_ARGS} "${FIT_KEY_SIGN_PKCS}" \ - -key "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".key \ - -out "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".crt - fi - fi -} - addtask generate_rsa_keys before do_assemble_fitimage after do_compile kernel_do_deploy[vardepsexclude] = "DATETIME" @@ -753,12 +695,22 @@ kernel_do_deploy_append() { ln -snf fitImage-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_NAME}.bin "$deployDir/fitImage-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_LINK_NAME}" fi fi - if [ "${UBOOT_SIGN_ENABLE}" = "1" -a -n "${UBOOT_DTB_BINARY}" ] ; then - # UBOOT_DTB_IMAGE is a realfile, but we can't use - # ${UBOOT_DTB_IMAGE} since it contains ${PV} which is aimed - # for u-boot, but we are in kernel env now. - install -m 0644 ${B}/u-boot-${MACHINE}*.dtb "$deployDir/" - fi + fi + if [ "${UBOOT_SIGN_ENABLE}" = "1" -o "${UBOOT_FITIMAGE_ENABLE}" = "1" ] && \ + [ -n "${UBOOT_DTB_BINARY}" ] ; then + # UBOOT_DTB_IMAGE is a realfile, but we can't use + # ${UBOOT_DTB_IMAGE} since it contains ${PV} which is aimed + # for u-boot, but we are in kernel env now. + install -m 0644 ${B}/u-boot-${MACHINE}*.dtb "$deployDir/" + fi + if [ "${UBOOT_FITIMAGE_ENABLE}" = "1" -a -n "${UBOOT_BINARY}" -a -n "${SPL_DTB_BINARY}" ] ; then + # If we're also creating and/or signing the uboot fit, now we need to + # deploy it, it's its file, as well as u-boot-spl.dtb + install -m 0644 ${B}/u-boot-spl-${MACHINE}*.dtb "$deployDir/" + echo "Copying u-boot-fitImage file..." + install -m 0644 ${B}/u-boot-fitImage-* "$deployDir/" + echo "Copying u-boot-its file..." + install -m 0644 ${B}/u-boot-its-* "$deployDir/" fi } diff --git a/poky/meta/classes/kernel-yocto.bbclass b/poky/meta/classes/kernel-yocto.bbclass index 35587dd56..15c8dbb81 100644 --- a/poky/meta/classes/kernel-yocto.bbclass +++ b/poky/meta/classes/kernel-yocto.bbclass @@ -403,11 +403,11 @@ do_kernel_configme() { *alldefconfig) config_flags="" ;; - *) - if [ -f ${WORKDIR}/defconfig ]; then - config_flags="-n" - fi - ;; + *) + if [ -f ${WORKDIR}/defconfig ]; then + config_flags="-n" + fi + ;; esac cd ${S} diff --git a/poky/meta/classes/testimage.bbclass b/poky/meta/classes/testimage.bbclass index 78da4b09b..e61375950 100644 --- a/poky/meta/classes/testimage.bbclass +++ b/poky/meta/classes/testimage.bbclass @@ -305,6 +305,7 @@ def testimage_main(d): 'dump_dir' : d.getVar("TESTIMAGE_DUMP_DIR"), 'serial_ports': len(d.getVar("SERIAL_CONSOLES").split()), 'ovmf' : ovmf, + 'tmpfsdir' : d.getVar("RUNQEMU_TMPFS_DIR"), } if d.getVar("TESTIMAGE_BOOT_PATTERNS"): diff --git a/poky/meta/classes/uboot-config.bbclass b/poky/meta/classes/uboot-config.bbclass index 89ff970fc..3bba02828 100644 --- a/poky/meta/classes/uboot-config.bbclass +++ b/poky/meta/classes/uboot-config.bbclass @@ -11,7 +11,65 @@ # # Copyright 2013, 2014 (C) O.S. Systems Software LTDA. +# Some versions of u-boot use .bin and others use .img. By default use .bin +# but enable individual recipes to change this value. +UBOOT_SUFFIX ??= "bin" UBOOT_BINARY ?= "u-boot.${UBOOT_SUFFIX}" +UBOOT_BINARYNAME ?= "${@os.path.splitext(d.getVar("UBOOT_BINARY"))[0]}" +UBOOT_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}" +UBOOT_SYMLINK ?= "u-boot-${MACHINE}.${UBOOT_SUFFIX}" +UBOOT_MAKE_TARGET ?= "all" + +# Output the ELF generated. Some platforms can use the ELF file and directly +# load it (JTAG booting, QEMU) additionally the ELF can be used for debugging +# purposes. +UBOOT_ELF ?= "" +UBOOT_ELF_SUFFIX ?= "elf" +UBOOT_ELF_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.${UBOOT_ELF_SUFFIX}" +UBOOT_ELF_BINARY ?= "u-boot.${UBOOT_ELF_SUFFIX}" +UBOOT_ELF_SYMLINK ?= "u-boot-${MACHINE}.${UBOOT_ELF_SUFFIX}" + +# Some versions of u-boot build an SPL (Second Program Loader) image that +# should be packaged along with the u-boot binary as well as placed in the +# deploy directory. For those versions they can set the following variables +# to allow packaging the SPL. +SPL_BINARY ?= "" +SPL_BINARYNAME ?= "${@os.path.basename(d.getVar("SPL_BINARY"))}" +SPL_IMAGE ?= "${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}" +SPL_SYMLINK ?= "${SPL_BINARYNAME}-${MACHINE}" + +# Additional environment variables or a script can be installed alongside +# u-boot to be used automatically on boot. This file, typically 'uEnv.txt' +# or 'boot.scr', should be packaged along with u-boot as well as placed in the +# deploy directory. Machine configurations needing one of these files should +# include it in the SRC_URI and set the UBOOT_ENV parameter. +UBOOT_ENV_SUFFIX ?= "txt" +UBOOT_ENV ?= "" +UBOOT_ENV_BINARY ?= "${UBOOT_ENV}.${UBOOT_ENV_SUFFIX}" +UBOOT_ENV_IMAGE ?= "${UBOOT_ENV}-${MACHINE}-${PV}-${PR}.${UBOOT_ENV_SUFFIX}" +UBOOT_ENV_SYMLINK ?= "${UBOOT_ENV}-${MACHINE}.${UBOOT_ENV_SUFFIX}" + +# Default name of u-boot initial env, but enable individual recipes to change +# this value. +UBOOT_INITIAL_ENV ?= "${PN}-initial-env" + +# U-Boot EXTLINUX variables. U-Boot searches for /boot/extlinux/extlinux.conf +# to find EXTLINUX conf file. +UBOOT_EXTLINUX_INSTALL_DIR ?= "/boot/extlinux" +UBOOT_EXTLINUX_CONF_NAME ?= "extlinux.conf" +UBOOT_EXTLINUX_SYMLINK ?= "${UBOOT_EXTLINUX_CONF_NAME}-${MACHINE}-${PR}" + +# Options for the device tree compiler passed to mkimage '-D' feature: +UBOOT_MKIMAGE_DTCOPTS ??= "" +SPL_MKIMAGE_DTCOPTS ??= "" + +# mkimage command +UBOOT_MKIMAGE ?= "uboot-mkimage" +UBOOT_MKIMAGE_SIGN ?= "${UBOOT_MKIMAGE}" + +# Arguments passed to mkimage for signing +UBOOT_MKIMAGE_SIGN_ARGS ?= "" +SPL_MKIMAGE_SIGN_ARGS ?= "" python () { ubootmachine = d.getVar("UBOOT_MACHINE") diff --git a/poky/meta/classes/uboot-sign.bbclass b/poky/meta/classes/uboot-sign.bbclass index 713196df4..d11882f90 100644 --- a/poky/meta/classes/uboot-sign.bbclass +++ b/poky/meta/classes/uboot-sign.bbclass @@ -31,19 +31,81 @@ # # For more details on signature process, please refer to U-Boot documentation. -# Signature activation. +# We need some variables from u-boot-config +inherit uboot-config + +# Enable use of a U-Boot fitImage +UBOOT_FITIMAGE_ENABLE ?= "0" + +# Signature activation - these require their respective fitImages UBOOT_SIGN_ENABLE ?= "0" +SPL_SIGN_ENABLE ?= "0" # Default value for deployment filenames. UBOOT_DTB_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.dtb" UBOOT_DTB_BINARY ?= "u-boot.dtb" UBOOT_DTB_SYMLINK ?= "u-boot-${MACHINE}.dtb" -UBOOT_NODTB_IMAGE ?= "u-boot-nodtb-${MACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}" -UBOOT_NODTB_BINARY ?= "u-boot-nodtb.${UBOOT_SUFFIX}" -UBOOT_NODTB_SYMLINK ?= "u-boot-nodtb-${MACHINE}.${UBOOT_SUFFIX}" +UBOOT_NODTB_IMAGE ?= "u-boot-nodtb-${MACHINE}-${PV}-${PR}.bin" +UBOOT_NODTB_BINARY ?= "u-boot-nodtb.bin" +UBOOT_NODTB_SYMLINK ?= "u-boot-nodtb-${MACHINE}.bin" +UBOOT_ITS_IMAGE ?= "u-boot-its-${MACHINE}-${PV}-${PR}" +UBOOT_ITS ?= "u-boot.its" +UBOOT_ITS_SYMLINK ?= "u-boot-its-${MACHINE}" +UBOOT_FITIMAGE_IMAGE ?= "u-boot-fitImage-${MACHINE}-${PV}-${PR}" +UBOOT_FITIMAGE_BINARY ?= "u-boot-fitImage" +UBOOT_FITIMAGE_SYMLINK ?= "u-boot-fitImage-${MACHINE}" +SPL_DIR ?= "spl" +SPL_DTB_IMAGE ?= "u-boot-spl-${MACHINE}-${PV}-${PR}.dtb" +SPL_DTB_BINARY ?= "u-boot-spl.dtb" +SPL_DTB_SYMLINK ?= "u-boot-spl-${MACHINE}.dtb" +SPL_NODTB_IMAGE ?= "u-boot-spl-nodtb-${MACHINE}-${PV}-${PR}.bin" +SPL_NODTB_BINARY ?= "u-boot-spl-nodtb.bin" +SPL_NODTB_SYMLINK ?= "u-boot-spl-nodtb-${MACHINE}.bin" + +# U-Boot fitImage description +UBOOT_FIT_DESC ?= "U-Boot fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}" + +# Kernel / U-Boot fitImage Hash Algo +FIT_HASH_ALG ?= "sha256" +UBOOT_FIT_HASH_ALG ?= "sha256" + +# Kernel / U-Boot fitImage Signature Algo +FIT_SIGN_ALG ?= "rsa2048" +UBOOT_FIT_SIGN_ALG ?= "rsa2048" + +# Generate keys for signing Kernel / U-Boot fitImage +FIT_GENERATE_KEYS ?= "0" +UBOOT_FIT_GENERATE_KEYS ?= "0" + +# Size of private keys in number of bits +FIT_SIGN_NUMBITS ?= "2048" +UBOOT_FIT_SIGN_NUMBITS ?= "2048" -# Functions in this bbclass is for u-boot only +# args to openssl genrsa (Default is just the public exponent) +FIT_KEY_GENRSA_ARGS ?= "-F4" +UBOOT_FIT_KEY_GENRSA_ARGS ?= "-F4" + +# args to openssl req (Default is -batch for non interactive mode and +# -new for new certificate) +FIT_KEY_REQ_ARGS ?= "-batch -new" +UBOOT_FIT_KEY_REQ_ARGS ?= "-batch -new" + +# Standard format for public key certificate +FIT_KEY_SIGN_PKCS ?= "-x509" +UBOOT_FIT_KEY_SIGN_PKCS ?= "-x509" + +# Functions on this bbclass can apply to either U-boot or Kernel, +# depending on the scenario UBOOT_PN = "${@d.getVar('PREFERRED_PROVIDER_u-boot') or 'u-boot'}" +KERNEL_PN = "${@d.getVar('PREFERRED_PROVIDER_virtual/kernel')}" + +# We need u-boot-tools-native if we're creating a U-Boot fitImage +python() { + if d.getVar('UBOOT_FITIMAGE_ENABLE') == '1': + depends = d.getVar("DEPENDS") + depends = "%s u-boot-tools-native dtc-native" % depends + d.setVar("DEPENDS", depends) +} concat_dtb_helper() { if [ -e "${UBOOT_DTB_BINARY}" ]; then @@ -57,21 +119,44 @@ concat_dtb_helper() { ln -sf ${UBOOT_NODTB_IMAGE} ${DEPLOYDIR}/${UBOOT_NODTB_BINARY} fi - # Concatenate U-Boot w/o DTB & DTB with public key - # (cf. kernel-fitimage.bbclass for more details) - deployed_uboot_dtb_binary='${DEPLOY_DIR_IMAGE}/${UBOOT_DTB_IMAGE}' - if [ "x${UBOOT_SUFFIX}" = "ximg" -o "x${UBOOT_SUFFIX}" = "xrom" ] && \ - [ -e "$deployed_uboot_dtb_binary" ]; then - oe_runmake EXT_DTB=$deployed_uboot_dtb_binary - install ${UBOOT_BINARY} ${DEPLOYDIR}/${UBOOT_IMAGE} - elif [ -e "${DEPLOYDIR}/${UBOOT_NODTB_IMAGE}" -a -e "$deployed_uboot_dtb_binary" ]; then + # If we're not using a signed u-boot fit, concatenate SPL w/o DTB & U-Boot DTB + # with public key (otherwise it will be deployed by the equivalent + # concat_spl_dtb_helper function - cf. kernel-fitimage.bbclass for more details) + if [ "${SPL_SIGN_ENABLE}" != "1" ] ; then + deployed_uboot_dtb_binary='${DEPLOY_DIR_IMAGE}/${UBOOT_DTB_IMAGE}' + if [ "x${UBOOT_SUFFIX}" = "ximg" -o "x${UBOOT_SUFFIX}" = "xrom" ] && \ + [ -e "$deployed_uboot_dtb_binary" ]; then + oe_runmake EXT_DTB=$deployed_uboot_dtb_binary + install ${UBOOT_BINARY} ${DEPLOYDIR}/${UBOOT_IMAGE} + elif [ -e "${DEPLOYDIR}/${UBOOT_NODTB_IMAGE}" -a -e "$deployed_uboot_dtb_binary" ]; then + cd ${DEPLOYDIR} + cat ${UBOOT_NODTB_IMAGE} $deployed_uboot_dtb_binary | tee ${B}/${CONFIG_B_PATH}/${UBOOT_BINARY} > ${UBOOT_IMAGE} + else + bbwarn "Failure while adding public key to u-boot binary. Verified boot won't be available." + fi + fi +} + +concat_spl_dtb_helper() { + + # We only deploy symlinks to the u-boot-spl.dtb,as the KERNEL_PN will + # be responsible for deploying the real file + if [ -e "${SPL_DIR}/${SPL_DTB_BINARY}" ] ; then + ln -sf ${SPL_DTB_IMAGE} ${DEPLOYDIR}/${SPL_DTB_SYMLINK} + ln -sf ${SPL_DTB_IMAGE} ${DEPLOYDIR}/${SPL_DTB_BINARY} + fi + + # Concatenate the SPL nodtb binary and u-boot.dtb + deployed_spl_dtb_binary='${DEPLOY_DIR_IMAGE}/${SPL_DTB_IMAGE}' + if [ -e "${DEPLOYDIR}/${SPL_NODTB_IMAGE}" -a -e "$deployed_spl_dtb_binary" ] ; then cd ${DEPLOYDIR} - cat ${UBOOT_NODTB_IMAGE} $deployed_uboot_dtb_binary | tee ${B}/${CONFIG_B_PATH}/${UBOOT_BINARY} > ${UBOOT_IMAGE} + cat ${SPL_NODTB_IMAGE} $deployed_spl_dtb_binary | tee ${B}/${CONFIG_B_PATH}/${SPL_BINARY} > ${SPL_IMAGE} else - bbwarn "Failure while adding public key to u-boot binary. Verified boot won't be available." + bbwarn "Failure while adding public key to spl binary. Verified U-Boot boot won't be available." fi } + concat_dtb() { if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${PN}" = "${UBOOT_PN}" -a -n "${UBOOT_DTB_BINARY}" ]; then mkdir -p ${DEPLOYDIR} @@ -89,6 +174,24 @@ concat_dtb() { fi } +concat_spl_dtb() { + if [ "${SPL_SIGN_ENABLE}" = "1" -a "${PN}" = "${UBOOT_PN}" -a -n "${SPL_DTB_BINARY}" ]; then + mkdir -p ${DEPLOYDIR} + if [ -n "${UBOOT_CONFIG}" ]; then + for config in ${UBOOT_MACHINE}; do + CONFIG_B_PATH="${config}" + cd ${B}/${config} + concat_spl_dtb_helper + done + else + CONFIG_B_PATH="" + cd ${B} + concat_spl_dtb_helper + fi + fi +} + + # Install UBOOT_DTB_BINARY to datadir, so that kernel can use it for # signing, and kernel will deploy UBOOT_DTB_BINARY after signs it. install_helper() { @@ -103,30 +206,302 @@ install_helper() { fi } +# Install SPL dtb and u-boot nodtb to datadir, +install_spl_helper() { + if [ -f "${SPL_DIR}/${SPL_DTB_BINARY}" ]; then + install -d ${D}${datadir} + install ${SPL_DIR}/${SPL_DTB_BINARY} ${D}${datadir}/${SPL_DTB_IMAGE} + ln -sf ${SPL_DTB_IMAGE} ${D}${datadir}/${SPL_DTB_BINARY} + else + bbwarn "${SPL_DTB_BINARY} not found" + fi + if [ -f "${UBOOT_NODTB_BINARY}" ] ; then + install ${UBOOT_NODTB_BINARY} ${D}${datadir}/${UBOOT_NODTB_IMAGE} + ln -sf ${UBOOT_NODTB_IMAGE} ${D}${datadir}/${UBOOT_NODTB_BINARY} + else + bbwarn "${UBOOT_NODTB_BINARY} not found" + fi + + # We need to install a 'stub' u-boot-fitimage + its to datadir, + # so that the KERNEL_PN can use the correct filename when + # assembling and deploying them + touch ${D}/${datadir}/${UBOOT_FITIMAGE_IMAGE} + touch ${D}/${datadir}/${UBOOT_ITS_IMAGE} +} + do_install_append() { - if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${PN}" = "${UBOOT_PN}" -a -n "${UBOOT_DTB_BINARY}" ]; then + if [ "${PN}" = "${UBOOT_PN}" ]; then if [ -n "${UBOOT_CONFIG}" ]; then for config in ${UBOOT_MACHINE}; do cd ${B}/${config} - install_helper + if [ "${UBOOT_SIGN_ENABLE}" = "1" -o "${UBOOT_FITIMAGE_ENABLE}" = "1" ] && \ + [ -n "${UBOOT_DTB_BINARY}" ]; then + install_helper + fi + if [ "${SPL_SIGN_ENABLE}" = "1" -a -n "${SPL_DTB_BINARY}" ]; then + install_spl_helper + fi done else cd ${B} - install_helper + if [ "${UBOOT_SIGN_ENABLE}" = "1" -o "${UBOOT_FITIMAGE_ENABLE}" = "1" ] && \ + [ -n "${UBOOT_DTB_BINARY}" ]; then + install_helper + fi + if [ "${UBOOT_FITIMAGE_ENABLE}" = "1" -a -n "${SPL_DTB_BINARY}" ]; then + install_spl_helper + fi + fi + fi +} + +do_generate_rsa_keys() { + if [ "${UBOOT_SIGN_ENABLE}" = "0" ] && [ "${FIT_GENERATE_KEYS}" = "1" ]; then + bbwarn "FIT_GENERATE_KEYS is set to 1 even though UBOOT_SIGN_ENABLE is set to 0. The keys will not be generated as they won't be used." + fi + + if [ "${UBOOT_SIGN_ENABLE}" = "1" ] && [ "${FIT_GENERATE_KEYS}" = "1" ]; then + + # Generate keys only if they don't already exist + if [ ! -f "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".key ] || \ + [ ! -f "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".crt ]; then + + # make directory if it does not already exist + mkdir -p "${UBOOT_SIGN_KEYDIR}" + + echo "Generating RSA private key for signing fitImage" + openssl genrsa ${FIT_KEY_GENRSA_ARGS} -out \ + "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".key \ + "${FIT_SIGN_NUMBITS}" + + echo "Generating certificate for signing fitImage" + openssl req ${FIT_KEY_REQ_ARGS} "${FIT_KEY_SIGN_PKCS}" \ + -key "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".key \ + -out "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".crt + fi + fi + + if [ "${SPL_SIGN_ENABLE}" = "0" ] && [ "${UBOOT_FIT_GENERATE_KEYS}" = "1" ]; then + bbwarn "UBOOT_FIT_GENERATE_KEYS is set to 1 eventhough SPL_SIGN_ENABLE is set to 0. The keys will not be generated as they won't be used." + fi + + if [ "${SPL_SIGN_ENABLE}" = "1" ] && [ "${UBOOT_FIT_GENERATE_KEYS}" = "1" ]; then + + # Generate keys only if they don't already exist + if [ ! -f "${SPL_SIGN_KEYDIR}/${SPL_SIGN_KEYNAME}".key ] || \ + [ ! -f "${SPL_SIGN_KEYDIR}/${SPL_SIGN_KEYNAME}".crt ]; then + + # make directory if it does not already exist + mkdir -p "${SPL_SIGN_KEYDIR}" + + echo "Generating RSA private key for signing U-Boot fitImage" + openssl genrsa ${UBOOT_FIT_KEY_GENRSA_ARGS} -out \ + "${SPL_SIGN_KEYDIR}/${SPL_SIGN_KEYNAME}".key \ + "${UBOOT_FIT_SIGN_NUMBITS}" + + echo "Generating certificate for signing U-Boot fitImage" + openssl req ${FIT_KEY_REQ_ARGS} "${UBOOT_FIT_KEY_SIGN_PKCS}" \ + -key "${SPL_SIGN_KEYDIR}/${SPL_SIGN_KEYNAME}".key \ + -out "${SPL_SIGN_KEYDIR}/${SPL_SIGN_KEYNAME}".crt + fi + fi + +} + +addtask generate_rsa_keys before do_uboot_assemble_fitimage after do_compile + +# Create a ITS file for the U-boot FIT, for use when +# we want to sign it so that the SPL can verify it +uboot_fitimage_assemble() { + uboot_its="${1}" + uboot_nodtb_bin="${2}" + uboot_dtb="${3}" + uboot_bin="${4}" + spl_dtb="${5}" + uboot_csum="${UBOOT_FIT_HASH_ALG}" + uboot_sign_algo="${UBOOT_FIT_SIGN_ALG}" + uboot_sign_keyname="${SPL_SIGN_KEYNAME}" + + rm -f ${uboot_its} ${uboot_bin} + + # First we create the ITS script + cat << EOF >> ${uboot_its} +/dts-v1/; + +/ { + description = "${UBOOT_FIT_DESC}"; + #address-cells = <1>; + + images { + uboot { + description = "U-Boot image"; + data = /incbin/("${uboot_nodtb_bin}"); + type = "standalone"; + os = "u-boot"; + arch = "${UBOOT_ARCH}"; + compression = "none"; + load = <${UBOOT_LOADADDRESS}>; + entry = <${UBOOT_ENTRYPOINT}>; +EOF + + if [ "${SPL_SIGN_ENABLE}" = "1" ] ; then + cat << EOF >> ${uboot_its} + signature { + algo = "${uboot_csum},${uboot_sign_algo}"; + key-name-hint = "${uboot_sign_keyname}"; + }; +EOF + fi + + cat << EOF >> ${uboot_its} + }; + fdt { + description = "U-Boot FDT"; + data = /incbin/("${uboot_dtb}"); + type = "flat_dt"; + arch = "${UBOOT_ARCH}"; + compression = "none"; +EOF + + if [ "${SPL_SIGN_ENABLE}" = "1" ] ; then + cat << EOF >> ${uboot_its} + signature { + algo = "${uboot_csum},${uboot_sign_algo}"; + key-name-hint = "${uboot_sign_keyname}"; + }; +EOF + fi + + cat << EOF >> ${uboot_its} + }; + }; + + configurations { + default = "conf"; + conf { + description = "Boot with signed U-Boot FIT"; + loadables = "uboot"; + fdt = "fdt"; + }; + }; +}; +EOF + + # + # Assemble the U-boot FIT image + # + ${UBOOT_MKIMAGE} \ + ${@'-D "${SPL_MKIMAGE_DTCOPTS}"' if len('${SPL_MKIMAGE_DTCOPTS}') else ''} \ + -f ${uboot_its} \ + ${uboot_bin} + + if [ "${SPL_SIGN_ENABLE}" = "1" ] ; then + # + # Sign the U-boot FIT image and add public key to SPL dtb + # + ${UBOOT_MKIMAGE_SIGN} \ + ${@'-D "${SPL_MKIMAGE_DTCOPTS}"' if len('${SPL_MKIMAGE_DTCOPTS}') else ''} \ + -F -k "${SPL_SIGN_KEYDIR}" \ + -K "${spl_dtb}" \ + -r ${uboot_bin} \ + ${SPL_MKIMAGE_SIGN_ARGS} + fi + +} + +do_uboot_assemble_fitimage() { + # This function runs in KERNEL_PN context. The reason for that is that we need to + # support the scenario where UBOOT_SIGN_ENABLE is placing the Kernel fitImage's + # pubkey in the u-boot.dtb file, so that we can use it when building the U-Boot + # fitImage itself. + if [ "${UBOOT_FITIMAGE_ENABLE}" = "1" ] && \ + [ -n "${SPL_DTB_BINARY}" -a "${PN}" = "${KERNEL_PN}" ] ; then + if [ "${UBOOT_SIGN_ENABLE}" != "1" ]; then + # If we're not signing the Kernel fitImage, that means + # we need to copy the u-boot.dtb from staging ourselves + cp -P ${STAGING_DATADIR}/u-boot*.dtb ${B} fi + # As we are in the kernel context, we need to copy u-boot-spl.dtb from staging first. + # Unfortunately, need to glob on top of ${SPL_DTB_BINARY} since _IMAGE and _SYMLINK + # will contain U-boot's PV + # Similarly, we need to get the filename for the 'stub' u-boot-fitimage + its in + # staging so that we can use it for creating the image with the correct filename + # in the KERNEL_PN context. + # As for the u-boot.dtb (with fitimage's pubkey), it should come from the dependent + # do_assemble_fitimage task + cp -P ${STAGING_DATADIR}/u-boot-spl*.dtb ${B} + cp -P ${STAGING_DATADIR}/u-boot-nodtb*.bin ${B} + rm -rf ${B}/u-boot-fitImage-* ${B}/u-boot-its-* + kernel_uboot_fitimage_name=`basename ${STAGING_DATADIR}/u-boot-fitImage-*` + kernel_uboot_its_name=`basename ${STAGING_DATADIR}/u-boot-its-*` + cd ${B} + uboot_fitimage_assemble ${kernel_uboot_its_name} ${UBOOT_NODTB_BINARY} \ + ${UBOOT_DTB_BINARY} ${kernel_uboot_fitimage_name} \ + ${SPL_DTB_BINARY} fi } +addtask uboot_assemble_fitimage before do_deploy after do_compile + do_deploy_prepend_pn-${UBOOT_PN}() { - if [ "${UBOOT_SIGN_ENABLE}" = "1" -a -n "${UBOOT_DTB_BINARY}" ]; then + if [ "${UBOOT_SIGN_ENABLE}" = "1" -a -n "${UBOOT_DTB_BINARY}" ] ; then concat_dtb fi + + if [ "${UBOOT_FITIMAGE_ENABLE}" = "1" ] ; then + # Deploy the u-boot-nodtb binary and symlinks... + if [ -f "${SPL_DIR}/${SPL_NODTB_BINARY}" ] ; then + echo "Copying u-boot-nodtb binary..." + install -m 0644 ${SPL_DIR}/${SPL_NODTB_BINARY} ${DEPLOYDIR}/${SPL_NODTB_IMAGE} + ln -sf ${SPL_NODTB_IMAGE} ${DEPLOYDIR}/${SPL_NODTB_SYMLINK} + ln -sf ${SPL_NODTB_IMAGE} ${DEPLOYDIR}/${SPL_NODTB_BINARY} + fi + + + # We only deploy the symlinks to the uboot-fitImage and uboot-its + # images, as the KERNEL_PN will take care of deploying the real file + ln -sf ${UBOOT_FITIMAGE_IMAGE} ${DEPLOYDIR}/${UBOOT_FITIMAGE_BINARY} + ln -sf ${UBOOT_FITIMAGE_IMAGE} ${DEPLOYDIR}/${UBOOT_FITIMAGE_SYMLINK} + ln -sf ${UBOOT_ITS_IMAGE} ${DEPLOYDIR}/${UBOOT_ITS} + ln -sf ${UBOOT_ITS_IMAGE} ${DEPLOYDIR}/${UBOOT_ITS_SYMLINK} + fi + + if [ "${SPL_SIGN_ENABLE}" = "1" -a -n "${SPL_DTB_BINARY}" ] ; then + concat_spl_dtb + fi + + +} + +do_deploy_append_pn-${UBOOT_PN}() { + # If we're creating a u-boot fitImage, point u-boot.bin + # symlink since it might get used by image recipes + if [ "${UBOOT_FITIMAGE_ENABLE}" = "1" ] ; then + ln -sf ${UBOOT_FITIMAGE_IMAGE} ${DEPLOYDIR}/${UBOOT_BINARY} + ln -sf ${UBOOT_FITIMAGE_IMAGE} ${DEPLOYDIR}/${UBOOT_SYMLINK} + fi } python () { - if d.getVar('UBOOT_SIGN_ENABLE') == '1' and d.getVar('PN') == d.getVar('UBOOT_PN') and d.getVar('UBOOT_DTB_BINARY'): - kernel_pn = d.getVar('PREFERRED_PROVIDER_virtual/kernel') + if ( (d.getVar('UBOOT_SIGN_ENABLE') == '1' + or d.getVar('UBOOT_FITIMAGE_ENABLE') == '1') + and d.getVar('PN') == d.getVar('UBOOT_PN') + and d.getVar('UBOOT_DTB_BINARY')): # Make "bitbake u-boot -cdeploy" deploys the signed u-boot.dtb - d.appendVarFlag('do_deploy', 'depends', ' %s:do_deploy' % kernel_pn) + # and/or the U-Boot fitImage + d.appendVarFlag('do_deploy', 'depends', ' %s:do_deploy' % d.getVar('KERNEL_PN')) + + if d.getVar('UBOOT_FITIMAGE_ENABLE') == '1' and d.getVar('PN') == d.getVar('KERNEL_PN'): + # As the U-Boot fitImage is created by the KERNEL_PN, we need + # to make sure that the u-boot-spl.dtb and u-boot-spl-nodtb.bin + # files are in the staging dir for it's use + d.appendVarFlag('do_uboot_assemble_fitimage', 'depends', ' %s:do_populate_sysroot' % d.getVar('UBOOT_PN')) + + # If the Kernel fitImage is being signed, we need to + # create the U-Boot fitImage after it + if d.getVar('UBOOT_SIGN_ENABLE') == '1': + d.appendVarFlag('do_uboot_assemble_fitimage', 'depends', ' %s:do_assemble_fitimage' % d.getVar('KERNEL_PN')) + d.appendVarFlag('do_uboot_assemble_fitimage', 'depends', ' %s:do_assemble_fitimage_initramfs' % d.getVar('KERNEL_PN')) + } diff --git a/poky/meta/conf/bitbake.conf b/poky/meta/conf/bitbake.conf index d87d7cafb..385fc7dd5 100644 --- a/poky/meta/conf/bitbake.conf +++ b/poky/meta/conf/bitbake.conf @@ -810,6 +810,10 @@ XZ_THREADS ?= "${@oe.utils.cpu_count(at_least=2)}" XZ_DEFAULTS ?= "--memlimit=${XZ_MEMLIMIT} --threads=${XZ_THREADS}" XZ_DEFAULTS[vardepsexclude] += "XZ_MEMLIMIT XZ_THREADS" +# Limit the number of threads that OpenMP libraries will use. Otherwise they +# may fallback to using all CPUs +export OMP_NUM_THREADS = "${BB_NUMBER_THREADS}" + ################################################################## # Magic Cookie for SANITY CHECK ################################################################## @@ -891,7 +895,8 @@ BB_HASHEXCLUDE_COMMON ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH BBSERVER DL_DI WARN_QA ERROR_QA WORKDIR STAMPCLEAN PKGDATA_DIR BUILD_ARCH SSTATE_PKGARCH \ BB_WORKERCONTEXT BB_LIMITEDDEPS BB_UNIHASH extend_recipe_sysroot DEPLOY_DIR \ SSTATE_HASHEQUIV_METHOD SSTATE_HASHEQUIV_REPORT_TASKDATA \ - SSTATE_HASHEQUIV_OWNER CCACHE_TOP_DIR BB_HASHSERVE GIT_CEILING_DIRECTORIES" + SSTATE_HASHEQUIV_OWNER CCACHE_TOP_DIR BB_HASHSERVE GIT_CEILING_DIRECTORIES \ + OMP_NUM_THREADS" BB_HASHBASE_WHITELIST ?= "${BB_HASHEXCLUDE_COMMON} PSEUDO_IGNORE_PATHS BUILDHISTORY_DIR SSTATE_DIR " BB_HASHCONFIG_WHITELIST ?= "${BB_HASHEXCLUDE_COMMON} DATE TIME SSH_AGENT_PID \ SSH_AUTH_SOCK PSEUDO_BUILD BB_ENV_EXTRAWHITE DISABLE_SANITY_CHECKS \ diff --git a/poky/meta/conf/machine/include/riscv/qemuriscv.inc b/poky/meta/conf/machine/include/riscv/qemuriscv.inc index 47d7e9b17..428d28bde 100644 --- a/poky/meta/conf/machine/include/riscv/qemuriscv.inc +++ b/poky/meta/conf/machine/include/riscv/qemuriscv.inc @@ -34,3 +34,5 @@ QB_NETWORK_DEVICE = "-device virtio-net-device,netdev=net0,mac=@MAC@" QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0" QB_SERIAL_OPT = "-device virtio-serial-device -chardev null,id=virtcon -device virtconsole,chardev=virtcon" QB_TCPSERIAL_OPT = " -device virtio-serial-device -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device virtconsole,chardev=virtcon" +QB_GRAPHICS = "-device bochs-display" +QB_OPT_APPEND = "-device virtio-mouse-pci -device virtio-keyboard-pci" diff --git a/poky/meta/lib/oeqa/core/target/qemu.py b/poky/meta/lib/oeqa/core/target/qemu.py index 0f29414df..792efca1f 100644 --- a/poky/meta/lib/oeqa/core/target/qemu.py +++ b/poky/meta/lib/oeqa/core/target/qemu.py @@ -21,7 +21,7 @@ class OEQemuTarget(OESSHTarget): port=None, machine='', rootfs='', kernel='', kvm=False, slirp=False, dump_dir='', dump_host_cmds='', display='', bootlog='', tmpdir='', dir_image='', boottime=60, serial_ports=2, - boot_patterns = defaultdict(str), ovmf=False, **kwargs): + boot_patterns = defaultdict(str), ovmf=False, tmpfsdir=None, **kwargs): super(OEQemuTarget, self).__init__(logger, None, server_ip, timeout, user, port) @@ -42,7 +42,7 @@ class OEQemuTarget(OESSHTarget): use_kvm=kvm, use_slirp=slirp, dump_dir=dump_dir, dump_host_cmds=dump_host_cmds, logger=logger, serial_ports=serial_ports, boot_patterns = boot_patterns, - use_ovmf=ovmf) + use_ovmf=ovmf, tmpfsdir=tmpfsdir) dump_target_cmds = kwargs.get("testimage_dump_target") self.target_dumper = TargetDumper(dump_target_cmds, dump_dir, self.runner) self.target_dumper.create_dir("qemu") diff --git a/poky/meta/lib/oeqa/core/utils/concurrencytest.py b/poky/meta/lib/oeqa/core/utils/concurrencytest.py index b2eb68fb0..161a2f6e9 100644 --- a/poky/meta/lib/oeqa/core/utils/concurrencytest.py +++ b/poky/meta/lib/oeqa/core/utils/concurrencytest.py @@ -48,11 +48,15 @@ _all__ = [ # class BBThreadsafeForwardingResult(ThreadsafeForwardingResult): - def __init__(self, target, semaphore, threadnum, totalinprocess, totaltests): + def __init__(self, target, semaphore, threadnum, totalinprocess, totaltests, output, finalresult): super(BBThreadsafeForwardingResult, self).__init__(target, semaphore) self.threadnum = threadnum self.totalinprocess = totalinprocess self.totaltests = totaltests + self.buffer = True + self.outputbuf = output + self.finalresult = finalresult + self.finalresult.buffer = True def _add_result_with_semaphore(self, method, test, *args, **kwargs): self.semaphore.acquire() @@ -71,6 +75,8 @@ class BBThreadsafeForwardingResult(ThreadsafeForwardingResult): test.id()) finally: self.semaphore.release() + self.finalresult._stderr_buffer = io.StringIO(initial_value=self.outputbuf.getvalue().decode("utf-8")) + self.finalresult._stdout_buffer = io.StringIO() super(BBThreadsafeForwardingResult, self)._add_result_with_semaphore(method, test, *args, **kwargs) class ProxyTestResult: @@ -190,28 +196,20 @@ class ConcurrentTestSuite(unittest.TestSuite): self.removefunc = removefunc def run(self, result): - tests, totaltests = fork_for_tests(self.processes, self) + testservers, totaltests = fork_for_tests(self.processes, self) try: threads = {} queue = Queue() semaphore = threading.Semaphore(1) result.threadprogress = {} - for i, (test, testnum) in enumerate(tests): + for i, (testserver, testnum, output) in enumerate(testservers): result.threadprogress[i] = [] process_result = BBThreadsafeForwardingResult( ExtraResultsDecoderTestResult(result), - semaphore, i, testnum, totaltests) - # Force buffering of stdout/stderr so the console doesn't get corrupted by test output - # as per default in parent code - process_result.buffer = True - # We have to add a buffer object to stdout to keep subunit happy - process_result._stderr_buffer = io.StringIO() - process_result._stderr_buffer.buffer = dummybuf(process_result._stderr_buffer) - process_result._stdout_buffer = io.StringIO() - process_result._stdout_buffer.buffer = dummybuf(process_result._stdout_buffer) + semaphore, i, testnum, totaltests, output, result) reader_thread = threading.Thread( - target=self._run_test, args=(test, process_result, queue)) - threads[test] = reader_thread, process_result + target=self._run_test, args=(testserver, process_result, queue)) + threads[testserver] = reader_thread, process_result reader_thread.start() while threads: finished_test = queue.get() @@ -222,13 +220,13 @@ class ConcurrentTestSuite(unittest.TestSuite): process_result.stop() raise finally: - for test in tests: - test[0]._stream.close() + for testserver in testservers: + testserver[0]._stream.close() - def _run_test(self, test, process_result, queue): + def _run_test(self, testserver, process_result, queue): try: try: - test.run(process_result) + testserver.run(process_result) except Exception: # The run logic itself failed case = testtools.ErrorHolder( @@ -236,10 +234,10 @@ class ConcurrentTestSuite(unittest.TestSuite): error=sys.exc_info()) case.run(process_result) finally: - queue.put(test) + queue.put(testserver) def fork_for_tests(concurrency_num, suite): - result = [] + testservers = [] if 'BUILDDIR' in os.environ: selftestdir = get_test_layer() @@ -273,10 +271,11 @@ def fork_for_tests(concurrency_num, suite): newsi = os.open(os.devnull, os.O_RDWR) os.dup2(newsi, sys.stdin.fileno()) + # Send stdout/stderr over the stream + os.dup2(c2pwrite, sys.stdout.fileno()) + os.dup2(c2pwrite, sys.stderr.fileno()) + subunit_client = TestProtocolClient(stream) - # Force buffering of stdout/stderr so the console doesn't get corrupted by test output - # as per default in parent code - subunit_client.buffer = True subunit_result = AutoTimingTestResultDecorator(subunit_client) unittest_result = process_suite.run(ExtraResultsEncoderTestResult(subunit_result)) if ourpid != os.getpid(): @@ -306,9 +305,11 @@ def fork_for_tests(concurrency_num, suite): else: os.close(c2pwrite) stream = os.fdopen(c2pread, 'rb', 1) - test = ProtocolTestCase(stream) - result.append((test, numtests)) - return result, totaltests + # Collect stdout/stderr into an io buffer + output = io.BytesIO() + testserver = ProtocolTestCase(stream, passthrough=output) + testservers.append((testserver, numtests, output)) + return testservers, totaltests def partition_tests(suite, count): # Keep tests from the same class together but allow tests from modules diff --git a/poky/meta/lib/oeqa/selftest/cases/fetch.py b/poky/meta/lib/oeqa/selftest/cases/fetch.py index 76cbadf2f..67e85d3e4 100644 --- a/poky/meta/lib/oeqa/selftest/cases/fetch.py +++ b/poky/meta/lib/oeqa/selftest/cases/fetch.py @@ -2,6 +2,9 @@ # SPDX-License-Identifier: MIT # +import tempfile +import textwrap +import bb.tinfoil import oe.path from oeqa.selftest.case import OESelftestTestCase from oeqa.utils.commands import bitbake @@ -49,3 +52,54 @@ MIRRORS_forcevariable = "git://.*/.* http://downloads.yoctoproject.org/mirror/so self.write_config(features) oe.path.remove(dldir, recurse=True) bitbake("dbus-wait -c fetch -f") + + +class Dependencies(OESelftestTestCase): + def write_recipe(self, content): + f = tempfile.NamedTemporaryFile(mode="wt", suffix=".bb") + f.write(content) + f.flush() + return f + + def test_dependencies(self): + """ + Verify that the correct dependencies are generated for specific SRC_URI entries. + """ + with bb.tinfoil.Tinfoil() as tinfoil: + tinfoil.prepare(config_only=False, quiet=2) + + r = """ + LICENSE="CLOSED" + SRC_URI="http://example.com/tarball.zip" + """ + f = self.write_recipe(textwrap.dedent(r)) + d = tinfoil.parse_recipe_file(f.name) + self.assertIn("wget-native", d.getVarFlag("do_fetch", "depends")) + self.assertIn("unzip-native", d.getVarFlag("do_unpack", "depends")) + + # Verify that the downloadfilename overrides the URI + r = """ + LICENSE="CLOSED" + SRC_URI="https://example.com/tarball;downloadfilename=something.zip" + """ + f = self.write_recipe(textwrap.dedent(r)) + d = tinfoil.parse_recipe_file(f.name) + self.assertIn("wget-native", d.getVarFlag("do_fetch", "depends")) + self.assertIn("unzip-native", d.getVarFlag("do_unpack", "depends") or "") + + r = """ + LICENSE="CLOSED" + SRC_URI="ftp://example.com/tarball.lz" + """ + f = self.write_recipe(textwrap.dedent(r)) + d = tinfoil.parse_recipe_file(f.name) + self.assertIn("wget-native", d.getVarFlag("do_fetch", "depends")) + self.assertIn("lzip-native", d.getVarFlag("do_unpack", "depends")) + + r = """ + LICENSE="CLOSED" + SRC_URI="git://example.com/repo" + """ + f = self.write_recipe(textwrap.dedent(r)) + d = tinfoil.parse_recipe_file(f.name) + self.assertIn("git-native", d.getVarFlag("do_fetch", "depends")) diff --git a/poky/meta/lib/oeqa/selftest/cases/fitimage.py b/poky/meta/lib/oeqa/selftest/cases/fitimage.py index 02692de82..815ee48c0 100644 --- a/poky/meta/lib/oeqa/selftest/cases/fitimage.py +++ b/poky/meta/lib/oeqa/selftest/cases/fitimage.py @@ -231,6 +231,474 @@ UBOOT_MKIMAGE_SIGN_ARGS = "-c 'a smart comment'" result = runCmd('grep "### uboot-mkimage signing wrapper message" %s/log.do_assemble_fitimage' % tempdir, ignore_status=True) self.assertEqual(result.status, 0, 'UBOOT_MKIMAGE_SIGN did not work') + def test_uboot_fit_image(self): + """ + Summary: Check if Uboot FIT image and Image Tree Source + (its) are built and the Image Tree Source has the + correct fields. + Expected: 1. u-boot-fitImage and u-boot-its can be built + 2. The type, load address, entrypoint address and + default values of U-boot image are correct in the + Image Tree Source. Not all the fields are tested, + only the key fields that wont vary between + different architectures. + Product: oe-core + Author: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com> + based on work by Usama Arif <usama.arif@arm.com> + """ + config = """ +# We need at least CONFIG_SPL_LOAD_FIT and CONFIG_SPL_OF_CONTROL set +MACHINE = "qemuarm" +UBOOT_MACHINE = "am57xx_evm_defconfig" +SPL_BINARY = "MLO" + +# Enable creation of the U-Boot fitImage +UBOOT_FITIMAGE_ENABLE = "1" + +# (U-boot) fitImage properties +UBOOT_LOADADDRESS = "0x80080000" +UBOOT_ENTRYPOINT = "0x80080000" +UBOOT_FIT_DESC = "A model description" + +# Enable creation of Kernel fitImage +KERNEL_IMAGETYPES += " fitImage " +KERNEL_CLASSES = " kernel-fitimage" +UBOOT_SIGN_ENABLE = "1" +FIT_GENERATE_KEYS = "1" +UBOOT_SIGN_KEYDIR = "${TOPDIR}/signing-keys" +UBOOT_SIGN_KEYNAME = "oe-selftest" +FIT_SIGN_INDIVIDUAL = "1" +""" + self.write_config(config) + + # The U-Boot fitImage is created as part of linux recipe + bitbake("virtual/kernel") + + deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE') + machine = get_bb_var('MACHINE') + fitimage_its_path = os.path.join(deploy_dir_image, + "u-boot-its-%s" % (machine,)) + fitimage_path = os.path.join(deploy_dir_image, + "u-boot-fitImage-%s" % (machine,)) + + self.assertTrue(os.path.exists(fitimage_its_path), + "%s image tree source doesn't exist" % (fitimage_its_path)) + self.assertTrue(os.path.exists(fitimage_path), + "%s FIT image doesn't exist" % (fitimage_path)) + + # Check that the type, load address, entrypoint address and default + # values for kernel and ramdisk in Image Tree Source are as expected. + # The order of fields in the below array is important. Not all the + # fields are tested, only the key fields that wont vary between + # different architectures. + its_field_check = [ + 'description = "A model description";', + 'type = "standalone";', + 'load = <0x80080000>;', + 'entry = <0x80080000>;', + 'default = "conf";', + 'loadables = "uboot";', + 'fdt = "fdt";' + ] + + with open(fitimage_its_path) as its_file: + field_index = 0 + for line in its_file: + if field_index == len(its_field_check): + break + if its_field_check[field_index] in line: + field_index +=1 + + if field_index != len(its_field_check): # if its equal, the test passed + self.assertTrue(field_index == len(its_field_check), + "Fields in Image Tree Source File %s did not match, error in finding %s" + % (fitimage_its_path, its_field_check[field_index])) + + def test_uboot_sign_fit_image(self): + """ + Summary: Check if Uboot FIT image and Image Tree Source + (its) are built and the Image Tree Source has the + correct fields, in the scenario where the Kernel + is also creating/signing it's fitImage. + Expected: 1. u-boot-fitImage and u-boot-its can be built + 2. The type, load address, entrypoint address and + default values of U-boot image are correct in the + Image Tree Source. Not all the fields are tested, + only the key fields that wont vary between + different architectures. + Product: oe-core + Author: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com> + based on work by Usama Arif <usama.arif@arm.com> + """ + config = """ +# We need at least CONFIG_SPL_LOAD_FIT and CONFIG_SPL_OF_CONTROL set +MACHINE = "qemuarm" +UBOOT_MACHINE = "am57xx_evm_defconfig" +SPL_BINARY = "MLO" + +# Enable creation of the U-Boot fitImage +UBOOT_FITIMAGE_ENABLE = "1" + +# (U-boot) fitImage properties +UBOOT_LOADADDRESS = "0x80080000" +UBOOT_ENTRYPOINT = "0x80080000" +UBOOT_FIT_DESC = "A model description" +KERNEL_IMAGETYPES += " fitImage " +KERNEL_CLASSES = " kernel-fitimage test-mkimage-wrapper " +UBOOT_SIGN_ENABLE = "1" +FIT_GENERATE_KEYS = "1" +UBOOT_SIGN_KEYDIR = "${TOPDIR}/signing-keys" +UBOOT_SIGN_KEYNAME = "oe-selftest" +FIT_SIGN_INDIVIDUAL = "1" +UBOOT_MKIMAGE_SIGN_ARGS = "-c 'a smart U-Boot comment'" +""" + self.write_config(config) + + # The U-Boot fitImage is created as part of linux recipe + bitbake("virtual/kernel") + + deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE') + machine = get_bb_var('MACHINE') + fitimage_its_path = os.path.join(deploy_dir_image, + "u-boot-its-%s" % (machine,)) + fitimage_path = os.path.join(deploy_dir_image, + "u-boot-fitImage-%s" % (machine,)) + + self.assertTrue(os.path.exists(fitimage_its_path), + "%s image tree source doesn't exist" % (fitimage_its_path)) + self.assertTrue(os.path.exists(fitimage_path), + "%s FIT image doesn't exist" % (fitimage_path)) + + # Check that the type, load address, entrypoint address and default + # values for kernel and ramdisk in Image Tree Source are as expected. + # The order of fields in the below array is important. Not all the + # fields are tested, only the key fields that wont vary between + # different architectures. + its_field_check = [ + 'description = "A model description";', + 'type = "standalone";', + 'load = <0x80080000>;', + 'entry = <0x80080000>;', + 'default = "conf";', + 'loadables = "uboot";', + 'fdt = "fdt";' + ] + + with open(fitimage_its_path) as its_file: + field_index = 0 + for line in its_file: + if field_index == len(its_field_check): + break + if its_field_check[field_index] in line: + field_index +=1 + + if field_index != len(its_field_check): # if its equal, the test passed + self.assertTrue(field_index == len(its_field_check), + "Fields in Image Tree Source File %s did not match, error in finding %s" + % (fitimage_its_path, its_field_check[field_index])) + + + def test_sign_standalone_uboot_fit_image(self): + """ + Summary: Check if U-Boot FIT image and Image Tree Source (its) are + created and signed correctly for the scenario where only + the U-Boot proper fitImage is being created and signed. + Expected: 1) U-Boot its and FIT image are built successfully + 2) Scanning the its file indicates signing is enabled + as requested by SPL_SIGN_ENABLE (using keys generated + via UBOOT_FIT_GENERATE_KEYS) + 3) Dumping the FIT image indicates signature values + are present + 4) Examination of the do_uboot_assemble_fitimage + runfile/logfile indicate that UBOOT_MKIMAGE, UBOOT_MKIMAGE_SIGN + and SPL_MKIMAGE_SIGN_ARGS are working as expected. + Product: oe-core + Author: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com> based upon + work by Paul Eggleton <paul.eggleton@microsoft.com> and + Usama Arif <usama.arif@arm.com> + """ + config = """ +# There's no U-boot deconfig with CONFIG_FIT_SIGNATURE yet, so we need at +# least CONFIG_SPL_LOAD_FIT and CONFIG_SPL_OF_CONTROL set +MACHINE = "qemuarm" +UBOOT_MACHINE = "am57xx_evm_defconfig" +SPL_BINARY = "MLO" +# The kernel-fitimage class is a dependency even if we're only +# creating/signing the U-Boot fitImage +KERNEL_CLASSES = " kernel-fitimage test-mkimage-wrapper " +# Enable creation and signing of the U-Boot fitImage +UBOOT_FITIMAGE_ENABLE = "1" +SPL_SIGN_ENABLE = "1" +SPL_SIGN_KEYNAME = "spl-oe-selftest" +SPL_SIGN_KEYDIR = "${TOPDIR}/signing-keys" +UBOOT_DTB_BINARY = "u-boot.dtb" +UBOOT_ENTRYPOINT = "0x80000000" +UBOOT_LOADADDRESS = "0x80000000" +UBOOT_DTB_LOADADDRESS = "0x82000000" +UBOOT_ARCH = "arm" +SPL_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000" +SPL_MKIMAGE_SIGN_ARGS = "-c 'a smart U-Boot comment'" +UBOOT_EXTLINUX = "0" +UBOOT_FIT_GENERATE_KEYS = "1" +UBOOT_FIT_HASH_ALG = "sha256" +""" + self.write_config(config) + + # The U-Boot fitImage is created as part of linux recipe + bitbake("virtual/kernel") + + image_type = "core-image-minimal" + deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE') + machine = get_bb_var('MACHINE') + fitimage_its_path = os.path.join(deploy_dir_image, + "u-boot-its-%s" % (machine,)) + fitimage_path = os.path.join(deploy_dir_image, + "u-boot-fitImage-%s" % (machine,)) + + self.assertTrue(os.path.exists(fitimage_its_path), + "%s image tree source doesn't exist" % (fitimage_its_path)) + self.assertTrue(os.path.exists(fitimage_path), + "%s FIT image doesn't exist" % (fitimage_path)) + + req_itspaths = [ + ['/', 'images', 'uboot'], + ['/', 'images', 'uboot', 'signature'], + ['/', 'images', 'fdt'], + ['/', 'images', 'fdt', 'signature'], + ] + + itspath = [] + itspaths = [] + linect = 0 + sigs = {} + with open(fitimage_its_path) as its_file: + linect += 1 + for line in its_file: + line = line.strip() + if line.endswith('};'): + itspath.pop() + elif line.endswith('{'): + itspath.append(line[:-1].strip()) + itspaths.append(itspath[:]) + elif itspath and itspath[-1] == 'signature': + itsdotpath = '.'.join(itspath) + if not itsdotpath in sigs: + sigs[itsdotpath] = {} + if not '=' in line or not line.endswith(';'): + self.fail('Unexpected formatting in %s sigs section line %d:%s' % (fitimage_its_path, linect, line)) + key, value = line.split('=', 1) + sigs[itsdotpath][key.rstrip()] = value.lstrip().rstrip(';') + + for reqpath in req_itspaths: + if not reqpath in itspaths: + self.fail('Missing section in its file: %s' % reqpath) + + reqsigvalues_image = { + 'algo': '"sha256,rsa2048"', + 'key-name-hint': '"spl-oe-selftest"', + } + + for itspath, values in sigs.items(): + reqsigvalues = reqsigvalues_image + for reqkey, reqvalue in reqsigvalues.items(): + value = values.get(reqkey, None) + if value is None: + self.fail('Missing key "%s" in its file signature section %s' % (reqkey, itspath)) + self.assertEqual(value, reqvalue) + + # Dump the image to see if it really got signed + bitbake("u-boot-tools-native -c addto_recipe_sysroot") + result = runCmd('bitbake -e u-boot-tools-native | grep ^RECIPE_SYSROOT_NATIVE=') + recipe_sysroot_native = result.output.split('=')[1].strip('"') + dumpimage_path = os.path.join(recipe_sysroot_native, 'usr', 'bin', 'dumpimage') + result = runCmd('%s -l %s' % (dumpimage_path, fitimage_path)) + in_signed = None + signed_sections = {} + for line in result.output.splitlines(): + if line.startswith((' Image')): + in_signed = re.search('\((.*)\)', line).groups()[0] + elif re.match(' \w', line): + in_signed = None + elif in_signed: + if not in_signed in signed_sections: + signed_sections[in_signed] = {} + key, value = line.split(':', 1) + signed_sections[in_signed][key.strip()] = value.strip() + self.assertIn('uboot', signed_sections) + self.assertIn('fdt', signed_sections) + for signed_section, values in signed_sections.items(): + value = values.get('Sign algo', None) + self.assertEqual(value, 'sha256,rsa2048:spl-oe-selftest', 'Signature algorithm for %s not expected value' % signed_section) + value = values.get('Sign value', None) + self.assertEqual(len(value), 512, 'Signature value for section %s not expected length' % signed_section) + + # Check for SPL_MKIMAGE_SIGN_ARGS + result = runCmd('bitbake -e virtual/kernel | grep ^T=') + tempdir = result.output.split('=', 1)[1].strip().strip('') + result = runCmd('grep "a smart U-Boot comment" %s/run.do_uboot_assemble_fitimage' % tempdir, ignore_status=True) + self.assertEqual(result.status, 0, 'SPL_MKIMAGE_SIGN_ARGS value did not get used') + + # Check for evidence of test-mkimage-wrapper class + result = runCmd('grep "### uboot-mkimage wrapper message" %s/log.do_uboot_assemble_fitimage' % tempdir, ignore_status=True) + self.assertEqual(result.status, 0, 'UBOOT_MKIMAGE did not work') + result = runCmd('grep "### uboot-mkimage signing wrapper message" %s/log.do_uboot_assemble_fitimage' % tempdir, ignore_status=True) + self.assertEqual(result.status, 0, 'UBOOT_MKIMAGE_SIGN did not work') + + def test_sign_cascaded_uboot_fit_image(self): + """ + Summary: Check if U-Boot FIT image and Image Tree Source (its) are + created and signed correctly for the scenario where both + U-Boot proper and Kernel fitImages are being created and + signed. + Expected: 1) U-Boot its and FIT image are built successfully + 2) Scanning the its file indicates signing is enabled + as requested by SPL_SIGN_ENABLE (using keys generated + via UBOOT_FIT_GENERATE_KEYS) + 3) Dumping the FIT image indicates signature values + are present + 4) Examination of the do_uboot_assemble_fitimage + runfile/logfile indicate that UBOOT_MKIMAGE, UBOOT_MKIMAGE_SIGN + and SPL_MKIMAGE_SIGN_ARGS are working as expected. + Product: oe-core + Author: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com> based upon + work by Paul Eggleton <paul.eggleton@microsoft.com> and + Usama Arif <usama.arif@arm.com> + """ + config = """ +# There's no U-boot deconfig with CONFIG_FIT_SIGNATURE yet, so we need at +# least CONFIG_SPL_LOAD_FIT and CONFIG_SPL_OF_CONTROL set +MACHINE = "qemuarm" +UBOOT_MACHINE = "am57xx_evm_defconfig" +SPL_BINARY = "MLO" +# Enable creation and signing of the U-Boot fitImage +UBOOT_FITIMAGE_ENABLE = "1" +SPL_SIGN_ENABLE = "1" +SPL_SIGN_KEYNAME = "spl-cascaded-oe-selftest" +SPL_SIGN_KEYDIR = "${TOPDIR}/signing-keys" +UBOOT_DTB_BINARY = "u-boot.dtb" +UBOOT_ENTRYPOINT = "0x80000000" +UBOOT_LOADADDRESS = "0x80000000" +UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000" +UBOOT_MKIMAGE_SIGN_ARGS = "-c 'a smart cascaded Kernel comment'" +UBOOT_DTB_LOADADDRESS = "0x82000000" +UBOOT_ARCH = "arm" +SPL_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000" +SPL_MKIMAGE_SIGN_ARGS = "-c 'a smart cascaded U-Boot comment'" +UBOOT_EXTLINUX = "0" +UBOOT_FIT_GENERATE_KEYS = "1" +UBOOT_FIT_HASH_ALG = "sha256" +KERNEL_IMAGETYPES += " fitImage " +KERNEL_CLASSES = " kernel-fitimage test-mkimage-wrapper " +UBOOT_SIGN_ENABLE = "1" +FIT_GENERATE_KEYS = "1" +UBOOT_SIGN_KEYDIR = "${TOPDIR}/signing-keys" +UBOOT_SIGN_KEYNAME = "kernel-oe-selftest" +FIT_SIGN_INDIVIDUAL = "1" +""" + self.write_config(config) + + # The U-Boot fitImage is created as part of linux recipe + bitbake("virtual/kernel") + + image_type = "core-image-minimal" + deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE') + machine = get_bb_var('MACHINE') + fitimage_its_path = os.path.join(deploy_dir_image, + "u-boot-its-%s" % (machine,)) + fitimage_path = os.path.join(deploy_dir_image, + "u-boot-fitImage-%s" % (machine,)) + + self.assertTrue(os.path.exists(fitimage_its_path), + "%s image tree source doesn't exist" % (fitimage_its_path)) + self.assertTrue(os.path.exists(fitimage_path), + "%s FIT image doesn't exist" % (fitimage_path)) + + req_itspaths = [ + ['/', 'images', 'uboot'], + ['/', 'images', 'uboot', 'signature'], + ['/', 'images', 'fdt'], + ['/', 'images', 'fdt', 'signature'], + ] + + itspath = [] + itspaths = [] + linect = 0 + sigs = {} + with open(fitimage_its_path) as its_file: + linect += 1 + for line in its_file: + line = line.strip() + if line.endswith('};'): + itspath.pop() + elif line.endswith('{'): + itspath.append(line[:-1].strip()) + itspaths.append(itspath[:]) + elif itspath and itspath[-1] == 'signature': + itsdotpath = '.'.join(itspath) + if not itsdotpath in sigs: + sigs[itsdotpath] = {} + if not '=' in line or not line.endswith(';'): + self.fail('Unexpected formatting in %s sigs section line %d:%s' % (fitimage_its_path, linect, line)) + key, value = line.split('=', 1) + sigs[itsdotpath][key.rstrip()] = value.lstrip().rstrip(';') + + for reqpath in req_itspaths: + if not reqpath in itspaths: + self.fail('Missing section in its file: %s' % reqpath) + + reqsigvalues_image = { + 'algo': '"sha256,rsa2048"', + 'key-name-hint': '"spl-cascaded-oe-selftest"', + } + + for itspath, values in sigs.items(): + reqsigvalues = reqsigvalues_image + for reqkey, reqvalue in reqsigvalues.items(): + value = values.get(reqkey, None) + if value is None: + self.fail('Missing key "%s" in its file signature section %s' % (reqkey, itspath)) + self.assertEqual(value, reqvalue) + + # Dump the image to see if it really got signed + bitbake("u-boot-tools-native -c addto_recipe_sysroot") + result = runCmd('bitbake -e u-boot-tools-native | grep ^RECIPE_SYSROOT_NATIVE=') + recipe_sysroot_native = result.output.split('=')[1].strip('"') + dumpimage_path = os.path.join(recipe_sysroot_native, 'usr', 'bin', 'dumpimage') + result = runCmd('%s -l %s' % (dumpimage_path, fitimage_path)) + in_signed = None + signed_sections = {} + for line in result.output.splitlines(): + if line.startswith((' Image')): + in_signed = re.search('\((.*)\)', line).groups()[0] + elif re.match(' \w', line): + in_signed = None + elif in_signed: + if not in_signed in signed_sections: + signed_sections[in_signed] = {} + key, value = line.split(':', 1) + signed_sections[in_signed][key.strip()] = value.strip() + self.assertIn('uboot', signed_sections) + self.assertIn('fdt', signed_sections) + for signed_section, values in signed_sections.items(): + value = values.get('Sign algo', None) + self.assertEqual(value, 'sha256,rsa2048:spl-cascaded-oe-selftest', 'Signature algorithm for %s not expected value' % signed_section) + value = values.get('Sign value', None) + self.assertEqual(len(value), 512, 'Signature value for section %s not expected length' % signed_section) + + # Check for SPL_MKIMAGE_SIGN_ARGS + result = runCmd('bitbake -e virtual/kernel | grep ^T=') + tempdir = result.output.split('=', 1)[1].strip().strip('') + result = runCmd('grep "a smart cascaded U-Boot comment" %s/run.do_uboot_assemble_fitimage' % tempdir, ignore_status=True) + self.assertEqual(result.status, 0, 'SPL_MKIMAGE_SIGN_ARGS value did not get used') + + # Check for evidence of test-mkimage-wrapper class + result = runCmd('grep "### uboot-mkimage wrapper message" %s/log.do_uboot_assemble_fitimage' % tempdir, ignore_status=True) + self.assertEqual(result.status, 0, 'UBOOT_MKIMAGE did not work') + result = runCmd('grep "### uboot-mkimage signing wrapper message" %s/log.do_uboot_assemble_fitimage' % tempdir, ignore_status=True) + self.assertEqual(result.status, 0, 'UBOOT_MKIMAGE_SIGN did not work') + + + def test_initramfs_bundle(self): """ Summary: Verifies the content of the initramfs bundle node in the FIT Image Tree Source (its) diff --git a/poky/meta/lib/oeqa/targetcontrol.py b/poky/meta/lib/oeqa/targetcontrol.py index 19f5a4ea7..12057f855 100644 --- a/poky/meta/lib/oeqa/targetcontrol.py +++ b/poky/meta/lib/oeqa/targetcontrol.py @@ -131,6 +131,7 @@ class QemuTarget(BaseTarget): logfile = self.qemulog, kernel = self.kernel, boottime = int(d.getVar("TEST_QEMUBOOT_TIMEOUT")), + tmpfsdir = d.getVar("RUNQEMU_TMPFS_DIR"), logger = logger) else: self.runner = QemuRunner(machine=d.getVar("MACHINE"), @@ -144,6 +145,7 @@ class QemuTarget(BaseTarget): dump_dir = dump_dir, dump_host_cmds = d.getVar("testimage_dump_host"), logger = logger, + tmpfsdir = d.getVar("RUNQEMU_TMPFS_DIR"), serial_ports = len(d.getVar("SERIAL_CONSOLES").split())) self.target_dumper = TargetDumper(dump_target_cmds, dump_dir, self.runner) diff --git a/poky/meta/lib/oeqa/utils/qemurunner.py b/poky/meta/lib/oeqa/utils/qemurunner.py index eb23dbceb..278904ba0 100644 --- a/poky/meta/lib/oeqa/utils/qemurunner.py +++ b/poky/meta/lib/oeqa/utils/qemurunner.py @@ -32,7 +32,7 @@ re_control_char = re.compile('[%s]' % re.escape("".join(control_chars))) class QemuRunner: def __init__(self, machine, rootfs, display, tmpdir, deploy_dir_image, logfile, boottime, dump_dir, dump_host_cmds, - use_kvm, logger, use_slirp=False, serial_ports=2, boot_patterns = defaultdict(str), use_ovmf=False, workdir=None): + use_kvm, logger, use_slirp=False, serial_ports=2, boot_patterns = defaultdict(str), use_ovmf=False, workdir=None, tmpfsdir=None): # Popen object for runqemu self.runqemu = None @@ -61,6 +61,7 @@ class QemuRunner: self.serial_ports = serial_ports self.msg = '' self.boot_patterns = boot_patterns + self.tmpfsdir = tmpfsdir self.runqemutime = 120 if not workdir: @@ -150,6 +151,9 @@ class QemuRunner: else: env["DEPLOY_DIR_IMAGE"] = self.deploy_dir_image + if self.tmpfsdir: + env["RUNQEMU_TMPFS_DIR"] = self.tmpfsdir + if not launch_cmd: launch_cmd = 'runqemu %s' % ('snapshot' if discard_writes else '') if self.use_kvm: diff --git a/poky/meta/lib/oeqa/utils/qemutinyrunner.py b/poky/meta/lib/oeqa/utils/qemutinyrunner.py index 5c92941c0..20009401c 100644 --- a/poky/meta/lib/oeqa/utils/qemutinyrunner.py +++ b/poky/meta/lib/oeqa/utils/qemutinyrunner.py @@ -19,7 +19,7 @@ from .qemurunner import QemuRunner class QemuTinyRunner(QemuRunner): - def __init__(self, machine, rootfs, display, tmpdir, deploy_dir_image, logfile, kernel, boottime, logger): + def __init__(self, machine, rootfs, display, tmpdir, deploy_dir_image, logfile, kernel, boottime, logger, tmpfsdir=None): # Popen object for runqemu self.runqemu = None @@ -37,6 +37,7 @@ class QemuTinyRunner(QemuRunner): self.deploy_dir_image = deploy_dir_image self.logfile = logfile self.boottime = boottime + self.tmpfsdir = tmpfsdir self.runqemutime = 60 self.socketfile = "console.sock" @@ -83,6 +84,9 @@ class QemuTinyRunner(QemuRunner): return False else: os.environ["DEPLOY_DIR_IMAGE"] = self.deploy_dir_image + if self.tmpfsdir: + env["RUNQEMU_TMPFS_DIR"] = self.tmpfsdir + # Set this flag so that Qemu doesn't do any grabs as SDL grabs interact # badly with screensavers. diff --git a/poky/meta/recipes-bsp/u-boot/u-boot.inc b/poky/meta/recipes-bsp/u-boot/u-boot.inc index 251178db3..5398c2e62 100644 --- a/poky/meta/recipes-bsp/u-boot/u-boot.inc +++ b/poky/meta/recipes-bsp/u-boot/u-boot.inc @@ -24,52 +24,6 @@ PACKAGECONFIG[openssl] = ",,openssl-native" # file already exists it will not be overwritten. UBOOT_LOCALVERSION ?= "" -# Some versions of u-boot use .bin and others use .img. By default use .bin -# but enable individual recipes to change this value. -UBOOT_SUFFIX ??= "bin" -UBOOT_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}" -UBOOT_SYMLINK ?= "u-boot-${MACHINE}.${UBOOT_SUFFIX}" -UBOOT_MAKE_TARGET ?= "all" - -# Output the ELF generated. Some platforms can use the ELF file and directly -# load it (JTAG booting, QEMU) additionally the ELF can be used for debugging -# purposes. -UBOOT_ELF ?= "" -UBOOT_ELF_SUFFIX ?= "elf" -UBOOT_ELF_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.${UBOOT_ELF_SUFFIX}" -UBOOT_ELF_BINARY ?= "u-boot.${UBOOT_ELF_SUFFIX}" -UBOOT_ELF_SYMLINK ?= "u-boot-${MACHINE}.${UBOOT_ELF_SUFFIX}" - -# Some versions of u-boot build an SPL (Second Program Loader) image that -# should be packaged along with the u-boot binary as well as placed in the -# deploy directory. For those versions they can set the following variables -# to allow packaging the SPL. -SPL_BINARY ?= "" -SPL_BINARYNAME ?= "${@os.path.basename(d.getVar("SPL_BINARY"))}" -SPL_IMAGE ?= "${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}" -SPL_SYMLINK ?= "${SPL_BINARYNAME}-${MACHINE}" - -# Additional environment variables or a script can be installed alongside -# u-boot to be used automatically on boot. This file, typically 'uEnv.txt' -# or 'boot.scr', should be packaged along with u-boot as well as placed in the -# deploy directory. Machine configurations needing one of these files should -# include it in the SRC_URI and set the UBOOT_ENV parameter. -UBOOT_ENV_SUFFIX ?= "txt" -UBOOT_ENV ?= "" -UBOOT_ENV_BINARY ?= "${UBOOT_ENV}.${UBOOT_ENV_SUFFIX}" -UBOOT_ENV_IMAGE ?= "${UBOOT_ENV}-${MACHINE}-${PV}-${PR}.${UBOOT_ENV_SUFFIX}" -UBOOT_ENV_SYMLINK ?= "${UBOOT_ENV}-${MACHINE}.${UBOOT_ENV_SUFFIX}" - -# Default name of u-boot initial env, but enable individual recipes to change -# this value. -UBOOT_INITIAL_ENV ?= "${PN}-initial-env" - -# U-Boot EXTLINUX variables. U-Boot searches for /boot/extlinux/extlinux.conf -# to find EXTLINUX conf file. -UBOOT_EXTLINUX_INSTALL_DIR ?= "/boot/extlinux" -UBOOT_EXTLINUX_CONF_NAME ?= "extlinux.conf" -UBOOT_EXTLINUX_SYMLINK ?= "${UBOOT_EXTLINUX_CONF_NAME}-${MACHINE}-${PR}" - do_configure () { if [ -n "${UBOOT_CONFIG}" ]; then unset i j diff --git a/poky/meta/recipes-core/images/build-appliance-image_15.0.0.bb b/poky/meta/recipes-core/images/build-appliance-image_15.0.0.bb index 925235db6..1aeb952db 100644 --- a/poky/meta/recipes-core/images/build-appliance-image_15.0.0.bb +++ b/poky/meta/recipes-core/images/build-appliance-image_15.0.0.bb @@ -24,7 +24,7 @@ IMAGE_FSTYPES = "wic.vmdk wic.vhd wic.vhdx" inherit core-image setuptools3 -SRCREV ?= "c6483187f96c6d21b7129ad78de3ff976fbe5970" +SRCREV ?= "42514ade8bdb9502f49a56752561f6c2e9f23348" SRC_URI = "git://git.yoctoproject.org/poky \ file://Yocto_Build_Appliance.vmx \ file://Yocto_Build_Appliance.vmxf \ diff --git a/poky/meta/recipes-devtools/apt/apt_2.2.2.bb b/poky/meta/recipes-devtools/apt/apt_2.2.2.bb index d1aa5de8d..7d1bce558 100644 --- a/poky/meta/recipes-devtools/apt/apt_2.2.2.bb +++ b/poky/meta/recipes-devtools/apt/apt_2.2.2.bb @@ -44,6 +44,7 @@ DEPENDS += "db gnutls lz4 zlib bzip2 xz libgcrypt xxhash" EXTRA_OECMAKE_append = " -DCURRENT_VENDOR=debian -DWITH_DOC=False \ -DDPKG_DATADIR=${datadir}/dpkg \ -DTRIEHASH_EXECUTABLE=${WORKDIR}/triehash \ + -DCMAKE_DISABLE_FIND_PACKAGE_ZSTD=True \ -DWITH_TESTS=False \ " diff --git a/poky/meta/recipes-devtools/binutils/binutils/0008-warn-for-uses-of-system-directories-when-cross-linki.patch b/poky/meta/recipes-devtools/binutils/binutils/0008-warn-for-uses-of-system-directories-when-cross-linki.patch index 3f83d48f6..5c148eaa9 100644 --- a/poky/meta/recipes-devtools/binutils/binutils/0008-warn-for-uses-of-system-directories-when-cross-linki.patch +++ b/poky/meta/recipes-devtools/binutils/binutils/0008-warn-for-uses-of-system-directories-when-cross-linki.patch @@ -1,4 +1,4 @@ -From a1d0ca24d3bbdf4cb37537cd84d04a17bf0f813b Mon Sep 17 00:00:00 2001 +From bb48edf1a87bbc711e8978dd1e9112fe953dc1bf Mon Sep 17 00:00:00 2001 From: Khem Raj <raj.khem@gmail.com> Date: Fri, 15 Jan 2016 06:31:09 +0000 Subject: [PATCH] warn for uses of system directories when cross linking @@ -59,8 +59,8 @@ Signed-off-by: Khem Raj <raj.khem@gmail.com> ld/ldfile.c | 17 +++++++++++++++++ ld/ldlex.h | 2 ++ ld/ldmain.c | 2 ++ - ld/lexsup.c | 15 +++++++++++++++ - 9 files changed, 85 insertions(+) + ld/lexsup.c | 16 ++++++++++++++++ + 9 files changed, 86 insertions(+) diff --git a/ld/config.in b/ld/config.in index 7b60d778587..37b8e9b6f6c 100644 @@ -77,7 +77,7 @@ index 7b60d778587..37b8e9b6f6c 100644 #undef EXTRA_SHLIB_EXTENSION diff --git a/ld/configure b/ld/configure -index d399d08d0c4..8355c433c76 100755 +index b0969791959..50bb04ce6a8 100755 --- a/ld/configure +++ b/ld/configure @@ -828,6 +828,7 @@ with_lib_path @@ -235,7 +235,7 @@ index 080b1c4c6c2..78d8a2df278 100644 /* We initialize DEMANGLING based on the environment variable COLLECT_NO_DEMANGLE. The gcc collect2 program will demangle the diff --git a/ld/lexsup.c b/ld/lexsup.c -index f005a58a045..c83292a9427 100644 +index f005a58a045..5eb8439fef7 100644 --- a/ld/lexsup.c +++ b/ld/lexsup.c @@ -591,6 +591,14 @@ static const struct ld_option ld_options[] = @@ -253,17 +253,18 @@ index f005a58a045..c83292a9427 100644 }; #define OPTION_COUNT ARRAY_SIZE (ld_options) -@@ -1674,6 +1682,13 @@ parse_args (unsigned argc, char **argv) - - case OPTION_PRINT_MAP_DISCARDED: +@@ -1676,6 +1684,14 @@ parse_args (unsigned argc, char **argv) config.print_map_discarded = TRUE; -+ + break; + + case OPTION_NO_POISON_SYSTEM_DIRECTORIES: + command_line.poison_system_directories = FALSE; + break; + + case OPTION_ERROR_POISON_SYSTEM_DIRECTORIES: + command_line.error_poison_system_directories = TRUE; - break; - ++ break; ++ case OPTION_DEPENDENCY_FILE: + config.dependency_file = optarg; + break; diff --git a/poky/meta/recipes-devtools/perl/files/perl-rdepends.txt b/poky/meta/recipes-devtools/perl/files/perl-rdepends.txt index e7cd55198..f20fc44b5 100644 --- a/poky/meta/recipes-devtools/perl/files/perl-rdepends.txt +++ b/poky/meta/recipes-devtools/perl/files/perl-rdepends.txt @@ -1,3 +1,11 @@ + +# Some additional dependencies that the above doesn't manage to figure out +RDEPENDS_perl-module-file-spec += "perl-module-file-spec-unix" +RDEPENDS_perl-module-math-bigint += "perl-module-math-bigint-calc" +RDEPENDS_perl-module-thread-queue += "perl-module-attributes" +RDEPENDS_perl-module-overload += "perl-module-overloading" + +# Generated depends list beyond this line RDEPENDS_perl-module-anydbm-file += "perl-module-strict" RDEPENDS_perl-module-anydbm-file += "perl-module-warnings" RDEPENDS_perl-module-app-cpan += "perl-module-config" diff --git a/poky/meta/recipes-devtools/perl/perl_5.32.1.bb b/poky/meta/recipes-devtools/perl/perl_5.32.1.bb index 1fafc0a8c..b28040c7f 100644 --- a/poky/meta/recipes-devtools/perl/perl_5.32.1.bb +++ b/poky/meta/recipes-devtools/perl/perl_5.32.1.bb @@ -320,6 +320,9 @@ python split_perl_packages () { # Read the pre-generated dependency file, and use it to set module dependecies for line in open(d.expand("${WORKDIR}") + '/perl-rdepends.txt').readlines(): splitline = line.split() + # Filter empty lines and comments + if len(splitline) == 0 or splitline[0].startswith("#"): + continue if bb.data.inherits_class('native', d): module = splitline[0] + '-native' depends = "perl-native" @@ -367,8 +370,8 @@ EOPREAMBLE sort -u | \ sed 's/^/RDEPENDS_/;s/perl-module-/${PN}-module-/g;s/module-\(module-\)/\1/g;s/\(module-load\)-conditional/\1/g;s/encode-configlocal/&-pm/;' | \ egrep -wv '=>|module-a|module-apache.?|module-apr|module-authen-sasl|module-b-asmdata|module-convert-ebcdic|module-devel-size|module-digest-perl-md5|module-dumpvalue|module-extutils-constant-aaargh56hash|module-extutils-xssymset|module-file-bsdglob|module-for|module-it|module-io-socket-inet6|module-io-socket-ssl|module-io-string|module-ipc-system-simple|module-lexical|module-local-lib|metadata|module-modperl-util|module-pluggable-object|module-test-builder-io-scalar|module-test2|module-text-unidecode|module-unicore|module-win32|objects\sload|syscall.ph|systeminfo.ph|%s' | \ - egrep -wv '=>|module-algorithm-diff|module-carp|module-c<extutils-mm-unix>|module-encode-hanextra|module-extutils-makemaker-version-regex|module-file-spec|module-io-compress-lzma|module-locale-maketext-lexicon|module-log-agent|module-meta-notation|module-net-localcfg|module-net-ping-external|module-b-deparse|module-scalar-util|module-some-module|module-symbol|module-uri|module-win32api-file' >> ${WORKDIR}/perl-rdepends.generated - cp ${WORKDIR}/perl-rdepends.generated ${THISDIR}/files/perl-rdepends.txt + egrep -wv '=>|module-algorithm-diff|module-carp|module-c<extutils-mm-unix>|module-l<extutils-mm-unix>|module-encode-hanextra|module-extutils-makemaker-version-regex|module-file-spec|module-io-compress-lzma|module-io-uncompress-unxz|module-locale-maketext-lexicon|module-log-agent|module-meta-notation|module-net-localcfg|module-net-ping-external|module-b-deparse|module-scalar-util|module-some-module|module-symbol|module-uri|module-win32api-file' > ${WORKDIR}/perl-rdepends.generated + cat ${WORKDIR}/perl-rdepends.inc ${WORKDIR}/perl-rdepends.generated > ${THISDIR}/files/perl-rdepends.txt } # bitbake perl -c create_rdepends_inc diff --git a/poky/meta/recipes-devtools/python/python3/0001-Skip-failing-tests-due-to-load-variability-on-YP-AB.patch b/poky/meta/recipes-devtools/python/python3/0001-Skip-failing-tests-due-to-load-variability-on-YP-AB.patch new file mode 100644 index 000000000..a49d603d4 --- /dev/null +++ b/poky/meta/recipes-devtools/python/python3/0001-Skip-failing-tests-due-to-load-variability-on-YP-AB.patch @@ -0,0 +1,53 @@ +From 0b25b66d4f54bd74615c9ff10f3fae8f0d1c548d Mon Sep 17 00:00:00 2001 +From: Yi Fan Yu <yifan.yu@windriver.com> +Date: Thu, 1 Apr 2021 13:08:37 -0700 +Subject: [PATCH] Skip failing tests due to load variability on YP AB + + +Skip these tests until AB-INT is solved. + +[YOCTO #14296] + +Upstream-Status: Inappropriate [OE-Specific] + +Signed-off-by: Yi Fan Yu <yifan.yu@windriver.com> +--- + Lib/test/_test_multiprocessing.py | 2 ++ + Lib/test/test_time.py | 1 + + 2 files changed, 3 insertions(+) + +diff --git a/Lib/test/_test_multiprocessing.py b/Lib/test/_test_multiprocessing.py +index fd3b430..cda29f6 100644 +--- a/Lib/test/_test_multiprocessing.py ++++ b/Lib/test/_test_multiprocessing.py +@@ -568,6 +568,7 @@ def test_close(self): + + close_queue(q) + ++ @unittest.skip('timing related test, dependent on load') + def test_many_processes(self): + if self.TYPE == 'threads': + self.skipTest('test not appropriate for {}'.format(self.TYPE)) +@@ -4715,6 +4716,7 @@ def signal_and_sleep(cls, sem, period): + sem.release() + time.sleep(period) + ++ @unittest.skip('timing related test, dependent on load') + def test_wait_integer(self): + from multiprocessing.connection import wait + +diff --git a/Lib/test/test_time.py b/Lib/test/test_time.py +index 3258298..adcf407 100644 +--- a/Lib/test/test_time.py ++++ b/Lib/test/test_time.py +@@ -474,6 +474,7 @@ def test_monotonic(self): + def test_perf_counter(self): + time.perf_counter() + ++ @unittest.skip('timing related test, dependent on load') + def test_process_time(self): + # process_time() should not include time spend during a sleep + start = time.process_time() +-- +2.17.1 + diff --git a/poky/meta/recipes-devtools/python/python3_3.9.2.bb b/poky/meta/recipes-devtools/python/python3_3.9.2.bb index c5e47eec4..fd1172335 100644 --- a/poky/meta/recipes-devtools/python/python3_3.9.2.bb +++ b/poky/meta/recipes-devtools/python/python3_3.9.2.bb @@ -30,6 +30,7 @@ SRC_URI = "http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \ file://0001-Makefile-do-not-compile-.pyc-in-parallel.patch \ file://0020-configure.ac-setup.py-do-not-add-a-curses-include-pa.patch \ file://0001-Lib-sysconfig.py-use-libdir-values-from-configuratio.patch \ + file://0001-Skip-failing-tests-due-to-load-variability-on-YP-AB.patch \ " SRC_URI_append_class-native = " \ diff --git a/poky/meta/recipes-devtools/valgrind/valgrind/run-ptest b/poky/meta/recipes-devtools/valgrind/valgrind/run-ptest index e8a1a668f..f37780ef6 100755 --- a/poky/meta/recipes-devtools/valgrind/valgrind/run-ptest +++ b/poky/meta/recipes-devtools/valgrind/valgrind/run-ptest @@ -55,6 +55,16 @@ for i in `cat remove-for-all`; do mv $i.IGNORE $i.vgtest; done +echo "Failed test details..." +failed_tests=`grep FAIL: ${LOG} | awk '{print $2}'` +for test in $failed_tests; do + for diff_results in `ls $test*.diff`; do + echo $diff_results + echo '************' + cat $diff_results + done +done + passed=`grep PASS: ${LOG}|wc -l` failed=`grep FAIL: ${LOG}|wc -l` skipped=`grep SKIP: ${LOG}|wc -l` diff --git a/poky/meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb b/poky/meta/recipes-graphics/mesa/mesa-gl_21.0.1.bb index e50782be1..dff79f0be 100644 --- a/poky/meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb +++ b/poky/meta/recipes-graphics/mesa/mesa-gl_21.0.1.bb @@ -8,8 +8,9 @@ S = "${WORKDIR}/mesa-${PV}" # At least one DRI rendering engine is required to build mesa. # When no X11 is available, use osmesa for the rendering engine. -PACKAGECONFIG ??= "opengl dri ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 'osmesa', d)}" -PACKAGECONFIG_class-target = "opengl dri ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 'osmesa', d)}" +PACKAGECONFIG ??= "opengl dri ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 'osmesa gallium', d)}" +PACKAGECONFIG_class-target = "opengl dri ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 'osmesa gallium', d)}" -# When NOT using X11, we need to make sure we have swrast available. -DRIDRIVERS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', '', ',swrast', d)}" +# 21.0.0 version fails to build when any driver is enabled in DRIDRIVERS +# ./mesa-21.0.0/meson.build:519:4: ERROR: Problem encountered: building dri drivers require at least one windowing system +DRIDRIVERS ?= "" diff --git a/poky/meta/recipes-graphics/mesa/mesa.inc b/poky/meta/recipes-graphics/mesa/mesa.inc index e9b72ce06..caf3c62ad 100644 --- a/poky/meta/recipes-graphics/mesa/mesa.inc +++ b/poky/meta/recipes-graphics/mesa/mesa.inc @@ -21,7 +21,7 @@ SRC_URI = "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \ file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \ " -SRC_URI[sha256sum] = "e6204e98e6a8d77cf9dc5d34f99dd8e3ef7144f3601c808ca0dd26ba522e0d84" +SRC_URI[sha256sum] = "379fc984459394f2ab2d84049efdc3a659869dc1328ce72ef0598506611712bb" UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P<pver>\d+(\.\d+)+)" @@ -87,8 +87,8 @@ PACKAGECONFIG_class-target ??= "${@bb.utils.filter('DISTRO_FEATURES', 'wayland v ${@bb.utils.contains('DISTRO_FEATURES', 'x11 vulkan', 'dri3', '', d)} \ elf-tls \ " -PACKAGECONFIG_class-native ?= "gbm dri egl opengl elf-tls x11" -PACKAGECONFIG_class-nativesdk ?= "gbm dri egl opengl elf-tls x11" +PACKAGECONFIG_class-native ?= "gbm gallium egl opengl elf-tls x11" +PACKAGECONFIG_class-nativesdk ?= "gbm gallium egl opengl elf-tls x11" PACKAGECONFIG_remove_libc-musl = "elf-tls" @@ -102,10 +102,6 @@ PACKAGECONFIG[elf-tls] = "-Delf-tls=true, -Delf-tls=false" PACKAGECONFIG[xvmc] = "-Dgallium-xvmc=enabled,-Dgallium-xvmc=disabled,libxvmc" PACKAGECONFIG[wayland] = ",,wayland-native wayland libdrm wayland-protocols" -DRIDRIVERS_class-native = "nouveau" -DRIDRIVERS_class-nativesdk = "nouveau" -DRIDRIVERS_append_x86_class-target = ",r100,r200,nouveau,i965,i915" -DRIDRIVERS_append_x86-64_class-target = ",r100,r200,nouveau,i965,i915" # "dri" requires "opengl" PACKAGECONFIG[dri] = "-Ddri-drivers=${@strip_comma('${DRIDRIVERS}')}, -Ddri-drivers='', xorgproto libdrm" PACKAGECONFIG[dri3] = "-Ddri3=enabled, -Ddri3=disabled, xorgproto libxshmfence" @@ -153,7 +149,7 @@ GALLIUMDRIVERS_append = "${@bb.utils.contains('PACKAGECONFIG', 'gallium-llvm', ' GALLIUMDRIVERS_append = "${@bb.utils.contains('PACKAGECONFIG', 'r600', ',r600', '', d)}" GALLIUMDRIVERS_append = "${@bb.utils.contains('PACKAGECONFIG', 'virgl', ',virgl', '', d)}" -PACKAGECONFIG[gallium] = "-Dgallium-drivers=${@strip_comma('${GALLIUMDRIVERS}')}, -Dgallium-drivers=''" +PACKAGECONFIG[gallium] = "-Dgallium-drivers=${@strip_comma('${GALLIUMDRIVERS}')}, -Dgallium-drivers='', libdrm" PACKAGECONFIG[gallium-llvm] = "-Dllvm=enabled -Dshared-llvm=enabled, -Dllvm=disabled, llvm${MESA_LLVM_RELEASE} llvm-native \ elfutils" PACKAGECONFIG[xa] = "-Dgallium-xa=enabled, -Dgallium-xa=disabled" diff --git a/poky/meta/recipes-graphics/mesa/mesa_21.0.0.bb b/poky/meta/recipes-graphics/mesa/mesa_21.0.0.bb deleted file mode 100644 index 96e8aa38d..000000000 --- a/poky/meta/recipes-graphics/mesa/mesa_21.0.0.bb +++ /dev/null @@ -1,2 +0,0 @@ -require ${BPN}.inc - diff --git a/poky/meta/recipes-graphics/mesa/mesa_21.0.1.bb b/poky/meta/recipes-graphics/mesa/mesa_21.0.1.bb new file mode 100644 index 000000000..8c584d8e9 --- /dev/null +++ b/poky/meta/recipes-graphics/mesa/mesa_21.0.1.bb @@ -0,0 +1,4 @@ +require ${BPN}.inc + +DRIDRIVERS_append_x86_class-target = ",r100,r200,nouveau,i965,i915" +DRIDRIVERS_append_x86-64_class-target = ",r100,r200,nouveau,i965,i915" diff --git a/poky/meta/recipes-graphics/xorg-lib/libxcb_1.14.bb b/poky/meta/recipes-graphics/xorg-lib/libxcb_1.14.bb index e9f6051b6..f0a223a19 100644 --- a/poky/meta/recipes-graphics/xorg-lib/libxcb_1.14.bb +++ b/poky/meta/recipes-graphics/xorg-lib/libxcb_1.14.bb @@ -19,7 +19,7 @@ BBCLASSEXTEND = "native nativesdk" DEPENDS = "xcb-proto xorgproto libxau libpthread-stubs libxdmcp" -PACKAGES_DYNAMIC = "^libxcb-.*" +PACKAGES_DYNAMIC = "^${PN}-.*" FILES_${PN} = "${libdir}/libxcb.so.*" @@ -35,5 +35,5 @@ do_install_append () { } python populate_packages_prepend () { - do_split_packages(d, '${libdir}', r'^libxcb-(.*)\.so\..*$', 'libxcb-%s', 'XCB library module for %s', allow_links=True) + do_split_packages(d, '${libdir}', r'^libxcb-(.*)\.so\..*$', '${PN}-%s', 'XCB library module for %s', allow_links=True) } diff --git a/poky/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb b/poky/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb index 92ffa4720..b2b50b9bc 100644 --- a/poky/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb +++ b/poky/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb @@ -19,7 +19,7 @@ DEPENDS += "bc-native bison-native" DEPENDS += "gmp-native" EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" HOSTCPP="${BUILD_CPP}"" -EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX} ${BUILD_CXXFLAGS} ${BUILD_LDFLAGS}"" +EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX} ${BUILD_CXXFLAGS} ${BUILD_LDFLAGS}" CROSS_COMPILE=${TARGET_PREFIX}" # Build some host tools under work-shared. CC, LD, and AR are probably # not used, but this is the historical way of invoking "make scripts". diff --git a/poky/meta/recipes-kernel/perf/perf.bb b/poky/meta/recipes-kernel/perf/perf.bb index 1274df68c..b4683720a 100644 --- a/poky/meta/recipes-kernel/perf/perf.bb +++ b/poky/meta/recipes-kernel/perf/perf.bb @@ -324,7 +324,7 @@ RDEPENDS_${PN} += "elfutils bash" RDEPENDS_${PN}-archive =+ "bash" RDEPENDS_${PN}-python =+ "bash python3 python3-modules ${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python3', '', d)}" RDEPENDS_${PN}-perl =+ "bash perl perl-modules" -RDEPENDS_${PN}-tests =+ "python3" +RDEPENDS_${PN}-tests =+ "python3 bash" RSUGGESTS_SCRIPTING = "${@bb.utils.contains('PACKAGECONFIG', 'scripting', '${PN}-perl ${PN}-python', '',d)}" RSUGGESTS_${PN} += "${PN}-archive ${PN}-tests ${RSUGGESTS_SCRIPTING}" diff --git a/poky/meta/recipes-sato/webkit/webkitgtk/include_array.patch b/poky/meta/recipes-sato/webkit/webkitgtk/include_array.patch deleted file mode 100644 index 7268b04bf..000000000 --- a/poky/meta/recipes-sato/webkit/webkitgtk/include_array.patch +++ /dev/null @@ -1,15 +0,0 @@ -Added missing include for std::array - -Upstream-Status: Submitted [https://bugs.webkit.org/show_bug.cgi?id=197085] -Signed-off-by: Khem Raj <raj.khem@gmail.com> - ---- webkitgtk-2.24.0/Source/JavaScriptCore/assembler/PerfLog.cpp.org 2019-04-18 18:03:50.226231691 -0700 -+++ webkitgtk-2.24.0/Source/JavaScriptCore/assembler/PerfLog.cpp 2019-04-18 18:07:28.569153989 -0700 -@@ -31,6 +31,7 @@ - #include <elf.h> - #include <fcntl.h> - #include <mutex> -+#include <array> - #include <sys/mman.h> - #include <sys/stat.h> - #include <sys/syscall.h> diff --git a/poky/meta/recipes-sato/webkit/webkitgtk_2.30.5.bb b/poky/meta/recipes-sato/webkit/webkitgtk_2.30.5.bb index ff4c496e2..cdc3f9b58 100644 --- a/poky/meta/recipes-sato/webkit/webkitgtk_2.30.5.bb +++ b/poky/meta/recipes-sato/webkit/webkitgtk_2.30.5.bb @@ -16,7 +16,6 @@ SRC_URI = "https://www.webkitgtk.org/releases/${BPN}-${PV}.tar.xz \ file://0001-Tweak-gtkdoc-settings-so-that-gtkdoc-generation-work.patch \ file://0001-Enable-THREADS_PREFER_PTHREAD_FLAG.patch \ file://0001-Fix-build-with-musl.patch \ - file://include_array.patch \ file://include_xutil.patch \ file://reduce-memory-overheads.patch \ file://0001-Extend-atomics-check-to-include-1-byte-CAS-test.patch \ diff --git a/poky/meta/recipes-support/diffoscope/diffoscope_168.bb b/poky/meta/recipes-support/diffoscope/diffoscope_172.bb index a7cfdf9ff..bf4726e77 100644 --- a/poky/meta/recipes-support/diffoscope/diffoscope_168.bb +++ b/poky/meta/recipes-support/diffoscope/diffoscope_172.bb @@ -12,7 +12,7 @@ PYPI_PACKAGE = "diffoscope" inherit pypi setuptools3 -SRC_URI[sha256sum] = "c6f1dc3e75b7e2e5ceac4f857fbd2ee0ddb3f0169c2b39ea9187af34208e98de" +SRC_URI[sha256sum] = "5ffe7f38555c6409bc7e7edc277ed77dd78641fe1306fc38d153dbbe445ddea4" RDEPENDS_${PN} += "binutils vim squashfs-tools python3-libarchive-c python3-magic python3-rpm" diff --git a/poky/meta/recipes-support/ptest-runner/ptest-runner_2.4.0.bb b/poky/meta/recipes-support/ptest-runner/ptest-runner_2.4.1.bb index 8b9938f57..57a3ae005 100644 --- a/poky/meta/recipes-support/ptest-runner/ptest-runner_2.4.0.bb +++ b/poky/meta/recipes-support/ptest-runner/ptest-runner_2.4.1.bb @@ -7,12 +7,11 @@ HOMEPAGE = "http://git.yoctoproject.org/cgit/cgit.cgi/ptest-runner2/about/" LICENSE = "GPLv2+" LIC_FILES_CHKSUM = "file://LICENSE;md5=751419260aa954499f7abaabaa882bbe" -SRCREV = "834670317bd3f6e427e1ac461c07ada6b8936dfd" +SRCREV = "cce0edb4282ee081d043030bfdf29f3e4052f86c" PV .= "+git${SRCPV}" SRC_URI = "git://git.yoctoproject.org/ptest-runner2 \ " -UPSTREAM_VERSION_UNKNOWN = "1" S = "${WORKDIR}/git" diff --git a/poky/scripts/runqemu b/poky/scripts/runqemu index df4ee21d5..ba0b701af 100755 --- a/poky/scripts/runqemu +++ b/poky/scripts/runqemu @@ -1196,6 +1196,15 @@ class BaseConfig(object): self.fstype = self.fstype[4:] rootfs_format = self.fstype if self.fstype in ('vmdk', 'vhd', 'vhdx', 'qcow2', 'vdi') else 'raw' + tmpfsdir = os.environ.get("RUNQEMU_TMPFS_DIR", None) + if self.snapshot and tmpfsdir: + newrootfs = os.path.join(tmpfsdir, os.path.basename(self.rootfs)) + "." + str(os.getpid()) + shutil.copyfile(self.rootfs, newrootfs) + #print("Copying rootfs to tmpfs: %s" % newrootfs) + self.rootfs = newrootfs + # Don't need a second copy now! + self.snapshot = False + qb_rootfs_opt = self.get('QB_ROOTFS_OPT') if qb_rootfs_opt: self.rootfs_options = qb_rootfs_opt.replace('@ROOTFS@', self.rootfs) @@ -1314,7 +1323,6 @@ class BaseConfig(object): if self.gtk == True: raise RunQemuError('Option nographic makes no sense alongside the gtk option.') self.qemu_opt += ' -nographic' - return if self.novga == True: self.qemu_opt += ' -vga none' |