diff options
Diffstat (limited to 'poky/documentation')
21 files changed, 207 insertions, 108 deletions
diff --git a/poky/documentation/README b/poky/documentation/README index f9e803a28..fad19683c 100644 --- a/poky/documentation/README +++ b/poky/documentation/README @@ -328,10 +328,19 @@ The sphinx.ext.intersphinx extension is enabled by default so that we can cross reference content from other Sphinx based documentation projects, such as the BitBake manual. -References to the bitbake manual can be done like this: +References to the BitBake manual can be done: + - With a specific description instead of the section name: + :ref:`Azure Storage fetcher (az://) <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` + - With the section name: + ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-intro:usage and syntax` option + - Linking to the entire BitBake manual: + :doc:`BitBake User Manual <bitbake:index>` + +Note that a reference to a variable (:term:`VARIABLE`) automatically points to +the BitBake manual if the variable is not described in the Reference Manual's Variable Glossary. +However, if you need to bypass this, you can explicitely refer to a description in the +BitBake manual as follows: - See the ":ref:`-D <bitbake:bitbake-user-manual/bitbake-user-manual-intro:usage and syntax>`" option -or :term:`bitbake:BB_NUMBER_PARSE_THREADS` Submitting documentation changes diff --git a/poky/documentation/brief-yoctoprojectqs/index.rst b/poky/documentation/brief-yoctoprojectqs/index.rst index b92b0d33d..74167befa 100644 --- a/poky/documentation/brief-yoctoprojectqs/index.rst +++ b/poky/documentation/brief-yoctoprojectqs/index.rst @@ -207,7 +207,7 @@ an entire Linux distribution, including the toolchain, from source. https://docs.yoctoproject.org For more information about OpenEmbedded see their website: - http://www.openembedded.org/ + https://www.openembedded.org/ ### Shell environment set up for builds. ### @@ -215,12 +215,19 @@ an entire Linux distribution, including the toolchain, from source. Common targets are: core-image-minimal + core-image-full-cmdline core-image-sato + core-image-weston meta-toolchain meta-ide-support You can also run generated QEMU images with a command like 'runqemu qemux86-64' + Other commonly useful commands are: + - 'devtool' and 'recipetool' handle common recipe tasks + - 'bitbake-layers' handles common layer tasks + - 'oe-pkgdata-util' handles common target package tasks + Among other things, the script creates the :term:`Build Directory`, which is ``build`` in this case and is located in the :term:`Source Directory`. After the script runs, your current working directory is set to the Build @@ -260,8 +267,9 @@ an entire Linux distribution, including the toolchain, from source. For information on using the ``bitbake`` command, see the :ref:`overview-manual/concepts:bitbake` section in the Yocto Project Overview and - Concepts Manual, or see the ":ref:`BitBake Command - <bitbake:bitbake-user-manual/bitbake-user-manual-intro:the bitbake command>`" section in the BitBake User Manual. + Concepts Manual, or see + :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-intro:the bitbake command` + in the BitBake User Manual. #. **Simulate Your Image Using QEMU:** Once this particular image is built, you can start QEMU, which is a Quick EMUlator that ships with diff --git a/poky/documentation/dev-manual/common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst index 2af289617..7fa0df4d3 100644 --- a/poky/documentation/dev-manual/common-tasks.rst +++ b/poky/documentation/dev-manual/common-tasks.rst @@ -872,7 +872,7 @@ a recipe and using :term:`EXTRA_IMAGE_FEATURES` from within your :term:`Build Directory`. To understand how these features work, the best reference is -``meta/classes/core-image.bbclass``. This class lists out the available +``meta/classes/image.bbclass``. This class lists out the available :term:`IMAGE_FEATURES` of which most map to package groups while some, such as ``debug-tweaks`` and ``read-only-rootfs``, resolve as general configuration settings. @@ -4384,7 +4384,7 @@ directory: variable, inherit the :ref:`own-mirrors <ref-classes-own-mirrors>` class, and use the - :term:`bitbake:BB_NO_NETWORK` + :term:`BB_NO_NETWORK` variable to your ``local.conf``. :: @@ -4457,7 +4457,7 @@ variable for more information: - :term:`BB_NUMBER_THREADS`: The maximum number of threads BitBake simultaneously executes. -- :term:`bitbake:BB_NUMBER_PARSE_THREADS`: +- :term:`BB_NUMBER_PARSE_THREADS`: The number of threads BitBake uses during parsing. - :term:`PARALLEL_MAKE`: Extra @@ -7288,7 +7288,8 @@ The ``devtool edit-recipe`` command lets you take a look at the recipe:: npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \ " S = "${WORKDIR}/npm" - inherit npm LICENSE_${PN} = "MIT" + inherit npm + LICENSE_${PN} = "MIT" LICENSE_${PN}-accepts = "MIT" LICENSE_${PN}-array-flatten = "MIT" ... @@ -9121,7 +9122,7 @@ BitBake has determined by doing the following: The output of ``bitbake-dumpsig`` also includes the value each variable had, a list of dependencies for each variable, and - :term:`bitbake:BB_HASHBASE_WHITELIST` + :term:`BB_HASHBASE_WHITELIST` information. There is also a ``bitbake-diffsigs`` command for comparing two @@ -9358,7 +9359,7 @@ log to ``${T}/log.do_``\ `task`, and can also log to standard output - ``bb.debug(level, msg)``: Writes "DEBUG: msg" to the log. Also logs to stdout if the log level is greater than or equal to - level. See the ":ref:`-D <bitbake:bitbake-user-manual/bitbake-user-manual-intro:usage and syntax>`" option + level. See the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-intro:usage and syntax`" option in the BitBake User Manual for more information. - ``bb.warn(msg)``: Writes "WARNING: msg" to the log while also @@ -10528,6 +10529,9 @@ follows: 1. *Identify the bug or CVE to be fixed:* This information should be collected so that it can be included in your submission. + See :ref:`dev-manual/common-tasks:checking for vulnerabilities` + for details about CVE tracking. + 2. *Check if the fix is already present in the master branch:* This will result in the most straightforward path into the stable branch for the fix. @@ -10928,7 +10932,7 @@ concerned with GPL code as identified by running the following script: p=${p%-*} # Only archive GPL packages (update *GPL* regex for your license check) numfiles=`ls tmp/deploy/licenses/$p/*GPL* 2> /dev/null | wc -l` - if [ $numfiles -gt 1 ]; then + if [ $numfiles -ge 1 ]; then echo Archiving $p mkdir -p $src_release_dir/$p/source cp $d/* $src_release_dir/$p/source 2> /dev/null @@ -11090,6 +11094,48 @@ the license from the fetched source:: NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt" +Checking for Vulnerabilities +============================ + +Vulnerabilities in images +------------------------- + +The Yocto Project has an infrastructure to track and address unfixed +known security vulnerabilities, as tracked by the public +`Common Vulnerabilities and Exposures (CVE) <https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures>`__ +database. + +To know which packages are vulnerable to known security vulnerabilities, +add the following setting to your configuration:: + + INHERIT += "cve-check" + +This way, at build time, BitBake will warn you about known CVEs +as in the example below:: + + WARNING: flex-2.6.4-r0 do_cve_check: Found unpatched CVE (CVE-2019-6293), for more information check /poky/build/tmp/work/core2-64-poky-linux/flex/2.6.4-r0/temp/cve.log + WARNING: libarchive-3.5.1-r0 do_cve_check: Found unpatched CVE (CVE-2021-36976), for more information check /poky/build/tmp/work/core2-64-poky-linux/libarchive/3.5.1-r0/temp/cve.log + +It is also possible to check the CVE status of individual packages as follows:: + + bitbake -c cve_check flex libarchive + +Note that OpenEmbedded-Core keeps a list of known unfixed CVE issues which can +be ignored. You can pass this list to the check as follows:: + + bitbake -c cve_check libarchive -R conf/distro/include/cve-extra-exclusions.inc + +Enabling vulnerabily tracking in recipes +---------------------------------------- + +The :term:`CVE_PRODUCT` variable defines the name used to match the recipe name +against the name in the upstream `NIST CVE database <https://nvd.nist.gov/>`__. + +The CVE database is stored in :term:`DL_DIR` and can be inspected using +``sqlite3`` command as follows:: + + sqlite3 downloads/CVE_CHECK/nvdcve_1.1.db .dump | grep CVE-2021-37462 + Using the Error Reporting Tool ============================== diff --git a/poky/documentation/migration-guides/index.rst b/poky/documentation/migration-guides/index.rst index 6304e6318..287b55319 100644 --- a/poky/documentation/migration-guides/index.rst +++ b/poky/documentation/migration-guides/index.rst @@ -12,6 +12,7 @@ to move to one release of the Yocto Project from the previous one. .. toctree:: migration-general + migration-3.4 migration-3.3 migration-3.2 migration-3.1 diff --git a/poky/documentation/migration-guides/migration-2.4.rst b/poky/documentation/migration-guides/migration-2.4.rst index cab81356d..ae1a212b5 100644 --- a/poky/documentation/migration-guides/migration-2.4.rst +++ b/poky/documentation/migration-guides/migration-2.4.rst @@ -286,8 +286,8 @@ The following are additional changes: - BitBake fires multiple "BuildStarted" events when multiconfig is enabled (one per configuration). For more information, see the - ":ref:`Events <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:events>`" section in the BitBake User - Manual. + ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:events`" + section in the BitBake User Manual. - By default, the ``security_flags.inc`` file sets a :term:`GCCPIE` variable with an option to enable diff --git a/poky/documentation/migration-guides/migration-3.0.rst b/poky/documentation/migration-guides/migration-3.0.rst index 20c7026e8..9a5f5714b 100644 --- a/poky/documentation/migration-guides/migration-3.0.rst +++ b/poky/documentation/migration-guides/migration-3.0.rst @@ -194,7 +194,7 @@ The following BitBake changes have occurred. scripts that handles these two events need to be updated. - The arguments passed to functions used with - :term:`bitbake:BB_HASHCHECK_FUNCTION` + :term:`BB_HASHCHECK_FUNCTION` have changed. If you are using your own custom hash check function, see :yocto_git:`/poky/commit/?id=40a5e193c4ba45c928fccd899415ea56b5417725` for details. diff --git a/poky/documentation/migration-guides/migration-3.4.rst b/poky/documentation/migration-guides/migration-3.4.rst new file mode 100644 index 000000000..6fa1ab20c --- /dev/null +++ b/poky/documentation/migration-guides/migration-3.4.rst @@ -0,0 +1,76 @@ +Release 3.4 (honister) +====================== + +This section provides migration information for moving to the Yocto +Project 3.4 Release (codename "honister") from the prior release. + +Override syntax changes +----------------------- + +This release requires changes to the metadata to indicate where overrides are +being used in variable key names. This is done with the ``:`` character replacing +the use of ``_`` previously. This means that an entry like:: + + SRC_URI_qemux86 = "file://somefile" + +becomes:: + + SRC_URI:qemux86 = "file://somefile" + +since ``qemux86`` is an override. This applies to any use of override syntax so:: + + SRC_URI_append = " file://somefile" + SRC_URI_append_qemux86 = " file://somefile2" + SRC_URI_remove_qemux86-64 = " file://somefile3" + SRC_URI_prepend_qemuarm = "file://somefile4 " + FILES_${PN}-ptest = "${bindir}/xyz" + IMAGE_CMD_tar = "tar" + BASE_LIB_tune-cortexa76 = "lib" + SRCREV_pn-bash = "abc" + BB_TASK_NICE_LEVEL_task-testimage = '0' + +becomes:: + + SRC_URI:append = " file://somefile" + SRC_URI:append:qemux86 = " file://somefile2" + SRC_URI:remove:qemux86-64 = " file://somefile3" + SRC_URI:prepend:qemuarm = "file://somefile4 " + FILES:${PN}-ptest = "${bindir}/xyz" + IMAGE_CMD:tar = "tar" + BASE_LIB:tune-cortexa76 = "lib" + SRCREV:pn-bash = "abc" + BB_TASK_NICE_LEVEL:task-testimage = '0' + +This also applies to +:ref:`variable queries to the datastore <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:functions for accessing datastore variables>`, +for example using ``getVar`` and similar so ``d.getVar("RDEPENDS_${PN}")`` +becomes ``d.getVar("RDEPENDS:${PN}")``. + +Whilst some of these are fairly obvious such as :term:`MACHINE` and :term:`DISTRO` +overrides, some are less obvious, for example the packaging variables such as +:term:`RDEPENDS`, :term:`FILES` and so on taking package names (e.g. ``${PN}``, +``${PN}-ptest``) as overrides. These overrides are not always in +:term:`OVERRIDES` but applied conditionally in specific contexts +such as packaging. ``task-<taskname>`` is another context specific override, the +context being specific tasks in that case. Tune overrides are another special +case where some code does use them as overrides but some does not. We plan to try +and make the tune code use overrides more consistently in the future. + +To help with migration of layers there is a script in OE-Core. Once configured +with the overrides used by a layer, this can be run as:: + + <oe-core>/scripts/contrib/convert-overrides.py <layerdir> + +.. note:: + + Please read the notes in the script as it isn't entirely automatic and it isn't + expected to handle every case. In particular, it needs to be told which overrides + the layer uses (usually machine and distro names/overrides) and the result should + be carefully checked since it can be a little enthusiastic and will convert + references to ``_append``, ``_remove`` and ``_prepend`` in function and variables names. + +For reference, this conversion is important as it allows BitBake to know what is +an override and what is not. This should allow us to proceed with other syntax +improvements and simplifications for usability. It also means bitbake no longer +has to guess and maintain large lookup lists just in case ``functionname`` in +``my_functionname`` is an override and this should improve efficiency. diff --git a/poky/documentation/overview-manual/concepts.rst b/poky/documentation/overview-manual/concepts.rst index 1e5f0f903..4f8e6cb04 100644 --- a/poky/documentation/overview-manual/concepts.rst +++ b/poky/documentation/overview-manual/concepts.rst @@ -74,7 +74,7 @@ versions of ``matchbox-desktop`` might exist. BitBake chooses the one selected by the distribution configuration. You can get more details about how BitBake chooses between different target versions and providers in the -":ref:`Preferences <bitbake:bitbake-user-manual/bitbake-user-manual-execution:preferences>`" section +":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:preferences`" section of the BitBake User Manual. BitBake also tries to execute any dependent tasks first. So for example, @@ -584,7 +584,7 @@ Source Control Managers (Optional) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Another place from which the build system can get source files is with -:ref:`fetchers <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` employing various Source +:ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers` employing various Source Control Managers (SCMs) such as Git or Subversion. In such cases, a repository is cloned or checked out. The :ref:`ref-tasks-fetch` task inside @@ -1250,11 +1250,9 @@ download or setscene task fails, the build system then tries to install dependencies, such as the compiler, from the cache. The availability of objects in the sstate cache is handled by the -function specified by the -:term:`bitbake:BB_HASHCHECK_FUNCTION` +function specified by the :term:`BB_HASHCHECK_FUNCTION` variable and returns a list of available objects. The function specified -by the -:term:`bitbake:BB_SETSCENE_DEPVALID` +by the :term:`BB_SETSCENE_DEPVALID` variable is the function that determines whether a given dependency needs to be followed, and whether for any given relationship the function needs to be passed. The function returns a True or False value. @@ -1863,7 +1861,7 @@ The following list explains the previous example: through the shared state cache if possible. If the task was accelerated, ``sstate_setscene()`` returns True. Otherwise, it returns False, and the normal ``do_deploy`` task runs. For more - information, see the ":ref:`setscene <bitbake:bitbake-user-manual/bitbake-user-manual-execution:setscene>`" + information, see the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:setscene`" section in the BitBake User Manual. - The ``do_deploy[dirs] = "${DEPLOYDIR} ${B}"`` line creates diff --git a/poky/documentation/poky.yaml b/poky/documentation/poky.yaml index 3bfc35b6f..19441f099 100644 --- a/poky/documentation/poky.yaml +++ b/poky/documentation/poky.yaml @@ -1,12 +1,12 @@ -DISTRO : "3.3.1" +DISTRO : "3.3.2" DISTRO_NAME_NO_CAP : "hardknott" DISTRO_NAME : "Hardknott" DISTRO_NAME_NO_CAP_MINUS_ONE : "gatesgarth" DISTRO_NAME_NO_CAP_LTS : "dunfell" -YOCTO_DOC_VERSION : "3.3.1" +YOCTO_DOC_VERSION : "3.3.2" YOCTO_DOC_VERSION_MINUS_ONE : "3.2.4" -DISTRO_REL_TAG : "yocto-3.3.1" -POKYVERSION : "25.0.1" +DISTRO_REL_TAG : "yocto-3.3.2" +POKYVERSION : "25.0.2" YOCTO_POKY : "poky-&DISTRO_NAME_NO_CAP;-&POKYVERSION;" YOCTO_DL_URL : "https://downloads.yoctoproject.org" YOCTO_AB_URL : "https://autobuilder.yoctoproject.org" diff --git a/poky/documentation/profile-manual/usage.rst b/poky/documentation/profile-manual/usage.rst index 825290c3f..ae4efa7f4 100644 --- a/poky/documentation/profile-manual/usage.rst +++ b/poky/documentation/profile-manual/usage.rst @@ -1157,13 +1157,14 @@ section can be found here: Normally, you should be able to invoke the man pages via perf itself e.g. 'perf help' or 'perf help record'. -However, by default Yocto doesn't install man pages, but perf invokes -the man pages for most help functionality. This is a bug and is being -addressed by a Yocto bug: :yocto_bugs:`Bug 3388 - perf: enable man pages for -basic 'help' functionality </show_bug.cgi?id=3388>`. +To have the perf manpages installed on your target, modify your +configuration as follows:: + + IMAGE_INSTALL:append = " perf perf-doc" + DISTRO_FEATURES:append = " api-documentation" The man pages in text form, along with some other files, such as a set -of examples, can be found in the 'perf' directory of the kernel tree:: +of examples, can also be found in the 'perf' directory of the kernel tree:: tools/perf/Documentation diff --git a/poky/documentation/ref-manual/examples/hello-autotools/hello_2.10.bb b/poky/documentation/ref-manual/examples/hello-autotools/hello_2.10.bb deleted file mode 100644 index aa2beb9a9..000000000 --- a/poky/documentation/ref-manual/examples/hello-autotools/hello_2.10.bb +++ /dev/null @@ -1,9 +0,0 @@ -DESCRIPTION = "GNU Helloworld application" -SECTION = "examples" -LICENSE = "GPLv3" -LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504" - -SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz" -SRC_URI[sha256sum] = "31e066137a962676e89f69d1b65382de95a7ef7d914b8cb956f41ea72e0f516b" - -inherit autotools-brokensep gettext diff --git a/poky/documentation/ref-manual/examples/hello-single/files/helloworld.c b/poky/documentation/ref-manual/examples/hello-single/files/helloworld.c deleted file mode 100644 index fc7169b7b..000000000 --- a/poky/documentation/ref-manual/examples/hello-single/files/helloworld.c +++ /dev/null @@ -1,8 +0,0 @@ -#include <stdio.h> - -int main(void) -{ - printf("Hello world!\n"); - - return 0; -} diff --git a/poky/documentation/ref-manual/examples/hello-single/hello.bb b/poky/documentation/ref-manual/examples/hello-single/hello.bb deleted file mode 100644 index 90d3aefd8..000000000 --- a/poky/documentation/ref-manual/examples/hello-single/hello.bb +++ /dev/null @@ -1,17 +0,0 @@ -DESCRIPTION = "Simple helloworld application" -SECTION = "examples" -LICENSE = "MIT" -LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302" - -SRC_URI = "file://helloworld.c" - -S = "${WORKDIR}" - -do_compile() { - ${CC} ${LDFLAGS} helloworld.c -o helloworld -} - -do_install() { - install -d ${D}${bindir} - install -m 0755 helloworld ${D}${bindir} -} diff --git a/poky/documentation/ref-manual/examples/libxpm/libxpm_3.5.6.bb b/poky/documentation/ref-manual/examples/libxpm/libxpm_3.5.6.bb deleted file mode 100644 index c0c898640..000000000 --- a/poky/documentation/ref-manual/examples/libxpm/libxpm_3.5.6.bb +++ /dev/null @@ -1,14 +0,0 @@ -require recipes-graphics/xorg-lib/xorg-lib-common.inc - -DESCRIPTION = "X11 Pixmap library" -LICENSE = "X-BSD" -LIC_FILES_CHKSUM = "file://COPYING;md5=3e07763d16963c3af12db271a31abaa5" -DEPENDS += "libxext" -PR = "r2" -PE = "1" - -XORG_PN = "libXpm" - -PACKAGES =+ "sxpm cxpm" -FILES_cxpm = "${bindir}/cxpm" -FILES_sxpm = "${bindir}/sxpm" diff --git a/poky/documentation/ref-manual/examples/mtd-makefile/mtd-utils_1.0.0.bb b/poky/documentation/ref-manual/examples/mtd-makefile/mtd-utils_1.0.0.bb deleted file mode 100644 index 5d05a437a..000000000 --- a/poky/documentation/ref-manual/examples/mtd-makefile/mtd-utils_1.0.0.bb +++ /dev/null @@ -1,15 +0,0 @@ -DESCRIPTION = "Tools for managing memory technology devices." -SECTION = "base" -DEPENDS = "zlib" -HOMEPAGE = "http://www.linux-mtd.infradead.org/" -LICENSE = "GPLv2" -LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \ - file://include/common.h;beginline=1;endline=17;md5=ba05b07912a44ea2bf81ce409380049c" - -SRC_URI = "ftp://ftp.infradead.org/pub/mtd-utils/mtd-utils-${PV}.tar.gz" - -CFLAGS_prepend = "-I ${S}/include " - -do_install() { - oe_runmake install DESTDIR=${D} -} diff --git a/poky/documentation/ref-manual/tasks.rst b/poky/documentation/ref-manual/tasks.rst index 970b08394..ecc701856 100644 --- a/poky/documentation/ref-manual/tasks.rst +++ b/poky/documentation/ref-manual/tasks.rst @@ -14,8 +14,8 @@ Normal Recipe Build Tasks The following sections describe normal tasks associated with building a recipe. For more information on tasks and dependencies, see the -":ref:`Tasks <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:tasks>`" and -":ref:`Dependencies <bitbake:bitbake-user-manual/bitbake-user-manual-execution:dependencies>`" sections in the +":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:tasks`" and +":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:dependencies`" sections in the BitBake User Manual. .. _ref-tasks-build: diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst index 3de37a1ab..115094013 100644 --- a/poky/documentation/ref-manual/variables.rst +++ b/poky/documentation/ref-manual/variables.rst @@ -256,7 +256,7 @@ system and gives an overview of their function and contents. To add a tune to the list, be sure to append it with spaces using the "+=" BitBake operator. Do not simply replace the list by using the "=" operator. See the - ":ref:`Basic Syntax <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:basic syntax>`" section in the BitBake + ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:basic syntax`" section in the BitBake User Manual for more information. :term:`AZ_SAS` @@ -762,8 +762,7 @@ system and gives an overview of their function and contents. export BBSERVER=localhost:$port - By default, :term:`BBSERVER` also appears in - :term:`bitbake:BB_HASHBASE_WHITELIST`. + By default, :term:`BBSERVER` also appears in :term:`BB_HASHBASE_WHITELIST`. Consequently, :term:`BBSERVER` is excluded from checksum and dependency data. @@ -1472,6 +1471,18 @@ system and gives an overview of their function and contents. variable only in certain contexts (e.g. when building for kernel and kernel module recipes). + :term:`CVE_PRODUCT` + In a recipe, defines the name used to match the recipe name + against the name in the upstream `NIST CVE database <https://nvd.nist.gov/>`__. + + The default is ${:term:`BPN`}. If it does not match the name in NIST CVE + database or matches with multiple entries in the database, the default + value needs to be changed. + + Here is an example from the :oe_layerindex:`Berkeley DB recipe </layerindex/recipe/544>`:: + + CVE_PRODUCT = "oracle_berkeley_db berkeley_db" + :term:`CVSDIR` The directory in which files checked out under the CVS system are stored. @@ -1638,8 +1649,8 @@ system and gives an overview of their function and contents. For information on runtime dependencies, see the :term:`RDEPENDS` variable. You can also see the - ":ref:`Tasks <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:tasks>`" and - ":ref:`Dependencies <bitbake:bitbake-user-manual/bitbake-user-manual-execution:dependencies>`" sections in the + ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:tasks`" and + ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:dependencies`" sections in the BitBake User Manual for additional information on tasks and dependencies. @@ -6105,8 +6116,8 @@ system and gives an overview of their function and contents. For information on build-time dependencies, see the :term:`DEPENDS` variable. You can also see the - ":ref:`Tasks <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:tasks>`" and - ":ref:`Dependencies <bitbake:bitbake-user-manual/bitbake-user-manual-execution:dependencies>`" sections in the + ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:tasks`" and + ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:dependencies`" sections in the BitBake User Manual for additional information on tasks and dependencies. @@ -6500,7 +6511,7 @@ system and gives an overview of their function and contents. - :term:`CONF_VERSION` - :term:`BB_NUMBER_THREADS` - - :term:`bitbake:BB_NUMBER_PARSE_THREADS` + - :term:`BB_NUMBER_PARSE_THREADS` - :term:`PARALLEL_MAKE` - :term:`PRSERV_HOST` - :term:`SSTATE_MIRRORS` :term:`DL_DIR` @@ -6951,7 +6962,7 @@ system and gives an overview of their function and contents. protocols are highly dependent on particular BitBake Fetcher submodules. Depending on the fetcher BitBake uses, various URL parameters are employed. For specifics on the supported Fetchers, see - the ":ref:`Fetchers <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`" section in the + the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers`" section in the BitBake User Manual. - ``file://`` - Fetches files, which are usually files shipped diff --git a/poky/documentation/releases.rst b/poky/documentation/releases.rst index d6e1fb3c1..3ace7c06f 100644 --- a/poky/documentation/releases.rst +++ b/poky/documentation/releases.rst @@ -10,6 +10,7 @@ Release Series 3.3 (hardknott) - :yocto_docs:`3.3 Documentation </3.3>` - :yocto_docs:`3.3.1 Documentation </3.3.1>` +- :yocto_docs:`3.3.2 Documentation </3.3.2>` ******************************* Release Series 3.2 (gatesgarth) diff --git a/poky/documentation/sdk-manual/extensible.rst b/poky/documentation/sdk-manual/extensible.rst index 5520a0718..2cdb06d65 100644 --- a/poky/documentation/sdk-manual/extensible.rst +++ b/poky/documentation/sdk-manual/extensible.rst @@ -614,7 +614,7 @@ specify source code revision and versioning schemes, extract code into or out of the ``devtool`` :ref:`devtool-the-workspace-layer-structure`, and work with any source file forms that the -:ref:`fetchers <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` support. +:ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers` support. The following diagram shows the common development flow used with the ``devtool upgrade`` command: diff --git a/poky/documentation/sphinx-static/switchers.js b/poky/documentation/sphinx-static/switchers.js index 63649354b..3972b48a7 100644 --- a/poky/documentation/sphinx-static/switchers.js +++ b/poky/documentation/sphinx-static/switchers.js @@ -3,7 +3,7 @@ var all_versions = { 'dev': 'dev (3.4)', - '3.3.1': '3.3.1', + '3.3.2': '3.3.2', '3.2.4': '3.2.4', '3.1.9': '3.1.9', '3.0.4': '3.0.4', diff --git a/poky/documentation/test-manual/reproducible-builds.rst b/poky/documentation/test-manual/reproducible-builds.rst index e13583c0b..c66c82f86 100644 --- a/poky/documentation/test-manual/reproducible-builds.rst +++ b/poky/documentation/test-manual/reproducible-builds.rst @@ -68,6 +68,17 @@ things we do within the build system to ensure reproducibility include: - Filtering the tools available from the host's ``PATH`` to only a specific set of tools, set using the :term:`HOSTTOOLS` variable. +.. note:: + + Because of an open bug in GCC, using ``DISTRO_FEATURES_append = " lto"`` or + adding ``-flto`` (Link Time Optimization) to ``CFLAGS`` makes the resulting + binary non-reproducible, in that it depends on the full absolute build path + to ``recipe-sysroot-native``, so installing the Yocto Project in a different + directory results in a different binary. + + This issue is addressed by + :yocto_bugs:`bug 14481 - Programs built with -flto are not reproducible</show_bug.cgi?id=14481>`. + ========================================= Can we prove the project is reproducible? ========================================= |