From patchwork Tue Feb 27 14:01:13 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40143 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7945FC54E5A for ; Tue, 27 Feb 2024 14:01:41 +0000 (UTC) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by mx.groups.io with SMTP id smtpd.web11.12658.1709042497521426694 for ; Tue, 27 Feb 2024 06:01:37 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=do2t0gs/; spf=pass (domain: bootlin.com, ip: 217.70.183.201, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 9F2D01BF208; Tue, 27 Feb 2024 14:01:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042495; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ay+nl+vp26SFGXafpjMb7It4CoDux7SZpgp1/r0bCG8=; b=do2t0gs/p6LA6OdH9tVdmIStJ4nm/dKcTorpdU6zUfS5zgiNh12OscuNp9r1CZniSl5pLa 11GNcqCPC3zb2fcpbiS1XBVPnX4Fl97TWYtSuedsgHdGISjIrzqeKPiLNZAuJQvOr0kP3d l9QGbsB8t+YUwHtp3kSnS5F7Jg1MF5Vauuzth5N/rU0DaOQ8yHhhdOsTjRFT5UYuaSBqqj v0lZn0JNgVIxGZhoAhpBDif1FDqalBXqRNQnI/w4ymfUaFhpK5XsMTpBgkzBpKV++aT/ex oU6KzDWZkkGc1+Y1fdyUtuqUmPTM+zAeUVfieyNQBBn+vwMkfLY2tFg5DyJykQ== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker , =?utf-8?q?Simone_We?= =?utf-8?q?i=C3=9F?= Subject: [kirkstone][PATCH 01/16] dev-manual: Rephrase spdx creation Date: Tue, 27 Feb 2024 15:01:13 +0100 Message-Id: <20240227140128.481522-2-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:41 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4892 From: Michael Opdenacker From: Simone Weiß Make the options more clear by providing them in a list instead of plain prosa. Also add a ref for a presentation wrt spdx 3.0 in the Yocto project. Fixes [YOCTO 7476] Signed-off-by: Simone Weiß Reviewed-by: Michael Opdenacker --- documentation/dev-manual/sbom.rst | 39 +++++++++++++++++++------------ 1 file changed, 24 insertions(+), 15 deletions(-) diff --git a/documentation/dev-manual/sbom.rst b/documentation/dev-manual/sbom.rst index 448c071c55..6949675c25 100644 --- a/documentation/dev-manual/sbom.rst +++ b/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 @@ -67,6 +74,8 @@ See the `tools page `__ 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 `__ -presentation at FOSDEM 2023. +at FOSDEM 2023 and +`SPDX in the Yocto Project `__ +at FOSDEM 2024. From patchwork Tue Feb 27 14:01:14 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40142 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A2F8C54E59 for ; Tue, 27 Feb 2024 14:01:41 +0000 (UTC) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by mx.groups.io with SMTP id smtpd.web10.12827.1709042498346201326 for ; Tue, 27 Feb 2024 06:01:38 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=bJkFcIBo; spf=pass (domain: bootlin.com, ip: 217.70.183.199, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 83BCCFF80C; Tue, 27 Feb 2024 14:01:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042496; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VfN0rrmB0RbOaaOSBBZBk/t1uuPec1pdArgLQGvOvbU=; b=bJkFcIBo++Jdsykh61bppG7H540Rl+je2WcRfhlYg5gSlrNEcvI16bBV6Jcyz3jJ3Ir997 4X52UJliGODIhMW8aYKA5ip6kTVkVSgyMA7OTH+u6Ps7+TbjQ0l0ysCm+ESDorJyDavjNU 2XMJPjVEkDOnfQ87Z0ul+ED8fyOVSe9V93/LCBjqdlXvOa0LhYq1+kTBjSmlJg8CmFXI4C AnVLAAF6CDpj7ETEBVRGThcv4PHpCZ5EvIQfF+W6Hi8WJvwUcGSi0FR8aV/Wgncf78HXCQ C2CbYaJlLKF4LbN/9OF8aPLkJhJJSdAPfhlw6uX2MaQRJzo6s/q0z+3x/DPzTw== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker Subject: [kirkstone][PATCH 02/16] ref-manual: release-process: grammar fix Date: Tue, 27 Feb 2024 15:01:14 +0100 Message-Id: <20240227140128.481522-3-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:41 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4893 From: Michael Opdenacker Signed-off-by: Michael Opdenacker --- documentation/ref-manual/release-process.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/ref-manual/release-process.rst b/documentation/ref-manual/release-process.rst index daa28308ce..2393ac8d81 100644 --- a/documentation/ref-manual/release-process.rst +++ b/documentation/ref-manual/release-process.rst @@ -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. From patchwork Tue Feb 27 14:01:15 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40145 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 872D5C54E5B for ; Tue, 27 Feb 2024 14:01:41 +0000 (UTC) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by mx.groups.io with SMTP id smtpd.web11.12659.1709042498461207114 for ; Tue, 27 Feb 2024 06:01:39 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=LDRNkHrS; spf=pass (domain: bootlin.com, ip: 217.70.183.199, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id DCBADFF815; Tue, 27 Feb 2024 14:01:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042497; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5yyS+HQxV25hOaKExwfo/7iCWeT4yLLGdakRhdI8TKA=; b=LDRNkHrSnSwhArkeICuANrNse1n7enakvX3MkiFo9lZ8XhDPkpL2s2jb1VD54IKrHK5lnK L0krY2EsVe4OZuB6hQY9t0RZVVWh3CX62vm0QGfK3EX4Euxz0gmQ29fb4rsxiqz1QRP4bR p3zvr7HLNwpm9jSBhV2ZwlORCw00ghVdI9isKtq6ANS0+l5k+0zKITE9WMhgXPt5TYT9Iz d4nuF46VhJmOBxNq5L/BakBJDEym0GJOcjdW6jSBECoSX2c/tG3vKvwyEgOuB+naQrwfbc 5aYU0n0JSaVejQpcdmksxqmrOOgGN7QjxfhBcmnG9tuQckwAGg2HpoRpyjt8aw== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker , Daniel Ammann Subject: [kirkstone][PATCH 03/16] manuals: suppress excess use of "following" word Date: Tue, 27 Feb 2024 15:01:15 +0100 Message-Id: <20240227140128.481522-4-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:41 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4894 From: Michael Opdenacker To simplify the style, replace "Following is" and "Following are" by "here is" and "here are", sounding more natural. In some cases, also go further by simplifying "Here are/is xxx" by "xxx are/is" when the "are" or "is" are not two far at the end of the sentence. In some cases too, completely remove the sentence, when it's redundant with the preceding title. Signed-off-by: Michael Opdenacker CC: Daniel Ammann --- Changes in V2: - Further simplication of some "Here are" and "Here is" statements as suggested by Daniel Ammann - Remove some sentences which were just repeating the preceding title. --- documentation/bsp-guide/bsp.rst | 9 ++++---- documentation/dev-manual/building.rst | 2 +- documentation/dev-manual/debugging.rst | 8 +++---- .../dev-manual/development-shell.rst | 2 +- documentation/dev-manual/layers.rst | 8 +++---- documentation/dev-manual/libraries.rst | 4 ++-- documentation/dev-manual/licenses.rst | 2 +- documentation/dev-manual/new-machine.rst | 2 +- documentation/dev-manual/new-recipe.rst | 8 +++---- documentation/dev-manual/packages.rst | 4 ++-- .../dev-manual/prebuilt-libraries.rst | 4 ++-- .../dev-manual/python-development-shell.rst | 2 +- documentation/dev-manual/qemu.rst | 4 ++-- documentation/dev-manual/runtime-testing.rst | 4 ++-- .../dev-manual/speeding-up-build.rst | 4 ++-- documentation/dev-manual/start.rst | 6 ++--- documentation/kernel-dev/common.rst | 4 ++-- .../migration-guides/migration-1.5.rst | 6 ++--- .../migration-guides/migration-2.2.rst | 16 ++++--------- .../migration-guides/migration-2.4.rst | 8 ------- .../migration-guides/migration-2.5.rst | 8 +------ .../migration-guides/migration-4.0.rst | 2 +- documentation/overview-manual/concepts.rst | 23 +++++++++---------- documentation/overview-manual/yp-intro.rst | 2 +- documentation/ref-manual/classes.rst | 8 +++---- .../ref-manual/devtool-reference.rst | 8 +++---- documentation/ref-manual/faq.rst | 4 ++-- documentation/ref-manual/features.rst | 2 +- documentation/ref-manual/images.rst | 2 +- documentation/ref-manual/release-process.rst | 6 ++--- documentation/ref-manual/structure.rst | 2 +- documentation/ref-manual/terms.rst | 6 ++--- documentation/ref-manual/variables.rst | 8 +++---- documentation/sdk-manual/appendix-obtain.rst | 14 +++++------ documentation/sdk-manual/intro.rst | 2 +- .../toaster-manual/setup-and-use.rst | 4 ++-- 36 files changed, 92 insertions(+), 116 deletions(-) diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst index 6cb35ba6cc..1779f9e208 100644 --- a/documentation/bsp-guide/bsp.rst +++ b/documentation/bsp-guide/bsp.rst @@ -853,8 +853,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 @@ -958,7 +957,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 @@ -1020,7 +1019,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 @@ -1443,7 +1442,7 @@ metadata used to build the kernel. In this case, a kernel append file kernel recipe (i.e. ``linux-yocto_5.15.bb``), which is located in :yocto_git:`/poky/tree/meta-yocto-bsp/recipes-kernel/linux`. -Following is the contents of the append file:: +The contents of the append file are:: KBRANCH:genericx86 = "v5.15/standard/base" KBRANCH:genericx86-64 = "v5.15/standard/base" diff --git a/documentation/dev-manual/building.rst b/documentation/dev-manual/building.rst index e964bd1aee..7fcac33b75 100644 --- a/documentation/dev-manual/building.rst +++ b/documentation/dev-manual/building.rst @@ -160,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 diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst index bd1e716b0b..71b5807f5a 100644 --- a/documentation/dev-manual/debugging.rst +++ b/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:: @@ -608,7 +608,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 +636,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 +1221,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/documentation/dev-manual/development-shell.rst b/documentation/dev-manual/development-shell.rst index a18d792150..be26bcffc7 100644 --- a/documentation/dev-manual/development-shell.rst +++ b/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/documentation/dev-manual/layers.rst b/documentation/dev-manual/layers.rst index 2da5d9f93e..9bfbd726d9 100644 --- a/documentation/dev-manual/layers.rst +++ b/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/documentation/dev-manual/libraries.rst b/documentation/dev-manual/libraries.rst index ae4ca27209..521dbb9a7c 100644 --- a/documentation/dev-manual/libraries.rst +++ b/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/documentation/dev-manual/licenses.rst b/documentation/dev-manual/licenses.rst index 419af7c326..197712b68d 100644 --- a/documentation/dev-manual/licenses.rst +++ b/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 \ diff --git a/documentation/dev-manual/new-machine.rst b/documentation/dev-manual/new-machine.rst index b7978f4ba9..d007c1631f 100644 --- a/documentation/dev-manual/new-machine.rst +++ b/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/documentation/dev-manual/new-recipe.rst b/documentation/dev-manual/new-recipe.rst index ed87f9b2d0..be52610621 100644 --- a/documentation/dev-manual/new-recipe.rst +++ b/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:: @@ -1233,7 +1233,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" @@ -1286,7 +1286,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:: @@ -1511,7 +1511,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/documentation/dev-manual/packages.rst b/documentation/dev-manual/packages.rst index 79f21d9f34..0e991e409a 100644 --- a/documentation/dev-manual/packages.rst +++ b/documentation/dev-manual/packages.rst @@ -365,7 +365,7 @@ For more examples that show how to use ``do_split_packages``, see the directory of the ``poky`` :ref:`source repository `. 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 @@ -1123,7 +1123,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/documentation/dev-manual/prebuilt-libraries.rst b/documentation/dev-manual/prebuilt-libraries.rst index b80a844e93..a05f39ca1e 100644 --- a/documentation/dev-manual/prebuilt-libraries.rst +++ b/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/documentation/dev-manual/python-development-shell.rst b/documentation/dev-manual/python-development-shell.rst index 2dc6a3f138..81a5c43472 100644 --- a/documentation/dev-manual/python-development-shell.rst +++ b/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/documentation/dev-manual/qemu.rst b/documentation/dev-manual/qemu.rst index 88a63c1808..f998e47934 100644 --- a/documentation/dev-manual/qemu.rst +++ b/documentation/dev-manual/qemu.rst @@ -318,7 +318,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 @@ -360,7 +360,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/documentation/dev-manual/runtime-testing.rst b/documentation/dev-manual/runtime-testing.rst index 7b9345fb79..bd3f42ac09 100644 --- a/documentation/dev-manual/runtime-testing.rst +++ b/documentation/dev-manual/runtime-testing.rst @@ -199,7 +199,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. @@ -578,7 +578,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/documentation/dev-manual/speeding-up-build.rst b/documentation/dev-manual/speeding-up-build.rst index 31b6f75ab0..6e0d7873ac 100644 --- a/documentation/dev-manual/speeding-up-build.rst +++ b/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/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst index 794da1e672..9dc9b855b3 100644 --- a/documentation/dev-manual/start.rst +++ b/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. 5. *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. 6. *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 diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst index 3e1ef389b8..cbcb30281a 100644 --- a/documentation/kernel-dev/common.rst +++ b/documentation/kernel-dev/common.rst @@ -1376,7 +1376,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 ``do_kernel_configcheck`` task: +Here is sample output from the ``do_kernel_configcheck`` task: .. code-block:: none @@ -1809,7 +1809,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/documentation/migration-guides/migration-1.5.rst b/documentation/migration-guides/migration-1.5.rst index 6affe68b58..81a434d5b7 100644 --- a/documentation/migration-guides/migration-1.5.rst +++ b/documentation/migration-guides/migration-1.5.rst @@ -252,7 +252,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 @@ -275,7 +275,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 @@ -319,7 +319,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/documentation/migration-guides/migration-2.2.rst b/documentation/migration-guides/migration-2.2.rst index 40e3b5cb2b..49cd9b9ae0 100644 --- a/documentation/migration-guides/migration-2.2.rst +++ b/documentation/migration-guides/migration-2.2.rst @@ -70,9 +70,9 @@ 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: +Alternatively, you can reference the conversion commits for BitBake and +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 @@ -181,14 +181,8 @@ 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 -such as ``bsp.conf`` to enable the BSP to be booted by ``runqemu``: - -.. note:: - - "QB" means "QEMU Boot". - -:: +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") QB_OPT_APPEND: Options to append to QEMU (e.g. "-show-cursor") diff --git a/documentation/migration-guides/migration-2.4.rst b/documentation/migration-guides/migration-2.4.rst index 964ed92937..66dfc20d95 100644 --- a/documentation/migration-guides/migration-2.4.rst +++ b/documentation/migration-guides/migration-2.4.rst @@ -89,8 +89,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/documentation/migration-guides/migration-2.5.rst b/documentation/migration-guides/migration-2.5.rst index fdbf2f3da3..03ecb16dc6 100644 --- a/documentation/migration-guides/migration-2.5.rst +++ b/documentation/migration-guides/migration-2.5.rst @@ -85,8 +85,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 @@ -117,8 +115,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: @@ -151,7 +147,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 @@ -185,8 +181,6 @@ change please see :yocto_git:`this commit Miscellaneous Changes --------------------- -The following are additional changes: - - The :ref:`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/documentation/migration-guides/migration-4.0.rst b/documentation/migration-guides/migration-4.0.rst index fc801144b1..9e78fc709f 100644 --- a/documentation/migration-guides/migration-4.0.rst +++ b/documentation/migration-guides/migration-4.0.rst @@ -140,7 +140,7 @@ Python changes classes should be updated to inherit ``setuptools*`` equivalents instead. - The Python package build process is now based on `wheels `__. - Here are the new Python packaging classes that should be used: + The new Python packaging classes that should be used are :ref:`python_flit_core `, :ref:`python_setuptools_build_meta ` and :ref:`python_poetry_core `. diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst index 371c73418a..3e80d6fddd 100644 --- a/documentation/overview-manual/concepts.rst +++ b/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`" @@ -1351,10 +1351,9 @@ can initialize the environment before using the tools. the :doc:`/sdk-manual/index` manual. All the output files for an SDK are written to the ``deploy/sdk`` folder -inside the :term:`Build Directory` as -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: +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. +The variables associated with an extensible SDK are: - :term:`DEPLOY_DIR`: Points to the ``deploy`` directory. @@ -2279,7 +2278,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 @@ -2307,7 +2306,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 @@ -2316,7 +2315,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 @@ -2324,7 +2323,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 @@ -2337,7 +2336,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 @@ -2346,7 +2345,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" @@ -2369,7 +2368,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/documentation/overview-manual/yp-intro.rst b/documentation/overview-manual/yp-intro.rst index f7cd2486af..3dc8ae5519 100644 --- a/documentation/overview-manual/yp-intro.rst +++ b/documentation/overview-manual/yp-intro.rst @@ -742,7 +742,7 @@ workflow: .. image:: figures/YP-flow-diagram.png :align: center -Following is a brief summary of the "workflow": +Here is a brief summary of the "workflow": 1. Developers specify architecture, policies, patches and configuration details. diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst index 216b236e33..05473edcca 100644 --- a/documentation/ref-manual/classes.rst +++ b/documentation/ref-manual/classes.rst @@ -616,7 +616,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" @@ -1141,8 +1141,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 @@ -3148,7 +3148,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/documentation/ref-manual/devtool-reference.rst b/documentation/ref-manual/devtool-reference.rst index ba0385c4c8..4144277e88 100644 --- a/documentation/ref-manual/devtool-reference.rst +++ b/documentation/ref-manual/devtool-reference.rst @@ -379,16 +379,14 @@ 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. Notice the reported reason for not upgrading the ``base-passwd`` recipe. In this example, while a new version is available upstream, you do not want to use it because the dependency on ``cdebconf`` is not easily satisfied. Maintainers can explicit the reason that is shown by adding the :term:`RECIPE_NO_UPDATE_REASON` variable to the corresponding recipe. See :yocto_git:`base-passwd.bb ` -for an example. - -:: +for an example:: $ devtool check-upgrade-status ... @@ -599,7 +597,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 ` to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory:: diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst index b428dc2db6..9fb60899c9 100644 --- a/documentation/ref-manual/faq.rst +++ b/documentation/ref-manual/faq.rst @@ -312,7 +312,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" @@ -328,7 +328,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" diff --git a/documentation/ref-manual/features.rst b/documentation/ref-manual/features.rst index a7078c7f3a..4f0366eeb6 100644 --- a/documentation/ref-manual/features.rst +++ b/documentation/ref-manual/features.rst @@ -198,7 +198,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 root logins and logins from accounts having an empty password string. diff --git a/documentation/ref-manual/images.rst b/documentation/ref-manual/images.rst index da27512855..f875633128 100644 --- a/documentation/ref-manual/images.rst +++ b/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/documentation/ref-manual/release-process.rst b/documentation/ref-manual/release-process.rst index 2393ac8d81..2913a4d4eb 100644 --- a/documentation/ref-manual/release-process.rst +++ b/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 diff --git a/documentation/ref-manual/structure.rst b/documentation/ref-manual/structure.rst index d21134fd7f..021e49e9d7 100644 --- a/documentation/ref-manual/structure.rst +++ b/documentation/ref-manual/structure.rst @@ -530,7 +530,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/documentation/ref-manual/terms.rst b/documentation/ref-manual/terms.rst index 2a5baa4cbf..d602f7ea36 100644 --- a/documentation/ref-manual/terms.rst +++ b/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: @@ -66,8 +66,8 @@ universal, the list includes them just in case: (i.e. :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``). The :term:`TOPDIR` variable points to the Build Directory. - You have a lot of flexibility when creating the Build Directory. - Following are some examples that show how to create the directory. The + You have a lot of flexibility when creating the :term:`Build Directory`. + Here are some examples that show how to create the directory. The examples assume your :term:`Source Directory` is named ``poky``: - Create the Build Directory inside your Source Directory and let diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst index ae14c450dd..691a0cdc1a 100644 --- a/documentation/ref-manual/variables.rst +++ b/documentation/ref-manual/variables.rst @@ -318,7 +318,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 @@ -6174,7 +6174,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" @@ -8940,7 +8940,7 @@ system and gives an overview of their function and contents. configuration can define the :term:`UBOOT_MACHINE` and optionally the :term:`IMAGE_FSTYPES` and the :term:`UBOOT_BINARY`. - Following is an example from the ``meta-freescale`` layer. :: + 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" @@ -9413,7 +9413,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/documentation/sdk-manual/appendix-obtain.rst b/documentation/sdk-manual/appendix-obtain.rst index 7b458f281b..d384b4916a 100644 --- a/documentation/sdk-manual/appendix-obtain.rst +++ b/documentation/sdk-manual/appendix-obtain.rst @@ -51,8 +51,8 @@ Follow these steps to locate and hand-install the toolchain: poky-glibc-x86_64-core-image-sato-core2-64-qemux86-64-toolchain-&DISTRO;.sh -4. *Run the Installer:* Be sure you have execution privileges and run - the installer. Following is an example from the ``Downloads`` +#. *Run the Installer:* Be sure you have execution privileges and run + 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 @@ -155,12 +155,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" -7. *Run the Installer:* You can now run the SDK installer from - ``tmp/deploy/sdk`` in the Build Directory. Following is an example:: +#. *Run the Installer:* You can now run the SDK installer from + ``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 @@ -225,7 +225,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 @@ -233,7 +233,7 @@ Follow these steps to extract the root filesystem: 3. *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 `. This command extracts the root filesystem into the ``core2-64-sato`` diff --git a/documentation/sdk-manual/intro.rst b/documentation/sdk-manual/intro.rst index 802d3f3d42..4310e133fb 100644 --- a/documentation/sdk-manual/intro.rst +++ b/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/documentation/toaster-manual/setup-and-use.rst b/documentation/toaster-manual/setup-and-use.rst index 1e1a314d66..69155bdeb7 100644 --- a/documentation/toaster-manual/setup-and-use.rst +++ b/documentation/toaster-manual/setup-and-use.rst @@ -366,7 +366,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 @@ -496,7 +496,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 `__ overviews and From patchwork Tue Feb 27 14:01:16 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40141 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C7E3C54E58 for ; Tue, 27 Feb 2024 14:01:41 +0000 (UTC) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx.groups.io with SMTP id smtpd.web10.12828.1709042498937472084 for ; Tue, 27 Feb 2024 06:01:39 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=KUNhmVxl; spf=pass (domain: bootlin.com, ip: 217.70.183.197, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 784151C0014; Tue, 27 Feb 2024 14:01:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042497; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OWKZ1exxJjcEr+bSJGbHWiEp3pxCkXHnjkPDysSKj2k=; b=KUNhmVxlTz1i/R+wTyZ7KhqrpZJDemCfRr11cJaYn7pazOV6iAsqvHOQn+6eftQZ8m2Blf YuShaVcuGv2xRfc8LJk8fu8wMKHuVXcA1MYsI5CoxIh4Q14IOLltbhnxjTjeTUkkvqKBNc v2uKHo0rr2o5WcJCJJ/r8/JCquZyzwY1LcDqmUzmF9U/NCHrbBps8UJV/R+Oi1H1zyi2gY 0cmKFvtGj+qmVKuIEbu9uVDSmLhWa/Gpe+g477ZK3Gd9/4PmPY+xFXGq9YbrcWwCCafrbA Z9DbA6Jrz0v5hgacD98zZe7zi784suXhy9wmp8PZ7UItPHWwXYtG9aGZvK4TnA== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker , Richard Purdie Subject: [kirkstone][PATCH 04/16] dev-manual: packages: clarify shared PR service constraint Date: Tue, 27 Feb 2024 15:01:16 +0100 Message-Id: <20240227140128.481522-5-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:41 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4895 From: Michael Opdenacker Explicit the problems previous described as "obvious". Signed-off-by: Michael Opdenacker Suggested-by: Richard Purdie --- documentation/dev-manual/packages.rst | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/documentation/dev-manual/packages.rst b/documentation/dev-manual/packages.rst index 0e991e409a..d90ff7110e 100644 --- a/documentation/dev-manual/packages.rst +++ b/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`" From patchwork Tue Feb 27 14:01:17 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40139 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 792D5C54E56 for ; Tue, 27 Feb 2024 14:01:41 +0000 (UTC) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx.groups.io with SMTP id smtpd.web10.12829.1709042499320399333 for ; Tue, 27 Feb 2024 06:01:39 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=FN8LqQHQ; spf=pass (domain: bootlin.com, ip: 217.70.183.196, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id DAA45E000F; Tue, 27 Feb 2024 14:01:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042498; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Wb25ItySJ1SkRqVqTb64ZujnJcv4sud70bfUc7VLkhg=; b=FN8LqQHQo1H0/+oqI4Qd3HIonhHD/pkBIBt0+NGXpO6WcNPq/sUMR5PbyopuFboeN80huM DtiFDDtrqPZIklX0HN4q8DgFchAGmPum4h+U16DAcN0p5ybzcBx0rmDr2w5wMVeyKtfBmG unogvJuDl5ww+ImxCBCuowB4iggH6XYZEYMz7e2FFmmzoPSkv3YPlZf4UB0GROj3yXwOvu MK5WIycZYUDAeCH/zVyTq1/BGpSNke/5ZzQ2cKgXPIypo0mVuX1DDjQqO0VZ/FAUcqQak7 WNk+JB7ni/1WwGnrnvEidPRvv7oitXuCaYrn6R4nWKSGxHwJpDq9JBW4dFbgbg== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker Subject: [kirkstone][PATCH 05/16] dev-manual: packages: need enough free space Date: Tue, 27 Feb 2024 15:01:17 +0100 Message-Id: <20240227140128.481522-6-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:41 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4896 From: Michael Opdenacker Enough free storage space is needed to apply package upgrades. Signed-off-by: Michael Opdenacker --- documentation/dev-manual/packages.rst | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/documentation/dev-manual/packages.rst b/documentation/dev-manual/packages.rst index d90ff7110e..a6e6af0de7 100644 --- a/documentation/dev-manual/packages.rst +++ b/documentation/dev-manual/packages.rst @@ -612,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 From patchwork Tue Feb 27 14:01:18 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40138 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C39EC54E55 for ; Tue, 27 Feb 2024 14:01:41 +0000 (UTC) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by mx.groups.io with SMTP id smtpd.web10.12830.1709042499632892225 for ; Tue, 27 Feb 2024 06:01:40 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=n3zqzzEJ; spf=pass (domain: bootlin.com, ip: 217.70.183.200, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 3862C20007; Tue, 27 Feb 2024 14:01:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042498; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=916V1MNbg+hpB1kx1vdDBRucA789AemVe4AsknXM+vw=; b=n3zqzzEJPMB5KB3X11j7fJ+vcRp/KbqdNGV8Sb2RrDmagJ02PuNU2aHF8PwEzzxYBcVHBs 1L7gGc82NQIfkSiMkNQ73xgBlHuWbVGLVXOj46da3vd1qy5E7xkLlGpng9lqUGK9d89JLo 5CYcQYuNNW5B2VfYNk4HThV5iWgTegCteiJ6A73C4XECudTs5unteb4LobrONnkEg3O8Yj +N50HuKXG32dn++f7U8JfmjgpAGkyqWuUHr8zNiPv2vSu4UzgGm21tW2/7ZkDrl0YBeDNs vCKV/3SCJRmwBdNFW7ci6W3mkLees0qR2SZW3xBi+oZPH2M/k82r9qHcduPxTQ== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker Subject: [kirkstone][PATCH 06/16] manuals: update disk space requirements Date: Tue, 27 Feb 2024 15:01:18 +0100 Message-Id: <20240227140128.481522-7-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:41 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4897 From: Michael Opdenacker Tests made on Poky master on March 16, 2023. Add a "Free Disk Space" section to the "System Requirements" document. Signed-off-by: Michael Opdenacker --- documentation/brief-yoctoprojectqs/index.rst | 4 +++- documentation/poky.yaml.in | 2 ++ documentation/ref-manual/system-requirements.rst | 11 +++++++++++ 3 files changed, 16 insertions(+), 1 deletion(-) diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst index ec4cc8b051..565e00be2e 100644 --- a/documentation/brief-yoctoprojectqs/index.rst +++ b/documentation/brief-yoctoprojectqs/index.rst @@ -47,7 +47,9 @@ Compatible Linux Distribution Make sure your :term:`Build Host` meets the following requirements: -- 50 Gbytes of free disk space +- At least &MIN_DISK_SPACE; Gbytes of free disk space, though + much more will help to run multiple builds and increase + performance by reusing build artifacts. - Runs a supported Linux distribution (i.e. recent releases of Fedora, openSUSE, CentOS, Debian, or Ubuntu). For a list of Linux diff --git a/documentation/poky.yaml.in b/documentation/poky.yaml.in index 6b942f0959..1d4e176604 100644 --- a/documentation/poky.yaml.in +++ b/documentation/poky.yaml.in @@ -46,3 +46,5 @@ MIN_TAR_VERSION : "1.28" MIN_GIT_VERSION : "1.8.3.1" MIN_GCC_VERSION : "7.5" MIN_MAKE_VERSION : "4.0" +# Disk space (Gbytes) needed to generate qemux86-64 core-image-sato on Ubuntu 22.04 (x86-64), rounded up from 87 +MIN_DISK_SPACE : "90" diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst index 274781a903..72579a5e23 100644 --- a/documentation/ref-manual/system-requirements.rst +++ b/documentation/ref-manual/system-requirements.rst @@ -29,6 +29,17 @@ and conceptual information in the :doc:`/overview-manual/index`. For more information about the Yocto Project Documentation set, see the :ref:`ref-manual/resources:links and related documentation` section. +Minimum Free Disk Space +======================= + +To build an image such as ``core-image-sato`` for the ``qemux86-64`` machine, +you need a system with at least &MIN_DISK_SPACE; Gbytes of free disk space. +However, much more disk space will be necessary to build more complex images, +to run multiple builds and to cache build artifacts, improving build efficiency. + +If you have a shortage of disk space, see the ":doc:`/dev-manual/disk-space`" +section of the Development Tasks Manual. + .. _detailed-supported-distros: Supported Linux Distributions From patchwork Tue Feb 27 14:01:19 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40140 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65308C54E4A for ; Tue, 27 Feb 2024 14:01:41 +0000 (UTC) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by mx.groups.io with SMTP id smtpd.web11.12660.1709042500021911556 for ; Tue, 27 Feb 2024 06:01:40 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=XJnNUKKd; spf=pass (domain: bootlin.com, ip: 217.70.183.199, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 908DCFF811; Tue, 27 Feb 2024 14:01:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042498; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HW5Dc0Hdj8keod+g8MYvKUjww6yexFGvnwhMHorkOXQ=; b=XJnNUKKdaVwCzx0nmCSUiYgw2qbI6PIodj8gYiVPK3TwuolTAp4QUYYmaitn80OCT2Goyw 2j4+zvmkHI2LFZPPIGVZ7ASTivJAMwPHVkraUCX2W/QEOmlVV9pTQQzNSSYnCF1xaf5ZvG 5JkhMTx6SnBBfMmt29gkx8KtAJjDG1AbqcEfAA1Y9gFbwvtoOuWgIpfiMKb2/NNKmcoTin QAlQpFQUkJzgDvkiAR4eRjMW3Y9dL567iE4TDE9n9E9kbSg5IYXdDqxGmQnHJl+JtscRgv G1H4NLkZyj9HHBWlKYTYrecsTL/9LEH03vM38OQhV8iLSc8yWXNykyWtcW3pcA== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker Subject: [kirkstone][PATCH 07/16] manuals: add minimum RAM requirements Date: Tue, 27 Feb 2024 15:01:19 +0100 Message-Id: <20240227140128.481522-8-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:41 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4898 From: Michael Opdenacker Measured by generating a "core-image-sato" image for a "qemux86-64" machine from an Ubuntu 22.04 VM with 4 cores. Less memory was not enough and caused Out of Memory failures. Signed-off-by: Michael Opdenacker --- documentation/brief-yoctoprojectqs/index.rst | 4 ++++ documentation/poky.yaml.in | 4 ++++ documentation/ref-manual/system-requirements.rst | 10 ++++++++++ 3 files changed, 18 insertions(+) diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst index 565e00be2e..462c942961 100644 --- a/documentation/brief-yoctoprojectqs/index.rst +++ b/documentation/brief-yoctoprojectqs/index.rst @@ -51,6 +51,10 @@ following requirements: much more will help to run multiple builds and increase performance by reusing build artifacts. +- At least &MIN_RAM; Gbytes of RAM, though a modern modern build host with as + much RAM and as many CPU cores as possible is strongly recommended to + maximize build performance. + - Runs a supported Linux distribution (i.e. recent releases of Fedora, openSUSE, CentOS, Debian, or Ubuntu). For a list of Linux distributions that support the Yocto Project, see the diff --git a/documentation/poky.yaml.in b/documentation/poky.yaml.in index 1d4e176604..8c6549d571 100644 --- a/documentation/poky.yaml.in +++ b/documentation/poky.yaml.in @@ -48,3 +48,7 @@ MIN_GCC_VERSION : "7.5" MIN_MAKE_VERSION : "4.0" # Disk space (Gbytes) needed to generate qemux86-64 core-image-sato on Ubuntu 22.04 (x86-64), rounded up from 87 MIN_DISK_SPACE : "90" +# Disk space (Gbytes) needed to generate qemux86-64 core-image-sato on Ubuntu 22.04 (x86-64) with "rm_work", rounded up from 38 +MIN_DISK_SPACE_RM_WORK : "40" +# RAM (Gbytes) needed to generate qemux86-64 core-image-sato on Ubuntu 22.04 (x86-64) on a 4 core system +MIN_RAM : "8" diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst index 72579a5e23..92e2211629 100644 --- a/documentation/ref-manual/system-requirements.rst +++ b/documentation/ref-manual/system-requirements.rst @@ -40,6 +40,16 @@ to run multiple builds and to cache build artifacts, improving build efficiency. If you have a shortage of disk space, see the ":doc:`/dev-manual/disk-space`" section of the Development Tasks Manual. +.. _system-requirements-minimum-ram: + +Minimum System RAM +================== + +You will manage to build an image such as ``core-image-sato`` for the +``qemux86-64`` machine with as little as &MIN_RAM; Gbytes of RAM on an old +system with 4 CPU cores, but your builds will be much faster on a system with +as much RAM and as many CPU cores as possible. + .. _detailed-supported-distros: Supported Linux Distributions From patchwork Tue Feb 27 14:01:20 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40137 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B37FC54E51 for ; Tue, 27 Feb 2024 14:01:41 +0000 (UTC) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx.groups.io with SMTP id smtpd.web10.12831.1709042500358504890 for ; Tue, 27 Feb 2024 06:01:40 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=iA/7o7wa; spf=pass (domain: bootlin.com, ip: 217.70.183.195, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id E22B66000C; Tue, 27 Feb 2024 14:01:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042499; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=08fmOFOTkj2ThVbhpCA2HTZp/P+PXtLcKuwuWhu9g/8=; b=iA/7o7wavI970ljgEwOUB57tRhQJOcnV8jtTqg0z4kwvSH4jrZkllAvLaRn74WPATy29EC 2SxX/xVQ8DKUioFNwTiSSa+IuxHtJ7wb3kcgYHHHbv7xSc0e8OvgLfNPJhmQfLrckFjafQ 5YH5gWsytHbm/e0ObdCh/ygo3G/RLx+jKiJqt/43wQJm876bAmfy8YMl5bT7R09nYypjxL 620Ou0NlOoLtZkoB7Hu8EtzLexPlkfkOv8C4AV0Wy2wCoBKaUW5hQlspqry9lkfwVTBFgM sFpdLSrz0Tc3FXxY/RqlWpztWwPoO5mtlTeF7ktxrxeGUAovti2dn4ZGwie8ow== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker , Paul Eggleton Subject: [kirkstone][PATCH 08/16] ref-manual: add info on buildtools-make-tarball Date: Tue, 27 Feb 2024 15:01:20 +0100 Message-Id: <20240227140128.481522-9-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:41 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4899 From: Michael Opdenacker From: Paul Eggleton PENDING ON THIS OE-CORE PATCH: install-buildtools: support buildtools-make-tarball and update to 4.1 https://lists.openembedded.org/g/openembedded-core/message/171522 Cover the use case and the new provided tarball. Signed-off-by: Paul Eggleton --- .../ref-manual/system-requirements.rst | 26 ++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst index 92e2211629..e0b8400178 100644 --- a/documentation/ref-manual/system-requirements.rst +++ b/documentation/ref-manual/system-requirements.rst @@ -303,8 +303,13 @@ resolve this by installing a ``buildtools-extended`` tarball that contains additional tools, the equivalent of the Debian/Ubuntu ``build-essential`` package. +For systems with a broken make version (e.g. make 4.2.1 without patches) but +where the rest of the host tools are usable, you can use the ``buildtools-make`` +tarball instead. + In the sections that follow, three different methods will be described for -installing the ``buildtools`` or ``buildtools-extended`` toolset. +installing the ``buildtools``, ``buildtools-extended`` or ``buildtools-make`` +toolset. Installing a Pre-Built ``buildtools`` Tarball with ``install-buildtools`` script -------------------------------------------------------------------------------- @@ -339,6 +344,13 @@ installer and automatically installs the tools for you: $ cd poky $ scripts/install-buildtools + Alternatively if your host development system has a broken ``make`` + version such that you only need a known good version of ``make``, + you can use the ``--make-only`` option: + + $ cd poky + $ scripts/install-buildtools --make-only + 2. Source the tools environment setup script by using a command like the following:: @@ -373,6 +385,10 @@ steps: $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh + An example for the make-only installer:: + + $ sh ~/Downloads/x86_64-buildtools-make-nativesdk-standalone-&DISTRO;.sh + During execution, a prompt appears that allows you to choose the installation directory. For example, you could choose the following: ``/home/your-username/buildtools`` @@ -418,6 +434,10 @@ installer: $ bitbake buildtools-extended-tarball + or to build the make-only tarball:: + + $ bitbake buildtools-make-tarball + .. note:: The :term:`SDKMACHINE` variable in your ``local.conf`` file determines @@ -441,6 +461,10 @@ installer: $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh + or for the make-only installer:: + + $ sh ~/Downloads/x86_64-buildtools-make-nativesdk-standalone-&DISTRO;.sh + During execution, a prompt appears that allows you to choose the installation directory. For example, you could choose the following: ``/home/your_username/buildtools`` From patchwork Tue Feb 27 14:01:21 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40144 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF743C54E5D for ; Tue, 27 Feb 2024 14:01:41 +0000 (UTC) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by mx.groups.io with SMTP id smtpd.web10.12832.1709042500794198354 for ; Tue, 27 Feb 2024 06:01:41 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=ezIdQOo2; spf=pass (domain: bootlin.com, ip: 217.70.183.195, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 5082060011; Tue, 27 Feb 2024 14:01:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042499; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZM28rGXbNQLyNnOTjEewozbHU2d1hq4dKCfwRzXHGm8=; b=ezIdQOo2N2gqtzxlyWqQKFdKHowcPIQZIDDaYU1ZQDdg+L8Z2pnxkXBW8zBaXuduZz9e8Z m+mOTDarz7nNgV9Y/V7p0uH6O5eu3M8vsFsg+7v91xdxCEDuz1wTbCZ/YbS9Twug4h1wbv 82hi0lT1tVQ/wt89ryDthq8i7ZYss9YSaxhBkem/mSNylk+QpRnIyMxOzpl007AqFtcj7/ 9CcJQGK7CkAzgtALQdXzDSJs6YHLeQ1XiSEXUiH+ll9ai+MjVO3oY0YisZfTIIIrbZ369j +gXTbzrGu2Y7SpY46O2spA2VvrrG/jZ+4OUv8e4e205NPqLdygQvj8ieMumBPw== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker Subject: [kirkstone][PATCH 09/16] manuals: update references to buildtools Date: Tue, 27 Feb 2024 15:01:21 +0100 Message-Id: <20240227140128.481522-10-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:41 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4900 From: Michael Opdenacker Also fix number of corresponding paragraphs Signed-off-by: Michael Opdenacker --- documentation/brief-yoctoprojectqs/index.rst | 2 +- documentation/dev-manual/start.rst | 4 +- .../migration-guides/migration-1.5.rst | 3 +- .../migration-guides/migration-1.7.rst | 4 +- .../migration-guides/migration-2.1.rst | 6 +- .../migration-guides/migration-2.2.rst | 2 +- .../migration-guides/migration-3.2.rst | 2 +- .../migration-guides/migration-3.3.rst | 6 +- .../migration-guides/migration-3.4.rst | 2 +- .../migration-guides/migration-4.0.rst | 2 +- documentation/ref-manual/faq.rst | 2 +- .../ref-manual/system-requirements.rst | 87 +++++++++---------- documentation/ref-manual/terms.rst | 18 ++++ .../test-manual/understand-autobuilder.rst | 2 +- 14 files changed, 78 insertions(+), 64 deletions(-) diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst index 462c942961..9eff13f583 100644 --- a/documentation/brief-yoctoprojectqs/index.rst +++ b/documentation/brief-yoctoprojectqs/index.rst @@ -75,7 +75,7 @@ following requirements: If your build host does not meet any of these three listed version requirements, you can take steps to prepare the system so that you can still use the Yocto Project. See the -:ref:`ref-manual/system-requirements:required git, tar, python and gcc versions` +:ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions` section in the Yocto Project Reference Manual for information. Build Host Packages diff --git a/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst index 9dc9b855b3..834fb13088 100644 --- a/documentation/dev-manual/start.rst +++ b/documentation/dev-manual/start.rst @@ -308,10 +308,12 @@ Project Build Host: - gcc &MIN_GCC_VERSION; or greater. + - GNU make &MIN_MAKE_VERSION; or greater + If your build host does not meet any of these listed version requirements, you can take steps to prepare the system so that you can still use the Yocto Project. See the - ":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`" + ":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`" section in the Yocto Project Reference Manual for information. 4. *Install Development Host Packages:* Required development host diff --git a/documentation/migration-guides/migration-1.5.rst b/documentation/migration-guides/migration-1.5.rst index 81a434d5b7..06334d6fc7 100644 --- a/documentation/migration-guides/migration-1.5.rst +++ b/documentation/migration-guides/migration-1.5.rst @@ -26,8 +26,7 @@ provide packages for these, you can install and use the Buildtools tarball, which provides an SDK-like environment containing them. For more information on this requirement, see the -":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`" -section. +":ref:`system-requirements-buildtools`" section. .. _migration-1.5-atom-pc-bsp: diff --git a/documentation/migration-guides/migration-1.7.rst b/documentation/migration-guides/migration-1.7.rst index d4af1277e9..73eb6d1b81 100644 --- a/documentation/migration-guides/migration-1.7.rst +++ b/documentation/migration-guides/migration-1.7.rst @@ -30,8 +30,8 @@ version required on the build host is now 1.7.8 because the ``--list`` option is now required by BitBake's Git fetcher. As always, if your host distribution does not provide a version of Git that meets this requirement, you can use the -``buildtools-tarball`` that does. See the -":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`" +:term:`buildtools` tarball that does. See the +":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`" section for more information. .. _migration-1.7-autotools-class-changes: diff --git a/documentation/migration-guides/migration-2.1.rst b/documentation/migration-guides/migration-2.1.rst index 6ef3adb443..54d359a67c 100644 --- a/documentation/migration-guides/migration-2.1.rst +++ b/documentation/migration-guides/migration-2.1.rst @@ -356,9 +356,9 @@ These additional changes exist: - The minimum Git version has been increased to 1.8.3.1. If your host distribution does not provide a sufficiently recent version, you can - install the buildtools, which will provide it. See the - :ref:`ref-manual/system-requirements:required git, tar, python and gcc versions` - section for more information on the buildtools tarball. + install the :term:`buildtools`, which will provide it. See the + :ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions` + section for more information on the :term:`buildtools` tarball. - The buggy and incomplete support for the RPM version 4 package manager has been removed. The well-tested and maintained support for diff --git a/documentation/migration-guides/migration-2.2.rst b/documentation/migration-guides/migration-2.2.rst index 49cd9b9ae0..979b5aa0f9 100644 --- a/documentation/migration-guides/migration-2.2.rst +++ b/documentation/migration-guides/migration-2.2.rst @@ -103,7 +103,7 @@ online package-manager support through SMART still require Python 2. ``buildtools-tarball`` Includes Python 3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -``buildtools-tarball`` now includes Python 3. +The :term:`buildtools` tarball now includes Python 3. .. _migration-2.2-uclibc-replaced-by-musl: diff --git a/documentation/migration-guides/migration-3.2.rst b/documentation/migration-guides/migration-3.2.rst index d593effe97..40a917bfc7 100644 --- a/documentation/migration-guides/migration-3.2.rst +++ b/documentation/migration-guides/migration-3.2.rst @@ -11,7 +11,7 @@ Minimum system requirements ``gcc`` version 6.0 is now required at minimum on the build host. For older host distributions where this is not available, you can use the -``buildtools-extended-tarball`` (easily installable using +:term:`buildtools-extended` tarball (easily installable using ``scripts/install-buildtools``). diff --git a/documentation/migration-guides/migration-3.3.rst b/documentation/migration-guides/migration-3.3.rst index 1eb494c286..b1b81d6839 100644 --- a/documentation/migration-guides/migration-3.3.rst +++ b/documentation/migration-guides/migration-3.3.rst @@ -12,9 +12,9 @@ Minimum system requirements You will now need at least Python 3.6 installed on your build host. Most recent distributions provide this, but should you be building on a distribution that -does not have it, you can use the ``buildtools-tarball`` (easily installable -using ``scripts/install-buildtools``) - see -:ref:`ref-manual/system-requirements:required git, tar, python and gcc versions` +does not have it, you can use the :term:`buildtools` tarball (easily installable +using ``scripts/install-buildtools``) --- see +:ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions` for details. diff --git a/documentation/migration-guides/migration-3.4.rst b/documentation/migration-guides/migration-3.4.rst index b184dde41e..0ef6c435ec 100644 --- a/documentation/migration-guides/migration-3.4.rst +++ b/documentation/migration-guides/migration-3.4.rst @@ -93,7 +93,7 @@ The ``lz4c``, ``pzstd`` and ``zstd`` commands are now required to be installed on the build host to support LZ4 and Zstandard compression functionality. These are typically provided by ``lz4`` and ``zstd`` packages in most Linux distributions. Alternatively they are available -as part of ``buildtools-tarball`` if your distribution does not provide +as part of :term:`buildtools` tarball if your distribution does not provide them. For more information see :ref:`ref-manual/system-requirements:required packages for the build host`. diff --git a/documentation/migration-guides/migration-4.0.rst b/documentation/migration-guides/migration-4.0.rst index 9e78fc709f..93576d4538 100644 --- a/documentation/migration-guides/migration-4.0.rst +++ b/documentation/migration-guides/migration-4.0.rst @@ -189,7 +189,7 @@ Supported host distribution changes - ``gcc`` version 7.5 is now required at minimum on the build host. For older host distributions where this is not available, you can use the - ``buildtools-extended-tarball`` (easily installable using + :term:`buildtools-extended` tarball (easily installable using ``scripts/install-buildtools``). :append/:prepend in combination with other operators diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst index 9fb60899c9..478fbb3a69 100644 --- a/documentation/ref-manual/faq.rst +++ b/documentation/ref-manual/faq.rst @@ -22,7 +22,7 @@ Can I still use the Yocto Project? **A:** You can get the required tools on your host development system a couple different ways (i.e. building a tarball or downloading a tarball). See the -":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`" +":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`" section for steps on how to update your build tools. **Q:** How can you claim Poky / OpenEmbedded-Core is stable? diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst index e0b8400178..1a6f7647b6 100644 --- a/documentation/ref-manual/system-requirements.rst +++ b/documentation/ref-manual/system-requirements.rst @@ -276,8 +276,10 @@ supported CentOS-8 Linux distribution: $ sudo dnf install make python3-pip which &PIP3_HOST_PACKAGES_DOC; -Required Git, tar, Python and gcc Versions -========================================== +.. _system-requirements-buildtools: + +Required Git, tar, Python, make and gcc Versions +================================================ In order to use the build system, your host development system must meet the following version requirements for Git, tar, and Python: @@ -288,10 +290,12 @@ the following version requirements for Git, tar, and Python: - Python &MIN_PYTHON_VERSION; or greater +- GNU make &MIN_MAKE_VERSION; or greater + If your host development system does not meet all these requirements, -you can resolve this by installing a ``buildtools`` tarball that -contains these tools. You can get the tarball one of two ways: download -a pre-built tarball or use BitBake to build the tarball. +you can resolve this by installing a :term:`buildtools` tarball that +contains these tools. You can either download a pre-built tarball or +use BitBake to build one. In addition, your host development system must meet the following version requirement for gcc: @@ -299,26 +303,26 @@ version requirement for gcc: - gcc &MIN_GCC_VERSION; or greater If your host development system does not meet this requirement, you can -resolve this by installing a ``buildtools-extended`` tarball that +resolve this by installing a :term:`buildtools-extended` tarball that contains additional tools, the equivalent of the Debian/Ubuntu ``build-essential`` package. For systems with a broken make version (e.g. make 4.2.1 without patches) but -where the rest of the host tools are usable, you can use the ``buildtools-make`` +where the rest of the host tools are usable, you can use the :term:`buildtools-make` tarball instead. In the sections that follow, three different methods will be described for -installing the ``buildtools``, ``buildtools-extended`` or ``buildtools-make`` +installing the :term:`buildtools`, :term:`buildtools-extended` or :term:`buildtools-make` toolset. Installing a Pre-Built ``buildtools`` Tarball with ``install-buildtools`` script -------------------------------------------------------------------------------- The ``install-buildtools`` script is the easiest of the three methods by -which you can get these tools. It downloads a pre-built buildtools +which you can get these tools. It downloads a pre-built :term:`buildtools` installer and automatically installs the tools for you: -1. Execute the ``install-buildtools`` script. Here is an example:: +#. Execute the ``install-buildtools`` script. Here is an example:: $ cd poky $ scripts/install-buildtools \ @@ -327,7 +331,7 @@ installer and automatically installs the tools for you: --release yocto-&DISTRO; \ --installer-version &DISTRO; - During execution, the buildtools tarball will be downloaded, the + During execution, the :term:`buildtools` tarball will be downloaded, the checksum of the download will be verified, the installer will be run for you, and some basic checks will be run to make sure the installation is functional. @@ -338,7 +342,7 @@ installer and automatically installs the tools for you: /path/to/poky/buildtools If your host development system needs the additional tools provided - in the ``buildtools-extended`` tarball, you can instead execute the + in the :term:`buildtools-extended` tarball, you can instead execute the ``install-buildtools`` script with the default parameters:: $ cd poky @@ -346,24 +350,21 @@ installer and automatically installs the tools for you: Alternatively if your host development system has a broken ``make`` version such that you only need a known good version of ``make``, - you can use the ``--make-only`` option: + you can use the ``--make-only`` option:: $ cd poky $ scripts/install-buildtools --make-only -2. Source the tools environment setup script by using a command like the +#. Source the tools environment setup script by using a command like the following:: $ source /path/to/poky/buildtools/environment-setup-x86_64-pokysdk-linux - Of course, you need to supply your installation directory and be sure to - use the right file (i.e. i586 or x86_64). - After you have sourced the setup script, the tools are added to ``PATH`` and any other environment variables required to run the tools are initialized. The results are working versions versions of Git, tar, Python and ``chrpath``. And in the case of the - ``buildtools-extended`` tarball, additional working versions of tools + :term:`buildtools-extended` tarball, additional working versions of tools including ``gcc``, ``make`` and the other tools included in ``packagegroup-core-buildessential``. @@ -371,12 +372,14 @@ Downloading a Pre-Built ``buildtools`` Tarball ---------------------------------------------- If you would prefer not to use the ``install-buildtools`` script, you can instead -download and run a pre-built buildtools installer yourself with the following +download and run a pre-built :term:`buildtools` installer yourself with the following steps: -1. Locate and download the ``*.sh`` at :yocto_dl:`/releases/yocto/yocto-&DISTRO;/buildtools/` +#. Go to :yocto_dl:`/releases/yocto/yocto-&DISTRO;/buildtools/`, locate and + download the ``.sh`` file corresponding to your host architecture + and to :term:`buildtools`, :term:`buildtools-extended` or :term:`buildtools-make`. -2. Execute the installation script. Here is an example for the +#. Execute the installation script. Here is an example for the traditional installer:: $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh @@ -393,44 +396,40 @@ steps: installation directory. For example, you could choose the following: ``/home/your-username/buildtools`` -3. Source the tools environment setup script by using a command like the - following:: +#. As instructed by the installer script, you will have to source the tools + environment setup script:: - $ source /home/your_username/buildtools/environment-setup-i586-poky-linux - - Of - course, you need to supply your installation directory and be sure to - use the right file (i.e. i585 or x86-64). + $ source /home/your_username/buildtools/environment-setup-x86_64-pokysdk-linux After you have sourced the setup script, the tools are added to ``PATH`` and any other environment variables required to run the tools are initialized. The results are working versions versions of Git, tar, Python and ``chrpath``. And in the case of the - ``buildtools-extended`` tarball, additional working versions of tools + :term:`buildtools-extended` tarball, additional working versions of tools including ``gcc``, ``make`` and the other tools included in ``packagegroup-core-buildessential``. Building Your Own ``buildtools`` Tarball ---------------------------------------- -Building and running your own buildtools installer applies only when you +Building and running your own :term:`buildtools` installer applies only when you have a build host that can already run BitBake. In this case, you use that machine to build the ``.sh`` file and then take steps to transfer and run it on a machine that does not meet the minimal Git, tar, and Python (or gcc) requirements. -Here are the steps to take to build and run your own buildtools +Here are the steps to take to build and run your own :term:`buildtools` installer: -1. On the machine that is able to run BitBake, be sure you have set up +#. On the machine that is able to run BitBake, be sure you have set up your build environment with the setup script (:ref:`structure-core-script`). -2. Run the BitBake command to build the tarball:: +#. Run the BitBake command to build the tarball:: $ bitbake buildtools-tarball - or run the BitBake command to build the extended tarball:: + or to build the extended tarball:: $ bitbake buildtools-extended-tarball @@ -446,22 +445,21 @@ installer: Once the build completes, you can find the ``.sh`` file that installs the tools in the ``tmp/deploy/sdk`` subdirectory of the :term:`Build Directory`. The installer file has the string - "buildtools" (or "buildtools-extended") in the name. + "buildtools" or "buildtools-extended" in the name. -3. Transfer the ``.sh`` file from the build host to the machine that +#. Transfer the ``.sh`` file from the build host to the machine that does not meet the Git, tar, or Python (or gcc) requirements. -4. On the machine that does not meet the requirements, run the ``.sh`` - file to install the tools. Here is an example for the traditional - installer:: +#. On this machine, run the ``.sh`` file to install the tools. Here is an + example for the traditional installer:: $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh - Here is an example for the extended installer:: + For the extended installer:: $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh - or for the make-only installer:: + And for the make-only installer:: $ sh ~/Downloads/x86_64-buildtools-make-nativesdk-standalone-&DISTRO;.sh @@ -469,18 +467,15 @@ installer: installation directory. For example, you could choose the following: ``/home/your_username/buildtools`` -5. Source the tools environment setup script by using a command like the +#. Source the tools environment setup script by using a command like the following:: $ source /home/your_username/buildtools/environment-setup-x86_64-poky-linux - Of course, you need to supply your installation directory and be sure to - use the right file (i.e. i586 or x86_64). - After you have sourced the setup script, the tools are added to ``PATH`` and any other environment variables required to run the tools are initialized. The results are working versions versions of Git, tar, Python and ``chrpath``. And in the case of the - ``buildtools-extended`` tarball, additional working versions of tools + :term:`buildtools-extended` tarball, additional working versions of tools including ``gcc``, ``make`` and the other tools included in ``packagegroup-core-buildessential``. diff --git a/documentation/ref-manual/terms.rst b/documentation/ref-manual/terms.rst index d602f7ea36..98ca677015 100644 --- a/documentation/ref-manual/terms.rst +++ b/documentation/ref-manual/terms.rst @@ -109,6 +109,24 @@ universal, the list includes them just in case: environment. The build system is sometimes referred to as the development host. + :term:`buildtools` + Build tools in binary form, providing required versions of development + tools (such as Git, GCC, Python and make), to run the OpenEmbedded build + system on a development host without such minimum versions. + + See the ":ref:`system-requirements-buildtools`" paragraph in the + Reference Manual for details about downloading or building an archive + of such tools. + + :term:`buildtools-extended` + A set of :term:`buildtools` binaries extended with additional development + tools, such as a required version of the GCC compiler to run the + OpenEmbedded build system. + + :term:`buildtools-make` + A variant of :term:`buildtools`, just providing the required + version of ``make`` to run the OpenEmbedded build system. + :term:`Classes` Files that provide for logic encapsulation and inheritance so that commonly used patterns can be defined once and then easily used in diff --git a/documentation/test-manual/understand-autobuilder.rst b/documentation/test-manual/understand-autobuilder.rst index 11e2ceb12f..837109ad7d 100644 --- a/documentation/test-manual/understand-autobuilder.rst +++ b/documentation/test-manual/understand-autobuilder.rst @@ -205,7 +205,7 @@ The ``scripts/run-config`` execution is where most of the work within the Autobuilder happens. It runs through a number of steps; the first are general setup steps that are run once and include: -#. Set up any ``buildtools-tarball`` if configured. +#. Set up any :term:`buildtools` tarball if configured. <<<<<<< HEAD #. Call "buildhistory-init" if buildhistory is configured. From patchwork Tue Feb 27 14:01:22 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40150 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7419C54E58 for ; Tue, 27 Feb 2024 14:01:51 +0000 (UTC) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by mx.groups.io with SMTP id smtpd.web10.12833.1709042501984933384 for ; Tue, 27 Feb 2024 06:01:42 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=Twx66CyC; spf=pass (domain: bootlin.com, ip: 217.70.183.198, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 0DAB7C0006; Tue, 27 Feb 2024 14:01:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042500; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YEwLs4SaiFOh7tSb3t3AjHTeHvg26OB4lsjdr7G3LfE=; b=Twx66CyC7sm5XszJ315JJ5tHxM4QbUUkVE8rpRFoKqCbSxPrO5/S8wrx820haROZ3s2yvJ NEA9uv2Lzz40F66+bPGEDRiFkHKoZsIxmvFjT5WFu8DF2habWqEU9+mMctejLIj7TLPwcT UCtFLeaZGHtLFhuTc50szeHjFOiQCNaRQrE1cFdUuOy7JYkBvokk9h59utodjYu0ycNQ0S IC9KuJq1XJHmd1RkegVZDrnIMZgf5CBXjb6TdbRku6gYsm0ZqBXRT8y7dZ4MqRmFyXxYox bOdoP/2nBAkmmVUh3QukAK4VXG9dieSxmedwHQ3TP2IhArKGEqyjzaBNx91BFQ== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker Subject: [kirkstone][PATCH 10/16] ref-manual: system-requirements: modify anchor Date: Tue, 27 Feb 2024 15:01:22 +0100 Message-Id: <20240227140128.481522-11-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:51 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4902 From: Michael Opdenacker To align with the "master" branch Signed-off-by: Michael Opdenacker --- documentation/dev-manual/start.rst | 2 +- documentation/dev-manual/wic.rst | 2 +- documentation/ref-manual/system-requirements.rst | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst index 834fb13088..7d3a25b1f9 100644 --- a/documentation/dev-manual/start.rst +++ b/documentation/dev-manual/start.rst @@ -289,7 +289,7 @@ Project Build Host: as these releases are frequently tested against the Yocto Project and officially supported. For a list of the distributions under validation and their status, see the ":ref:`Supported Linux - Distributions `" + Distributions `" section in the Yocto Project Reference Manual and the wiki page at :yocto_wiki:`Distribution Support `. diff --git a/documentation/dev-manual/wic.rst b/documentation/dev-manual/wic.rst index 25180c5cb5..f794693c50 100644 --- a/documentation/dev-manual/wic.rst +++ b/documentation/dev-manual/wic.rst @@ -72,7 +72,7 @@ In order to use the Wic utility with the OpenEmbedded Build system, your system needs to meet the following requirements: - The Linux distribution on your development host must support the - Yocto Project. See the ":ref:`detailed-supported-distros`" + Yocto Project. See the ":ref:`system-requirements-supported-distros`" section in the Yocto Project Reference Manual for the list of distributions that support the Yocto Project. diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst index 1a6f7647b6..159f16fb8d 100644 --- a/documentation/ref-manual/system-requirements.rst +++ b/documentation/ref-manual/system-requirements.rst @@ -50,7 +50,7 @@ You will manage to build an image such as ``core-image-sato`` for the system with 4 CPU cores, but your builds will be much faster on a system with as much RAM and as many CPU cores as possible. -.. _detailed-supported-distros: +.. _system-requirements-supported-distros: Supported Linux Distributions ============================= From patchwork Tue Feb 27 14:01:23 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40146 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id AAEA8C54798 for ; Tue, 27 Feb 2024 14:01:51 +0000 (UTC) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx.groups.io with SMTP id smtpd.web11.12661.1709042501884276513 for ; Tue, 27 Feb 2024 06:01:42 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=UIdgZqhZ; spf=pass (domain: bootlin.com, ip: 217.70.183.196, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 713EEE000C; Tue, 27 Feb 2024 14:01:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042500; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6JK5gb1jES9Jb+UBxHrUr85C47ntva/MEU0jRsARWPg=; b=UIdgZqhZwBEl6zhx/ymdAXKIrVrFbf1iwstSsqaNsrmBm9xuiDE0EwAj9vszWxMF3s7EuI UdoCHVmCdwBDZeS2aYJsokFrxShBGBLXQ5xlEk5xbvTpQ/Lm4mCeLu0z5jiJnfN0yH2Ufe G4+MII+5i4T3rd4ZZFYj30dvDD6PNgUDGCcp2m8ZauNkJElq3FuqtJr8YqUbKHG2Gynabh VubbFgKtcJcFnVAMmpUdSaxoVSM31dheWck9LtRi7mWOGZ+MC19E5JLfcy2/lnAVQmLf1V MenNj1BbLNJ+a4PD3gH9Q+qlCqqRADLmd6ur5MaX5ojtb9HsO3UDitfK9JeURA== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker , Alexander Kanavin Subject: [kirkstone][PATCH 11/16] ref-manual/system-requirements.rst: recommend buildtools for not supported distros Date: Tue, 27 Feb 2024 15:01:23 +0100 Message-Id: <20240227140128.481522-12-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:51 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4901 From: Michael Opdenacker Also minor correction to supported distribution notes Signed-off-by: Michael Opdenacker Suggested-by: Alexander Kanavin --- Changes in V2: - Add reference to the section explaining how to get buildtools --- documentation/ref-manual/system-requirements.rst | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst index 159f16fb8d..79c40046b4 100644 --- a/documentation/ref-manual/system-requirements.rst +++ b/documentation/ref-manual/system-requirements.rst @@ -118,7 +118,13 @@ tested on former revisions of "&DISTRO_NAME;", but no longer are: has no plans to support rolling-releases or development distributions due to their constantly changing nature. We welcome patches and bug reports, but keep in mind that our priority is on - the supported platforms listed below. + the supported platforms listed above. + + - If your Linux distribution is not in the above list, we recommend to + get the :term:`buildtools` or :term:`buildtools-extended` tarballs + containing the host tools required by your Yocto Project release, + typically by running ``scripts/install-buildtools`` as explained in + the ":ref:`system-requirements-buildtools`" section. - You may use Windows Subsystem For Linux v2 to set up a build host using Windows 10, but validation is not performed against build From patchwork Tue Feb 27 14:01:24 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40152 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id E589EC54E5A for ; Tue, 27 Feb 2024 14:01:51 +0000 (UTC) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by mx.groups.io with SMTP id smtpd.web11.12663.1709042502326522593 for ; Tue, 27 Feb 2024 06:01:42 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=MmwdjvDl; spf=pass (domain: bootlin.com, ip: 217.70.183.199, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id CDA48FF808; Tue, 27 Feb 2024 14:01:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042501; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dqHLUzO6MG6pq3j/n7EG82gPWIYqfOs9BZqBkcx5+VA=; b=MmwdjvDlJI4kA4RDN3FA9RWzPOL1ATvJwLi5+E/XEZLLUsIKff+LYzarRK8Wo2tO2cSO9t mMaFbDClCfxm9nAIoh5+xuKYiHKGpKsLlUqbf2d4XrOjxObiiP823/bPm0rYG4nW7VjK6d mD0P1B938wQ4mSldTM4W+fr5cyYXR7205pYCIJyOwZRizewOKv84gmPPcXuEtFwc+owW5F WRdrOTMfI86duYM86ad4tEwjvHGDlrJP0JkvmYV0A9n0Jnx18PvAgKwfNlmYM3qiqmxUO2 z60B9nMFCEc01PtDv3B7N9ZKsuPvQhI3GJXi85yLiq3T2zBhfjzUNqovomscTg== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker , Quentin Schulz Subject: [kirkstone][PATCH 12/16] manuals: updates for building on Windows (WSL 2) Date: Tue, 27 Feb 2024 15:01:24 +0100 Message-Id: <20240227140128.481522-13-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:51 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4903 From: Michael Opdenacker - Use the Wikipedia naming scheme: WSL 2 instead of WSLv2 - Take into account Windows Server 2019 and 2022 which are supported too. - Improve some explanations Signed-off-by: Michael Opdenacker Reviewed-by: Quentin Schulz --- Changes in V2: - Now using "Windows 10 or later, or Windows Server 2019 or later" as suggested by Quentin Schulz. --- documentation/brief-yoctoprojectqs/index.rst | 17 ++--- documentation/dev-manual/start.rst | 72 +++++++++---------- documentation/overview-manual/yp-intro.rst | 17 ++--- .../ref-manual/system-requirements.rst | 10 +-- 4 files changed, 51 insertions(+), 65 deletions(-) diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst index 9eff13f583..f52b7fa0e0 100644 --- a/documentation/brief-yoctoprojectqs/index.rst +++ b/documentation/brief-yoctoprojectqs/index.rst @@ -25,18 +25,11 @@ build a reference embedded OS called Poky. in the Yocto Project Development Tasks Manual for more information. - - You may use Windows Subsystem For Linux v2 to set up a build host - using Windows 10. - - .. note:: - - The Yocto Project is not compatible with WSLv1, it is - compatible but not officially supported nor validated with - WSLv2, if you still decide to use WSL please upgrade to WSLv2. - - See the :ref:`dev-manual/start:setting up to use windows - subsystem for linux (wslv2)` section in the Yocto Project Development - Tasks Manual for more information. + - You may use version 2 of Windows Subsystem For Linux (WSL 2) to set + up a build host using Windows 10 or later, Windows Server 2019 or later. + See the :ref:`dev-manual/start:setting up to use windows subsystem for + linux (wsl 2)` section in the Yocto Project Development Tasks Manual + for more information. If you want more conceptual or background information on the Yocto Project, see the :doc:`/overview-manual/index`. diff --git a/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst index 7d3a25b1f9..7b6026cf42 100644 --- a/documentation/dev-manual/start.rst +++ b/documentation/dev-manual/start.rst @@ -254,16 +254,16 @@ development using the Yocto Project. Your build host can be a native Linux machine (recommended), it can be a machine (Linux, Mac, or Windows) that uses `CROPS `__, which leverages `Docker Containers `__ or it -can be a Windows machine capable of running Windows Subsystem For Linux -v2 (WSL). +can be a Windows machine capable of running version 2 of Windows Subsystem +For Linux (WSL 2). .. note:: - The Yocto Project is not compatible with - `Windows Subsystem for Linux v1 `__. - It is compatible but not officially supported nor validated with - WSLv2. If you still decide to use WSL please upgrade to - `WSLv2 `__. + The Yocto Project is not compatible with version 1 of + `Windows Subsystem for Linux `__. + It is compatible but neither officially supported nor validated with + WSL 2. If you still decide to use WSL please upgrade to + `WSL 2 `__. Once your build host is set up to use the Yocto Project, further steps are necessary depending on what you want to accomplish. See the @@ -434,35 +434,36 @@ the `Yocto Project BitBake `__ extension accordingly. -Setting Up to Use Windows Subsystem For Linux (WSLv2) +Setting Up to Use Windows Subsystem For Linux (WSL 2) ----------------------------------------------------- -With `Windows Subsystem for Linux -(WSLv2) `__, +With `Windows Subsystem for Linux (WSL 2) +`__, you can create a Yocto Project development environment that allows you to build on Windows. You can set up a Linux distribution inside Windows in which you can develop using the Yocto Project. -Follow these general steps to prepare a Windows machine using WSLv2 as +Follow these general steps to prepare a Windows machine using WSL 2 as your Yocto Project build host: -1. *Make sure your Windows 10 machine is capable of running WSLv2:* - WSLv2 is only available for Windows 10 builds > 18917. To check which - build version you are running, you may open a command prompt on - Windows and execute the command "ver". - :: +1. *Make sure your Windows machine is capable of running WSL 2:* + + While all Windows 11 and Windows Server 2022 builds support WSL 2, + the first versions of Windows 10 and Windows Server 2019 didn't. + Check the minimum build numbers for `Windows 10 + `__ + and for `Windows Server 2019 + `__. + + To check which build version you are running, you may open a command + prompt on Windows and execute the command "ver":: C:\Users\myuser> ver Microsoft Windows [Version 10.0.19041.153] - If your build is capable of running - WSLv2 you may continue, for more information on this subject or - instructions on how to upgrade to WSLv2 visit `Windows 10 - WSLv2 `__ - -2. *Install the Linux distribution of your choice inside Windows 10:* - Once you know your version of Windows 10 supports WSLv2, you can +2. *Install the Linux distribution of your choice inside WSL 2:* + Once you know your version of Windows supports WSL 2, you can install the distribution of your choice from the Microsoft Store. Open the Microsoft Store and search for Linux. While there are several Linux distributions available, the assumption is that your @@ -471,31 +472,28 @@ your Yocto Project build host: making your selection, simply click "Get" to download and install the distribution. -3. *Check your Linux distribution is using WSLv2:* Open a Windows +3. *Check which Linux distribution WSL 2 is using:* Open a Windows PowerShell and run:: C:\WINDOWS\system32> wsl -l -v NAME STATE VERSION *Ubuntu Running 2 - Note the version column which says the WSL version - being used by your distribution, on compatible systems, this can be - changed back at any point in time. + Note that WSL 2 supports running as many different Linux distributions + as you want to install. -4. *Optionally Orient Yourself on WSL:* If you are unfamiliar with WSL, - you can learn more here - +4. *Optionally Get Familiar with WSL:* You can learn more on https://docs.microsoft.com/en-us/windows/wsl/wsl2-about. 5. *Launch your WSL Distibution:* From the Windows start menu simply launch your WSL distribution just like any other application. -6. *Optimize your WSLv2 storage often:* Due to the way storage is - handled on WSLv2, the storage space used by the undelying Linux - distribution is not reflected immedately, and since bitbake heavily +6. *Optimize your WSL 2 storage often:* Due to the way storage is + handled on WSL 2, the storage space used by the underlying Linux + distribution is not reflected immediately, and since BitBake heavily uses storage, after several builds, you may be unaware you are - running out of space. WSLv2 uses a VHDX file for storage, this issue - can be easily avoided by manually optimizing this file often, this - can be done in the following way: + running out of space. As WSL 2 uses a VHDX file for storage, this issue + can be easily avoided by regularly optimizing this file in a manual way: 1. *Find the location of your VHDX file:* @@ -549,14 +547,14 @@ your Yocto Project build host: .. note:: - The current implementation of WSLv2 does not have out-of-the-box + The current implementation of WSL 2 does not have out-of-the-box access to external devices such as those connected through a USB port, but it automatically mounts your ``C:`` drive on ``/mnt/c/`` (and others), which you can use to share deploy artifacts to be later flashed on hardware through Windows, but your build directory should not reside inside this mountpoint. -Once you have WSLv2 set up, everything is in place to develop just as if +Once you have WSL 2 set up, everything is in place to develop just as if you were running on a native Linux machine. If you are going to use the Extensible SDK container, see the ":doc:`/sdk-manual/extensible`" Chapter in the Yocto Project Application Development and the Extensible Software Development diff --git a/documentation/overview-manual/yp-intro.rst b/documentation/overview-manual/yp-intro.rst index 3dc8ae5519..8683fb9ebd 100644 --- a/documentation/overview-manual/yp-intro.rst +++ b/documentation/overview-manual/yp-intro.rst @@ -596,20 +596,15 @@ Build Host runs, you have several choices. ":ref:`dev-manual/start:setting up to use cross platforms (crops)`" section in the Yocto Project Development Tasks Manual. -- *Windows Subsystem For Linux (WSLv2):* You may use Windows Subsystem - For Linux v2 to set up a Build Host using Windows 10. +- *Windows Subsystem For Linux (WSL 2):* You may use Windows Subsystem + For Linux version 2 to set up a Build Host using Windows 10 or later, + or Windows Server 2019 or later. - .. note:: - - The Yocto Project is not compatible with WSLv1, it is compatible - but not officially supported nor validated with WSLv2, if you - still decide to use WSL please upgrade to WSLv2. - - The Windows Subsystem For Linux allows Windows 10 to run a real Linux + The Windows Subsystem For Linux allows Windows to run a real Linux kernel inside of a lightweight virtual machine (VM). - For information on how to set up a Build Host with WSLv2, see the - ":ref:`dev-manual/start:setting up to use windows subsystem for linux (wslv2)`" + For information on how to set up a Build Host with WSL 2, see the + ":ref:`dev-manual/start:setting up to use windows subsystem for linux (wsl 2)`" section in the Yocto Project Development Tasks Manual. - *Toaster:* Regardless of what your Build Host is running, you can use diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst index 79c40046b4..8499c1b1e8 100644 --- a/documentation/ref-manual/system-requirements.rst +++ b/documentation/ref-manual/system-requirements.rst @@ -127,12 +127,12 @@ tested on former revisions of "&DISTRO_NAME;", but no longer are: the ":ref:`system-requirements-buildtools`" section. - You may use Windows Subsystem For Linux v2 to set up a build host - using Windows 10, but validation is not performed against build - hosts using WSLv2. + using Windows 10 or later, or Windows Server 2019 or later, but validation + is not performed against build hosts using WSL 2. - - The Yocto Project is not compatible with WSLv1, it is - compatible but not officially supported nor validated with - WSLv2, if you still decide to use WSL please upgrade to WSLv2. + See the + :ref:`dev-manual/start:setting up to use windows subsystem for linux (wsl 2)` + section in the Yocto Project Development Tasks Manual for more information. - If you encounter problems, please go to :yocto_bugs:`Yocto Project Bugzilla <>` and submit a bug. We are From patchwork Tue Feb 27 14:01:25 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40151 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id D32F0C54E59 for ; Tue, 27 Feb 2024 14:01:51 +0000 (UTC) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx.groups.io with SMTP id smtpd.web11.12665.1709042502687453718 for ; Tue, 27 Feb 2024 06:01:43 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=obzXHiqO; spf=pass (domain: bootlin.com, ip: 217.70.183.196, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 3ECCEE0014; Tue, 27 Feb 2024 14:01:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042501; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=js1fErLrJGGSE7dFQmISvrvV6z8jwMudw02kJDWYt0Q=; b=obzXHiqOd+DKJRWU3SrWbBW6wXsNfCIt+hUeD8AO435/lAf+g2Kq8rpw7Iixl2XSUH5eNJ LrmqwdrCGSEeg6SQutnSzNZGMyqxO5NZoH00xufFIdAWLXniqhJpmJdMmQUpSH+zSTSHrm uysULASSA0r2wJvWVxoNdV9oFvBL0LEQgdmYOtp9yO9n8W0DqAVSF6XtTYmbz68IMbaoDx Y4EEeP/zgJlTf/7ZD6IptsYhnOrq8qloI2j1Mk3w54nxD6c+TUNxkF1+7YjrWKZeB2yrsQ 6QTUKggcvpxDGM7X0Kg4IVa9mI33AmWp3pOW7/xBhI/rTVIF6HgJHzf6gpvT2Q== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker Subject: [kirkstone][PATCH 13/16] ref-manual: system-requirements.rst: simplify supported distro requirements Date: Tue, 27 Feb 2024 15:01:25 +0100 Message-Id: <20240227140128.481522-14-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:51 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4904 From: Michael Opdenacker - This allows to continue sharing the updated Ubuntu/Debian requirements with the brief-yoctoprojectqs/index.rst without indentation mismatches (caused by using the same macro in two different contexts: in direct text and in a bullet list). - Update poky.yaml.in to adapt the number of spaces at the beginning of lines. - brief-yoctoprojectqs/index.rst: fix bad number of spaces before quote block. Signed-off-by: Michael Opdenacker --- documentation/brief-yoctoprojectqs/index.rst | 6 +- documentation/poky.yaml.in | 25 ++-- .../ref-manual/system-requirements.rst | 120 ++++++------------ 3 files changed, 48 insertions(+), 103 deletions(-) diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst index f52b7fa0e0..db17437aa8 100644 --- a/documentation/brief-yoctoprojectqs/index.rst +++ b/documentation/brief-yoctoprojectqs/index.rst @@ -76,11 +76,9 @@ Build Host Packages You must install essential host packages on your build host. The following command installs the host packages based on an Ubuntu -distribution: +distribution:: -.. code-block:: shell - - $ sudo apt install &UBUNTU_HOST_PACKAGES_ESSENTIAL; + $ sudo apt install &UBUNTU_HOST_PACKAGES_ESSENTIAL; .. note:: diff --git a/documentation/poky.yaml.in b/documentation/poky.yaml.in index 8c6549d571..b9cdd844e4 100644 --- a/documentation/poky.yaml.in +++ b/documentation/poky.yaml.in @@ -13,7 +13,8 @@ YOCTO_RELEASE_DL_URL : "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;" UBUNTU_HOST_PACKAGES_ESSENTIAL : "gawk wget git diffstat unzip texinfo gcc \ build-essential chrpath socat cpio python3 python3-pip python3-pexpect \ xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \ - pylint3 xterm python3-subunit mesa-common-dev zstd liblz4-tool" + python3-subunit mesa-common-dev zstd liblz4-tool file locales + \n\ $ sudo locale-gen en_US.UTF-8" FEDORA_HOST_PACKAGES_ESSENTIAL : "gawk make wget tar bzip2 gzip python3 unzip perl patch \ diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \ ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue perl-bignum socat \ @@ -22,20 +23,14 @@ FEDORA_HOST_PACKAGES_ESSENTIAL : "gawk make wget tar bzip2 gzip python3 unzip pe perl-File-Copy perl-locale zstd lz4" OPENSUSE_HOST_PACKAGES_ESSENTIAL : "python gcc gcc-c++ git chrpath make wget python-xml \ diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip \ - python3-pexpect xz which python3-Jinja2 Mesa-libEGL1 libSDL-devel xterm rpcgen Mesa-dri-devel \ - zstd lz4 - \n\ $ sudo pip3 install GitPython" -CENTOS7_HOST_PACKAGES_ESSENTIAL : "-y epel-release - \n\ $ sudo yum makecache - \n\ $ sudo yum install gawk make wget tar bzip2 gzip python3 unzip perl patch \ - diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath socat \ - perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python3-pip xz \ - which SDL-devel xterm mesa-libGL-devel zstd lz4 - \n\ $ sudo pip3 install GitPython jinja2" -CENTOS8_HOST_PACKAGES_ESSENTIAL : "-y epel-release - \n\ $ sudo dnf config-manager --set-enabled PowerTools - \n\ $ sudo dnf makecache - \n\ $ sudo dnf install gawk make wget tar bzip2 gzip python3 unzip perl patch \ + python3-pexpect xz which python3-Jinja2 Mesa-libEGL1 libSDL-devel rpcgen Mesa-dri-devel \ + zstd lz4 bzip2 gzip hostname + \n\ $ sudo pip3 install GitPython" +ALMALINUX_HOST_PACKAGES_ESSENTIAL : "-y epel-release + \n\ $ sudo yum install dnf-plugins-core + \n\ $ sudo dnf config-manager --set-enabled crb + \n\ $ sudo dnf makecache + \n\ $ sudo dnf install gawk make wget tar bzip2 gzip python3 unzip perl patch \ diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath ccache \ socat perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python3-pip \ python3-GitPython python3-jinja2 python3-pexpect xz which SDL-devel xterm \ diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst index 8499c1b1e8..c5fe4da036 100644 --- a/documentation/ref-manual/system-requirements.rst +++ b/documentation/ref-manual/system-requirements.rst @@ -155,8 +155,10 @@ function. Ubuntu and Debian ----------------- -Here are the required packages by function given a -supported Ubuntu or Debian Linux distribution: +Here are the packages needed to build an image on a headless system +with a supported Ubuntu or Debian Linux distribution:: + + $ sudo apt install &UBUNTU_HOST_PACKAGES_ESSENTIAL; .. note:: @@ -168,21 +170,10 @@ supported Ubuntu or Debian Linux distribution: $ sudo apt build-dep qemu $ sudo apt remove oss4-dev - - For Debian-8, ``python3-git`` and ``pylint3`` are no longer - available via ``apt``. - :: - - $ sudo pip3 install GitPython pylint==1.9.5 - -- *Essentials:* Packages needed to build an image on a headless system:: +Here are the packages needed to build Project documentation manuals:: - $ sudo apt install &UBUNTU_HOST_PACKAGES_ESSENTIAL; - -- *Documentation:* Packages needed if you are going to build out the - Yocto Project documentation manuals:: - - $ sudo apt install make python3-pip - &PIP3_HOST_PACKAGES_DOC; + $ sudo apt install make python3-pip inkscape texlive-latex-extra + &PIP3_HOST_PACKAGES_DOC; .. note:: @@ -193,94 +184,55 @@ supported Ubuntu or Debian Linux distribution: Fedora Packages --------------- -Here are the required packages by function given a -supported Fedora Linux distribution: - -- *Essentials:* Packages needed to build an image for a headless - system:: +Here are the packages needed to build an image on a headless system +with a supported Fedora Linux distribution:: - $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL; + $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL; -- *Documentation:* Packages needed if you are going to build out the - Yocto Project documentation manuals:: +Here are the packages needed to build Project documentation manuals:: - $ sudo dnf install make python3-pip which - &PIP3_HOST_PACKAGES_DOC; + $ sudo dnf install make python3-pip which inkscape texlive-fncychap + &PIP3_HOST_PACKAGES_DOC; openSUSE Packages ----------------- -Here are the required packages by function given a -supported openSUSE Linux distribution: - -- *Essentials:* Packages needed to build an image for a headless - system:: - - $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL; - -- *Documentation:* Packages needed if you are going to build out the - Yocto Project documentation manuals:: - - $ sudo zypper install make python3-pip which - &PIP3_HOST_PACKAGES_DOC; - - -CentOS-7 Packages ------------------ - -Here are the required packages by function given a -supported CentOS-7 Linux distribution: +Here are the packages needed to build an image on a headless system +with a supported openSUSE distribution:: -- *Essentials:* Packages needed to build an image for a headless - system:: + $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL; - $ sudo yum install &CENTOS7_HOST_PACKAGES_ESSENTIAL; +Here are the packages needed to build Project documentation manuals:: - .. note:: - - - Extra Packages for Enterprise Linux (i.e. ``epel-release``) is - a collection of packages from Fedora built on RHEL/CentOS for - easy installation of packages not included in enterprise Linux - by default. You need to install these packages separately. + $ sudo zypper install make python3-pip which inkscape texlive-fncychap + &PIP3_HOST_PACKAGES_DOC; - - The ``makecache`` command consumes additional Metadata from - ``epel-release``. -- *Documentation:* Packages needed if you are going to build out the - Yocto Project documentation manuals:: +AlmaLinux Packages +------------------ - $ sudo yum install make python3-pip which - &PIP3_HOST_PACKAGES_DOC; +Here are the packages needed to build an image on a headless system +with a supported AlmaLinux distribution:: -CentOS-8 Packages ------------------ + $ sudo dnf install &ALMALINUX8_HOST_PACKAGES_ESSENTIAL; -Here are the required packages by function given a -supported CentOS-8 Linux distribution: - -- *Essentials:* Packages needed to build an image for a headless - system:: - - $ sudo dnf install &CENTOS8_HOST_PACKAGES_ESSENTIAL; - - .. note:: +.. note:: - - Extra Packages for Enterprise Linux (i.e. ``epel-release``) is - a collection of packages from Fedora built on RHEL/CentOS for - easy installation of packages not included in enterprise Linux - by default. You need to install these packages separately. + - Extra Packages for Enterprise Linux (i.e. ``epel-release``) is + a collection of packages from Fedora built on RHEL/CentOS for + easy installation of packages not included in enterprise Linux + by default. You need to install these packages separately. - - The ``PowerTools`` repo provides additional packages such as - ``rpcgen`` and ``texinfo``. + - The ``PowerTools/CRB`` repo provides additional packages such as + ``rpcgen`` and ``texinfo``. - - The ``makecache`` command consumes additional Metadata from - ``epel-release``. + - The ``makecache`` command consumes additional Metadata from + ``epel-release``. -- *Documentation:* Packages needed if you are going to build out the - Yocto Project documentation manuals:: +Here are the packages needed to build Project documentation manuals:: - $ sudo dnf install make python3-pip which - &PIP3_HOST_PACKAGES_DOC; + $ sudo dnf install make python3-pip which inkscape texlive-fncychap + &PIP3_HOST_PACKAGES_DOC; .. _system-requirements-buildtools: From patchwork Tue Feb 27 14:01:26 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40148 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id B70CCC5478C for ; Tue, 27 Feb 2024 14:01:51 +0000 (UTC) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx.groups.io with SMTP id smtpd.web11.12668.1709042503113617671 for ; Tue, 27 Feb 2024 06:01:43 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=Rhfwq3K+; spf=pass (domain: bootlin.com, ip: 217.70.183.197, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 97D781C0004; Tue, 27 Feb 2024 14:01:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042501; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RNQpFvv9TXMwF8IpH0Auph33zThEGXgds6Zy19ovh58=; b=Rhfwq3K+oXGEuIMcYaCGhMBJ2tbr7Mk5YKcEpuq8Iq/pXOW75a7ESrmtARFunfiCfzyG9U zvvoaSBbI2Utv/dwx3dl6lpcQzQHKTkw50RgOx6w4S1POYjcs/vP/gb8Wdq6tXgab8H04F k2xMDPrq6710/NtXuUh0J/BBxDRlMYHqnGks8Dv5ZXc6n19Z6E+K4knaCfFyHfOS9Bv3jM V86kzQWVESDXBvB0KpKylZlxA/1vZHfkkx/9/UrE/YL2g+I20jtmqDn5lrQneQDae8aKxN n7uoIiSflNGWBVuxIBW0L296pCIKCdQ7qNqkPx1Ygl7OTKrGiyupqYd2vmvqpA== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker , mhagans@skyviewsat.com Subject: [kirkstone][PATCH 14/16] ref-manual: system-requirements: update packages to build docs Date: Tue, 27 Feb 2024 15:01:26 +0100 Message-Id: <20240227140128.481522-15-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:51 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4905 From: Michael Opdenacker - "git" is now required to run "set_versions.py" - Fix Ubuntu / Debian packages. The previous instructions didn't run on Debian 12 Tested on Ubuntu 22.04 and Debian 12. Reported on https://lists.yoctoproject.org/g/docs/message/4789 Signed-off-by: Michael Opdenacker Reported-by: --- documentation/ref-manual/system-requirements.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst index c5fe4da036..391ba95c42 100644 --- a/documentation/ref-manual/system-requirements.rst +++ b/documentation/ref-manual/system-requirements.rst @@ -172,8 +172,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 .. note:: @@ -191,7 +191,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 @@ -204,7 +204,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; @@ -231,7 +231,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: From patchwork Tue Feb 27 14:01:27 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40149 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id C73C6C54E51 for ; Tue, 27 Feb 2024 14:01:51 +0000 (UTC) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by mx.groups.io with SMTP id smtpd.web11.12669.1709042503461766719 for ; Tue, 27 Feb 2024 06:01:43 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=ApG5W1Fd; spf=pass (domain: bootlin.com, ip: 217.70.183.199, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 06218FF804; Tue, 27 Feb 2024 14:01:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042502; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=goi+Q68SK2vCBmOtPsKzKdDQ6AJXObdkaZKdcNqnl4A=; b=ApG5W1FdMia/31eBB7o8Qw/Ne9kbaftzQ6tkk3HJzcTH7qIKwech+rrqD7/tnRXZ5S3/9x gjfIg0+phZbUOf+L8Sid7X41SLAGAU0XX3ShkpuF7C8sDnyG8KpfVeF2N1eB3zsgx9rkmU 2ELUhMeGsjurgvAW5iehBdJ+F4llyZ6mvOjE0CBVqM/hC7ZUR5ceSk+Uii+qDnis51TKZK gQi97ik0DyxhO2NLmE2RuUnEdZ74gWqz2QPyAttlZDy1Wju2CQORMhATPknMouxVAtEfGS mLiPrirZ7aUSBAbc0JGFdKamqiSeJEj2jTH1dd+NmmZdxENBgn8QFe9IZUO3IQ== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker Subject: [kirkstone][PATCH 15/16] ref-manual: system-requirements.rst: fix AlmaLinux variable name Date: Tue, 27 Feb 2024 15:01:27 +0100 Message-Id: <20240227140128.481522-16-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:51 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4906 From: Michael Opdenacker Signed-off-by: Michael Opdenacker --- documentation/ref-manual/system-requirements.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst index 391ba95c42..41f8077d60 100644 --- a/documentation/ref-manual/system-requirements.rst +++ b/documentation/ref-manual/system-requirements.rst @@ -214,7 +214,7 @@ AlmaLinux Packages Here are the packages needed to build an image on a headless system with a supported AlmaLinux distribution:: - $ sudo dnf install &ALMALINUX8_HOST_PACKAGES_ESSENTIAL; + $ sudo dnf install &ALMALINUX_HOST_PACKAGES_ESSENTIAL; .. note:: From patchwork Tue Feb 27 14:01:28 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Opdenacker X-Patchwork-Id: 40147 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8E18C54E55 for ; Tue, 27 Feb 2024 14:01:51 +0000 (UTC) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx.groups.io with SMTP id smtpd.web10.12835.1709042503833579326 for ; Tue, 27 Feb 2024 06:01:44 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=Ykfh5/Dm; spf=pass (domain: bootlin.com, ip: 217.70.183.197, mailfrom: michael.opdenacker@bootlin.com) Received: by mail.gandi.net (Postfix) with ESMTPSA id 630441C000D; Tue, 27 Feb 2024 14:01:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1709042502; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Req8qhJCUKJBLt4gmlceJnQCG1fZxDf++joCYlmeCUs=; b=Ykfh5/DmJtewSzwseYBTmeQxw5E5x64lP3w7wxc8wjK257o4gf+QFzJpOsIFJBpWtO+I5i hMsaHMkUfIl3KdrKfkml9guVqeepyy8C/6iHBKhXypCdKF7x1llrUlzZrpkrtm08mOR1t0 PHUqvoraKnlf2yRE/5zxhW3jL2iVLH4SU692O2p8BrB02IvPDLcIDr3uR7b4tGXasD43qF 9VORGvJBT614dFpndXBjITsXG3rkt7aNaTZfsBVUrm+Fr1r7ABc0TkMip3VhHBWoEbJuak yIiOrCqLCSdGXa0482aLYOPnul+Oom0STQzKbdavsQOKvIAdVO5Wo4Jm3uwMzQ== From: michael.opdenacker@bootlin.com To: docs@lists.yoctoproject.org Cc: Michael Opdenacker Subject: [kirkstone][PATCH 16/16] ref-manual: system-requirements: remove outdated note Date: Tue, 27 Feb 2024 15:01:28 +0100 Message-Id: <20240227140128.481522-17-michael.opdenacker@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240227140128.481522-1-michael.opdenacker@bootlin.com> References: <20240227140128.481522-1-michael.opdenacker@bootlin.com> MIME-Version: 1.0 X-GND-Sasl: michael.opdenacker@bootlin.com List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Tue, 27 Feb 2024 14:01:51 -0000 X-Groupsio-URL: https://lists.yoctoproject.org/g/docs/message/4907 From: Michael Opdenacker To align this document with the version in the master branch Signed-off-by: Michael Opdenacker --- documentation/ref-manual/system-requirements.rst | 6 ------ 1 file changed, 6 deletions(-) diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst index 41f8077d60..b45c863005 100644 --- a/documentation/ref-manual/system-requirements.rst +++ b/documentation/ref-manual/system-requirements.rst @@ -175,12 +175,6 @@ Here are the packages needed to build Project documentation manuals:: $ sudo apt install git make inkscape texlive-latex-extra $ sudo apt install sphinx python3-saneyaml python3-sphinx-rtd-theme - .. note:: - - It is currently not possible to build out documentation from Debian 8 - (Jessie) because of outdated ``pip3`` and ``python3``. ``python3-sphinx`` - is too outdated. - Fedora Packages ---------------