diff options
Diffstat (limited to 'poky')
203 files changed, 4496 insertions, 1071 deletions
diff --git a/poky/bitbake/lib/toaster/toastergui/api.py b/poky/bitbake/lib/toaster/toastergui/api.py index a06ffc00dc..e367bd910e 100644 --- a/poky/bitbake/lib/toaster/toastergui/api.py +++ b/poky/bitbake/lib/toaster/toastergui/api.py @@ -227,7 +227,7 @@ class XhrSetDefaultImageUrl(View): # same logical name # * Each project that uses a layer will have its own # LayerVersion and Project Layer for it -# * During the Paroject delete process, when the last +# * During the Project delete process, when the last # LayerVersion for a 'local_source_dir' layer is deleted # then the Layer record is deleted to remove orphans # @@ -457,15 +457,18 @@ class XhrLayer(View): 'layerdetailurl': layer_dep.get_detailspage_url(project.pk)}) - # Scan the layer's content and update components - scan_layer_content(layer,layer_version) + # Only scan_layer_content if layer is local + if layer_data.get('local_source_dir', None): + # Scan the layer's content and update components + scan_layer_content(layer,layer_version) except Layer_Version.DoesNotExist: return error_response("layer-dep-not-found") except Project.DoesNotExist: return error_response("project-not-found") - except KeyError: - return error_response("incorrect-parameters") + except KeyError as e: + _log("KeyError: %s" % e) + return error_response(f"incorrect-parameters") return JsonResponse({'error': "ok", 'imported_layer': { diff --git a/poky/documentation/.gitignore b/poky/documentation/.gitignore index 494b4f4de5..b23d598054 100644 --- a/poky/documentation/.gitignore +++ b/poky/documentation/.gitignore @@ -7,3 +7,5 @@ releases.rst .vscode/ */svg/*.png */svg/*.pdf +styles/* +!styles/config diff --git a/poky/documentation/.vale.ini b/poky/documentation/.vale.ini new file mode 100644 index 0000000000..02042bb632 --- /dev/null +++ b/poky/documentation/.vale.ini @@ -0,0 +1,7 @@ +StylesPath = styles +MinAlertLevel = suggestion +Packages = RedHat, proselint, write-good, alex, Readability, Joblint +Vocab = Yocto, OpenSource +[*.rst] +BasedOnStyles = Vale, RedHat, proselint, write-good, alex, Readability, Joblint + diff --git a/poky/documentation/Makefile b/poky/documentation/Makefile index 9fb6814c8f..c930d2d280 100644 --- a/poky/documentation/Makefile +++ b/poky/documentation/Makefile @@ -5,6 +5,9 @@ # from the environment for the first two. SPHINXOPTS ?= -W --keep-going -j auto SPHINXBUILD ?= sphinx-build +# Release notes are excluded because they contain contributor names and commit messages which can't be modified +VALEOPTS ?= --no-wrap --glob '!migration-guides/release-notes-*.rst' +VALEDOCS ?= . SOURCEDIR = . IMAGEDIRS = */svg BUILDDIR = _build @@ -20,7 +23,7 @@ endif help: @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) -.PHONY: all help Makefile clean publish epub latexpdf +.PHONY: all help Makefile clean stylecheck publish epub latexpdf publish: Makefile html singlehtml rm -rf $(BUILDDIR)/$(DESTDIR)/ @@ -44,7 +47,15 @@ PNGs := $(foreach dir, $(IMAGEDIRS), $(patsubst %.svg,%.png,$(wildcard $(SOURCED $(SVG2PNG) --export-filename=$@ $< clean: - @rm -rf $(BUILDDIR) $(PNGs) $(PDFs) poky.yaml sphinx-static/switchers.js + @rm -rf $(BUILDDIR) $(PNGs) $(PDFs) poky.yaml sphinx-static/switchers.js releases.rst + +stylecheck: + vale sync + vale $(VALEOPTS) $(VALEDOCS) + +stylecheck: + vale sync + vale $(VALEOPTS) $(VALEDOCS) epub: $(PNGs) $(SOURCEDIR)/set_versions.py diff --git a/poky/documentation/README b/poky/documentation/README index 4d31036e69..8035418cac 100644 --- a/poky/documentation/README +++ b/poky/documentation/README @@ -151,6 +151,20 @@ dependencies in a virtual environment: $ pipenv install $ pipenv run make html +Style checking the Yocto Project documentation +============================================== + +The project is starting to use Vale (https://vale.sh/) +to validate the text style. + +To install Vale: + + $ pip install vale + +To run Vale: + + $ make stylecheck + Sphinx theme and CSS customization ================================== diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst index f92b1177b7..5348d084dc 100644 --- a/poky/documentation/bsp-guide/bsp.rst +++ b/poky/documentation/bsp-guide/bsp.rst @@ -851,8 +851,7 @@ Before looking at BSP requirements, you should consider the following: dictating that a specific kernel or kernel version be used in a given BSP. -Following are the requirements for a released BSP that conform to the -Yocto Project: +The requirements for a released BSP that conform to the Yocto Project are: - *Layer Name:* The BSP must have a layer name that follows the Yocto Project standards. For information on BSP layer names, see the @@ -956,7 +955,7 @@ Yocto Project: Released BSP Recommendations ---------------------------- -Following are recommendations for released BSPs that conform to the +Here are recommendations for released BSPs that conform to the Yocto Project: - *Bootable Images:* Released BSPs can contain one or more bootable @@ -1018,7 +1017,7 @@ the following: that additional hierarchy and the files would obviously not be able to reside in a machine-specific directory. -Following is a specific example to help you better understand the +Here is a specific example to help you better understand the 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 @@ -1448,7 +1447,7 @@ metadata used to build the kernel. In this case, a kernel append file kernel recipe (i.e. ``linux-yocto_6.1.bb``), which is located in :yocto_git:`/poky/tree/meta/recipes-kernel/linux`. -Following is the contents of the append file:: +The contents of the append file are:: KBRANCH:genericx86 = "v6.1/standard/base" KBRANCH:genericx86-64 = "v6.1/standard/base" diff --git a/poky/documentation/contributor-guide/submit-changes.rst b/poky/documentation/contributor-guide/submit-changes.rst index 5a6136c8c8..dfeb0305c3 100644 --- a/poky/documentation/contributor-guide/submit-changes.rst +++ b/poky/documentation/contributor-guide/submit-changes.rst @@ -57,7 +57,7 @@ Set up Git The first thing to do is to install Git packages. Here is an example on Debian and Ubuntu:: - sudo aptitude install git-core git-email + sudo apt install git-core git-email Then, you need to set a name and e-mail address that Git will use to identify your commits:: @@ -221,6 +221,38 @@ to add the upgraded version. <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`__ in the Linux kernel documentation. +Test your changes +----------------- + +For each contributions you make, you should test your changes as well. +For this the Yocto Project offers several types of tests. Those tests cover +different areas and it depends on your changes which are feasible. For example run: + + - For changes that affect the build environment: + + - ``bitbake-selftest``: for changes within BitBake + + - ``oe-selftest``: to test combinations of BitBake runs + + - ``oe-build-perf-test``: to test the performance of common build scenarios + + - For changes in a recipe: + + - ``ptest``: run package specific tests, if they exist + + - ``testimage``: build an image, boot it and run testcases on it + + - If applicable, ensure also the ``native`` and ``nativesdk`` variants builds + + - For changes relating to the SDK: + + - ``testsdk``: to build, install and run tests against a SDK + + - ``testsdk_ext``: to build, install and run tests against an extended SDK + +Note that this list just gives suggestions and is not exhaustive. More details can +be found here: :ref:`test-manual/intro:Yocto Project Tests --- Types of Testing Overview`. + Creating Patches ================ @@ -285,8 +317,9 @@ Validating Patches with Patchtest ``patchtest`` is available in ``openembedded-core`` as a tool for making sure that your patches are well-formatted and contain important info for maintenance purposes, such as ``Signed-off-by`` and ``Upstream-Status`` -tags. Currently, it only supports testing patches for -``openembedded-core`` branches. To setup, perform the following:: +tags. Note that no functional testing of the changes will be performed by ``patchtest``. +Currently, it only supports testing patches for ``openembedded-core`` branches. +To setup, perform the following:: pip install -r meta/lib/patchtest/requirements.txt source oe-init-build-env @@ -399,7 +432,7 @@ varies by component: :oe_lists:`bitbake-devel </g/bitbake-devel>` mailing list. -- *"meta-\*" trees:* These trees contain Metadata. Use the +- *meta-poky* and *meta-yocto-bsp* trees: These trees contain Metadata. Use the :yocto_lists:`poky </g/poky>` mailing list. - *Documentation*: For changes to the Yocto Project documentation, use the @@ -438,7 +471,7 @@ their e-mail clients will default to including your email address in the conversation anyway. Anyway, you'll also be able to access the new messages on mailing list archives, -either through a web browser, or for the lists archived on https://lore.kernelorg, +either through a web browser, or for the lists archived on https://lore.kernel.org, through an individual newsgroup feed or a git repository. Sending Patches via Email diff --git a/poky/documentation/dev-manual/building.rst b/poky/documentation/dev-manual/building.rst index a395793493..fe502690dd 100644 --- a/poky/documentation/dev-manual/building.rst +++ b/poky/documentation/dev-manual/building.rst @@ -32,6 +32,10 @@ build host running Linux. OpenEmbedded build system, see the :doc:`/brief-yoctoprojectqs/index` document. + - You can also use the `Yocto Project BitBake + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__ + extension for Visual Studio Code to build images. + The build process creates an entire Linux distribution from source and places it in your :term:`Build Directory` under ``tmp/deploy/images``. For detailed information on the build process using BitBake, see the @@ -156,7 +160,7 @@ Follow these steps to set up and execute multiple configuration builds: The location for these multiconfig configuration files is specific. They must reside in the current :term:`Build Directory` in a sub-directory of ``conf`` named ``multiconfig`` or within a layer's ``conf`` directory - under a directory named ``multiconfig``. Following is an example that defines + under a directory named ``multiconfig``. Here is an example that defines two configuration files for the "x86" and "arm" multiconfigs: .. image:: figures/multiconfig_files.png @@ -771,10 +775,9 @@ your tunings to best consider build times and package feed maintenance. in the script for information on how to use the tool. - *BitBake's "-S printdiff" Option:* Using this option causes - BitBake to try to establish the closest signature match it can - (e.g. in the shared state cache) and then run ``bitbake-diffsigs`` - over the matches to determine the stamps and delta where these two - stamp trees diverge. + BitBake to try to establish the most recent signature match + (e.g. in the shared state cache) and then compare matched signatures + to determine the stamps and delta where these two stamp trees diverge. Building Software from an External Source ========================================= diff --git a/poky/documentation/dev-manual/debugging.rst b/poky/documentation/dev-manual/debugging.rst index bd1e716b0b..74f5772554 100644 --- a/poky/documentation/dev-manual/debugging.rst +++ b/poky/documentation/dev-manual/debugging.rst @@ -170,7 +170,7 @@ You can use the ``oe-pkgdata-util`` command-line utility to query various package-related information. When you use the utility, you must use it to view information on packages that have already been built. -Following are a few of the available ``oe-pkgdata-util`` subcommands. +Here are a few of the available ``oe-pkgdata-util`` subcommands. .. note:: @@ -339,7 +339,10 @@ BitBake has determined by doing the following: :term:`BB_BASEHASH_IGNORE_VARS` information. -There is also a ``bitbake-diffsigs`` command for comparing two +Debugging signature construction and unexpected task executions +=============================================================== + +There is a ``bitbake-diffsigs`` command for comparing two ``siginfo`` or ``sigdata`` files. This command can be helpful when trying to figure out what changed between two versions of a task. If you call ``bitbake-diffsigs`` with just one file, the command behaves like @@ -356,8 +359,12 @@ BitBake command-line options:: .. note:: Two common values for `SIGNATURE_HANDLER` are "none" and "printdiff", which - dump only the signature or compare the dumped signature with the cached one, - respectively. + dump only the signature or compare the dumped signature with the most recent one, + respectively. "printdiff" will try to establish the most recent + signature match (e.g. in the sstate cache) and then + compare the matched signatures to determine the stamps and delta + where these two stamp trees diverge. This can be used to determine why + tasks need to be re-run in situations where that is not expected. Using BitBake with either of these options causes BitBake to dump out ``sigdata`` files in the ``stamps`` directory for every task it would @@ -608,7 +615,7 @@ logs, keep in mind the goal is to have informative logs while keeping the console as "silent" as possible. Also, if you want status messages in the log, use the "debug" loglevel. -Following is an example written in Python. The code handles logging for +Here is an example written in Python. The code handles logging for a function that determines the number of tasks needed to be run. See the ":ref:`ref-tasks-listtasks`" section for additional information:: @@ -636,7 +643,7 @@ logs, you have the same goals --- informative with minimal console output. The syntax you use for recipes written in Bash is similar to that of recipes written in Python described in the previous section. -Following is an example written in Bash. The code logs the progress of +Here is an example written in Bash. The code logs the progress of the ``do_my_function`` function:: do_my_function() { @@ -1221,7 +1228,7 @@ Here are some other tips that you might find useful: "$@" } - Following are some usage examples:: + Here are some usage examples:: $ g FOO # Search recursively for "FOO" $ g -i foo # Search recursively for "foo", ignoring case diff --git a/poky/documentation/dev-manual/development-shell.rst b/poky/documentation/dev-manual/development-shell.rst index a18d792150..be26bcffc7 100644 --- a/poky/documentation/dev-manual/development-shell.rst +++ b/poky/documentation/dev-manual/development-shell.rst @@ -16,7 +16,7 @@ OpenEmbedded build system were executing them. Consequently, working this way can be helpful when debugging a build or preparing software to be used with the OpenEmbedded build system. -Following is an example that uses ``devshell`` on a target named +Here is an example that uses ``devshell`` on a target named ``matchbox-desktop``:: $ bitbake matchbox-desktop -c devshell diff --git a/poky/documentation/dev-manual/device-manager.rst b/poky/documentation/dev-manual/device-manager.rst index 0343d19b9c..49fc785fec 100644 --- a/poky/documentation/dev-manual/device-manager.rst +++ b/poky/documentation/dev-manual/device-manager.rst @@ -60,10 +60,10 @@ kernel. All devices created by ``devtmpfs`` will be owned by ``root`` and have permissions ``0600``. -To have more control over the device nodes, you can use a device manager -like ``udev`` or ``busybox-mdev``. You choose the device manager by -defining the ``VIRTUAL-RUNTIME_dev_manager`` variable in your machine or -distro configuration file. Alternatively, you can set this variable in +To have more control over the device nodes, you can use a device manager like +``udev`` or ``busybox-mdev``. You choose the device manager by defining the +:term:`VIRTUAL-RUNTIME_dev_manager <VIRTUAL-RUNTIME>` variable in your machine +or distro configuration file. Alternatively, you can set this variable in your ``local.conf`` configuration file:: VIRTUAL-RUNTIME_dev_manager = "udev" diff --git a/poky/documentation/dev-manual/layers.rst b/poky/documentation/dev-manual/layers.rst index b3ccf633df..f7929e630e 100644 --- a/poky/documentation/dev-manual/layers.rst +++ b/poky/documentation/dev-manual/layers.rst @@ -82,7 +82,7 @@ Follow these general steps to create your layer without using tools: LAYERVERSION_yoctobsp = "4" LAYERSERIES_COMPAT_yoctobsp = "dunfell" - Following is an explanation of the layer configuration file: + Here is an explanation of the layer configuration file: - :term:`BBPATH`: Adds the layer's root directory to BitBake's search path. Through the use of the @@ -191,7 +191,7 @@ following list: - *Structure Your Layers:* Proper use of overrides within append files and placement of machine-specific files within your layer can ensure that a build is not using the wrong Metadata and negatively impacting - a build for a different machine. Following are some examples: + a build for a different machine. Here are some examples: - *Modify Variables to Support a Different Machine:* Suppose you have a layer named ``meta-one`` that adds support for building @@ -513,7 +513,7 @@ In the main recipe, note the :term:`SRC_URI` variable, which tells the OpenEmbedded build system where to find files during the build. -Following is the append file, which is named ``formfactor_0.0.bbappend`` +Here is the append file, which is named ``formfactor_0.0.bbappend`` and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The file is in the layer at ``recipes-bsp/formfactor``:: @@ -588,7 +588,7 @@ Directory`. Here is the main ``xserver-xf86-config`` recipe, which is named fi } -Following is the append file, which is named ``xserver-xf86-config_%.bbappend`` +Here is the append file, which is named ``xserver-xf86-config_%.bbappend`` and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The file is in the layer at ``recipes-graphics/xorg-xserver``:: diff --git a/poky/documentation/dev-manual/libraries.rst b/poky/documentation/dev-manual/libraries.rst index ae4ca27209..521dbb9a7c 100644 --- a/poky/documentation/dev-manual/libraries.rst +++ b/poky/documentation/dev-manual/libraries.rst @@ -37,7 +37,7 @@ library files. Some previously released versions of the Yocto Project defined the static library files through ``${PN}-dev``. -Following is part of the BitBake configuration file, where you can see +Here is the part of the BitBake configuration file, where you can see how the static library files are defined:: PACKAGE_BEFORE_PN ?= "" @@ -177,7 +177,7 @@ Additional Implementation Details --------------------------------- There are generic implementation details as well as details that are specific to -package management systems. Following are implementation details +package management systems. Here are implementation details that exist regardless of the package management system: - The typical convention used for the class extension code as used by diff --git a/poky/documentation/dev-manual/licenses.rst b/poky/documentation/dev-manual/licenses.rst index 3b9190d47f..bffff3675f 100644 --- a/poky/documentation/dev-manual/licenses.rst +++ b/poky/documentation/dev-manual/licenses.rst @@ -27,7 +27,7 @@ Specifying the ``LIC_FILES_CHKSUM`` Variable -------------------------------------------- The :term:`LIC_FILES_CHKSUM` variable contains checksums of the license text -in the source code for the recipe. Following is an example of how to +in the source code for the recipe. Here is an example of how to specify :term:`LIC_FILES_CHKSUM`:: LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \ @@ -332,7 +332,7 @@ completeness. The Yocto Project generates a license manifest during image creation that is located in - ``${DEPLOY_DIR}/licenses/<image-name>-<machine>.rootfs-<datestamp>/`` + ``${DEPLOY_DIR}/licenses/${SSTATE_PKGARCH}/<image-name>-<machine>.rootfs-<datestamp>/`` to assist with any audits. Providing the Source Code diff --git a/poky/documentation/dev-manual/new-machine.rst b/poky/documentation/dev-manual/new-machine.rst index 6b41d24db4..469b2d395a 100644 --- a/poky/documentation/dev-manual/new-machine.rst +++ b/poky/documentation/dev-manual/new-machine.rst @@ -104,7 +104,7 @@ contains directories for specific machines such as ``qemuarm`` and defaults, see the ``meta/recipes-bsp/formfactor/files/config`` file found in the same area. -Following is an example for "qemuarm" machine:: +Here is an example for "qemuarm" machine:: HAVE_TOUCHSCREEN=1 HAVE_KEYBOARD=1 diff --git a/poky/documentation/dev-manual/new-recipe.rst b/poky/documentation/dev-manual/new-recipe.rst index 2c1033eb35..61fc2eb122 100644 --- a/poky/documentation/dev-manual/new-recipe.rst +++ b/poky/documentation/dev-manual/new-recipe.rst @@ -100,7 +100,7 @@ command:: Running ``recipetool create -o OUTFILE`` creates the base recipe and locates it properly in the layer that contains your source files. -Following are some syntax examples: +Here are some syntax examples: - Use this syntax to generate a recipe based on source. Once generated, the recipe resides in the existing source code layer:: @@ -1232,7 +1232,7 @@ inherit the :ref:`ref-classes-autotools` class, which contains the definitions of all the steps needed to build an Autotool-based application. The result of the build is automatically packaged. And, if the application uses NLS for localization, packages with local information are generated (one package per -language). Following is one example: (``hello_2.3.bb``):: +language). Here is one example: (``hello_2.3.bb``):: SUMMARY = "GNU Helloworld application" SECTION = "examples" @@ -1285,7 +1285,7 @@ Splitting an Application into Multiple Packages You can use the variables :term:`PACKAGES` and :term:`FILES` to split an application into multiple packages. -Following is an example that uses the ``libxpm`` recipe. By default, +Here is an example that uses the ``libxpm`` recipe. By default, this recipe generates a single package that contains the library along with a few binaries. You can modify the recipe to split the binaries into separate packages:: @@ -1510,7 +1510,7 @@ in the BitBake User Manual. when you make the assignment, but this is not generally needed. - *Quote All Assignments ("value"):* Use double quotes around values in - all variable assignments (e.g. ``"value"``). Following is an example:: + all variable assignments (e.g. ``"value"``). Here is an example:: VAR1 = "${OTHERVAR}" VAR2 = "The version is ${PV}" diff --git a/poky/documentation/dev-manual/packages.rst b/poky/documentation/dev-manual/packages.rst index 79f21d9f34..e5028fffdc 100644 --- a/poky/documentation/dev-manual/packages.rst +++ b/poky/documentation/dev-manual/packages.rst @@ -205,9 +205,14 @@ history, see the The OpenEmbedded build system does not maintain :term:`PR` information as part of the shared state (sstate) packages. If you maintain an sstate 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. + contribute to the sstate feed use a shared PR service, or you do not + run a PR service on any of your building systems. + + That's because if you had multiple machines sharing a PR service but + not their sstate feed, you could end up with "diverging" hashes for + the same output artefacts. When presented to the share PR service, + each would be considered as new and would increase the revision + number, causing many unnecessary package upgrades. For more information on shared state, see the ":ref:`overview-manual/concepts:shared state cache`" @@ -365,7 +370,7 @@ For more examples that show how to use ``do_split_packages``, see the directory of the ``poky`` :ref:`source repository <overview-manual/development-environment:yocto project source repositories>`. You can also find examples in ``meta/classes-recipe/kernel.bbclass``. -Following is a reference that shows ``do_split_packages`` mandatory and +Here is a reference that shows ``do_split_packages`` mandatory and optional arguments:: Mandatory arguments @@ -607,6 +612,13 @@ subsequent sections are necessary to configure the target. You should set these variables before building the image in order to produce a correctly configured image. +.. note:: + + Your image will need enough free storage space to run package upgrades, + especially if many of them need to be downloaded at the same time. + You should make sure images are created with enough free space + by setting the :term:`IMAGE_ROOTFS_EXTRA_SPACE` variable. + When your build is complete, your packages reside in the ``${TMPDIR}/deploy/packageformat`` directory. For example, if ``${``\ :term:`TMPDIR`\ ``}`` is @@ -1123,7 +1135,7 @@ The ``devtool edit-recipe`` command lets you take a look at the recipe:: ... LICENSE:${PN}-vary = "MIT" -Here are three key points in the previous example: +Three key points in the previous example are: - :term:`SRC_URI` uses the NPM scheme so that the NPM fetcher is used. diff --git a/poky/documentation/dev-manual/prebuilt-libraries.rst b/poky/documentation/dev-manual/prebuilt-libraries.rst index b80a844e93..a05f39ca1e 100644 --- a/poky/documentation/dev-manual/prebuilt-libraries.rst +++ b/poky/documentation/dev-manual/prebuilt-libraries.rst @@ -148,8 +148,8 @@ recipe. By default, ``libfoo.so`` gets packaged into ``${PN}-dev``, which triggers a QA warning that a non-symlink library is in a ``-dev`` package, and binaries in the same recipe link to the library in ``${PN}-dev``, which triggers more QA warnings. To solve this problem, you need to package the -unversioned library into ``${PN}`` where it belongs. The following are the abridged -default :term:`FILES` variables in ``bitbake.conf``:: +unversioned library into ``${PN}`` where it belongs. The abridged +default :term:`FILES` variables in ``bitbake.conf`` are:: SOLIBS = ".so.*" SOLIBSDEV = ".so" diff --git a/poky/documentation/dev-manual/python-development-shell.rst b/poky/documentation/dev-manual/python-development-shell.rst index 2dc6a3f138..81a5c43472 100644 --- a/poky/documentation/dev-manual/python-development-shell.rst +++ b/poky/documentation/dev-manual/python-development-shell.rst @@ -35,7 +35,7 @@ system were executing them. Consequently, working this way can be helpful when debugging a build or preparing software to be used with the OpenEmbedded build system. -Following is an example that uses ``pydevshell`` on a target named +Here is an example that uses ``pydevshell`` on a target named ``matchbox-desktop``:: $ bitbake matchbox-desktop -c pydevshell diff --git a/poky/documentation/dev-manual/qemu.rst b/poky/documentation/dev-manual/qemu.rst index d431ea4b99..19f3e40d63 100644 --- a/poky/documentation/dev-manual/qemu.rst +++ b/poky/documentation/dev-manual/qemu.rst @@ -311,7 +311,7 @@ timestamp when it needs to look for an image. Minimally, through the use of options, you must provide either a machine name, a virtual machine image (``*wic.vmdk``), or a kernel image (``*.bin``). -Following is the command-line help output for the ``runqemu`` command:: +Here is the command-line help output for the ``runqemu`` command:: $ runqemu --help @@ -353,7 +353,7 @@ Following is the command-line help output for the ``runqemu`` command:: ``runqemu`` Command-Line Options ================================ -Following is a description of ``runqemu`` options you can provide on the +Here is a description of ``runqemu`` options you can provide on the command line: .. note:: diff --git a/poky/documentation/dev-manual/runtime-testing.rst b/poky/documentation/dev-manual/runtime-testing.rst index be1e8c02e5..7a2b42f25a 100644 --- a/poky/documentation/dev-manual/runtime-testing.rst +++ b/poky/documentation/dev-manual/runtime-testing.rst @@ -52,6 +52,8 @@ In order to run tests, you need to do the following: - Be sure to use an absolute path when calling this script with sudo. + - Ensure that your host has the package ``iptables`` installed. + - The package recipe ``qemu-helper-native`` is required to run this script. Build the package using the following command:: @@ -191,7 +193,7 @@ perform a one-time setup of your controller image by doing the following: "controller" image and you can customize the image recipe as you would any other recipe. - Here are the image recipe requirements: + Image recipe requirements are: - Inherits ``core-image`` so that kernel modules are installed. @@ -570,7 +572,7 @@ data: When set to "true", the package is not automatically installed into the DUT. -Following is an example JSON file that handles test "foo" installing +Here is an example JSON file that handles test "foo" installing package "bar" and test "foobar" installing packages "foo" and "bar". Once the test is complete, the packages are removed from the DUT:: diff --git a/poky/documentation/dev-manual/sbom.rst b/poky/documentation/dev-manual/sbom.rst index f51d08f84d..b72bad1554 100644 --- a/poky/documentation/dev-manual/sbom.rst +++ b/poky/documentation/dev-manual/sbom.rst @@ -30,22 +30,29 @@ To make this happen, you must inherit the INHERIT += "create-spdx" -You then get :term:`SPDX` output in JSON format as an -``IMAGE-MACHINE.spdx.json`` file in ``tmp/deploy/images/MACHINE/`` inside the -:term:`Build Directory`. +Upon building an image, you will then get: -This is a toplevel file accompanied by an ``IMAGE-MACHINE.spdx.index.json`` -containing an index of JSON :term:`SPDX` files for individual recipes, together -with an ``IMAGE-MACHINE.spdx.tar.zst`` compressed archive containing all such -files. +- :term:`SPDX` output in JSON format as an ``IMAGE-MACHINE.spdx.json`` file in + ``tmp/deploy/images/MACHINE/`` inside the :term:`Build Directory`. + +- This toplevel file is accompanied by an ``IMAGE-MACHINE.spdx.index.json`` + containing an index of JSON :term:`SPDX` files for individual recipes. + +- The compressed archive ``IMAGE-MACHINE.spdx.tar.zst`` contains the index + and the files for the single recipes. The :ref:`ref-classes-create-spdx` class offers options to include -more information in the output :term:`SPDX` data, such as making the generated -files more human readable (:term:`SPDX_PRETTY`), adding compressed archives of -the files in the generated target packages (:term:`SPDX_ARCHIVE_PACKAGED`), -adding a description of the source files used to generate host tools and target -packages (:term:`SPDX_INCLUDE_SOURCES`) and adding archives of these source -files themselves (:term:`SPDX_ARCHIVE_SOURCES`). +more information in the output :term:`SPDX` data: + +- Make the json files more human readable by setting (:term:`SPDX_PRETTY`). + +- Add compressed archives of the files in the generated target packages by + setting (:term:`SPDX_ARCHIVE_PACKAGED`). + +- Add a description of the source files used to generate host tools and target + packages (:term:`SPDX_INCLUDE_SOURCES`) + +- Add archives of these source files themselves (:term:`SPDX_ARCHIVE_SOURCES`). Though the toplevel :term:`SPDX` output is available in ``tmp/deploy/images/MACHINE/`` inside the :term:`Build Directory`, ancillary @@ -65,11 +72,12 @@ generated files are available in ``tmp/deploy/spdx/MACHINE`` too, such as: See also the :term:`SPDX_CUSTOM_ANNOTATION_VARS` variable which allows to associate custom notes to a recipe. - See the `tools page <https://spdx.dev/resources/tools/>`__ on the :term:`SPDX` project website for a list of tools to consume and transform the :term:`SPDX` data generated by the OpenEmbedded build system. -See also Joshua Watt's +See also Joshua Watt's presentations `Automated SBoM generation with OpenEmbedded and the Yocto Project <https://youtu.be/Q5UQUM6zxVU>`__ -presentation at FOSDEM 2023. +at FOSDEM 2023 and +`SPDX in the Yocto Project <https://fosdem.org/2024/schedule/event/fosdem-2024-3318-spdx-in-the-yocto-project/>`__ +at FOSDEM 2024. diff --git a/poky/documentation/dev-manual/speeding-up-build.rst b/poky/documentation/dev-manual/speeding-up-build.rst index 31b6f75ab0..6e0d7873ac 100644 --- a/poky/documentation/dev-manual/speeding-up-build.rst +++ b/poky/documentation/dev-manual/speeding-up-build.rst @@ -33,7 +33,7 @@ auto-scaling ensures that the build system fundamentally takes advantage of potential parallel operations during the build based on the build machine's capabilities. -Following are additional factors that can affect build speed: +Additional factors that can affect build speed are: - File system type: The file system type that the build is being performed on can also influence performance. Using ``ext4`` is @@ -88,7 +88,7 @@ that can help you speed up the build: variable to "1". - Disable static library generation for recipes derived from - ``autoconf`` or ``libtool``: Following is an example showing how to + ``autoconf`` or ``libtool``: Here is an example showing how to disable static libraries and still provide an override to handle exceptions:: diff --git a/poky/documentation/dev-manual/start.rst b/poky/documentation/dev-manual/start.rst index 4a556967eb..8539bc0889 100644 --- a/poky/documentation/dev-manual/start.rst +++ b/poky/documentation/dev-manual/start.rst @@ -36,7 +36,7 @@ particular working environment and set of practices. equipment together and set up your development environment's hardware topology. - Here are possible roles: + Possible roles are: - *Application Developer:* This type of developer does application level work on top of an existing software stack. @@ -99,7 +99,7 @@ particular working environment and set of practices. #. *Set up the Application Development Machines:* As mentioned earlier, application developers are creating applications on top of existing - software stacks. Following are some best practices for setting up + software stacks. Here are some best practices for setting up machines used for application development: - Use a pre-built toolchain that contains the software stack @@ -118,7 +118,7 @@ particular working environment and set of practices. #. *Set up the Core Development Machines:* As mentioned earlier, core developers work on the contents of the operating system itself. - Following are some best practices for setting up machines used for + Here are some best practices for setting up machines used for developing images: - Have the :term:`OpenEmbedded Build System` available on @@ -334,7 +334,10 @@ to use the Extensible SDK, see the ":doc:`/sdk-manual/extensible`" Chapter in th Project Application Development and the Extensible Software Development Kit (eSDK) manual. If you want to work on the kernel, see the :doc:`/kernel-dev/index`. If you are going to use Toaster, see the ":doc:`/toaster-manual/setup-and-use`" -section in the Toaster User Manual. +section in the Toaster User Manual. If you are a VSCode user, you can configure +the `Yocto Project BitBake +<https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__ +extension accordingly. Setting Up to Use CROss PlatformS (CROPS) ----------------------------------------- @@ -426,7 +429,10 @@ section. If you are going to use the Extensible SDK container, see the Project Application Development and the Extensible Software Development Kit (eSDK) manual. If you are going to use the Toaster container, see the ":doc:`/toaster-manual/setup-and-use`" -section in the Toaster User Manual. +section in the Toaster User Manual. If you are a VSCode user, you can configure +the `Yocto Project BitBake +<https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__ +extension accordingly. Setting Up to Use Windows Subsystem For Linux (WSL 2) ----------------------------------------------------- @@ -554,7 +560,10 @@ Extensible SDK container, see the ":doc:`/sdk-manual/extensible`" Chapter in the Project Application Development and the Extensible Software Development Kit (eSDK) manual. If you are going to use the Toaster container, see the ":doc:`/toaster-manual/setup-and-use`" -section in the Toaster User Manual. +section in the Toaster User Manual. If you are a VSCode user, you can configure +the `Yocto Project BitBake +<https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__ +extension accordingly. Locating Yocto Project Source Files =================================== @@ -621,7 +630,7 @@ a selection of these components. Using the Downloads Page ------------------------ -The :yocto_home:`Yocto Project Website <>` uses a "DOWNLOADS" page +The :yocto_home:`Yocto Project Website <>` uses a "RELEASES" page from which you can locate and download tarballs of any Yocto Project release. Rather than Git repositories, these files represent snapshot tarballs similar to the tarballs located in the Index of Releases @@ -630,12 +639,13 @@ described in the ":ref:`dev-manual/start:accessing source archives`" section. #. *Go to the Yocto Project Website:* Open The :yocto_home:`Yocto Project Website <>` in your browser. -#. *Get to the Downloads Area:* Select the "DOWNLOADS" item from the - pull-down "SOFTWARE" tab menu near the top of the page. +#. *Get to the Downloads Area:* Select the "RELEASES" item from the + pull-down "DEVELOPMENT" tab menu near the top of the page. -#. *Select a Yocto Project Release:* Use the menu next to "RELEASE" to - display and choose a recent or past supported Yocto Project release - (e.g. &DISTRO_NAME_NO_CAP;, &DISTRO_NAME_NO_CAP_MINUS_ONE;, and so forth). +#. *Select a Yocto Project Release:* On the top of the "RELEASE" page currently + supported releases are displayed, further down past supported Yocto Project + releases are visible. The "Download" links in the rows of the table there + will lead to the download tarballs for the release. .. note:: @@ -645,9 +655,9 @@ described in the ":ref:`dev-manual/start:accessing source archives`" section. You can use the "RELEASE ARCHIVE" link to reveal a menu of all Yocto Project releases. -#. *Download Tools or Board Support Packages (BSPs):* From the - "DOWNLOADS" page, you can download tools or BSPs as well. Just scroll - down the page and look for what you need. +#. *Download Tools or Board Support Packages (BSPs):* Next to the tarballs you + will find download tools or BSPs as well. Just select a Yocto Project + release and look for what you need. Cloning and Checking Out Branches ================================= diff --git a/poky/documentation/kernel-dev/common.rst b/poky/documentation/kernel-dev/common.rst index 9b197bfccb..0cee503346 100644 --- a/poky/documentation/kernel-dev/common.rst +++ b/poky/documentation/kernel-dev/common.rst @@ -1295,7 +1295,7 @@ In order to run this task, you must have an existing ``.config`` file. See the ":ref:`kernel-dev/common:using \`\`menuconfig\`\``" section for information on how to create a configuration file. -Following is sample output from the :ref:`ref-tasks-kernel_configcheck` task: +Here is sample output from the :ref:`ref-tasks-kernel_configcheck` task: .. code-block:: none @@ -1726,7 +1726,7 @@ tree. Using Git is an efficient way to see what has changed in the tree. What Changed in a Kernel? ------------------------- -Following are a few examples that show how to use Git commands to +Here are a few examples that show how to use Git commands to examine changes. These examples are by no means the only way to see changes. diff --git a/poky/documentation/migration-guides/migration-1.5.rst b/poky/documentation/migration-guides/migration-1.5.rst index d82d33f91f..c8f3cbc165 100644 --- a/poky/documentation/migration-guides/migration-1.5.rst +++ b/poky/documentation/migration-guides/migration-1.5.rst @@ -256,7 +256,7 @@ section in the Yocto Project Development Tasks Manual. Build History ------------- -Following are changes to Build History: +The changes to Build History are: - Installed package sizes: ``installed-package-sizes.txt`` for an image now records the size of the files installed by each package instead @@ -279,7 +279,7 @@ section in the Yocto Project Development Tasks Manual. ``udev`` -------- -Following are changes to ``udev``: +The changes to ``udev`` are: - ``udev`` no longer brings in ``udev-extraconf`` automatically through :term:`RRECOMMENDS`, since this was originally @@ -323,7 +323,7 @@ Removed and Renamed Recipes Other Changes ------------- -Following is a list of short entries describing other changes: +Here is a list of short entries describing other changes: - ``run-postinsts``: Make this generic. diff --git a/poky/documentation/migration-guides/migration-2.2.rst b/poky/documentation/migration-guides/migration-2.2.rst index 3932792c78..9d50dc6202 100644 --- a/poky/documentation/migration-guides/migration-2.2.rst +++ b/poky/documentation/migration-guides/migration-2.2.rst @@ -73,8 +73,8 @@ Metadata Must Now Use Python 3 Syntax The metadata is now required to use Python 3 syntax. For help preparing metadata, see any of the many Python 3 porting guides available. Alternatively, you can reference the conversion commits for BitBake and -you can use :term:`OpenEmbedded-Core (OE-Core)` as a guide for changes. Following are -particular areas of interest: +you can use :term:`OpenEmbedded-Core (OE-Core)` as a guide for changes. +Particular areas of interest are: - subprocess command-line pipes needing locale decoding @@ -182,7 +182,7 @@ root filesystem, provides an image, and uses the ``nographic`` option:: $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4 tmp/deploy/images/qemux86-64/bzImage nographic -Following is a list of variables that can be set in configuration files +Here is a list of variables that can be set in configuration files such as ``bsp.conf`` to enable the BSP to be booted by ``runqemu``:: QB_SYSTEM_NAME: QEMU name (e.g. "qemu-system-i386") diff --git a/poky/documentation/migration-guides/migration-2.4.rst b/poky/documentation/migration-guides/migration-2.4.rst index abad43acc3..5d5d601988 100644 --- a/poky/documentation/migration-guides/migration-2.4.rst +++ b/poky/documentation/migration-guides/migration-2.4.rst @@ -91,8 +91,6 @@ occurred: Removed Recipes --------------- -The following recipes have been removed: - - ``acpitests``: This recipe is not maintained. - ``autogen-native``: No longer required by Grub, oe-core, or @@ -213,8 +211,6 @@ recipes you might have. This will avoid breakage in post 2.4 releases. Package QA Changes ------------------ -The following package QA changes took place: - - The "unsafe-references-in-scripts" QA check has been removed. - If you refer to ``${COREBASE}/LICENSE`` within @@ -229,8 +225,6 @@ The following package QA changes took place: ``README`` File Changes ----------------------- -The following are changes to ``README`` files: - - The main Poky ``README`` file has been moved to the ``meta-poky`` layer and has been renamed ``README.poky``. A symlink has been created so that references to the old location work. @@ -246,8 +240,6 @@ The following are changes to ``README`` files: Miscellaneous Changes --------------------- -The following are additional changes: - - The ``ROOTFS_PKGMANAGE_BOOTSTRAP`` variable and any references to it have been removed. You should remove this variable from any custom recipes. diff --git a/poky/documentation/migration-guides/migration-2.5.rst b/poky/documentation/migration-guides/migration-2.5.rst index 9f089bb93b..facf5110b7 100644 --- a/poky/documentation/migration-guides/migration-2.5.rst +++ b/poky/documentation/migration-guides/migration-2.5.rst @@ -87,8 +87,6 @@ The following recipes have been removed: Scripts and Tools Changes ------------------------- -The following are changes to scripts and tools: - - ``yocto-bsp``, ``yocto-kernel``, and ``yocto-layer``: The ``yocto-bsp``, ``yocto-kernel``, and ``yocto-layer`` scripts previously shipped with poky but not in OpenEmbedded-Core have been @@ -119,8 +117,6 @@ The following are changes to scripts and tools: BitBake Changes --------------- -The following are BitBake changes: - - The ``--runall`` option has changed. There are two different behaviors people might want: @@ -153,7 +149,7 @@ The following are BitBake changes: Python and Python 3 Changes --------------------------- -The following are auto-packaging changes to Python and Python 3: +Here are auto-packaging changes to Python and Python 3: The script-managed ``python-*-manifest.inc`` files that were previously used to generate Python and Python 3 packages have been replaced with a @@ -187,8 +183,6 @@ change please see :yocto_git:`this commit Miscellaneous Changes --------------------- -The following are additional changes: - - The :ref:`ref-classes-kernel` class supports building packages for multiple kernels. If your kernel recipe or ``.bbappend`` file mentions packaging at all, you should replace references to the kernel in package names diff --git a/poky/documentation/migration-guides/migration-4.0.rst b/poky/documentation/migration-guides/migration-4.0.rst index 2aa9145ef8..b5bd57c312 100644 --- a/poky/documentation/migration-guides/migration-4.0.rst +++ b/poky/documentation/migration-guides/migration-4.0.rst @@ -142,7 +142,7 @@ Python changes classes should be updated to inherit ``setuptools*`` equivalents instead. - The Python package build process is now based on `wheels <https://pythonwheels.com/>`__. - Here are the new Python packaging classes that should be used: + The new Python packaging classes that should be used are :ref:`ref-classes-python_flit_core`, :ref:`ref-classes-python_setuptools_build_meta` and :ref:`ref-classes-python_poetry_core`. diff --git a/poky/documentation/migration-guides/release-4.0.rst b/poky/documentation/migration-guides/release-4.0.rst index 09fb8ca049..685799e268 100644 --- a/poky/documentation/migration-guides/release-4.0.rst +++ b/poky/documentation/migration-guides/release-4.0.rst @@ -22,3 +22,5 @@ Release 4.0 (kirkstone) release-notes-4.0.13 release-notes-4.0.14 release-notes-4.0.15 + release-notes-4.0.16 + release-notes-4.0.17 diff --git a/poky/documentation/migration-guides/release-4.3.rst b/poky/documentation/migration-guides/release-4.3.rst index 5b651a2efd..fa5653c467 100644 --- a/poky/documentation/migration-guides/release-4.3.rst +++ b/poky/documentation/migration-guides/release-4.3.rst @@ -8,3 +8,5 @@ Release 4.3 (nanbield) migration-4.3 release-notes-4.3 release-notes-4.3.1 + release-notes-4.3.2 + release-notes-4.3.3 diff --git a/poky/documentation/migration-guides/release-notes-4.0.16.rst b/poky/documentation/migration-guides/release-notes-4.0.16.rst new file mode 100644 index 0000000000..0eb31832ab --- /dev/null +++ b/poky/documentation/migration-guides/release-notes-4.0.16.rst @@ -0,0 +1,191 @@ +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK + +Release notes for Yocto-4.0.16 (Kirkstone) +------------------------------------------ + +Security Fixes in Yocto-4.0.16 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- cpio: Fix :cve_mitre:`2023-7207` +- curl: Revert "curl: Backport fix CVE-2023-32001" +- curl: Fix :cve:`2023-46218` +- dropbear:Fix :cve:`2023-48795` +- ffmpeg: Fix :cve:`2022-3964` and :cve:`2022-3965` +- ghostscript: Fix :cve:`2023-46751` +- gnutls: Fix :cve:`2024-0553` and :cve:`2024-0567` +- go: Fix :cve:`2023-39326` +- openssh: Fix :cve:`2023-48795`, :cve:`2023-51384` and :cve:`2023-51385` +- openssl: Fix :cve:`2023-6129` and :cve_mitre:`2023-6237` +- pam: Fix :cve_mitre:`2024-22365` +- perl: Fix :cve:`2023-47038` +- qemu: Fix :cve:`2023-5088` +- sqlite3: Fix :cve:`2023-7104` +- systemd: Fix :cve:`2023-7008` +- tiff: Fix :cve:`2023-6228` +- xserver-xorg: Fix :cve:`2023-6377`, :cve:`2023-6478`, :cve:`2023-6816`, :cve_mitre:`2024-0229`, :cve:`2024-0408`, :cve:`2024-0409`, :cve_mitre:`2024-21885` and :cve_mitre:`2024-21886` +- zlib: Ignore :cve:`2023-6992` + + +Fixes in Yocto-4.0.16 +~~~~~~~~~~~~~~~~~~~~~ + +- bitbake: asyncrpc: Add context manager API +- bitbake: data: Add missing dependency handling of remove operator +- bitbake: lib/bb: Add workaround for libgcc issues with python 3.8 and 3.9 +- bitbake: toastergui: verify that an existing layer path is given +- build-appliance-image: Update to kirkstone head revision +- contributor-guide: add License-Update tag +- contributor-guide: fix command option +- contributor-guide: use "apt" instead of "aptitude" +- cpio: upgrade to 2.14 +- cve-update-nvd2-native: faster requests with API keys +- cve-update-nvd2-native: increase the delay between subsequent request failures +- cve-update-nvd2-native: make number of fetch attemtps configurable +- cve-update-nvd2-native: remove unused variable CVE_SOCKET_TIMEOUT +- dev-manual: Discourage the use of SRC_URI[md5sum] +- dev-manual: layers: update link to YP Compatible form +- dev-manual: runtime-testing: fix test module name +- dev-manual: start.rst: update use of Download page +- docs:what-i-wish-id-known.rst: fix URL +- docs: document VSCode extension +- docs:brief-yoctoprojectqs:index.rst: align variable order with default local.conf +- docs:migration-guides: add release notes for 4.0.15 +- docs:migration-guides: release 3.5 is actually 4.0 +- elfutils: Disable stringop-overflow warning for build host +- externalsrc: Ensure :term:`SRCREV` is processed before accessing :term:`SRC_URI` +- linux-firmware: upgrade to 20231030 +- manuals: Add :term:`CONVERSION_CMD` definition +- manuals: Add :term:`UBOOT_BINARY`, extend :term:`UBOOT_CONFIG` +- perl: upgrade to 5.34.3 +- poky.conf: bump version for 4.0.16 +- pybootchartgui: fix 2 SyntaxWarnings +- python3-ptest: skip test_storlines +- ref-manual: Fix reference to MIRRORS/PREMIRRORS defaults +- ref-manual: classes: remove insserv bbclass +- ref-manual: releases.svg: update nanbield release status +- ref-manual: resources: sync with master branch +- ref-manual: update tested and supported distros +- test-manual: add links to python unittest +- test-manual: add or improve hyperlinks +- test-manual: explicit or fix file paths +- test-manual: resource updates +- test-manual: text and formatting fixes +- test-manual: use working example +- testimage: Exclude wtmp from target-dumper commands +- testimage: drop target_dumper, host_dumper, and monitor_dumper +- tzdata: Upgrade to 2023d + + +Known Issues in Yocto-4.0.16 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- N/A + + +Contributors to Yocto-4.0.16 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- Aatir Manzur +- Archana Polampalli +- Dhairya Nagodra +- Dmitry Baryshkov +- Enguerrand de Ribaucourt +- Hitendra Prajapati +- Insu Park +- Joshua Watt +- Justin Bronder +- Jörg Sommer +- Khem Raj +- Lee Chee Yang +- mark.yang +- Marta Rybczynska +- Martin Jansa +- Maxin B. John +- Michael Opdenacker +- Paul Barker +- Peter Kjellerstedt +- Peter Marko +- Poonam Jadhav +- Richard Purdie +- Shubham Kulkarni +- Simone Weiß +- Soumya Sambu +- Sourav Pramanik +- Steve Sakoman +- Trevor Gamblin +- Vijay Anusuri +- Vivek Kumbhar +- Yoann Congal +- Yogita Urade + + +Repositories / Downloads for Yocto-4.0.16 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +poky + +- Repository Location: :yocto_git:`/poky` +- Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>` +- Tag: :yocto_git:`yocto-4.0.16 </poky/log/?h=yocto-4.0.16>` +- Git Revision: :yocto_git:`54af8c5e80ebf63707ef4e51cc9d374f716da603 </poky/commit/?id=54af8c5e80ebf63707ef4e51cc9d374f716da603>` +- Release Artefact: poky-54af8c5e80ebf63707ef4e51cc9d374f716da603 +- sha: a53ec3a661cf56ca40c0fbf1500288c2c20abe94896d66a572bc5ccf5d92e9d6 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.16/poky-54af8c5e80ebf63707ef4e51cc9d374f716da603.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.16/poky-54af8c5e80ebf63707ef4e51cc9d374f716da603.tar.bz2 + +openembedded-core + +- Repository Location: :oe_git:`/openembedded-core` +- Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>` +- Tag: :oe_git:`yocto-4.0.16 </openembedded-core/log/?h=yocto-4.0.16>` +- Git Revision: :oe_git:`a744a897f0ea7d34c31c024c13031221f9a85f24 </openembedded-core/commit/?id=a744a897f0ea7d34c31c024c13031221f9a85f24>` +- Release Artefact: oecore-a744a897f0ea7d34c31c024c13031221f9a85f24 +- sha: 8c2bc9487597b0caa9f5a1d72b18cfcd1ddc7e6d91f0f051313563d6af95aeec +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.16/oecore-a744a897f0ea7d34c31c024c13031221f9a85f24.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.16/oecore-a744a897f0ea7d34c31c024c13031221f9a85f24.tar.bz2 + +meta-mingw + +- Repository Location: :yocto_git:`/meta-mingw` +- Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>` +- Tag: :yocto_git:`yocto-4.0.16 </meta-mingw/log/?h=yocto-4.0.16>` +- Git Revision: :yocto_git:`f6b38ce3c90e1600d41c2ebb41e152936a0357d7 </meta-mingw/commit/?id=f6b38ce3c90e1600d41c2ebb41e152936a0357d7>` +- Release Artefact: meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7 +- sha: 7d57167c19077f4ab95623d55a24c2267a3a3fb5ed83688659b4c03586373b25 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.16/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.16/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.tar.bz2 + +meta-gplv2 + +- Repository Location: :yocto_git:`/meta-gplv2` +- Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>` +- Tag: :yocto_git:`yocto-4.0.16 </meta-gplv2/log/?h=yocto-4.0.16>` +- Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>` +- Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a +- sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.16/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.16/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2 + +bitbake + +- Repository Location: :oe_git:`/bitbake` +- Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>` +- Tag: :oe_git:`yocto-4.0.16 </bitbake/log/?h=yocto-4.0.16>` +- Git Revision: :oe_git:`ee090484cc25d760b8c20f18add17b5eff485b40 </bitbake/commit/?id=ee090484cc25d760b8c20f18add17b5eff485b40>` +- Release Artefact: bitbake-ee090484cc25d760b8c20f18add17b5eff485b40 +- sha: 479e3a57ae9fbc2aa95292a7554caeef113bbfb28c226ed19547b8dde1c95314 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.16/bitbake-ee090484cc25d760b8c20f18add17b5eff485b40.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.16/bitbake-ee090484cc25d760b8c20f18add17b5eff485b40.tar.bz2 + +yocto-docs + +- Repository Location: :yocto_git:`/yocto-docs` +- Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>` +- Tag: :yocto_git:`yocto-4.0.16 </yocto-docs/log/?h=yocto-4.0.16>` +- Git Revision: :yocto_git:`aba67b58711019a6ba439b2b77337f813ed799ac </yocto-docs/commit/?id=aba67b58711019a6ba439b2b77337f813ed799ac>` + diff --git a/poky/documentation/migration-guides/release-notes-4.0.17.rst b/poky/documentation/migration-guides/release-notes-4.0.17.rst new file mode 100644 index 0000000000..1dfd10ce20 --- /dev/null +++ b/poky/documentation/migration-guides/release-notes-4.0.17.rst @@ -0,0 +1,238 @@ +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK + +Release notes for Yocto-4.0.17 (Kirkstone) +------------------------------------------ + +Security Fixes in Yocto-4.0.17 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- bind: Fix :cve:`2023-4408`, :cve:`2023-50387`, :cve:`2023-50868`, :cve:`2023-5517` and :cve:`2023-5679` +- binutils: Fix :cve:`2023-39129` and :cve:`2023-39130` +- curl: Fix :cve:`2023-46219` +- curl: Ignore :cve:`2023-42915` +- gcc: Ignore :cve:`2023-4039` +- gdb: Fix :cve:`2023-39129` and :cve:`2023-39130` +- glibc: Ignore :cve:`2023-0687` +- go: Fix :cve:`2023-29406`, :cve:`2023-45285`, :cve:`2023-45287`, :cve:`2023-45289`, :cve:`2023-45290`, :cve:`2024-24784` and :cve:`2024-24785` +- less: Fix :cve:`2022-48624` +- libgit2: Fix :cve:`2024-24575` and :cve:`2024-24577` +- libuv: fix :cve:`2024-24806` +- libxml2: Fix for :cve:`2024-25062` +- linux-yocto/5.15: Fix :cve:`2022-36402`, :cve:`2022-40982`, :cve:`2022-47940`, :cve:`2023-1193`, :cve:`2023-1194`, :cve:`2023-20569`, :cve:`2023-20588`, :cve:`2023-25775`, :cve:`2023-31085`, :cve:`2023-32247`, :cve:`2023-32250`, :cve:`2023-32252`, :cve:`2023-32254`, :cve:`2023-32257`, :cve:`2023-32258`, :cve:`2023-34324`, :cve:`2023-35827`, :cve:`2023-3772`, :cve:`2023-38427`, :cve:`2023-38430`, :cve:`2023-38431`, :cve_mitre:`2023-3867`, :cve:`2023-39189`, :cve:`2023-39192`, :cve:`2023-39193`, :cve:`2023-39194`, :cve:`2023-39198`, :cve:`2023-40283`, :cve:`2023-4128`, :cve:`2023-4206`, :cve:`2023-4207`, :cve:`2023-4208`, :cve:`2023-4244`, :cve:`2023-4273`, :cve:`2023-42752`, :cve:`2023-42753`, :cve:`2023-42754`, :cve:`2023-42755`, :cve:`2023-4563`, :cve:`2023-4569`, :cve:`2023-45871`, :cve:`2023-4623`, :cve:`2023-46343`, :cve:`2023-46813`, :cve:`2023-46838`, :cve:`2023-46862`, :cve:`2023-4881`, :cve:`2023-4921`, :cve:`2023-51042`, :cve:`2023-5158`, :cve:`2023-51779`, :cve_mitre:`2023-52340`, :cve:`2023-52429`, :cve:`2023-52435`, :cve:`2023-52436`, :cve:`2023-52438`, :cve:`2023-52439`, :cve:`2023-52441`, :cve:`2023-52442`, :cve:`2023-52443`, :cve:`2023-52444`, :cve:`2023-52445`, :cve:`2023-52448`, :cve:`2023-52449`, :cve:`2023-52451`, :cve:`2023-52454`, :cve:`2023-52456`, :cve:`2023-52457`, :cve:`2023-52458`, :cve:`2023-52463`, :cve:`2023-52464`, :cve:`2023-5717`, :cve:`2023-6040`, :cve:`2023-6121`, :cve:`2023-6176`, :cve:`2023-6546`, :cve:`2023-6606`, :cve:`2023-6622`, :cve:`2023-6817`, :cve:`2023-6915`, :cve:`2023-6931`, :cve:`2023-6932`, :cve:`2024-0340`, :cve:`2024-0584`, :cve:`2024-0607`, :cve:`2024-0641`, :cve:`2024-0646`, :cve:`2024-1085`, :cve:`2024-1086`, :cve:`2024-1151`, :cve:`2024-22705`, :cve:`2024-23849`, :cve:`2024-23850`, :cve:`2024-23851`, :cve:`2024-24860`, :cve:`2024-26586`, :cve:`2024-26589`, :cve:`2024-26591`, :cve:`2024-26592`, :cve:`2024-26593`, :cve:`2024-26594`, :cve:`2024-26597` and :cve:`2024-26598` +- linux-yocto/5.15: Ignore :cve:`2020-27418`, :cve:`2020-36766`, :cve:`2021-33630`, :cve:`2021-33631`, :cve:`2022-48619`, :cve:`2023-2430`, :cve:`2023-40791`, :cve:`2023-42756`, :cve:`2023-44466`, :cve:`2023-45862`, :cve:`2023-45863`, :cve:`2023-45898`, :cve:`2023-4610`, :cve:`2023-4732`, :cve:`2023-5090`, :cve:`2023-51043`, :cve:`2023-5178`, :cve:`2023-51780`, :cve:`2023-51781`, :cve:`2023-51782`, :cve:`2023-5197`, :cve:`2023-52433`, :cve:`2023-52440`, :cve:`2023-52446`, :cve:`2023-52450`, :cve:`2023-52453`, :cve:`2023-52455`, :cve:`2023-52459`, :cve:`2023-52460`, :cve:`2023-52461`, :cve:`2023-52462`, :cve:`2023-5345`, :cve:`2023-5633`, :cve:`2023-5972`, :cve:`2023-6111`, :cve:`2023-6200`, :cve:`2023-6531`, :cve:`2023-6679`, :cve:`2023-7192`, :cve:`2024-0193`, :cve:`2024-0443`, :cve:`2024-0562`, :cve:`2024-0582`, :cve:`2024-0639`, :cve:`2024-0775`, :cve:`2024-26581`, :cve:`2024-26582`, :cve:`2024-26590`, :cve:`2024-26596` and :cve:`2024-26599` +- linux-yocto/5.10: Fix :cve:`2023-39198`, :cve:`2023-46838`, :cve:`2023-51779`, :cve:`2023-51780`, :cve:`2023-51781`, :cve:`2023-51782`, :cve_mitre:`2023-52340`, :cve:`2023-6040`, :cve:`2023-6121`, :cve:`2023-6606`, :cve:`2023-6817`, :cve:`2023-6915`, :cve:`2023-6931`, :cve:`2023-6932`, :cve:`2024-0584` and :cve:`2024-0646` +- linux-yocto/5.10: Ignore :cve:`2021-33630`, :cve:`2021-33631`, :cve:`2022-1508`, :cve:`2022-36402`, :cve:`2022-48619`, :cve:`2023-2430`, :cve:`2023-4610`, :cve:`2023-46343`, :cve:`2023-51042`, :cve:`2023-51043`, :cve:`2023-5972`, :cve:`2023-6039`, :cve:`2023-6200`, :cve:`2023-6531`, :cve:`2023-6546`, :cve:`2023-6622`, :cve:`2023-6679`, :cve:`2023-7192`, :cve:`2024-0193`, :cve:`2024-0443`, :cve:`2024-0562`, :cve:`2024-0582`, :cve:`2024-0639`, :cve:`2024-0641`, :cve:`2024-0775`, :cve:`2024-1085` and :cve:`2024-22705` +- openssl: Fix :cve:`2024-0727` +- python3-pycryptodome: Fix :cve:`2023-52323` +- qemu: Fix :cve:`2023-42467`, :cve:`2023-6693` and :cve:`2024-24474` +- vim: Fix :cve:`2024-22667` +- xwayland: Fix :cve:`2023-6377` and :cve:`2023-6478` + + +Fixes in Yocto-4.0.17 +~~~~~~~~~~~~~~~~~~~~~ + +- bind: Upgrade to 9.18.24 +- bitbake: bitbake/codeparser.py: address ast module deprecations in py 3.12 +- bitbake: bitbake/lib/bs4/tests/test_tree.py: python 3.12 regex +- bitbake: codeparser: replace deprecated ast.Str and 's' +- bitbake: fetch2: Ensure that git LFS objects are available +- bitbake: tests/fetch: Add real git lfs tests and decorator +- bitbake: tests/fetch: git-lfs restore _find_git_lfs +- bitbake: toaster/toastergui: Bug-fix verify given layer path only if import/add local layer +- build-appliance-image: Update to kirkstone head revision +- cmake: Unset CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES +- contributor-guide: fix lore URL +- curl: don't enable debug builds +- cve_check: cleanup logging +- dbus: Add missing :term:`CVE_PRODUCT` +- dev-manual: sbom: Rephrase spdx creation +- dev-manual: runtime-testing: gen-tapdevs need iptables installed +- dev-manual: packages: clarify shared :term:`PR` service constraint +- dev-manual: packages: need enough free space +- dev-manual: start: remove idle line +- feature-microblaze-versions.inc: python 3.12 regex +- ghostscript: correct :term:`LICENSE` with AGPLv3 +- image-live.bbclass: LIVE_ROOTFS_TYPE support compression +- kernel.bbclass: Set pkg-config variables for building modules +- kernel.bbclass: introduce KERNEL_LOCALVERSION +- kernel: fix localversion in v6.3+ +- kernel: make LOCALVERSION consistent between recipes +- ldconfig-native: Fix to point correctly on the DT_NEEDED entries in an ELF file +- librsvg: Fix do_package_qa error for librsvg +- linux-firmware: upgrade to 20231211 +- linux-yocto/5.10: update to v5.10.210 +- linux-yocto/5.15: update to v5.15.150 +- manuals: add minimum RAM requirements +- manuals: suppress excess use of "following" word +- manuals: update disk space requirements +- manuals: update references to buildtools +- manuals: updates for building on Windows (WSL 2) +- meta/lib/oeqa: python 3.12 regex +- meta/recipes: python 3.12 regex +- migration-guide: add release notes for 4.0.16 +- oeqa/selftest/oelib/buildhistory: git default branch +- oeqa/selftest/recipetool: downgrade meson version to not use pyproject.toml +- oeqa/selftest/recipetool: expect meson.bb +- oeqa/selftest/recipetool: fix for python 3.12 +- oeqa/selftest/runtime_test: only run the virgl tests on qemux86-64 +- oeqa: replace deprecated assertEquals +- openssl: Upgrade to 3.0.13 +- poky.conf: bump version for 4.0.17 +- populate_sdk_ext: use ConfigParser instead of SafeConfigParser +- python3-jinja2: upgrade to 3.1.3 +- recipetool/create_buildsys_python: use importlib instead of imp +- ref-manual: system-requirements: recommend buildtools for not supported distros +- ref-manual: system-requirements: add info on buildtools-make-tarball +- ref-manual: release-process: grammar fix +- ref-manual: system-requirements: fix AlmaLinux variable name +- ref-manual: system-requirements: modify anchor +- ref-manual: system-requirements: remove outdated note +- ref-manual: system-requirements: simplify supported distro requirements +- ref-manual: system-requirements: update packages to build docs +- scripts/runqemu: add qmp socket support +- scripts/runqemu: direct mesa to use its own drivers, rather than ones provided by host distro +- scripts/runqemu: fix regex escape sequences +- scripts: python 3.12 regex +- selftest: skip virgl gtk/sdl test on ubuntu 18.04 +- systemd: Only add myhostname to nsswitch.conf if in :term:`PACKAGECONFIG` +- tzdata : Upgrade to 2024a +- u-boot: Move UBOOT_INITIAL_ENV back to u-boot.inc +- useradd-example: do not use unsupported clear text password +- vim: upgrade to v9.0.2190 +- yocto-bsp: update to v5.15.150 + + +Known Issues in Yocto-4.0.17 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- N/A + + +Contributors to Yocto-4.0.17 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- Adrian Freihofer +- Alassane Yattara +- Alexander Kanavin +- Alexander Sverdlin +- Archana Polampalli +- Baruch Siach +- Bruce Ashfield +- Chen Qi +- Chris Laplante +- Deepthi Hemraj +- Dhairya Nagodra +- Fabien Mahot +- Fabio Estevam +- Hitendra Prajapati +- Hugo SIMELIERE +- Jermain Horsman +- Kai Kang +- Lee Chee Yang +- Ludovic Jozeau +- Michael Opdenacker +- Ming Liu +- Munehisa Kamata +- Narpat Mali +- Nikhil R +- Paul Eggleton +- Paulo Neves +- Peter Marko +- Philip Lorenz +- Poonam Jadhav +- Priyal Doshi +- Ross Burton +- Simone Weiß +- Soumya Sambu +- Steve Sakoman +- Tim Orling +- Trevor Gamblin +- Vijay Anusuri +- Vivek Kumbhar +- Wang Mingyu +- Zahir Hussain + + +Repositories / Downloads for Yocto-4.0.17 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +poky + +- Repository Location: :yocto_git:`/poky` +- Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>` +- Tag: :yocto_git:`yocto-4.0.17 </poky/log/?h=yocto-4.0.17>` +- Git Revision: :yocto_git:`6d1a878bbf24c66f7186b270f823fcdf82e35383 </poky/commit/?id=6d1a878bbf24c66f7186b270f823fcdf82e35383>` +- Release Artefact: poky-6d1a878bbf24c66f7186b270f823fcdf82e35383 +- sha: 3bc3010340b674f7b0dd0a7997f0167b2240b794fbd4aa28c0c4217bddd15e30 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/poky-6d1a878bbf24c66f7186b270f823fcdf82e35383.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/poky-6d1a878bbf24c66f7186b270f823fcdf82e35383.tar.bz2 + +openembedded-core + +- Repository Location: :oe_git:`/openembedded-core` +- Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>` +- Tag: :oe_git:`yocto-4.0.17 </openembedded-core/log/?h=yocto-4.0.17>` +- Git Revision: :oe_git:`2501534c9581c6c3439f525d630be11554a57d24 </openembedded-core/commit/?id=2501534c9581c6c3439f525d630be11554a57d24>` +- Release Artefact: oecore-2501534c9581c6c3439f525d630be11554a57d24 +- sha: 52cc6cce9e920bdce078584b89136e81cc01e0c55616fab5fca6c3e04264c88e +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/oecore-2501534c9581c6c3439f525d630be11554a57d24.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/oecore-2501534c9581c6c3439f525d630be11554a57d24.tar.bz2 + +meta-mingw + +- Repository Location: :yocto_git:`/meta-mingw` +- Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>` +- Tag: :yocto_git:`yocto-4.0.17 </meta-mingw/log/?h=yocto-4.0.17>` +- Git Revision: :yocto_git:`f6b38ce3c90e1600d41c2ebb41e152936a0357d7 </meta-mingw/commit/?id=f6b38ce3c90e1600d41c2ebb41e152936a0357d7>` +- Release Artefact: meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7 +- sha: 7d57167c19077f4ab95623d55a24c2267a3a3fb5ed83688659b4c03586373b25 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.tar.bz2 + +meta-gplv2 + +- Repository Location: :yocto_git:`/meta-gplv2` +- Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>` +- Tag: :yocto_git:`yocto-4.0.17 </meta-gplv2/log/?h=yocto-4.0.17>` +- Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>` +- Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a +- sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2 + +meta-clang + +- Repository Location: :yocto_git:`/meta-clang` +- Branch: :yocto_git:`kirkstone </meta-clang/log/?h=kirkstone>` +- Tag: :yocto_git:`yocto-4.0.17 </meta-clang/log/?h=yocto-4.0.17>` +- Git Revision: :yocto_git:`eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52 </meta-clang/commit/?id=eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52>` +- Release Artefact: meta-clang-eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52 +- sha: 3299e96e069a22c0971e903fbc191f2427efffc83d910ac51bf0237caad01d17 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/meta-clang-eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/meta-clang-eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52.tar.bz2 + +bitbake + +- Repository Location: :oe_git:`/bitbake` +- Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>` +- Tag: :oe_git:`yocto-4.0.17 </bitbake/log/?h=yocto-4.0.17>` +- Git Revision: :oe_git:`40fd5f4eef7460ca67f32cfce8e229e67e1ff607 </bitbake/commit/?id=40fd5f4eef7460ca67f32cfce8e229e67e1ff607>` +- Release Artefact: bitbake-40fd5f4eef7460ca67f32cfce8e229e67e1ff607 +- sha: 5d20a0e4c5d0fce44bd84778168714a261a30a4b83f67c88df3b8a7e7115e444 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/bitbake-40fd5f4eef7460ca67f32cfce8e229e67e1ff607.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/bitbake-40fd5f4eef7460ca67f32cfce8e229e67e1ff607.tar.bz2 + +yocto-docs + +- Repository Location: :yocto_git:`/yocto-docs` +- Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>` +- Tag: :yocto_git:`yocto-4.0.17 </yocto-docs/log/?h=yocto-4.0.17>` +- Git Revision: :yocto_git:`08ce7db2aa3a38deb8f5aa59bafc78542986babb </yocto-docs/commit/?id=08ce7db2aa3a38deb8f5aa59bafc78542986babb>` + diff --git a/poky/documentation/migration-guides/release-notes-4.3.2.rst b/poky/documentation/migration-guides/release-notes-4.3.2.rst new file mode 100644 index 0000000000..3a40d83bc2 --- /dev/null +++ b/poky/documentation/migration-guides/release-notes-4.3.2.rst @@ -0,0 +1,247 @@ +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK + +Release notes for Yocto-4.3.2 (Nanbield) +---------------------------------------- + +Security Fixes in Yocto-4.3.2 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- avahi: Fix :cve:`2023-1981`, :cve:`2023-38469`, :cve:`2023-38470`, :cve:`2023-38471`, :cve:`2023-38472` and :cve:`2023-38473` +- curl: Fix :cve:`2023-46218` +- ghostscript: Fix :cve:`2023-46751` +- grub: fix :cve:`2023-4692` and :cve:`2023-4693` +- gstreamer1.0: Fix :cve_mitre:`2023-44446` +- linux-yocto/6.1: Ignore :cve_mitre:`2023-39197`, :cve:`2023-39198`, :cve:`2023-5090`, :cve:`2023-5633`, :cve:`2023-6111`, :cve:`2023-6121` and :cve:`2023-6176` +- linux-yocto/6.5: Ignore :cve:`2022-44034`, :cve_mitre:`2023-39197`, :cve:`2023-39198`, :cve:`2023-5972`, :cve:`2023-6039`, :cve:`2023-6111` and :cve:`2023-6176` +- perl: fix :cve:`2023-47100` +- python3-urllib3: Fix :cve:`2023-45803` +- rust: Fix :cve:`2023-40030` +- vim: Fix :cve:`2023-48231`, :cve:`2023-48232`, :cve:`2023-48233`, :cve:`2023-48234`, :cve:`2023-48235`, :cve:`2023-48236` and :cve:`2023-48237` +- xserver-xorg: Fix :cve:`2023-5367` and :cve:`2023-5380` +- xwayland: Fix :cve:`2023-5367` + + +Fixes in Yocto-4.3.2 +~~~~~~~~~~~~~~~~~~~~ + +- base-passwd: Upgrade to 3.6.2 +- bind: Upgrade to 9.18.20 +- binutils: stable 2.41 branch updates +- bitbake: command: Make parseRecipeFile() handle virtual recipes correctly +- bitbake: lib/bb: Add workaround for libgcc issues with python 3.8 and 3.9 +- bitbake: toastergui: verify that an existing layer path is given +- bluez5: fix connection for ps5/dualshock controllers +- build-appliance-image: Update to nanbield head revision +- cmake: Upgrade to 3.27.7 +- contributor-guide: add License-Update tag +- contributor-guide: fix command option +- cups: Add root,sys,wheel to system groups +- cve-update-nvd2-native: faster requests with API keys +- cve-update-nvd2-native: increase the delay between subsequent request failures +- cve-update-nvd2-native: make number of fetch attemtps configurable +- cve-update-nvd2-native: remove unused variable CVE_SOCKET_TIMEOUT +- dev-manual: Discourage the use of SRC_URI[md5sum] +- dev-manual: layers: update link to YP Compatible form +- dev-manual: runtime-testing: fix test module name +- devtool: finish/update-recipe: restrict mode srcrev to recipes fetched from SCM +- devtool: fix update-recipe dry-run mode +- ell: Upgrade to 0.60 +- enchant2: Upgrade to 2.6.2 +- ghostscript: Upgrade to 10.02.1 +- glib-2.0: Upgrade to 2.78.1 +- glibc: stable 2.38 branch updates +- gstreamer1.0: Upgrade to 1.22.7 +- gtk: Add rdepend on printbackend for cups +- harfbuzz: Upgrade to 8.2.2 +- json-c: fix icecc compilation +- kern-tools: bump :term:`SRCREV` for queue processing changes +- kern-tools: make lower context patches reproducible +- kern-tools: update :term:`SRCREV` to include SECURITY.md file +- kernel-arch: use ccache only for compiler +- kernel-yocto: improve metadata patching +- lib/oe/buildcfg.py: Include missing import +- lib/oe/buildcfg.py: Remove unused parameter +- lib/oe/patch: ensure os.chdir restoring always happens +- lib/oe/path: Deploy files can start only with a dot +- libgcrypt: Upgrade to 1.10.3 +- libjpeg-turbo: Upgrade to 3.0.1 +- libnewt: Upgrade to 0.52.24 +- libnsl2: Upgrade to 2.0.1 +- libsolv: Upgrade to 0.7.26 +- libxslt: Upgrade to 1.1.39 +- linux-firmware: add audio topology symlink to the X13's audio package +- linux-firmware: add missing depenencies on license packages +- linux-firmware: add new fw file to ${PN}-rtl8821 +- linux-firmware: add notice file to sdm845 modem firmware +- linux-firmware: create separate packages +- linux-firmware: package Qualcomm Venus 6.0 firmware +- linux-firmware: package Robotics RB5 sensors DSP firmware +- linux-firmware: package firmware for Qualcomm Adreno a702 +- linux-firmware: package firmware for Qualcomm QCM2290 / QRB4210 +- linux-firmware: Upgrade to 20231030 +- linux-yocto-rt/6.1: update to -rt18 +- linux-yocto/6.1: cfg: restore CONFIG_DEVMEM +- linux-yocto/6.1: drop removed IMA option +- linux-yocto/6.1: Upgrade to v6.1.68 +- linux-yocto/6.5: cfg: restore CONFIG_DEVMEM +- linux-yocto/6.5: cfg: split runtime and symbol debug +- linux-yocto/6.5: drop removed IMA option +- linux-yocto/6.5: fix AB-INT: QEMU kernel panic: No irq handler for vector +- linux-yocto/6.5: Upgrade to v6.5.13 +- linux/cve-exclusion6.1: Update to latest kernel point release +- log4cplus: Upgrade to 2.1.1 +- lsb-release: use https for :term:`UPSTREAM_CHECK_URI` +- manuals: brief-yoctoprojectqs: align variable order with default local.conf +- manuals: fix URL +- meson: use correct targets for rust binaries +- migration-guide: add release notes for 4.0.14, 4.0.15, 4.2.4, 4.3.1 +- migration-guides: release 3.5 is actually 4.0 +- migration-guides: reword fix in release-notes-4.3.1 +- msmtp: Upgrade to 1.8.25 +- oeqa/selftest/tinfoil: Add tests that parse virtual recipes +- openssl: improve handshake test error reporting +- package_ipk: Fix Source: field variable dependency +- patchtest: shorten patch signed-off-by test output +- perf: lift :term:`TARGET_CC_ARCH` modification out of security_flags.inc +- perl: Upgrade to 5.38.2 +- perlcross: Upgrade to 1.5.2 +- poky.conf: bump version for 4.3.2 release +- python3-ptest: skip test_storlines +- python3-urllib3: Upgrade to 2.0.7 +- qemu: Upgrade to 8.1.2 +- ref-manual: Fix reference to MIRRORS/PREMIRRORS defaults +- ref-manual: releases.svg: update nanbield release status +- useradd_base: sed -i destroys symlinks +- rootfs-postcommands: sed -i destroys symlinks +- sstate: Ensure sstate searches update file mtime +- strace: backport fix for so_peerpidfd-test +- systemd-boot: Fix build issues on armv7a-linux +- systemd-compat-units.bb: fix postinstall script +- systemd: fix DynamicUser issue +- systemd: update :term:`LICENSE` statement +- tcl: skip async and event tests in run-ptest +- tcl: skip timing-dependent tests in run-ptest +- test-manual: add links to python unittest +- test-manual: add or improve hyperlinks +- test-manual: explicit or fix file paths +- test-manual: resource updates +- test-manual: text and formatting fixes +- test-manual: use working example +- testimage: Drop target_dumper and most of monitor_dumper +- testimage: Exclude wtmp from target-dumper commands +- tzdata: Upgrade to 2023d +- update_gtk_icon_cache: Fix for GTK4-only builds +- useradd_base: Fix sed command line for passwd-expire +- vim: Upgrade to 9.0.2130 +- xserver-xorg: Upgrade to 21.1.9 +- xwayland: Upgrade to 23.2.2 + + +Known Issues in Yocto-4.3.2 +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- N/A + +Contributors to Yocto-4.3.2 +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- Adam Johnston +- Alexander Kanavin +- Anuj Mittal +- Bastian Krause +- Bruce Ashfield +- Chen Qi +- Deepthi Hemraj +- Dhairya Nagodra +- Dmitry Baryshkov +- Fahad Arslan +- Javier Tia +- Jermain Horsman +- Joakim Tjernlund +- Julien Stephan +- Justin Bronder +- Khem Raj +- Lee Chee Yang +- Marco Felsch +- Markus Volk +- Marta Rybczynska +- Massimiliano Minella +- Michael Opdenacker +- Paul Barker +- Peter Kjellerstedt +- Peter Marko +- Randy MacLeod +- Rasmus Villemoes +- Richard Purdie +- Ross Burton +- Shubham Kulkarni +- Simone Weiß +- Steve Sakoman +- Sundeep KOKKONDA +- Tim Orling +- Trevor Gamblin +- Vijay Anusuri +- Viswanath Kraleti +- Vyacheslav Yurkov +- Wang Mingyu +- William Lyu +- Zoltán Böszörményi + +Repositories / Downloads for Yocto-4.3.2 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +poky + +- Repository Location: :yocto_git:`/poky` +- Branch: :yocto_git:`nanbield </poky/log/?h=nanbield>` +- Tag: :yocto_git:`yocto-4.3.2 </poky/log/?h=yocto-4.3.2>` +- Git Revision: :yocto_git:`f768ffb8916feb6542fcbe3e946cbf30e247b151 </poky/commit/?id=f768ffb8916feb6542fcbe3e946cbf30e247b151>` +- Release Artefact: poky-f768ffb8916feb6542fcbe3e946cbf30e247b151 +- sha: 21ca1695d70aba9b4bd8626d160111feab76206883cd14fe41eb024692bdfd7b +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.3.2/poky-f768ffb8916feb6542fcbe3e946cbf30e247b151.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.3.2/poky-f768ffb8916feb6542fcbe3e946cbf30e247b151.tar.bz2 + +openembedded-core + +- Repository Location: :oe_git:`/openembedded-core` +- Branch: :oe_git:`nanbield </openembedded-core/log/?h=nanbield>` +- Tag: :oe_git:`yocto-4.3.2 </openembedded-core/log/?h=yocto-4.3.2>` +- Git Revision: :oe_git:`ff595b937d37d2315386aebf315cea719e2362ea </openembedded-core/commit/?id=ff595b937d37d2315386aebf315cea719e2362ea>` +- Release Artefact: oecore-ff595b937d37d2315386aebf315cea719e2362ea +- sha: a7c6332dc0e09ecc08221e78b11151e8e2a3fd9fa3eaad96a4c03b67012bfb97 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.3.2/oecore-ff595b937d37d2315386aebf315cea719e2362ea.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.3.2/oecore-ff595b937d37d2315386aebf315cea719e2362ea.tar.bz2 + +meta-mingw + +- Repository Location: :yocto_git:`/meta-mingw` +- Branch: :yocto_git:`nanbield </meta-mingw/log/?h=nanbield>` +- Tag: :yocto_git:`yocto-4.3.2 </meta-mingw/log/?h=yocto-4.3.2>` +- Git Revision: :yocto_git:`49617a253e09baabbf0355bc736122e9549c8ab2 </meta-mingw/commit/?id=49617a253e09baabbf0355bc736122e9549c8ab2>` +- Release Artefact: meta-mingw-49617a253e09baabbf0355bc736122e9549c8ab2 +- sha: 2225115b73589cdbf1e491115221035c6a61679a92a93b2a3cf761ff87bf4ecc +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.3.2/meta-mingw-49617a253e09baabbf0355bc736122e9549c8ab2.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.3.2/meta-mingw-49617a253e09baabbf0355bc736122e9549c8ab2.tar.bz2 + +bitbake + +- Repository Location: :oe_git:`/bitbake` +- Branch: :oe_git:`2.6 </bitbake/log/?h=2.6>` +- Tag: :oe_git:`yocto-4.3.2 </bitbake/log/?h=yocto-4.3.2>` +- Git Revision: :oe_git:`72bf75f0b2e7f36930185e18a1de8277ce7045d8 </bitbake/commit/?id=72bf75f0b2e7f36930185e18a1de8277ce7045d8>` +- Release Artefact: bitbake-72bf75f0b2e7f36930185e18a1de8277ce7045d8 +- sha: 0b6ccd4796ccd211605090348a3d4378358c839ae1bb4c35964d0f36f2663187 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.3.2/bitbake-72bf75f0b2e7f36930185e18a1de8277ce7045d8.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.3.2/bitbake-72bf75f0b2e7f36930185e18a1de8277ce7045d8.tar.bz2 + +yocto-docs + +- Repository Location: :yocto_git:`/yocto-docs` +- Branch: :yocto_git:`nanbield </yocto-docs/log/?h=nanbield>` +- Tag: :yocto_git:`yocto-4.3.2 </yocto-docs/log/?h=yocto-4.3.2>` +- Git Revision: :yocto_git:`fac88b9e80646a68b31975c915a718a9b6b2b439 </yocto-docs/commit/?id=fac88b9e80646a68b31975c915a718a9b6b2b439>` + diff --git a/poky/documentation/migration-guides/release-notes-4.3.3.rst b/poky/documentation/migration-guides/release-notes-4.3.3.rst new file mode 100644 index 0000000000..2a0658a9c9 --- /dev/null +++ b/poky/documentation/migration-guides/release-notes-4.3.3.rst @@ -0,0 +1,200 @@ +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK + +Release notes for Yocto-4.3.3 (Nanbield) +---------------------------------------- + +Security Fixes in Yocto-4.3.3 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- curl: Fix :cve:`2023-46219` +- glibc: Ignore fixed :cve:`2023-0687` and :cve:`2023-5156` +- linux-yocto/6.1: Ignore :cve:`2022-48619`, :cve:`2023-4610`, :cve:`2023-5178`, :cve:`2023-5972`, :cve:`2023-6040`, :cve:`2023-6531`, :cve:`2023-6546`, :cve:`2023-6622`, :cve:`2023-6679`, :cve:`2023-6817`, :cve:`2023-6931`, :cve:`2023-6932`, :cve:`2023-7192`, :cve:`2024-0193` and :cve:`2024-0443` +- linux-yocto/6.1: Fix :cve:`2023-1193`, :cve_mitre:`2023-51779`, :cve:`2023-51780`, :cve:`2023-51781`, :cve:`2023-51782` and :cve:`2023-6606` +- qemu: Fix :cve:`2023-3019` +- shadow: Fix :cve:`2023-4641` +- sqlite3: Fix :cve:`2024-0232` +- sqlite3: drop obsolete CVE ignore :cve:`2023-36191` +- sudo: Fix :cve:`2023-42456` and :cve:`2023-42465` +- tiff: Fix :cve:`2023-6277` +- xwayland: Fix :cve:`2023-6377` and :cve:`2023-6478` + + +Fixes in Yocto-4.3.3 +~~~~~~~~~~~~~~~~~~~~ + +- aspell: upgrade to 0.60.8.1 +- avahi: update URL for new project location +- base-passwd: upgrade to 3.6.3 +- bitbake: asyncrpc: Add context manager API +- bitbake: toaster/toastergui: Bug-fix verify given layer path only if import/add local layer +- build-appliance-image: Update to nanbield head revision +- classes-global/sstate: Fix variable typo +- cmake: Unset CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES +- contributor-guide: fix lore URL +- contributor-guide: use "apt" instead of "aptitude" +- create-spdx-2.2: combine spdx can try to write before dir creation +- curl: Disable test 1091 due to intermittent failures +- curl: Disable two intermittently failing tests +- dev-manual: gen-tapdevs need iptables installed +- dev-manual: start.rst: Update use of Download page +- dev-manual: update license manifest path +- devtool: deploy: provide max_process to strip_execs +- devtool: modify: Handle recipes with a menuconfig task correctly +- docs: document VSCode extension +- dtc: preserve version also from shallow git clones +- elfutils: Update license information +- glib-2.0: upgrade to 2.78.3 +- glibc-y2038-tests: do not run tests using 32 bit time APIs +- go: upgrade to 1.20.12 +- grub: fs/fat: Don't error when mtime is 0 +- gstreamer1.0: upgrade to 1.22.8 +- icon-naming-utils: take tarball from debian +- kea: upgrade to 2.4.1 +- lib/prservice: Improve lock handling robustness +- libadwaita: upgrade to 1.4.2 +- libatomic-ops: upgrade to 7.8.2 +- libva-utils: upgrade to 2.20.1 +- linux-firmware: Change bnx2 packaging +- linux-firmware: Create bnx2x subpackage +- linux-firmware: Fix the linux-firmware-bcm4373 :term:`FILES` variable +- linux-firmware: Package iwlwifi .pnvm files +- linux-yocto/6.1: security/cfg: add configs to harden protection +- linux-yocto/6.1: update to v6.1.73 +- meta/documentation.conf: fix do_menuconfig description +- migration-guide: add release notes for 4.0.16 +- migration-guide: add release notes for 4.3.2 +- ncurses: Fix - tty is hung after reset +- nfs-utils: Update Upstream-Status +- nfs-utils: upgrade to 2.6.4 +- oeqa/selftest/prservice: Improve test robustness +- package.py: OEHasPackage: Add :term:`MLPREFIX` to packagename +- poky.conf: bump version for 4.3.3 release +- pseudo: Update to pull in syncfs probe fix +- python3-license-expression: Fix the ptest failure +- qemu.bbclass: fix a python TypeError +- qemu: upgrade to 8.1.4 +- ref-manual: Add UBOOT_BINARY, extend :term:`UBOOT_CONFIG` +- ref-manual: classes: remove insserv bbclass +- ref-manual: update tested and supported distros +- release-notes-4.3: fix spacing +- rootfs.py: check depmodwrapper execution result +- rpcbind: Specify state directory under /run +- scripts/runqemu: fix regex escape sequences +- sqlite3: upgrade to 3.43.2 +- sstate: Fix dir ownership issues in :term:`SSTATE_DIR` +- sudo: upgrade to 1.9.15p5 +- tcl: Fix prepending to run-ptest script +- uninative-tarball.xz - reproducibility fix +- xwayland: upgrade to 23.2.3 +- zstd: fix :term:`LICENSE` statement + + +Known Issues in Yocto-4.3.3 +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- N/A + + +Contributors to Yocto-4.3.3 +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- Alassane Yattara +- Alexander Kanavin +- Anuj Mittal +- Baruch Siach +- Bruce Ashfield +- Chen Qi +- Clay Chang +- Enguerrand de Ribaucourt +- Ilya A. Kriveshko +- Jason Andryuk +- Jeremy A. Puhlman +- Joao Marcos Costa +- Jose Quaresma +- Joshua Watt +- Jörg Sommer +- Khem Raj +- Lee Chee Yang +- Markus Volk +- Massimiliano Minella +- Maxin B. John +- Michael Opdenacker +- Ming Liu +- Mingli Yu +- Peter Kjellerstedt +- Peter Marko +- Richard Purdie +- Robert Berger +- Robert Yang +- Rodrigo M. Duarte +- Ross Burton +- Saul Wold +- Simone Weiß +- Soumya Sambu +- Steve Sakoman +- Trevor Gamblin +- Wang Mingyu +- William Lyu +- Xiangyu Chen +- Yang Xu +- Zahir Hussain + + +Repositories / Downloads for Yocto-4.3.3 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +poky + +- Repository Location: :yocto_git:`/poky` +- Branch: :yocto_git:`nanbield </poky/log/?h=nanbield>` +- Tag: :yocto_git:`yocto-4.3.3 </poky/log/?h=yocto-4.3.3>` +- Git Revision: :yocto_git:`d3b27346c3a4a7ef7ec517e9d339d22bda74349d </poky/commit/?id=d3b27346c3a4a7ef7ec517e9d339d22bda74349d>` +- Release Artefact: poky-d3b27346c3a4a7ef7ec517e9d339d22bda74349d +- sha: 2db39f1bf7bbcee039e9970eed1f6f9233bcc95d675159647c9a2a334fc81eb0 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.3.3/poky-d3b27346c3a4a7ef7ec517e9d339d22bda74349d.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.3.3/poky-d3b27346c3a4a7ef7ec517e9d339d22bda74349d.tar.bz2 + +openembedded-core + +- Repository Location: :oe_git:`/openembedded-core` +- Branch: :oe_git:`nanbield </openembedded-core/log/?h=nanbield>` +- Tag: :oe_git:`yocto-4.3.3 </openembedded-core/log/?h=yocto-4.3.3>` +- Git Revision: :oe_git:`0584d01f623e1f9b0fef4dfa95dd66de6cbfb7b3 </openembedded-core/commit/?id=0584d01f623e1f9b0fef4dfa95dd66de6cbfb7b3>` +- Release Artefact: oecore-0584d01f623e1f9b0fef4dfa95dd66de6cbfb7b3 +- sha: 730de0d5744f139322402ff9a6b2483c6ab929f704cec06258ae51de1daebe3d +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.3.3/oecore-0584d01f623e1f9b0fef4dfa95dd66de6cbfb7b3.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.3.3/oecore-0584d01f623e1f9b0fef4dfa95dd66de6cbfb7b3.tar.bz2 + +meta-mingw + +- Repository Location: :yocto_git:`/meta-mingw` +- Branch: :yocto_git:`nanbield </meta-mingw/log/?h=nanbield>` +- Tag: :yocto_git:`yocto-4.3.3 </meta-mingw/log/?h=yocto-4.3.3>` +- Git Revision: :yocto_git:`49617a253e09baabbf0355bc736122e9549c8ab2 </meta-mingw/commit/?id=49617a253e09baabbf0355bc736122e9549c8ab2>` +- Release Artefact: meta-mingw-49617a253e09baabbf0355bc736122e9549c8ab2 +- sha: 2225115b73589cdbf1e491115221035c6a61679a92a93b2a3cf761ff87bf4ecc +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.3.3/meta-mingw-49617a253e09baabbf0355bc736122e9549c8ab2.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.3.3/meta-mingw-49617a253e09baabbf0355bc736122e9549c8ab2.tar.bz2 + +bitbake + +- Repository Location: :oe_git:`/bitbake` +- Branch: :oe_git:`2.6 </bitbake/log/?h=2.6>` +- Tag: :oe_git:`yocto-4.3.3 </bitbake/log/?h=yocto-4.3.3>` +- Git Revision: :oe_git:`380a9ac97de5774378ded5e37d40b79b96761a0c </bitbake/commit/?id=380a9ac97de5774378ded5e37d40b79b96761a0c>` +- Release Artefact: bitbake-380a9ac97de5774378ded5e37d40b79b96761a0c +- sha: 78f579b9d29e72d09b6fb10ac62aa925104335e92d2afb3155bc9ab1994e36c1 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.3.3/bitbake-380a9ac97de5774378ded5e37d40b79b96761a0c.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.3.3/bitbake-380a9ac97de5774378ded5e37d40b79b96761a0c.tar.bz2 + +yocto-docs + +- Repository Location: :yocto_git:`/yocto-docs` +- Branch: :yocto_git:`nanbield </yocto-docs/log/?h=nanbield>` +- Tag: :yocto_git:`yocto-4.3.3 </yocto-docs/log/?h=yocto-4.3.3>` +- Git Revision: :yocto_git:`dde4b815db82196af086847f68ee27d7902b4ffa </yocto-docs/commit/?id=dde4b815db82196af086847f68ee27d7902b4ffa>` + diff --git a/poky/documentation/migration-guides/release-notes-4.3.rst b/poky/documentation/migration-guides/release-notes-4.3.rst index 85180dfc3c..0e175067da 100644 --- a/poky/documentation/migration-guides/release-notes-4.3.rst +++ b/poky/documentation/migration-guides/release-notes-4.3.rst @@ -94,7 +94,7 @@ New Features / Enhancements in 4.3 API to access the kernel tracefs directory (from meta-openembedded) - `libxmlb <https://github.com/hughsie/libxmlb>`__: A library to help create - and query binary XML blobs (from meta-oe) + and query binary XML blobs (from meta-oe) - ``musl-legacy-error``: glibc ``error()`` API implementation still needed by a few packages. diff --git a/poky/documentation/overview-manual/concepts.rst b/poky/documentation/overview-manual/concepts.rst index d335c2fcdd..62f2327a7e 100644 --- a/poky/documentation/overview-manual/concepts.rst +++ b/poky/documentation/overview-manual/concepts.rst @@ -37,7 +37,7 @@ to each data source as a layer. For information on layers, see the ":ref:`dev-manual/layers:understanding and creating layers`" section of the Yocto Project Development Tasks Manual. -Following are some brief details on these core components. For +Here are some brief details on these core components. For additional information on how these components interact during a build, see the ":ref:`overview-manual/concepts:openembedded build system concepts`" @@ -1321,7 +1321,7 @@ can initialize the environment before using the tools. All the output files for an SDK are written to the ``deploy/sdk`` folder inside the :term:`Build Directory` as shown in the previous figure. Depending on the type of SDK, there are several variables to configure these files. -Here are the variables associated with an extensible SDK: +The variables associated with an extensible SDK are: - :term:`DEPLOY_DIR`: Points to the ``deploy`` directory. @@ -1375,7 +1375,7 @@ This next list, shows the variables associated with a standard SDK: Lists packages that make up the target part of the SDK (i.e. the part built for the target hardware). -- :term:`SDKPATH`: Defines the +- :term:`SDKPATHINSTALL`: Defines the default SDK installation path offered by the installation script. - :term:`SDK_HOST_MANIFEST`: @@ -2238,7 +2238,7 @@ which is integrating ``sayhello`` in our root file system: #. Add ``sayhello`` to :term:`IMAGE_INSTALL` to integrate it into the root file system -The following are the contents of ``libhello/Makefile``:: +The contents of ``libhello/Makefile`` are:: LIB=libhello.so @@ -2266,7 +2266,7 @@ The following are the contents of ``libhello/Makefile``:: and ``CFLAGS`` as BitBake will set them as environment variables according to your build configuration. -The following are the contents of ``libhello/hellolib.h``:: +The contents of ``libhello/hellolib.h`` are:: #ifndef HELLOLIB_H #define HELLOLIB_H @@ -2275,7 +2275,7 @@ The following are the contents of ``libhello/hellolib.h``:: #endif -The following are the contents of ``libhello/hellolib.c``:: +The contents of ``libhello/hellolib.c`` are:: #include <stdio.h> @@ -2283,7 +2283,7 @@ The following are the contents of ``libhello/hellolib.c``:: puts("Hello from a Yocto demo \n"); } -The following are the contents of ``sayhello/Makefile``:: +The contents of ``sayhello/Makefile`` are:: EXEC=sayhello LDFLAGS += -lhello @@ -2296,7 +2296,7 @@ The following are the contents of ``sayhello/Makefile``:: clean: rm -rf $(EXEC) *.o -The following are the contents of ``sayhello/sayhello.c``:: +The contents of ``sayhello/sayhello.c`` are:: #include <hellolib.h> @@ -2305,7 +2305,7 @@ The following are the contents of ``sayhello/sayhello.c``:: return 0; } -The following are the contents of ``libhello_0.1.bb``:: +The contents of ``libhello_0.1.bb`` are:: SUMMARY = "Hello demo library" DESCRIPTION = "Hello shared library used in Yocto demo" @@ -2328,7 +2328,7 @@ The following are the contents of ``libhello_0.1.bb``:: oe_soinstall ${PN}.so.${PV} ${D}${libdir} } -The following are the contents of ``sayhello_0.1.bb``:: +The contents of ``sayhello_0.1.bb`` are:: SUMMARY = "SayHello demo" DESCRIPTION = "SayHello project used in Yocto demo" diff --git a/poky/documentation/overview-manual/development-environment.rst b/poky/documentation/overview-manual/development-environment.rst index 262d5cb203..d79173ff55 100644 --- a/poky/documentation/overview-manual/development-environment.rst +++ b/poky/documentation/overview-manual/development-environment.rst @@ -131,6 +131,14 @@ are several ways of working in the Yocto Project environment: Toaster and on how to use Toaster in general, see the :doc:`/toaster-manual/index`. +- *Using the VSCode Extension:* You can use the `Yocto Project BitBake + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__ + extension for Visual Studio Code to start your BitBake builds through a + graphical user interface. + + Learn more about the VSCode Extension on the `extension's marketplace page + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__. + Yocto Project Source Repositories ================================= diff --git a/poky/documentation/overview-manual/yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst index d694642af2..4a27e12e01 100644 --- a/poky/documentation/overview-manual/yp-intro.rst +++ b/poky/documentation/overview-manual/yp-intro.rst @@ -340,6 +340,18 @@ the Yocto Project: view information about builds. For information on Toaster, see the :doc:`/toaster-manual/index`. +- *VSCode IDE Extension:* The `Yocto Project BitBake + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__ + extension for Visual Studio Code provides a rich set of features for working + with BitBake recipes. The extension provides syntax highlighting, + hover tips, and completion for BitBake files as well as embedded Python and + Bash languages. Additional views and commands allow you to efficiently + browse, build and edit recipes. It also provides SDK integration for + cross-compiling and debugging through ``devtool``. + + Learn more about the VSCode Extension on the `extension's frontpage + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__. + Production Tools ---------------- @@ -605,6 +617,14 @@ Build Host runs, you have several choices. For information about and how to use Toaster, see the :doc:`/toaster-manual/index`. +- *Using the VSCode Extension:* You can use the `Yocto Project BitBake + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__ + extension for Visual Studio Code to start your BitBake builds through a + graphical user interface. + + Learn more about the VSCode Extension on the `extension's marketplace page + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__ + Reference Embedded Distribution (Poky) ====================================== @@ -717,7 +737,7 @@ workflow: .. image:: figures/YP-flow-diagram.png :width: 100% -Following is a brief summary of the "workflow": +Here is a brief summary of the "workflow": #. Developers specify architecture, policies, patches and configuration details. diff --git a/poky/documentation/profile-manual/usage.rst b/poky/documentation/profile-manual/usage.rst index 6f0b0418e7..2f82137538 100644 --- a/poky/documentation/profile-manual/usage.rst +++ b/poky/documentation/profile-manual/usage.rst @@ -13,7 +13,7 @@ tools. perf ==== -The 'perf' tool is the profiling and tracing tool that comes bundled +The perf tool is the profiling and tracing tool that comes bundled with the Linux kernel. Don't let the fact that it's part of the kernel fool you into thinking @@ -26,22 +26,22 @@ of what's going on. In many ways, perf aims to be a superset of all the tracing and profiling tools available in Linux today, including all the other tools -covered in this HOWTO. The past couple of years have seen perf subsume a +covered in this How-to. The past couple of years have seen perf subsume a lot of the functionality of those other tools and, at the same time, those other tools have removed large portions of their previous functionality and replaced it with calls to the equivalent functionality now implemented by the perf subsystem. Extrapolation suggests that at -some point those other tools will simply become completely redundant and +some point those other tools will become completely redundant and go away; until then, we'll cover those other tools in these pages and in many cases show how the same things can be accomplished in perf and the other tools when it seems useful to do so. The coverage below details some of the most common ways you'll likely want to apply the tool; full documentation can be found either within -the tool itself or in the man pages at +the tool itself or in the manual pages at `perf(1) <https://linux.die.net/man/1/perf>`__. -Perf Setup +perf Setup ---------- For this section, we'll assume you've already performed the basic setup @@ -54,14 +54,14 @@ image built with the following in your ``local.conf`` file:: perf runs on the target system for the most part. You can archive profile data and copy it to the host for analysis, but for the rest of -this document we assume you've ssh'ed to the host and will be running -the perf commands on the target. +this document we assume you're connected to the host through SSH and will be +running the perf commands on the target. -Basic Perf Usage +Basic perf Usage ---------------- The perf tool is pretty much self-documenting. To remind yourself of the -available commands, simply type 'perf', which will show you basic usage +available commands, just type ``perf``, which will show you basic usage along with the available perf subcommands:: root@crownbay:~# perf @@ -97,19 +97,19 @@ along with the available perf subcommands:: Using perf to do Basic Profiling ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -As a simple test case, we'll profile the 'wget' of a fairly large file, +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 -applets in Yocto. :: +can be used in a similar way to the whole host of supported BusyBox +applets in Yocto:: root@crownbay:~# rm linux-2.6.19.2.tar.bz2; \ wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2 The quickest and easiest way to get some basic overall data about what's -going on for a particular workload is to profile it using 'perf stat'. -'perf stat' basically profiles using a few default counters and displays +going on for a particular workload is to profile it using ``perf stat``. +This command basically profiles using a few default counters and displays the summed counts at the end of the run:: root@crownbay:~# perf stat wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2 @@ -131,13 +131,13 @@ the summed counts at the end of the run:: 59.836627620 seconds time elapsed -Many times such a simple-minded test doesn't yield much of -interest, but sometimes it does (see Real-world Yocto bug (slow -loop-mounted write speed)). +Such a simple-minded test doesn't always yield much of interest, but sometimes +it does (see the :yocto_bugs:`Slow write speed on live images with denzil +</show_bug.cgi?id=3049>` bug report). -Also, note that 'perf stat' isn't restricted to a fixed set of counters -- basically any event listed in the output of 'perf list' can be tallied -by 'perf stat'. For example, suppose we wanted to see a summary of all +Also, note that ``perf stat`` isn't restricted to a fixed set of counters +--- basically any event listed in the output of ``perf list`` can be tallied +by ``perf stat``. For example, suppose we wanted to see a summary of all the events related to kernel memory allocation/freeing along with cache hits and misses:: @@ -164,22 +164,22 @@ hits and misses:: 44.831023415 seconds time elapsed -So 'perf stat' gives us a nice easy +As you can see, ``perf stat`` gives us a nice easy way to get a quick overview of what might be happening for a set of events, but normally we'd need a little more detail in order to understand what's going on in a way that we can act on in a useful way. -To dive down into a next level of detail, we can use 'perf record'/'perf -report' which will collect profiling data and present it to use using an -interactive text-based UI (or simply as text if we specify ``--stdio`` to -'perf report'). +To dive down into a next level of detail, we can use ``perf record`` / +``perf report`` which will collect profiling data and present it to use using an +interactive text-based UI (or just as text if we specify ``--stdio`` to +``perf report``). -As our first attempt at profiling this workload, we'll simply run 'perf -record', handing it the workload we want to profile (everything after -'perf record' and any perf options we hand it --- here none, will be +As our first attempt at profiling this workload, we'll just run ``perf +record``, handing it the workload we want to profile (everything after +``perf record`` and any perf options we hand it --- here none, will be executed in a new shell). perf collects samples until the process exits -and records them in a file named 'perf.data' in the current working -directory. :: +and records them in a file named ``perf.data`` in the current working +directory:: root@crownbay:~# perf record wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2 @@ -189,7 +189,7 @@ directory. :: [ perf record: Captured and wrote 0.176 MB perf.data (~7700 samples) ] To see the results in a -'text-based UI' (tui), simply run 'perf report', which will read the +"text-based UI" (tui), just run ``perf report``, which will read the perf.data file in the current working directory and display the results in an interactive UI:: @@ -199,26 +199,26 @@ in an interactive UI:: :align: center :width: 70% -The above screenshot displays a 'flat' profile, one entry for each -'bucket' corresponding to the functions that were profiled during the +The above screenshot displays a "flat" profile, one entry for each +"bucket" corresponding to the functions that were profiled during the profiling run, ordered from the most popular to the least (perf has options to sort in various orders and keys as well as display entries only above a certain threshold and so on --- see the perf documentation -for details). Note that this includes both userspace functions (entries -containing a [.]) and kernel functions accounted to the process (entries -containing a [k]). (perf has command-line modifiers that can be used to -restrict the profiling to kernel or userspace, among others). +for details). Note that this includes both user space functions (entries +containing a ``[.]``) and kernel functions accounted to the process (entries +containing a ``[k]``). perf has command-line modifiers that can be used to +restrict the profiling to kernel or user space, among others. -Notice also that the above report shows an entry for 'busybox', which is -the executable that implements 'wget' in Yocto, but that instead of a +Notice also that the above report shows an entry for ``busybox``, which is +the executable that implements ``wget`` in Yocto, but that instead of a useful function name in that entry, it displays a not-so-friendly hex value instead. The steps below will show how to fix that problem. Before we do that, however, let's try running a different profile, one which shows something a little more interesting. The only difference -between the new profile and the previous one is that we'll add the -g +between the new profile and the previous one is that we'll add the ``-g`` option, which will record not just the address of a sampled function, -but the entire callchain to the sampled function as well:: +but the entire call chain to the sampled function as well:: root@crownbay:~# perf record -g wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2 Connecting to downloads.yoctoproject.org (140.211.169.59:80) @@ -233,45 +233,45 @@ but the entire callchain to the sampled function as well:: :align: center :width: 70% -Using the callgraph view, we can actually see not only which functions +Using the call graph view, we can actually see not only which functions took the most time, but we can also see a summary of how those functions were called and learn something about how the program interacts with the kernel in the process. -Notice that each entry in the above screenshot now contains a '+' on the -left-hand side. This means that we can expand the entry and drill down -into the callchains that feed into that entry. Pressing 'enter' on any -one of them will expand the callchain (you can also press 'E' to expand -them all at the same time or 'C' to collapse them all). +Notice that each entry in the above screenshot now contains a ``+`` on the +left side. This means that we can expand the entry and drill down +into the call chains that feed into that entry. Pressing ``Enter`` on any +one of them will expand the call chain (you can also press ``E`` to expand +them all at the same time or ``C`` to collapse them all). In the screenshot above, we've toggled the ``__copy_to_user_ll()`` entry -and several subnodes all the way down. This lets us see which callchains +and several subnodes all the way down. This lets us see which call chains contributed to the profiled ``__copy_to_user_ll()`` function which contributed 1.77% to the total profile. -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 +As a bit of background explanation for these call chains, 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 +via the network connection (socket) and is passed to the user space +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 has read from the socket -down to wget i.e. a copy-to-user. +down to wget i.e. a ``copy-to-user``. Notice also that here there's also a case where the hex value is -displayed in the callstack, here in the expanded ``sys_clock_gettime()`` -function. Later we'll see it resolve to a userspace function call in -busybox. +displayed in the call stack, here in the expanded ``sys_clock_gettime()`` +function. Later we'll see it resolve to a user space function call in +BusyBox. .. image:: figures/perf-wget-g-copy-from-user-expanded-stripped.png :align: center :width: 70% -The above screenshot shows the other half of the journey for the data - -from the wget program's userspace buffers to disk. To get the buffers to +The above screenshot shows the other half of the journey for the data --- +from the ``wget`` program's user space buffers to disk. To get the buffers to disk, the wget program issues a ``write(2)``, which does a ``copy-from-user`` to the kernel, which then takes care via some circuitous path (probably also present somewhere in the profile data), to get it safely to disk. @@ -281,8 +281,8 @@ 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: +is ``wget``, the executable we're actually interested in is ``busybox``. +Therefore, let's expand the first entry containing BusyBox: .. image:: figures/perf-wget-busybox-expanded-stripped.png :align: center @@ -293,7 +293,7 @@ hex value instead of a symbol as with most of the kernel entries. 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 +``busybox`` binary, which is actually stripped out by the Yocto build system. One way around that is to put the following in your ``local.conf`` file @@ -303,40 +303,39 @@ 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 debugging information 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:: EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile dbg-pkgs" -Additionally, in order to generate the type of debuginfo that perf -understands, we also need to set -:term:`PACKAGE_DEBUG_SPLIT_STYLE` +Additionally, in order to generate the type of debugging information that perf +understands, we also need to set :term:`PACKAGE_DEBUG_SPLIT_STYLE` 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 -``build/tmp/deploy/rpm/*`` on the host system. Find the busybox-dbg-...rpm -file and copy it to the target. For example:: +Once we've done that, we can install the debugging information 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:: [trz@empanada core2]$ scp /home/trz/yocto/crownbay-tracing-dbg/build/tmp/deploy/rpm/core2_32/busybox-dbg-1.20.2-r2.core2_32.rpm root@192.168.1.31: busybox-dbg-1.20.2-r2.core2_32.rpm 100% 1826KB 1.8MB/s 00:01 -Now install the debug rpm on the target:: +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 debugging information is installed, we see that the BusyBox entries now display their functions symbolically: .. image:: figures/perf-wget-busybox-debuginfo.png :align: center :width: 70% -If we expand one of the entries and press 'enter' on a leaf node, we're +If we expand one of the entries and press ``Enter`` on a leaf node, we're presented with a menu of actions we can take to get more information related to that entry: @@ -346,17 +345,17 @@ related to that entry: One of these actions allows us to show a view that displays a busybox-centric view of the profiled functions (in this case we've also -expanded all the nodes using the 'E' key): +expanded all the nodes using the ``E`` key): .. image:: figures/perf-wget-busybox-dso-zoom.png :align: center :width: 70% -Finally, we can see that now that the BusyBox debuginfo is installed, +Finally, we can see that now that the BusyBox debugging information 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 +``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 function: .. image:: figures/perf-wget-g-copy-to-user-expanded-debuginfo.png @@ -365,15 +364,15 @@ function: At the lowest level of detail, we can dive down to the assembly level and see which instructions caused the most overhead in a function. -Pressing 'enter' on the 'udhcpc_main' function, we're again presented +Pressing ``Enter`` on the ``udhcpc_main`` function, we're again presented with a menu: .. image:: figures/perf-wget-busybox-annotate-menu.png :align: center :width: 70% -Selecting 'Annotate udhcpc_main', we get a detailed listing of -percentages by instruction for the udhcpc_main function. From the +Selecting ``Annotate udhcpc_main``, we get a detailed listing of +percentages by instruction for the ``udhcpc_main`` function. From the display, we can see that over 50% of the time spent in this function is taken up by a couple tests and the move of a constant (1) to a register: @@ -382,17 +381,17 @@ taken up by a couple tests and the move of a constant (1) to a register: :width: 70% As a segue into tracing, let's try another profile using a different -counter, something other than the default 'cycles'. +counter, something other than the default ``cycles``. The tracing and profiling infrastructure in Linux has become unified in a way that allows us to use the same tool with a completely different set of counters, not just the standard hardware counters that -traditional tools have had to restrict themselves to (of course the -traditional tools can also make use of the expanded possibilities now +traditional tools have had to restrict themselves to (the +traditional tools can now actually make use of the expanded possibilities now available to them, and in some cases have, as mentioned previously). We can get a list of the available events that can be used to profile a -workload via 'perf list':: +workload via ``perf list``:: root@crownbay:~# perf list @@ -528,14 +527,14 @@ workload via 'perf list':: .. admonition:: Tying it Together These are exactly the same set of events defined by the trace event - subsystem and exposed by ftrace/tracecmd/kernelshark as files in - /sys/kernel/debug/tracing/events, by SystemTap as + subsystem and exposed by ftrace / trace-cmd / KernelShark as files in + ``/sys/kernel/debug/tracing/events``, by SystemTap as kernel.trace("tracepoint_name") and (partially) accessed by LTTng. Only a subset of these would be of interest to us when looking at this workload, so let's choose the most likely subsystems (identified by the -string before the colon in the Tracepoint events) and do a 'perf stat' -run using only those wildcarded subsystems:: +string before the colon in the ``Tracepoint`` events) and do a ``perf stat`` +run using only those subsystem wildcards:: root@crownbay:~# perf stat -e skb:* -e net:* -e napi:* -e sched:* -e workqueue:* -e irq:* -e syscalls:* wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2 Performance counter stats for 'wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2': @@ -607,8 +606,8 @@ and tell perf to do a profile using it as the sampling event:: The screenshot above shows the results of running a profile using sched:sched_switch tracepoint, which shows the relative costs of various -paths to sched_wakeup (note that sched_wakeup is the name of the -tracepoint --- it's actually defined just inside ttwu_do_wakeup(), which +paths to ``sched_wakeup`` (note that ``sched_wakeup`` is the name of the +tracepoint --- it's actually defined just inside ``ttwu_do_wakeup()``, which accounts for the function name actually displayed in the profile: .. code-block:: c @@ -626,15 +625,15 @@ accounts for the function name actually displayed in the profile: } A couple of the more interesting -callchains are expanded and displayed above, basically some network -receive paths that presumably end up waking up wget (busybox) when +call chains are expanded and displayed above, basically some network +receive paths that presumably end up waking up wget (BusyBox) when network data is ready. Note that because tracepoints are normally used for tracing, the default -sampling period for tracepoints is 1 i.e. for tracepoints perf will -sample on every event occurrence (this can be changed using the -c +sampling period for tracepoints is ``1`` i.e. for tracepoints perf will +sample on every event occurrence (this can be changed using the ``-c`` option). This is in contrast to hardware counters such as for example -the default 'cycles' hardware counter used for normal profiling, where +the default ``cycles`` hardware counter used for normal profiling, where sampling periods are much higher (in the thousands) because profiling should have as low an overhead as possible and sampling on every cycle would be prohibitively expensive. @@ -645,10 +644,10 @@ Using perf to do Basic Tracing Profiling is a great tool for solving many problems or for getting a high-level view of what's going on with a workload or across the system. It is however by definition an approximation, as suggested by the most -prominent word associated with it, 'sampling'. On the one hand, it +prominent word associated with it, ``sampling``. On the one hand, it allows a representative picture of what's going on in the system to be -cheaply taken, but on the other hand, that cheapness limits its utility -when that data suggests a need to 'dive down' more deeply to discover +cheaply taken, but alternatively, that cheapness limits its utility +when that data suggests a need to "dive down" more deeply to discover what's really going on. In such cases, the only way to see what's really going on is to be able to look at (or summarize more intelligently) the individual steps that go into the higher-level behavior exposed by the @@ -661,7 +660,7 @@ applicable to our workload:: -e syscalls:sys_enter_read -e syscalls:sys_exit_read -e syscalls:sys_enter_write -e syscalls:sys_exit_write wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2 -We can look at the raw trace output using 'perf script' with no +We can look at the raw trace output using ``perf script`` with no arguments:: root@crownbay:~# perf script @@ -692,7 +691,7 @@ arguments:: This gives us a detailed timestamped sequence of events that occurred within the workload with respect to those events. -In many ways, profiling can be viewed as a subset of tracing - +In many ways, profiling can be viewed as a subset of tracing --- theoretically, if you have a set of trace events that's sufficient to capture all the important aspects of a workload, you can derive any of the results or views that a profiling run can. @@ -712,23 +711,23 @@ an infinite variety of ways. Another way to look at it is that there are only so many ways that the 'primitive' counters can be used on their own to generate interesting output; to get anything more complicated than simple counts requires -some amount of additional logic, which is typically very specific to the +some amount of additional logic, which is typically specific to the problem at hand. For example, if we wanted to make use of a 'counter' that maps to the value of the time difference between when a process was scheduled to run on a processor and the time it actually ran, we wouldn't expect such a counter to exist on its own, but we could derive -one called say 'wakeup_latency' and use it to extract a useful view of +one called say ``wakeup_latency`` and use it to extract a useful view of that metric from trace data. Likewise, we really can't figure out from standard profiling tools how much data every process on the system reads and writes, along with how many of those reads and writes fail completely. If we have sufficient trace data, however, we could with the right tools easily extract and present that information, but we'd need -something other than pre-canned profiling tools to do that. +something other than ready-made profiling tools to do that. Luckily, there is a general-purpose way to handle such needs, called -'programming languages'. Making programming languages easily available +"programming languages". Making programming languages easily available to apply to such problems given the specific format of data is called a -'programming language binding' for that data and language. Perf supports +'programming language binding' for that data and language. perf supports two programming language bindings, one for Python and one for Perl. .. admonition:: Tying it Together @@ -738,21 +737,21 @@ two programming language bindings, one for Python and one for Perl. DProbes dpcc compiler, an ANSI C compiler which targeted a low-level assembly language running on an in-kernel interpreter on the target system. This is exactly analogous to what Sun's DTrace did, except - that DTrace invented its own language for the purpose. Systemtap, + that DTrace invented its own language for the purpose. SystemTap, heavily inspired by DTrace, also created its own one-off language, but rather than running the product on an in-kernel interpreter, created an elaborate compiler-based machinery to translate its language into kernel modules written in C. -Now that we have the trace data in perf.data, we can use 'perf script --g' to generate a skeleton script with handlers for the read/write -entry/exit events we recorded:: +Now that we have the trace data in ``perf.data``, we can use ``perf script +-g`` to generate a skeleton script with handlers for the read / write +entry / exit events we recorded:: root@crownbay:~# perf script -g python generated Python script: perf-script.py -The skeleton script simply creates a Python function for each event type in the -perf.data file. The body of each function simply prints the event name along +The skeleton script just creates a Python function for each event type in the +``perf.data`` file. The body of each function just prints the event name along with its parameters. For example: .. code-block:: python @@ -766,7 +765,7 @@ with its parameters. For example: print "skbaddr=%u, len=%u, name=%s\n" % (skbaddr, len, name), We can run that script directly to print all of the events contained in the -perf.data file:: +``perf.data`` file:: root@crownbay:~# perf script -s perf-script.py @@ -795,8 +794,8 @@ perf.data file:: syscalls__sys_exit_read 1 11624.859944032 1262 wget nr=3, ret=1024 That in itself isn't very useful; after all, we can accomplish pretty much the -same thing by simply running 'perf script' without arguments in the same -directory as the perf.data file. +same thing by just running ``perf script`` without arguments in the same +directory as the ``perf.data`` file. We can however replace the print statements in the generated function bodies with whatever we want, and thereby make it infinitely more @@ -817,8 +816,8 @@ event. For example: Each event handler function in the generated code is modified to do this. For convenience, we define a common function -called inc_counts() that each handler calls; inc_counts() simply tallies -a count for each event using the 'counts' hash, which is a specialized +called ``inc_counts()`` that each handler calls; ``inc_counts()`` just tallies +a count for each event using the ``counts`` hash, which is a specialized hash function that does Perl-like autovivification, a capability that's extremely useful for kinds of multi-level aggregation commonly used in processing traces (see perf's documentation on the Python language @@ -836,7 +835,7 @@ binding for details): Finally, at the end of the trace processing run, we want to print the result of all the per-event tallies. For that, we use the special -'trace_end()' function: +``trace_end()`` function: .. code-block:: python @@ -865,7 +864,7 @@ The end result is a summary of all the events recorded in the trace:: syscalls__sys_exit_write 8990 Note that this is -pretty much exactly the same information we get from 'perf stat', which +pretty much exactly the same information we get from ``perf stat``, which goes a little way to support the idea mentioned previously that given the right kind of trace data, higher-level profiling-type summaries can be derived from it. @@ -877,44 +876,44 @@ System-Wide Tracing and Profiling ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The examples so far have focused on tracing a particular program or -workload --- in other words, every profiling run has specified the program -to profile in the command-line e.g. 'perf record wget ...'. +workload --- that is, every profiling run has specified the program +to profile in the command-line e.g. ``perf record wget ...``. It's also possible, and more interesting in many cases, to run a system-wide profile or trace while running the workload in a separate shell. -To do system-wide profiling or tracing, you typically use the -a flag to -'perf record'. +To do system-wide profiling or tracing, you typically use the ``-a`` flag to +``perf record``. To demonstrate this, open up one window and start the profile using the --a flag (press Ctrl-C to stop tracing):: +``-a`` flag (press ``Ctrl-C`` to stop tracing):: root@crownbay:~# perf record -g -a ^C[ perf record: Woken up 6 times to write data ] [ perf record: Captured and wrote 1.400 MB perf.data (~61172 samples) ] -In another window, run the wget test:: +In another window, run the ``wget`` test:: root@crownbay:~# wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2 Connecting to downloads.yoctoproject.org (140.211.169.59:80) linux-2.6.19.2.tar.b 100% \|*******************************\| 41727k 0:00:00 ETA -Here we see entries not only for our wget load, but for +Here we see entries not only for our ``wget`` load, but for other processes running on the system as well: .. image:: figures/perf-systemwide.png :align: center :width: 70% -In the snapshot above, we can see callchains that originate in libc, and -a callchain from Xorg that demonstrates that we're using a proprietary X -driver in userspace (notice the presence of 'PVR' and some other -unresolvable symbols in the expanded Xorg callchain). +In the snapshot above, we can see call chains that originate in ``libc``, and +a call chain from ``Xorg`` that demonstrates that we're using a proprietary X +driver in user space (notice the presence of ``PVR`` and some other +unresolvable symbols in the expanded ``Xorg`` call chain). -Note also that we have both kernel and userspace entries in the above -snapshot. We can also tell perf to focus on userspace but providing a -modifier, in this case 'u', to the 'cycles' hardware counter when we +Note also that we have both kernel and user space entries in the above +snapshot. We can also tell perf to focus on user space but providing a +modifier, in this case ``u``, to the ``cycles`` hardware counter when we record a profile:: root@crownbay:~# perf record -g -a -e cycles:u @@ -925,25 +924,25 @@ record a profile:: :align: center :width: 70% -Notice in the screenshot above, we see only userspace entries ([.]) +Notice in the screenshot above, we see only user space entries (``[.]``) -Finally, we can press 'enter' on a leaf node and select the 'Zoom into -DSO' menu item to show only entries associated with a specific DSO. In -the screenshot below, we've zoomed into the 'libc' DSO which shows all -the entries associated with the libc-xxx.so DSO. +Finally, we can press ``Enter`` on a leaf node and select the ``Zoom into +DSO`` menu item to show only entries associated with a specific DSO. In +the screenshot below, we've zoomed into the ``libc`` DSO which shows all +the entries associated with the ``libc-xxx.so`` DSO. .. image:: figures/perf-systemwide-libc.png :align: center :width: 70% -We can also use the system-wide -a switch to do system-wide tracing. +We can also use the system-wide ``-a`` switch to do system-wide tracing. Here we'll trace a couple of scheduler events:: root@crownbay:~# perf record -a -e sched:sched_switch -e sched:sched_wakeup ^C[ perf record: Woken up 38 times to write data ] [ perf record: Captured and wrote 9.780 MB perf.data (~427299 samples) ] -We can look at the raw output using 'perf script' with no arguments:: +We can look at the raw output using ``perf script`` with no arguments:: root@crownbay:~# perf script @@ -961,11 +960,11 @@ We can look at the raw output using 'perf script' with no arguments:: Filtering ^^^^^^^^^ -Notice that there are a lot of events that don't really have anything to -do with what we're interested in, namely events that schedule 'perf' +Notice that there are many events that don't really have anything to +do with what we're interested in, namely events that schedule ``perf`` itself in and out or that wake perf up. We can get rid of those by using -the '--filter' option --- for each event we specify using -e, we can add a ---filter after that to filter out trace events that contain fields with +the ``--filter`` option --- for each event we specify using ``-e``, we can add a +``--filter`` after that to filter out trace events that contain fields with specific values:: root@crownbay:~# perf record -a -e sched:sched_switch --filter 'next_comm != perf && prev_comm != perf' -e sched:sched_wakeup --filter 'comm != perf' @@ -991,16 +990,16 @@ specific values:: kworker/0:3 1209 [000] 7932.326214: sched_switch: prev_comm=kworker/0:3 prev_pid=1209 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120 In this case, we've filtered out all events that have -'perf' in their 'comm' or 'comm_prev' or 'comm_next' fields. Notice that +``perf`` in their ``comm``, ``comm_prev`` or ``comm_next`` fields. Notice that there are still events recorded for perf, but notice that those events -don't have values of 'perf' for the filtered fields. To completely +don't have values of ``perf`` for the filtered fields. To completely filter out anything from perf will require a bit more work, but for the purpose of demonstrating how to use filters, it's close enough. .. admonition:: Tying it Together These are exactly the same set of event filters defined by the trace - event subsystem. See the ftrace/tracecmd/kernelshark section for more + event subsystem. See the ftrace / trace-cmd / KernelShark section for more discussion about these event filters. .. admonition:: Tying it Together @@ -1010,14 +1009,14 @@ purpose of demonstrating how to use filters, it's close enough. indispensable part of the perf design as it relates to tracing. kernel-based event filters provide a mechanism to precisely throttle the event stream that appears in user space, where it makes sense to - provide bindings to real programming languages for postprocessing the + provide bindings to real programming languages for post-processing the event stream. This architecture allows for the intelligent and flexible partitioning of processing between the kernel and user space. Contrast this with other tools such as SystemTap, which does all of its processing in the kernel and as such requires a special project-defined language in order to accommodate that design, or - LTTng, where everything is sent to userspace and as such requires a - super-efficient kernel-to-userspace transport mechanism in order to + LTTng, where everything is sent to user space and as such requires a + super-efficient kernel-to-user space transport mechanism in order to function properly. While perf certainly can benefit from for instance advances in the design of the transport, it doesn't fundamentally depend on them. Basically, if you find that your perf tracing @@ -1028,9 +1027,9 @@ Using Dynamic Tracepoints ~~~~~~~~~~~~~~~~~~~~~~~~~ perf isn't restricted to the fixed set of static tracepoints listed by -'perf list'. Users can also add their own 'dynamic' tracepoints anywhere -in the kernel. For instance, suppose we want to define our own -tracepoint on do_fork(). We can do that using the 'perf probe' perf +``perf list``. Users can also add their own "dynamic" tracepoints anywhere +in the kernel. For example, suppose we want to define our own +tracepoint on ``do_fork()``. We can do that using the ``perf probe`` perf subcommand:: root@crownbay:~# perf probe do_fork @@ -1042,8 +1041,8 @@ subcommand:: perf record -e probe:do_fork -aR sleep 1 Adding a new tracepoint via -'perf probe' results in an event with all the expected files and format -in /sys/kernel/debug/tracing/events, just the same as for static +``perf probe`` results in an event with all the expected files and format +in ``/sys/kernel/debug/tracing/events``, just the same as for static tracepoints (as discussed in more detail in the trace events subsystem section:: @@ -1076,7 +1075,7 @@ existence:: probe:do_fork (on do_fork) probe:schedule (on schedule) -Let's record system-wide ('sleep 30' is a +Let's record system-wide (``sleep 30`` is a trick for recording system-wide but basically do nothing and then wake up after 30 seconds):: @@ -1084,7 +1083,7 @@ up after 30 seconds):: [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.087 MB perf.data (~3812 samples) ] -Using 'perf script' we can see each do_fork event that fired:: +Using ``perf script`` we can see each ``do_fork`` event that fired:: root@crownbay:~# perf script @@ -1125,8 +1124,8 @@ Using 'perf script' we can see each do_fork event that fired:: matchbox-deskto 1311 [001] 34237.114106: do_fork: (c1028460) gaku 1312 [000] 34237.202388: do_fork: (c1028460) -And using 'perf report' on the same file, we can see the -callgraphs from starting a few programs during those 30 seconds: +And using ``perf report`` on the same file, we can see the +call graphs from starting a few programs during those 30 seconds: .. image:: figures/perf-probe-do_fork-profile.png :align: center @@ -1141,57 +1140,57 @@ callgraphs from starting a few programs during those 30 seconds: .. admonition:: Tying it Together - Dynamic tracepoints are implemented under the covers by kprobes and - uprobes. kprobes and uprobes are also used by and in fact are the + Dynamic tracepoints are implemented under the covers by Kprobes and + Uprobes. Kprobes and Uprobes are also used by and in fact are the main focus of SystemTap. -Perf Documentation +perf Documentation ------------------ -Online versions of the man pages for the commands discussed in this +Online versions of the manual pages for the commands discussed in this section can be found here: -- The `'perf stat' manpage <https://linux.die.net/man/1/perf-stat>`__. +- The `'perf stat' manual page <https://linux.die.net/man/1/perf-stat>`__. - The `'perf record' - manpage <https://linux.die.net/man/1/perf-record>`__. + manual page <https://linux.die.net/man/1/perf-record>`__. - The `'perf report' - manpage <https://linux.die.net/man/1/perf-report>`__. + manual page <https://linux.die.net/man/1/perf-report>`__. -- The `'perf probe' manpage <https://linux.die.net/man/1/perf-probe>`__. +- The `'perf probe' manual page <https://linux.die.net/man/1/perf-probe>`__. - The `'perf script' - manpage <https://linux.die.net/man/1/perf-script>`__. + manual page <https://linux.die.net/man/1/perf-script>`__. - Documentation on using the `'perf script' Python binding <https://linux.die.net/man/1/perf-script-python>`__. -- The top-level `perf(1) manpage <https://linux.die.net/man/1/perf>`__. +- The top-level `perf(1) manual page <https://linux.die.net/man/1/perf>`__. -Normally, you should be able to invoke the man pages via perf itself -e.g. 'perf help' or 'perf help record'. +Normally, you should be able to open the manual pages via perf itself +e.g. ``perf help`` or ``perf help record``. -To have the perf manpages installed on your target, modify your +To have the perf manual pages installed on your target, modify your configuration as follows:: IMAGE_INSTALL:append = " perf perf-doc" DISTRO_FEATURES:append = " api-documentation" -The man pages in text form, along with some other files, such as a set -of examples, can also be found in the 'perf' directory of the kernel tree:: +The manual pages in text form, along with some other files, such as a set +of examples, can also be found in the ``perf`` directory of the kernel tree:: tools/perf/Documentation There's also a nice perf tutorial on the perf -wiki that goes into more detail than we do here in certain areas: `Perf +wiki that goes into more detail than we do here in certain areas: `perf Tutorial <https://perf.wiki.kernel.org/index.php/Tutorial>`__ ftrace ====== -'ftrace' literally refers to the 'ftrace function tracer' but in reality -this encompasses a number of related tracers along with the +"ftrace" literally refers to the "ftrace function tracer" but in reality +this encompasses several related tracers along with the infrastructure that they all make use of. ftrace Setup @@ -1200,20 +1199,20 @@ ftrace Setup For this section, we'll assume you've already performed the basic setup outlined in the ":ref:`profile-manual/intro:General Setup`" section. -ftrace, trace-cmd, and kernelshark run on the target system, and are +ftrace, trace-cmd, and KernelShark run on the target system, and are ready to go out-of-the-box --- no additional setup is necessary. For the -rest of this section we assume you've ssh'ed to the host and will be -running ftrace on the target. kernelshark is a GUI application and if -you use the '-X' option to ssh you can have the kernelshark GUI run on +rest of this section we assume you're connected to the host through SSH and +will be running ftrace on the target. KernelShark is a GUI application and if +you use the ``-X`` option to ``ssh`` you can have the KernelShark GUI run on the target but display remotely on the host if you want. Basic ftrace usage ------------------ -'ftrace' essentially refers to everything included in the /tracing +"ftrace" essentially refers to everything included in the ``/tracing`` directory of the mounted debugfs filesystem (Yocto follows the standard -convention and mounts it at /sys/kernel/debug). Here's a listing of all -the files found in /sys/kernel/debug/tracing on a Yocto system:: +convention and mounts it at ``/sys/kernel/debug``). All the files found in +``/sys/kernel/debug/tracing`` on a Yocto system are:: root@sugarbay:/sys/kernel/debug/tracing# ls README kprobe_events trace @@ -1229,7 +1228,7 @@ the files found in /sys/kernel/debug/tracing on a Yocto system:: free_buffer set_graph_function The files listed above are used for various purposes -- some relate directly to the tracers themselves, others are used to set +--- some relate directly to the tracers themselves, others are used to set tracing options, and yet others actually contain the tracing output when a tracer is in effect. Some of the functions can be guessed from their names, others need explanation; in any case, we'll cover some of the @@ -1238,30 +1237,30 @@ the ftrace documentation. We'll start by looking at some of the available built-in tracers. -cat'ing the 'available_tracers' file lists the set of available tracers:: +The ``available_tracers`` file lists the set of available tracers:: root@sugarbay:/sys/kernel/debug/tracing# cat available_tracers blk function_graph function nop -The 'current_tracer' file contains the tracer currently in effect:: +The ``current_tracer`` file contains the tracer currently in effect:: root@sugarbay:/sys/kernel/debug/tracing# cat current_tracer nop -The above listing of current_tracer shows that the -'nop' tracer is in effect, which is just another way of saying that +The above listing of ``current_tracer`` shows that the +``nop`` tracer is in effect, which is just another way of saying that there's actually no tracer currently in effect. -echo'ing one of the available_tracers into current_tracer makes the +Writing one of the available tracers into ``current_tracer`` makes the specified tracer the current tracer:: root@sugarbay:/sys/kernel/debug/tracing# echo function > current_tracer root@sugarbay:/sys/kernel/debug/tracing# cat current_tracer function -The above sets the current tracer to be the 'function tracer'. This tracer +The above sets the current tracer to be the ``function`` tracer. This tracer traces every function call in the kernel and makes it available as the -contents of the 'trace' file. Reading the 'trace' file lists the +contents of the ``trace`` file. Reading the ``trace`` file lists the currently buffered function calls that have been traced by the function tracer:: @@ -1308,7 +1307,7 @@ tracer:: . Each line in the trace above shows what was happening in the kernel on a given -cpu, to the level of detail of function calls. Each entry shows the function +CPU, to the level of detail of function calls. Each entry shows the function called, followed by its caller (after the arrow). The function tracer gives you an extremely detailed idea of what the @@ -1318,11 +1317,11 @@ great way to learn about how the kernel code works in a dynamic sense. .. admonition:: Tying it Together The ftrace function tracer is also available from within perf, as the - ftrace:function tracepoint. + ``ftrace:function`` tracepoint. It is a little more difficult to follow the call chains than it needs to be --- luckily there's a variant of the function tracer that displays the -callchains explicitly, called the 'function_graph' tracer:: +call chains explicitly, called the ``function_graph`` tracer:: root@sugarbay:/sys/kernel/debug/tracing# echo function_graph > current_tracer root@sugarbay:/sys/kernel/debug/tracing# cat trace | less @@ -1437,11 +1436,11 @@ callchains explicitly, called the 'function_graph' tracer:: 3) + 13.784 us | } 3) | sys_ioctl() { -As you can see, the function_graph display is much easier +As you can see, the ``function_graph`` display is much easier to follow. Also note that in addition to the function calls and associated braces, other events such as scheduler events are displayed in context. In fact, you can freely include any tracepoint available in -the trace events subsystem described in the next section by simply +the trace events subsystem described in the next section by just enabling those events, and they'll appear in context in the function graph display. Quite a powerful tool for understanding kernel dynamics. @@ -1455,9 +1454,9 @@ The 'trace events' Subsystem ---------------------------- One especially important directory contained within the -/sys/kernel/debug/tracing directory is the 'events' subdirectory, which +``/sys/kernel/debug/tracing`` directory is the ``events`` subdirectory, which contains representations of every tracepoint in the system. Listing out -the contents of the 'events' subdirectory, we see mainly another set of +the contents of the ``events`` subdirectory, we see mainly another set of subdirectories:: root@sugarbay:/sys/kernel/debug/tracing# cd events @@ -1505,9 +1504,9 @@ subdirectories:: drwxr-xr-x 26 root root 0 Nov 14 23:19 writeback Each one of these subdirectories -corresponds to a 'subsystem' and contains yet again more subdirectories, +corresponds to a "subsystem" and contains yet again more subdirectories, each one of those finally corresponding to a tracepoint. For example, -here are the contents of the 'kmem' subsystem:: +here are the contents of the ``kmem`` subsystem:: root@sugarbay:/sys/kernel/debug/tracing/events# cd kmem root@sugarbay:/sys/kernel/debug/tracing/events/kmem# ls -al @@ -1529,7 +1528,7 @@ here are the contents of the 'kmem' subsystem:: drwxr-xr-x 2 root root 0 Nov 14 23:19 mm_page_pcpu_drain Let's see what's inside the subdirectory for a -specific tracepoint, in this case the one for kmalloc:: +specific tracepoint, in this case the one for ``kmalloc``:: root@sugarbay:/sys/kernel/debug/tracing/events/kmem# cd kmalloc root@sugarbay:/sys/kernel/debug/tracing/events/kmem/kmalloc# ls -al @@ -1540,12 +1539,12 @@ specific tracepoint, in this case the one for kmalloc:: -r--r--r-- 1 root root 0 Nov 14 23:19 format -r--r--r-- 1 root root 0 Nov 14 23:19 id -The 'format' file for the +The ``format`` file for the tracepoint describes the event in memory, which is used by the various tracing tools that now make use of these tracepoint to parse the event -and make sense of it, along with a 'print fmt' field that allows tools -like ftrace to display the event as text. Here's what the format of the -kmalloc event looks like:: +and make sense of it, along with a ``print fmt`` field that allows tools +like ftrace to display the event as text. The format of the +``kmalloc`` event looks like:: root@sugarbay:/sys/kernel/debug/tracing/events/kmem/kmalloc# cat format name: kmalloc @@ -1580,11 +1579,11 @@ kmalloc event looks like:: long)(( gfp_t)0x08u), "GFP_MOVABLE"}, {(unsigned long)(( gfp_t)0), "GFP_NOTRACK"}, {(unsigned long)(( gfp_t)0x400000u), "GFP_NO_KSWAPD"}, {(unsigned long)(( gfp_t)0x800000u), "GFP_OTHER_NODE"} ) : "GFP_NOWAIT" -The 'enable' file +The ``enable`` file in the tracepoint directory is what allows the user (or tools such as -trace-cmd) to actually turn the tracepoint on and off. When enabled, the -corresponding tracepoint will start appearing in the ftrace 'trace' file -described previously. For example, this turns on the kmalloc tracepoint:: +``trace-cmd``) to actually turn the tracepoint on and off. When enabled, the +corresponding tracepoint will start appearing in the ftrace ``trace`` file +described previously. For example, this turns on the ``kmalloc`` tracepoint:: root@sugarbay:/sys/kernel/debug/tracing/events/kmem/kmalloc# echo 1 > enable @@ -1596,8 +1595,8 @@ 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 'trace' file, we see nothing -but the kmalloc events we just turned on:: +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 # tracer: nop @@ -1643,17 +1642,17 @@ but the kmalloc events we just turned on:: <idle>-0 [000] ..s3 18156.400660: kmalloc: call_site=ffffffff81619b36 ptr=ffff88006d554800 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_ATOMIC matchbox-termin-1361 [001] ...1 18156.552800: kmalloc: call_site=ffffffff81614050 ptr=ffff88006db34800 bytes_req=576 bytes_alloc=1024 gfp_flags=GFP_KERNEL|GFP_REPEAT -To again disable the kmalloc event, we need to send 0 to the enable file:: +To again disable the ``kmalloc`` event, we need to send ``0`` to the ``enable`` file:: root@sugarbay:/sys/kernel/debug/tracing/events/kmem/kmalloc# echo 0 > enable You can enable any number of events or complete subsystems (by -using the 'enable' file in the subsystem directory) and get an +using the ``enable`` file in the subsystem directory) and get an arbitrarily fine-grained idea of what's going on in the system by enabling as many of the appropriate tracepoints as applicable. -A number of the tools described in this HOWTO do just that, including -trace-cmd and kernelshark in the next section. +Several tools described in this How-to do just that, including +``trace-cmd`` and KernelShark in the next section. .. admonition:: Tying it Together @@ -1661,41 +1660,40 @@ trace-cmd and kernelshark in the next section. ftrace, but by many of the other tools covered in this document and they form a central point of integration for the various tracers available in Linux. They form a central part of the instrumentation - for the following tools: perf, lttng, ftrace, blktrace and SystemTap + for the following tools: perf, LTTng, ftrace, blktrace and SystemTap .. admonition:: Tying it Together Eventually all the special-purpose tracers currently available in - /sys/kernel/debug/tracing will be removed and replaced with - equivalent tracers based on the 'trace events' subsystem. + ``/sys/kernel/debug/tracing`` will be removed and replaced with + equivalent tracers based on the "trace events" subsystem. -trace-cmd/kernelshark ---------------------- +trace-cmd / KernelShark +----------------------- -trace-cmd is essentially an extensive command-line 'wrapper' interface +trace-cmd is essentially an extensive command-line "wrapper" interface that hides the details of all the individual files in -/sys/kernel/debug/tracing, allowing users to specify specific particular -events within the /sys/kernel/debug/tracing/events/ subdirectory and to +``/sys/kernel/debug/tracing``, allowing users to specify specific particular +events within the ``/sys/kernel/debug/tracing/events/`` subdirectory and to collect traces and avoid having to deal with those details directly. -As yet another layer on top of that, kernelshark provides a GUI that +As yet another layer on top of that, KernelShark provides a GUI that allows users to start and stop traces and specify sets of events using an intuitive interface, and view the output as both trace events and as -a per-CPU graphical display. It directly uses 'trace-cmd' as the +a per-CPU graphical display. It directly uses trace-cmd as the plumbing that accomplishes all that underneath the covers (and actually displays the trace-cmd command it uses, as we'll see). -To start a trace using kernelshark, first start kernelshark:: +To start a trace using KernelShark, first start this tool:: root@sugarbay:~# kernelshark -Then bring up the 'Capture' dialog by -choosing from the kernelshark menu:: +Then open up the ``Capture`` dialog by choosing from the KernelShark menu:: Capture | Record That will display the following dialog, which allows you to choose one or more -events (or even one or more complete subsystems) to trace: +events (or even entire subsystems) to trace: .. image:: figures/kernelshark-choose-events.png :align: center @@ -1703,41 +1701,41 @@ events (or even one or more complete subsystems) to trace: Note that these are exactly the same sets of events described in the previous trace events subsystem section, and in fact is where trace-cmd -gets them for kernelshark. +gets them for KernelShark. In the above screenshot, we've decided to explore the graphics subsystem a bit and so have chosen to trace all the tracepoints contained within -the 'i915' and 'drm' subsystems. +the ``i915`` and ``drm`` subsystems. -After doing that, we can start and stop the trace using the 'Run' and -'Stop' button on the lower right corner of the dialog (the same button +After doing that, we can start and stop the trace using the ``Run`` and +``Stop`` button on the lower right corner of the dialog (the same button will turn into the 'Stop' button after the trace has started): .. image:: figures/kernelshark-output-display.png :align: center :width: 70% -Notice that the right-hand pane shows the exact trace-cmd command-line +Notice that the right pane shows the exact trace-cmd command-line that's used to run the trace, along with the results of the trace-cmd run. -Once the 'Stop' button is pressed, the graphical view magically fills up -with a colorful per-cpu display of the trace data, along with the +Once the ``Stop`` button is pressed, the graphical view magically fills up +with a colorful per-CPU display of the trace data, along with the detailed event listing below that: .. image:: figures/kernelshark-i915-display.png :align: center :width: 70% -Here's another example, this time a display resulting from tracing 'all -events': +Here's another example, this time a display resulting from tracing ``all +events``: .. image:: figures/kernelshark-all.png :align: center :width: 70% The tool is pretty self-explanatory, but for more detailed information -on navigating through the data, see the `kernelshark +on navigating through the data, see the `KernelShark website <https://kernelshark.org/Documentation.html>`__. ftrace Documentation @@ -1753,41 +1751,41 @@ Documentation directory:: Documentation/trace/events.txt -There is a nice series of articles on using ftrace and trace-cmd at LWN: +A nice series of articles on using ftrace and trace-cmd are available at LWN: -- `Debugging the kernel using Ftrace - part +- `Debugging the kernel using ftrace - part 1 <https://lwn.net/Articles/365835/>`__ -- `Debugging the kernel using Ftrace - part +- `Debugging the kernel using ftrace - part 2 <https://lwn.net/Articles/366796/>`__ -- `Secrets of the Ftrace function +- `Secrets of the ftrace function tracer <https://lwn.net/Articles/370423/>`__ - `trace-cmd: A front-end for - Ftrace <https://lwn.net/Articles/410200/>`__ + ftrace <https://lwn.net/Articles/410200/>`__ See also `KernelShark's documentation <https://kernelshark.org/Documentation.html>`__ for further usage details. -An amusing yet useful README (a tracing mini-HOWTO) can be found in +An amusing yet useful README (a tracing mini-How-to) can be found in ``/sys/kernel/debug/tracing/README``. -systemtap +SystemTap ========= SystemTap is a system-wide script-based tracing and profiling tool. SystemTap scripts are C-like programs that are executed in the kernel to -gather/print/aggregate data extracted from the context they end up being -invoked under. +gather / print / aggregate data extracted from the context they end up being +called under. For example, this probe from the `SystemTap -tutorial <https://sourceware.org/systemtap/tutorial/>`__ simply prints a -line every time any process on the system open()s a file. For each line, +tutorial <https://sourceware.org/systemtap/tutorial/>`__ just prints a +line every time any process on the system runs ``open()`` on a file. For each line, it prints the executable name of the program that opened the file, along -with its PID, and the name of the file it opened (or tried to open), -which it extracts from the open syscall's argstr. +with its PID, and the name of the file it opened (or tried to open), which it +extracts from the argument string (``argstr``) of the ``open`` system call. .. code-block:: none @@ -1802,48 +1800,48 @@ which it extracts from the open syscall's argstr. } Normally, to execute this -probe, you'd simply install systemtap on the system you want to probe, +probe, you'd just install SystemTap on the system you want to probe, and directly run the probe on that system e.g. assuming the name of the -file containing the above text is trace_open.stp:: +file containing the above text is ``trace_open.stp``:: # stap trace_open.stp -What systemtap does under the covers to run this probe is 1) parse and -convert the probe to an equivalent 'C' form, 2) compile the 'C' form +What SystemTap does under the covers to run this probe is 1) parse and +convert the probe to an equivalent "C" form, 2) compile the "C" form into a kernel module, 3) insert the module into the kernel, which arms it, and 4) collect the data generated by the probe and display it to the user. -In order to accomplish steps 1 and 2, the 'stap' program needs access to +In order to accomplish steps 1 and 2, the ``stap`` program needs access to the kernel build system that produced the kernel that the probed system -is running. In the case of a typical embedded system (the 'target'), the +is running. In the case of a typical embedded system (the "target"), the kernel build system unfortunately isn't typically part of the image -running on the target. It is normally available on the 'host' system +running on the target. It is normally available on the "host" system that produced the target image however; in such cases, steps 1 and 2 are executed on the host system, and steps 3 and 4 are executed on the -target system, using only the systemtap 'runtime'. +target system, using only the SystemTap "runtime". -The systemtap support in Yocto assumes that only steps 3 and 4 are run +The SystemTap support in Yocto assumes that only steps 3 and 4 are run on the target; it is possible to do everything on the target, but this section assumes only the typical embedded use-case. -So basically what you need to do in order to run a systemtap script on +Therefore, what you need to do in order to run a SystemTap script on the target is to 1) on the host system, compile the probe into a kernel module that makes sense to the target, 2) copy the module onto the target system and 3) insert the module into the target kernel, which arms it, and 4) collect the data generated by the probe and display it to the user. -systemtap Setup +SystemTap Setup --------------- -Those are a lot of steps and a lot of details, but fortunately Yocto -includes a script called 'crosstap' that will take care of those -details, allowing you to simply execute a systemtap script on the remote +Those are many steps and details, but fortunately Yocto +includes a script called ``crosstap`` that will take care of those +details, allowing you to just execute a SystemTap script on the remote target, with arguments if necessary. In order to do this from a remote host, however, you need to have access -to the build for the image you booted. The 'crosstap' script provides +to the build for the image you booted. The ``crosstap`` script provides details on how to do this if you run the script on the host without having done a build:: @@ -1852,29 +1850,35 @@ having done a build:: Error: No target kernel build found. Did you forget to create a local build of your image? - 'crosstap' requires a local sdk build of the target system - (or a build that includes 'tools-profile') in order to build - kernel modules that can probe the target system. - - Practically speaking, that means you need to do the following: - - If you're running a pre-built image, download the release - and/or BSP tarballs used to build the image. - - If you're working from git sources, just clone the metadata - and BSP layers needed to build the image you'll be booting. - - Make sure you're properly set up to build a new image (see - the BSP README and/or the widely available basic documentation - that discusses how to build images). - - Build an -sdk version of the image e.g.: - $ bitbake core-image-sato-sdk - OR - - Build a non-sdk image but include the profiling tools: - [ edit local.conf and add 'tools-profile' to the end of - the EXTRA_IMAGE_FEATURES variable ] - $ bitbake core-image-sato +'crosstap' requires a local SDK build of the target system +(or a build that includes 'tools-profile') in order to build +kernel modules that can probe the target system. + +Practically speaking, that means you need to do the following: + +- If you're running a pre-built image, download the release + and/or BSP tarballs used to build the image. + +- If you're working from git sources, just clone the metadata + and BSP layers needed to build the image you'll be booting. + +- Make sure you're properly set up to build a new image (see + the BSP README and/or the widely available basic documentation + that discusses how to build images). + +- Build an ``-sdk`` version of the image e.g.:: + + $ bitbake core-image-sato-sdk + +- Or build a non-SDK image but include the profiling tools + (edit ``local.conf`` and add ``tools-profile`` to the end of + :term:``EXTRA_IMAGE_FEATURES`` variable):: + + $ bitbake core-image-sato Once you've build the image on the host system, you're ready to - boot it (or the equivalent pre-built image) and use 'crosstap' - to probe it (you need to source the environment as usual first): + boot it (or the equivalent pre-built image) and use ``crosstap`` + to probe it (you need to source the environment as usual first):: $ source oe-init-build-env $ cd ~/my/systemtap/scripts @@ -1882,29 +1886,27 @@ having done a build:: .. note:: - SystemTap, which uses 'crosstap', assumes you can establish an ssh + SystemTap, which uses ``crosstap``, assumes you can establish an SSH connection to the remote target. Please refer to the crosstap wiki - page for details on verifying ssh connections at - . Also, the ability to ssh into the target system is not enabled by - default in \*-minimal images. + page for details on verifying SSH connections. Also, the ability to SSH + into the target system is not enabled by default in ``*-minimal`` images. -So essentially what you need to -do is build an SDK image or image with 'tools-profile' as detailed in -the ":ref:`profile-manual/intro:General Setup`" section of this -manual, and boot the resulting target image. +Therefore, what you need to do is build an SDK image or image with +``tools-profile`` as detailed in the ":ref:`profile-manual/intro:General Setup`" +section of this manual, and boot the resulting target image. .. note:: If you have a :term:`Build Directory` containing multiple machines, you need - to have the :term:`MACHINE` you're connecting to selected in local.conf, and + to have the :term:`MACHINE` you're connecting to selected in ``local.conf``, and the kernel in that machine's :term:`Build Directory` must match the kernel on - the booted system exactly, or you'll get the above 'crosstap' message - when you try to invoke a script. + the booted system exactly, or you'll get the above ``crosstap`` message + when you try to call a script. Running a Script on a Target ---------------------------- -Once you've done that, you should be able to run a systemtap script on +Once you've done that, you should be able to run a SystemTap script on the target:: $ cd /path/to/yocto @@ -1922,8 +1924,8 @@ the target:: 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:: +Once you've done that, you can ``cd`` to whatever +directory contains your scripts and use ``crosstap`` to run the script:: $ cd /path/to/my/systemap/script $ crosstap root@192.168.7.2 trace_open.stp @@ -1933,13 +1935,12 @@ If you get an error connecting to the target e.g.:: $ crosstap root@192.168.7.2 trace_open.stp error establishing ssh connection on remote 'root@192.168.7.2' -Try ssh'ing to the target and see what happens:: +Try connecting to the target through SSH and see what happens:: $ ssh root@192.168.7.2 -A lot of the time, connection -problems are due specifying a wrong IP address or having a 'host key -verification error'. +Connection problems are often due specifying a wrong IP address or having a ``host key +verification error``. If everything worked as planned, you should see something like this (enter the password when prompted, or press enter if it's set up to use @@ -1952,7 +1953,7 @@ no password): matchbox-termin(1036) open ("/tmp/vte3FS2LW", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) matchbox-termin(1036) open ("/tmp/vteJMC7LW", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) -systemtap Documentation +SystemTap Documentation ----------------------- The SystemTap language reference can be found here: `SystemTap Language @@ -1965,7 +1966,7 @@ page <https://sourceware.org/systemtap/documentation.html>`__ Sysprof ======= -Sysprof is a very easy to use system-wide profiler that consists of a +Sysprof is an easy to use system-wide profiler that consists of a single window with three panes and a few buttons which allow you to start, stop, and view the profile from one place. @@ -1975,18 +1976,18 @@ Sysprof Setup For this section, we'll assume you've already performed the basic setup outlined in the ":ref:`profile-manual/intro:General Setup`" section. -Sysprof is a GUI-based application that runs on the target system. For -the rest of this document we assume you've ssh'ed to the host and will -be running Sysprof on the target (you can use the '-X' option to ssh and +Sysprof is a GUI-based application that runs on the target system. For the rest +of this document we assume you're connected to the host through SSH and will be +running Sysprof on the target (you can use the ``-X`` option to ``ssh`` and have the Sysprof GUI run on the target but display remotely on the host if you want). Basic Sysprof Usage ------------------- -To start profiling the system, you simply press the 'Start' button. To +To start profiling the system, you just press the ``Start`` button. To stop profiling and to start viewing the profile data in one easy step, -press the 'Profile' button. +press the ``Profile`` button. Once you've pressed the profile button, the three panes will fill up with profiling data: @@ -1998,11 +1999,11 @@ with profiling data: The left pane shows a list of functions and processes. Selecting one of those expands that function in the right pane, showing all its callees. Note that this caller-oriented display is essentially the inverse of -perf's default callee-oriented callchain display. +perf's default callee-oriented call chain display. In the screenshot above, we're focusing on ``__copy_to_user_ll()`` and -looking up the callchain we can see that one of the callers of -``__copy_to_user_ll`` is sys_read() and the complete callpath between them. +looking up the call chain we can see that one of the callers of +``__copy_to_user_ll`` is ``sys_read()`` and the complete call path between them. Notice that this is essentially a portion of the same information we saw in the perf display shown in the perf section of this page. @@ -2011,7 +2012,7 @@ in the perf display shown in the perf section of this page. :width: 70% Similarly, the above is a snapshot of the Sysprof display of a -copy-from-user callchain. +``copy-from-user`` call chain. Finally, looking at the third Sysprof pane in the lower left, we can see a list of all the callers of a particular function selected in the top @@ -2027,18 +2028,17 @@ to the selected function, and so on. .. admonition:: Tying it Together - If you like sysprof's 'caller-oriented' display, you may be able to - approximate it in other tools as well. For example, 'perf report' has - the -g (--call-graph) option that you can experiment with; one of the - options is 'caller' for an inverted caller-based callgraph display. + If you like Sysprof's ``caller-oriented`` display, you may be able to + approximate it in other tools as well. For example, ``perf report`` has + the ``-g`` (``--call-graph``) option that you can experiment with; one of the + options is ``caller`` for an inverted caller-based call graph display. Sysprof Documentation --------------------- There doesn't seem to be any documentation for Sysprof, but maybe that's -because it's pretty self-explanatory. The Sysprof website, however, is -here: `Sysprof, System-wide Performance Profiler for -Linux <http://sysprof.com/>`__ +because it's pretty self-explanatory. The Sysprof website, however, is here: +`Sysprof, System-wide Performance Profiler for Linux <http://sysprof.com/>`__ LTTng (Linux Trace Toolkit, next generation) ============================================ @@ -2048,20 +2048,20 @@ LTTng Setup For this section, we'll assume you've already performed the basic setup outlined in the ":ref:`profile-manual/intro:General Setup`" section. -LTTng is run on the target system by ssh'ing to it. +LTTng is run on the target system by connecting to it through SSH. Collecting and Viewing Traces ----------------------------- Once you've applied the above commits and built and booted your image -(you need to build the core-image-sato-sdk image or use one of the other +(you need to build the ``core-image-sato-sdk`` image or use one of the other methods described in the ":ref:`profile-manual/intro:General Setup`" section), you're ready to start tracing. Collecting and viewing a trace on the target (inside a shell) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -First, from the host, ssh to the target:: +First, from the host, connect to the target through SSH:: $ ssh -l root 192.168.1.47 The authenticity of host '192.168.1.47 (192.168.1.47)' can't be established. @@ -2139,30 +2139,30 @@ You can now view the trace in text form on the target:: You can now safely destroy the trace session (note that this doesn't delete the trace --- it's still there in -~/lttng-traces):: +``~/lttng-traces``):: root@crownbay:~# lttng destroy Session auto-20121015-232120 destroyed at /home/root Note that the trace is saved in a directory of the same name as returned by -'lttng create', under the ~/lttng-traces directory (note that you can change this by -supplying your own name to 'lttng create'):: +``lttng create``, under the ``~/lttng-traces`` directory (note that you can change this by +supplying your own name to ``lttng create``):: root@crownbay:~# ls -al ~/lttng-traces drwxrwx--- 3 root root 1024 Oct 15 23:21 . drwxr-xr-x 5 root root 1024 Oct 15 23:57 .. drwxrwx--- 3 root root 1024 Oct 15 23:21 auto-20121015-232120 -Collecting and viewing a userspace trace on the target (inside a shell) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Collecting and viewing a user space trace on the target (inside a shell) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -For LTTng userspace tracing, you need to have a properly instrumented -userspace program. For this example, we'll use the 'hello' test program -generated by the lttng-ust build. +For LTTng user space tracing, you need to have a properly instrumented +user space program. For this example, we'll use the ``hello`` test program +generated by the ``lttng-ust`` build. -The 'hello' test program isn't installed on the root filesystem by the lttng-ust -build, so we need to copy it over manually. First cd into the build -directory that contains the hello executable:: +The ``hello`` test program isn't installed on the root filesystem by the ``lttng-ust`` +build, so we need to copy it over manually. First ``cd`` into the build +directory that contains the ``hello`` executable:: $ cd build/tmp/work/core2_32-poky-linux/lttng-ust/2.0.5-r0/git/tests/hello/.libs @@ -2170,10 +2170,10 @@ Copy that over to the target machine:: $ scp hello root@192.168.1.20: -You now have the instrumented lttng 'hello world' test program on the +You now have the instrumented LTTng "hello world" test program on the target, ready to test. -First, from the host, ssh to the target:: +First, from the host, connect to the target through SSH:: $ ssh -l root 192.168.1.47 The authenticity of host '192.168.1.47 (192.168.1.47)' can't be established. @@ -2188,7 +2188,7 @@ Once on the target, use these steps to create a trace:: Session auto-20190303-021943 created. Traces will be written in /home/root/lttng-traces/auto-20190303-021943 -Enable the events you want to trace (in this case all userspace events):: +Enable the events you want to trace (in this case all user space events):: root@crownbay:~# lttng enable-event --userspace --all All UST events are enabled in channel channel0 @@ -2198,7 +2198,7 @@ Start the trace:: root@crownbay:~# lttng start Tracing started for session auto-20190303-021943 -Run the instrumented hello world program:: +Run the instrumented "hello world" program:: root@crownbay:~# ./hello Hello, World! @@ -2222,7 +2222,7 @@ You can now view the trace in text form on the target:: . You can now safely destroy the trace session (note that this doesn't delete the -trace --- it's still there in ~/lttng-traces):: +trace --- it's still there in ``~/lttng-traces``):: root@crownbay:~# lttng destroy Session auto-20190303-021943 destroyed at /home/root @@ -2260,27 +2260,27 @@ the entire blktrace and blkparse pipeline on the target, or you can run blktrace in 'listen' mode on the target and have blktrace and blkparse collect and analyze the data on the host (see the ":ref:`profile-manual/usage:Using blktrace Remotely`" section -below). For the rest of this section we assume you've ssh'ed to the host and -will be running blkrace on the target. +below). For the rest of this section we assume you've to the host through SSH +and will be running blktrace on the target. Basic blktrace Usage -------------------- -To record a trace, simply run the 'blktrace' command, giving it the name +To record a trace, just run the ``blktrace`` command, giving it the name of the block device you want to trace activity on:: root@crownbay:~# blktrace /dev/sdc -In another shell, execute a workload you want to trace. :: +In another shell, execute a workload you want to trace:: root@crownbay:/media/sdc# rm linux-2.6.19.2.tar.bz2; wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2; sync Connecting to downloads.yoctoproject.org (140.211.169.59:80) linux-2.6.19.2.tar.b 100% \|*******************************\| 41727k 0:00:00 ETA -Press Ctrl-C in the blktrace shell to stop the trace. It +Press ``Ctrl-C`` in the blktrace shell to stop the trace. It will display how many events were logged, along with the per-cpu file -sizes (blktrace records traces in per-cpu kernel buffers and simply -dumps them to userspace for blkparse to merge and sort later). :: +sizes (blktrace records traces in per-cpu kernel buffers and just +dumps them to user space for blkparse to merge and sort later):: ^C=== sdc === CPU 0: 7082 events, 332 KiB data @@ -2296,7 +2296,7 @@ with the device name as the first part of the filename:: -rw-r--r-- 1 root root 339938 Oct 27 22:40 sdc.blktrace.0 -rw-r--r-- 1 root root 75753 Oct 27 22:40 sdc.blktrace.1 -To view the trace events, simply invoke 'blkparse' in the directory +To view the trace events, just call ``blkparse`` in the directory containing the trace files, giving it the device name that forms the first part of the filenames:: @@ -2388,15 +2388,15 @@ first part of the filenames:: The report shows each event that was found in the blktrace data, along with a summary of the overall block I/O traffic during the run. You can look at the -`blkparse <https://linux.die.net/man/1/blkparse>`__ manpage to learn the +`blkparse <https://linux.die.net/man/1/blkparse>`__ manual page to learn the meaning of each field displayed in the trace listing. Live Mode ~~~~~~~~~ blktrace and blkparse are designed from the ground up to be able to -operate together in a 'pipe mode' where the stdout of blktrace can be -fed directly into the stdin of blkparse:: +operate together in a "pipe mode" where the standard output of blktrace can be +fed directly into the standard input of blkparse:: root@crownbay:~# blktrace /dev/sdc -o - | blkparse -i - @@ -2441,13 +2441,13 @@ On the host system, you should see this:: server: connection from 192.168.1.43 -In another shell, execute a workload you want to trace. :: +In another shell, execute a workload you want to trace:: root@crownbay:/media/sdc# rm linux-2.6.19.2.tar.bz2; wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2; sync Connecting to downloads.yoctoproject.org (140.211.169.59:80) linux-2.6.19.2.tar.b 100% \|*******************************\| 41727k 0:00:00 ETA -When it's done, do a Ctrl-C on the target system to stop the +When it's done, do a ``Ctrl-C`` on the target system to stop the trace:: ^C=== sdc === @@ -2465,14 +2465,14 @@ just ended:: Total: 11800 events (dropped 0), 554 KiB data The blktrace instance on the host will -save the target output inside a hostname-timestamp directory:: +save the target output inside a ``<hostname>-<timestamp>`` directory:: $ ls -al drwxr-xr-x 10 root root 1024 Oct 28 02:40 . drwxr-sr-x 4 root root 1024 Oct 26 18:24 .. drwxr-xr-x 2 root root 1024 Oct 28 02:40 192.168.1.43-2012-10-28-02:40:56 -cd into that directory to see the output files:: +``cd`` into that directory to see the output files:: $ ls -l -rw-r--r-- 1 root root 369193 Oct 28 02:44 sdc.blktrace.0 @@ -2537,16 +2537,16 @@ Tracing Block I/O via 'ftrace' It's also possible to trace block I/O using only :ref:`profile-manual/usage:The 'trace events' Subsystem`, which can be useful for casual tracing if you don't want to bother dealing with the -userspace tools. +user space tools. -To enable tracing for a given device, use /sys/block/xxx/trace/enable, -where xxx is the device name. This for example enables tracing for -/dev/sdc:: +To enable tracing for a given device, use ``/sys/block/xxx/trace/enable``, +where ``xxx`` is the device name. This for example enables tracing for +``/dev/sdc``:: root@crownbay:/sys/kernel/debug/tracing# echo 1 > /sys/block/sdc/trace/enable Once you've selected the device(s) you want -to trace, selecting the 'blk' tracer will turn the blk tracer on:: +to trace, selecting the ``blk`` tracer will turn the blk tracer on:: root@crownbay:/sys/kernel/debug/tracing# cat available_tracers blk function_graph function nop @@ -2557,7 +2557,7 @@ Execute the workload you're interested in:: root@crownbay:/sys/kernel/debug/tracing# cat /media/sdc/testfile.txt -And look at the output (note here that we're using 'trace_pipe' instead of +And look at the output (note here that we're using ``trace_pipe`` instead of trace to capture this trace --- this allows us to wait around on the pipe for data to appear):: @@ -2585,7 +2585,7 @@ And this turns off tracing for the specified device:: blktrace Documentation ---------------------- -Online versions of the man pages for the commands discussed in this +Online versions of the manual pages for the commands discussed in this section can be found here: - https://linux.die.net/man/8/blktrace @@ -2594,8 +2594,8 @@ section can be found here: - https://linux.die.net/man/8/btrace -The above manpages, along with manpages for the other blktrace utilities -(btt, blkiomon, etc) can be found in the /doc directory of the blktrace -tools git repo:: +The above manual pages, along with manuals for the other blktrace utilities +(``btt``, ``blkiomon``, etc) can be found in the ``/doc`` directory of the blktrace +tools git repository:: $ git clone git://git.kernel.dk/blktrace.git diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst index a8afe9f2dc..7b4ce2c67d 100644 --- a/poky/documentation/ref-manual/classes.rst +++ b/poky/documentation/ref-manual/classes.rst @@ -392,7 +392,7 @@ and BusyBox. It could have been called "kconfig" too. ``compress_doc`` ================ -Enables compression for man pages and info pages. This class is intended +Enables compression for manual and info pages. This class is intended to be inherited globally. The default compression mechanism is gz (gzip) but you can select an alternative mechanism by setting the :term:`DOC_COMPRESS` variable. @@ -664,7 +664,7 @@ information about using :ref:`ref-classes-devshell`. The :ref:`ref-classes-devupstream` class uses :term:`BBCLASSEXTEND` to add a variant of the recipe that fetches from an alternative URI (e.g. Git) instead of a -tarball. Following is an example:: +tarball. Here is an example:: BBCLASSEXTEND = "devupstream:target" SRC_URI:class-devupstream = "git://git.example.com/example;branch=main" @@ -1217,8 +1217,8 @@ Please keep in mind that the QA checks are meant to detect real or potential problems in the packaged output. So exercise caution when disabling these checks. -Here are the tests you can list with the :term:`WARN_QA` and -:term:`ERROR_QA` variables: +The tests you can list with the :term:`WARN_QA` and +:term:`ERROR_QA` variables are: - ``already-stripped:`` Checks that produced binaries have not already been stripped prior to the build system extracting debug @@ -1538,16 +1538,6 @@ Here are the tests you can list with the :term:`WARN_QA` and automatically get these versions. Consequently, you should only need to explicitly add dependencies to binary driver recipes. -.. _ref-classes-insserv: - -``insserv`` -=========== - -The :ref:`ref-classes-insserv` class uses the ``insserv`` utility to update the order -of symbolic links in ``/etc/rc?.d/`` within an image based on -dependencies specified by LSB headers in the ``init.d`` scripts -themselves. - .. _ref-classes-kernel: ``kernel`` @@ -3210,7 +3200,7 @@ The :ref:`ref-classes-uboot-config` class provides support for U-Boot configurat a machine. Specify the machine in your recipe as follows:: UBOOT_CONFIG ??= <default> - UBOOT_CONFIG[foo] = "config,images" + UBOOT_CONFIG[foo] = "config,images,binary" You can also specify the machine using this method:: @@ -3227,7 +3217,7 @@ information. The :ref:`ref-classes-uboot-sign` class provides support for U-Boot verified boot. It is intended to be inherited from U-Boot recipes. -Here are variables used by this class: +The variables used by this class are: - :term:`SPL_MKIMAGE_DTCOPTS`: DTC options for U-Boot ``mkimage`` when building the FIT image. diff --git a/poky/documentation/ref-manual/devtool-reference.rst b/poky/documentation/ref-manual/devtool-reference.rst index e167f58092..9319addc3c 100644 --- a/poky/documentation/ref-manual/devtool-reference.rst +++ b/poky/documentation/ref-manual/devtool-reference.rst @@ -378,7 +378,7 @@ command:: Unless you provide a specific recipe name on the command line, the command checks all recipes in all configured layers. -Following is a partial example table that reports on all the recipes:: +Here is a partial example table that reports on all the recipes:: $ devtool check-upgrade-status ... @@ -598,7 +598,7 @@ The ``devtool status`` command has no command-line options:: $ devtool status -Following is sample output after using +Here is sample output after using :ref:`devtool add <ref-manual/devtool-reference:adding a new recipe to the workspace layer>` to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory:: diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst index a3a15506c3..bab284bbfd 100644 --- a/poky/documentation/ref-manual/faq.rst +++ b/poky/documentation/ref-manual/faq.rst @@ -90,7 +90,7 @@ HTTPS requests and direct them to the ``http://`` sources mirror. You can use ``file://`` URLs to point to local directories or network shares as well. -Here are other options:: +Another option is to set:: BB_NO_NETWORK = "1" @@ -106,7 +106,7 @@ This statement limits the build system to pulling source from the :term:`PREMIRRORS` only. Again, this technique is useful for reproducing builds. -Here is another technique:: +Here is yet another technique:: BB_GENERATE_MIRROR_TARBALLS = "1" @@ -135,7 +135,7 @@ Most source fetching by the OpenEmbedded build system is done by single user or can be in ``/usr/local/etc/wgetrc`` as a global user file. -Following is the applicable code for setting various proxy types in the +Here is the applicable code for setting various proxy types in the ``.wgetrc`` file. By default, these settings are disabled with comments. To use them, remove the comments:: diff --git a/poky/documentation/ref-manual/features.rst b/poky/documentation/ref-manual/features.rst index dd14339bc2..96e79d608a 100644 --- a/poky/documentation/ref-manual/features.rst +++ b/poky/documentation/ref-manual/features.rst @@ -268,7 +268,7 @@ you can add several different predefined packages such as development utilities or packages with debug information needed to investigate application problems or profile applications. -Here are the image features available for all images: +The image features available for all images are: - *allow-empty-password:* Allows Dropbear and OpenSSH to accept logins from accounts having an empty password string. diff --git a/poky/documentation/ref-manual/images.rst b/poky/documentation/ref-manual/images.rst index 0f6d6bdb3f..c45f9104a9 100644 --- a/poky/documentation/ref-manual/images.rst +++ b/poky/documentation/ref-manual/images.rst @@ -32,7 +32,7 @@ that contain image recipe files:: $ ls meta*/recipes*/images/*.bb -Following is a list of supported recipes: +Here is a list of supported recipes: - ``build-appliance-image``: An example virtual machine that contains all the pieces required to run builds using the build system as well diff --git a/poky/documentation/ref-manual/release-process.rst b/poky/documentation/ref-manual/release-process.rst index c861feaa9d..920794679d 100644 --- a/poky/documentation/ref-manual/release-process.rst +++ b/poky/documentation/ref-manual/release-process.rst @@ -14,7 +14,7 @@ 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 +Here are examples of some major YP releases with their codenames also shown. See the ":ref:`ref-manual/release-process:major release codenames`" section for information on codenames used with major releases. @@ -29,8 +29,8 @@ major holidays in various geographies. The Yocto project delivers minor (point) releases on an unscheduled basis and are usually driven by the accumulation of enough significant -fixes or enhancements to the associated major release. Following are -some example past point releases: +fixes or enhancements to the associated major release. +Some example past point releases are: - 4.1.3 - 4.0.8 @@ -175,7 +175,7 @@ consists of the following pieces: piece of software. The test allows the packages to be run within a target image. -- ``oe-selftest``: Tests combination BitBake invocations. These tests +- ``oe-selftest``: Tests combinations of BitBake invocations. These tests operate outside the OpenEmbedded build system itself. The ``oe-selftest`` can run all tests by default or can run selected tests or test suites. diff --git a/poky/documentation/ref-manual/resources.rst b/poky/documentation/ref-manual/resources.rst index 8c3726e83b..8e54ac87c9 100644 --- a/poky/documentation/ref-manual/resources.rst +++ b/poky/documentation/ref-manual/resources.rst @@ -169,6 +169,11 @@ Here is a list of resources you might find helpful: the :term:`OpenEmbedded Build System`, which uses BitBake, that reports build information. +- `Yocto Project BitBake extension for VSCode + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__: + This extension provides a rich feature set when working with BitBake recipes + within the Visual Studio Code IDE. + - :yocto_wiki:`FAQ </FAQ>`: A list of commonly asked questions and their answers. diff --git a/poky/documentation/ref-manual/structure.rst b/poky/documentation/ref-manual/structure.rst index f1b11ad69b..acadd5efa3 100644 --- a/poky/documentation/ref-manual/structure.rst +++ b/poky/documentation/ref-manual/structure.rst @@ -537,7 +537,7 @@ recipe-specific :term:`WORKDIR` directories. Thus, the This directory holds information that BitBake uses for accounting purposes to track what tasks have run and when they have run. The directory is sub-divided by architecture, package name, and version. -Following is an example:: +Here is an example:: stamps/all-poky-linux/distcc-config/1.0-r0.do_build-2fdd....2do diff --git a/poky/documentation/ref-manual/system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst index 9dee24a1fa..bcca42e36e 100644 --- a/poky/documentation/ref-manual/system-requirements.rst +++ b/poky/documentation/ref-manual/system-requirements.rst @@ -168,8 +168,8 @@ with a supported Ubuntu or Debian Linux distribution:: Here are the packages needed to build Project documentation manuals:: - $ sudo apt install make python3-pip inkscape texlive-latex-extra - &PIP3_HOST_PACKAGES_DOC; + $ sudo apt install git make inkscape texlive-latex-extra + $ sudo apt install sphinx python3-saneyaml python3-sphinx-rtd-theme Fedora Packages --------------- @@ -181,7 +181,7 @@ with a supported Fedora Linux distribution:: Here are the packages needed to build Project documentation manuals:: - $ sudo dnf install make python3-pip which inkscape texlive-fncychap + $ sudo dnf install git make python3-pip which inkscape texlive-fncychap &PIP3_HOST_PACKAGES_DOC; openSUSE Packages @@ -194,7 +194,7 @@ with a supported openSUSE distribution:: Here are the packages needed to build Project documentation manuals:: - $ sudo zypper install make python3-pip which inkscape texlive-fncychap + $ sudo zypper install git make python3-pip which inkscape texlive-fncychap &PIP3_HOST_PACKAGES_DOC; @@ -221,7 +221,7 @@ with a supported AlmaLinux distribution:: Here are the packages needed to build Project documentation manuals:: - $ sudo dnf install make python3-pip which inkscape texlive-fncychap + $ sudo dnf install git make python3-pip which inkscape texlive-fncychap &PIP3_HOST_PACKAGES_DOC; .. _system-requirements-buildtools: diff --git a/poky/documentation/ref-manual/tasks.rst b/poky/documentation/ref-manual/tasks.rst index 0db960b22f..c28cd7a94a 100644 --- a/poky/documentation/ref-manual/tasks.rst +++ b/poky/documentation/ref-manual/tasks.rst @@ -470,9 +470,29 @@ You can run this task using BitBake as follows:: $ bitbake -c cleanall recipe -Typically, you would not normally use the :ref:`ref-tasks-cleanall` task. Do so only -if you want to start fresh with the :ref:`ref-tasks-fetch` -task. +You should never use the :ref:`ref-tasks-cleanall` task in a normal +scenario. If you want to start fresh with the :ref:`ref-tasks-fetch` task, +use instead:: + + $ bitbake -f -c fetch recipe + +.. note:: + + The reason to prefer ``bitbake -f -c fetch`` is that the + :ref:`ref-tasks-cleanall` task would break in some cases, such as:: + + $ bitbake -c fetch recipe + $ bitbake -c cleanall recipe-native + $ bitbake -c unpack recipe + + because after step 1 there is a stamp file for the + :ref:`ref-tasks-fetch` task of ``recipe``, and it won't be removed at + step 2 because step 2 uses a different work directory. So the unpack task + at step 3 will try to extract the downloaded archive and fail as it has + been deleted in step 2. + + Note that this also applies to BitBake from concurrent processes when a + shared download directory (:term:`DL_DIR`) is setup. .. _ref-tasks-cleansstate: @@ -496,6 +516,18 @@ scratch is guaranteed. .. note:: + Using :ref:`ref-tasks-cleansstate` with a shared :term:`SSTATE_DIR` is + not recommended because it could trigger an error during the build of a + separate BitBake instance. This is because the builds check sstate "up + front" but download the files later, so it if is deleted in the + meantime, it will cause an error but not a total failure as it will + rebuild it. + + The reliable and preferred way to force a new build is to use ``bitbake + -f`` instead. + +.. note:: + The :ref:`ref-tasks-cleansstate` task cannot remove sstate from a remote sstate mirror. If you need to build a target from scratch using remote mirrors, use the "-f" option as follows:: diff --git a/poky/documentation/ref-manual/terms.rst b/poky/documentation/ref-manual/terms.rst index 31ddeae009..ad9c46c339 100644 --- a/poky/documentation/ref-manual/terms.rst +++ b/poky/documentation/ref-manual/terms.rst @@ -4,7 +4,7 @@ Yocto Project Terms ******************* -Following is a list of terms and definitions users new to the Yocto Project +Here is a list of terms and definitions users new to the Yocto Project development environment might find helpful. While some of these terms are universal, the list includes them just in case: @@ -67,7 +67,7 @@ universal, the list includes them just in case: :term:`TOPDIR` variable points to the :term:`Build Directory`. You have a lot of flexibility when creating the :term:`Build Directory`. - Following are some examples that show how to create the directory. The + Here are some examples that show how to create the directory. The examples assume your :term:`Source Directory` is named ``poky``: - Create the :term:`Build Directory` inside your Source Directory and let diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst index b394d31099..7ae61ad0ff 100644 --- a/poky/documentation/ref-manual/variables.rst +++ b/poky/documentation/ref-manual/variables.rst @@ -311,7 +311,7 @@ system and gives an overview of their function and contents. :term:`BB_ALLOWED_NETWORKS` Specifies a space-delimited list of hosts that the fetcher is allowed - to use to obtain the required source code. Following are + to use to obtain the required source code. Here are considerations surrounding this variable: - This host list is only used if :term:`BB_NO_NETWORK` is either not set @@ -2292,7 +2292,7 @@ system and gives an overview of their function and contents. :term:`DOC_COMPRESS` When inheriting the :ref:`ref-classes-compress_doc` class, this variable sets the compression policy used when the - OpenEmbedded build system compresses man pages and info pages. By + OpenEmbedded build system compresses manual and info pages. By default, the compression method used is gz (gzip). Other policies available are xz and bz2. @@ -3234,6 +3234,14 @@ system and gives an overview of their function and contents. GROUPADD_PARAM:${PN} = "-r netdev" + More than one group can be added by separating each set of different + groups' parameters with a semicolon. + + Here is an example adding multiple groups from the ``useradd-example.bb`` + file in the ``meta-skeleton`` layer:: + + GROUPADD_PARAM:${PN} = "-g 880 group1; -g 890 group2" + For information on the standard Linux shell command ``groupadd``, see https://linux.die.net/man/8/groupadd. @@ -6557,7 +6565,7 @@ system and gives an overview of their function and contents. The :term:`PREFERRED_PROVIDER` variable is set with the name (:term:`PN`) of the recipe you prefer to provide "virtual/kernel". - Following are more examples:: + Here are more examples:: PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86" PREFERRED_PROVIDER_virtual/libgl ?= "mesa" @@ -6742,11 +6750,11 @@ system and gives an overview of their function and contents. .. note:: - A corresponding mechanism for virtual runtime dependencies - (packages) exists. However, the mechanism does not depend on any - special functionality beyond ordinary variable assignments. For - example, ``VIRTUAL-RUNTIME_dev_manager`` refers to the package of - the component that manages the ``/dev`` directory. + A corresponding mechanism for virtual runtime dependencies (packages) + exists. However, the mechanism does not depend on any special + functionality beyond ordinary variable assignments. For example, + :term:`VIRTUAL-RUNTIME_dev_manager <VIRTUAL-RUNTIME>` refers to the + package of the component that manages the ``/dev`` directory. Setting the "preferred provider" for runtime dependencies is as simple as using the following assignment in a configuration file:: @@ -7612,6 +7620,10 @@ system and gives an overview of their function and contents. configuration will not take effect. :term:`SDKPATH` + Defines the path used to collect the SDK components and build the + installer. + + :term:`SDKPATHINSTALL` Defines the path offered to the user for installation of the SDK that is generated by the OpenEmbedded build system. The path appears as the default location for installing the SDK when you run the SDK's @@ -7621,7 +7633,7 @@ system and gives an overview of their function and contents. :term:`SDKTARGETSYSROOT` The full path to the sysroot used for cross-compilation within an SDK as it will be when installed into the default - :term:`SDKPATH`. + :term:`SDKPATHINSTALL`. :term:`SECTION` The section in which packages should be categorized. Package @@ -7913,6 +7925,11 @@ system and gives an overview of their function and contents. image), compared to just using the :ref:`ref-classes-create-spdx` class with no option. + :term:`SPDX_NAMESPACE_PREFIX` + This option could be used in order to change the prefix of ``spdxDocument`` + and the prefix of ``documentNamespace``. It is set by default to + ``http://spdx.org/spdxdoc``. + :term:`SPDX_PRETTY` This option makes the SPDX output more human-readable, using identation and newlines, instead of the default output in a @@ -9383,23 +9400,30 @@ system and gives an overview of their function and contents. See the machine include files in the :term:`Source Directory` for these features. - :term:`UBOOT_CONFIG` - Configures the :term:`UBOOT_MACHINE` and can - also define :term:`IMAGE_FSTYPES` for individual - cases. - - Following is an example from the ``meta-fsl-arm`` layer. :: - - UBOOT_CONFIG ??= "sd" - UBOOT_CONFIG[sd] = "mx6qsabreauto_config,sdcard" - UBOOT_CONFIG[eimnor] = "mx6qsabreauto_eimnor_config" - UBOOT_CONFIG[nand] = "mx6qsabreauto_nand_config,ubifs" - UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config" + :term:`UBOOT_BINARY` + Specifies the name of the binary build by U-Boot. - In this example, "sd" is selected as the configuration of the possible four for the - :term:`UBOOT_MACHINE`. The "sd" configuration defines - "mx6qsabreauto_config" as the value for :term:`UBOOT_MACHINE`, while the - "sdcard" specifies the :term:`IMAGE_FSTYPES` to use for the U-Boot image. + :term:`UBOOT_CONFIG` + Configures one or more U-Boot configurations to build. Each + configuration can define the :term:`UBOOT_MACHINE` and optionally the + :term:`IMAGE_FSTYPES` and the :term:`UBOOT_BINARY`. + + Here is an example from the ``meta-freescale`` layer. :: + + UBOOT_CONFIG ??= "sdcard-ifc-secure-boot sdcard-ifc sdcard-qspi lpuart qspi secure-boot nor" + UBOOT_CONFIG[nor] = "ls1021atwr_nor_defconfig" + UBOOT_CONFIG[sdcard-ifc] = "ls1021atwr_sdcard_ifc_defconfig,,u-boot-with-spl-pbl.bin" + UBOOT_CONFIG[sdcard-qspi] = "ls1021atwr_sdcard_qspi_defconfig,,u-boot-with-spl-pbl.bin" + UBOOT_CONFIG[lpuart] = "ls1021atwr_nor_lpuart_defconfig" + UBOOT_CONFIG[qspi] = "ls1021atwr_qspi_defconfig" + UBOOT_CONFIG[secure-boot] = "ls1021atwr_nor_SECURE_BOOT_defconfig" + UBOOT_CONFIG[sdcard-ifc-secure-boot] = "ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig,,u-boot-with-spl-pbl.bin" + + In this example, all possible seven configurations are selected. Each + configuration specifies "..._defconfig" as :term:`UBOOT_MACHINE`, and + the "sd..." configurations define an individual name for + :term:`UBOOT_BINARY`. No configuration defines a second parameter for + :term:`IMAGE_FSTYPES` to use for the U-Boot image. For more information on how the :term:`UBOOT_CONFIG` is handled, see the :ref:`ref-classes-uboot-config` class. @@ -9861,6 +9885,33 @@ system and gives an overview of their function and contents. Additionally, you should also set the :term:`USERADD_ERROR_DYNAMIC` variable. + :term:`VIRTUAL-RUNTIME` + :term:`VIRTUAL-RUNTIME` is a commonly used prefix for defining virtual + packages for runtime usage, typically for use in :term:`RDEPENDS` + or in image definitions. + + An example is ``VIRTUAL-RUNTIME_base-utils`` that makes it possible + to either use BusyBox based utilities:: + + VIRTUAL-RUNTIME_base-utils = "busybox" + + or their full featured implementations from GNU Coreutils + and other projects:: + + VIRTUAL-RUNTIME_base-utils = "packagegroup-core-base-utils" + + Here are two examples using this virtual runtime package. The + first one is in :yocto_git:`initramfs-framework_1.0.bb + </poky/tree/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb?h=scarthgap>`:: + + RDEPENDS:${PN} += "${VIRTUAL-RUNTIME_base-utils}" + + The second example is in the :yocto_git:`core-image-initramfs-boot + </poky/tree/meta/recipes-core/images/core-image-initramfs-boot.bb?h=scarthgap>` + image definition:: + + PACKAGE_INSTALL = "${INITRAMFS_SCRIPTS} ${VIRTUAL-RUNTIME_base-utils} base-passwd" + :term:`VOLATILE_LOG_DIR` Specifies the persistence of the target's ``/var/log`` directory, which is used to house postinstall target log files. @@ -9922,7 +9973,7 @@ system and gives an overview of their function and contents. With the :term:`WKS_FILE_DEPENDS` variable, you have the possibility to specify a list of additional dependencies (e.g. native tools, bootloaders, and so forth), that are required to build Wic images. - Following is an example:: + Here is an example:: WKS_FILE_DEPENDS = "some-native-tool" diff --git a/poky/documentation/sdk-manual/appendix-obtain.rst b/poky/documentation/sdk-manual/appendix-obtain.rst index ad531cbf24..d06d6ec6b5 100644 --- a/poky/documentation/sdk-manual/appendix-obtain.rst +++ b/poky/documentation/sdk-manual/appendix-obtain.rst @@ -66,7 +66,7 @@ Follow these steps to locate and hand-install the toolchain: poky-glibc-x86_64-core-image-sato-core2-64-qemux86-64-toolchain-&DISTRO;.sh #. *Run the Installer:* Be sure you have execution privileges and run - the installer. Following is an example from the ``Downloads`` + the installer. Here is an example from the ``Downloads`` directory:: $ ~/Downloads/poky-glibc-x86_64-core-image-sato-core2-64-qemux86-64-toolchain-&DISTRO;.sh @@ -165,12 +165,12 @@ build the SDK installer. Follow these steps: variable inside your ``local.conf`` file before building the SDK installer. Doing so ensures that the eventual SDK installation process installs the appropriate library packages - as part of the SDK. Following is an example using ``libc`` + as part of the SDK. Here is an example using ``libc`` static development libraries: TOOLCHAIN_TARGET_TASK:append = " libc-staticdev" #. *Run the Installer:* You can now run the SDK installer from - ``tmp/deploy/sdk`` in the :term:`Build Directory`. Following is an example:: + ``tmp/deploy/sdk`` in the :term:`Build Directory`. Here is an example:: $ cd poky/build/tmp/deploy/sdk $ ./poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh @@ -235,7 +235,7 @@ Follow these steps to extract the root filesystem: This script is located in the top-level directory in which you installed the toolchain (e.g. ``poky_sdk``). - Following is an example based on the toolchain installed in the + Here is an example based on the toolchain installed in the ":ref:`sdk-manual/appendix-obtain:locating pre-built sdk installers`" section:: $ source poky_sdk/environment-setup-core2-64-poky-linux @@ -243,7 +243,7 @@ Follow these steps to extract the root filesystem: #. *Extract the Root Filesystem:* Use the ``runqemu-extract-sdk`` command and provide the root filesystem image. - Following is an example command that extracts the root filesystem + Here is an example command that extracts the root filesystem from a previously built root filesystem image that was downloaded from the :yocto_dl:`Index of Releases </releases/yocto/yocto-&DISTRO;/machines/>`. This command extracts the root filesystem into the ``core2-64-sato`` diff --git a/poky/documentation/sdk-manual/extensible.rst b/poky/documentation/sdk-manual/extensible.rst index 355c6cb0e4..d335e78623 100644 --- a/poky/documentation/sdk-manual/extensible.rst +++ b/poky/documentation/sdk-manual/extensible.rst @@ -74,7 +74,7 @@ Setting up the Extensible SDK environment directly in a Yocto build $ bitbake meta-ide-support $ bitbake -c populate_sysroot gtk+3 # or any other target or native item that the application developer would need - $ bitbake build-sysroots + $ bitbake build-sysroots -c build_native_sysroot && bitbake build-sysroots -c build_target_sysroot Setting up the Extensible SDK from a standalone installer --------------------------------------------------------- @@ -1226,8 +1226,12 @@ In this scenario, the Yocto build tooling, e.g. ``bitbake`` is directly accessible to build additional items, and it can simply be executed directly:: + $ bitbake curl-native + # Add newly built native items to native sysroot + $ bitbake build-sysroots -c build_native_sysroot $ bitbake mesa - $ bitbake build-sysroots + # Add newly built target items to target sysroot + $ bitbake build-sysroots -c build_target_sysroot When using a standalone installer for the Extensible SDK -------------------------------------------------------- diff --git a/poky/documentation/sdk-manual/intro.rst b/poky/documentation/sdk-manual/intro.rst index 49aa921e70..e8fd191dbc 100644 --- a/poky/documentation/sdk-manual/intro.rst +++ b/poky/documentation/sdk-manual/intro.rst @@ -66,7 +66,7 @@ The SDK development environment consists of the following: In summary, the extensible and standard SDK share many features. However, the extensible SDK has powerful development tools to help you -more quickly develop applications. Following is a table that summarizes +more quickly develop applications. Here is a table that summarizes the primary differences between the standard and extensible SDK types when considering which to build: diff --git a/poky/documentation/standards.md b/poky/documentation/standards.md index 9f4771ebd9..e0c0cba83c 100644 --- a/poky/documentation/standards.md +++ b/poky/documentation/standards.md @@ -5,6 +5,21 @@ documentation is created. It is currently a work in progress. +## Automatic style validation + +There is an ongoing effort to automate style validation +through the [Vale](https://vale.sh/). To try it, run: + + $ make stylecheck + +Note that this just applies to text. Therefore, the syntax +conventions described below still apply. + +If you wish to add a new word to an "accept.txt" file +(./styles/config/vocabularies/<Vocab>/accept.txt), +make sure the spelling and capitalization matches +what Wikipedia or the project defining this word uses. + ## Text standards ### Bulleted lists diff --git a/poky/documentation/styles/config/vocabularies/OpenSource/accept.txt b/poky/documentation/styles/config/vocabularies/OpenSource/accept.txt new file mode 100644 index 0000000000..e378fbf79b --- /dev/null +++ b/poky/documentation/styles/config/vocabularies/OpenSource/accept.txt @@ -0,0 +1,20 @@ +autovivification +blkparse +blktrace +callee +debugfs +ftrace +KernelShark +Kprobe +LTTng +perf +profiler +subcommand +subnode +superset +Sysprof +systemd +toolchain +tracepoint +Uprobe +wget diff --git a/poky/documentation/styles/config/vocabularies/Yocto/accept.txt b/poky/documentation/styles/config/vocabularies/Yocto/accept.txt new file mode 100644 index 0000000000..ca622ba412 --- /dev/null +++ b/poky/documentation/styles/config/vocabularies/Yocto/accept.txt @@ -0,0 +1,5 @@ +BitBake +BSP +crosstap +OpenEmbedded +Yocto diff --git a/poky/documentation/toaster-manual/setup-and-use.rst b/poky/documentation/toaster-manual/setup-and-use.rst index c5521edda1..a0c27499ba 100644 --- a/poky/documentation/toaster-manual/setup-and-use.rst +++ b/poky/documentation/toaster-manual/setup-and-use.rst @@ -365,7 +365,7 @@ Perform the following steps to install Toaster: /etc/apache2/conf.d/toaster.conf - Following is a sample Apache configuration for Toaster you can follow: + Here is a sample Apache configuration for Toaster you can follow: .. code-block:: apache @@ -495,7 +495,7 @@ The Toaster web interface allows you to do the following: Toaster Web Interface Videos ---------------------------- -Following are several videos that show how to use the Toaster GUI: +Here are several videos that show how to use the Toaster GUI: - *Build Configuration:* This `video <https://www.youtube.com/watch?v=qYgDZ8YzV6w>`__ overviews and diff --git a/poky/documentation/what-i-wish-id-known.rst b/poky/documentation/what-i-wish-id-known.rst index fe79bc0129..5bc55804f6 100644 --- a/poky/documentation/what-i-wish-id-known.rst +++ b/poky/documentation/what-i-wish-id-known.rst @@ -214,6 +214,13 @@ contact us with other suggestions. OpenEmbedded build system. If you are interested in using this type of interface to create images, see the :doc:`/toaster-manual/index`. + * **Discover the VSCode extension**: The `Yocto Project BitBake + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__ + extension for the Visual Studio Code IDE provides language features and + commands for working with the Yocto Project. If you are interested in using + this extension, visit its `marketplace page + <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__. + * **Have Available the Yocto Project Reference Manual**: Unlike the rest of the Yocto Project manual set, this manual is comprised of material suited for reference rather than procedures. You can get build details, a closer diff --git a/poky/meta-poky/conf/distro/poky.conf b/poky/meta-poky/conf/distro/poky.conf index 7d6eb60cbb..c21ba469fd 100644 --- a/poky/meta-poky/conf/distro/poky.conf +++ b/poky/meta-poky/conf/distro/poky.conf @@ -1,6 +1,6 @@ DISTRO = "poky" DISTRO_NAME = "Poky (Yocto Project Reference Distro)" -DISTRO_VERSION = "4.3.2" +DISTRO_VERSION = "4.3.4" DISTRO_CODENAME = "nanbield" SDK_VENDOR = "-pokysdk" SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${METADATA_REVISION}', 'snapshot')}" diff --git a/poky/meta-selftest/recipes-test/aspell/aspell_0.60.8.bbappend b/poky/meta-selftest/recipes-test/aspell/aspell_%.bbappend index 205720982c..205720982c 100644 --- a/poky/meta-selftest/recipes-test/aspell/aspell_0.60.8.bbappend +++ b/poky/meta-selftest/recipes-test/aspell/aspell_%.bbappend diff --git a/poky/meta-selftest/recipes-test/overlayfs-user/overlayfs-user.bb b/poky/meta-selftest/recipes-test/overlayfs-user/overlayfs-user.bb index 50cba9514b..20f4213a62 100644 --- a/poky/meta-selftest/recipes-test/overlayfs-user/overlayfs-user.bb +++ b/poky/meta-selftest/recipes-test/overlayfs-user/overlayfs-user.bb @@ -18,5 +18,5 @@ do_install() { FILES:${PN} += "\ ${exec_prefix} \ - ${sysconfdir \ + ${sysconfdir} \ " diff --git a/poky/meta/classes-global/sstate.bbclass b/poky/meta/classes-global/sstate.bbclass index 5b27a1f0f9..08e6421093 100644 --- a/poky/meta/classes-global/sstate.bbclass +++ b/poky/meta/classes-global/sstate.bbclass @@ -336,7 +336,7 @@ def sstate_install(ss, d): for lock in locks: bb.utils.unlockfile(lock) -sstate_install[vardepsexclude] += "SSTATE_ALLOW_OVERLAP_FILES STATE_MANMACH SSTATE_MANFILEPREFIX" +sstate_install[vardepsexclude] += "SSTATE_ALLOW_OVERLAP_FILES SSTATE_MANMACH SSTATE_MANFILEPREFIX" sstate_install[vardeps] += "${SSTATEPOSTINSTFUNCS}" def sstate_installpkg(ss, d): @@ -703,7 +703,7 @@ def sstate_package(ss, d): if d.getVar('SSTATE_SKIP_CREATION') == '1': return - sstate_create_package = ['sstate_report_unihash', 'sstate_create_package'] + sstate_create_package = ['sstate_report_unihash', 'sstate_create_pkgdirs', 'sstate_create_package'] if d.getVar('SSTATE_SIG_KEY'): sstate_create_package.append('sstate_sign_package') @@ -810,6 +810,12 @@ python sstate_task_postfunc () { } sstate_task_postfunc[dirs] = "${WORKDIR}" +python sstate_create_pkgdirs () { + # report_unihash can change SSTATE_PKG and mkdir -p in shell doesn't own intermediate directories + # correctly so do this in an intermediate python task + with bb.utils.umask(0o002): + bb.utils.mkdirhier(os.path.dirname(d.getVar('SSTATE_PKG'))) +} # # Shell function to generate a sstate package from a directory @@ -822,7 +828,6 @@ sstate_create_package () { return fi - mkdir --mode=0775 -p `dirname ${SSTATE_PKG}` TFILE=`mktemp ${SSTATE_PKG}.XXXXXXXX` OPT="-cS" diff --git a/poky/meta/classes-recipe/allarch.bbclass b/poky/meta/classes-recipe/allarch.bbclass index 9138f40ed8..e429b92437 100644 --- a/poky/meta/classes-recipe/allarch.bbclass +++ b/poky/meta/classes-recipe/allarch.bbclass @@ -63,9 +63,9 @@ python () { d.appendVarFlag("emit_pkgdata", "vardepsexclude", " MULTILIB_VARIANTS") d.appendVarFlag("write_specfile", "vardepsexclude", " MULTILIBS") d.appendVarFlag("do_package", "vardepsexclude", " package_do_shlibs") + + d.setVar("qemu_wrapper_cmdline", "def qemu_wrapper_cmdline(data, rootfs_path, library_paths):\n return 'false'") elif bb.data.inherits_class('packagegroup', d) and not bb.data.inherits_class('nativesdk', d): bb.error("Please ensure recipe %s sets PACKAGE_ARCH before inherit packagegroup" % d.getVar("FILE")) } -def qemu_wrapper_cmdline(data, rootfs_path, library_paths): - return 'false' diff --git a/poky/meta/classes-recipe/kernel.bbclass b/poky/meta/classes-recipe/kernel.bbclass index 16b85dbca4..2ff2dff9e2 100644 --- a/poky/meta/classes-recipe/kernel.bbclass +++ b/poky/meta/classes-recipe/kernel.bbclass @@ -239,6 +239,8 @@ KERNEL_EXTRA_ARGS ?= "" EXTRA_OEMAKE += ' CC="${KERNEL_CC}" LD="${KERNEL_LD}" OBJCOPY="${KERNEL_OBJCOPY}" STRIP="${KERNEL_STRIP}"' EXTRA_OEMAKE += ' HOSTCC="${BUILD_CC}" HOSTCFLAGS="${BUILD_CFLAGS}" HOSTLDFLAGS="${BUILD_LDFLAGS}" HOSTCPP="${BUILD_CPP}"' EXTRA_OEMAKE += ' HOSTCXX="${BUILD_CXX}" HOSTCXXFLAGS="${BUILD_CXXFLAGS}"' +# Only for newer kernels (5.19+), native pkg-config variables are set for older kernels when building kernel and modules +EXTRA_OEMAKE += ' HOSTPKG_CONFIG="pkg-config-native"' KERNEL_ALT_IMAGETYPE ??= "" @@ -356,9 +358,6 @@ kernel_do_compile() { export PKG_CONFIG_LIBDIR="$PKG_CONFIG_DIR" export PKG_CONFIG_SYSROOT_DIR="" - # for newer kernels (5.19+) there's a dedicated variable - export HOSTPKG_CONFIG="pkg-config-native" - if [ "${KERNEL_DEBUG_TIMESTAMPS}" != "1" ]; then # kernel sources do not use do_unpack, so SOURCE_DATE_EPOCH may not # be set.... @@ -408,6 +407,13 @@ addtask transform_kernel after do_compile before do_install do_compile_kernelmodules() { unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE + + # setup native pkg-config variables (kconfig scripts call pkg-config directly, cannot generically be overriden to pkg-config-native) + export PKG_CONFIG_DIR="${STAGING_DIR_NATIVE}${libdir_native}/pkgconfig" + export PKG_CONFIG_PATH="$PKG_CONFIG_DIR:${STAGING_DATADIR_NATIVE}/pkgconfig" + export PKG_CONFIG_LIBDIR="$PKG_CONFIG_DIR" + export PKG_CONFIG_SYSROOT_DIR="" + if [ "${KERNEL_DEBUG_TIMESTAMPS}" != "1" ]; then # kernel sources do not use do_unpack, so SOURCE_DATE_EPOCH may not # be set.... diff --git a/poky/meta/classes-recipe/populate_sdk_base.bbclass b/poky/meta/classes-recipe/populate_sdk_base.bbclass index dfd4bb1d4d..8fadfef942 100644 --- a/poky/meta/classes-recipe/populate_sdk_base.bbclass +++ b/poky/meta/classes-recipe/populate_sdk_base.bbclass @@ -285,7 +285,7 @@ python check_sdk_sysroots() { dir_walk(SCAN_ROOT) } -SDKTAROPTS = "--owner=root --group=root" +SDKTAROPTS = "--owner=root --group=root --clamp-mtime --mtime=@${SOURCE_DATE_EPOCH}" fakeroot archive_sdk() { # Package it up diff --git a/poky/meta/classes-recipe/qemu.bbclass b/poky/meta/classes-recipe/qemu.bbclass index 874b15127c..dbb5ee0b66 100644 --- a/poky/meta/classes-recipe/qemu.bbclass +++ b/poky/meta/classes-recipe/qemu.bbclass @@ -34,7 +34,7 @@ def qemu_wrapper_cmdline(data, rootfs_path, library_paths): if qemu_binary == "qemu-allarch": qemu_binary = "qemuwrapper" - qemu_options = data.getVar("QEMU_OPTIONS") + qemu_options = data.getVar("QEMU_OPTIONS") or "" return "PSEUDO_UNLOAD=1 " + qemu_binary + " " + qemu_options + " -L " + rootfs_path\ + " -E LD_LIBRARY_PATH=" + ":".join(library_paths) + " " diff --git a/poky/meta/classes/create-spdx-2.2.bbclass b/poky/meta/classes/create-spdx-2.2.bbclass index b0aef80db1..486efadba9 100644 --- a/poky/meta/classes/create-spdx-2.2.bbclass +++ b/poky/meta/classes/create-spdx-2.2.bbclass @@ -1075,7 +1075,7 @@ def combine_spdx(d, rootfs_name, rootfs_deploydir, rootfs_spdxid, packages, spdx "%s:%s" % (runtime_ref.externalDocumentId, runtime_doc.SPDXID), comment="Runtime dependencies for %s" % name ) - + bb.utils.mkdirhier(spdx_workdir) image_spdx_path = spdx_workdir / (rootfs_name + ".spdx.json") with image_spdx_path.open("wb") as f: diff --git a/poky/meta/classes/cve-check.bbclass b/poky/meta/classes/cve-check.bbclass index 5191d04303..56ba8bceef 100644 --- a/poky/meta/classes/cve-check.bbclass +++ b/poky/meta/classes/cve-check.bbclass @@ -418,6 +418,9 @@ def check_cves(d, patched_cves): cves_status.append([product, False]) conn.close() + diff_ignore = list(set(cve_ignore) - set(cves_ignored)) + if diff_ignore: + oe.qa.handle_error("cve_status_not_in_db", "Found CVE (%s) with CVE_STATUS set that are not found in database for this component" % " ".join(diff_ignore), d) if not cves_in_recipe: bb.note("No CVE records for products in recipe %s" % (pn)) diff --git a/poky/meta/classes/externalsrc.bbclass b/poky/meta/classes/externalsrc.bbclass index a54f316aa0..70e27a8d35 100644 --- a/poky/meta/classes/externalsrc.bbclass +++ b/poky/meta/classes/externalsrc.bbclass @@ -104,6 +104,7 @@ python () { # If we deltask do_patch, there's no dependency to ensure do_unpack gets run, so add one # Note that we cannot use d.appendVarFlag() here because deps is expected to be a list object, not a string d.setVarFlag('do_configure', 'deps', (d.getVarFlag('do_configure', 'deps', False) or []) + ['do_unpack']) + d.setVarFlag('do_populate_lic', 'deps', (d.getVarFlag('do_populate_lic', 'deps', False) or []) + ['do_unpack']) for task in d.getVar("SRCTREECOVEREDTASKS").split(): if local_srcuri and task in fetch_tasks: diff --git a/poky/meta/classes/multilib_global.bbclass b/poky/meta/classes/multilib_global.bbclass index dcd89b2f63..6095d278dd 100644 --- a/poky/meta/classes/multilib_global.bbclass +++ b/poky/meta/classes/multilib_global.bbclass @@ -195,6 +195,7 @@ python multilib_virtclass_handler_global () { # from a copy of the datastore localdata = bb.data.createCopy(d) localdata.delVar("KERNEL_VERSION") + localdata.delVar("KERNEL_VERSION_PKG_NAME") variants = (e.data.getVar("MULTILIB_VARIANTS") or "").split() diff --git a/poky/meta/conf/distro/include/ptest-packagelists.inc b/poky/meta/conf/distro/include/ptest-packagelists.inc index fc42f95de2..fdeac3db3c 100644 --- a/poky/meta/conf/distro/include/ptest-packagelists.inc +++ b/poky/meta/conf/distro/include/ptest-packagelists.inc @@ -102,7 +102,6 @@ PTESTS_SLOW = "\ libgcrypt \ libmodule-build-perl \ lttng-tools \ - mdadm \ openssh \ openssl \ parted \ @@ -131,6 +130,7 @@ PTESTS_PROBLEMS:append:x86 = " valgrind" # ifupdown \ # Tested separately in lib/oeqa/selftest/cases/imagefeatures.py # libinput \ # Tests need an unloaded system to be reliable # libpam \ # Needs pam DISTRO_FEATURE +# mdadm \ # tests are flaky in AB. # numactl \ # qemu not (yet) configured for numa; all tests are skipped # libseccomp \ # tests failed: 38; add to slow tests once addressed # python3-numpy \ # requires even more RAM and (possibly) disk space; multiple failures @@ -143,6 +143,7 @@ PTESTS_PROBLEMS = "\ libinput \ libpam \ libseccomp \ + mdadm \ numactl \ python3-license-expression \ python3-numpy \ diff --git a/poky/meta/conf/distro/include/yocto-uninative.inc b/poky/meta/conf/distro/include/yocto-uninative.inc index eaa3e9b31c..4ac66fd506 100644 --- a/poky/meta/conf/distro/include/yocto-uninative.inc +++ b/poky/meta/conf/distro/include/yocto-uninative.inc @@ -6,10 +6,10 @@ # to the distro running on the build machine. # -UNINATIVE_MAXGLIBCVERSION = "2.38" -UNINATIVE_VERSION = "4.3" +UNINATIVE_MAXGLIBCVERSION = "2.39" +UNINATIVE_VERSION = "4.4" UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/${UNINATIVE_VERSION}/" -UNINATIVE_CHECKSUM[aarch64] ?= "8df05f4a41455018b4303b2e0ea4eac5c960b5a13713f6dbb33dfdb3e32753ec" -UNINATIVE_CHECKSUM[i686] ?= "bea76b4a97c9ba0077c0dd1295f519cd599dbf71f0ca1c964471c4cdb043addd" -UNINATIVE_CHECKSUM[x86_64] ?= "1c35f09a75c4096749bbe1e009df4e3968cde151424062cf4aa3ed89db22b030" +UNINATIVE_CHECKSUM[aarch64] ?= "b61876130f494f75092f21086b4a64ea5fb064045769bf1d32e9cb6af17ea8ec" +UNINATIVE_CHECKSUM[i686] ?= "9f28627828f0082cc0344eede4d9a861a9a064bfa8f36e072e46212f0fe45fcc" +UNINATIVE_CHECKSUM[x86_64] ?= "d81c54284be2bb886931fc87281d58177a2cd381cf99d1981f8923039a72a302" diff --git a/poky/meta/conf/documentation.conf b/poky/meta/conf/documentation.conf index d03c497c0e..486c62b6e8 100644 --- a/poky/meta/conf/documentation.conf +++ b/poky/meta/conf/documentation.conf @@ -28,7 +28,7 @@ do_kernel_configcheck[doc] = "Validates the kernel configuration for a linux-yoc do_kernel_configme[doc] = "Assembles the kernel configuration for a linux-yocto style kernel" do_kernel_link_images[doc] = "Creates a symbolic link in arch/$arch/boot for vmlinux and vmlinuz kernel images" do_listtasks[doc] = "Lists all defined tasks for a target" -do_menuconfig[doc] = "Runs 'make menuconfig' for the kernel" +do_menuconfig[doc] = "Runs 'make menuconfig' in the compilation directory" do_package[doc] = "Analyzes the content of the holding area and splits it into subsets based on available packages and files" do_package_index[doc] = "Creates or updates the index in the Package Feed area" do_package_qa[doc] = "Runs QA checks on packaged files" diff --git a/poky/meta/lib/oe/cve_check.py b/poky/meta/lib/oe/cve_check.py index 3fa77bf9a7..ed5c714cb8 100644 --- a/poky/meta/lib/oe/cve_check.py +++ b/poky/meta/lib/oe/cve_check.py @@ -79,20 +79,19 @@ def get_patched_cves(d): import re import oe.patch - pn = d.getVar("PN") - cve_match = re.compile("CVE:( CVE\-\d{4}\-\d+)+") + cve_match = re.compile(r"CVE:( CVE-\d{4}-\d+)+") # Matches the last "CVE-YYYY-ID" in the file name, also if written # in lowercase. Possible to have multiple CVE IDs in a single # file name, but only the last one will be detected from the file name. # However, patch files contents addressing multiple CVE IDs are supported # (cve_match regular expression) - - cve_file_name_match = re.compile(".*([Cc][Vv][Ee]\-\d{4}\-\d+)") + cve_file_name_match = re.compile(r".*(CVE-\d{4}-\d+)", re.IGNORECASE) patched_cves = set() - bb.debug(2, "Looking for patches that solves CVEs for %s" % pn) - for url in oe.patch.src_patches(d): + patches = oe.patch.src_patches(d) + bb.debug(2, "Scanning %d patches for CVEs" % len(patches)) + for url in patches: patch_file = bb.fetch.decodeurl(url)[2] # Check patch file name for CVE ID @@ -100,7 +99,7 @@ def get_patched_cves(d): if fname_match: cve = fname_match.group(1).upper() patched_cves.add(cve) - bb.debug(2, "Found CVE %s from patch file name %s" % (cve, patch_file)) + bb.debug(2, "Found %s from patch file name %s" % (cve, patch_file)) # Remote patches won't be present and compressed patches won't be # unpacked, so say we're not scanning them @@ -231,7 +230,7 @@ def decode_cve_status(d, cve): Convert CVE_STATUS into status, detail and description. """ status = d.getVarFlag("CVE_STATUS", cve) - if status is None: + if not status: return ("", "", "") status_split = status.split(':', 1) @@ -240,7 +239,7 @@ def decode_cve_status(d, cve): status_mapping = d.getVarFlag("CVE_CHECK_STATUSMAP", detail) if status_mapping is None: - bb.warn('Invalid detail %s for CVE_STATUS[%s] = "%s", fallback to Unpatched' % (detail, cve, status)) + bb.warn('Invalid detail "%s" for CVE_STATUS[%s] = "%s", fallback to Unpatched' % (detail, cve, status)) status_mapping = "Unpatched" return (status_mapping, detail, description) diff --git a/poky/meta/lib/oe/prservice.py b/poky/meta/lib/oe/prservice.py index 2f2a0c128a..c41242c878 100644 --- a/poky/meta/lib/oe/prservice.py +++ b/poky/meta/lib/oe/prservice.py @@ -78,8 +78,7 @@ def prserv_export_tofile(d, metainfo, datainfo, lockdown, nomax=False): bb.utils.mkdirhier(d.getVar('PRSERV_DUMPDIR')) df = d.getVar('PRSERV_DUMPFILE') #write data - lf = bb.utils.lockfile("%s.lock" % df) - with open(df, "a") as f: + with open(df, "a") as f, bb.utils.fileslocked(["%s.lock" % df]) as locks: if metainfo: #dump column info f.write("#PR_core_ver = \"%s\"\n\n" % metainfo['core_ver']); @@ -113,7 +112,6 @@ def prserv_export_tofile(d, metainfo, datainfo, lockdown, nomax=False): if not nomax: for i in idx: f.write("PRAUTO_%s_%s = \"%s\"\n" % (str(datainfo[idx[i]]['version']),str(datainfo[idx[i]]['pkgarch']),str(datainfo[idx[i]]['value']))) - bb.utils.unlockfile(lf) def prserv_check_avail(d): host_params = list([_f for _f in (d.getVar("PRSERV_HOST") or '').split(':') if _f]) diff --git a/poky/meta/lib/oe/reproducible.py b/poky/meta/lib/oe/reproducible.py index 9ac75c02e3..448befce33 100644 --- a/poky/meta/lib/oe/reproducible.py +++ b/poky/meta/lib/oe/reproducible.py @@ -131,6 +131,9 @@ def get_source_date_epoch_from_youngest_file(d, sourcedir): files = [f for f in files if not f[0] == '.'] for fname in files: + if fname == "singletask.lock": + # Ignore externalsrc/devtool lockfile [YOCTO #14921] + continue filename = os.path.join(root, fname) try: mtime = int(os.lstat(filename).st_mtime) diff --git a/poky/meta/lib/oe/rootfs.py b/poky/meta/lib/oe/rootfs.py index 1a48ed10b3..3f27164536 100644 --- a/poky/meta/lib/oe/rootfs.py +++ b/poky/meta/lib/oe/rootfs.py @@ -349,7 +349,8 @@ class Rootfs(object, metaclass=ABCMeta): bb.utils.mkdirhier(versioned_modules_dir) bb.note("Running depmodwrapper for %s ..." % versioned_modules_dir) - self._exec_shell_cmd(['depmodwrapper', '-a', '-b', self.image_rootfs, kernel_ver, kernel_package_name]) + if self._exec_shell_cmd(['depmodwrapper', '-a', '-b', self.image_rootfs, kernel_ver, kernel_package_name]): + bb.fatal("Kernel modules dependency generation failed") """ Create devfs: diff --git a/poky/meta/lib/oeqa/runtime/decorator/package.py b/poky/meta/lib/oeqa/runtime/decorator/package.py index 8aba3f325b..b78ac9fc38 100644 --- a/poky/meta/lib/oeqa/runtime/decorator/package.py +++ b/poky/meta/lib/oeqa/runtime/decorator/package.py @@ -38,11 +38,12 @@ class OEHasPackage(OETestDecorator): if isinstance(self.need_pkgs, str): self.need_pkgs = [self.need_pkgs,] + mlprefix = self.case.td.get("MLPREFIX") for pkg in self.need_pkgs: if pkg.startswith('!'): - unneed_pkgs.add(pkg[1:]) + unneed_pkgs.add(mlprefix + pkg[1:]) else: - need_pkgs.add(pkg) + need_pkgs.add(mlprefix + pkg) if unneed_pkgs: msg = 'Checking if %s is not installed' % ', '.join(unneed_pkgs) diff --git a/poky/meta/lib/oeqa/selftest/cases/prservice.py b/poky/meta/lib/oeqa/selftest/cases/prservice.py index 9fe3b80a31..8da3739c57 100644 --- a/poky/meta/lib/oeqa/selftest/cases/prservice.py +++ b/poky/meta/lib/oeqa/selftest/cases/prservice.py @@ -14,6 +14,8 @@ from oeqa.selftest.case import OESelftestTestCase from oeqa.utils.commands import runCmd, bitbake, get_bb_var from oeqa.utils.network import get_free_port +import bb.utils + class BitbakePrTests(OESelftestTestCase): @classmethod @@ -21,6 +23,16 @@ class BitbakePrTests(OESelftestTestCase): super(BitbakePrTests, cls).setUpClass() cls.pkgdata_dir = get_bb_var('PKGDATA_DIR') + cls.exported_db_path = os.path.join(cls.builddir, 'export.inc') + cls.current_db_path = os.path.join(get_bb_var('PERSISTENT_DIR'), 'prserv.sqlite3') + + def cleanup(self): + # Ensure any memory resident bitbake is stopped + bitbake("-m") + # Remove any existing export file or prserv database + bb.utils.remove(self.exported_db_path) + bb.utils.remove(self.current_db_path + "*") + def get_pr_version(self, package_name): package_data_file = os.path.join(self.pkgdata_dir, 'runtime', package_name) package_data = ftools.read_file(package_data_file) @@ -49,6 +61,7 @@ class BitbakePrTests(OESelftestTestCase): self.assertEqual(res.status, 0, msg=res.output) def config_pr_tests(self, package_name, package_type='rpm', pr_socket='localhost:0'): + self.cleanup() config_package_data = 'PACKAGE_CLASSES = "package_%s"' % package_type self.write_config(config_package_data) config_server_data = 'PRSERV_HOST = "%s"' % pr_socket @@ -68,24 +81,24 @@ class BitbakePrTests(OESelftestTestCase): self.assertTrue(pr_2 - pr_1 == 1, "New PR %s did not increment as expected (from %s), difference should be 1" % (pr_2, pr_1)) self.assertTrue(stamp_1 != stamp_2, "Different pkg rev. but same stamp: %s" % stamp_1) + self.cleanup() + def run_test_pr_export_import(self, package_name, replace_current_db=True): self.config_pr_tests(package_name) self.increment_package_pr(package_name) pr_1 = self.get_pr_version(package_name) - exported_db_path = os.path.join(self.builddir, 'export.inc') - export_result = runCmd("bitbake-prserv-tool export %s" % exported_db_path, ignore_status=True) + export_result = runCmd("bitbake-prserv-tool export %s" % self.exported_db_path, ignore_status=True) self.assertEqual(export_result.status, 0, msg="PR Service database export failed: %s" % export_result.output) - self.assertTrue(os.path.exists(exported_db_path), msg="%s didn't exist, tool output %s" % (exported_db_path, export_result.output)) + self.assertTrue(os.path.exists(self.exported_db_path), msg="%s didn't exist, tool output %s" % (self.exported_db_path, export_result.output)) if replace_current_db: - current_db_path = os.path.join(get_bb_var('PERSISTENT_DIR'), 'prserv.sqlite3') - self.assertTrue(os.path.exists(current_db_path), msg="Path to current PR Service database is invalid: %s" % current_db_path) - os.remove(current_db_path) + self.assertTrue(os.path.exists(self.current_db_path), msg="Path to current PR Service database is invalid: %s" % self.current_db_path) + os.remove(self.current_db_path) - import_result = runCmd("bitbake-prserv-tool import %s" % exported_db_path, ignore_status=True) - os.remove(exported_db_path) + import_result = runCmd("bitbake-prserv-tool import %s" % self.exported_db_path, ignore_status=True) + #os.remove(self.exported_db_path) self.assertEqual(import_result.status, 0, msg="PR Service database import failed: %s" % import_result.output) self.increment_package_pr(package_name) @@ -93,6 +106,8 @@ class BitbakePrTests(OESelftestTestCase): self.assertTrue(pr_2 - pr_1 == 1, "New PR %s did not increment as expected (from %s), difference should be 1" % (pr_2, pr_1)) + self.cleanup() + def test_import_export_replace_db(self): self.run_test_pr_export_import('m4') diff --git a/poky/meta/recipes-bsp/grub/files/0001-fs-fat-Don-t-error-when-mtime-is-0.patch b/poky/meta/recipes-bsp/grub/files/0001-fs-fat-Don-t-error-when-mtime-is-0.patch new file mode 100644 index 0000000000..a5fbd58f46 --- /dev/null +++ b/poky/meta/recipes-bsp/grub/files/0001-fs-fat-Don-t-error-when-mtime-is-0.patch @@ -0,0 +1,70 @@ +From e43f3d93b28cce852c110c7a8e40d8311bcd8bb1 Mon Sep 17 00:00:00 2001 +From: Robbie Harwood <rharwood@redhat.com> +Date: Fri, 15 Jul 2022 16:13:02 -0400 +Subject: [PATCH] fs/fat: Don't error when mtime is 0 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +In the wild, we occasionally see valid ESPs where some file modification +times are 0. For instance: + + ├── [Dec 31 1979] EFI + │ ├── [Dec 31 1979] BOOT + │ │ ├── [Dec 31 1979] BOOTX64.EFI + │ │ └── [Dec 31 1979] fbx64.efi + │ └── [Jun 27 02:41] fedora + │ ├── [Dec 31 1979] BOOTX64.CSV + │ ├── [Dec 31 1979] fonts + │ ├── [Mar 14 03:35] fw + │ │ ├── [Mar 14 03:35] fwupd-359c1169-abd6-4a0d-8bce-e4d4713335c1.cap + │ │ ├── [Mar 14 03:34] fwupd-9d255c4b-2d88-4861-860d-7ee52ade9463.cap + │ │ └── [Mar 14 03:34] fwupd-b36438d8-9128-49d2-b280-487be02d948b.cap + │ ├── [Dec 31 1979] fwupdx64.efi + │ ├── [May 10 10:47] grub.cfg + │ ├── [Jun 3 12:38] grub.cfg.new.new + │ ├── [May 10 10:41] grub.cfg.old + │ ├── [Jun 27 02:41] grubenv + │ ├── [Dec 31 1979] grubx64.efi + │ ├── [Dec 31 1979] mmx64.efi + │ ├── [Dec 31 1979] shim.efi + │ ├── [Dec 31 1979] shimx64.efi + │ └── [Dec 31 1979] shimx64-fedora.efi + └── [Dec 31 1979] FSCK0000.REC + + 5 directories, 17 files + +This causes grub-probe failure, which in turn causes grub-mkconfig +failure. They are valid filesystems that appear intact, and the Linux +FAT stack is able to mount and manipulate them without complaint. + +The check for mtime of 0 has been present since +20def1a3c3952982395cd7c3ea7e78638527962b (fat: support file +modification times). + +Upstream-Status: Backport [https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e43f3d93b28cce852c110c7a8e40d8311bcd8bb1] + +Signed-off-by: Robbie Harwood <rharwood@redhat.com> +Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com> +Signed-off-by: Ming Liu <liu.ming50@gmail.com> +--- + grub-core/fs/fat.c | 3 --- + 1 file changed, 3 deletions(-) + +diff --git a/grub-core/fs/fat.c b/grub-core/fs/fat.c +index 0951b2e63..c5efed724 100644 +--- a/grub-core/fs/fat.c ++++ b/grub-core/fs/fat.c +@@ -1027,9 +1027,6 @@ grub_fat_dir (grub_device_t device, const char *path, grub_fs_dir_hook_t hook, + grub_le_to_cpu16 (ctxt.dir.w_date), + &info.mtime); + #endif +- if (info.mtimeset == 0) +- grub_error (GRUB_ERR_OUT_OF_RANGE, +- "invalid modification timestamp for %s", path); + + if (hook (ctxt.filename, &info, hook_data)) + break; +-- +2.34.1 + diff --git a/poky/meta/recipes-bsp/grub/grub2.inc b/poky/meta/recipes-bsp/grub/grub2.inc index f594e7d3a4..1215b24668 100644 --- a/poky/meta/recipes-bsp/grub/grub2.inc +++ b/poky/meta/recipes-bsp/grub/grub2.inc @@ -44,6 +44,7 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \ file://0001-fs-ext2-Ignore-checksum-seed-incompat-feature.patch \ file://CVE-2023-4692.patch \ file://CVE-2023-4693.patch \ + file://0001-fs-fat-Don-t-error-when-mtime-is-0.patch \ " SRC_URI[sha256sum] = "23b64b4c741569f9426ed2e3d0e6780796fca081bee4c99f62aa3f53ae803f5f" diff --git a/poky/meta/recipes-connectivity/avahi/avahi_0.8.bb b/poky/meta/recipes-connectivity/avahi/avahi_0.8.bb index bfd945c7ae..1f18d4491d 100644 --- a/poky/meta/recipes-connectivity/avahi/avahi_0.8.bb +++ b/poky/meta/recipes-connectivity/avahi/avahi_0.8.bb @@ -6,7 +6,7 @@ IPv4 Link-Local Addresses" (IETF RFC3927), a protocol for automatic IP address \ configuration from the link-local 169.254.0.0/16 range without the need for a central \ server.' HOMEPAGE = "http://avahi.org" -BUGTRACKER = "https://github.com/lathiat/avahi/issues" +BUGTRACKER = "https://github.com/avahi/avahi/issues" SECTION = "network" # major part is under LGPL-2.1-or-later, but several .dtd, .xsl, initscripts and @@ -37,8 +37,7 @@ SRC_URI = "${GITHUB_BASE_URI}/download/v${PV}/avahi-${PV}.tar.gz \ file://CVE-2023-38473.patch \ " -GITHUB_BASE_URI = "https://github.com/lathiat/avahi/releases/" -SRC_URI[md5sum] = "229c6aa30674fc43c202b22c5f8c2be7" +GITHUB_BASE_URI = "https://github.com/avahi/avahi/releases/" SRC_URI[sha256sum] = "060309d7a333d38d951bc27598c677af1796934dbd98e1024e7ad8de798fedda" CVE_STATUS[CVE-2021-26720] = "not-applicable-platform: Issue only affects Debian/SUSE" diff --git a/poky/meta/recipes-connectivity/bind/bind/bind-ensure-searching-for-json-headers-searches-sysr.patch b/poky/meta/recipes-connectivity/bind/bind/bind-ensure-searching-for-json-headers-searches-sysr.patch index f1abd179e8..38d07cae39 100644 --- a/poky/meta/recipes-connectivity/bind/bind/bind-ensure-searching-for-json-headers-searches-sysr.patch +++ b/poky/meta/recipes-connectivity/bind/bind/bind-ensure-searching-for-json-headers-searches-sysr.patch @@ -1,4 +1,4 @@ -From 246087f89e9434b726c7884e4c0964f71084f091 Mon Sep 17 00:00:00 2001 +From 5ae30329f168c1e8d2e0c3831988a4f3e9096e39 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker <paul.gortmaker@windriver.com> Date: Tue, 9 Jun 2015 11:22:00 -0400 Subject: [PATCH] bind: ensure searching for json headers searches sysroot @@ -33,10 +33,10 @@ Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac -index 10e8bf6..bf20690 100644 +index 2ab8ddd..92fe983 100644 --- a/configure.ac +++ b/configure.ac -@@ -814,7 +814,7 @@ AS_CASE([$with_lmdb], +@@ -761,7 +761,7 @@ AS_CASE([$with_lmdb], [no],[], [auto|yes], [PKG_CHECK_MODULES([LMDB], [lmdb], [ac_lib_lmdb_found=yes], diff --git a/poky/meta/recipes-connectivity/bind/bind_9.18.20.bb b/poky/meta/recipes-connectivity/bind/bind_9.18.24.bb index 187685eef5..2874990320 100644 --- a/poky/meta/recipes-connectivity/bind/bind_9.18.20.bb +++ b/poky/meta/recipes-connectivity/bind/bind_9.18.24.bb @@ -20,7 +20,7 @@ SRC_URI = "https://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.xz \ file://0001-avoid-start-failure-with-bind-user.patch \ " -SRC_URI[sha256sum] = "4b891ebf58d3f2a7ac3dd2682990f528a3448eaa1c992ddc5c141b8587a98ec5" +SRC_URI[sha256sum] = "709d73023c9115ddad3bab65b6c8c79a590196d0d114f5d0ca2533dbd52ddf66" UPSTREAM_CHECK_URI = "https://ftp.isc.org/isc/bind9/" # follow the ESV versions divisible by 2 diff --git a/poky/meta/recipes-connectivity/kea/files/fix-multilib-conflict.patch b/poky/meta/recipes-connectivity/kea/files/fix-multilib-conflict.patch index 451b409c88..5b135b3aee 100644 --- a/poky/meta/recipes-connectivity/kea/files/fix-multilib-conflict.patch +++ b/poky/meta/recipes-connectivity/kea/files/fix-multilib-conflict.patch @@ -1,4 +1,4 @@ -From d027b1d85a8c1a0193b6e4a00083d3038d699a59 Mon Sep 17 00:00:00 2001 +From 06ebd1b2ced426c420ed162980eca194f9f918ae Mon Sep 17 00:00:00 2001 From: Kai Kang <kai.kang@windriver.com> Date: Tue, 22 Sep 2020 15:02:33 +0800 Subject: [PATCH] There are conflict of config files between kea and lib32-kea: @@ -35,10 +35,10 @@ index e6ae8b8..50a3092 100644 // "param1": "foo" // } diff --git a/src/bin/keactrl/kea-dhcp4.conf.pre b/src/bin/keactrl/kea-dhcp4.conf.pre -index 26bf163..49ddb0a 100644 +index 6edb8a1..b2a7385 100644 --- a/src/bin/keactrl/kea-dhcp4.conf.pre +++ b/src/bin/keactrl/kea-dhcp4.conf.pre -@@ -252,7 +252,7 @@ +@@ -255,7 +255,7 @@ // // of all devices serviced by Kea, including their identifiers // // (like MAC address), their location in the network, times // // when they were active etc. @@ -47,7 +47,7 @@ index 26bf163..49ddb0a 100644 // "parameters": { // "path": "/var/lib/kea", // "base-name": "kea-forensic4" -@@ -269,7 +269,7 @@ +@@ -272,7 +272,7 @@ // // of specific options or perhaps even a combination of several // // options and fields to uniquely identify a client. Those scenarios // // are addressed by the Flexible Identifiers hook application. diff --git a/poky/meta/recipes-connectivity/kea/files/fix_pid_keactrl.patch b/poky/meta/recipes-connectivity/kea/files/fix_pid_keactrl.patch index b7c2fd4f0d..63a6a2805b 100644 --- a/poky/meta/recipes-connectivity/kea/files/fix_pid_keactrl.patch +++ b/poky/meta/recipes-connectivity/kea/files/fix_pid_keactrl.patch @@ -1,4 +1,4 @@ -From 18f4f6206c248d6169aa67b3ecf16bf54e9292e8 Mon Sep 17 00:00:00 2001 +From c878a356712606549f7f188b62f7d1cae08a176e Mon Sep 17 00:00:00 2001 From: Armin kuster <akuster808@gmail.com> Date: Wed, 14 Oct 2020 22:48:31 -0700 Subject: [PATCH] Busybox does not support ps -p so use pgrep @@ -13,10 +13,10 @@ Signed-off-by: Armin kuster <akuster808@gmail.com> 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/bin/keactrl/keactrl.in b/src/bin/keactrl/keactrl.in -index ae5bd8e..e9f9b73 100644 +index 450e997..c353ca9 100644 --- a/src/bin/keactrl/keactrl.in +++ b/src/bin/keactrl/keactrl.in -@@ -151,8 +151,8 @@ check_running() { +@@ -149,8 +149,8 @@ check_running() { # Get the PID from the PID file (if it exists) get_pid_from_file "${proc_name}" if [ ${_pid} -gt 0 ]; then diff --git a/poky/meta/recipes-connectivity/kea/kea_2.4.0.bb b/poky/meta/recipes-connectivity/kea/kea_2.4.1.bb index 316468754e..c3aa4dc8f0 100644 --- a/poky/meta/recipes-connectivity/kea/kea_2.4.0.bb +++ b/poky/meta/recipes-connectivity/kea/kea_2.4.1.bb @@ -19,7 +19,7 @@ SRC_URI = "http://ftp.isc.org/isc/kea/${PV}/${BP}.tar.gz \ file://0001-src-lib-log-logger_unittest_support.cc-do-not-write-.patch \ file://0001-kea-fix-reproducible-build-failure.patch \ " -SRC_URI[sha256sum] = "3a33cd08dc3319ff544e6bbf2c0429042106f4051ebe115dc1bb2625c95003f7" +SRC_URI[sha256sum] = "815c61f5c271caa4a1db31dd656eb50a7f6ea973da3690f7c8581408e180131a" inherit autotools systemd update-rc.d upstream-version-is-even diff --git a/poky/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch b/poky/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch deleted file mode 100644 index 5afc714f19..0000000000 --- a/poky/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch +++ /dev/null @@ -1,80 +0,0 @@ -From b62a3fe424026b73ec6b1934483b16863c7dff23 Mon Sep 17 00:00:00 2001 -From: Wiktor Jaskulski <wjaskulski@adva.com> -Date: Thu, 11 May 2023 15:28:23 -0400 -Subject: [PATCH] configure.ac: libevent and libsqlite3 checked when nfsv4 is - disabled - -Upstream-Status: Backport -(http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=bc4a5deef9f820c55fdac3c0070364c17cd91cca) - -Signed-off-by: Steve Dickson <steved@redhat.com> -Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com> ---- - configure.ac | 38 +++++++++++++++----------------------- - 1 file changed, 15 insertions(+), 23 deletions(-) - -diff --git a/configure.ac b/configure.ac -index 4ade528d..519cacbf 100644 ---- a/configure.ac -+++ b/configure.ac -@@ -335,42 +335,34 @@ AC_CHECK_HEADER(rpc/rpc.h, , - AC_MSG_ERROR([Header file rpc/rpc.h not found - maybe try building with --enable-tirpc])) - CPPFLAGS="${nfsutils_save_CPPFLAGS}" - -+dnl check for libevent libraries and headers -+AC_LIBEVENT -+ -+dnl Check for sqlite3 -+AC_SQLITE3_VERS -+ -+case $libsqlite3_cv_is_recent in -+yes) ;; -+unknown) -+ dnl do not fail when cross-compiling -+ AC_MSG_WARN([assuming sqlite is at least v3.3]) ;; -+*) -+ AC_MSG_ERROR([nfsdcld requires sqlite-devel]) ;; -+esac -+ - if test "$enable_nfsv4" = yes; then -- dnl check for libevent libraries and headers -- AC_LIBEVENT - - dnl check for the keyutils libraries and headers - AC_KEYUTILS - -- dnl Check for sqlite3 -- AC_SQLITE3_VERS -- - if test "$enable_nfsdcld" = "yes"; then - AC_CHECK_HEADERS([libgen.h sys/inotify.h], , - AC_MSG_ERROR([Cannot find header needed for nfsdcld])) -- -- case $libsqlite3_cv_is_recent in -- yes) ;; -- unknown) -- dnl do not fail when cross-compiling -- AC_MSG_WARN([assuming sqlite is at least v3.3]) ;; -- *) -- AC_MSG_ERROR([nfsdcld requires sqlite-devel]) ;; -- esac - fi - - if test "$enable_nfsdcltrack" = "yes"; then - AC_CHECK_HEADERS([libgen.h sys/inotify.h], , - AC_MSG_ERROR([Cannot find header needed for nfsdcltrack])) -- -- case $libsqlite3_cv_is_recent in -- yes) ;; -- unknown) -- dnl do not fail when cross-compiling -- AC_MSG_WARN([assuming sqlite is at least v3.3]) ;; -- *) -- AC_MSG_ERROR([nfsdcltrack requires sqlite-devel]) ;; -- esac - fi - - else --- -2.41.0 - diff --git a/poky/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-reexport.h-Include-unistd.h-to-compile-with-musl.patch b/poky/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-reexport.h-Include-unistd.h-to-compile-with-musl.patch new file mode 100644 index 0000000000..57d4660571 --- /dev/null +++ b/poky/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-reexport.h-Include-unistd.h-to-compile-with-musl.patch @@ -0,0 +1,34 @@ +From 45597a58e98f351b18db8444292b1cf6dd0cd810 Mon Sep 17 00:00:00 2001 +From: Robert Yang <liezhi.yang@windriver.com> +Date: Sat, 9 Dec 2023 23:34:08 -0800 +Subject: [PATCH] reexport.h: Include unistd.h to compile with musl + +Fixed error when compile with musl +reexport.c: In function 'reexpdb_init': +reexport.c:62:17: error: implicit declaration of function 'sleep' [-Werror=implicit-function-declaration] + 62 | sleep(1); + + +Upstream-Status: Submitted [https://marc.info/?l=linux-nfs&m=170254661824522&w=2] + +Signed-off-by: Robert Yang <liezhi.yang@windriver.com> +--- + support/reexport/reexport.h | 1 + + 1 files changed, 1 insertions(+) + +diff --git a/support/reexport/reexport.h b/support/reexport/reexport.h +index 85fd59c..02f8684 100644 +--- a/support/reexport/reexport.h ++++ b/support/reexport/reexport.h +@@ -1,6 +1,8 @@ + #ifndef REEXPORT_H + #define REEXPORT_H + ++#include <unistd.h> ++ + #include "nfslib.h" + + enum { +-- +2.42.0 + diff --git a/poky/meta/recipes-connectivity/nfs-utils/nfs-utils_2.6.3.bb b/poky/meta/recipes-connectivity/nfs-utils/nfs-utils_2.6.4.bb index 35cf6af6d4..2f2644f9a8 100644 --- a/poky/meta/recipes-connectivity/nfs-utils/nfs-utils_2.6.3.bb +++ b/poky/meta/recipes-connectivity/nfs-utils/nfs-utils_2.6.4.bb @@ -30,11 +30,11 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/nfs-utils/${PV}/nfs-utils-${PV}.tar.x file://bugfix-adjust-statd-service-name.patch \ file://0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch \ file://clang-warnings.patch \ - file://0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch \ - file://0001-locktest-Makefile.am-Do-not-use-build-flags.patch \ - file://0001-tools-locktest-Use-intmax_t-to-print-off_t.patch \ + file://0001-locktest-Makefile.am-Do-not-use-build-flags.patch \ + file://0001-tools-locktest-Use-intmax_t-to-print-off_t.patch \ + file://0001-reexport.h-Include-unistd.h-to-compile-with-musl.patch \ " -SRC_URI[sha256sum] = "38d89e853a71d3c560ff026af3d969d75e24f782ff68324e76261fe0344459e1" +SRC_URI[sha256sum] = "01b3b0fb9c7d0bbabf5114c736542030748c788ec2fd9734744201e9b0a1119d" # Only kernel-module-nfsd is required here (but can be built-in) - the nfsd module will # pull in the remainder of the dependencies. diff --git a/poky/meta/recipes-connectivity/openssl/openssl/bti.patch b/poky/meta/recipes-connectivity/openssl/openssl/bti.patch new file mode 100644 index 0000000000..748576c30c --- /dev/null +++ b/poky/meta/recipes-connectivity/openssl/openssl/bti.patch @@ -0,0 +1,58 @@ +From ba8a599395f8b770c76316b5f5b0f3838567014f Mon Sep 17 00:00:00 2001 +From: Tom Cosgrove <tom.cosgrove@arm.com> +Date: Tue, 26 Mar 2024 13:18:00 +0000 +Subject: [PATCH] aarch64: fix BTI in bsaes assembly code + +In Arm systems where BTI is enabled but the Crypto extensions are not (more +likely in FVPs than in real hardware), the bit-sliced assembler code will +be used. However, this wasn't annotated with BTI instructions when BTI was +enabled, so the moment libssl jumps into this code it (correctly) aborts. + +Solve this by adding the missing BTI landing pads. + +Upstream-Status: Submitted [https://github.com/openssl/openssl/pull/23982] +Signed-off-by: Ross Burton <ross.burton@arm.com> +--- + crypto/aes/asm/bsaes-armv8.pl | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/crypto/aes/asm/bsaes-armv8.pl b/crypto/aes/asm/bsaes-armv8.pl +index b3c97e439f..c3c5ff3e05 100644 +--- a/crypto/aes/asm/bsaes-armv8.pl ++++ b/crypto/aes/asm/bsaes-armv8.pl +@@ -1018,6 +1018,7 @@ _bsaes_key_convert: + // Initialisation vector overwritten with last quadword of ciphertext + // No output registers, usual AAPCS64 register preservation + ossl_bsaes_cbc_encrypt: ++ AARCH64_VALID_CALL_TARGET + cmp x2, #128 + bhs .Lcbc_do_bsaes + b AES_cbc_encrypt +@@ -1270,7 +1271,7 @@ ossl_bsaes_cbc_encrypt: + // Output text filled in + // No output registers, usual AAPCS64 register preservation + ossl_bsaes_ctr32_encrypt_blocks: +- ++ AARCH64_VALID_CALL_TARGET + cmp x2, #8 // use plain AES for + blo .Lctr_enc_short // small sizes + +@@ -1476,6 +1477,7 @@ ossl_bsaes_ctr32_encrypt_blocks: + // Output ciphertext filled in + // No output registers, usual AAPCS64 register preservation + ossl_bsaes_xts_encrypt: ++ AARCH64_VALID_CALL_TARGET + // Stack layout: + // sp -> + // nrounds*128-96 bytes: key schedule +@@ -1921,6 +1923,7 @@ ossl_bsaes_xts_encrypt: + // Output plaintext filled in + // No output registers, usual AAPCS64 register preservation + ossl_bsaes_xts_decrypt: ++ AARCH64_VALID_CALL_TARGET + // Stack layout: + // sp -> + // nrounds*128-96 bytes: key schedule +-- +2.34.1 + diff --git a/poky/meta/recipes-connectivity/openssl/openssl/fix_random_labels.patch b/poky/meta/recipes-connectivity/openssl/openssl/fix_random_labels.patch deleted file mode 100644 index 78dcd81685..0000000000 --- a/poky/meta/recipes-connectivity/openssl/openssl/fix_random_labels.patch +++ /dev/null @@ -1,22 +0,0 @@ -The perl script adds random suffixes to the local function names to ensure -it doesn't clash with other parts of openssl. Set the random number seed -to something predictable so the assembler files are generated consistently -and our own reproducible builds tests pass. - -Upstream-Status: Pending -Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> - -Index: openssl-3.1.0/crypto/modes/asm/aes-gcm-avx512.pl -=================================================================== ---- openssl-3.1.0.orig/crypto/modes/asm/aes-gcm-avx512.pl -+++ openssl-3.1.0/crypto/modes/asm/aes-gcm-avx512.pl -@@ -191,6 +191,9 @@ my $CTX_OFFSET_HTable = (16 * 6); - # ;;; Helper functions - # ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; - -+# Ensure the local labels are reproduicble -+srand(10000); -+ - # ; Generates "random" local labels - sub random_string() { - my @chars = ('a' .. 'z', 'A' .. 'Z', '0' .. '9', '_'); diff --git a/poky/meta/recipes-connectivity/openssl/openssl_3.1.4.bb b/poky/meta/recipes-connectivity/openssl/openssl_3.1.5.bb index 0fe4e76808..174b5f6ad3 100644 --- a/poky/meta/recipes-connectivity/openssl/openssl_3.1.4.bb +++ b/poky/meta/recipes-connectivity/openssl/openssl_3.1.5.bb @@ -11,15 +11,15 @@ SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz \ file://run-ptest \ file://0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch \ file://0001-Configure-do-not-tweak-mips-cflags.patch \ - file://fix_random_labels.patch \ file://0001-Added-handshake-history-reporting-when-test-fails.patch \ + file://bti.patch \ " SRC_URI:append:class-nativesdk = " \ file://environment.d-openssl.sh \ " -SRC_URI[sha256sum] = "840af5366ab9b522bde525826be3ef0fb0af81c6a9ebd84caa600fea1731eee3" +SRC_URI[sha256sum] = "6ae015467dabf0469b139ada93319327be24b98251ffaeceda0221848dc09262" inherit lib_package multilib_header multilib_script ptest perlnative manpages MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash" @@ -187,6 +187,7 @@ PTEST_BUILD_HOST_PATTERN = "perl_version =" do_install_ptest () { install -d ${D}${PTEST_PATH}/test install -m755 ${B}/test/p_test.so ${D}${PTEST_PATH}/test + install -m755 ${B}/test/p_minimal.so ${D}${PTEST_PATH}/test install -m755 ${B}/test/provider_internal_test.cnf ${D}${PTEST_PATH}/test # Prune the build tree diff --git a/poky/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-PEAP-client-Update-Phase-2-authentication-requiremen.patch b/poky/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-PEAP-client-Update-Phase-2-authentication-requiremen.patch new file mode 100644 index 0000000000..620560d3c7 --- /dev/null +++ b/poky/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-PEAP-client-Update-Phase-2-authentication-requiremen.patch @@ -0,0 +1,213 @@ +From f6f7cead3661ceeef54b21f7e799c0afc98537ec Mon Sep 17 00:00:00 2001 +From: Jouni Malinen <j@w1.fi> +Date: Sat, 8 Jul 2023 19:55:32 +0300 +Subject: [PATCH] PEAP client: Update Phase 2 authentication requirements + +The previous PEAP client behavior allowed the server to skip Phase 2 +authentication with the expectation that the server was authenticated +during Phase 1 through TLS server certificate validation. Various PEAP +specifications are not exactly clear on what the behavior on this front +is supposed to be and as such, this ended up being more flexible than +the TTLS/FAST/TEAP cases. However, this is not really ideal when +unfortunately common misconfiguration of PEAP is used in deployed +devices where the server trust root (ca_cert) is not configured or the +user has an easy option for allowing this validation step to be skipped. + +Change the default PEAP client behavior to be to require Phase 2 +authentication to be successfully completed for cases where TLS session +resumption is not used and the client certificate has not been +configured. Those two exceptions are the main cases where a deployed +authentication server might skip Phase 2 and as such, where a more +strict default behavior could result in undesired interoperability +issues. Requiring Phase 2 authentication will end up disabling TLS +session resumption automatically to avoid interoperability issues. + +Allow Phase 2 authentication behavior to be configured with a new phase1 +configuration parameter option: +'phase2_auth' option can be used to control Phase 2 (i.e., within TLS +tunnel) behavior for PEAP: + * 0 = do not require Phase 2 authentication + * 1 = require Phase 2 authentication when client certificate + (private_key/client_cert) is no used and TLS session resumption was + not used (default) + * 2 = require Phase 2 authentication in all cases + +Signed-off-by: Jouni Malinen <j@w1.fi> + +CVE: CVE-2023-52160 +Upstream-Status: Backport [https://w1.fi/cgit/hostap/commit/?id=8e6485a1bcb0baffdea9e55255a81270b768439c] + +Signed-off-by: Claus Stovgaard <claus.stovgaard@gmail.com> + +--- + src/eap_peer/eap_config.h | 8 ++++++ + src/eap_peer/eap_peap.c | 40 +++++++++++++++++++++++++++--- + src/eap_peer/eap_tls_common.c | 6 +++++ + src/eap_peer/eap_tls_common.h | 5 ++++ + wpa_supplicant/wpa_supplicant.conf | 7 ++++++ + 5 files changed, 63 insertions(+), 3 deletions(-) + +diff --git a/src/eap_peer/eap_config.h b/src/eap_peer/eap_config.h +index 3238f74..047eec2 100644 +--- a/src/eap_peer/eap_config.h ++++ b/src/eap_peer/eap_config.h +@@ -469,6 +469,14 @@ struct eap_peer_config { + * 1 = use cryptobinding if server supports it + * 2 = require cryptobinding + * ++ * phase2_auth option can be used to control Phase 2 (i.e., within TLS ++ * tunnel) behavior for PEAP: ++ * 0 = do not require Phase 2 authentication ++ * 1 = require Phase 2 authentication when client certificate ++ * (private_key/client_cert) is no used and TLS session resumption was ++ * not used (default) ++ * 2 = require Phase 2 authentication in all cases ++ * + * EAP-WSC (WPS) uses following options: pin=Device_Password and + * uuid=Device_UUID + * +diff --git a/src/eap_peer/eap_peap.c b/src/eap_peer/eap_peap.c +index 12e30df..6080697 100644 +--- a/src/eap_peer/eap_peap.c ++++ b/src/eap_peer/eap_peap.c +@@ -67,6 +67,7 @@ struct eap_peap_data { + u8 cmk[20]; + int soh; /* Whether IF-TNCCS-SOH (Statement of Health; Microsoft NAP) + * is enabled. */ ++ enum { NO_AUTH, FOR_INITIAL, ALWAYS } phase2_auth; + }; + + +@@ -114,6 +115,19 @@ static void eap_peap_parse_phase1(struct eap_peap_data *data, + wpa_printf(MSG_DEBUG, "EAP-PEAP: Require cryptobinding"); + } + ++ if (os_strstr(phase1, "phase2_auth=0")) { ++ data->phase2_auth = NO_AUTH; ++ wpa_printf(MSG_DEBUG, ++ "EAP-PEAP: Do not require Phase 2 authentication"); ++ } else if (os_strstr(phase1, "phase2_auth=1")) { ++ data->phase2_auth = FOR_INITIAL; ++ wpa_printf(MSG_DEBUG, ++ "EAP-PEAP: Require Phase 2 authentication for initial connection"); ++ } else if (os_strstr(phase1, "phase2_auth=2")) { ++ data->phase2_auth = ALWAYS; ++ wpa_printf(MSG_DEBUG, ++ "EAP-PEAP: Require Phase 2 authentication for all cases"); ++ } + #ifdef EAP_TNC + if (os_strstr(phase1, "tnc=soh2")) { + data->soh = 2; +@@ -142,6 +156,7 @@ static void * eap_peap_init(struct eap_sm *sm) + data->force_peap_version = -1; + data->peap_outer_success = 2; + data->crypto_binding = OPTIONAL_BINDING; ++ data->phase2_auth = FOR_INITIAL; + + if (config && config->phase1) + eap_peap_parse_phase1(data, config->phase1); +@@ -454,6 +469,20 @@ static int eap_tlv_validate_cryptobinding(struct eap_sm *sm, + } + + ++static bool peap_phase2_sufficient(struct eap_sm *sm, ++ struct eap_peap_data *data) ++{ ++ if ((data->phase2_auth == ALWAYS || ++ (data->phase2_auth == FOR_INITIAL && ++ !tls_connection_resumed(sm->ssl_ctx, data->ssl.conn) && ++ !data->ssl.client_cert_conf) || ++ data->phase2_eap_started) && ++ !data->phase2_eap_success) ++ return false; ++ return true; ++} ++ ++ + /** + * eap_tlv_process - Process a received EAP-TLV message and generate a response + * @sm: Pointer to EAP state machine allocated with eap_peer_sm_init() +@@ -568,6 +597,11 @@ static int eap_tlv_process(struct eap_sm *sm, struct eap_peap_data *data, + " - force failed Phase 2"); + resp_status = EAP_TLV_RESULT_FAILURE; + ret->decision = DECISION_FAIL; ++ } else if (!peap_phase2_sufficient(sm, data)) { ++ wpa_printf(MSG_INFO, ++ "EAP-PEAP: Server indicated Phase 2 success, but sufficient Phase 2 authentication has not been completed"); ++ resp_status = EAP_TLV_RESULT_FAILURE; ++ ret->decision = DECISION_FAIL; + } else { + resp_status = EAP_TLV_RESULT_SUCCESS; + ret->decision = DECISION_UNCOND_SUCC; +@@ -887,8 +921,7 @@ continue_req: + /* EAP-Success within TLS tunnel is used to indicate + * shutdown of the TLS channel. The authentication has + * been completed. */ +- if (data->phase2_eap_started && +- !data->phase2_eap_success) { ++ if (!peap_phase2_sufficient(sm, data)) { + wpa_printf(MSG_DEBUG, "EAP-PEAP: Phase 2 " + "Success used to indicate success, " + "but Phase 2 EAP was not yet " +@@ -1199,8 +1232,9 @@ static struct wpabuf * eap_peap_process(struct eap_sm *sm, void *priv, + static bool eap_peap_has_reauth_data(struct eap_sm *sm, void *priv) + { + struct eap_peap_data *data = priv; ++ + return tls_connection_established(sm->ssl_ctx, data->ssl.conn) && +- data->phase2_success; ++ data->phase2_success && data->phase2_auth != ALWAYS; + } + + +diff --git a/src/eap_peer/eap_tls_common.c b/src/eap_peer/eap_tls_common.c +index c1837db..a53eeb1 100644 +--- a/src/eap_peer/eap_tls_common.c ++++ b/src/eap_peer/eap_tls_common.c +@@ -239,6 +239,12 @@ static int eap_tls_params_from_conf(struct eap_sm *sm, + + sm->ext_cert_check = !!(params->flags & TLS_CONN_EXT_CERT_CHECK); + ++ if (!phase2) ++ data->client_cert_conf = params->client_cert || ++ params->client_cert_blob || ++ params->private_key || ++ params->private_key_blob; ++ + return 0; + } + +diff --git a/src/eap_peer/eap_tls_common.h b/src/eap_peer/eap_tls_common.h +index 9ac0012..3348634 100644 +--- a/src/eap_peer/eap_tls_common.h ++++ b/src/eap_peer/eap_tls_common.h +@@ -79,6 +79,11 @@ struct eap_ssl_data { + * tls_v13 - Whether TLS v1.3 or newer is used + */ + int tls_v13; ++ ++ /** ++ * client_cert_conf: Whether client certificate has been configured ++ */ ++ bool client_cert_conf; + }; + + +diff --git a/wpa_supplicant/wpa_supplicant.conf b/wpa_supplicant/wpa_supplicant.conf +index 6619d6b..d63f73c 100644 +--- a/wpa_supplicant/wpa_supplicant.conf ++++ b/wpa_supplicant/wpa_supplicant.conf +@@ -1321,6 +1321,13 @@ fast_reauth=1 + # * 0 = do not use cryptobinding (default) + # * 1 = use cryptobinding if server supports it + # * 2 = require cryptobinding ++# 'phase2_auth' option can be used to control Phase 2 (i.e., within TLS ++# tunnel) behavior for PEAP: ++# * 0 = do not require Phase 2 authentication ++# * 1 = require Phase 2 authentication when client certificate ++# (private_key/client_cert) is no used and TLS session resumption was ++# not used (default) ++# * 2 = require Phase 2 authentication in all cases + # EAP-WSC (WPS) uses following options: pin=<Device Password> or + # pbc=1. + # diff --git a/poky/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.10.bb b/poky/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.10.bb index 46604045da..22028ce957 100644 --- a/poky/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.10.bb +++ b/poky/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.10.bb @@ -18,6 +18,7 @@ SRC_URI = "http://w1.fi/releases/wpa_supplicant-${PV}.tar.gz \ file://0001-build-Re-enable-options-for-libwpa_client.so-and-wpa.patch \ file://0002-Fix-removal-of-wpa_passphrase-on-make-clean.patch \ file://0001-Install-wpa_passphrase-when-not-disabled.patch \ + file://0001-PEAP-client-Update-Phase-2-authentication-requiremen.patch \ " SRC_URI[sha256sum] = "20df7ae5154b3830355f8ab4269123a87affdea59fe74fe9292a91d0d7e17b2f" diff --git a/poky/meta/recipes-core/base-passwd/base-passwd_3.6.2.bb b/poky/meta/recipes-core/base-passwd/base-passwd_3.6.3.bb index bb4b49e6ab..9d7703b1c0 100644 --- a/poky/meta/recipes-core/base-passwd/base-passwd_3.6.2.bb +++ b/poky/meta/recipes-core/base-passwd/base-passwd_3.6.3.bb @@ -15,7 +15,7 @@ SRC_URI = "https://launchpad.net/debian/+archive/primary/+files/${BPN}_${PV}.tar file://0001-base-passwd-Add-the-sgx-group.patch \ " -SRC_URI[sha256sum] = "06dc78352bf38a8df76ff295e15ab5654cdefe41e62368b15bfcbbab8e4ec2a0" +SRC_URI[sha256sum] = "83575327d8318a419caf2d543341215c046044073d1afec2acc0ac4d8095ff39" # the package is taken from launchpad; that source is static and goes stale # so we check the latest upstream from a directory that does get updated diff --git a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Do-not-write-bindir-into-pkg-config-files.patch b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Do-not-write-bindir-into-pkg-config-files.patch index 0d44ddf299..0e5f371cb5 100644 --- a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Do-not-write-bindir-into-pkg-config-files.patch +++ b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Do-not-write-bindir-into-pkg-config-files.patch @@ -1,4 +1,4 @@ -From 9ec4eedeb3f67db0bff09f5d859318d05ff47964 Mon Sep 17 00:00:00 2001 +From cf7df91cc8c3b4811235ef8aec144c5f0cf90bdb Mon Sep 17 00:00:00 2001 From: Alexander Kanavin <alex.kanavin@gmail.com> Date: Fri, 15 Feb 2019 11:17:27 +0100 Subject: [PATCH] Do not write $bindir into pkg-config files @@ -16,7 +16,7 @@ Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/gio/meson.build b/gio/meson.build -index a320c0f..86ce7c4 100644 +index 5f91586..1a95f4f 100644 --- a/gio/meson.build +++ b/gio/meson.build @@ -884,14 +884,14 @@ pkg.generate(libgio, diff --git a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Fix-DATADIRNAME-on-uclibc-Linux.patch b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Fix-DATADIRNAME-on-uclibc-Linux.patch index 16f2d31496..1254466063 100644 --- a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Fix-DATADIRNAME-on-uclibc-Linux.patch +++ b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Fix-DATADIRNAME-on-uclibc-Linux.patch @@ -1,4 +1,4 @@ -From c94e669de98a3892c699bd8d0d2b5164b2de747e Mon Sep 17 00:00:00 2001 +From b907a6681c4c24e5d3745538d9fcd471cf1c4c4a Mon Sep 17 00:00:00 2001 From: Khem Raj <raj.khem@gmail.com> Date: Sat, 15 Mar 2014 22:42:29 -0700 Subject: [PATCH] Fix DATADIRNAME on uclibc/Linux @@ -9,7 +9,6 @@ based systems therefore lets set DATADIRNAME to "share". Signed-off-by: Khem Raj <raj.khem@gmail.com> Upstream-Status: Pending - --- m4macros/glib-gettext.m4 | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Install-gio-querymodules-as-libexec_PROGRAM.patch b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Install-gio-querymodules-as-libexec_PROGRAM.patch index 597864d9ac..50d369c24e 100644 --- a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Install-gio-querymodules-as-libexec_PROGRAM.patch +++ b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Install-gio-querymodules-as-libexec_PROGRAM.patch @@ -1,4 +1,4 @@ -From 0015db45cd1bfefc04959dffab5dabeead93136f Mon Sep 17 00:00:00 2001 +From 6e2ddcb5465d10618345b12e0b4471ead0f14304 Mon Sep 17 00:00:00 2001 From: Jussi Kukkonen <jussi.kukkonen@intel.com> Date: Tue, 22 Mar 2016 15:14:58 +0200 Subject: [PATCH] Install gio-querymodules as libexec_PROGRAM @@ -14,10 +14,10 @@ Upstream-Status: Inappropriate [OE specific] 1 file changed, 1 insertion(+) diff --git a/gio/meson.build b/gio/meson.build -index 2ef60ed..532b086 100644 +index f9fdf6e..5f91586 100644 --- a/gio/meson.build +++ b/gio/meson.build -@@ -936,6 +936,7 @@ gio_querymodules = executable('gio-querymodules', 'gio-querymodules.c', 'giomodu +@@ -1005,6 +1005,7 @@ gio_querymodules = executable('gio-querymodules', 'gio-querymodules.c', 'giomodu c_args : gio_c_args, # intl.lib is not compatible with SAFESEH link_args : noseh_link_args, diff --git a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch index 6fd93526ce..f810574d97 100644 --- a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch +++ b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch @@ -1,4 +1,4 @@ -From 4f47b8a8d650d185aa61aec2f56a283522a723c4 Mon Sep 17 00:00:00 2001 +From c8c223045821cac97f798cfa63f19853621a8a2a Mon Sep 17 00:00:00 2001 From: Alexander Kanavin <alex.kanavin@gmail.com> Date: Fri, 12 Jun 2015 17:08:46 +0300 Subject: [PATCH] Remove the warning about deprecated paths in schemas @@ -15,7 +15,7 @@ Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> 1 file changed, 13 deletions(-) diff --git a/gio/glib-compile-schemas.c b/gio/glib-compile-schemas.c -index 7888120..7acbd5b 100644 +index 04ef404..e791ce2 100644 --- a/gio/glib-compile-schemas.c +++ b/gio/glib-compile-schemas.c @@ -1232,19 +1232,6 @@ parse_state_start_schema (ParseState *state, diff --git a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Set-host_machine-correctly-when-building-with-mingw3.patch b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Set-host_machine-correctly-when-building-with-mingw3.patch index 2e1e2313e8..e1d2fb0e54 100644 --- a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Set-host_machine-correctly-when-building-with-mingw3.patch +++ b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-Set-host_machine-correctly-when-building-with-mingw3.patch @@ -1,4 +1,4 @@ -From ba1728bc27c88597164957d000b70ec4be6edf28 Mon Sep 17 00:00:00 2001 +From bafde4eedc0a22b45e73ee6183b9a11393a1e400 Mon Sep 17 00:00:00 2001 From: Alexander Kanavin <alex.kanavin@gmail.com> Date: Wed, 13 Feb 2019 15:32:05 +0100 Subject: [PATCH] Set host_machine correctly when building with mingw32 @@ -13,7 +13,7 @@ Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/gio/tests/meson.build b/gio/tests/meson.build -index f644aa2..64a8684 100644 +index 4ef3343..e498e7e 100644 --- a/gio/tests/meson.build +++ b/gio/tests/meson.build @@ -29,7 +29,7 @@ endif @@ -25,7 +25,7 @@ index f644aa2..64a8684 100644 common_gio_tests_deps += [iphlpapi_dep, winsock2, cc.find_library ('secur32')] endif -@@ -210,7 +210,7 @@ if have_dbus_daemon +@@ -230,7 +230,7 @@ if have_dbus_daemon endif # Test programs buildable on UNIX only @@ -34,7 +34,7 @@ index f644aa2..64a8684 100644 gio_tests += { 'file' : {}, 'gdbus-peer-object-manager' : {}, -@@ -462,7 +462,7 @@ if host_machine.system() != 'windows' +@@ -562,7 +562,7 @@ if host_machine.system() != 'windows' endif # unix # Test programs buildable on Windows only @@ -43,7 +43,7 @@ index f644aa2..64a8684 100644 gio_tests += {'win32-streams' : {}} endif -@@ -532,7 +532,7 @@ if cc.get_id() != 'msvc' and cc.get_id() != 'clang-cl' +@@ -632,7 +632,7 @@ if cc.get_id() != 'msvc' and cc.get_id() != 'clang-cl' } endif @@ -53,10 +53,10 @@ index f644aa2..64a8684 100644 'gdbus-example-unix-fd-client' : { 'install' : false, diff --git a/glib/tests/meson.build b/glib/tests/meson.build -index db01b54..6950817 100644 +index d80c86e..5329cda 100644 --- a/glib/tests/meson.build +++ b/glib/tests/meson.build -@@ -188,7 +188,7 @@ if glib_conf.has('HAVE_EVENTFD') +@@ -216,7 +216,7 @@ if glib_conf.has('HAVE_EVENTFD') } endif @@ -66,10 +66,10 @@ index db01b54..6950817 100644 glib_tests += { 'gpoll' : { diff --git a/meson.build b/meson.build -index 43bb468..5f9b59c 100644 +index f7e936e..122f8b5 100644 --- a/meson.build +++ b/meson.build -@@ -43,6 +43,9 @@ else +@@ -54,6 +54,9 @@ else endif host_system = host_machine.system() diff --git a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch index d33fdd4d8b..e4c2f77459 100644 --- a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch +++ b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch @@ -1,4 +1,4 @@ -From 92de6c7eb30b961b24a2dce812d5276487b7d23d Mon Sep 17 00:00:00 2001 +From 3f05b9418c88bbb83c08b57cc5529b006f26fff4 Mon Sep 17 00:00:00 2001 From: Alexander Kanavin <alex.kanavin@gmail.com> Date: Wed, 8 Jan 2020 18:22:46 +0100 Subject: [PATCH] gio/tests/resources.c: comment out a build host-only test @@ -14,10 +14,10 @@ Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gio/tests/resources.c b/gio/tests/resources.c -index c44d214..e289a01 100644 +index f567914..b21b616 100644 --- a/gio/tests/resources.c +++ b/gio/tests/resources.c -@@ -993,7 +993,7 @@ main (int argc, +@@ -1068,7 +1068,7 @@ main (int argc, g_test_add_func ("/resource/automatic", test_resource_automatic); /* This only uses automatic resources too, so it tests the constructors and destructors */ g_test_add_func ("/resource/module", test_resource_module); diff --git a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-meson-Run-atomics-test-on-clang-as-well.patch b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-meson-Run-atomics-test-on-clang-as-well.patch index 44482dd2b7..071e4a7c4d 100644 --- a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-meson-Run-atomics-test-on-clang-as-well.patch +++ b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-meson-Run-atomics-test-on-clang-as-well.patch @@ -1,4 +1,4 @@ -From 4b97f457b7b44117e27d2a218c4b68e7fe3fe4ce Mon Sep 17 00:00:00 2001 +From 17d718640ae6f953e5eea714c1bd64eeb6e4799f Mon Sep 17 00:00:00 2001 From: Khem Raj <raj.khem@gmail.com> Date: Sat, 12 Oct 2019 17:46:26 -0700 Subject: [PATCH] meson: Run atomics test on clang as well @@ -15,10 +15,10 @@ Signed-off-by: Khem Raj <raj.khem@gmail.com> 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meson.build b/meson.build -index afb6eaa..6aa70f5 100644 +index 122f8b5..f055079 100644 --- a/meson.build +++ b/meson.build -@@ -1692,7 +1692,7 @@ atomicdefine = ''' +@@ -1938,7 +1938,7 @@ atomicdefine = ''' # We know that we can always use real ("lock free") atomic operations with MSVC if cc.get_id() == 'msvc' or cc.get_id() == 'clang-cl' or cc.links(atomictest, name : 'atomic ops') have_atomic_lock_free = true diff --git a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-meson.build-do-not-enable-pidfd-features-on-native-g.patch b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-meson.build-do-not-enable-pidfd-features-on-native-g.patch index 788f420d11..e03f9a3c84 100644 --- a/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-meson.build-do-not-enable-pidfd-features-on-native-g.patch +++ b/poky/meta/recipes-core/glib-2.0/glib-2.0/0001-meson.build-do-not-enable-pidfd-features-on-native-g.patch @@ -1,4 +1,4 @@ -From 9aa9574861fad39d0679025e35fe1e188345f685 Mon Sep 17 00:00:00 2001 +From 7865d698b5d392aac3a3d32e9ebd5fea45017d15 Mon Sep 17 00:00:00 2001 From: Alexander Kanavin <alex@linutronix.de> Date: Sat, 16 Sep 2023 22:28:27 +0200 Subject: [PATCH] meson.build: do not enable pidfd features on native glib @@ -9,12 +9,13 @@ where these features are not implemented. Upstream-Status: Inappropriate [oe-core specific] Signed-off-by: Alexander Kanavin <alex@linutronix.de> + --- meson.build | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meson.build b/meson.build -index 1c36993..bbf97fc 100644 +index f055079..77d78aa 100644 --- a/meson.build +++ b/meson.build @@ -981,7 +981,8 @@ if cc.links('''#include <sys/syscall.h> @@ -27,6 +28,3 @@ index 1c36993..bbf97fc 100644 endif # Check for __uint128_t (gcc) by checking for 128-bit division --- -2.30.2 - diff --git a/poky/meta/recipes-core/glib-2.0/glib-2.0/0010-Do-not-hardcode-python-path-into-various-tools.patch b/poky/meta/recipes-core/glib-2.0/glib-2.0/0010-Do-not-hardcode-python-path-into-various-tools.patch index 1c645f3a9a..4b75167da6 100644 --- a/poky/meta/recipes-core/glib-2.0/glib-2.0/0010-Do-not-hardcode-python-path-into-various-tools.patch +++ b/poky/meta/recipes-core/glib-2.0/glib-2.0/0010-Do-not-hardcode-python-path-into-various-tools.patch @@ -1,4 +1,4 @@ -From 79ce7e545dd3a93f77d2146d50b6fa061fbceed9 Mon Sep 17 00:00:00 2001 +From 53bcd4b6cd3fe3fe4246914462e6724761eecf51 Mon Sep 17 00:00:00 2001 From: Alexander Kanavin <alex.kanavin@gmail.com> Date: Tue, 3 Oct 2017 10:45:55 +0300 Subject: [PATCH] Do not hardcode python path into various tools @@ -23,7 +23,7 @@ index 67d3675..4e92a7a 100755 # GDBus - GLib D-Bus Library # diff --git a/gobject/glib-genmarshal.in b/gobject/glib-genmarshal.in -index 7380f24..c8abeaa 100755 +index aa5af43..56e8e2e 100755 --- a/gobject/glib-genmarshal.in +++ b/gobject/glib-genmarshal.in @@ -1,4 +1,4 @@ @@ -33,7 +33,7 @@ index 7380f24..c8abeaa 100755 # pylint: disable=too-many-lines, missing-docstring, invalid-name diff --git a/gobject/glib-mkenums.in b/gobject/glib-mkenums.in -index 91ad779..3ebef62 100755 +index 353e53a..8ed6c39 100755 --- a/gobject/glib-mkenums.in +++ b/gobject/glib-mkenums.in @@ -1,4 +1,4 @@ diff --git a/poky/meta/recipes-core/glib-2.0/glib-2.0/relocate-modules.patch b/poky/meta/recipes-core/glib-2.0/glib-2.0/relocate-modules.patch index 841fedef8a..95a73298d8 100644 --- a/poky/meta/recipes-core/glib-2.0/glib-2.0/relocate-modules.patch +++ b/poky/meta/recipes-core/glib-2.0/glib-2.0/relocate-modules.patch @@ -1,4 +1,4 @@ -From b90d13900dd2777c2ab90c5b0be1a872c10a17da Mon Sep 17 00:00:00 2001 +From 03a069cb8066d3e8ef72a43f7b1db5c9625e9cc2 Mon Sep 17 00:00:00 2001 From: Ross Burton <ross.burton@intel.com> Date: Fri, 11 Mar 2016 15:35:55 +0000 Subject: [PATCH] glib-2.0: relocate the GIO module directory for native builds diff --git a/poky/meta/recipes-core/glib-2.0/glib-2.0_2.78.1.bb b/poky/meta/recipes-core/glib-2.0/glib-2.0_2.78.3.bb index a490262112..13d4b38e22 100644 --- a/poky/meta/recipes-core/glib-2.0/glib-2.0_2.78.1.bb +++ b/poky/meta/recipes-core/glib-2.0/glib-2.0_2.78.3.bb @@ -19,7 +19,7 @@ SRC_URI:append:class-native = " file://relocate-modules.patch \ file://0001-meson.build-do-not-enable-pidfd-features-on-native-g.patch \ " -SRC_URI[sha256sum] = "915bc3d0f8507d650ead3832e2f8fb670fce59aac4d7754a7dab6f1e6fed78b2" +SRC_URI[sha256sum] = "609801dd373796e515972bf95fc0b2daa44545481ee2f465c4f204d224b2bc21" # Find any meson cross files in FILESPATH that are relevant for the current # build (using siteinfo) and add them to EXTRA_OEMESON. diff --git a/poky/meta/recipes-core/glibc/glibc-version.inc b/poky/meta/recipes-core/glibc/glibc-version.inc index 0ef4289557..ee89762ae6 100644 --- a/poky/meta/recipes-core/glibc/glibc-version.inc +++ b/poky/meta/recipes-core/glibc/glibc-version.inc @@ -1,6 +1,6 @@ SRCBRANCH ?= "release/2.38/master" PV = "2.38+git" -SRCREV_glibc ?= "44f757a6364a546359809d48c76b3debd26e77d4" +SRCREV_glibc ?= "d37c2b20a4787463d192b32041c3406c2bd91de0" SRCREV_localedef ?= "e0eca29583b9e0f62645c4316ced93cf4e4e26e1" GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git;protocol=https" @@ -10,4 +10,8 @@ UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>\d+\.\d+(\.(?!90)\d+)*)" CVE_STATUS[CVE-2023-4527] = "fixed-version: Fixed in stable branch updates" CVE_STATUS[CVE-2023-4911] = "fixed-version: Fixed in stable branch updates" CVE_STATUS[CVE-2023-4806] = "fixed-version: Fixed in stable branch updates" -CVE_STATUS[CVE-2023-4527] = "fixed-version: Fixed in stable branch updates" +CVE_STATUS[CVE-2023-5156] = "fixed-version: Fixed in stable branch updates" +CVE_STATUS[CVE-2023-0687] = "fixed-version: Fixed in stable branch updates" +CVE_STATUS[CVE-2023-6246] = "fixed-version: Fixed in stable branch updates" +CVE_STATUS[CVE-2023-6779] = "fixed-version: Fixed in stable branch updates" +CVE_STATUS[CVE-2023-6780] = "fixed-version: Fixed in stable branch updates" diff --git a/poky/meta/recipes-core/glibc/glibc/run-ptest b/poky/meta/recipes-core/glibc/glibc/run-ptest index c394b49866..cb71c75682 100755 --- a/poky/meta/recipes-core/glibc/glibc/run-ptest +++ b/poky/meta/recipes-core/glibc/glibc/run-ptest @@ -22,12 +22,12 @@ tst_time64=$(ls -r ${PWD}/tests/glibc-ptest/*-time64) # related tst_time_tmp=$(sed -e "s/-time64$//" <<< ${tst_time64}) -# Run tests supporting only 32 bit time -for i in ${tst_time_tmp} -do - $i >/dev/null 2>&1 - output -done +# Do not run tests supporting only 32 bit time +#for i in ${tst_time_tmp} +#do +# $i >/dev/null 2>&1 +# output +#done # Run tests supporting only 64 bit time for i in ${tst_time64} 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 3a049b8e37..07764a1826 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 @@ -26,7 +26,7 @@ inherit core-image setuptools3 features_check REQUIRED_DISTRO_FEATURES += "xattr" -SRCREV ?= "59e8c565ef9cddb4cab90017d187368aa34f361b" +SRCREV ?= "8730750b335c2eb9c3af673262dd83f4a861e075" SRC_URI = "git://git.yoctoproject.org/poky;branch=nanbield \ file://Yocto_Build_Appliance.vmx \ file://Yocto_Build_Appliance.vmxf \ diff --git a/poky/meta/recipes-core/images/core-image-ptest.bb b/poky/meta/recipes-core/images/core-image-ptest.bb index b6f5c2fd60..f2d0ae94b8 100644 --- a/poky/meta/recipes-core/images/core-image-ptest.bb +++ b/poky/meta/recipes-core/images/core-image-ptest.bb @@ -21,7 +21,7 @@ BBCLASSEXTEND = "${@' '.join(['mcextend:'+x for x in d.getVar('PTESTS').split()] IMAGE_OVERHEAD_FACTOR = "1.0" IMAGE_ROOTFS_EXTRA_SPACE = "324288" IMAGE_ROOTFS_EXTRA_SPACE:virtclass-mcextend-mdadm = "1524288" -IMAGE_ROOTFS_EXTRA_SPACE:virtclass-mcextend-strace = "1024288" +IMAGE_ROOTFS_EXTRA_SPACE:virtclass-mcextend-strace = "1524288" IMAGE_ROOTFS_EXTRA_SPACE:virtclass-mcextend-lttng-tools = "1524288" # tar-ptest in particular needs more space diff --git a/poky/meta/recipes-core/libxml/libxml2_2.11.5.bb b/poky/meta/recipes-core/libxml/libxml2_2.11.7.bb index fc82912df2..482ce9042d 100644 --- a/poky/meta/recipes-core/libxml/libxml2_2.11.5.bb +++ b/poky/meta/recipes-core/libxml/libxml2_2.11.7.bb @@ -18,7 +18,7 @@ SRC_URI += "http://www.w3.org/XML/Test/xmlts20130923.tar;subdir=${BP};name=testt file://install-tests.patch \ " -SRC_URI[archive.sha256sum] = "3727b078c360ec69fa869de14bd6f75d7ee8d36987b071e6928d4720a28df3a6" +SRC_URI[archive.sha256sum] = "fb27720e25eaf457f94fd3d7189bcf2626c6dccf4201553bc8874d50e3560162" SRC_URI[testtar.sha256sum] = "c6b2d42ee50b8b236e711a97d68e6c4b5c8d83e69a2be4722379f08702ea7273" # Disputed as a security issue, but fixed in d39f780 diff --git a/poky/meta/recipes-core/meta/cve-update-nvd2-native.bb b/poky/meta/recipes-core/meta/cve-update-nvd2-native.bb index bfe48b27e7..1901641965 100644 --- a/poky/meta/recipes-core/meta/cve-update-nvd2-native.bb +++ b/poky/meta/recipes-core/meta/cve-update-nvd2-native.bb @@ -26,13 +26,17 @@ NVDCVE_API_KEY ?= "" # Use a negative value to skip the update CVE_DB_UPDATE_INTERVAL ?= "86400" -# Number of attmepts for each http query to nvd server before giving up +# CVE database incremental update age threshold, in seconds. If the database is +# older than this threshold, do a full re-download, else, do an incremental +# update. By default: the maximum allowed value from NVD: 120 days (120*24*60*60) +# Use 0 to force a full download. +CVE_DB_INCR_UPDATE_AGE_THRES ?= "10368000" + +# Number of attempts for each http query to nvd server before giving up CVE_DB_UPDATE_ATTEMPTS ?= "5" CVE_DB_TEMP_FILE ?= "${CVE_CHECK_DB_DIR}/temp_nvdcve_2.db" -CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvdcve_2.db" - python () { if not bb.data.inherits_class("cve-check", d): raise bb.parse.SkipRecipe("Skip recipe when cve-check class is not loaded.") @@ -119,7 +123,8 @@ def nvd_request_wait(attempt, min_wait): def nvd_request_next(url, attempts, api_key, args, min_wait): """ - Request next part of the NVD dabase + Request next part of the NVD database + NVD API documentation: https://nvd.nist.gov/developers/vulnerabilities """ import urllib.request @@ -172,18 +177,24 @@ def update_db_file(db_tmp_file, d, database_time): req_args = {'startIndex' : 0} - # The maximum range for time is 120 days - # Force a complete update if our range is longer - if (database_time != 0): + incr_update_threshold = int(d.getVar("CVE_DB_INCR_UPDATE_AGE_THRES")) + if database_time != 0: database_date = datetime.datetime.fromtimestamp(database_time, tz=datetime.timezone.utc) today_date = datetime.datetime.now(tz=datetime.timezone.utc) delta = today_date - database_date - if delta.days < 120: + if incr_update_threshold == 0: + bb.note("CVE database: forced full update") + elif delta < datetime.timedelta(seconds=incr_update_threshold): bb.note("CVE database: performing partial update") + # The maximum range for time is 120 days + if delta > datetime.timedelta(days=120): + bb.error("CVE database: Trying to do an incremental update on a larger than supported range") req_args['lastModStartDate'] = database_date.isoformat() req_args['lastModEndDate'] = today_date.isoformat() else: bb.note("CVE database: file too old, forcing a full update") + else: + bb.note("CVE database: no preexisting database, do a full download") with bb.progress.ProgressHandler(d) as ph, open(os.path.join(d.getVar("TMPDIR"), 'cve_check'), 'a') as cve_f: @@ -313,6 +324,10 @@ def update_db(conn, elt): vectorString = None cveId = elt['cve']['id'] if elt['cve']['vulnStatus'] == "Rejected": + c = conn.cursor() + c.execute("delete from PRODUCTS where ID = ?;", [cveId]) + c.execute("delete from NVD where ID = ?;", [cveId]) + c.close() return cveDesc = "" for desc in elt['cve']['descriptions']: @@ -346,6 +361,10 @@ def update_db(conn, elt): [cveId, cveDesc, cvssv2, cvssv3, date, accessVector, vectorString]).close() try: + # Remove any pre-existing CVE configuration. Even for partial database + # update, those will be repopulated. This ensures that old + # configuration is not kept for an updated CVE. + conn.execute("delete from PRODUCTS where ID = ?", [cveId]).close() for config in elt['cve']['configurations']: # This is suboptimal as it doesn't handle AND/OR and negate, but is better than nothing for node in config["nodes"]: diff --git a/poky/meta/recipes-core/ncurses/files/0001-Updating-reset-code-ncurses-6.4-patch-20231104.patch b/poky/meta/recipes-core/ncurses/files/0001-Updating-reset-code-ncurses-6.4-patch-20231104.patch new file mode 100644 index 0000000000..121db6bffe --- /dev/null +++ b/poky/meta/recipes-core/ncurses/files/0001-Updating-reset-code-ncurses-6.4-patch-20231104.patch @@ -0,0 +1,499 @@ +From 135d37072755704b8d018e5de74e62ff3f28c930 Mon Sep 17 00:00:00 2001 +From: Thomas E. Dickey <dickey@invisible-island.net> +Date: Sun, 5 Nov 2023 05:54:54 +0530 +Subject: [PATCH] Updating reset code - ncurses 6.4 - patch 20231104 + ++ modify reset command to avoid altering clocal if the terminal uses a + modem (prompted by discussion with Werner Fink, Michal Suchanek, + OpenSUSE #1201384, Debian #60377). ++ build-fixes for --with-caps variations. ++ correct a couple of section-references in INSTALL. + +Signed-off-by: Thomas E. Dickey <dickey@invisible-island.net> + +Upstream-Status: Backport [https://ncurses.scripts.mit.edu/?p=ncurses.git;a=commitdiff;h=135d37072755704b8d018e5de74e62ff3f28c930] + +Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com> +--- + INSTALL | 8 +- + include/curses.events | 2 +- + ncurses/tinfo/lib_tparm.c | 2 + + progs/reset_cmd.c | 281 +++++++++++++++++++++----------------- + progs/tabs.c | 10 +- + progs/tic.c | 4 + + 6 files changed, 176 insertions(+), 131 deletions(-) + +diff --git a/INSTALL b/INSTALL +index d9c1dd12..d0a39af0 100644 +--- a/INSTALL ++++ b/INSTALL +@@ -47,7 +47,7 @@ If you are converting from BSD curses and do not have root access, be sure + to read the BSD CONVERSION NOTES section below. + + If you are trying to build applications using gpm with ncurses, +-read the USING NCURSES WITH GPM section below. ++read the USING GPM section below. + + If you are cross-compiling, see the note below on BUILDING WITH A CROSS-COMPILER. + +@@ -79,7 +79,7 @@ INSTALLATION PROCEDURE: + The --prefix option to configure changes the root directory for installing + ncurses. The default is normally in subdirectories of /usr/local, except + for systems where ncurses is normally installed as a system library (see +- "IF YOU ARE A SYSTEM INTEGRATOR"). Use --prefix=/usr to replace your ++ "FOR SYSTEM INTEGRATORS"). Use --prefix=/usr to replace your + default curses distribution. + + The package gets installed beneath the --prefix directory as follows: +@@ -176,7 +176,7 @@ INSTALLATION PROCEDURE: + You can make curses and terminfo fall back to an existing file of termcap + definitions by configuring with --enable-termcap. If you do this, the + library will search /etc/termcap before the terminfo database, and will +- also interpret the contents of the TERM environment variable. See the ++ also interpret the contents of the $TERM environment variable. See the + section BSD CONVERSION NOTES below. + + 3. Type `make'. Ignore any warnings, no error messages should be produced. +@@ -1231,7 +1231,7 @@ CONFIGURE OPTIONS: + Specify a search-list of terminfo directories which will be compiled + into the ncurses library (default: DATADIR/terminfo) + +- This is a colon-separated list, like the TERMINFO_DIRS environment ++ This is a colon-separated list, like the $TERMINFO_DIRS environment + variable. + + --with-termlib[=XXX] +diff --git a/include/curses.events b/include/curses.events +index 25a2583f..468bde18 100644 +--- a/include/curses.events ++++ b/include/curses.events +@@ -50,6 +50,6 @@ typedef struct + extern NCURSES_EXPORT(int) wgetch_events (WINDOW *, _nc_eventlist *) GCC_DEPRECATED(experimental option); /* experimental */ + extern NCURSES_EXPORT(int) wgetnstr_events (WINDOW *,char *,int,_nc_eventlist *) GCC_DEPRECATED(experimental option); /* experimental */ + +-#define KEY_EVENT 0633 /* We were interrupted by an event */ ++#define KEY_EVENT 0634 /* We were interrupted by an event */ + + #endif /* NCURSES_WGETCH_EVENTS */ +diff --git a/ncurses/tinfo/lib_tparm.c b/ncurses/tinfo/lib_tparm.c +index a10a3877..cd972c0f 100644 +--- a/ncurses/tinfo/lib_tparm.c ++++ b/ncurses/tinfo/lib_tparm.c +@@ -1113,8 +1113,10 @@ check_string_caps(TPARM_DATA *data, const char *string) + want_type = 2; /* function key #1, transmit string #2 */ + else if (CHECK_CAP(plab_norm)) + want_type = 2; /* label #1, show string #2 */ ++#ifdef pkey_plab + else if (CHECK_CAP(pkey_plab)) + want_type = 6; /* function key #1, type string #2, show string #3 */ ++#endif + #if NCURSES_XNAMES + else { + char *check; +diff --git a/progs/reset_cmd.c b/progs/reset_cmd.c +index eff3af72..aec4b077 100644 +--- a/progs/reset_cmd.c ++++ b/progs/reset_cmd.c +@@ -75,6 +75,9 @@ MODULE_ID("$Id: reset_cmd.c,v 1.28 2021/10/02 18:08:44 tom Exp $") + # endif + #endif + ++#define set_flags(target, mask) target |= mask ++#define clear_flags(target, mask) target &= ~((unsigned)(mask)) ++ + static FILE *my_file; + + static bool use_reset = FALSE; /* invoked as reset */ +@@ -188,6 +191,79 @@ out_char(int c) + #define reset_char(item, value) \ + tty_settings->c_cc[item] = CHK(tty_settings->c_cc[item], value) + ++/* ++ * Simplify ifdefs ++ */ ++#ifndef BSDLY ++#define BSDLY 0 ++#endif ++#ifndef CRDLY ++#define CRDLY 0 ++#endif ++#ifndef ECHOCTL ++#define ECHOCTL 0 ++#endif ++#ifndef ECHOKE ++#define ECHOKE 0 ++#endif ++#ifndef ECHOPRT ++#define ECHOPRT 0 ++#endif ++#ifndef FFDLY ++#define FFDLY 0 ++#endif ++#ifndef IMAXBEL ++#define IMAXBEL 0 ++#endif ++#ifndef IUCLC ++#define IUCLC 0 ++#endif ++#ifndef IXANY ++#define IXANY 0 ++#endif ++#ifndef NLDLY ++#define NLDLY 0 ++#endif ++#ifndef OCRNL ++#define OCRNL 0 ++#endif ++#ifndef OFDEL ++#define OFDEL 0 ++#endif ++#ifndef OFILL ++#define OFILL 0 ++#endif ++#ifndef OLCUC ++#define OLCUC 0 ++#endif ++#ifndef ONLCR ++#define ONLCR 0 ++#endif ++#ifndef ONLRET ++#define ONLRET 0 ++#endif ++#ifndef ONOCR ++#define ONOCR 0 ++#endif ++#ifndef OXTABS ++#define OXTABS 0 ++#endif ++#ifndef TAB3 ++#define TAB3 0 ++#endif ++#ifndef TABDLY ++#define TABDLY 0 ++#endif ++#ifndef TOSTOP ++#define TOSTOP 0 ++#endif ++#ifndef VTDLY ++#define VTDLY 0 ++#endif ++#ifndef XCASE ++#define XCASE 0 ++#endif ++ + /* + * Reset the terminal mode bits to a sensible state. Very useful after + * a child program dies in raw mode. +@@ -195,6 +271,10 @@ out_char(int c) + void + reset_tty_settings(int fd, TTY * tty_settings, int noset) + { ++ unsigned mask; ++#ifdef TIOCMGET ++ int modem_bits; ++#endif + GET_TTY(fd, tty_settings); + + #ifdef TERMIOS +@@ -228,106 +308,65 @@ reset_tty_settings(int fd, TTY * tty_settings, int noset) + reset_char(VWERASE, CWERASE); + #endif + +- tty_settings->c_iflag &= ~((unsigned) (IGNBRK +- | PARMRK +- | INPCK +- | ISTRIP +- | INLCR +- | IGNCR +-#ifdef IUCLC +- | IUCLC +-#endif +-#ifdef IXANY +- | IXANY +-#endif +- | IXOFF)); +- +- tty_settings->c_iflag |= (BRKINT +- | IGNPAR +- | ICRNL +- | IXON +-#ifdef IMAXBEL +- | IMAXBEL +-#endif +- ); +- +- tty_settings->c_oflag &= ~((unsigned) (0 +-#ifdef OLCUC +- | OLCUC +-#endif +-#ifdef OCRNL +- | OCRNL +-#endif +-#ifdef ONOCR +- | ONOCR +-#endif +-#ifdef ONLRET +- | ONLRET +-#endif +-#ifdef OFILL +- | OFILL +-#endif +-#ifdef OFDEL +- | OFDEL +-#endif +-#ifdef NLDLY +- | NLDLY +-#endif +-#ifdef CRDLY +- | CRDLY +-#endif +-#ifdef TABDLY +- | TABDLY +-#endif +-#ifdef BSDLY +- | BSDLY +-#endif +-#ifdef VTDLY +- | VTDLY +-#endif +-#ifdef FFDLY +- | FFDLY +-#endif +- )); +- +- tty_settings->c_oflag |= (OPOST +-#ifdef ONLCR +- | ONLCR +-#endif +- ); +- +- tty_settings->c_cflag &= ~((unsigned) (CSIZE +- | CSTOPB +- | PARENB +- | PARODD +- | CLOCAL)); +- tty_settings->c_cflag |= (CS8 | CREAD); +- tty_settings->c_lflag &= ~((unsigned) (ECHONL +- | NOFLSH +-#ifdef TOSTOP +- | TOSTOP +-#endif +-#ifdef ECHOPTR +- | ECHOPRT +-#endif +-#ifdef XCASE +- | XCASE +-#endif +- )); +- +- tty_settings->c_lflag |= (ISIG +- | ICANON +- | ECHO +- | ECHOE +- | ECHOK +-#ifdef ECHOCTL +- | ECHOCTL +-#endif +-#ifdef ECHOKE +- | ECHOKE +-#endif +- ); +-#endif ++ clear_flags(tty_settings->c_iflag, (IGNBRK ++ | PARMRK ++ | INPCK ++ | ISTRIP ++ | INLCR ++ | IGNCR ++ | IUCLC ++ | IXANY ++ | IXOFF)); ++ ++ set_flags(tty_settings->c_iflag, (BRKINT ++ | IGNPAR ++ | ICRNL ++ | IXON ++ | IMAXBEL)); ++ ++ clear_flags(tty_settings->c_oflag, (0 ++ | OLCUC ++ | OCRNL ++ | ONOCR ++ | ONLRET ++ | OFILL ++ | OFDEL ++ | NLDLY ++ | CRDLY ++ | TABDLY ++ | BSDLY ++ | VTDLY ++ | FFDLY)); ++ ++ set_flags(tty_settings->c_oflag, (OPOST ++ | ONLCR)); ++ ++ mask = (CSIZE | CSTOPB | PARENB | PARODD); ++#ifdef TIOCMGET ++ /* leave clocal alone if this appears to use a modem */ ++ if (ioctl(fd, TIOCMGET, &modem_bits) == -1) ++ mask |= CLOCAL; ++#else ++ /* cannot check - use the behavior from tset */ ++ mask |= CLOCAL; ++#endif ++ clear_flags(tty_settings->c_cflag, mask); ++ ++ set_flags(tty_settings->c_cflag, (CS8 | CREAD)); ++ clear_flags(tty_settings->c_lflag, (ECHONL ++ | NOFLSH ++ | TOSTOP ++ | ECHOPRT ++ | XCASE)); ++ ++ set_flags(tty_settings->c_lflag, (ISIG ++ | ICANON ++ | ECHO ++ | ECHOE ++ | ECHOK ++ | ECHOCTL ++ | ECHOKE)); ++#endif /* TERMIOS */ + + if (!noset) { + SET_TTY(fd, tty_settings); +@@ -402,29 +441,23 @@ set_conversions(TTY * tty_settings) + #if defined(EXP_WIN32_DRIVER) + /* FIXME */ + #else +-#ifdef ONLCR +- tty_settings->c_oflag |= ONLCR; +-#endif +- tty_settings->c_iflag |= ICRNL; +- tty_settings->c_lflag |= ECHO; +-#ifdef OXTABS +- tty_settings->c_oflag |= OXTABS; +-#endif /* OXTABS */ ++ set_flags(tty_settings->c_oflag, ONLCR); ++ set_flags(tty_settings->c_iflag, ICRNL); ++ set_flags(tty_settings->c_lflag, ECHO); ++ set_flags(tty_settings->c_oflag, OXTABS); + + /* test used to be tgetflag("NL") */ + if (VALID_STRING(newline) && newline[0] == '\n' && !newline[1]) { + /* Newline, not linefeed. */ +-#ifdef ONLCR +- tty_settings->c_oflag &= ~((unsigned) ONLCR); +-#endif +- tty_settings->c_iflag &= ~((unsigned) ICRNL); ++ clear_flags(tty_settings->c_oflag, ONLCR); ++ clear_flags(tty_settings->c_iflag, ICRNL); + } +-#ifdef OXTABS ++#if OXTABS + /* test used to be tgetflag("pt") */ + if (VALID_STRING(set_tab) && VALID_STRING(clear_all_tabs)) +- tty_settings->c_oflag &= ~OXTABS; ++ clear_flags(tty_settings->c_oflag, OXTABS); + #endif /* OXTABS */ +- tty_settings->c_lflag |= (ECHOE | ECHOK); ++ set_flags(tty_settings->c_lflag, (ECHOE | ECHOK)); + #endif + } + +@@ -490,7 +523,7 @@ send_init_strings(int fd GCC_UNUSED, TTY * old_settings) + bool need_flush = FALSE; + + (void) old_settings; +-#ifdef TAB3 ++#if TAB3 + if (old_settings != 0 && + old_settings->c_oflag & (TAB3 | ONLCR | OCRNL | ONLRET)) { + old_settings->c_oflag &= (TAB3 | ONLCR | OCRNL | ONLRET); +@@ -512,22 +545,22 @@ send_init_strings(int fd GCC_UNUSED, TTY * old_settings) + + if (VALID_STRING(clear_margins)) { + need_flush |= sent_string(clear_margins); +- } else ++ } + #if defined(set_lr_margin) +- if (VALID_STRING(set_lr_margin)) { ++ else if (VALID_STRING(set_lr_margin)) { + need_flush |= sent_string(TIPARM_2(set_lr_margin, 0, columns - 1)); +- } else ++ } + #endif + #if defined(set_left_margin_parm) && defined(set_right_margin_parm) +- if (VALID_STRING(set_left_margin_parm) +- && VALID_STRING(set_right_margin_parm)) { ++ else if (VALID_STRING(set_left_margin_parm) ++ && VALID_STRING(set_right_margin_parm)) { + need_flush |= sent_string(TIPARM_1(set_left_margin_parm, 0)); + need_flush |= sent_string(TIPARM_1(set_right_margin_parm, + columns - 1)); +- } else ++ } + #endif +- if (VALID_STRING(set_left_margin) +- && VALID_STRING(set_right_margin)) { ++ else if (VALID_STRING(set_left_margin) ++ && VALID_STRING(set_right_margin)) { + need_flush |= to_left_margin(); + need_flush |= sent_string(set_left_margin); + if (VALID_STRING(parm_right_cursor)) { +diff --git a/progs/tabs.c b/progs/tabs.c +index 7378d116..d904330b 100644 +--- a/progs/tabs.c ++++ b/progs/tabs.c +@@ -370,7 +370,9 @@ do_set_margin(int margin, bool no_op) + } + tputs(set_left_margin, 1, putch); + } +- } else if (VALID_STRING(set_left_margin_parm)) { ++ } ++#if defined(set_left_margin_parm) && defined(set_right_margin_parm) ++ else if (VALID_STRING(set_left_margin_parm)) { + result = TRUE; + if (!no_op) { + if (VALID_STRING(set_right_margin_parm)) { +@@ -379,12 +381,16 @@ do_set_margin(int margin, bool no_op) + tputs(TIPARM_2(set_left_margin_parm, margin, max_cols), 1, putch); + } + } +- } else if (VALID_STRING(set_lr_margin)) { ++ } ++#endif ++#if defined(set_lr_margin) ++ else if (VALID_STRING(set_lr_margin)) { + result = TRUE; + if (!no_op) { + tputs(TIPARM_2(set_lr_margin, margin, max_cols), 1, putch); + } + } ++#endif + return result; + } + +diff --git a/progs/tic.c b/progs/tic.c +index 888927e2..78b568fa 100644 +--- a/progs/tic.c ++++ b/progs/tic.c +@@ -3142,6 +3142,7 @@ guess_ANSI_VTxx(TERMTYPE2 *tp) + * In particular, any ECMA-48 terminal should support these, though the details + * for u9 are implementation dependent. + */ ++#if defined(user6) && defined(user7) && defined(user8) && defined(user9) + static void + check_user_6789(TERMTYPE2 *tp) + { +@@ -3177,6 +3178,9 @@ check_user_6789(TERMTYPE2 *tp) + break; + } + } ++#else ++#define check_user_6789(tp) /* nothing */ ++#endif + + /* other sanity-checks (things that we don't want in the normal + * logic that reads a terminfo entry) +-- +2.40.0 diff --git a/poky/meta/recipes-core/ncurses/ncurses_6.4.bb b/poky/meta/recipes-core/ncurses/ncurses_6.4.bb index 388cd8d407..2c621525f9 100644 --- a/poky/meta/recipes-core/ncurses/ncurses_6.4.bb +++ b/poky/meta/recipes-core/ncurses/ncurses_6.4.bb @@ -5,6 +5,7 @@ SRC_URI += "file://0001-tic-hang.patch \ file://0003-gen-pkgconfig.in-Do-not-include-LDFLAGS-in-generated.patch \ file://exit_prototype.patch \ file://0001-Fix-CVE-2023-29491.patch \ + file://0001-Updating-reset-code-ncurses-6.4-patch-20231104.patch \ " # commit id corresponds to the revision in package version SRCREV = "79b9071f2be20a24c7be031655a5638f6032f29f" diff --git a/poky/meta/recipes-core/udev/udev-extraconf/mount.sh b/poky/meta/recipes-core/udev/udev-extraconf/mount.sh index b7e86dbc0e..6cb0a9fea8 100644 --- a/poky/meta/recipes-core/udev/udev-extraconf/mount.sh +++ b/poky/meta/recipes-core/udev/udev-extraconf/mount.sh @@ -196,7 +196,7 @@ if [ "$ACTION" = "remove" ] || [ "$ACTION" = "change" ] && [ -x "$UMOUNT" ] && [ logger "mount.sh/remove" "cleaning up $DEVNAME, was mounted by the auto-mounter" for mnt in `cat /proc/mounts | grep "$DEVNAME" | cut -f 2 -d " " ` do - $UMOUNT $mnt + $UMOUNT "`printf $mnt`" done # Remove mount directory created by the auto-mounter # and clean up our tmp cache file diff --git a/poky/meta/recipes-core/zlib/zlib_1.3.bb b/poky/meta/recipes-core/zlib/zlib_1.3.bb index 1ed18172fa..ede75f90bd 100644 --- a/poky/meta/recipes-core/zlib/zlib_1.3.bb +++ b/poky/meta/recipes-core/zlib/zlib_1.3.bb @@ -47,3 +47,4 @@ do_install_ptest() { BBCLASSEXTEND = "native nativesdk" CVE_STATUS[CVE-2023-45853] = "not-applicable-config: we don't build minizip" +CVE_STATUS[CVE-2023-6992] = "cpe-incorrect: this CVE is for cloudflare zlib" diff --git a/poky/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake b/poky/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake index d6a1e0464c..6434b27371 100644 --- a/poky/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake +++ b/poky/meta/recipes-devtools/cmake/cmake/OEToolchainConfig.cmake @@ -18,3 +18,6 @@ file( GLOB toolchain_config_files "${CMAKE_CURRENT_LIST_FILE}.d/*.cmake" ) foreach(config ${toolchain_config_files}) include(${config}) endforeach() + +unset(CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES) +unset(CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES) diff --git a/poky/meta/recipes-devtools/elfutils/elfutils_0.189.bb b/poky/meta/recipes-devtools/elfutils/elfutils_0.189.bb index d8bf82b022..67494cd35a 100644 --- a/poky/meta/recipes-devtools/elfutils/elfutils_0.189.bb +++ b/poky/meta/recipes-devtools/elfutils/elfutils_0.189.bb @@ -2,7 +2,7 @@ SUMMARY = "Utilities and libraries for handling compiled object files" HOMEPAGE = "https://sourceware.org/elfutils" DESCRIPTION = "elfutils is a collection of utilities and libraries to read, create and modify ELF binary files, find and handle DWARF debug data, symbols, thread state and stacktraces for processes and core files on GNU/Linux." SECTION = "base" -LICENSE = "GPL-2.0-only & GPL-2.0-or-later & LGPL-3.0-or-later & GPL-3.0-or-later" +LICENSE = "( GPL-2.0-or-later | LGPL-3.0-or-later ) & GPL-3.0-or-later" LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \ file://debuginfod/debuginfod-client.c;endline=28;md5=f0a7c3170776866ee94e8f9225a6ad79 \ " @@ -106,19 +106,18 @@ EXTRA_OEMAKE:class-nativesdk = "" BBCLASSEXTEND = "native nativesdk" -# Package utilities separately +# Package utilities and libraries are listed separately PACKAGES =+ "${PN}-binutils libelf libasm libdw libdebuginfod" -# Shared libraries are licensed GPL-2.0-only or GPL-3.0-or-later, binaries -# GPL-3.0-or-later. According to NEWS file: -# "The license is now GPLv2/LGPLv3+ for the libraries and GPLv3+ for stand-alone -# programs. There is now also a formal CONTRIBUTING document describing how to -# submit patches." +# According to the upstream website https://sourceware.org/elfutils, the latest +# license policy is as follows: +# "License. The libraries and backends are dual GPLv2+/LGPLv3+. The utilities +# are GPLv3+." LICENSE:${PN}-binutils = "GPL-3.0-or-later" LICENSE:${PN} = "GPL-3.0-or-later" -LICENSE:libelf = "GPL-2.0-only | LGPL-3.0-or-later" -LICENSE:libasm = "GPL-2.0-only | LGPL-3.0-or-later" -LICENSE:libdw = "GPL-2.0-only | LGPL-3.0-or-later" +LICENSE:libelf = "GPL-2.0-or-later | LGPL-3.0-or-later" +LICENSE:libasm = "GPL-2.0-or-later | LGPL-3.0-or-later" +LICENSE:libdw = "GPL-2.0-or-later | LGPL-3.0-or-later" LICENSE:libdebuginfod = "GPL-2.0-or-later | LGPL-3.0-or-later" FILES:${PN}-binutils = "\ diff --git a/poky/meta/recipes-devtools/gcc/gcc-13.2.inc b/poky/meta/recipes-devtools/gcc/gcc-13.2.inc index 359db1e278..32fddd11c2 100644 --- a/poky/meta/recipes-devtools/gcc/gcc-13.2.inc +++ b/poky/meta/recipes-devtools/gcc/gcc-13.2.inc @@ -115,3 +115,4 @@ EXTRA_OECONF_PATHS = "\ " CVE_STATUS[CVE-2021-37322] = "cpe-incorrect: Is a binutils 2.26 issue, not gcc" +CVE_STATUS[CVE-2023-4039] = "fixed-version: Fixed via CVE-2023-4039.patch included here. Set the status explictly to deal with all recipes that share the gcc-source" diff --git a/poky/meta/recipes-devtools/go/go-1.20.10.inc b/poky/meta/recipes-devtools/go/go-1.20.12.inc index 39509ed986..9be56c6707 100644 --- a/poky/meta/recipes-devtools/go/go-1.20.10.inc +++ b/poky/meta/recipes-devtools/go/go-1.20.12.inc @@ -15,4 +15,4 @@ SRC_URI += "\ file://0008-src-cmd-dist-buildgo.go-do-not-hardcode-host-compile.patch \ file://0009-go-Filter-build-paths-on-staticly-linked-arches.patch \ " -SRC_URI[main.sha256sum] = "72d2f51805c47150066c103754c75fddb2c19d48c9219fa33d1e46696c841dbb" +SRC_URI[main.sha256sum] = "c5bf934751d31c315c1d0bb5fb02296545fa6d08923566f7a5afec81f2ed27d6" diff --git a/poky/meta/recipes-devtools/go/go-binary-native_1.20.10.bb b/poky/meta/recipes-devtools/go/go-binary-native_1.20.12.bb index 691670c31e..e555412a19 100644 --- a/poky/meta/recipes-devtools/go/go-binary-native_1.20.10.bb +++ b/poky/meta/recipes-devtools/go/go-binary-native_1.20.12.bb @@ -9,9 +9,9 @@ PROVIDES = "go-native" # Checksums available at https://go.dev/dl/ SRC_URI = "https://dl.google.com/go/go${PV}.${BUILD_GOOS}-${BUILD_GOARCH}.tar.gz;name=go_${BUILD_GOTUPLE}" -SRC_URI[go_linux_amd64.sha256sum] = "80d34f1fd74e382d86c2d6102e0e60d4318461a7c2f457ec1efc4042752d4248" -SRC_URI[go_linux_arm64.sha256sum] = "fb3c7e15fc4413c5b81eb9f26dbd7cd4faedd5c720b30fa8e2ff77457f74cab6" -SRC_URI[go_linux_ppc64le.sha256sum] = "ebac6e713810174f9ffd7f48c17c373fbf359d50d8e6233b1dfbbdebd524fd1c" +SRC_URI[go_linux_amd64.sha256sum] = "9c5d48c54dd8b0a3b2ef91b0f92a1190aa01f11d26e98033efa64c46a30bba7b" +SRC_URI[go_linux_arm64.sha256sum] = "8afe8e3fb6972eaa2179ef0a71678c67f26509fab4f0f67c4b00f4cdfa92dc87" +SRC_URI[go_linux_ppc64le.sha256sum] = "2ae0ec3736216dfbd7b01ff679842dc1bed365e53a024d522645bcffd01c7328" UPSTREAM_CHECK_URI = "https://golang.org/dl/" UPSTREAM_CHECK_REGEX = "go(?P<pver>\d+(\.\d+)+)\.linux" diff --git a/poky/meta/recipes-devtools/go/go-cross-canadian_1.20.10.bb b/poky/meta/recipes-devtools/go/go-cross-canadian_1.20.12.bb index 7ac9449e47..7ac9449e47 100644 --- a/poky/meta/recipes-devtools/go/go-cross-canadian_1.20.10.bb +++ b/poky/meta/recipes-devtools/go/go-cross-canadian_1.20.12.bb diff --git a/poky/meta/recipes-devtools/go/go-cross_1.20.10.bb b/poky/meta/recipes-devtools/go/go-cross_1.20.12.bb index 80b5a03f6c..80b5a03f6c 100644 --- a/poky/meta/recipes-devtools/go/go-cross_1.20.10.bb +++ b/poky/meta/recipes-devtools/go/go-cross_1.20.12.bb diff --git a/poky/meta/recipes-devtools/go/go-crosssdk_1.20.10.bb b/poky/meta/recipes-devtools/go/go-crosssdk_1.20.12.bb index 1857c8a577..1857c8a577 100644 --- a/poky/meta/recipes-devtools/go/go-crosssdk_1.20.10.bb +++ b/poky/meta/recipes-devtools/go/go-crosssdk_1.20.12.bb diff --git a/poky/meta/recipes-devtools/go/go-native_1.20.10.bb b/poky/meta/recipes-devtools/go/go-native_1.20.12.bb index ddf25b2c9b..ddf25b2c9b 100644 --- a/poky/meta/recipes-devtools/go/go-native_1.20.10.bb +++ b/poky/meta/recipes-devtools/go/go-native_1.20.12.bb diff --git a/poky/meta/recipes-devtools/go/go-runtime_1.20.10.bb b/poky/meta/recipes-devtools/go/go-runtime_1.20.12.bb index 63464a1501..63464a1501 100644 --- a/poky/meta/recipes-devtools/go/go-runtime_1.20.10.bb +++ b/poky/meta/recipes-devtools/go/go-runtime_1.20.12.bb diff --git a/poky/meta/recipes-devtools/go/go_1.20.10.bb b/poky/meta/recipes-devtools/go/go_1.20.12.bb index 46f5fbc6be..46f5fbc6be 100644 --- a/poky/meta/recipes-devtools/go/go_1.20.10.bb +++ b/poky/meta/recipes-devtools/go/go_1.20.12.bb diff --git a/poky/meta/recipes-devtools/pseudo/files/glibc238.patch b/poky/meta/recipes-devtools/pseudo/files/glibc238.patch index 76ca8c11eb..da4b8caee3 100644 --- a/poky/meta/recipes-devtools/pseudo/files/glibc238.patch +++ b/poky/meta/recipes-devtools/pseudo/files/glibc238.patch @@ -44,19 +44,6 @@ Index: git/pseudo_util.c #include <ctype.h> #include <errno.h> -Index: git/pseudolog.c -=================================================================== ---- git.orig/pseudolog.c -+++ git/pseudolog.c -@@ -8,7 +8,7 @@ - */ - /* We need _XOPEN_SOURCE for strptime(), but if we define that, - * we then don't get S_IFSOCK... _GNU_SOURCE turns on everything. */ --#define _GNU_SOURCE -+#define _DEFAULT_SOURCE - - #include <ctype.h> - #include <limits.h> Index: git/pseudo_client.c =================================================================== --- git.orig/pseudo_client.c diff --git a/poky/meta/recipes-devtools/pseudo/pseudo_git.bb b/poky/meta/recipes-devtools/pseudo/pseudo_git.bb index 4a894ebdd0..025cf0fc9c 100644 --- a/poky/meta/recipes-devtools/pseudo/pseudo_git.bb +++ b/poky/meta/recipes-devtools/pseudo/pseudo_git.bb @@ -14,7 +14,7 @@ SRC_URI:append:class-nativesdk = " \ file://older-glibc-symbols.patch" SRC_URI[prebuilt.sha256sum] = "ed9f456856e9d86359f169f46a70ad7be4190d6040282b84c8d97b99072485aa" -SRCREV = "ec6151a2b057109b3f798f151a36690af582e166" +SRCREV = "516a0a3c4b46f046895d27bfa019d685fe462dfa" S = "${WORKDIR}/git" PV = "1.9.0+git" diff --git a/poky/meta/recipes-devtools/python/python3-jinja2_3.1.2.bb b/poky/meta/recipes-devtools/python/python3-jinja2_3.1.3.bb index fa6d930a9c..18057809c8 100644 --- a/poky/meta/recipes-devtools/python/python3-jinja2_3.1.2.bb +++ b/poky/meta/recipes-devtools/python/python3-jinja2_3.1.3.bb @@ -4,7 +4,7 @@ HOMEPAGE = "https://pypi.org/project/Jinja2/" LICENSE = "BSD-3-Clause" LIC_FILES_CHKSUM = "file://LICENSE.rst;md5=5dc88300786f1c214c1e9827a5229462" -SRC_URI[sha256sum] = "31351a702a408a9e7595a8fc6150fc3f43bb6bf7e319770cbc0db9df9437e852" +SRC_URI[sha256sum] = "ac8bd6544d4bb2c9792bf3a159e80bba8fda7f07e81bc3aed565432d5925ba90" PYPI_PACKAGE = "Jinja2" diff --git a/poky/meta/recipes-devtools/python/python3-license-expression/run-ptest b/poky/meta/recipes-devtools/python/python3-license-expression/run-ptest index 5cec711696..8d2017d39c 100644 --- a/poky/meta/recipes-devtools/python/python3-license-expression/run-ptest +++ b/poky/meta/recipes-devtools/python/python3-license-expression/run-ptest @@ -1,3 +1,3 @@ #!/bin/sh -pytest +pytest --automake diff --git a/poky/meta/recipes-devtools/python/python3-license-expression_30.1.1.bb b/poky/meta/recipes-devtools/python/python3-license-expression_30.1.1.bb index 31fb88d6e5..92ca419e4a 100644 --- a/poky/meta/recipes-devtools/python/python3-license-expression_30.1.1.bb +++ b/poky/meta/recipes-devtools/python/python3-license-expression_30.1.1.bb @@ -26,6 +26,7 @@ SRC_URI += " \ RDEPENDS:${PN}-ptest += " \ ${PYTHON_PN}-pytest \ + ${PYTHON_PN}-unittest-automake-output \ " do_install_ptest() { @@ -33,4 +34,5 @@ do_install_ptest() { install -d ${D}${PTEST_PATH}/src cp -rf ${S}/tests/* ${D}${PTEST_PATH}/tests/ cp -rf ${S}/src/* ${D}${PTEST_PATH}/src/ + cp -rf ${S}/setup.cfg ${D}${PTEST_PATH}/ } diff --git a/poky/meta/recipes-devtools/qemu/qemu-native_8.1.2.bb b/poky/meta/recipes-devtools/qemu/qemu-native_8.1.4.bb index 73a0f63f2b..73a0f63f2b 100644 --- a/poky/meta/recipes-devtools/qemu/qemu-native_8.1.2.bb +++ b/poky/meta/recipes-devtools/qemu/qemu-native_8.1.4.bb diff --git a/poky/meta/recipes-devtools/qemu/qemu-system-native_8.1.2.bb b/poky/meta/recipes-devtools/qemu/qemu-system-native_8.1.4.bb index 558a416f7b..558a416f7b 100644 --- a/poky/meta/recipes-devtools/qemu/qemu-system-native_8.1.2.bb +++ b/poky/meta/recipes-devtools/qemu/qemu-system-native_8.1.4.bb diff --git a/poky/meta/recipes-devtools/qemu/qemu.inc b/poky/meta/recipes-devtools/qemu/qemu.inc index 5ab2cb83b4..0ea23ecdc3 100644 --- a/poky/meta/recipes-devtools/qemu/qemu.inc +++ b/poky/meta/recipes-devtools/qemu/qemu.inc @@ -37,7 +37,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \ UPSTREAM_CHECK_REGEX = "qemu-(?P<pver>\d+(\.\d+)+)\.tar" -SRC_URI[sha256sum] = "541526a764576eb494d2ff5ec46aeb253e62ea29035d1c23c0a8af4e6cd4f087" +SRC_URI[sha256sum] = "176dd6d0bdcc4c71a94172d12ddb7a3b2e8e20d638e5db26138165a382be2dbd" SRC_URI:append:class-target = " file://cross.patch" SRC_URI:append:class-nativesdk = " file://cross.patch" diff --git a/poky/meta/recipes-devtools/qemu/qemu_8.1.2.bb b/poky/meta/recipes-devtools/qemu/qemu_8.1.4.bb index 84ee0bcc49..84ee0bcc49 100644 --- a/poky/meta/recipes-devtools/qemu/qemu_8.1.2.bb +++ b/poky/meta/recipes-devtools/qemu/qemu_8.1.4.bb diff --git a/poky/meta/recipes-devtools/tcltk/tcl_8.6.13.bb b/poky/meta/recipes-devtools/tcltk/tcl_8.6.13.bb index b33a78e147..bb75353a5a 100644 --- a/poky/meta/recipes-devtools/tcltk/tcl_8.6.13.bb +++ b/poky/meta/recipes-devtools/tcltk/tcl_8.6.13.bb @@ -88,7 +88,7 @@ do_install_ptest() { do_install_ptest:append:libc-musl () { # Assumes locales other than provided by musl-locales - sed -i -e 's|SKIPPED_TESTS=|SKIPPED_TESTS="unixInit-3*"|' ${D}${PTEST_PATH}/run-ptest + sed -i -e "s|SKIPPED_TESTS='|SKIPPED_TESTS='unixInit-3* |" ${D}${PTEST_PATH}/run-ptest } # Fix some paths that might be used by Tcl extensions diff --git a/poky/meta/recipes-extended/cpio/cpio_2.14.bb b/poky/meta/recipes-extended/cpio/cpio_2.15.bb index 560038d2a6..55e9add5cd 100644 --- a/poky/meta/recipes-extended/cpio/cpio_2.14.bb +++ b/poky/meta/recipes-extended/cpio/cpio_2.15.bb @@ -7,12 +7,11 @@ LICENSE = "GPL-3.0-only" LIC_FILES_CHKSUM = "file://COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949" SRC_URI = "${GNU_MIRROR}/cpio/cpio-${PV}.tar.gz \ - file://0001-configure-Include-needed-header-for-major-minor-macr.patch \ file://run-ptest \ file://test.sh \ " -SRC_URI[sha256sum] = "145a340fd9d55f0b84779a44a12d5f79d77c99663967f8cfa168d7905ca52454" +SRC_URI[sha256sum] = "efa50ef983137eefc0a02fdb51509d624b5e3295c980aa127ceee4183455499e" inherit autotools gettext texinfo ptest diff --git a/poky/meta/recipes-extended/cpio/files/0001-configure-Include-needed-header-for-major-minor-macr.patch b/poky/meta/recipes-extended/cpio/files/0001-configure-Include-needed-header-for-major-minor-macr.patch deleted file mode 100644 index 95ece0bbf3..0000000000 --- a/poky/meta/recipes-extended/cpio/files/0001-configure-Include-needed-header-for-major-minor-macr.patch +++ /dev/null @@ -1,48 +0,0 @@ -From 8179be21e664cedb2e9d238cc2f6d04965e97275 Mon Sep 17 00:00:00 2001 -From: Sergey Poznyakoff <gray@gnu.org> -Date: Thu, 11 May 2023 10:18:44 +0300 -Subject: [PATCH] configure: Include needed header for major/minor macros - -This helps in avoiding the warning about implicit function declaration -which is elevated as error with newer compilers e.g. clang 16 - -Signed-off-by: Khem Raj <raj.khem@gmail.com> - -Upstream-Status: Backport -Signed-off-by: Ross Burton <ross.burton@arm.com> ---- - configure.ac | 18 ++++++++++++++++-- - 1 file changed, 16 insertions(+), 2 deletions(-) - -diff --git a/configure.ac b/configure.ac -index de479e7..c601029 100644 ---- a/configure.ac -+++ b/configure.ac -@@ -43,8 +43,22 @@ AC_TYPE_UID_T - AC_CHECK_TYPE(gid_t, int) - - AC_HEADER_DIRENT --AX_COMPILE_CHECK_RETTYPE([major], [0]) --AX_COMPILE_CHECK_RETTYPE([minor], [0]) -+AX_COMPILE_CHECK_RETTYPE([major], [0], [ -+#include <sys/types.h> -+#ifdef MAJOR_IN_MKDEV -+# include <sys/mkdev.h> -+#endif -+#ifdef MAJOR_IN_SYSMACROS -+# include <sys/sysmacros.h> -+#endif]) -+AX_COMPILE_CHECK_RETTYPE([minor], [0], [ -+#include <sys/types.h> -+#ifdef MAJOR_IN_MKDEV -+# include <sys/mkdev.h> -+#endif -+#ifdef MAJOR_IN_SYSMACROS -+# include <sys/sysmacros.h> -+#endif]) - - AC_CHECK_FUNCS([fchmod fchown]) - # This is needed for mingw build --- -2.34.1 - diff --git a/poky/meta/recipes-extended/rpcbind/rpcbind_1.2.6.bb b/poky/meta/recipes-extended/rpcbind/rpcbind_1.2.6.bb index dd89726afc..dbd4d32e0a 100644 --- a/poky/meta/recipes-extended/rpcbind/rpcbind_1.2.6.bb +++ b/poky/meta/recipes-extended/rpcbind/rpcbind_1.2.6.bb @@ -40,7 +40,7 @@ PACKAGECONFIG[systemd] = "--with-systemdsystemunitdir=${systemd_system_unitdir}/ systemd \ " -EXTRA_OECONF += " --enable-warmstarts --with-rpcuser=rpc" +EXTRA_OECONF += " --enable-warmstarts --with-rpcuser=rpc --with-statedir=${runtimedir}/rpcbind" do_install:append () { install -d ${D}${sysconfdir}/init.d diff --git a/poky/meta/recipes-extended/shadow/files/CVE-2023-4641.patch b/poky/meta/recipes-extended/shadow/files/CVE-2023-4641.patch new file mode 100644 index 0000000000..1fabfe928e --- /dev/null +++ b/poky/meta/recipes-extended/shadow/files/CVE-2023-4641.patch @@ -0,0 +1,147 @@ +From 25dbe2ce166a13322b7536ff2f738786ea2e61e7 Mon Sep 17 00:00:00 2001 +From: Alejandro Colomar <alx@kernel.org> +Date: Sat, 10 Jun 2023 16:20:05 +0200 +Subject: [PATCH] gpasswd(1): Fix password leak + +How to trigger this password leak? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When gpasswd(1) asks for the new password, it asks twice (as is usual +for confirming the new password). Each of those 2 password prompts +uses agetpass() to get the password. If the second agetpass() fails, +the first password, which has been copied into the 'static' buffer +'pass' via STRFCPY(), wasn't being zeroed. + +agetpass() is defined in <./libmisc/agetpass.c> (around line 91), and +can fail for any of the following reasons: + +- malloc(3) or readpassphrase(3) failure. + + These are going to be difficult to trigger. Maybe getting the system + to the limits of memory utilization at that exact point, so that the + next malloc(3) gets ENOMEM, and possibly even the OOM is triggered. + About readpassphrase(3), ENFILE and EINTR seem the only plausible + ones, and EINTR probably requires privilege or being the same user; + but I wouldn't discard ENFILE so easily, if a process starts opening + files. + +- The password is longer than PASS_MAX. + + The is plausible with physical access. However, at that point, a + keylogger will be a much simpler attack. + +And, the attacker must be able to know when the second password is being +introduced, which is not going to be easy. + +How to read the password after the leak? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Provoking the leak yourself at the right point by entering a very long +password is easy, and inspecting the process stack at that point should +be doable. Try to find some consistent patterns. + +Then, search for those patterns in free memory, right after the victim +leaks their password. + +Once you get the leak, a program should read all the free memory +searching for patterns that gpasswd(1) leaves nearby the leaked +password. + +On 6/10/23 03:14, Seth Arnold wrote: +> An attacker process wouldn't be able to use malloc(3) for this task. +> There's a handful of tools available for userspace to allocate memory: +> +> - brk / sbrk +> - mmap MAP_ANONYMOUS +> - mmap /dev/zero +> - mmap some other file +> - shm_open +> - shmget +> +> Most of these return only pages of zeros to a process. Using mmap of an +> existing file, you can get some of the contents of the file demand-loaded +> into the memory space on the first use. +> +> The MAP_UNINITIALIZED flag only works if the kernel was compiled with +> CONFIG_MMAP_ALLOW_UNINITIALIZED. This is rare. +> +> malloc(3) doesn't zero memory, to our collective frustration, but all the +> garbage in the allocations is from previous allocations in the current +> process. It isn't leftover from other processes. +> +> The avenues available for reading the memory: +> - /dev/mem and /dev/kmem (requires root, not available with Secure Boot) +> - /proc/pid/mem (requires ptrace privileges, mediated by YAMA) +> - ptrace (requires ptrace privileges, mediated by YAMA) +> - causing memory to be swapped to disk, and then inspecting the swap +> +> These all require a certain amount of privileges. + +How to fix it? +~~~~~~~~~~~~~~ + +memzero(), which internally calls explicit_bzero(3), or whatever +alternative the system provides with a slightly different name, will +make sure that the buffer is zeroed in memory, and optimizations are not +allowed to impede this zeroing. + +This is not really 100% effective, since compilers may place copies of +the string somewhere hidden in the stack. Those copies won't get zeroed +by explicit_bzero(3). However, that's arguably a compiler bug, since +compilers should make everything possible to avoid optimizing strings +that are later passed to explicit_bzero(3). But we all know that +sometimes it's impossible to have perfect knowledge in the compiler, so +this is plausible. Nevertheless, there's nothing we can do against such +issues, except minimizing the time such passwords are stored in plain +text. + +Security concerns +~~~~~~~~~~~~~~~~~ + +We believe this isn't easy to exploit. Nevertheless, and since the fix +is trivial, this fix should probably be applied soon, and backported to +all supported distributions, to prevent someone else having more +imagination than us to find a way. + +Affected versions +~~~~~~~~~~~~~~~~~ + +All. Bug introduced in shadow 19990709. That's the second commit in +the git history. + +Fixes: 45c6603cc86c ("[svn-upgrade] Integrating new upstream version, shadow (19990709)") + +CVE: CVE-2023-4641 +Upstream-Status: Backport [https://github.com/shadow-maint/shadow/commit/65c88a43a23c2391dcc90c0abda3e839e9c57904] + +Reported-by: Alejandro Colomar <alx@kernel.org> +Cc: Serge Hallyn <serge@hallyn.com> +Cc: Iker Pedrosa <ipedrosa@redhat.com> +Cc: Seth Arnold <seth.arnold@canonical.com> +Cc: Christian Brauner <christian@brauner.io> +Cc: Balint Reczey <rbalint@debian.org> +Cc: Sam James <sam@gentoo.org> +Cc: David Runge <dvzrv@archlinux.org> +Cc: Andreas Jaeger <aj@suse.de> +Cc: <~hallyn/shadow@lists.sr.ht> +Signed-off-by: Alejandro Colomar <alx@kernel.org> +Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com> +--- + src/gpasswd.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/src/gpasswd.c b/src/gpasswd.c +index 5983f787..2d8869ef 100644 +--- a/src/gpasswd.c ++++ b/src/gpasswd.c +@@ -896,6 +896,7 @@ static void change_passwd (struct group *gr) + strzero (cp); + cp = getpass (_("Re-enter new password: ")); + if (NULL == cp) { ++ memzero (pass, sizeof pass); + exit (1); + } + +-- +2.34.1 + diff --git a/poky/meta/recipes-extended/shadow/shadow.inc b/poky/meta/recipes-extended/shadow/shadow.inc index 83e1a84769..ce3ce62715 100644 --- a/poky/meta/recipes-extended/shadow/shadow.inc +++ b/poky/meta/recipes-extended/shadow/shadow.inc @@ -17,6 +17,7 @@ SRC_URI = "${GITHUB_BASE_URI}/download/${PV}/${BP}.tar.gz \ file://0001-Fix-can-not-print-full-login.patch \ file://CVE-2023-29383.patch \ file://0001-Overhaul-valid_field.patch \ + file://CVE-2023-4641.patch \ " SRC_URI:append:class-target = " \ diff --git a/poky/meta/recipes-extended/sudo/sudo_1.9.14p3.bb b/poky/meta/recipes-extended/sudo/sudo_1.9.15p5.bb index d5c5718ea5..8e542015ad 100644 --- a/poky/meta/recipes-extended/sudo/sudo_1.9.14p3.bb +++ b/poky/meta/recipes-extended/sudo/sudo_1.9.15p5.bb @@ -7,7 +7,7 @@ SRC_URI = "https://www.sudo.ws/dist/sudo-${PV}.tar.gz \ PAM_SRC_URI = "file://sudo.pam" -SRC_URI[sha256sum] = "a08318b1c4bc8582c004d4cd9ae2903abc549e7e46ba815e41fe81d1c0782b62" +SRC_URI[sha256sum] = "558d10b9a1991fb3b9fa7fa7b07ec4405b7aefb5b3cb0b0871dbc81e3a88e558" DEPENDS += " virtual/crypt ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}" RDEPENDS:${PN} += " ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam-plugin-limits pam-plugin-keyinit', '', d)}" diff --git a/poky/meta/recipes-extended/timezone/timezone.inc b/poky/meta/recipes-extended/timezone/timezone.inc index 2774e5e730..4734adcc08 100644 --- a/poky/meta/recipes-extended/timezone/timezone.inc +++ b/poky/meta/recipes-extended/timezone/timezone.inc @@ -6,7 +6,7 @@ SECTION = "base" LICENSE = "PD & BSD-3-Clause" LIC_FILES_CHKSUM = "file://LICENSE;md5=c679c9d6b02bc2757b3eaf8f53c43fba" -PV = "2023d" +PV = "2024a" SRC_URI =" http://www.iana.org/time-zones/repository/releases/tzcode${PV}.tar.gz;name=tzcode;subdir=tz \ http://www.iana.org/time-zones/repository/releases/tzdata${PV}.tar.gz;name=tzdata;subdir=tz \ @@ -16,5 +16,5 @@ S = "${WORKDIR}/tz" UPSTREAM_CHECK_URI = "http://www.iana.org/time-zones" -SRC_URI[tzcode.sha256sum] = "e9a5f9e118886d2de92b62bb05510a28cc6c058d791c93bd6b84d3292c3c161e" -SRC_URI[tzdata.sha256sum] = "dbca21970b0a8b8c0ceceec1d7b91fa903be0f6eca5ae732b5329672232a08f3" +SRC_URI[tzcode.sha256sum] = "80072894adff5a458f1d143e16e4ca1d8b2a122c9c5399da482cb68cba6a1ff8" +SRC_URI[tzdata.sha256sum] = "0d0434459acbd2059a7a8da1f3304a84a86591f6ed69c6248fffa502b6edffe3" diff --git a/poky/meta/recipes-extended/zstd/zstd_1.5.5.bb b/poky/meta/recipes-extended/zstd/zstd_1.5.5.bb index 5c5fb5e734..2d72af50a4 100644 --- a/poky/meta/recipes-extended/zstd/zstd_1.5.5.bb +++ b/poky/meta/recipes-extended/zstd/zstd_1.5.5.bb @@ -5,7 +5,7 @@ It's backed by a very fast entropy stage, provided by Huff0 and FSE library." HOMEPAGE = "http://www.zstd.net/" SECTION = "console/utils" -LICENSE = "BSD-3-Clause & GPL-2.0-only" +LICENSE = "BSD-3-Clause | GPL-2.0-only" LIC_FILES_CHKSUM = "file://LICENSE;md5=0822a32f7acdbe013606746641746ee8 \ file://COPYING;md5=39bba7d2cf0ba1036f2a6e2be52fe3f0 \ " diff --git a/poky/meta/recipes-gnome/gtk+/gtk+3_3.24.38.bb b/poky/meta/recipes-gnome/gtk+/gtk+3_3.24.38.bb index 37fa0a7290..c23c46a689 100644 --- a/poky/meta/recipes-gnome/gtk+/gtk+3_3.24.38.bb +++ b/poky/meta/recipes-gnome/gtk+/gtk+3_3.24.38.bb @@ -13,3 +13,5 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2 \ file://gtk/gtk.h;endline=25;md5=1d8dc0fccdbfa26287a271dce88af737 \ file://gdk/gdk.h;endline=25;md5=c920ce39dc88c6f06d3e7c50e08086f2 \ file://tests/testgtk.c;endline=25;md5=cb732daee1d82af7a2bf953cf3cf26f1" + +CVE_PRODUCT = "gnome:gtk" diff --git a/poky/meta/recipes-gnome/gtk+/gtk4_4.12.3.bb b/poky/meta/recipes-gnome/gtk+/gtk4_4.12.3.bb index 001b06934e..2c85e7e75f 100644 --- a/poky/meta/recipes-gnome/gtk+/gtk4_4.12.3.bb +++ b/poky/meta/recipes-gnome/gtk+/gtk4_4.12.3.bb @@ -41,6 +41,8 @@ SRC_URI[sha256sum] = "148ce262f6c86487455fb1d9793c3f58bc3e1da477a29617fadb0420f5 S = "${WORKDIR}/gtk-${PV}" +CVE_PRODUCT = "gnome:gtk" + inherit meson gettext pkgconfig gi-docgen update-alternatives gsettings features_check gobject-introspection # TBD: nativesdk diff --git a/poky/meta/recipes-gnome/libadwaita/libadwaita_1.4.0.bb b/poky/meta/recipes-gnome/libadwaita/libadwaita_1.4.2.bb index d8aa2cd697..64b7473b0a 100644 --- a/poky/meta/recipes-gnome/libadwaita/libadwaita_1.4.0.bb +++ b/poky/meta/recipes-gnome/libadwaita/libadwaita_1.4.2.bb @@ -12,7 +12,7 @@ DEPENDS = " \ inherit gnomebase gobject-introspection gi-docgen vala features_check -SRC_URI[archive.sha256sum] = "e51a098a54d43568218fc48fcf52e80e36f469b3ce912d8ce9c308a37e9f47c2" +SRC_URI[archive.sha256sum] = "33fa16754e7370c841767298b3ff5f23003ee1d2515cc2ff255e65ef3d4e8713" ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}" REQUIRED_DISTRO_FEATURES = "opengl" diff --git a/poky/meta/recipes-graphics/libva/libva-utils_2.20.0.bb b/poky/meta/recipes-graphics/libva/libva-utils_2.20.1.bb index 2e1fd09406..3bce9a1e32 100644 --- a/poky/meta/recipes-graphics/libva/libva-utils_2.20.0.bb +++ b/poky/meta/recipes-graphics/libva/libva-utils_2.20.1.bb @@ -15,7 +15,7 @@ LICENSE = "MIT" LIC_FILES_CHKSUM = "file://COPYING;md5=b148fc8adf19dc9aec17cf9cd29a9a5e" SRC_URI = "git://github.com/intel/libva-utils.git;branch=v2.20-branch;protocol=https" -SRCREV = "0c8373e62af3e4d9a3831334c5402ad255797e67" +SRCREV = "2ad888bb463dc9bfb3deb512ec9faf78f1d3bfa8" S = "${WORKDIR}/git" UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>(\d+(\.\d+)+))$" diff --git a/poky/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.9.bb b/poky/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.11.bb index 43c06181e3..6506d775ca 100644 --- a/poky/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.9.bb +++ b/poky/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.11.bb @@ -3,7 +3,7 @@ require xserver-xorg.inc SRC_URI += "file://0001-xf86pciBus.c-use-Intel-ddx-only-for-pre-gen4-hardwar.patch \ file://0001-Avoid-duplicate-definitions-of-IOPortBase.patch \ " -SRC_URI[sha256sum] = "ff697be2011b4c4966b7806929e51b7a08e9d33800d505305d26d9ccde4b533a" +SRC_URI[sha256sum] = "1d3dadbd57fb86b16a018e9f5f957aeeadf744f56c0553f55737628d06d326ef" # These extensions are now integrated into the server, so declare the migration # path for in-place upgrades. diff --git a/poky/meta/recipes-graphics/xwayland/xwayland_23.2.2.bb b/poky/meta/recipes-graphics/xwayland/xwayland_23.2.4.bb index 9feac147db..092359172a 100644 --- a/poky/meta/recipes-graphics/xwayland/xwayland_23.2.2.bb +++ b/poky/meta/recipes-graphics/xwayland/xwayland_23.2.4.bb @@ -10,7 +10,7 @@ LICENSE = "MIT" LIC_FILES_CHKSUM = "file://COPYING;md5=5df87950af51ac2c5822094553ea1880" SRC_URI = "https://www.x.org/archive/individual/xserver/xwayland-${PV}.tar.xz" -SRC_URI[sha256sum] = "9f7c0938d2a41e941ffa04f99c35e5db2bcd3eec034afe8d35d5c810a22eb0a8" +SRC_URI[sha256sum] = "a99e159b6d0d33098b3b6ab22a88bfcece23c8b9d0ca72c535c55dcb0681b46b" UPSTREAM_CHECK_REGEX = "xwayland-(?P<pver>\d+(\.(?!90\d)\d+)+)\.tar" diff --git a/poky/meta/recipes-kernel/dtc/dtc/0001-meson.build-bump-version-to-1.7.0.patch b/poky/meta/recipes-kernel/dtc/dtc/0001-meson.build-bump-version-to-1.7.0.patch new file mode 100644 index 0000000000..79a3b92b44 --- /dev/null +++ b/poky/meta/recipes-kernel/dtc/dtc/0001-meson.build-bump-version-to-1.7.0.patch @@ -0,0 +1,29 @@ +From 9153522103bd4ed7e3299c4d073f66bb37cb2d42 Mon Sep 17 00:00:00 2001 +From: Nikolay Letov <letov.nikolay@gmail.com> +Date: Wed, 22 Feb 2023 13:36:07 +0300 +Subject: [PATCH 1/2] meson.build: bump version to 1.7.0 + +[This was botched in the actual 1.7.0 release :( - David Gibson] + +Upstream-Status: Backport [https://git.kernel.org/pub/scm/utils/dtc/dtc.git/commit/?id=64a907f08b9bedd89833c1eee674148cff2343c6] + +Signed-off-by: Nikolay Letov <letov.nikolay@gmail.com> +Signed-off-by: Peter Marko <peter.marko@siemens.com> +--- + meson.build | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/meson.build b/meson.build +index 78251eb..d88cd9f 100644 +--- a/meson.build ++++ b/meson.build +@@ -1,5 +1,5 @@ + project('dtc', 'c', +- version: '1.6.0', ++ version: '1.7.0', + license: ['GPL2+', 'BSD-2'], + default_options: 'werror=true', + ) +-- +2.30.2 + diff --git a/poky/meta/recipes-kernel/dtc/dtc/0002-meson-allow-building-from-shallow-clones.patch b/poky/meta/recipes-kernel/dtc/dtc/0002-meson-allow-building-from-shallow-clones.patch new file mode 100644 index 0000000000..0284905913 --- /dev/null +++ b/poky/meta/recipes-kernel/dtc/dtc/0002-meson-allow-building-from-shallow-clones.patch @@ -0,0 +1,38 @@ +From 4415b0baece3c4351a6d3637c2754abbefd4795d Mon Sep 17 00:00:00 2001 +From: Peter Marko <peter.marko@siemens.com> +Date: Sat, 16 Dec 2023 18:58:31 +0100 +Subject: [PATCH 2/2] meson: allow building from shallow clones + +When building from shallow clone, tag is not available +and version defaults to git hash. +Problem is that some builds check DTC version and fail the comparison. +Example is https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git +Which fails to build with following error: +dtc version too old (039a994), you need at least version 1.4.4 + +Drop --always from git describe command, see +https://github.com/mesonbuild/meson/blob/1.3.0/mesonbuild/utils/universal.py#L773 +This will make it more closer to build via Makefile. + +Upstream-Status: Submitted [https://github.com/dgibson/dtc/pull/122] + +Signed-off-by: Peter Marko <peter.marko@siemens.com> +--- + meson.build | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/meson.build b/meson.build +index 78251eb..fc0c92a 100644 +--- a/meson.build ++++ b/meson.build +@@ -56,6 +56,7 @@ py = py.find_installation(required: get_option('python')) + swig = find_program('swig', required: get_option('python')) + + version_gen_h = vcs_tag( ++ command: ['git', 'describe', '--dirty=+'], + input: 'version_gen.h.in', + output: 'version_gen.h', + ) +-- +2.30.2 + diff --git a/poky/meta/recipes-kernel/dtc/dtc_1.7.0.bb b/poky/meta/recipes-kernel/dtc/dtc_1.7.0.bb index 1a78a0c079..0702fc16df 100644 --- a/poky/meta/recipes-kernel/dtc/dtc_1.7.0.bb +++ b/poky/meta/recipes-kernel/dtc/dtc_1.7.0.bb @@ -8,7 +8,11 @@ LIC_FILES_CHKSUM = "file://GPL;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ file://BSD-2-Clause;md5=5d6306d1b08f8df623178dfd81880927 \ file://README.license;md5=a1eb22e37f09df5b5511b8a278992d0e" -SRC_URI = "git://git.kernel.org/pub/scm/utils/dtc/dtc.git;branch=main;protocol=https" +SRC_URI = " \ + git://git.kernel.org/pub/scm/utils/dtc/dtc.git;branch=main;protocol=https \ + file://0001-meson.build-bump-version-to-1.7.0.patch \ + file://0002-meson-allow-building-from-shallow-clones.patch \ +" SRCREV = "039a99414e778332d8f9c04cbd3072e1dcc62798" UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>\d+(\.\d+)+)" diff --git a/poky/meta/recipes-kernel/linux-firmware/linux-firmware_20231030.bb b/poky/meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb index c0394b9b3b..490c0ab89f 100644 --- a/poky/meta/recipes-kernel/linux-firmware/linux-firmware_20231030.bb +++ b/poky/meta/recipes-kernel/linux-firmware/linux-firmware_20240220.bb @@ -91,7 +91,7 @@ LIC_FILES_CHKSUM = "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \ file://LICENCE.cadence;md5=009f46816f6956cfb75ede13d3e1cee0 \ file://LICENCE.cavium;md5=c37aaffb1ebe5939b2580d073a95daea \ file://LICENCE.chelsio_firmware;md5=819aa8c3fa453f1b258ed8d168a9d903 \ - file://LICENSE.cirrus;md5=bb18d943382abf8e8232a9407bfdafe0 \ + file://LICENSE.cirrus;md5=662ea2c1a8888f7d79ed7f27c27472e1 \ file://LICENCE.cnm;md5=93b67e6bac7f8fec22b96b8ad0a1a9d0 \ file://LICENCE.cw1200;md5=f0f770864e7a8444a5c5aa9d12a3a7ed \ file://LICENCE.cypress;md5=48cd9436c763bf873961f9ed7b5c147b \ @@ -151,7 +151,7 @@ LIC_FILES_CHKSUM = "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \ " # WHENCE checksum is defined separately to ease overriding it if # class-devupstream is selected. -WHENCE_CHKSUM = "ceb5248746d24d165b603e71b288cf75" +WHENCE_CHKSUM = "a344e6c28970fc7daafa81c10247aeb6" # These are not common licenses, set NO_GENERIC_LICENSE for them # so that the license files will be copied from fetched source @@ -237,7 +237,7 @@ SRC_URI:class-devupstream = "git://git.kernel.org/pub/scm/linux/kernel/git/firmw # Pin this to the 20220509 release, override this in local.conf SRCREV:class-devupstream ?= "b19cbdca78ab2adfd210c91be15a22568e8b8cae" -SRC_URI[sha256sum] = "c98d200fc4a3120de1a594713ce34e135819dff23e883a4ed387863ba25679c7" +SRC_URI[sha256sum] = "bf0f239dc0801e9d6bf5d5fb3e2f549575632cf4688f4348184199cb02c2bcd7" inherit allarch @@ -248,7 +248,8 @@ do_compile() { } do_install() { - oe_runmake 'DESTDIR=${D}' 'FIRMWAREDIR=${nonarch_base_libdir}/firmware' install + # install-nodedup avoids rdfind dependency + oe_runmake 'DESTDIR=${D}' 'FIRMWAREDIR=${nonarch_base_libdir}/firmware' install-nodedup cp GPL-2 LICEN[CS]E.* WHENCE ${D}${nonarch_base_libdir}/firmware/ } @@ -340,7 +341,8 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \ ${PN}-ice-license ${PN}-ice \ ${PN}-ice-enhanced-license ${PN}-ice-enhanced \ ${PN}-adsp-sst-license ${PN}-adsp-sst \ - ${PN}-bnx2-mips \ + ${PN}-bnx2 \ + ${PN}-bnx2x \ ${PN}-liquidio \ ${PN}-nvidia-license \ ${PN}-nvidia-tegra-k1 ${PN}-nvidia-tegra \ @@ -1070,6 +1072,7 @@ FILES:${PN}-bcm4373 = "${nonarch_base_libdir}/firmware/brcm/brcmfmac4373-sdio.bi ${nonarch_base_libdir}/firmware/brcm/brcmfmac4373.bin \ ${nonarch_base_libdir}/firmware/cypress/cyfmac4373-sdio.bin \ ${nonarch_base_libdir}/firmware/brcm/brcmfmac4373-sdio.clm_blob \ + ${nonarch_base_libdir}/firmware/cypress/cyfmac4373-sdio.clm_blob \ " LICENSE:${PN}-bcm-0bb4-0306 = "Firmware-cypress" @@ -1087,18 +1090,28 @@ RDEPENDS:${PN}-bcm4356-pcie += "${PN}-cypress-license" LICENSE:${PN}-bcm4373 = "Firmware-cypress" RDEPENDS:${PN}-bcm4373 += "${PN}-cypress-license" -# For Broadcom bnx2-mips +# For Broadcom bnx2 # # which is a separate case to the other Broadcom firmwares since its # license is contained in the shared WHENCE file. -LICENSE:${PN}-bnx2-mips = "WHENCE" +LICENSE:${PN}-bnx2 = "WHENCE" LICENSE:${PN}-whence-license = "WHENCE" -FILES:${PN}-bnx2-mips = "${nonarch_base_libdir}/firmware/bnx2/bnx2-mips-09-6.2.1b.fw" +FILES:${PN}-bnx2 = " \ + ${nonarch_base_libdir}/firmware/bnx2/bnx2-mips*.fw \ + ${nonarch_base_libdir}/firmware/bnx2/bnx2-rv2p*.fw \ +" FILES:${PN}-whence-license = "${nonarch_base_libdir}/firmware/WHENCE" -RDEPENDS:${PN}-bnx2-mips += "${PN}-whence-license" +RDEPENDS:${PN}-bnx2 += "${PN}-whence-license" +RPROVIDES:${PN}-bnx2 = "${PN}-bnx2-mips" + +LICENSE:${PN}-bnx2x = "WHENCE" + +FILES:${PN}-bnx2x = "${nonarch_base_libdir}/firmware/bnx2x/bnx2x*.fw" + +RDEPENDS:${PN}-bnx2x += "${PN}-whence-license" # For cirrus LICENSE:${PN}-cirrus = "Firmware-cirrus" @@ -1187,7 +1200,10 @@ FILES:${PN}-iwlwifi-7265d = "${nonarch_base_libdir}/firmware/iwlwifi-7265D-*.u FILES:${PN}-iwlwifi-8000c = "${nonarch_base_libdir}/firmware/iwlwifi-8000C-*.ucode" FILES:${PN}-iwlwifi-8265 = "${nonarch_base_libdir}/firmware/iwlwifi-8265-*.ucode" FILES:${PN}-iwlwifi-9000 = "${nonarch_base_libdir}/firmware/iwlwifi-9000-*.ucode" -FILES:${PN}-iwlwifi-misc = "${nonarch_base_libdir}/firmware/iwlwifi-*.ucode" +FILES:${PN}-iwlwifi-misc = " \ + ${nonarch_base_libdir}/firmware/iwlwifi-*.ucode \ + ${nonarch_base_libdir}/firmware/iwlwifi-*.pnvm \ +" RDEPENDS:${PN}-iwlwifi-135-6 = "${PN}-iwlwifi-license" RDEPENDS:${PN}-iwlwifi-3160-7 = "${PN}-iwlwifi-license" diff --git a/poky/meta/recipes-kernel/linux/cve-exclusion_6.1.inc b/poky/meta/recipes-kernel/linux/cve-exclusion_6.1.inc index 1b51737c7d..cb48e4d88d 100644 --- a/poky/meta/recipes-kernel/linux/cve-exclusion_6.1.inc +++ b/poky/meta/recipes-kernel/linux/cve-exclusion_6.1.inc @@ -1,9 +1,9 @@ # Auto-generated CVE metadata, DO NOT EDIT BY HAND. -# Generated at 2023-12-23 08:44:42.304531+00:00 for version 6.1.68 +# Generated at 2024-02-21 02:22:41.710563+00:00 for version 6.1.78 python check_kernel_cve_status_version() { - this_version = "6.1.68" + this_version = "6.1.78" kernel_version = d.getVar("LINUX_VERSION") if kernel_version != this_version: bb.warn("Kernel CVE status needs updating: generated for %s but kernel is %s" % (this_version, kernel_version)) @@ -3668,6 +3668,10 @@ CVE_STATUS[CVE-2021-3348] = "fixed-version: Fixed from version 5.11rc6" CVE_STATUS[CVE-2021-33624] = "fixed-version: Fixed from version 5.13rc7" +CVE_STATUS[CVE-2021-33630] = "fixed-version: Fixed from version 5.4rc1" + +CVE_STATUS[CVE-2021-33631] = "cpe-stable-backport: Backported in 6.1.4" + CVE_STATUS[CVE-2021-33655] = "fixed-version: Fixed from version 5.19rc6" CVE_STATUS[CVE-2021-33656] = "fixed-version: Fixed from version 5.12rc1" @@ -4420,7 +4424,7 @@ CVE_STATUS[CVE-2022-3636] = "fixed-version: Fixed from version 5.19rc1" CVE_STATUS[CVE-2022-3640] = "fixed-version: Fixed from version 6.1rc4" -# CVE-2022-36402 has no known resolution +CVE_STATUS[CVE-2022-36402] = "cpe-stable-backport: Backported in 6.1.50" # CVE-2022-3642 has no known resolution @@ -4584,6 +4588,8 @@ CVE_STATUS[CVE-2022-48425] = "cpe-stable-backport: Backported in 6.1.33" CVE_STATUS[CVE-2022-48502] = "cpe-stable-backport: Backported in 6.1.40" +CVE_STATUS[CVE-2022-48619] = "fixed-version: Fixed from version 5.18rc1" + CVE_STATUS[CVE-2023-0030] = "fixed-version: Fixed from version 5.0rc1" CVE_STATUS[CVE-2023-0045] = "cpe-stable-backport: Backported in 6.1.5" @@ -4644,7 +4650,7 @@ CVE_STATUS[CVE-2023-1118] = "cpe-stable-backport: Backported in 6.1.16" CVE_STATUS[CVE-2023-1192] = "cpe-stable-backport: Backported in 6.1.33" -# CVE-2023-1193 needs backporting (fixed from 6.3rc6) +CVE_STATUS[CVE-2023-1193] = "cpe-stable-backport: Backported in 6.1.71" CVE_STATUS[CVE-2023-1194] = "cpe-stable-backport: Backported in 6.1.34" @@ -4666,6 +4672,8 @@ CVE_STATUS[CVE-2023-1382] = "fixed-version: Fixed from version 6.1rc7" CVE_STATUS[CVE-2023-1390] = "fixed-version: Fixed from version 5.11rc4" +# CVE-2023-1476 has no known resolution + CVE_STATUS[CVE-2023-1513] = "cpe-stable-backport: Backported in 6.1.13" CVE_STATUS[CVE-2023-1582] = "fixed-version: Fixed from version 5.17rc4" @@ -4954,7 +4962,7 @@ CVE_STATUS[CVE-2023-35824] = "cpe-stable-backport: Backported in 6.1.28" CVE_STATUS[CVE-2023-35826] = "cpe-stable-backport: Backported in 6.1.28" -# CVE-2023-35827 needs backporting (fixed from 6.1.59) +CVE_STATUS[CVE-2023-35827] = "cpe-stable-backport: Backported in 6.1.59" CVE_STATUS[CVE-2023-35828] = "cpe-stable-backport: Backported in 6.1.28" @@ -5028,7 +5036,7 @@ CVE_STATUS[CVE-2023-4015] = "cpe-stable-backport: Backported in 6.1.43" CVE_STATUS[CVE-2023-40283] = "cpe-stable-backport: Backported in 6.1.45" -# CVE-2023-40791 needs backporting (fixed from 6.5rc6) +CVE_STATUS[CVE-2023-40791] = "fixed-version: only affects 6.3rc1 onwards" CVE_STATUS[CVE-2023-4128] = "cpe-stable-backport: Backported in 6.1.45" @@ -5088,7 +5096,7 @@ CVE_STATUS[CVE-2023-45871] = "cpe-stable-backport: Backported in 6.1.53" CVE_STATUS[CVE-2023-45898] = "fixed-version: only affects 6.5rc1 onwards" -# CVE-2023-4610 needs backporting (fixed from 6.4) +CVE_STATUS[CVE-2023-4610] = "fixed-version: only affects 6.4rc1 onwards" CVE_STATUS[CVE-2023-4611] = "fixed-version: only affects 6.4rc1 onwards" @@ -5096,9 +5104,15 @@ CVE_STATUS[CVE-2023-4611] = "fixed-version: only affects 6.4rc1 onwards" CVE_STATUS[CVE-2023-4623] = "cpe-stable-backport: Backported in 6.1.53" -# CVE-2023-46813 needs backporting (fixed from 6.1.60) +CVE_STATUS[CVE-2023-46343] = "cpe-stable-backport: Backported in 6.1.60" + +CVE_STATUS[CVE-2023-46813] = "cpe-stable-backport: Backported in 6.1.60" -# CVE-2023-46862 needs backporting (fixed from 6.6) +CVE_STATUS[CVE-2023-46838] = "cpe-stable-backport: Backported in 6.1.75" + +CVE_STATUS[CVE-2023-46862] = "cpe-stable-backport: Backported in 6.1.61" + +# CVE-2023-47233 has no known resolution CVE_STATUS[CVE-2023-4732] = "fixed-version: Fixed from version 5.14rc1" @@ -5106,29 +5120,153 @@ CVE_STATUS[CVE-2023-4881] = "cpe-stable-backport: Backported in 6.1.54" CVE_STATUS[CVE-2023-4921] = "cpe-stable-backport: Backported in 6.1.54" +CVE_STATUS[CVE-2023-50431] = "cpe-stable-backport: Backported in 6.1.75" + CVE_STATUS[CVE-2023-5090] = "cpe-stable-backport: Backported in 6.1.62" +CVE_STATUS[CVE-2023-51042] = "cpe-stable-backport: Backported in 6.1.47" + +CVE_STATUS[CVE-2023-51043] = "cpe-stable-backport: Backported in 6.1.40" + CVE_STATUS[CVE-2023-5158] = "cpe-stable-backport: Backported in 6.1.57" -# CVE-2023-5178 needs backporting (fixed from 6.1.60) +CVE_STATUS[CVE-2023-51779] = "cpe-stable-backport: Backported in 6.1.70" + +CVE_STATUS[CVE-2023-5178] = "cpe-stable-backport: Backported in 6.1.60" + +CVE_STATUS[CVE-2023-51780] = "cpe-stable-backport: Backported in 6.1.69" + +CVE_STATUS[CVE-2023-51781] = "cpe-stable-backport: Backported in 6.1.69" + +CVE_STATUS[CVE-2023-51782] = "cpe-stable-backport: Backported in 6.1.69" CVE_STATUS[CVE-2023-5197] = "cpe-stable-backport: Backported in 6.1.56" +CVE_STATUS[CVE-2023-52340] = "cpe-stable-backport: Backported in 6.1.73" + CVE_STATUS[CVE-2023-5345] = "cpe-stable-backport: Backported in 6.1.56" CVE_STATUS[CVE-2023-5633] = "fixed-version: only affects 6.2 onwards" -# CVE-2023-5717 needs backporting (fixed from 6.1.60) +CVE_STATUS[CVE-2023-5717] = "cpe-stable-backport: Backported in 6.1.60" -# CVE-2023-5972 needs backporting (fixed from 6.6rc7) +CVE_STATUS[CVE-2023-5972] = "fixed-version: only affects 6.2rc1 onwards" # CVE-2023-6039 needs backporting (fixed from 6.5rc5) +CVE_STATUS[CVE-2023-6040] = "fixed-version: Fixed from version 5.18rc1" + CVE_STATUS[CVE-2023-6111] = "fixed-version: only affects 6.6rc3 onwards" CVE_STATUS[CVE-2023-6121] = "cpe-stable-backport: Backported in 6.1.65" CVE_STATUS[CVE-2023-6176] = "cpe-stable-backport: Backported in 6.1.54" +CVE_STATUS[CVE-2023-6200] = "fixed-version: only affects 6.6rc1 onwards" + # CVE-2023-6238 has no known resolution +# CVE-2023-6240 has no known resolution + +# CVE-2023-6270 has no known resolution + +# CVE-2023-6356 has no known resolution + +CVE_STATUS[CVE-2023-6531] = "cpe-stable-backport: Backported in 6.1.68" + +# CVE-2023-6535 has no known resolution + +# CVE-2023-6536 has no known resolution + +CVE_STATUS[CVE-2023-6546] = "cpe-stable-backport: Backported in 6.1.47" + +# CVE-2023-6560 needs backporting (fixed from 6.7rc4) + +CVE_STATUS[CVE-2023-6606] = "cpe-stable-backport: Backported in 6.1.70" + +CVE_STATUS[CVE-2023-6610] = "cpe-stable-backport: Backported in 6.1.74" + +CVE_STATUS[CVE-2023-6622] = "cpe-stable-backport: Backported in 6.1.68" + +CVE_STATUS[CVE-2023-6679] = "fixed-version: only affects 6.7rc1 onwards" + +CVE_STATUS[CVE-2023-6817] = "cpe-stable-backport: Backported in 6.1.68" + +CVE_STATUS[CVE-2023-6915] = "cpe-stable-backport: Backported in 6.1.74" + +CVE_STATUS[CVE-2023-6931] = "cpe-stable-backport: Backported in 6.1.68" + +CVE_STATUS[CVE-2023-6932] = "cpe-stable-backport: Backported in 6.1.66" + +# CVE-2023-7042 has no known resolution + +CVE_STATUS[CVE-2023-7192] = "cpe-stable-backport: Backported in 6.1.18" + +CVE_STATUS[CVE-2024-0193] = "fixed-version: only affects 6.5rc6 onwards" + +# CVE-2024-0340 needs backporting (fixed from 6.4rc6) + +CVE_STATUS[CVE-2024-0443] = "fixed-version: only affects 6.2rc1 onwards" + +CVE_STATUS[CVE-2024-0562] = "fixed-version: Fixed from version 6.0rc3" + +# CVE-2024-0564 has no known resolution + +CVE_STATUS[CVE-2024-0565] = "cpe-stable-backport: Backported in 6.1.69" + +CVE_STATUS[CVE-2024-0582] = "fixed-version: only affects 6.4rc1 onwards" + +CVE_STATUS[CVE-2024-0584] = "cpe-stable-backport: Backported in 6.1.66" + +CVE_STATUS[CVE-2024-0607] = "cpe-stable-backport: Backported in 6.1.64" + +CVE_STATUS[CVE-2024-0639] = "cpe-stable-backport: Backported in 6.1.39" + +CVE_STATUS[CVE-2024-0641] = "cpe-stable-backport: Backported in 6.1.57" + +CVE_STATUS[CVE-2024-0646] = "cpe-stable-backport: Backported in 6.1.69" + +CVE_STATUS[CVE-2024-0775] = "cpe-stable-backport: Backported in 6.1.29" + +# CVE-2024-0841 has no known resolution + +CVE_STATUS[CVE-2024-1085] = "cpe-stable-backport: Backported in 6.1.75" + +CVE_STATUS[CVE-2024-1086] = "cpe-stable-backport: Backported in 6.1.76" + +# CVE-2024-1312 needs backporting (fixed from 6.5rc4) + +# CVE-2024-21803 has no known resolution + +# CVE-2024-22099 has no known resolution + +# CVE-2024-22386 has no known resolution + +CVE_STATUS[CVE-2024-22705] = "cpe-stable-backport: Backported in 6.1.71" + +# CVE-2024-23196 has no known resolution + +# CVE-2024-23307 has no known resolution + +# CVE-2024-23848 has no known resolution + +CVE_STATUS[CVE-2024-23849] = "cpe-stable-backport: Backported in 6.1.76" + +# CVE-2024-23850 has no known resolution + +# CVE-2024-23851 has no known resolution + +# CVE-2024-24855 has no known resolution + +# CVE-2024-24857 has no known resolution + +# CVE-2024-24858 has no known resolution + +# CVE-2024-24859 has no known resolution + +# CVE-2024-24860 has no known resolution + +# CVE-2024-24861 has no known resolution + +# CVE-2024-24864 has no known resolution + diff --git a/poky/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb b/poky/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb index 5cfc5a7dd8..cbf8a18d30 100644 --- a/poky/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb +++ b/poky/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb @@ -14,13 +14,13 @@ python () { raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it") } -SRCREV_machine ?= "739b3001f20153a66d2723de81faae18cd61892b" -SRCREV_meta ?= "991713c8765172cb5d18703d15589f3ec6e1b772" +SRCREV_machine ?= "8c4c2f0278e1c64eb5e95bfb23d6322e81090b3d" +SRCREV_meta ?= "ea5365f818fb6031ec97b8ae7a88bb83001b901e" SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine;protocol=https \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-6.1;destsuffix=${KMETA};protocol=https" -LINUX_VERSION ?= "6.1.68" +LINUX_VERSION ?= "6.1.78" LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46" diff --git a/poky/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb b/poky/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb index e19b0ec132..3f100b579f 100644 --- a/poky/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb +++ b/poky/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb @@ -8,7 +8,7 @@ require recipes-kernel/linux/linux-yocto.inc # CVE exclusions include recipes-kernel/linux/cve-exclusion_6.1.inc -LINUX_VERSION ?= "6.1.68" +LINUX_VERSION ?= "6.1.78" LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46" DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}" @@ -17,8 +17,8 @@ DEPENDS += "openssl-native util-linux-native" KMETA = "kernel-meta" KCONF_BSP_AUDIT_LEVEL = "2" -SRCREV_machine ?= "db1e71dc5c31557828fae0084b0f9cc83882eacd" -SRCREV_meta ?= "991713c8765172cb5d18703d15589f3ec6e1b772" +SRCREV_machine ?= "d025fe8c17718aa4c837bfafee0f3aa0f830bc75" +SRCREV_meta ?= "ea5365f818fb6031ec97b8ae7a88bb83001b901e" PV = "${LINUX_VERSION}+git" diff --git a/poky/meta/recipes-kernel/linux/linux-yocto_6.1.bb b/poky/meta/recipes-kernel/linux/linux-yocto_6.1.bb index 1329ccc958..982996b9a8 100644 --- a/poky/meta/recipes-kernel/linux/linux-yocto_6.1.bb +++ b/poky/meta/recipes-kernel/linux/linux-yocto_6.1.bb @@ -18,25 +18,25 @@ KBRANCH:qemux86-64 ?= "v6.1/standard/base" KBRANCH:qemuloongarch64 ?= "v6.1/standard/base" KBRANCH:qemumips64 ?= "v6.1/standard/mti-malta64" -SRCREV_machine:qemuarm ?= "85915187700314cb7ac70fd33da3e9dfd7c20063" -SRCREV_machine:qemuarm64 ?= "db1e71dc5c31557828fae0084b0f9cc83882eacd" -SRCREV_machine:qemuloongarch64 ?= "db1e71dc5c31557828fae0084b0f9cc83882eacd" -SRCREV_machine:qemumips ?= "24b06ee00fc3b65a24d7e867148b08a85296e67c" -SRCREV_machine:qemuppc ?= "db1e71dc5c31557828fae0084b0f9cc83882eacd" -SRCREV_machine:qemuriscv64 ?= "db1e71dc5c31557828fae0084b0f9cc83882eacd" -SRCREV_machine:qemuriscv32 ?= "db1e71dc5c31557828fae0084b0f9cc83882eacd" -SRCREV_machine:qemux86 ?= "db1e71dc5c31557828fae0084b0f9cc83882eacd" -SRCREV_machine:qemux86-64 ?= "db1e71dc5c31557828fae0084b0f9cc83882eacd" -SRCREV_machine:qemumips64 ?= "d4659a339611a02e4ffc2861e697c1a278707d70" -SRCREV_machine ?= "db1e71dc5c31557828fae0084b0f9cc83882eacd" -SRCREV_meta ?= "991713c8765172cb5d18703d15589f3ec6e1b772" +SRCREV_machine:qemuarm ?= "2f7e672f9677d3cc448ec7e004763f76f95c7fe0" +SRCREV_machine:qemuarm64 ?= "d025fe8c17718aa4c837bfafee0f3aa0f830bc75" +SRCREV_machine:qemuloongarch64 ?= "d025fe8c17718aa4c837bfafee0f3aa0f830bc75" +SRCREV_machine:qemumips ?= "f6c42d90dab94077c1c8b6b7eb77d6ca85eab07e" +SRCREV_machine:qemuppc ?= "ff10270b2748ad74c93ef0abf8e76a464665c23d" +SRCREV_machine:qemuriscv64 ?= "d025fe8c17718aa4c837bfafee0f3aa0f830bc75" +SRCREV_machine:qemuriscv32 ?= "d025fe8c17718aa4c837bfafee0f3aa0f830bc75" +SRCREV_machine:qemux86 ?= "d025fe8c17718aa4c837bfafee0f3aa0f830bc75" +SRCREV_machine:qemux86-64 ?= "d025fe8c17718aa4c837bfafee0f3aa0f830bc75" +SRCREV_machine:qemumips64 ?= "01b545e3fd1f9ea66d812e281de06b07c861dd69" +SRCREV_machine ?= "d025fe8c17718aa4c837bfafee0f3aa0f830bc75" +SRCREV_meta ?= "ea5365f818fb6031ec97b8ae7a88bb83001b901e" # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and you'll # get the <version>/base branch, which is pure upstream -stable, and the same # meta SRCREV as the linux-yocto-standard builds. Select your version using the # normal PREFERRED_VERSION settings. BBCLASSEXTEND = "devupstream:target" -SRCREV_machine:class-devupstream ?= "ba6f5fb465114fcd48ddb2c7a7740915b2289d6b" +SRCREV_machine:class-devupstream ?= "8b4118fabd6eb75fed19483b04dab3a036886489" PN:class-devupstream = "linux-yocto-upstream" KBRANCH:class-devupstream = "v6.1/base" @@ -45,7 +45,7 @@ SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRA SRC_URI += "file://0001-perf-cpumap-Make-counter-as-unsigned-ints.patch" LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46" -LINUX_VERSION ?= "6.1.68" +LINUX_VERSION ?= "6.1.78" PV = "${LINUX_VERSION}+git" diff --git a/poky/meta/recipes-kernel/wireless-regdb/wireless-regdb_2023.09.01.bb b/poky/meta/recipes-kernel/wireless-regdb/wireless-regdb_2024.01.23.bb index c09600ecbe..8fde236ab4 100644 --- a/poky/meta/recipes-kernel/wireless-regdb/wireless-regdb_2023.09.01.bb +++ b/poky/meta/recipes-kernel/wireless-regdb/wireless-regdb_2024.01.23.bb @@ -5,7 +5,7 @@ LICENSE = "ISC" LIC_FILES_CHKSUM = "file://LICENSE;md5=07c4f6dea3845b02a18dc00c8c87699c" SRC_URI = "https://www.kernel.org/pub/software/network/${BPN}/${BP}.tar.xz" -SRC_URI[sha256sum] = "26d4c2a727cc59239b84735aad856b7c7d0b04e30aa5c235c4f7f47f5f053491" +SRC_URI[sha256sum] = "c8a61c9acf76fa7eb4239e89f640dee3e87098d9f69b4d3518c9c60fc6d20c55" inherit bin_package allarch @@ -13,7 +13,7 @@ do_install() { install -d -m0755 ${D}${nonarch_libdir}/crda install -d -m0755 ${D}${sysconfdir}/wireless-regdb/pubkeys install -m 0644 regulatory.bin ${D}${nonarch_libdir}/crda/regulatory.bin - install -m 0644 sforshee.key.pub.pem ${D}${sysconfdir}/wireless-regdb/pubkeys/sforshee.key.pub.pem + install -m 0644 wens.key.pub.pem ${D}${sysconfdir}/wireless-regdb/pubkeys/wens.key.pub.pem install -m 0644 -D regulatory.db ${D}${nonarch_base_libdir}/firmware/regulatory.db install -m 0644 regulatory.db.p7s ${D}${nonarch_base_libdir}/firmware/regulatory.db.p7s diff --git a/poky/meta/recipes-multimedia/gstreamer/gst-devtools_1.22.7.bb b/poky/meta/recipes-multimedia/gstreamer/gst-devtools_1.22.9.bb index b545f020cf..f60234b528 100644 --- a/poky/meta/recipes-multimedia/gstreamer/gst-devtools_1.22.7.bb +++ b/poky/meta/recipes-multimedia/gstreamer/gst-devtools_1.22.9.bb @@ -12,7 +12,7 @@ SRC_URI = "https://gstreamer.freedesktop.org/src/gst-devtools/gst-devtools-${PV} file://0001-connect-has-a-different-signature-on-musl.patch \ " -SRC_URI[sha256sum] = "157cf93fb2741cf0c3dea731be3af2ffae703c9f2cd3c0c91b380fbc685eb9f9" +SRC_URI[sha256sum] = "02e29400b44e9cc603aa6444dee5726b57edabef6455e6d0921ffed6f13840ee" DEPENDS = "json-glib glib-2.0 glib-2.0-native gstreamer1.0 gstreamer1.0-plugins-base" RRECOMMENDS:${PN} = "git" diff --git a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.22.7.bb b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.22.9.bb index 7169223636..10536acc87 100644 --- a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.22.7.bb +++ b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.22.9.bb @@ -12,7 +12,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=69333daa044cb77e486cc36129f7a770 \ " SRC_URI = "https://gstreamer.freedesktop.org/src/gst-libav/gst-libav-${PV}.tar.xz" -SRC_URI[sha256sum] = "1525b917141b895fe5cf618fe8867622b2528278a0286e9f727b5f37317daca1" +SRC_URI[sha256sum] = "192f7d27d21c1e7c72c339a2647a9b0c247fedc62ea5029115f8c3e22ebb87d8" S = "${WORKDIR}/gst-libav-${PV}" diff --git a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.22.7.bb b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.22.9.bb index ad40cf5513..05d64748bb 100644 --- a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.22.7.bb +++ b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.22.9.bb @@ -10,7 +10,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c \ SRC_URI = "https://gstreamer.freedesktop.org/src/gst-omx/gst-omx-${PV}.tar.xz" -SRC_URI[sha256sum] = "d7a18ec47d40a472bd5cba2015e0be72b732f1699895398cec5cd8e6a3a53b44" +SRC_URI[sha256sum] = "9362d6117985d09dcf6e27bdaef377dc08efb7df01d00101d04fb644addac61e" S = "${WORKDIR}/gst-omx-${PV}" diff --git a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.22.7.bb b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.22.9.bb index b7d787b611..6e5aa2f206 100644 --- a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.22.7.bb +++ b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.22.9.bb @@ -10,7 +10,7 @@ SRC_URI = "https://gstreamer.freedesktop.org/src/gst-plugins-bad/gst-plugins-bad file://0002-avoid-including-sys-poll.h-directly.patch \ file://0004-opencv-resolve-missing-opencv-data-dir-in-yocto-buil.patch \ " -SRC_URI[sha256sum] = "c716f8dffa8fac3fb646941af1c6ec72fff05a045131311bf2d049fdc87bce2e" +SRC_URI[sha256sum] = "1bc65d0fd5f53a3636564efd3fcf318c3edcdec39c4109a503c1fc8203840a1d" S = "${WORKDIR}/gst-plugins-bad-${PV}" diff --git a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.22.7.bb b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.22.9.bb index 3b8923e8f2..980766c74b 100644 --- a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.22.7.bb +++ b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.22.9.bb @@ -11,7 +11,7 @@ SRC_URI = "https://gstreamer.freedesktop.org/src/gst-plugins-base/gst-plugins-ba file://0003-viv-fb-Make-sure-config.h-is-included.patch \ file://0002-ssaparse-enhance-SSA-text-lines-parsing.patch \ " -SRC_URI[sha256sum] = "62519e0d8f969ebf62a9a7996f2d23efdda330217a635f4a32c0bf1c71577468" +SRC_URI[sha256sum] = "fac3e0dd2d8e9370388b34bf8c21b89d5f63bc3cfc12cd7fdc8fc6c1cba03334" S = "${WORKDIR}/gst-plugins-base-${PV}" diff --git a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.22.7.bb b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.22.9.bb index b8496a1750..052ba1801b 100644 --- a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.22.7.bb +++ b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.22.9.bb @@ -8,7 +8,7 @@ SRC_URI = "https://gstreamer.freedesktop.org/src/gst-plugins-good/gst-plugins-go file://0001-qt-include-ext-qt-gstqtgl.h-instead-of-gst-gl-gstglf.patch \ file://0001-v4l2-Define-ioctl_req_t-for-posix-linux-case.patch" -SRC_URI[sha256sum] = "b6db0e18e398b52665b7cdce301c34a8750483d5f4fbac1ede9f80b03743cd15" +SRC_URI[sha256sum] = "26959fcfebfff637d4ea08ef40316baf31b61bb7729820b0684e800c3a1478b6" S = "${WORKDIR}/gst-plugins-good-${PV}" diff --git a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.22.7.bb b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.22.9.bb index 8a67531123..722f8e9fe3 100644 --- a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.22.7.bb +++ b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-ugly_1.22.9.bb @@ -14,7 +14,8 @@ LICENSE_FLAGS = "commercial" SRC_URI = " \ https://gstreamer.freedesktop.org/src/gst-plugins-ugly/gst-plugins-ugly-${PV}.tar.xz \ " -SRC_URI[sha256sum] = "520b46bca637189ad86a298ff245b2d89375dbcac8b05d74daea910f81a9e9da" + +SRC_URI[sha256sum] = "0bf685d66015a01dd3fc1671b64a1c8acb321dd9d4ab9e05a29ab19782aa6236" S = "${WORKDIR}/gst-plugins-ugly-${PV}" diff --git a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.22.7.bb b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.22.9.bb index a387031635..e086fa6866 100644 --- a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.22.7.bb +++ b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-python_1.22.9.bb @@ -8,7 +8,7 @@ LICENSE = "LGPL-2.1-or-later" LIC_FILES_CHKSUM = "file://COPYING;md5=c34deae4e395ca07e725ab0076a5f740" SRC_URI = "https://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz" -SRC_URI[sha256sum] = "1ef8df7608012fa469329799c950ec087737a6dabad3003c230658b58c710172" +SRC_URI[sha256sum] = "3f9d5c6ffefda268703744b592a6b3983aa6723273b1220ecbcb62c2a5800009" DEPENDS = "gstreamer1.0 gstreamer1.0-plugins-base python3-pygobject" RDEPENDS:${PN} += "gstreamer1.0 gstreamer1.0-plugins-base python3-pygobject" diff --git a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.22.7.bb b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.22.9.bb index af1c2ced44..e232263a46 100644 --- a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.22.7.bb +++ b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.22.9.bb @@ -10,7 +10,7 @@ PNREAL = "gst-rtsp-server" SRC_URI = "https://gstreamer.freedesktop.org/src/${PNREAL}/${PNREAL}-${PV}.tar.xz" -SRC_URI[sha256sum] = "f7fac001e20ad21e36d18397741c4657c5d43571eb1cc3b49f9a93ae127dc88f" +SRC_URI[sha256sum] = "808af148f89404ff74850f8ca5272bed4bfe67f9620231dc4514fd07eb26d0a4" S = "${WORKDIR}/${PNREAL}-${PV}" diff --git a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.22.7.bb b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.22.9.bb index 4cad50742d..c53ee29051 100644 --- a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.22.7.bb +++ b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.22.9.bb @@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=4fbd65380cdd255951079008b364516c" SRC_URI = "https://gstreamer.freedesktop.org/src/${REALPN}/${REALPN}-${PV}.tar.xz" -SRC_URI[sha256sum] = "0e9fff768b89de6d318b34146e4e781d82b9a0f4025dc541b2c8349c7bcb7f67" +SRC_URI[sha256sum] = "8ba20da8c4cbf5b2953dba904672c4275d0053e1528f97fdf8e59942c7883ca8" S = "${WORKDIR}/${REALPN}-${PV}" DEPENDS = "libva gstreamer1.0 gstreamer1.0-plugins-base gstreamer1.0-plugins-bad" diff --git a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0/skip-aggregator-test.patch b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0/skip-aggregator-test.patch new file mode 100644 index 0000000000..81337512fd --- /dev/null +++ b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0/skip-aggregator-test.patch @@ -0,0 +1,35 @@ +From 9b72aa7cdbc2a81cffc6f855933afe90c81046d5 Mon Sep 17 00:00:00 2001 +From: Ross Burton <ross.burton@arm.com> +Date: Wed, 28 Feb 2024 12:40:34 +0000 +Subject: [PATCH] Skip aggregator test + +This test case is known to be flaky upstream[1] and often fails on the +autobuilder[2], so skip it until this has been resolved upstream. + +[1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/410 +[2] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15054 + +Upstream-Status: Inappropriate +Signed-off-by: Ross Burton <ross.burton@arm.com> +--- + tests/check/libs/aggregator.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/tests/check/libs/aggregator.c b/tests/check/libs/aggregator.c +index 1f2c5b4..27b3ac7 100644 +--- a/tests/check/libs/aggregator.c ++++ b/tests/check/libs/aggregator.c +@@ -1475,7 +1475,9 @@ gst_aggregator_suite (void) + tcase_add_test (general, test_flushing_seek); + tcase_add_test (general, test_infinite_seek); + tcase_add_test (general, test_infinite_seek_50_src); +- tcase_add_test (general, test_infinite_seek_50_src_live); ++ // This test case is known to be flaky, remove it until resolved: ++ // https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/410 ++ // tcase_add_test (general, test_infinite_seek_50_src_live); + tcase_add_test (general, test_linear_pipeline); + tcase_add_test (general, test_two_src_pipeline); + tcase_add_test (general, test_timeout_pipeline); +-- +2.34.1 + diff --git a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.22.7.bb b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.22.9.bb index 72161b272f..9d634e35dc 100644 --- a/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.22.7.bb +++ b/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0_1.22.9.bb @@ -21,8 +21,9 @@ SRC_URI = "https://gstreamer.freedesktop.org/src/gstreamer/gstreamer-${PV}.tar.x file://0002-tests-add-support-for-install-the-tests.patch \ file://0003-tests-use-a-dictionaries-for-environment.patch;striplevel=3 \ file://0004-tests-add-helper-script-to-run-the-installed_tests.patch;striplevel=3 \ + file://skip-aggregator-test.patch \ " -SRC_URI[sha256sum] = "01e42c6352a06bdfa4456e64b06ab7d98c5c487a25557c761554631cbda64217" +SRC_URI[sha256sum] = "1e7124d347e8cdc80f08ec1d370c201be513002af1102bb20e83c5279cb48ebd" PACKAGECONFIG ??= "${@bb.utils.contains('PTEST_ENABLED', '1', 'tests', '', d)} \ check \ diff --git a/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-52355-0001.patch b/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-52355-0001.patch new file mode 100644 index 0000000000..f5520fcafd --- /dev/null +++ b/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-52355-0001.patch @@ -0,0 +1,238 @@ +From 335947359ce2dd3862cd9f7c49f92eba065dfed4 Mon Sep 17 00:00:00 2001 +From: Su_Laus <sulau@freenet.de> +Date: Thu, 1 Feb 2024 13:06:08 +0000 +Subject: [PATCH] manpage: Update TIFF documentation about TIFFOpenOptions.rst + and TIFFOpenOptionsSetMaxSingleMemAlloc() usage and some other small fixes. + +CVE: CVE-2023-52355 +Upstream-Status: Backport [https://gitlab.com/libtiff/libtiff/-/commit/335947359ce2dd3862cd9f7c49f92eba065dfed4] + +Signed-off-by: Yogita Urade <yogita.urade@windriver.com> +--- + doc/functions/TIFFDeferStrileArrayWriting.rst | 5 +++ + doc/functions/TIFFError.rst | 3 ++ + doc/functions/TIFFOpen.rst | 13 +++--- + doc/functions/TIFFOpenOptions.rst | 44 ++++++++++++++++++- + doc/functions/TIFFStrileQuery.rst | 5 +++ + doc/libtiff.rst | 31 ++++++++++++- + 6 files changed, 91 insertions(+), 10 deletions(-) + +diff --git a/doc/functions/TIFFDeferStrileArrayWriting.rst b/doc/functions/TIFFDeferStrileArrayWriting.rst +index 60ee746..705aebc 100644 +--- a/doc/functions/TIFFDeferStrileArrayWriting.rst ++++ b/doc/functions/TIFFDeferStrileArrayWriting.rst +@@ -61,6 +61,11 @@ Diagnostics + All error messages are directed to the :c:func:`TIFFErrorExtR` routine. + Likewise, warning messages are directed to the :c:func:`TIFFWarningExtR` routine. + ++Note ++---- ++ ++This functionality was introduced with libtiff 4.1. ++ + See also + -------- + +diff --git a/doc/functions/TIFFError.rst b/doc/functions/TIFFError.rst +index 99924ad..cf4b37c 100644 +--- a/doc/functions/TIFFError.rst ++++ b/doc/functions/TIFFError.rst +@@ -65,6 +65,9 @@ or :c:func:`TIFFClientOpenExt`. + Furthermore, a **custom defined data structure** *user_data* for the + error handler can be given along. + ++Please refer to :doc:`/functions/TIFFOpenOptions` for how to setup the ++application-specific handler introduced with libtiff 4.5. ++ + Note + ---- + +diff --git a/doc/functions/TIFFOpen.rst b/doc/functions/TIFFOpen.rst +index db79d7b..adc474f 100644 +--- a/doc/functions/TIFFOpen.rst ++++ b/doc/functions/TIFFOpen.rst +@@ -94,8 +94,9 @@ TIFF structure without closing the file handle and afterwards the + file should be closed using its file descriptor *fd*. + + :c:func:`TIFFOpenExt` (added in libtiff 4.5) is like :c:func:`TIFFOpen`, +-but options, such as re-entrant error and warning handlers may be passed +-with the *opts* argument. The *opts* argument may be NULL. ++but options, such as re-entrant error and warning handlers and a limit in byte ++that libtiff internal memory allocation functions are allowed to request per call ++may be passed with the *opts* argument. The *opts* argument may be NULL. + Refer to :doc:`TIFFOpenOptions` for allocating and filling the *opts* argument + parameters. The allocated memory for :c:type:`TIFFOpenOptions` + can be released straight after successful execution of the related +@@ -105,9 +106,7 @@ can be released straight after successful execution of the related + but opens a TIFF file with a Unicode filename. + + :c:func:`TIFFFdOpenExt` (added in libtiff 4.5) is like :c:func:`TIFFFdOpen`, +-but options, such as re-entrant error and warning handlers may be passed +-with the *opts* argument. The *opts* argument may be NULL. +-Refer to :doc:`TIFFOpenOptions` for filling the *opts* argument. ++but options argument *opts* like for :c:func:`TIFFOpenExt` can be passed. + + :c:func:`TIFFSetFileName` sets the file name in the tif-structure + and returns the old file name. +@@ -326,5 +325,5 @@ See also + + :doc:`libtiff` (3tiff), + :doc:`TIFFClose` (3tiff), +-:doc:`TIFFStrileQuery`, +-:doc:`TIFFOpenOptions` +\ No newline at end of file ++:doc:`TIFFStrileQuery` (3tiff), ++:doc:`TIFFOpenOptions` +diff --git a/doc/functions/TIFFOpenOptions.rst b/doc/functions/TIFFOpenOptions.rst +index 5c67566..23f2975 100644 +--- a/doc/functions/TIFFOpenOptions.rst ++++ b/doc/functions/TIFFOpenOptions.rst +@@ -38,12 +38,17 @@ opaque structure and returns a :c:type:`TIFFOpenOptions` pointer. + :c:func:`TIFFOpenOptionsFree` releases the allocated memory for + :c:type:`TIFFOpenOptions`. The allocated memory for :c:type:`TIFFOpenOptions` + can be released straight after successful execution of the related +-TIFF open"Ext" functions like :c:func:`TIFFOpenExt`. ++TIFFOpen"Ext" functions like :c:func:`TIFFOpenExt`. + + :c:func:`TIFFOpenOptionsSetMaxSingleMemAlloc` sets parameter for the + maximum single memory limit in byte that ``libtiff`` internal memory allocation + functions are allowed to request per call. + ++.. note:: ++ However, the ``libtiff`` external functions :c:func:`_TIFFmalloc` ++ and :c:func:`_TIFFrealloc` **do not apply** this internal memory ++ allocation limit set by :c:func:`TIFFOpenOptionsSetMaxSingleMemAlloc`! ++ + :c:func:`TIFFOpenOptionsSetErrorHandlerExtR` sets the function pointer to + an application-specific and per-TIFF handle (re-entrant) error handler. + Furthermore, a pointer to a **custom defined data structure** *errorhandler_user_data* +@@ -55,6 +60,43 @@ The *errorhandler_user_data* argument may be NULL. + :c:func:`TIFFOpenOptionsSetErrorHandlerExtR` but for the warning handler, + which is invoked through :c:func:`TIFFWarningExtR` + ++Example ++------- ++ ++:: ++ ++ #include "tiffio.h" ++ ++ typedef struct MyErrorHandlerUserDataStruct ++ { ++ /* ... any user data structure ... */ ++ } MyErrorHandlerUserDataStruct; ++ ++ static int myErrorHandler(TIFF *tiff, void *user_data, const char *module, ++ const char *fmt, va_list ap) ++ { ++ MyErrorHandlerUserDataStruct *errorhandler_user_data = ++ (MyErrorHandlerUserDataStruct *)user_data; ++ /*... code of myErrorHandler ...*/ ++ return 1; ++ } ++ ++ ++ main() ++ { ++ tmsize_t limit = (256 * 1024 * 1024); ++ MyErrorHandlerUserDataStruct user_data = { /* ... any data ... */}; ++ ++ TIFFOpenOptions *opts = TIFFOpenOptionsAlloc(); ++ TIFFOpenOptionsSetMaxSingleMemAlloc(opts, limit); ++ TIFFOpenOptionsSetErrorHandlerExtR(opts, myErrorHandler, &user_data); ++ TIFF *tif = TIFFOpenExt("foo.tif", "r", opts); ++ TIFFOpenOptionsFree(opts); ++ /* ... go on here ... */ ++ ++ TIFFClose(tif); ++ } ++ + Note + ---- + +diff --git a/doc/functions/TIFFStrileQuery.rst b/doc/functions/TIFFStrileQuery.rst +index f8631af..7931fe4 100644 +--- a/doc/functions/TIFFStrileQuery.rst ++++ b/doc/functions/TIFFStrileQuery.rst +@@ -66,6 +66,11 @@ Diagnostics + All error messages are directed to the :c:func:`TIFFErrorExtR` routine. + Likewise, warning messages are directed to the :c:func:`TIFFWarningExtR` routine. + ++Note ++---- ++ ++This functionality was introduced with libtiff 4.1. ++ + See also + -------- + +diff --git a/doc/libtiff.rst b/doc/libtiff.rst +index 6a0054c..d96a860 100644 +--- a/doc/libtiff.rst ++++ b/doc/libtiff.rst +@@ -90,11 +90,15 @@ compatibility on machines with a segmented architecture. + :c:func:`realloc`, and :c:func:`free` routines in the C library.) + + To deal with segmented pointer issues ``libtiff`` also provides +-:c:func:`_TIFFmemcpy`, :c:func:`_TIFFmemset`, and :c:func:`_TIFFmemmove` ++:c:func:`_TIFFmemcpy`, :c:func:`_TIFFmemset`, and :c:func:`_TIFFmemcmp` + routines that mimic the equivalent ANSI C routines, but that are + intended for use with memory allocated through :c:func:`_TIFFmalloc` + and :c:func:`_TIFFrealloc`. + ++With ``libtiff`` 4.5 a method was introduced to limit the internal ++memory allocation that functions are allowed to request per call ++(see :c:func:`TIFFOpenOptionsSetMaxSingleMemAlloc` and :c:func:`TIFFOpenExt`). ++ + Error Handling + -------------- + +@@ -106,6 +110,10 @@ routine that can be specified with a call to :c:func:`TIFFSetErrorHandler`. + Likewise warning messages are directed to a single handler routine + that can be specified with a call to :c:func:`TIFFSetWarningHandler` + ++Further application-specific and per-TIFF handle (re-entrant) error handler ++and warning handler can be set. Please refer to :doc:`/functions/TIFFError` ++and :doc:`/functions/TIFFOpenOptions`. ++ + Basic File Handling + ------------------- + +@@ -139,7 +147,7 @@ a ``"w"`` argument: + main() + { + TIFF* tif = TIFFOpen("foo.tif", "w"); +- ... do stuff ... ++ /* ... do stuff ... */ + TIFFClose(tif); + } + +@@ -157,6 +165,25 @@ to always call :c:func:`TIFFClose` or :c:func:`TIFFFlush` to flush any + buffered information to a file. Note that if you call :c:func:`TIFFClose` + you do not need to call :c:func:`TIFFFlush`. + ++.. warning:: ++ ++ In order to prevent out-of-memory issues when opening a TIFF file ++ :c:func:`TIFFOpenExt` can be used and then the maximum single memory ++ limit in byte that ``libtiff`` internal memory allocation functions ++ are allowed to request per call can be set with ++ :c:func:`TIFFOpenOptionsSetMaxSingleMemAlloc`. ++ ++Example ++ ++:: ++ ++ tmsize_t limit = (256 * 1024 * 1024); ++ TIFFOpenOptions *opts = TIFFOpenOptionsAlloc(); ++ TIFFOpenOptionsSetMaxSingleMemAlloc(opts, limit); ++ TIFF *tif = TIFFOpenExt("foo.tif", "w", opts); ++ TIFFOpenOptionsFree(opts); ++ /* ... go on here ... */ ++ + TIFF Directories + ---------------- + +-- +2.40.0 + diff --git a/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-52355-0002.patch b/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-52355-0002.patch new file mode 100644 index 0000000000..19a1ef727a --- /dev/null +++ b/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-52355-0002.patch @@ -0,0 +1,28 @@ +From 16ab4a205cfc938c32686e8d697d048fabf97ed4 Mon Sep 17 00:00:00 2001 +From: Timothy Lyanguzov <theta682@gmail.com> +Date: Thu, 1 Feb 2024 11:19:06 +0000 +Subject: [PATCH] Fix typo. + +CVE: CVE-2023-52355 +Upstream-Status: Backport [https://gitlab.com/libtiff/libtiff/-/commit/16ab4a205cfc938c32686e8d697d048fabf97ed4] + +Signed-off-by: Yogita Urade <yogita.urade@windriver.com> +--- + doc/libtiff.rst | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/doc/libtiff.rst b/doc/libtiff.rst +index d96a860..4fedc3e 100644 +--- a/doc/libtiff.rst ++++ b/doc/libtiff.rst +@@ -169,7 +169,7 @@ you do not need to call :c:func:`TIFFFlush`. + + In order to prevent out-of-memory issues when opening a TIFF file + :c:func:`TIFFOpenExt` can be used and then the maximum single memory +- limit in byte that ``libtiff`` internal memory allocation functions ++ limit in bytes that ``libtiff`` internal memory allocation functions + are allowed to request per call can be set with + :c:func:`TIFFOpenOptionsSetMaxSingleMemAlloc`. + +-- +2.40.0 diff --git a/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-52356.patch b/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-52356.patch new file mode 100644 index 0000000000..75f5d8946a --- /dev/null +++ b/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-52356.patch @@ -0,0 +1,49 @@ +From 51558511bdbbcffdce534db21dbaf5d54b31638a Mon Sep 17 00:00:00 2001 +From: Even Rouault <even.rouault@spatialys.com> +Date: Thu, 1 Feb 2024 11:38:14 +0000 +Subject: [PATCH] TIFFReadRGBAStrip/TIFFReadRGBATile: add more validation of + col/row (fixes #622) + +CVE: CVE-2023-52356 +Upstream-Status: Backport [https://gitlab.com/libtiff/libtiff/-/commit/51558511bdbbcffdce534db21dbaf5d54b31638a] + +Signed-off-by: Yogita Urade <yogita.urade@windriver.com> +--- + libtiff/tif_getimage.c | 15 +++++++++++++++ + 1 file changed, 15 insertions(+) + +diff --git a/libtiff/tif_getimage.c b/libtiff/tif_getimage.c +index 41f7dfd..9cd6eee 100644 +--- a/libtiff/tif_getimage.c ++++ b/libtiff/tif_getimage.c +@@ -3224,6 +3224,13 @@ int TIFFReadRGBAStripExt(TIFF *tif, uint32_t row, uint32_t *raster, + if (TIFFRGBAImageOK(tif, emsg) && + TIFFRGBAImageBegin(&img, tif, stop_on_error, emsg)) + { ++ if (row >= img.height) ++ { ++ TIFFErrorExtR(tif, TIFFFileName(tif), ++ "Invalid row passed to TIFFReadRGBAStrip()."); ++ TIFFRGBAImageEnd(&img); ++ return (0); ++ } + + img.row_offset = row; + img.col_offset = 0; +@@ -3301,6 +3308,14 @@ int TIFFReadRGBATileExt(TIFF *tif, uint32_t col, uint32_t row, uint32_t *raster, + return (0); + } + ++ if (col >= img.width || row >= img.height) ++ { ++ TIFFErrorExtR(tif, TIFFFileName(tif), ++ "Invalid row/col passed to TIFFReadRGBATile()."); ++ TIFFRGBAImageEnd(&img); ++ return (0); ++ } ++ + /* + * The TIFFRGBAImageGet() function doesn't allow us to get off the + * edge of the image, even to fill an otherwise valid tile. So we +-- +2.40.0 diff --git a/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6228.patch b/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6228.patch new file mode 100644 index 0000000000..2020508fdf --- /dev/null +++ b/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6228.patch @@ -0,0 +1,31 @@ +From 1e7d217a323eac701b134afc4ae39b6bdfdbc96a Mon Sep 17 00:00:00 2001 +From: Su_Laus <sulau@freenet.de> +Date: Wed, 17 Jan 2024 06:57:08 +0000 +Subject: [PATCH] codec of input image is available, independently from codec + check of output image and return with error if not. + +Fixes #606. + +CVE: CVE-2023-6228 +Upstream-Status: Backport [https://gitlab.com/libtiff/libtiff/-/commit/1e7d217a323eac701b134afc4ae39b6bdfdbc96a] + +Signed-off-by: Yogita Urade <yogita.urade@windriver.com> +--- + tools/tiffcp.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/tools/tiffcp.c b/tools/tiffcp.c +index aff0626..a4f7f6b 100644 +--- a/tools/tiffcp.c ++++ b/tools/tiffcp.c +@@ -846,6 +846,8 @@ static int tiffcp(TIFF *in, TIFF *out) + if (!TIFFIsCODECConfigured(compression)) + return FALSE; + TIFFGetFieldDefaulted(in, TIFFTAG_COMPRESSION, &input_compression); ++ if (!TIFFIsCODECConfigured(input_compression)) ++ return FALSE; + TIFFGetFieldDefaulted(in, TIFFTAG_PHOTOMETRIC, &input_photometric); + if (input_compression == COMPRESSION_JPEG) + { +-- +2.40.0 diff --git a/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-Apply-1-suggestion-s-to-1-file-s.patch b/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-Apply-1-suggestion-s-to-1-file-s.patch new file mode 100644 index 0000000000..5d15dff1d9 --- /dev/null +++ b/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-Apply-1-suggestion-s-to-1-file-s.patch @@ -0,0 +1,27 @@ +From e1640519208121f916da1772a5efb6ca28971b86 Mon Sep 17 00:00:00 2001 +From: Even Rouault <even.rouault@spatialys.com> +Date: Tue, 31 Oct 2023 15:04:37 +0000 +Subject: [PATCH 3/3] Apply 1 suggestion(s) to 1 file(s) + +CVE: CVE-2023-6277 +Upstream-Status: Backport [https://gitlab.com/libtiff/libtiff/-/merge_requests/545] +Signed-off-by: Khem Raj <raj.khem@gmail.com> +--- + libtiff/tif_dirread.c | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/libtiff/tif_dirread.c b/libtiff/tif_dirread.c +index fe8d6f8..58a4276 100644 +--- a/libtiff/tif_dirread.c ++++ b/libtiff/tif_dirread.c +@@ -5306,7 +5306,6 @@ static int EstimateStripByteCounts(TIFF *tif, TIFFDirEntry *dir, + { + uint64_t space; + uint16_t n; +- filesize = TIFFGetFileSize(tif); + if (!(tif->tif_flags & TIFF_BIGTIFF)) + space = sizeof(TIFFHeaderClassic) + 2 + dircount * 12 + 4; + else +-- +2.43.0 + diff --git a/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-At-image-reading-compare-data-size-of-some-tags-data-2.patch b/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-At-image-reading-compare-data-size-of-some-tags-data-2.patch new file mode 100644 index 0000000000..9fc8182fef --- /dev/null +++ b/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-At-image-reading-compare-data-size-of-some-tags-data-2.patch @@ -0,0 +1,36 @@ +From f500facf7723f1cae725dd288b2daad15e45131c Mon Sep 17 00:00:00 2001 +From: Su_Laus <sulau@freenet.de> +Date: Mon, 30 Oct 2023 21:21:57 +0100 +Subject: [PATCH 2/3] At image reading, compare data size of some tags / data + structures (StripByteCounts, StripOffsets, StripArray, TIFF directory) with + file size to prevent provoked out-of-memory attacks. +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +See issue #614. + +Correct declaration of ‘filesize’ shadows a previous local. + +CVE: CVE-2023-6277 +Upstream-Status: Backport [https://gitlab.com/libtiff/libtiff/-/merge_requests/545] +Signed-off-by: Khem Raj <raj.khem@gmail.com> +--- + libtiff/tif_dirread.c | 1 - + 1 file changed, 1 deletion(-) + +diff --git a/libtiff/tif_dirread.c b/libtiff/tif_dirread.c +index c52d41f..fe8d6f8 100644 +--- a/libtiff/tif_dirread.c ++++ b/libtiff/tif_dirread.c +@@ -5305,7 +5305,6 @@ static int EstimateStripByteCounts(TIFF *tif, TIFFDirEntry *dir, + if (td->td_compression != COMPRESSION_NONE) + { + uint64_t space; +- uint64_t filesize; + uint16_t n; + filesize = TIFFGetFileSize(tif); + if (!(tif->tif_flags & TIFF_BIGTIFF)) +-- +2.43.0 + diff --git a/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-At-image-reading-compare-data-size-of-some-tags-data.patch b/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-At-image-reading-compare-data-size-of-some-tags-data.patch new file mode 100644 index 0000000000..d5854a9059 --- /dev/null +++ b/poky/meta/recipes-multimedia/libtiff/tiff/CVE-2023-6277-At-image-reading-compare-data-size-of-some-tags-data.patch @@ -0,0 +1,162 @@ +From b33baa5d9c6aac8ce49b5180dd48e39697ab7a11 Mon Sep 17 00:00:00 2001 +From: Su_Laus <sulau@freenet.de> +Date: Fri, 27 Oct 2023 22:11:10 +0200 +Subject: [PATCH 1/3] At image reading, compare data size of some tags / data + structures (StripByteCounts, StripOffsets, StripArray, TIFF directory) with + file size to prevent provoked out-of-memory attacks. + +See issue #614. + +CVE: CVE-2023-6277 +Upstream-Status: Backport [https://gitlab.com/libtiff/libtiff/-/merge_requests/545] +Signed-off-by: Khem Raj <raj.khem@gmail.com> +--- + libtiff/tif_dirread.c | 90 +++++++++++++++++++++++++++++++++++++++++++ + 1 file changed, 90 insertions(+) + +diff --git a/libtiff/tif_dirread.c b/libtiff/tif_dirread.c +index 2c49dc6..c52d41f 100644 +--- a/libtiff/tif_dirread.c ++++ b/libtiff/tif_dirread.c +@@ -1308,6 +1308,21 @@ TIFFReadDirEntryArrayWithLimit(TIFF *tif, TIFFDirEntry *direntry, + datasize = (*count) * typesize; + assert((tmsize_t)datasize > 0); + ++ /* Before allocating a huge amount of memory for corrupted files, check if ++ * size of requested memory is not greater than file size. ++ */ ++ uint64_t filesize = TIFFGetFileSize(tif); ++ if (datasize > filesize) ++ { ++ TIFFWarningExtR(tif, "ReadDirEntryArray", ++ "Requested memory size for tag %d (0x%x) %" PRIu32 ++ " is greather than filesize %" PRIu64 ++ ". Memory not allocated, tag not read", ++ direntry->tdir_tag, direntry->tdir_tag, datasize, ++ filesize); ++ return (TIFFReadDirEntryErrAlloc); ++ } ++ + if (isMapped(tif) && datasize > (uint64_t)tif->tif_size) + return TIFFReadDirEntryErrIo; + +@@ -5266,6 +5281,20 @@ static int EstimateStripByteCounts(TIFF *tif, TIFFDirEntry *dir, + if (!_TIFFFillStrilesInternal(tif, 0)) + return -1; + ++ /* Before allocating a huge amount of memory for corrupted files, check if ++ * size of requested memory is not greater than file size. */ ++ uint64_t filesize = TIFFGetFileSize(tif); ++ uint64_t allocsize = (uint64_t)td->td_nstrips * sizeof(uint64_t); ++ if (allocsize > filesize) ++ { ++ TIFFWarningExtR(tif, module, ++ "Requested memory size for StripByteCounts of %" PRIu64 ++ " is greather than filesize %" PRIu64 ++ ". Memory not allocated", ++ allocsize, filesize); ++ return -1; ++ } ++ + if (td->td_stripbytecount_p) + _TIFFfreeExt(tif, td->td_stripbytecount_p); + td->td_stripbytecount_p = (uint64_t *)_TIFFCheckMalloc( +@@ -5807,6 +5836,20 @@ static uint16_t TIFFFetchDirectory(TIFF *tif, uint64_t diroff, + dircount16 = (uint16_t)dircount64; + dirsize = 20; + } ++ /* Before allocating a huge amount of memory for corrupted files, check ++ * if size of requested memory is not greater than file size. */ ++ uint64_t filesize = TIFFGetFileSize(tif); ++ uint64_t allocsize = (uint64_t)dircount16 * dirsize; ++ if (allocsize > filesize) ++ { ++ TIFFWarningExtR( ++ tif, module, ++ "Requested memory size for TIFF directory of %" PRIu64 ++ " is greather than filesize %" PRIu64 ++ ". Memory not allocated, TIFF directory not read", ++ allocsize, filesize); ++ return 0; ++ } + origdir = _TIFFCheckMalloc(tif, dircount16, dirsize, + "to read TIFF directory"); + if (origdir == NULL) +@@ -5921,6 +5964,20 @@ static uint16_t TIFFFetchDirectory(TIFF *tif, uint64_t diroff, + "directories not supported"); + return 0; + } ++ /* Before allocating a huge amount of memory for corrupted files, check ++ * if size of requested memory is not greater than file size. */ ++ uint64_t filesize = TIFFGetFileSize(tif); ++ uint64_t allocsize = (uint64_t)dircount16 * dirsize; ++ if (allocsize > filesize) ++ { ++ TIFFWarningExtR( ++ tif, module, ++ "Requested memory size for TIFF directory of %" PRIu64 ++ " is greather than filesize %" PRIu64 ++ ". Memory not allocated, TIFF directory not read", ++ allocsize, filesize); ++ return 0; ++ } + origdir = _TIFFCheckMalloc(tif, dircount16, dirsize, + "to read TIFF directory"); + if (origdir == NULL) +@@ -5968,6 +6025,8 @@ static uint16_t TIFFFetchDirectory(TIFF *tif, uint64_t diroff, + } + } + } ++ /* No check against filesize needed here because "dir" should have same size ++ * than "origdir" checked above. */ + dir = (TIFFDirEntry *)_TIFFCheckMalloc( + tif, dircount16, sizeof(TIFFDirEntry), "to read TIFF directory"); + if (dir == 0) +@@ -7164,6 +7223,20 @@ static int TIFFFetchStripThing(TIFF *tif, TIFFDirEntry *dir, uint32_t nstrips, + return (0); + } + ++ /* Before allocating a huge amount of memory for corrupted files, check ++ * if size of requested memory is not greater than file size. */ ++ uint64_t filesize = TIFFGetFileSize(tif); ++ uint64_t allocsize = (uint64_t)nstrips * sizeof(uint64_t); ++ if (allocsize > filesize) ++ { ++ TIFFWarningExtR(tif, module, ++ "Requested memory size for StripArray of %" PRIu64 ++ " is greather than filesize %" PRIu64 ++ ". Memory not allocated", ++ allocsize, filesize); ++ _TIFFfreeExt(tif, data); ++ return (0); ++ } + resizeddata = (uint64_t *)_TIFFCheckMalloc( + tif, nstrips, sizeof(uint64_t), "for strip array"); + if (resizeddata == 0) +@@ -7263,6 +7336,23 @@ static void allocChoppedUpStripArrays(TIFF *tif, uint32_t nstrips, + } + bytecount = last_offset + last_bytecount - offset; + ++ /* Before allocating a huge amount of memory for corrupted files, check if ++ * size of StripByteCount and StripOffset tags is not greater than ++ * file size. ++ */ ++ uint64_t allocsize = (uint64_t)nstrips * sizeof(uint64_t) * 2; ++ uint64_t filesize = TIFFGetFileSize(tif); ++ if (allocsize > filesize) ++ { ++ TIFFWarningExtR(tif, "allocChoppedUpStripArrays", ++ "Requested memory size for StripByteCount and " ++ "StripOffsets %" PRIu64 ++ " is greather than filesize %" PRIu64 ++ ". Memory not allocated", ++ allocsize, filesize); ++ return; ++ } ++ + newcounts = + (uint64_t *)_TIFFCheckMalloc(tif, nstrips, sizeof(uint64_t), + "for chopped \"StripByteCounts\" array"); +-- +2.43.0 + diff --git a/poky/meta/recipes-multimedia/libtiff/tiff_4.6.0.bb b/poky/meta/recipes-multimedia/libtiff/tiff_4.6.0.bb index 49984f1125..a26e4694f6 100644 --- a/poky/meta/recipes-multimedia/libtiff/tiff_4.6.0.bb +++ b/poky/meta/recipes-multimedia/libtiff/tiff_4.6.0.bb @@ -9,6 +9,13 @@ LIC_FILES_CHKSUM = "file://LICENSE.md;md5=a3e32d664d6db1386b4689c8121531c3" CVE_PRODUCT = "libtiff" SRC_URI = "http://download.osgeo.org/libtiff/tiff-${PV}.tar.gz \ + file://CVE-2023-6277-At-image-reading-compare-data-size-of-some-tags-data.patch \ + file://CVE-2023-6277-At-image-reading-compare-data-size-of-some-tags-data-2.patch \ + file://CVE-2023-6277-Apply-1-suggestion-s-to-1-file-s.patch \ + file://CVE-2023-6228.patch \ + file://CVE-2023-52355-0001.patch \ + file://CVE-2023-52355-0002.patch \ + file://CVE-2023-52356.patch \ " SRC_URI[sha256sum] = "88b3979e6d5c7e32b50d7ec72fb15af724f6ab2cbf7e10880c360a77e4b5d99a" diff --git a/poky/meta/recipes-sato/sato-icon-theme/icon-naming-utils_0.8.90.bb b/poky/meta/recipes-sato/sato-icon-theme/icon-naming-utils_0.8.90.bb index 67cbd03100..5502b66905 100644 --- a/poky/meta/recipes-sato/sato-icon-theme/icon-naming-utils_0.8.90.bb +++ b/poky/meta/recipes-sato/sato-icon-theme/icon-naming-utils_0.8.90.bb @@ -14,7 +14,7 @@ DEPENDS = "libxml-simple-perl-native" LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f" -SRC_URI = "http://tango.freedesktop.org/releases/icon-naming-utils-${PV}.tar.gz" +SRC_URI = "${DEBIAN_MIRROR}/main/i/icon-naming-utils/icon-naming-utils_${PV}.orig.tar.gz" SRC_URI[sha256sum] = "044ab2199ed8c6a55ce36fd4fcd8b8021a5e21f5bab028c0a7cdcf52a5902e1c" inherit autotools allarch perlnative @@ -26,4 +26,4 @@ do_configure:append() { FILES:${PN} += "${datadir}/dtds" -BBCLASSEXTEND = "native"
\ No newline at end of file +BBCLASSEXTEND = "native" diff --git a/poky/meta/recipes-support/aspell/aspell_0.60.8.bb b/poky/meta/recipes-support/aspell/aspell_0.60.8.1.bb index 39b55f4ff2..0ea9b063e0 100644 --- a/poky/meta/recipes-support/aspell/aspell_0.60.8.bb +++ b/poky/meta/recipes-support/aspell/aspell_0.60.8.1.bb @@ -13,11 +13,8 @@ HOMEPAGE = "http://aspell.net/" LICENSE = "LGPL-2.0-only | LGPL-2.1-only" LIC_FILES_CHKSUM = "file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34" -SRC_URI = "${GNU_MIRROR}/aspell/aspell-${PV}.tar.gz \ - file://CVE-2019-25051.patch \ -" -SRC_URI[md5sum] = "012fa9209203ae4e5a61c2a668fd10e3" -SRC_URI[sha256sum] = "f9b77e515334a751b2e60daab5db23499e26c9209f5e7b7443b05235ad0226f2" +SRC_URI = "${GNU_MIRROR}/aspell/aspell-${PV}.tar.gz" +SRC_URI[sha256sum] = "d6da12b34d42d457fa604e435ad484a74b2effcd120ff40acd6bb3fb2887d21b" PACKAGECONFIG ??= "" PACKAGECONFIG[curses] = "--enable-curses,--disable-curses,ncurses" diff --git a/poky/meta/recipes-support/aspell/files/CVE-2019-25051.patch b/poky/meta/recipes-support/aspell/files/CVE-2019-25051.patch deleted file mode 100644 index 8513f6de79..0000000000 --- a/poky/meta/recipes-support/aspell/files/CVE-2019-25051.patch +++ /dev/null @@ -1,101 +0,0 @@ -From 0718b375425aad8e54e1150313b862e4c6fd324a Mon Sep 17 00:00:00 2001 -From: Kevin Atkinson <kevina@gnu.org> -Date: Sat, 21 Dec 2019 20:32:47 +0000 -Subject: [PATCH] objstack: assert that the alloc size will fit within a chunk - to prevent a buffer overflow - -Bug found using OSS-Fuze. - -Upstream-Status: Backport -[https://github.com/gnuaspell/aspell/commit/0718b375425aad8e54e1150313b862e4c6fd324a] -CVE: CVE-2019-25051 -Signed-off-by: Chee Yang Lee <chee.yang.lee@intel.com> ---- - common/objstack.hpp | 18 ++++++++++++++---- - 1 file changed, 14 insertions(+), 4 deletions(-) - -diff --git a/common/objstack.hpp b/common/objstack.hpp -index 3997bf7..bd97ccd 100644 ---- a/common/objstack.hpp -+++ b/common/objstack.hpp -@@ -5,6 +5,7 @@ - #include "parm_string.hpp" - #include <stdlib.h> - #include <assert.h> -+#include <stddef.h> - - namespace acommon { - -@@ -26,6 +27,12 @@ class ObjStack - byte * temp_end; - void setup_chunk(); - void new_chunk(); -+ bool will_overflow(size_t sz) const { -+ return offsetof(Node,data) + sz > chunk_size; -+ } -+ void check_size(size_t sz) { -+ assert(!will_overflow(sz)); -+ } - - ObjStack(const ObjStack &); - void operator=(const ObjStack &); -@@ -56,7 +63,7 @@ class ObjStack - void * alloc_bottom(size_t size) { - byte * tmp = bottom; - bottom += size; -- if (bottom > top) {new_chunk(); tmp = bottom; bottom += size;} -+ if (bottom > top) {check_size(size); new_chunk(); tmp = bottom; bottom += size;} - return tmp; - } - // This alloc_bottom will insure that the object is aligned based on the -@@ -66,7 +73,7 @@ class ObjStack - align_bottom(align); - byte * tmp = bottom; - bottom += size; -- if (bottom > top) {new_chunk(); goto loop;} -+ if (bottom > top) {check_size(size); new_chunk(); goto loop;} - return tmp; - } - char * dup_bottom(ParmString str) { -@@ -79,7 +86,7 @@ class ObjStack - // always be aligned as such. - void * alloc_top(size_t size) { - top -= size; -- if (top < bottom) {new_chunk(); top -= size;} -+ if (top < bottom) {check_size(size); new_chunk(); top -= size;} - return top; - } - // This alloc_top will insure that the object is aligned based on -@@ -88,7 +95,7 @@ class ObjStack - {loop: - top -= size; - align_top(align); -- if (top < bottom) {new_chunk(); goto loop;} -+ if (top < bottom) {check_size(size); new_chunk(); goto loop;} - return top; - } - char * dup_top(ParmString str) { -@@ -117,6 +124,7 @@ class ObjStack - void * alloc_temp(size_t size) { - temp_end = bottom + size; - if (temp_end > top) { -+ check_size(size); - new_chunk(); - temp_end = bottom + size; - } -@@ -131,6 +139,7 @@ class ObjStack - } else { - size_t s = temp_end - bottom; - byte * p = bottom; -+ check_size(size); - new_chunk(); - memcpy(bottom, p, s); - temp_end = bottom + size; -@@ -150,6 +159,7 @@ class ObjStack - } else { - size_t s = temp_end - bottom; - byte * p = bottom; -+ check_size(size); - new_chunk(); - memcpy(bottom, p, s); - temp_end = bottom + size; diff --git a/poky/meta/recipes-support/atk/at-spi2-core_2.50.0.bb b/poky/meta/recipes-support/atk/at-spi2-core_2.50.1.bb index 57958fb7f5..6996ebebcd 100644 --- a/poky/meta/recipes-support/atk/at-spi2-core_2.50.0.bb +++ b/poky/meta/recipes-support/atk/at-spi2-core_2.50.1.bb @@ -11,7 +11,7 @@ MAJ_VER = "${@oe.utils.trim_version("${PV}", 2)}" SRC_URI = "${GNOME_MIRROR}/${BPN}/${MAJ_VER}/${BPN}-${PV}.tar.xz" -SRC_URI[sha256sum] = "e9f5a8c8235c9dd963b2171de9120301129c677dde933955e1df618b949c4adc" +SRC_URI[sha256sum] = "5727b5c0687ac57ba8040e79bd6731b714a36b8fcf32190f236b8fb3698789e7" DEPENDS = " \ dbus \ diff --git a/poky/meta/recipes-support/curl/curl/CVE-2023-46219.patch b/poky/meta/recipes-support/curl/curl/CVE-2023-46219.patch new file mode 100644 index 0000000000..d6c8925218 --- /dev/null +++ b/poky/meta/recipes-support/curl/curl/CVE-2023-46219.patch @@ -0,0 +1,131 @@ +CVE: CVE-2023-46219 +Upstream-Status: Backport [ https://github.com/curl/curl/commit/73b65e94f3531179de45 ] +Signed-off-by: Lee Chee Yang <chee.yang.lee@intel.com> + +From 73b65e94f3531179de45c6f3c836a610e3d0a846 Mon Sep 17 00:00:00 2001 +From: Daniel Stenberg <daniel@haxx.se> +Date: Thu, 23 Nov 2023 08:23:17 +0100 +Subject: [PATCH] fopen: create short(er) temporary file name + +Only using random letters in the name plus a ".tmp" extension. Not by +appending characters to the final file name. + +Reported-by: Maksymilian Arciemowicz + +Closes #12388 +--- + lib/fopen.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++----- + 1 file changed, 60 insertions(+), 5 deletions(-) + +diff --git a/lib/fopen.c b/lib/fopen.c +index 75b8a7aa534085..a73ac068ea3016 100644 +--- a/lib/fopen.c ++++ b/lib/fopen.c +@@ -39,6 +39,51 @@ + #include "curl_memory.h" + #include "memdebug.h" + ++/* ++ The dirslash() function breaks a null-terminated pathname string into ++ directory and filename components then returns the directory component up ++ to, *AND INCLUDING*, a final '/'. If there is no directory in the path, ++ this instead returns a "" string. ++ ++ This function returns a pointer to malloc'ed memory. ++ ++ The input path to this function is expected to have a file name part. ++*/ ++ ++#ifdef _WIN32 ++#define PATHSEP "\\" ++#define IS_SEP(x) (((x) == '/') || ((x) == '\\')) ++#elif defined(MSDOS) || defined(__EMX__) || defined(OS2) ++#define PATHSEP "\\" ++#define IS_SEP(x) ((x) == '\\') ++#else ++#define PATHSEP "/" ++#define IS_SEP(x) ((x) == '/') ++#endif ++ ++static char *dirslash(const char *path) ++{ ++ size_t n; ++ struct dynbuf out; ++ DEBUGASSERT(path); ++ Curl_dyn_init(&out, CURL_MAX_INPUT_LENGTH); ++ n = strlen(path); ++ if(n) { ++ /* find the rightmost path separator, if any */ ++ while(n && !IS_SEP(path[n-1])) ++ --n; ++ /* skip over all the path separators, if any */ ++ while(n && IS_SEP(path[n-1])) ++ --n; ++ } ++ if(Curl_dyn_addn(&out, path, n)) ++ return NULL; ++ /* if there was a directory, append a single trailing slash */ ++ if(n && Curl_dyn_addn(&out, PATHSEP, 1)) ++ return NULL; ++ return Curl_dyn_ptr(&out); ++} ++ + /* + * Curl_fopen() opens a file for writing with a temp name, to be renamed + * to the final name when completed. If there is an existing file using this +@@ -50,25 +95,34 @@ CURLcode Curl_fopen(struct Curl_easy *data, const char *filename, + FILE **fh, char **tempname) + { + CURLcode result = CURLE_WRITE_ERROR; +- unsigned char randsuffix[9]; ++ unsigned char randbuf[41]; + char *tempstore = NULL; + struct_stat sb; + int fd = -1; ++ char *dir; + *tempname = NULL; + ++ dir = dirslash(filename); ++ if(!dir) ++ goto fail; ++ + *fh = fopen(filename, FOPEN_WRITETEXT); + if(!*fh) + goto fail; +- if(fstat(fileno(*fh), &sb) == -1 || !S_ISREG(sb.st_mode)) ++ if(fstat(fileno(*fh), &sb) == -1 || !S_ISREG(sb.st_mode)) { ++ free(dir); + return CURLE_OK; ++ } + fclose(*fh); + *fh = NULL; + +- result = Curl_rand_alnum(data, randsuffix, sizeof(randsuffix)); ++ result = Curl_rand_alnum(data, randbuf, sizeof(randbuf)); + if(result) + goto fail; + +- tempstore = aprintf("%s.%s.tmp", filename, randsuffix); ++ /* The temp file name should not end up too long for the target file ++ system */ ++ tempstore = aprintf("%s%s.tmp", dir, randbuf); + if(!tempstore) { + result = CURLE_OUT_OF_MEMORY; + goto fail; +@@ -95,6 +149,7 @@ CURLcode Curl_fopen(struct Curl_easy *data, const char *filename, + if(!*fh) + goto fail; + ++ free(dir); + *tempname = tempstore; + return CURLE_OK; + +@@ -105,7 +160,7 @@ CURLcode Curl_fopen(struct Curl_easy *data, const char *filename, + } + + free(tempstore); +- ++ free(dir); + return result; + } + diff --git a/poky/meta/recipes-support/curl/curl/disable-tests b/poky/meta/recipes-support/curl/curl/disable-tests index fdac795662..89255d6034 100644 --- a/poky/meta/recipes-support/curl/curl/disable-tests +++ b/poky/meta/recipes-support/curl/curl/disable-tests @@ -1,9 +1,17 @@ +# Intermittently fails e.g. https://autobuilder.yocto.io/pub/non-release/20231220-28/testresults/qemux86-64-ptest/curl.log +# https://autobuilder.yocto.io/pub/non-release/20231220-27/testresults/qemux86-64-ptest/curl.log +337 # These CRL test (alt-avc) are failing 356 412 413 # These CRL tests are scanning docs 971 +# Intermittently hangs e.g http://autobuilder.yocto.io/pub/non-release/20231228-18/testresults/qemux86-64-ptest/curl.log +1091 +# Intermittently hangs e.g https://autobuilder.yocto.io/pub/non-release/20231220-27/testresults/qemux86-64-ptest/curl.log +1096 +# These CRL tests are scanning docs 1119 1132 1135 diff --git a/poky/meta/recipes-support/curl/curl/no-test-timeout.patch b/poky/meta/recipes-support/curl/curl/no-test-timeout.patch new file mode 100644 index 0000000000..b4cfe716db --- /dev/null +++ b/poky/meta/recipes-support/curl/curl/no-test-timeout.patch @@ -0,0 +1,18 @@ +Set the max-time timeout to 600 so the timeout is 10 minutes instead of 13 seconds. + +Upstream-Status: Inappropriate +Signed-off-by: Ross Burton <ross.burton@arm.com> + +diff --git a/tests/servers.pm b/tests/servers.pm +index d4472d509..aeab62c47 100644 +--- a/tests/servers.pm ++++ b/tests/servers.pm +@@ -120,7 +120,7 @@ my $sshdverstr; # for socks server, ssh daemon version string + my $sshderror; # for socks server, ssh daemon version error + my %doesntrun; # servers that don't work, identified by pidfile + my %PORT = (nolisten => 47); # port we use for a local non-listening service +-my $server_response_maxtime=13; ++my $server_response_maxtime=600; + my $httptlssrv = find_httptlssrv(); + my %run; # running server + my %runcert; # cert file currently in use by an ssl running server diff --git a/poky/meta/recipes-support/curl/curl/run-ptest b/poky/meta/recipes-support/curl/curl/run-ptest index 8f9c20f34d..acd2892f80 100644 --- a/poky/meta/recipes-support/curl/curl/run-ptest +++ b/poky/meta/recipes-support/curl/curl/run-ptest @@ -1,6 +1,11 @@ #!/bin/sh + cd tests -{ ./runtests.pl -a -n -s -j4 !flaky || echo "FAIL: curl" ; } | sed \ - -e 's|\([^ ]* *\) \([^ ]* *\)...OK|PASS: \1 \2|' \ - -e 's|\([^ ]* *\) \([^ ]* *\)...FAILED|FAIL: \1 \2|' \ - -e 's/Warning: test[0-9]\+ not present in tests\/data\/Makefile.inc//' + +# Run all tests, don't stop on first failure +# Don't use valgrind if it is found +# Use automake-style output +# Run four tests in parallel +# Print log output on failure +# Don't run the flaky or timing dependent tests +./runtests.pl -a -n -am -j4 -p '!flaky !timing-dependent' diff --git a/poky/meta/recipes-support/curl/curl_8.4.0.bb b/poky/meta/recipes-support/curl/curl_8.4.0.bb index 8f1ba52692..0b89542fde 100644 --- a/poky/meta/recipes-support/curl/curl_8.4.0.bb +++ b/poky/meta/recipes-support/curl/curl_8.4.0.bb @@ -14,6 +14,8 @@ SRC_URI = " \ file://run-ptest \ file://disable-tests \ file://CVE-2023-46218.patch \ + file://CVE-2023-46219.patch \ + file://no-test-timeout.patch \ " SRC_URI[sha256sum] = "16c62a9c4af0f703d28bda6d7bbf37ba47055ad3414d70dec63e2e6336f2a82d" @@ -126,6 +128,7 @@ RDEPENDS:${PN}-ptest += " \ perl-module-storable \ perl-module-time-hires \ " +RDEPENDS:${PN}-ptest:append:libc-glibc = " locale-base-en-us" PACKAGES =+ "lib${BPN}" diff --git a/poky/meta/recipes-support/gnutls/gnutls_3.8.1.bb b/poky/meta/recipes-support/gnutls/gnutls_3.8.3.bb index 455031dd47..27d6753be0 100644 --- a/poky/meta/recipes-support/gnutls/gnutls_3.8.1.bb +++ b/poky/meta/recipes-support/gnutls/gnutls_3.8.3.bb @@ -25,7 +25,7 @@ SRC_URI = "https://www.gnupg.org/ftp/gcrypt/gnutls/v${SHRT_VER}/gnutls-${PV}.tar file://Add-ptest-support.patch \ " -SRC_URI[sha256sum] = "ba8b9e15ae20aba88f44661978f5b5863494316fe7e722ede9d069fe6294829c" +SRC_URI[sha256sum] = "f74fc5954b27d4ec6dfbb11dea987888b5b124289a3703afcada0ee520f4173e" inherit autotools texinfo pkgconfig gettext lib_package gtk-doc ptest diff --git a/poky/meta/recipes-support/libatomic-ops/libatomic-ops_7.8.0.bb b/poky/meta/recipes-support/libatomic-ops/libatomic-ops_7.8.2.bb index d4b77f6244..824400e743 100644 --- a/poky/meta/recipes-support/libatomic-ops/libatomic-ops_7.8.0.bb +++ b/poky/meta/recipes-support/libatomic-ops/libatomic-ops_7.8.2.bb @@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ SRC_URI = "${GITHUB_BASE_URI}/download/v${PV}/libatomic_ops-${PV}.tar.gz" GITHUB_BASE_URI = "https://github.com/ivmai/libatomic_ops/releases" -SRC_URI[sha256sum] = "15676e7674e11bda5a7e50a73f4d9e7d60452271b8acf6fd39a71fefdf89fa31" +SRC_URI[sha256sum] = "d305207fe207f2b3fb5cb4c019da12b44ce3fcbc593dfd5080d867b1a2419b51" S = "${WORKDIR}/libatomic_ops-${PV}" diff --git a/poky/meta/recipes-support/libssh2/libssh2/CVE-2023-48795.patch b/poky/meta/recipes-support/libssh2/libssh2/CVE-2023-48795.patch new file mode 100644 index 0000000000..ab0f419ac5 --- /dev/null +++ b/poky/meta/recipes-support/libssh2/libssh2/CVE-2023-48795.patch @@ -0,0 +1,466 @@ +From d4634630432594b139b3af6b9f254b890c0f275d Mon Sep 17 00:00:00 2001 +From: Michael Buckley <michael@buckleyisms.com> +Date: Thu, 30 Nov 2023 15:08:02 -0800 +Subject: [PATCH] src: add 'strict KEX' to fix CVE-2023-48795 "Terrapin Attack" + +Refs: +https://terrapin-attack.com/ +https://seclists.org/oss-sec/2023/q4/292 +https://osv.dev/list?ecosystem=&q=CVE-2023-48795 +https://github.com/advisories/GHSA-45x7-px36-x8w8 +https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-48795 + +Fixes #1290 +Closes #1291 + +CVE: CVE-2023-48795 +Upstream-Status: Backport +Signed-off-by: Ross Burton <ross.burton@arm.com> +--- + src/kex.c | 63 +++++++++++++++++++++++------------ + src/libssh2_priv.h | 18 +++++++--- + src/packet.c | 83 +++++++++++++++++++++++++++++++++++++++++++--- + src/packet.h | 2 +- + src/session.c | 3 ++ + src/transport.c | 12 ++++++- + 6 files changed, 149 insertions(+), 32 deletions(-) + +diff --git a/src/kex.c b/src/kex.c +index d4034a0a..b4b748ca 100644 +--- a/src/kex.c ++++ b/src/kex.c +@@ -3037,6 +3037,13 @@ kex_method_extension_negotiation = { + 0, + }; + ++static const LIBSSH2_KEX_METHOD ++kex_method_strict_client_extension = { ++ "kex-strict-c-v00@openssh.com", ++ NULL, ++ 0, ++}; ++ + static const LIBSSH2_KEX_METHOD *libssh2_kex_methods[] = { + #if LIBSSH2_ED25519 + &kex_method_ssh_curve25519_sha256, +@@ -3055,6 +3062,7 @@ static const LIBSSH2_KEX_METHOD *libssh2_kex_methods[] = { + &kex_method_diffie_helman_group1_sha1, + &kex_method_diffie_helman_group_exchange_sha1, + &kex_method_extension_negotiation, ++ &kex_method_strict_client_extension, + NULL + }; + +@@ -3307,13 +3315,13 @@ static int kexinit(LIBSSH2_SESSION * session) + return 0; + } + +-/* kex_agree_instr ++/* _libssh2_kex_agree_instr + * Kex specific variant of strstr() + * Needle must be preceded by BOL or ',', and followed by ',' or EOL + */ +-static unsigned char * +-kex_agree_instr(unsigned char *haystack, size_t haystack_len, +- const unsigned char *needle, size_t needle_len) ++unsigned char * ++_libssh2_kex_agree_instr(unsigned char *haystack, size_t haystack_len, ++ const unsigned char *needle, size_t needle_len) + { + unsigned char *s; + unsigned char *end_haystack; +@@ -3398,7 +3406,7 @@ static int kex_agree_hostkey(LIBSSH2_SESSION * session, + while(s && *s) { + unsigned char *p = (unsigned char *) strchr((char *) s, ','); + size_t method_len = (p ? (size_t)(p - s) : strlen((char *) s)); +- if(kex_agree_instr(hostkey, hostkey_len, s, method_len)) { ++ if(_libssh2_kex_agree_instr(hostkey, hostkey_len, s, method_len)) { + const LIBSSH2_HOSTKEY_METHOD *method = + (const LIBSSH2_HOSTKEY_METHOD *) + kex_get_method_by_name((char *) s, method_len, +@@ -3432,9 +3440,9 @@ static int kex_agree_hostkey(LIBSSH2_SESSION * session, + } + + while(hostkeyp && (*hostkeyp) && (*hostkeyp)->name) { +- s = kex_agree_instr(hostkey, hostkey_len, +- (unsigned char *) (*hostkeyp)->name, +- strlen((*hostkeyp)->name)); ++ s = _libssh2_kex_agree_instr(hostkey, hostkey_len, ++ (unsigned char *) (*hostkeyp)->name, ++ strlen((*hostkeyp)->name)); + if(s) { + /* So far so good, but does it suit our purposes? (Encrypting vs + Signing) */ +@@ -3468,6 +3476,12 @@ static int kex_agree_kex_hostkey(LIBSSH2_SESSION * session, unsigned char *kex, + { + const LIBSSH2_KEX_METHOD **kexp = libssh2_kex_methods; + unsigned char *s; ++ const unsigned char *strict = ++ (unsigned char *)"kex-strict-s-v00@openssh.com"; ++ ++ if(_libssh2_kex_agree_instr(kex, kex_len, strict, 28)) { ++ session->kex_strict = 1; ++ } + + if(session->kex_prefs) { + s = (unsigned char *) session->kex_prefs; +@@ -3475,7 +3489,7 @@ static int kex_agree_kex_hostkey(LIBSSH2_SESSION * session, unsigned char *kex, + while(s && *s) { + unsigned char *q, *p = (unsigned char *) strchr((char *) s, ','); + size_t method_len = (p ? (size_t)(p - s) : strlen((char *) s)); +- q = kex_agree_instr(kex, kex_len, s, method_len); ++ q = _libssh2_kex_agree_instr(kex, kex_len, s, method_len); + if(q) { + const LIBSSH2_KEX_METHOD *method = (const LIBSSH2_KEX_METHOD *) + kex_get_method_by_name((char *) s, method_len, +@@ -3509,9 +3523,9 @@ static int kex_agree_kex_hostkey(LIBSSH2_SESSION * session, unsigned char *kex, + } + + while(*kexp && (*kexp)->name) { +- s = kex_agree_instr(kex, kex_len, +- (unsigned char *) (*kexp)->name, +- strlen((*kexp)->name)); ++ s = _libssh2_kex_agree_instr(kex, kex_len, ++ (unsigned char *) (*kexp)->name, ++ strlen((*kexp)->name)); + if(s) { + /* We've agreed on a key exchange method, + * Can we agree on a hostkey that works with this kex? +@@ -3555,7 +3569,7 @@ static int kex_agree_crypt(LIBSSH2_SESSION * session, + unsigned char *p = (unsigned char *) strchr((char *) s, ','); + size_t method_len = (p ? (size_t)(p - s) : strlen((char *) s)); + +- if(kex_agree_instr(crypt, crypt_len, s, method_len)) { ++ if(_libssh2_kex_agree_instr(crypt, crypt_len, s, method_len)) { + const LIBSSH2_CRYPT_METHOD *method = + (const LIBSSH2_CRYPT_METHOD *) + kex_get_method_by_name((char *) s, method_len, +@@ -3577,9 +3591,9 @@ static int kex_agree_crypt(LIBSSH2_SESSION * session, + } + + while(*cryptp && (*cryptp)->name) { +- s = kex_agree_instr(crypt, crypt_len, +- (unsigned char *) (*cryptp)->name, +- strlen((*cryptp)->name)); ++ s = _libssh2_kex_agree_instr(crypt, crypt_len, ++ (unsigned char *) (*cryptp)->name, ++ strlen((*cryptp)->name)); + if(s) { + endpoint->crypt = *cryptp; + return 0; +@@ -3619,7 +3633,7 @@ static int kex_agree_mac(LIBSSH2_SESSION * session, + unsigned char *p = (unsigned char *) strchr((char *) s, ','); + size_t method_len = (p ? (size_t)(p - s) : strlen((char *) s)); + +- if(kex_agree_instr(mac, mac_len, s, method_len)) { ++ if(_libssh2_kex_agree_instr(mac, mac_len, s, method_len)) { + const LIBSSH2_MAC_METHOD *method = (const LIBSSH2_MAC_METHOD *) + kex_get_method_by_name((char *) s, method_len, + (const LIBSSH2_COMMON_METHOD **) +@@ -3640,8 +3654,9 @@ static int kex_agree_mac(LIBSSH2_SESSION * session, + } + + while(*macp && (*macp)->name) { +- s = kex_agree_instr(mac, mac_len, (unsigned char *) (*macp)->name, +- strlen((*macp)->name)); ++ s = _libssh2_kex_agree_instr(mac, mac_len, ++ (unsigned char *) (*macp)->name, ++ strlen((*macp)->name)); + if(s) { + endpoint->mac = *macp; + return 0; +@@ -3672,7 +3687,7 @@ static int kex_agree_comp(LIBSSH2_SESSION *session, + unsigned char *p = (unsigned char *) strchr((char *) s, ','); + size_t method_len = (p ? (size_t)(p - s) : strlen((char *) s)); + +- if(kex_agree_instr(comp, comp_len, s, method_len)) { ++ if(_libssh2_kex_agree_instr(comp, comp_len, s, method_len)) { + const LIBSSH2_COMP_METHOD *method = + (const LIBSSH2_COMP_METHOD *) + kex_get_method_by_name((char *) s, method_len, +@@ -3694,8 +3709,9 @@ static int kex_agree_comp(LIBSSH2_SESSION *session, + } + + while(*compp && (*compp)->name) { +- s = kex_agree_instr(comp, comp_len, (unsigned char *) (*compp)->name, +- strlen((*compp)->name)); ++ s = _libssh2_kex_agree_instr(comp, comp_len, ++ (unsigned char *) (*compp)->name, ++ strlen((*compp)->name)); + if(s) { + endpoint->comp = *compp; + return 0; +@@ -3876,6 +3892,7 @@ _libssh2_kex_exchange(LIBSSH2_SESSION * session, int reexchange, + session->local.kexinit = key_state->oldlocal; + session->local.kexinit_len = key_state->oldlocal_len; + key_state->state = libssh2_NB_state_idle; ++ session->state &= ~LIBSSH2_STATE_INITIAL_KEX; + session->state &= ~LIBSSH2_STATE_KEX_ACTIVE; + session->state &= ~LIBSSH2_STATE_EXCHANGING_KEYS; + return -1; +@@ -3901,6 +3918,7 @@ _libssh2_kex_exchange(LIBSSH2_SESSION * session, int reexchange, + session->local.kexinit = key_state->oldlocal; + session->local.kexinit_len = key_state->oldlocal_len; + key_state->state = libssh2_NB_state_idle; ++ session->state &= ~LIBSSH2_STATE_INITIAL_KEX; + session->state &= ~LIBSSH2_STATE_KEX_ACTIVE; + session->state &= ~LIBSSH2_STATE_EXCHANGING_KEYS; + return -1; +@@ -3949,6 +3967,7 @@ _libssh2_kex_exchange(LIBSSH2_SESSION * session, int reexchange, + session->remote.kexinit = NULL; + } + ++ session->state &= ~LIBSSH2_STATE_INITIAL_KEX; + session->state &= ~LIBSSH2_STATE_KEX_ACTIVE; + session->state &= ~LIBSSH2_STATE_EXCHANGING_KEYS; + +diff --git a/src/libssh2_priv.h b/src/libssh2_priv.h +index 82c3afe2..ee1d8b5c 100644 +--- a/src/libssh2_priv.h ++++ b/src/libssh2_priv.h +@@ -699,6 +699,9 @@ struct _LIBSSH2_SESSION + /* key signing algorithm preferences -- NULL yields server order */ + char *sign_algo_prefs; + ++ /* Whether to use the OpenSSH Strict KEX extension */ ++ int kex_strict; ++ + /* (remote as source of data -- packet_read ) */ + libssh2_endpoint_data remote; + +@@ -870,6 +873,7 @@ struct _LIBSSH2_SESSION + int fullpacket_macstate; + size_t fullpacket_payload_len; + int fullpacket_packet_type; ++ uint32_t fullpacket_required_type; + + /* State variables used in libssh2_sftp_init() */ + libssh2_nonblocking_states sftpInit_state; +@@ -910,10 +914,11 @@ struct _LIBSSH2_SESSION + }; + + /* session.state bits */ +-#define LIBSSH2_STATE_EXCHANGING_KEYS 0x00000001 +-#define LIBSSH2_STATE_NEWKEYS 0x00000002 +-#define LIBSSH2_STATE_AUTHENTICATED 0x00000004 +-#define LIBSSH2_STATE_KEX_ACTIVE 0x00000008 ++#define LIBSSH2_STATE_INITIAL_KEX 0x00000001 ++#define LIBSSH2_STATE_EXCHANGING_KEYS 0x00000002 ++#define LIBSSH2_STATE_NEWKEYS 0x00000004 ++#define LIBSSH2_STATE_AUTHENTICATED 0x00000008 ++#define LIBSSH2_STATE_KEX_ACTIVE 0x00000010 + + /* session.flag helpers */ + #ifdef MSG_NOSIGNAL +@@ -1144,6 +1149,11 @@ ssize_t _libssh2_send(libssh2_socket_t socket, const void *buffer, + int _libssh2_kex_exchange(LIBSSH2_SESSION * session, int reexchange, + key_exchange_state_t * state); + ++unsigned char *_libssh2_kex_agree_instr(unsigned char *haystack, ++ size_t haystack_len, ++ const unsigned char *needle, ++ size_t needle_len); ++ + /* Let crypt.c/hostkey.c expose their method structs */ + const LIBSSH2_CRYPT_METHOD **libssh2_crypt_methods(void); + const LIBSSH2_HOSTKEY_METHOD **libssh2_hostkey_methods(void); +diff --git a/src/packet.c b/src/packet.c +index b5b41981..35d4d39e 100644 +--- a/src/packet.c ++++ b/src/packet.c +@@ -605,14 +605,13 @@ authagent_exit: + * layer when it has received a packet. + * + * The input pointer 'data' is pointing to allocated data that this function +- * is asked to deal with so on failure OR success, it must be freed fine. +- * The only exception is when the return code is LIBSSH2_ERROR_EAGAIN. ++ * will be freed unless return the code is LIBSSH2_ERROR_EAGAIN. + * + * This function will always be called with 'datalen' greater than zero. + */ + int + _libssh2_packet_add(LIBSSH2_SESSION * session, unsigned char *data, +- size_t datalen, int macstate) ++ size_t datalen, int macstate, uint32_t seq) + { + int rc = 0; + unsigned char *message = NULL; +@@ -657,6 +656,70 @@ _libssh2_packet_add(LIBSSH2_SESSION * session, unsigned char *data, + break; + } + ++ if(session->state & LIBSSH2_STATE_INITIAL_KEX) { ++ if(msg == SSH_MSG_KEXINIT) { ++ if(!session->kex_strict) { ++ if(datalen < 17) { ++ LIBSSH2_FREE(session, data); ++ session->packAdd_state = libssh2_NB_state_idle; ++ return _libssh2_error(session, ++ LIBSSH2_ERROR_BUFFER_TOO_SMALL, ++ "Data too short extracting kex"); ++ } ++ else { ++ const unsigned char *strict = ++ (unsigned char *)"kex-strict-s-v00@openssh.com"; ++ struct string_buf buf; ++ unsigned char *algs = NULL; ++ size_t algs_len = 0; ++ ++ buf.data = (unsigned char *)data; ++ buf.dataptr = buf.data; ++ buf.len = datalen; ++ buf.dataptr += 17; /* advance past type and cookie */ ++ ++ if(_libssh2_get_string(&buf, &algs, &algs_len)) { ++ LIBSSH2_FREE(session, data); ++ session->packAdd_state = libssh2_NB_state_idle; ++ return _libssh2_error(session, ++ LIBSSH2_ERROR_BUFFER_TOO_SMALL, ++ "Algs too short"); ++ } ++ ++ if(algs_len == 0 || ++ _libssh2_kex_agree_instr(algs, algs_len, strict, 28)) { ++ session->kex_strict = 1; ++ } ++ } ++ } ++ ++ if(session->kex_strict && seq) { ++ LIBSSH2_FREE(session, data); ++ session->socket_state = LIBSSH2_SOCKET_DISCONNECTED; ++ session->packAdd_state = libssh2_NB_state_idle; ++ libssh2_session_disconnect(session, "strict KEX violation: " ++ "KEXINIT was not the first packet"); ++ ++ return _libssh2_error(session, LIBSSH2_ERROR_SOCKET_DISCONNECT, ++ "strict KEX violation: " ++ "KEXINIT was not the first packet"); ++ } ++ } ++ ++ if(session->kex_strict && session->fullpacket_required_type && ++ session->fullpacket_required_type != msg) { ++ LIBSSH2_FREE(session, data); ++ session->socket_state = LIBSSH2_SOCKET_DISCONNECTED; ++ session->packAdd_state = libssh2_NB_state_idle; ++ libssh2_session_disconnect(session, "strict KEX violation: " ++ "unexpected packet type"); ++ ++ return _libssh2_error(session, LIBSSH2_ERROR_SOCKET_DISCONNECT, ++ "strict KEX violation: " ++ "unexpected packet type"); ++ } ++ } ++ + if(session->packAdd_state == libssh2_NB_state_allocated) { + /* A couple exceptions to the packet adding rule: */ + switch(msg) { +@@ -1341,6 +1404,15 @@ _libssh2_packet_ask(LIBSSH2_SESSION * session, unsigned char packet_type, + + return 0; + } ++ else if(session->kex_strict && ++ (session->state & LIBSSH2_STATE_INITIAL_KEX)) { ++ libssh2_session_disconnect(session, "strict KEX violation: " ++ "unexpected packet type"); ++ ++ return _libssh2_error(session, LIBSSH2_ERROR_SOCKET_DISCONNECT, ++ "strict KEX violation: " ++ "unexpected packet type"); ++ } + packet = _libssh2_list_next(&packet->node); + } + return -1; +@@ -1402,7 +1474,10 @@ _libssh2_packet_require(LIBSSH2_SESSION * session, unsigned char packet_type, + } + + while(session->socket_state == LIBSSH2_SOCKET_CONNECTED) { +- int ret = _libssh2_transport_read(session); ++ int ret; ++ session->fullpacket_required_type = packet_type; ++ ret = _libssh2_transport_read(session); ++ session->fullpacket_required_type = 0; + if(ret == LIBSSH2_ERROR_EAGAIN) + return ret; + else if(ret < 0) { +diff --git a/src/packet.h b/src/packet.h +index 79018bcf..6ea100a5 100644 +--- a/src/packet.h ++++ b/src/packet.h +@@ -71,6 +71,6 @@ int _libssh2_packet_burn(LIBSSH2_SESSION * session, + int _libssh2_packet_write(LIBSSH2_SESSION * session, unsigned char *data, + unsigned long data_len); + int _libssh2_packet_add(LIBSSH2_SESSION * session, unsigned char *data, +- size_t datalen, int macstate); ++ size_t datalen, int macstate, uint32_t seq); + + #endif /* __LIBSSH2_PACKET_H */ +diff --git a/src/session.c b/src/session.c +index a4d602ba..f4bafb57 100644 +--- a/src/session.c ++++ b/src/session.c +@@ -464,6 +464,8 @@ libssh2_session_init_ex(LIBSSH2_ALLOC_FUNC((*my_alloc)), + session->abstract = abstract; + session->api_timeout = 0; /* timeout-free API by default */ + session->api_block_mode = 1; /* blocking API by default */ ++ session->state = LIBSSH2_STATE_INITIAL_KEX; ++ session->fullpacket_required_type = 0; + session->packet_read_timeout = LIBSSH2_DEFAULT_READ_TIMEOUT; + session->flag.quote_paths = 1; /* default behavior is to quote paths + for the scp subsystem */ +@@ -1186,6 +1188,7 @@ libssh2_session_disconnect_ex(LIBSSH2_SESSION *session, int reason, + const char *desc, const char *lang) + { + int rc; ++ session->state &= ~LIBSSH2_STATE_INITIAL_KEX; + session->state &= ~LIBSSH2_STATE_EXCHANGING_KEYS; + BLOCK_ADJUST(rc, session, + session_disconnect(session, reason, desc, lang)); +diff --git a/src/transport.c b/src/transport.c +index 6d902d33..3b30ff84 100644 +--- a/src/transport.c ++++ b/src/transport.c +@@ -187,6 +187,7 @@ fullpacket(LIBSSH2_SESSION * session, int encrypted /* 1 or 0 */ ) + struct transportpacket *p = &session->packet; + int rc; + int compressed; ++ uint32_t seq = session->remote.seqno; + + if(session->fullpacket_state == libssh2_NB_state_idle) { + session->fullpacket_macstate = LIBSSH2_MAC_CONFIRMED; +@@ -318,7 +319,7 @@ fullpacket(LIBSSH2_SESSION * session, int encrypted /* 1 or 0 */ ) + if(session->fullpacket_state == libssh2_NB_state_created) { + rc = _libssh2_packet_add(session, p->payload, + session->fullpacket_payload_len, +- session->fullpacket_macstate); ++ session->fullpacket_macstate, seq); + if(rc == LIBSSH2_ERROR_EAGAIN) + return rc; + if(rc) { +@@ -329,6 +330,11 @@ fullpacket(LIBSSH2_SESSION * session, int encrypted /* 1 or 0 */ ) + + session->fullpacket_state = libssh2_NB_state_idle; + ++ if(session->kex_strict && ++ session->fullpacket_packet_type == SSH_MSG_NEWKEYS) { ++ session->remote.seqno = 0; ++ } ++ + return session->fullpacket_packet_type; + } + +@@ -1091,6 +1097,10 @@ int _libssh2_transport_send(LIBSSH2_SESSION *session, + + session->local.seqno++; + ++ if(session->kex_strict && data[0] == SSH_MSG_NEWKEYS) { ++ session->local.seqno = 0; ++ } ++ + ret = LIBSSH2_SEND(session, p->outbuf, total_length, + LIBSSH2_SOCKET_SEND_FLAGS(session)); + if(ret < 0) +-- +2.34.1 + diff --git a/poky/meta/recipes-support/libssh2/libssh2_1.11.0.bb b/poky/meta/recipes-support/libssh2/libssh2_1.11.0.bb index edc25db1b1..5100e6f7f9 100644 --- a/poky/meta/recipes-support/libssh2/libssh2_1.11.0.bb +++ b/poky/meta/recipes-support/libssh2/libssh2_1.11.0.bb @@ -9,6 +9,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=24a33237426720395ebb1dd1349ca225" SRC_URI = "http://www.libssh2.org/download/${BP}.tar.gz \ file://run-ptest \ + file://CVE-2023-48795.patch \ " SRC_URI[sha256sum] = "3736161e41e2693324deb38c26cfdc3efe6209d634ba4258db1cecff6a5ad461" diff --git a/poky/meta/recipes-support/sqlite/sqlite3_3.43.1.bb b/poky/meta/recipes-support/sqlite/sqlite3_3.43.1.bb deleted file mode 100644 index 93146358c7..0000000000 --- a/poky/meta/recipes-support/sqlite/sqlite3_3.43.1.bb +++ /dev/null @@ -1,10 +0,0 @@ -require sqlite3.inc - -LICENSE = "PD" -LIC_FILES_CHKSUM = "file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed00c66" - -SRC_URI = "http://www.sqlite.org/2023/sqlite-autoconf-${SQLITE_PV}.tar.gz" -SRC_URI[sha256sum] = "39116c94e76630f22d54cd82c3cea308565f1715f716d1b2527f1c9c969ba4d9" - -CVE_STATUS[CVE-2023-36191] = "disputed: The error is a bug. It has been fixed upstream. But it is not a vulnerability" - diff --git a/poky/meta/recipes-support/sqlite/sqlite3_3.43.2.bb b/poky/meta/recipes-support/sqlite/sqlite3_3.43.2.bb new file mode 100644 index 0000000000..66d6255ac0 --- /dev/null +++ b/poky/meta/recipes-support/sqlite/sqlite3_3.43.2.bb @@ -0,0 +1,7 @@ +require sqlite3.inc + +LICENSE = "PD" +LIC_FILES_CHKSUM = "file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed00c66" + +SRC_URI = "http://www.sqlite.org/2023/sqlite-autoconf-${SQLITE_PV}.tar.gz" +SRC_URI[sha256sum] = "6d422b6f62c4de2ca80d61860e3a3fb693554d2f75bb1aaca743ccc4d6f609f0" diff --git a/poky/meta/recipes-support/vim/vim.inc b/poky/meta/recipes-support/vim/vim.inc index 6b440d8947..906aa53a16 100644 --- a/poky/meta/recipes-support/vim/vim.inc +++ b/poky/meta/recipes-support/vim/vim.inc @@ -19,8 +19,8 @@ SRC_URI = "git://github.com/vim/vim.git;branch=master;protocol=https \ file://no-path-adjust.patch \ " -PV .= ".2130" -SRCREV = "075ad7047457debfeef13442c01e74088b461092" +PV .= ".2190" +SRCREV = "6a950da86d7a6eb09d5ebeab17657986420d07ac" # Do not consider .z in x.y.z, as that is updated with every commit UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>\d+\.\d+)\.0" diff --git a/poky/scripts/lib/devtool/deploy.py b/poky/scripts/lib/devtool/deploy.py index e14a587417..eadf6e1521 100644 --- a/poky/scripts/lib/devtool/deploy.py +++ b/poky/scripts/lib/devtool/deploy.py @@ -140,6 +140,7 @@ def deploy(args, config, basepath, workspace): import math import oe.recipeutils import oe.package + import oe.utils check_workspace_recipe(workspace, args.recipename, checksrc=False) @@ -174,7 +175,7 @@ def deploy(args, config, basepath, workspace): exec_fakeroot(rd, "cp -af %s %s" % (os.path.join(srcdir, '.'), recipe_outdir), shell=True) os.environ['PATH'] = ':'.join([os.environ['PATH'], rd.getVar('PATH') or '']) oe.package.strip_execs(args.recipename, recipe_outdir, rd.getVar('STRIP'), rd.getVar('libdir'), - rd.getVar('base_libdir'), rd) + rd.getVar('base_libdir'), oe.utils.get_bb_number_threads(rd), rd) filelist = [] inodes = set({}) diff --git a/poky/scripts/lib/devtool/standard.py b/poky/scripts/lib/devtool/standard.py index 55fa38ccfb..0126f75022 100644 --- a/poky/scripts/lib/devtool/standard.py +++ b/poky/scripts/lib/devtool/standard.py @@ -971,7 +971,7 @@ def modify(args, config, basepath, workspace): '}\n') if rd.getVarFlag('do_menuconfig','task'): f.write('\ndo_configure:append() {\n' - ' if [ ${@ oe.types.boolean(\'${KCONFIG_CONFIG_ENABLE_MENUCONFIG}\') } = True ]; then\n' + ' if [ ${@oe.types.boolean(d.getVar("KCONFIG_CONFIG_ENABLE_MENUCONFIG"))} = True ]; then\n' ' cp ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.baseline\n' ' ln -sfT ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.new\n' ' fi\n' diff --git a/poky/scripts/runqemu b/poky/scripts/runqemu index 6fca7439a1..63562cf6dc 100755 --- a/poky/scripts/runqemu +++ b/poky/scripts/runqemu @@ -367,7 +367,7 @@ class BaseConfig(object): if p.endswith('.qemuboot.conf'): self.qemuboot = p self.qbconfload = True - elif re.search('\.bin$', p) or re.search('bzImage', p) or \ + elif re.search('\\.bin$', p) or re.search('bzImage', p) or \ re.search('zImage', p) or re.search('vmlinux', p) or \ re.search('fitImage', p) or re.search('uImage', p): self.kernel = p @@ -381,19 +381,19 @@ class BaseConfig(object): fst = t break if not fst: - m = re.search('.*\.(.*)$', self.rootfs) + m = re.search('.*\\.(.*)$', self.rootfs) if m: fst = m.group(1) if fst: self.check_arg_fstype(fst) - qb = re.sub('\.' + fst + "$", '.qemuboot.conf', self.rootfs) + qb = re.sub('\\.' + fst + "$", '.qemuboot.conf', self.rootfs) if os.path.exists(qb): self.qemuboot = qb self.qbconfload = True else: logger.warning("%s doesn't exist, will try to remove '.rootfs' from filename" % qb) # They to remove .rootfs (IMAGE_NAME_SUFFIX) as well - qb = re.sub('\.rootfs.qemuboot.conf$', '.qemuboot.conf', qb) + qb = re.sub('\\.rootfs.qemuboot.conf$', '.qemuboot.conf', qb) if os.path.exists(qb): self.qemuboot = qb self.qbconfload = True |