From 82c905dc58a36aeae40b1b273a12f63fb1973cf4 Mon Sep 17 00:00:00 2001 From: Andrew Geissler Date: Mon, 13 Apr 2020 13:39:40 -0500 Subject: meta-openembedded and poky: subtree updates Squash of the following due to dependencies among them and OpenBMC changes: meta-openembedded: subtree update:d0748372d2..9201611135 meta-openembedded: subtree update:9201611135..17fd382f34 poky: subtree update:9052e5b32a..2e11d97b6c poky: subtree update:2e11d97b6c..a8544811d7 The change log was too large for the jenkins plugin to handle therefore it has been removed. Here is the first and last commit of each subtree: meta-openembedded:d0748372d2 cppzmq: bump to version 4.6.0 meta-openembedded:17fd382f34 mpv: Remove X11 dependency poky:9052e5b32a package_ipk: Remove pointless comment to trigger rebuild poky:a8544811d7 pbzip2: Fix license warning Change-Id: If0fc6c37629642ee207a4ca2f7aa501a2c673cd6 Signed-off-by: Andrew Geissler --- poky/documentation/Makefile | 9 +- .../brief-yoctoprojectqs/brief-yoctoprojectqs.xml | 31 ++- poky/documentation/bsp-guide/bsp-guide.xml | 48 ++-- poky/documentation/bsp-guide/bsp.xml | 97 ++++---- .../dev-manual/dev-manual-common-tasks.xml | 191 ++++++++------- poky/documentation/dev-manual/dev-manual-qemu.xml | 22 +- poky/documentation/dev-manual/dev-manual-start.xml | 218 ++++++++++++++---- poky/documentation/dev-manual/dev-manual.xml | 37 +-- .../documentation/kernel-dev/kernel-dev-common.xml | 40 ++-- .../kernel-dev/kernel-dev-concepts-appx.xml | 1 - poky/documentation/kernel-dev/kernel-dev.xml | 37 +-- poky/documentation/mega-manual/mega-manual.xml | 32 +-- .../overview-manual-development-environment.xml | 2 +- .../overview-manual/overview-manual-yp-intro.xml | 26 ++- .../overview-manual/overview-manual.xml | 32 +-- poky/documentation/poky.ent | 52 +++-- .../profile-manual/profile-manual-usage.xml | 2 +- .../profile-manual/profile-manual.xml | 37 +-- poky/documentation/ref-manual/faq.xml | 4 +- poky/documentation/ref-manual/migration.xml | 215 ++++++++++++++++- poky/documentation/ref-manual/ref-features.xml | 6 + poky/documentation/ref-manual/ref-manual.xml | 48 ++-- poky/documentation/ref-manual/ref-structure.xml | 130 +++++------ .../ref-manual/ref-system-requirements.xml | 256 +++++++++++++++++---- poky/documentation/ref-manual/ref-terms.xml | 10 +- poky/documentation/ref-manual/ref-variables.xml | 172 ++++++++++---- .../sdk-manual/sdk-appendix-obtain.xml | 3 +- poky/documentation/sdk-manual/sdk-manual.xml | 32 +-- .../toaster-manual/toaster-manual.xml | 32 +-- poky/documentation/tools/mega-manual.sed | 46 ++-- 30 files changed, 1276 insertions(+), 592 deletions(-) mode change 100644 => 100755 poky/documentation/bsp-guide/bsp-guide.xml mode change 100644 => 100755 poky/documentation/dev-manual/dev-manual.xml mode change 100644 => 100755 poky/documentation/kernel-dev/kernel-dev.xml mode change 100644 => 100755 poky/documentation/mega-manual/mega-manual.xml mode change 100644 => 100755 poky/documentation/overview-manual/overview-manual.xml mode change 100644 => 100755 poky/documentation/poky.ent mode change 100644 => 100755 poky/documentation/profile-manual/profile-manual.xml mode change 100644 => 100755 poky/documentation/ref-manual/ref-manual.xml mode change 100644 => 100755 poky/documentation/sdk-manual/sdk-manual.xml mode change 100644 => 100755 poky/documentation/toaster-manual/toaster-manual.xml (limited to 'poky/documentation') diff --git a/poky/documentation/Makefile b/poky/documentation/Makefile index 525a7309aa..15644bf926 100644 --- a/poky/documentation/Makefile +++ b/poky/documentation/Makefile @@ -76,6 +76,11 @@ # example publishes the 1.2 version of the PDF and HTML YP Development Tasks Manual # for the 'denzil' branch. # +# IN MEMORIAM: This comment is to remember Scott Rifenbark (scottrif), whom we lost +# in January, 2020. Scott was the primary technical writer for the Yocto Project for +# over 9 years. In that time, he contributed many thousands of patches, built this +# documentation tree, and enabled tens of thousands of developers to succeed with +# embedded Linux. He ran this Makefile many thousands of times. Godspeed, Dude. ifeq ($(DOC),brief-yoctoprojectqs) XSLTOPTS = --stringparam html.stylesheet brief-yoctoprojectqs-style.css \ @@ -414,8 +419,8 @@ publish: echo " "; \ echo "******** Publishing "$(DOC)".html"; \ echo " "; \ - scp -r $(MANUALS) $(STYLESHEET) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \ - cd $(DOC); scp -r $(FIGURES) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \ + scp -r $(MANUALS) $(STYLESHEET) www.yoctoproject.org:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \ + cd $(DOC); scp -r $(FIGURES) www.yoctoproject.org:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \ else \ echo " "; \ echo $(DOC)".html missing. Generate the file first then try again."; \ diff --git a/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml b/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml index 1daeb2547f..3c83afd46b 100644 --- a/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml +++ b/poky/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml @@ -55,10 +55,18 @@ information. - You cannot use a build host that is using the - Windows Subsystem for Linux - (WSL). - The Yocto Project is not compatible with WSL. + You may use Windows Subsystem For Linux v2 to set up a build + host using Windows 10. + + 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 + Setting Up to Use Windows Subsystem For Linux" + section in the Yocto Project Development Tasks Manual for more + information. @@ -99,17 +107,20 @@ Git 1.8.3.1 or greater - tar 1.27 or greater + tar 1.28 or greater - Python 3.4.0 or greater. - + Python 3.5.0 or greater. + + + gcc 5.0 or greater. + If your build host does not meet any of these three listed version requirements, you can take steps to prepare the system so that you can still use the Yocto Project. See the - "Required Git, tar, and Python Versions" + "Required Git, tar, Python and gcc Versions" section in the Yocto Project Reference Manual for information. @@ -266,7 +277,7 @@ meta-toolchain meta-ide-support - You can also run generated qemu images with a command like 'runqemu qemux86' + You can also run generated qemu images with a command like 'runqemu qemux86-64' Among other things, the script creates the Build Directory, @@ -332,7 +343,7 @@ QEMU, which is a Quick EMUlator that ships with the Yocto Project: - $ runqemu qemux86 + $ runqemu qemux86-64 If you want to learn more about running QEMU, see the "Using the Quick EMUlator (QEMU)" diff --git a/poky/documentation/bsp-guide/bsp-guide.xml b/poky/documentation/bsp-guide/bsp-guide.xml old mode 100644 new mode 100755 index dd0c76addc..a189606ce4 --- a/poky/documentation/bsp-guide/bsp-guide.xml +++ b/poky/documentation/bsp-guide/bsp-guide.xml @@ -22,33 +22,27 @@ - Scott Rifenbark - Scotty's Documentation Services, INC + &ORGNAME; - srifenbark@gmail.com + &ORGEMAIL; 0.9 - 24 November 2010 - The initial document draft released with the Yocto Project 0.9 Release. + November 2010 + The initial document released with the Yocto Project 0.9 Release. 1.0 - 6 April 2011 + April 2011 Released with the Yocto Project 1.0 Release. - - 1.0.1 - 23 May 2011 - Released with the Yocto Project 1.0.1 Release. - 1.1 - 6 October 2011 + October 2011 Released with the Yocto Project 1.1 Release. @@ -71,11 +65,6 @@ October 2013 Released with the Yocto Project 1.5 Release. - - 1.5.1 - January 2014 - Released with the Yocto Project 1.5.1 Release. - 1.6 April 2014 @@ -133,9 +122,14 @@ 3.0 - &REL_MONTH_YEAR; + October 2019 Released with the Yocto Project 3.0 Release. + + 3.1 + &REL_MONTH_YEAR; + Released with the Yocto Project 3.1 Release. + @@ -157,7 +151,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - Yocto Project documentation page + Yocto Project documentation page and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -174,18 +168,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - Yocto Project documentation page + Yocto Project documentation page and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. - + + To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - yocto@yoctoproject.com or log into - the freenode #yocto channel. - + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + docs@lists.yoctoproject.org or + log into the freenode #yocto channel. + + diff --git a/poky/documentation/bsp-guide/bsp.xml b/poky/documentation/bsp-guide/bsp.xml index 58f5733f7a..96c0455f67 100644 --- a/poky/documentation/bsp-guide/bsp.xml +++ b/poky/documentation/bsp-guide/bsp.xml @@ -19,7 +19,7 @@ - This guide presents information about BSP Layers, defines a structure for components + This guide presents information about BSP layers, defines a structure for components so that BSPs follow a commonly understood layout, discusses how to customize a recipe for a BSP, addresses BSP licensing, and provides information that shows you how to create a @@ -34,7 +34,7 @@ A BSP consists of a file structure inside a base directory. Collectively, you can think of the base directory, its file structure, - and the contents as a BSP Layer. + and the contents as a BSP layer. Although not a strict requirement, BSP layers in the Yocto Project use the following well-established naming convention: @@ -69,9 +69,9 @@ Each repository is a BSP layer supported by the Yocto Project (e.g. meta-raspberrypi and meta-intel). - Each of these layers is a repository unto itself and clicking on a - layer reveals information that includes two links from which you can choose - to set up a clone of the layer's repository on your local host system. + Each of these layers is a repository unto itself and clicking on + the layer name displays two URLs from which you can + clone the layer's repository to your local system. Here is an example that clones the Raspberry Pi BSP layer: $ git clone git://git.yoctoproject.org/meta-raspberrypi @@ -83,12 +83,13 @@ meta-yocto-bsp layer is part of the shipped poky repository. The meta-yocto-bsp layer maintains several - BSPs such as the Beaglebone, EdgeRouter, and generic versions of + "reference" BSPs including the ARM-based Beaglebone, MIPS-based + EdgeRouter, and generic versions of both 32-bit and 64-bit IA machines. - For information on the BSP development workflow, see the + For information on typical BSP development workflow, see the "Developing a Board Support Package (BSP)" section. For more information on how to set up a local copy of source files @@ -98,12 +99,12 @@ - The layer's base directory + The BSP layer's base directory (meta-bsp_root_name) - is the root directory of the BSP Layer. + is the root directory of that Layer. This directory is what you add to the BBLAYERS - variable in the conf/bblayers.conf file found in the + variable in the conf/bblayers.conf file found in your Build Directory, which is established after you run the OpenEmbedded build environment setup script (i.e. @@ -153,6 +154,20 @@ layer. The meta-openembedded layer contains many meta-* layers. + In cases like this, you need to include the names of the actual + layers you want to work with, such as: + + BBLAYERS ?= " \ + /usr/local/src/yocto/meta \ + /usr/local/src/yocto/meta-poky \ + /usr/local/src/yocto/meta-yocto-bsp \ + /usr/local/src/yocto/meta-mylayer \ + .../meta-openembedded/meta-oe \ + .../meta-openembedded/meta-perl \ + .../meta-openembedded/meta-networking \ + " + + and so on. @@ -351,25 +366,24 @@ layer combined with a build system and other tools. Realize that it is important to maintain the distinction that the BSP layer, a build system, and tools are - separate components that could to be combined in + separate components that could be combined in certain end products. - Before looking at the common form for the file structure - inside a BSP Layer, you should be aware that some + Before looking at the recommended form for the directory structure + inside a BSP layer, you should be aware that some requirements do exist in order for a BSP layer to - be considered compliant with the Yocto Project. + be considered compliant with the Yocto Project. For that list of requirements, see the "Released BSP Requirements" section. - Below is the common form for the file structure - inside a BSP Layer. + Below is the typical directory structure for a BSP layer. While this basic form represents the standard, - realize that the actual file structures for specific + realize that the actual layout for individual BSPs could differ. meta-bsp_root_name/ @@ -567,7 +581,7 @@ for the BSP. The type or types of files here can vary depending on the licensing requirements. - For example, in the Raspberry Pi BSP all licensing + For example, in the Raspberry Pi BSP, all licensing requirements are handled with the COPYING.MIT file. @@ -802,7 +816,7 @@ Source Directory. For example, many tune-* files (e.g. tune-arm1136jf-s.inc, - tun-1586-nlp.inc, and so forth) + tune-1586-nlp.inc, and so forth) reside in the poky/meta/conf/machine/include directory. @@ -834,7 +848,7 @@ This optional directory contains miscellaneous recipe files for the BSP. Most notably would be the formfactor files. - For example, in the Raspberry Pi BSP there is the + For example, in the Raspberry Pi BSP, there is the formfactor_0.0.bbappend file, which is an append file used to augment the recipe that starts the build. @@ -901,7 +915,7 @@ The *.bb files would be a developer-supplied kernel recipe. This area of the BSP hierarchy can contain both these - types of files, although in practice, it is likely that + types of files although, in practice, it is likely that you would have one or the other. @@ -976,7 +990,7 @@ Developing a Board Support Package (BSP) - This section contains the high-level procedure you can + This section describes the high-level procedure you can follow to create a BSP. Although not required for BSP creation, the meta-intel repository, which @@ -1074,10 +1088,6 @@ Texas Instruments Beaglebone (beaglebone-yocto) - - Freescale MPC8315E-RDB - (mpc8315e-rdb) - Ubiquiti Networks EdgeRouter Lite (edgerouter) @@ -1302,7 +1312,7 @@ (openembedded-core) or the Source Directory (poky). In other words, make sure you place related - files in appropriately related + files in appropriately-related recipes-* subdirectories specific to the recipe's function, or within a subdirectory containing a set of closely-related @@ -1319,7 +1329,7 @@ directory. This license covers the BSP Metadata as a whole. You must specify which license to use since no - default license exists when one not specified. + default license exists when one is not specified. See the COPYING.MIT file for the Raspberry Pi BSP in the @@ -1342,12 +1352,10 @@ file should contain the following: - A brief description about the hardware the BSP - targets. + A brief description of the target hardware. - A list of all the dependencies - on which a BSP layer depends. + A list of all the dependencies of the BSP. These dependencies are typically a list of required layers needed to build the BSP. @@ -1610,7 +1618,7 @@ BSP Licensing Considerations - In some cases, a BSP contains separately licensed + In some cases, a BSP contains separately-licensed Intellectual Property (IP) for a component or components. For these cases, you are required to accept the terms of a commercial or other type of license that requires @@ -1623,7 +1631,7 @@ - You could find that some separately licensed components + You could find that some separately-licensed components that are essential for normal operation of the system might not have an unencumbered (or free) substitute. Without these essential components, the system would be @@ -1631,7 +1639,7 @@ Then again, you might find that other licensed components that are simply 'good-to-have' or purely elective do have an unencumbered, free replacement component that you can - use rather than agreeing to the separately licensed + use rather than agreeing to the separately-licensed component. Even for components essential to the system, you might find an unencumbered component that is not identical but @@ -1744,7 +1752,7 @@ The bitbake-layers create-layer script automates creating a BSP layer. - What makes a layer a "BSP layer", is the presence of a machine + What makes a layer a "BSP layer" is the presence of at least one machine configuration file. Additionally, a BSP layer usually has a kernel recipe or an append file that leverages off an existing kernel recipe. @@ -1868,11 +1876,14 @@ - Machine configuration files exist in the + One or more machine configuration files exist in the bsp_layer/conf/machine/ directory of the layer: - bsp_layer/conf/machine/machine.conf + bsp_layer/conf/machine/machine1.conf + bsp_layer/conf/machine/machine2.conf + bsp_layer/conf/machine/machine3.conf + ... more ... For example, the machine configuration file for the BeagleBone and BeagleBone Black development boards @@ -1923,8 +1934,8 @@ IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} MLO zImage am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb" The variables used to configure the machine define - machine-specific properties. - For example, machine-dependent packages, machine + machine-specific properties; + for example, machine-dependent packages, machine tunings, the type of kernel to build, and U-Boot configurations. @@ -1935,7 +1946,7 @@ machine configuration file for the BeagleBone development boards. Realize that much more can be defined as part of - a machines configuration file. + a machine's configuration file. In general, you can learn about related variables that this example does not have by locating the variables in the @@ -2182,7 +2193,6 @@ KBRANCH_genericx86-64 = "v5.0/standard/base" KBRANCH_edgerouter = "v5.0/standard/edgerouter" KBRANCH_beaglebone-yocto = "v5.0/standard/beaglebone" - KBRANCH_mpc8315e-rdb = "v5.0/standard/fsl-mpc8315e-rdb" KMACHINE_genericx86 ?= "common-pc" KMACHINE_genericx86-64 ?= "common-pc-64" @@ -2192,19 +2202,16 @@ SRCREV_machine_genericx86-64 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d" SRCREV_machine_edgerouter ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d" SRCREV_machine_beaglebone-yocto ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d" - SRCREV_machine_mpc8315e-rdb ?= "8b62af7f252af10588276802c4c6d7c502e875be" COMPATIBLE_MACHINE_genericx86 = "genericx86" COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64" COMPATIBLE_MACHINE_edgerouter = "edgerouter" COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto" - COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb" LINUX_VERSION_genericx86 = "5.0.3" LINUX_VERSION_genericx86-64 = "5.0.3" LINUX_VERSION_edgerouter = "5.0.3" LINUX_VERSION_beaglebone-yocto = "5.0.3" - LINUX_VERSION_mpc8315e-rdb = "5.0.3" This particular append file works for all the machines that are part of the diff --git a/poky/documentation/dev-manual/dev-manual-common-tasks.xml b/poky/documentation/dev-manual/dev-manual-common-tasks.xml index 00741ee456..e9ce182a59 100644 --- a/poky/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/poky/documentation/dev-manual/dev-manual-common-tasks.xml @@ -183,6 +183,10 @@ LAYERDEPENDS variable. + + LAYERDEPENDS: + Lists all layers on which this layer depends (if any). + LAYERSERIES_COMPAT: Lists the @@ -315,12 +319,26 @@ DEPENDS_append_one = " foo" DEPENDS_prepend_one = "foo " - As an actual example, here's a line from the recipe - for gnutls, which adds dependencies on - "argp-standalone" when building with the musl C - library: + As an actual example, here's a snippet from the + generic kernel include file + linux-yocto.inc, + wherein the kernel compile and link options are + adjusted in the case of a subset of the supported + architectures: - DEPENDS_append_libc-musl = " argp-standalone" + DEPENDS_append_aarch64 = " libgcc" + KERNEL_CC_append_aarch64 = " ${TOOLCHAIN_OPTIONS}" + KERNEL_LD_append_aarch64 = " ${TOOLCHAIN_OPTIONS}" + + DEPENDS_append_nios2 = " libgcc" + KERNEL_CC_append_nios2 = " ${TOOLCHAIN_OPTIONS}" + KERNEL_LD_append_nios2 = " ${TOOLCHAIN_OPTIONS}" + + DEPENDS_append_arc = " libgcc" + KERNEL_CC_append_arc = " ${TOOLCHAIN_OPTIONS}" + KERNEL_LD_append_arc = " ${TOOLCHAIN_OPTIONS}" + + KERNEL_FEATURES_append_qemuall=" features/debug/printk.scc" Avoiding "+=" and "=+" and using @@ -579,11 +597,19 @@ is in order without errors (i.e. bitbake -e). + + common.test_world: + Verifies that bitbake world works. + common.test_signatures: Tests to be sure that BSP and DISTRO layers do not come with recipes that change signatures. + + common.test_layerseries_compat: + Verifies layer compatibility is set properly. + bsp.test_bsp_defines_machines: Tests if a BSP layer has machine configurations. @@ -593,12 +619,23 @@ Tests to ensure a BSP layer does not set the machine when the layer is added. + + bsp.test_machine_world: + Verifies that bitbake world + works regardless of which machine is selected. + + + bsp.test_machine_signatures: + Verifies that building for a particular machine + affects only the signature of tasks specific to that + machine. + distro.test_distro_defines_distros: Tests if a DISTRO layer has distro configurations. - distro.test_distro_no_set_distro: + distro.test_distro_no_set_distros: Tests to ensure a DISTRO layer does not set the distribution when the layer is added. @@ -1397,7 +1434,7 @@ package specified in the PACKAGES statement. - The inherit packages should be + The inherit packagegroup line should be located near the top of the recipe, certainly before the PACKAGES statement. @@ -1417,28 +1454,32 @@ Here is a short, fabricated example showing the same basic - pieces: + pieces for a hypothetical packagegroup defined in + packagegroup-custom.bb, where the + variable PN is the standard way to + abbreviate the reference to the full packagegroup name + packagegroup-custom: DESCRIPTION = "My Custom Package Groups" inherit packagegroup PACKAGES = "\ - packagegroup-custom-apps \ - packagegroup-custom-tools \ + ${PN}-apps \ + ${PN}-tools \ " - RDEPENDS_packagegroup-custom-apps = "\ + RDEPENDS_${PN}-apps = "\ dropbear \ portmap \ psplash" - RDEPENDS_packagegroup-custom-tools = "\ + RDEPENDS_${PN}-tools = "\ oprofile \ oprofileui-server \ lttng-tools" - RRECOMMENDS_packagegroup-custom-tools = "\ + RRECOMMENDS_${PN}-tools = "\ kernel-module-oprofile" @@ -1900,9 +1941,9 @@ The SRC_URI variable in your recipe must define each unique location for your source files. - It is good practice to not hard-code pathnames in an URL used + It is good practice to not hard-code version numbers in a URL used in SRC_URI. - Rather than hard-code these paths, use + Rather than hard-code these values, use ${PV}, which causes the fetch process to use the version specified in the recipe filename. @@ -1913,13 +1954,13 @@ Here is a simple example from the - meta/recipes-devtools/cdrtools/cdrtools-native_3.01a20.bb + meta/recipes-devtools/strace/strace_5.5.bb recipe where the source comes from a single tarball. Notice the use of the PV variable: - SRC_URI = "ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-${PV}.tar.bz2" + SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \ @@ -1978,16 +2019,17 @@ For these cases, you provide a name for each URL as part of the SRC_URI and then reference that name in the subsequent checksum statements. - Here is an example: + Here is an example combining lines from the files + git.inc and + git_2.24.1.bb: - SRC_URI = "${DEBIAN_MIRROR}/main/a/apmd/apmd_3.2.2.orig.tar.gz;name=tarball \ - ${DEBIAN_MIRROR}/main/a/apmd/apmd_${PV}.diff.gz;name=patch" + SRC_URI = "${KERNELORG_MIRROR}/software/scm/git/git-${PV}.tar.gz;name=tarball \ + ${KERNELORG_MIRROR}/software/scm/git/git-manpages-${PV}.tar.gz;name=manpages" - SRC_URI[tarball.md5sum] = "b1e6309e8331e0f4e6efd311c2d97fa8" - SRC_URI[tarball.sha256sum] = "7f7d9f60b7766b852881d40b8ff91d8e39fccb0d1d913102a5c75a2dbb52332d" - - SRC_URI[patch.md5sum] = "57e1b689264ea80f78353519eece0c92" - SRC_URI[patch.sha256sum] = "7905ff96be93d725544d0040e425c42f9c05580db3c272f11cff75b9aa89d430" + SRC_URI[tarball.md5sum] = "166bde96adbbc11c8843d4f8f4f9811b" + SRC_URI[tarball.sha256sum] = "ad5334956301c86841eb1e5b1bb20884a6bad89a10a6762c958220c7cf64da02" + SRC_URI[manpages.md5sum] = "31c2272a8979022497ba3d4202df145d" + SRC_URI[manpages.sha256sum] = "9a7ae3a093bea39770eb96ca3e5b40bff7af0b9f6123f089d7821d0e5b8e1230" @@ -3242,8 +3284,6 @@ The script defined in the post-installation function is called when the root filesystem is created. If the script succeeds, the package is marked as installed. - If the script fails, the package is marked as unpacked and - the script is executed when the image boots again. Any RPM post-installation script that runs on the target should return a 0 exit code. @@ -3262,7 +3302,7 @@ mark post installs to defer to the target. You can use pkg_postinst_ontarget() or call - postinst-intercepts defer_to_first_boot + postinst_intercept delay_to_first_boot from pkg_postinst(). Any failure of a pkg_postinst() script (including exit 1) triggers an error during the @@ -7609,7 +7649,6 @@ available Wic images as follows: $ wic list images - mpc8315e-rdb Create SD card image for MPC8315E-RDB genericx86 Create an EFI disk image for genericx86* beaglebone-yocto Create SD card image for Beaglebone edgerouter Create SD card image for Edgerouter @@ -7797,7 +7836,6 @@ files: $ wic list images - mpc8315e-rdb Create SD card image for MPC8315E-RDB genericx86 Create an EFI disk image for genericx86* beaglebone-yocto Create SD card image for Beaglebone edgerouter Create SD card image for Edgerouter @@ -10550,7 +10588,7 @@ devtool and the NPM fetcher to create the recipe: - $ devtool add "npm://registry.npmjs.org;name=cute-files;version=1.0.2" + $ devtool add "npm://registry.npmjs.org;package=cute-files;version=1.0.2" The devtool add command runs recipetool create and uses the @@ -10575,25 +10613,13 @@ - recipetool creates "shrinkwrap" and - "lockdown" files for your recipe. + recipetool creates a "shrinkwrap" file + for your recipe. Shrinkwrap files capture the version of all dependent modules. Many packages do not provide shrinkwrap files. recipetool create a shrinkwrap file as it runs. - You can replace the shrinkwrap file with your own file - by setting the NPM_SHRINKWRAP - variable. - - - - Lockdown files contain the checksum for each module - to determine if your users download the same files when - building with a recipe. - Lockdown files ensure that dependencies have not been - changed and that your NPM registry is still providing - the same file. A package is created for each sub-module. This policy is the only practical way to have the @@ -10608,23 +10634,26 @@ $ devtool edit-recipe cute-files SUMMARY = "Turn any folder on your computer into a cute file browser, available on the local network." - LICENSE = "BSD-3-Clause & Unknown & MIT & ISC" + LICENSE = "MIT & ISC & Unknown" LIC_FILES_CHKSUM = "file://LICENSE;md5=71d98c0a1db42956787b1909c74a86ca \ - file://node_modules/content-disposition/LICENSE;md5=c6e0ce1e688c5ff16db06b7259e9cd20 \ - file://node_modules/express/LICENSE;md5=5513c00a5c36cd361da863dd9aa8875d \ + file://node_modules/toidentifier/LICENSE;md5=1a261071a044d02eb6f2bb47f51a3502 \ + file://node_modules/debug/LICENSE;md5=ddd815a475e7338b0be7a14d8ee35a99 \ ... - SRC_URI = "npm://registry.npmjs.org;name=cute-files;version=${PV}" - NPM_SHRINKWRAP := "${THISDIR}/${PN}/npm-shrinkwrap.json" - NPM_LOCKDOWN := "${THISDIR}/${PN}/lockdown.json" + SRC_URI = " \ + npm://registry.npmjs.org/;package=cute-files;version=${PV} \ + npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \ + " + + S = "${WORKDIR}/npm" + inherit npm - # Must be set after inherit npm since that itself sets S - S = "${WORKDIR}/npmpkg" - LICENSE_${PN}-content-disposition = "MIT" - ... - LICENSE_${PN}-express = "MIT" LICENSE_${PN} = "MIT" + LICENSE_${PN}-accepts = "MIT" + LICENSE_${PN}-array-flatten = "MIT" + ... + LICENSE_${PN}-vary = "MIT" Three key points exist in the previous example: @@ -10717,11 +10746,10 @@ However, the SRC_URI looks like the following: - SRC_URI = "git://github.com/martinaglv/cute-files.git;protocol=https \ - npm://registry.npmjs.org;name=commander;version=2.9.0;subdir=node_modules/commander \ - npm://registry.npmjs.org;name=express;version=4.14.0;subdir=node_modules/express \ - npm://registry.npmjs.org;name=content-disposition;version=0.3.0;subdir=node_modules/content-disposition \ - " + SRC_URI = " \ + git://github.com/martinaglv/cute-files.git;protocol=https \ + npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \ + " In this example, the main module is taken from the Git repository and dependents are taken from the NPM registry. @@ -10822,7 +10850,7 @@ Use the following BitBake command form to fetch all the necessary sources without starting the build: - $ bitbake -c target runall="fetch" + $ bitbake target --runall=fetch This variation of the BitBake command guarantees that you have all the sources for that BitBake target should you @@ -10844,15 +10872,6 @@ features that are used by many distributions. - - By default, the Yocto Project uses SysVinit as the initialization - manager. - However, support also exists for systemd, - which is a full replacement for init with - parallel starting of services, reduced shell overhead and other - features that are used by many distributions. - - Within the system, SysVinit treats system components as services. These services are maintained as shell scripts stored in the @@ -11164,18 +11183,18 @@ To create the read-only root filesystem, simply add the - "read-only-rootfs" feature to your image. - Using either of the following statements in your - image recipe or from within the - local.conf file found in the - Build Directory - causes the build system to create a read-only root filesystem: + "read-only-rootfs" feature to your image, normally in one of two ways. + The first way is to add the "read-only-rootfs" image feature + in the image's recipe file via the + IMAGE_FEATURES variable: - IMAGE_FEATURES = "read-only-rootfs" + IMAGE_FEATURES += "read-only-rootfs" - or + As an alternative, you can add the same feature from within your + build directory's local.conf file with the + associated EXTRA_IMAGE_FEATURES variable, as in: - EXTRA_IMAGE_FEATURES += "read-only-rootfs" + EXTRA_IMAGE_FEATURES = "read-only-rootfs" @@ -12038,15 +12057,15 @@ In order to run tests on hardware, you need to set TEST_TARGET to an appropriate value. For QEMU, you do not have to change anything, the default - value is "QemuTarget". + value is "qemu". For running tests on hardware, the following options exist: - "SimpleRemoteTarget": - Choose "SimpleRemoteTarget" if you are going to + "simpleremote": + Choose "simpleremote" if you are going to run tests on a target system that is already running the image to be tested and is available on the network. - You can use "SimpleRemoteTarget" in conjunction + You can use "simpleremote" in conjunction with either real hardware or an image running within a separately started QEMU or any other virtual machine manager. @@ -12221,7 +12240,7 @@ Power Control - For most hardware targets other than SimpleRemoteTarget, + For most hardware targets other than "simpleremote", you can control power: @@ -12618,7 +12637,7 @@ target: The target controller object used to deploy and start an image on a particular target - (e.g. QemuTarget, SimpleRemote, and + (e.g. Qemu, SimpleRemote, and SystemdbootTarget). Tests usually use the following: diff --git a/poky/documentation/dev-manual/dev-manual-qemu.xml b/poky/documentation/dev-manual/dev-manual-qemu.xml index f5a0d64afe..5ccc0dfe83 100644 --- a/poky/documentation/dev-manual/dev-manual-qemu.xml +++ b/poky/documentation/dev-manual/dev-manual-qemu.xml @@ -151,13 +151,13 @@ This example starts QEMU with - MACHINE set to "qemux86". + MACHINE set to "qemux86-64". Assuming a standard Build Directory, runqemu automatically finds the - bzImage-qemux86.bin image file and + bzImage-qemux86-64.bin image file and the - core-image-minimal-qemux86-20140707074611.rootfs.ext3 + core-image-minimal-qemux86-64-20200218002850.rootfs.ext4 (assuming the current build created a core-image-minimal image). @@ -166,7 +166,7 @@ timestamp. - $ runqemu qemux86 + $ runqemu qemux86-64 @@ -175,7 +175,7 @@ This command, however, specifically provides the image and root filesystem type. - $ runqemu qemux86 core-image-minimal ext3 + $ runqemu qemux86-64 core-image-minimal ext4 @@ -188,7 +188,7 @@ be installed (see the previous description for the audio option for more information). - $ runqemu qemux86 ramfs audio + $ runqemu qemux86-64 ramfs audio @@ -200,7 +200,7 @@ KERNEL, or VM option. - $ runqemu ext3 + $ runqemu ext4 @@ -209,9 +209,9 @@ From the .wic.vmdk, runqemu determines the QEMU architecture (MACHINE) to be - "qemux86" and the root filesystem type to be "vmdk". + "qemux86-64" and the root filesystem type to be "vmdk". - $ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86.wic.vmdk + $ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86-64.wic.vmdk @@ -296,7 +296,7 @@ extracts it to a directory named test-nfs: - runqemu-extract-sdk ./tmp/deploy/images/qemux86/core-image-sato-qemux86.tar.bz2 test-nfs + runqemu-extract-sdk ./tmp/deploy/images/qemux86-64/core-image-sato-qemux86-64.tar.bz2 test-nfs @@ -310,7 +310,7 @@ Here is an example using the qemux86 image: - runqemu qemux86 ./test-nfs + runqemu qemux86-64 ./test-nfs diff --git a/poky/documentation/dev-manual/dev-manual-start.xml b/poky/documentation/dev-manual/dev-manual-start.xml index 59ffa49bb6..8cb5631f0d 100644 --- a/poky/documentation/dev-manual/dev-manual-start.xml +++ b/poky/documentation/dev-manual/dev-manual-start.xml @@ -7,7 +7,7 @@ Setting Up to Use the Yocto Project - This chapter provides procedures related to getting set up to use the + This chapter provides guidance on how to prepare to use the Yocto Project. You can learn about creating a team environment that develops using the Yocto Project, how to set up a @@ -24,9 +24,9 @@ Project in a team development environment, or how to scale it for a large team of developers. You can adapt the Yocto Project to many different use cases and - scenarios. - However, this flexibility could cause difficulties if you are trying - to create a working setup that scales across a large team. + scenarios; + however, this flexibility could cause difficulties if you are trying + to create a working setup that scales effectively. @@ -35,17 +35,17 @@ that can help you get the results you want. The procedure is high-level and presents some of the project's most successful experiences, practices, solutions, and available - technologies that have proved to work well in the past. - Keep in mind, the procedure here is a starting point. + technologies that have proved to work well in the past; + however, keep in mind, the procedure here is simply a starting point. You can build off these steps and customize the procedure to fit any particular working environment and set of practices. Determine Who is Going to be Developing: - You need to understand who is going to be doing anything + You first need to understand who is going to be doing anything related to the Yocto Project and determine their roles. Making this determination is essential to completing - steps two and three, which are to get your equipment together + subsequent steps, which are to get your equipment together and set up your development environment's hardware topology. @@ -64,8 +64,8 @@ Build Engineer: This type of developer manages Autobuilders and - releases. - Not all environments need a Build Engineer. + releases. Depending on the specifics of the environment, + not all situations might need a Build Engineer. Test Engineer: @@ -88,6 +88,11 @@ You can help ensure efficiency by having any machines used for testing or that run Autobuilders be as high performance as possible. + + Given sufficient processing power, you might also consider + building Yocto Project development containers to be run + under Docker, which is described later. + Understand the Hardware Topology of the Environment: @@ -114,10 +119,10 @@ and any software you are developing under the control of an SCM system that is compatible with the OpenEmbedded build system is advisable. - Of the SCMs BitBake supports, the Yocto Project team strongly + Of all of the SCMs supported by BitBake, the Yocto Project team strongly recommends using Git. - Git is a distributed system that is easy to backup, + Git is a distributed system that is easy to back up, allows you to work remotely, and then connects back to the infrastructure. @@ -302,7 +307,7 @@ As with any development environment, it is important to document the policy used as well as any main project guidelines so they are understood by everyone. - It is also a good idea to have well structured + It is also a good idea to have well-structured commit messages, which are usually a part of a project's guidelines. Good commit messages are essential when looking back in time and @@ -394,16 +399,18 @@ This section provides procedures to set up a system to be used as your build host for development using the Yocto Project. - Your build host can be a native Linux machine (recommended) or it can + Your build host can be a native Linux machine (recommended), it can be a machine (Linux, Mac, or Windows) that uses - CROPS, + CROPS, which leverages - Docker Containers. + Docker Containers or it can + be a Windows machine capable of running Windows Subsystem For Linux v2 (WSL). - You cannot use a build host that is using the - Windows Subsystem for Linux - (WSL). - The Yocto Project is not compatible with WSL. + 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. @@ -442,7 +449,7 @@ You should have a reasonably current Linux-based host system. You will have the best results with a recent release of - Fedora, openSUSE, Debian, Ubuntu, or CentOS as these + Fedora, openSUSE, Debian, Ubuntu, RHEL or CentOS as these releases are frequently tested against the Yocto Project and officially supported. For a list of the distributions under validation and their @@ -460,23 +467,26 @@ Meet Minimal Version Requirements: The OpenEmbedded build system should be able to run on any modern distribution that has the following versions for - Git, tar, and Python. + Git, tar, Python and gcc. Git 1.8.3.1 or greater - tar 1.27 or greater + tar 1.28 or greater - Python 3.4.0 or greater. - + Python 3.5.0 or greater. + + + gcc 5.0 or greater. + If your build host does not meet any of these three listed version requirements, you can take steps to prepare the system so that you can still use the Yocto Project. See the - "Required Git, tar, and Python Versions" + "Required Git, tar, Python and gcc Versions" section in the Yocto Project Reference Manual for information. @@ -517,7 +527,7 @@ With - CROPS, + CROPS, which leverages Docker Containers, you can create a Yocto Project development environment that @@ -654,15 +664,147 @@ section in the Toaster User Manual. + +
+ Setting Up to Use Windows Subsystem For Linux (WSLv2) + + + With + Windows Subsystem for Linux (WSLv2), 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 your Yocto Project build host: + + + 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". + + 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 + + + Install the Linux distribution of your choice inside Windows 10: + Once you know your version of Windows 10 supports WSLv2, + 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 pick will be one of the distributions supported + by the Yocto Project as stated on the instructions for + using a native Linux host. + After making your selection, simply click "Get" to download + and install the distribution. + + + Check your Linux distribution is using WSLv2: + 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. + + + Optionally Orient Yourself on WSL: + If you are unfamiliar with WSL, you can learn more here - + . + + + Launch your WSL Distibution: + From the Windows start menu simply launch your WSL distribution + just like any other application. + + + 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 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: + + + Find the location of your VHDX file: + First you need to find the distro app package directory, + to achieve this open a Windows Powershell as Administrator + and run: + + C:\WINDOWS\system32> Get-AppxPackage -Name "*Ubuntu*" | Select PackageFamilyName + PackageFamilyName + ----------------- + CanonicalGroupLimited.UbuntuonWindows_79abcdefgh + + You should now replace the PackageFamilyName + and your user on the following + path to find your VHDX file: C:\Users\user\AppData\Local\Packages\PackageFamilyName\LocalState\ + For example: + + ls C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ + Mode LastWriteTime Length Name + -a---- 3/14/2020 9:52 PM 57418973184 ext4.vhdx + + Your VHDX file path is: C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx + + Optimize your VHDX file: + Open a Windows Powershell as Administrator to optimize + your VHDX file, shutting down WSL first: + + C:\WINDOWS\system32> wsl --shutdown + C:\WINDOWS\system32> optimize-vhd -Path C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx -Mode full + + A progress bar should be shown while optimizing the VHDX file, + and storage should now be reflected correctly on the Windows + Explorer. + + + + + + The current implementation of WSLv2 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 you were running on a native Linux machine. + If you are going to use the Extensible SDK container, see the + "Using the Extensible SDK" + Chapter in the Yocto Project Application Development and the + Extensible Software Development Kit (eSDK) manual. + If you are going to use the Toaster container, see the + "Setting Up and Using Toaster" + section in the Toaster User Manual. + +
Locating Yocto Project Source Files - This section shows you how to locate and access the - source files that ship with the Yocto Project. - You establish and use these local files to work on projects. + This section shows you how to locate, fetch and configure the source + files you'll need to work with the Yocto Project. Notes @@ -1019,20 +1161,18 @@ . . . - remotes/origin/pyro - remotes/origin/pyro-next - remotes/origin/rocko - remotes/origin/rocko-next - remotes/origin/sumo - remotes/origin/sumo-next remotes/origin/thud remotes/origin/thud-next remotes/origin/warrior + remotes/origin/warrior-next + remotes/origin/zeus + remotes/origin/zeus-next + ... and so on ... - Checkout the Branch: - Checkout the development branch in which you want to work. + Check out the Branch: + Check out the development branch in which you want to work. For example, to access the files for the Yocto Project &DISTRO; Release (&DISTRO_NAME;), use the following command: @@ -1118,7 +1258,7 @@ - Checkout the Branch: + Check out the Branch: $ git checkout tags/&DISTRO_REL_TAG; -b my_yocto_&DISTRO; Switched to a new branch 'my_yocto_&DISTRO;' diff --git a/poky/documentation/dev-manual/dev-manual.xml b/poky/documentation/dev-manual/dev-manual.xml old mode 100644 new mode 100755 index 04fa1e4f9a..6f86454ede --- a/poky/documentation/dev-manual/dev-manual.xml +++ b/poky/documentation/dev-manual/dev-manual.xml @@ -22,18 +22,17 @@ - Scott Rifenbark - Scotty's Documentation Services, INC + &ORGNAME; - srifenbark@gmail.com + &ORGEMAIL; 1.1 - 6 October 2011 + October 2011 The initial document released with the Yocto Project 1.1 Release. @@ -56,11 +55,6 @@ October 2013 Released with the Yocto Project 1.5 Release. - - 1.5.1 - January 2014 - Released with the Yocto Project 1.5.1 Release. - 1.6 April 2014 @@ -118,9 +112,14 @@ 3.0 - &REL_MONTH_YEAR; + October 2019 Released with the Yocto Project 3.0 Release. + + 3.1 + &REL_MONTH_YEAR; + Released with the Yocto Project 3.1 Release. + @@ -144,7 +143,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - Yocto Project documentation page + Yocto Project documentation page and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -161,18 +160,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - Yocto Project documentation page + Yocto Project documentation page and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. - + + To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - yocto@yoctoproject.com or log into - the freenode #yocto channel. - + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + docs@lists.yoctoproject.org or + log into the freenode #yocto channel. + + diff --git a/poky/documentation/kernel-dev/kernel-dev-common.xml b/poky/documentation/kernel-dev/kernel-dev-common.xml index 2ea5d3f38e..c1c2d6d703 100644 --- a/poky/documentation/kernel-dev/kernel-dev-common.xml +++ b/poky/documentation/kernel-dev/kernel-dev-common.xml @@ -89,8 +89,8 @@ Prepare Your local.conf File: By default, the MACHINE - variable is set to "qemux86", which is fine if you are - building for the QEMU emulator in 32-bit mode. + variable is set to "qemux86-64", which is fine if you are + building for the QEMU emulator in 64-bit mode. However, if you are not, you need to set the MACHINE variable appropriately in your conf/local.conf file found in @@ -104,10 +104,12 @@ MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS variable to include kernel modules. - This example uses the default "qemux86" for the - MACHINE variable but needs to - add the "kernel-modules": + In this example we wish to build for qemux86 so + we must set the MACHINE variable + to "qemux86" and also add the "kernel-modules". As described + we do this by appending to conf/local.conf: + MACHINE = "qemux86" MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules" @@ -314,8 +316,8 @@ File: By default, the MACHINE - variable is set to "qemux86", which is fine if you are - building for the QEMU emulator in 32-bit mode. + variable is set to "qemux86-64", which is fine if you are + building for the QEMU emulator in 64-bit mode. However, if you are not, you need to set the MACHINE variable appropriately in your conf/local.conf file found @@ -329,10 +331,12 @@ MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS variable to include kernel modules. - This example uses the default "qemux86" for the - MACHINE variable but needs to - add the "kernel-modules": + In this example we wish to build for qemux86 so + we must set the MACHINE variable + to "qemux86" and also add the "kernel-modules". As described + we do this by appending to conf/local.conf: + MACHINE = "qemux86" MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules" @@ -655,26 +659,22 @@ KMACHINE_genericx86-64 ?= "common-pc-64" KBRANCH_edgerouter = "standard/edgerouter" KBRANCH_beaglebone = "standard/beaglebone" - KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb" SRCREV_machine_genericx86 ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19" SRCREV_machine_genericx86-64 ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19" SRCREV_machine_edgerouter ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d" SRCREV_machine_beaglebone ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d" - SRCREV_machine_mpc8315e-rdb ?= "2d1d010240846d7bff15d1fcc0cb6eb8a22fc78a" COMPATIBLE_MACHINE_genericx86 = "genericx86" COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64" COMPATIBLE_MACHINE_edgerouter = "edgerouter" COMPATIBLE_MACHINE_beaglebone = "beaglebone" - COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb" LINUX_VERSION_genericx86 = "4.12.7" LINUX_VERSION_genericx86-64 = "4.12.7" LINUX_VERSION_edgerouter = "4.12.10" LINUX_VERSION_beaglebone = "4.12.10" - LINUX_VERSION_mpc8315e-rdb = "4.12.10" This append file contains statements used to support several BSPs that ship with the Yocto Project. @@ -948,12 +948,14 @@ KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file - Here is an example that appends the - KBUILD_DEFCONFIG variable with - "common-pc" and provides the path to the "in-tree" - defconfig file: + Here is an example that assigns the + KBUILD_DEFCONFIG variable based on + "raspberrypi2" and provides the path to the "in-tree" + defconfig file + to be used for a Raspberry Pi 2, + which is based on the Broadcom 2708/2709 chipset: - KBUILD_DEFCONFIG_common-pc ?= "/home/scottrif/configfiles/my_defconfig_file" + KBUILD_DEFCONFIG_raspberrypi2 ?= "bcm2709_defconfig" diff --git a/poky/documentation/kernel-dev/kernel-dev-concepts-appx.xml b/poky/documentation/kernel-dev/kernel-dev-concepts-appx.xml index 6d675a6d51..62c68527d2 100644 --- a/poky/documentation/kernel-dev/kernel-dev-concepts-appx.xml +++ b/poky/documentation/kernel-dev/kernel-dev-concepts-appx.xml @@ -543,7 +543,6 @@ yocto-kernel-cache/features/kgdb/hardware.cfg yocto-kernel-cache/ktypes/base/hardware.cfg yocto-kernel-cache/bsp/mti-malta32/hardware.cfg - yocto-kernel-cache/bsp/fsl-mpc8315e-rdb/hardware.cfg yocto-kernel-cache/bsp/qemu-ppc32/hardware.cfg yocto-kernel-cache/bsp/qemuarma9/hardware.cfg yocto-kernel-cache/bsp/mti-malta64/hardware.cfg diff --git a/poky/documentation/kernel-dev/kernel-dev.xml b/poky/documentation/kernel-dev/kernel-dev.xml old mode 100644 new mode 100755 index 4c5881b071..998fe41415 --- a/poky/documentation/kernel-dev/kernel-dev.xml +++ b/poky/documentation/kernel-dev/kernel-dev.xml @@ -22,11 +22,10 @@ - Scott Rifenbark - Scotty's Documentation Services, INC + &ORGNAME; - srifenbark@gmail.com + &ORGEMAIL; @@ -34,18 +33,13 @@ 1.4 April 2013 - Released with the Yocto Project 1.4 Release. + The initial document released with the Yocto Project 1.4 Release. 1.5 October 2013 Released with the Yocto Project 1.5 Release. - - 1.5.1 - January 2014 - Released with the Yocto Project 1.5.1 Release. - 1.6 April 2014 @@ -103,9 +97,14 @@ 3.0 - &REL_MONTH_YEAR; + October 2019 Released with the Yocto Project 3.0 Release. + + 3.1 + &REL_MONTH_YEAR; + Released with the Yocto Project 3.1 Release. + @@ -127,7 +126,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - Yocto Project documentation page + Yocto Project documentation page and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -144,18 +143,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - Yocto Project documentation page + Yocto Project documentation page and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. - + + To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - yocto@yoctoproject.com or log into - the freenode #yocto channel. - + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + docs@lists.yoctoproject.org or + log into the freenode #yocto channel. + + diff --git a/poky/documentation/mega-manual/mega-manual.xml b/poky/documentation/mega-manual/mega-manual.xml old mode 100644 new mode 100755 index cd9a3da8f1..e730f72596 --- a/poky/documentation/mega-manual/mega-manual.xml +++ b/poky/documentation/mega-manual/mega-manual.xml @@ -33,11 +33,10 @@ - Scott Rifenbark - Scotty's Documentation Services, INC + &ORGNAME; - srifenbark@gmail.com + &ORGEMAIL; @@ -45,7 +44,7 @@ 1.8 April 2015 - Released with the Yocto Project 1.8 Release. + The initial document released with the Yocto Project 1.8 Release. 2.0 @@ -89,9 +88,14 @@ 3.0 - &REL_MONTH_YEAR; + October 2019 Released with the Yocto Project 3.0 Release. + + 3.1 + &REL_MONTH_YEAR; + Released with the Yocto Project 3.1 Release. + @@ -113,7 +117,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - Yocto Project documentation page + Yocto Project documentation page and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -130,18 +134,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - Yocto Project documentation page + Yocto Project documentation page and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. - + + To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - yocto@yoctoproject.com or log into - the freenode #yocto channel. - + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + docs@lists.yoctoproject.org or + log into the freenode #yocto channel. + + diff --git a/poky/documentation/overview-manual/overview-manual-development-environment.xml b/poky/documentation/overview-manual/overview-manual-development-environment.xml index 2f1bd1610d..36ebf8a321 100644 --- a/poky/documentation/overview-manual/overview-manual-development-environment.xml +++ b/poky/documentation/overview-manual/overview-manual-development-environment.xml @@ -87,7 +87,7 @@ as its operating system as your development host. When you have a Mac or Windows-based system, you can set it up as the development host by using - CROPS, + CROPS, which leverages Docker Containers. Once you take the steps to set up a CROPS machine, you effectively diff --git a/poky/documentation/overview-manual/overview-manual-yp-intro.xml b/poky/documentation/overview-manual/overview-manual-yp-intro.xml index dbf62cc162..1b60a30302 100644 --- a/poky/documentation/overview-manual/overview-manual-yp-intro.xml +++ b/poky/documentation/overview-manual/overview-manual-yp-intro.xml @@ -225,9 +225,9 @@ For information that helps you transition from trying out the Yocto Project to using it for your project, see the - "What I wish I'd Known" + "What I wish I'd Known" and - "Transitioning to a Custom Environment for Systems Development" + "Transitioning to a Custom Environment for Systems Development" documents on the Yocto Project website. @@ -437,7 +437,7 @@ CROPS: - CROPS + CROPS is an open source, cross-platform development framework that leverages Docker Containers. @@ -883,7 +883,7 @@ CROss PlatformS (CROPS): Typically, you use - CROPS, + CROPS, which leverages Docker Containers, to set up a Build Host that is not running Linux (e.g. @@ -907,6 +907,24 @@ "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. + + 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 kernel inside of a lightweight utility virtual + machine (VM) using virtualization technology. + For information on how to set up a Build Host with + WSLv2, see the + "Setting Up to Use Windows Subsystem For Linux" + section in the Yocto Project Development Tasks Manual. + Toaster: Regardless of what your Build Host is running, you can diff --git a/poky/documentation/overview-manual/overview-manual.xml b/poky/documentation/overview-manual/overview-manual.xml old mode 100644 new mode 100755 index c7716e460b..210d644b3d --- a/poky/documentation/overview-manual/overview-manual.xml +++ b/poky/documentation/overview-manual/overview-manual.xml @@ -22,11 +22,10 @@ - Scott Rifenbark - Scotty's Documentation Services, INC + &ORGNAME; - srifenbark@gmail.com + &ORGEMAIL; @@ -39,7 +38,7 @@ 2.6 November 2018 - Released with the Yocto Project 2.7 Release. + Released with the Yocto Project 2.6 Release. 2.7 @@ -48,9 +47,14 @@ 3.0 - &REL_MONTH_YEAR; + October 2019 Released with the Yocto Project 3.0 Release. + + 3.1 + &REL_MONTH_YEAR; + Released with the Yocto Project 3.1 Release. + @@ -74,7 +78,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - Yocto Project documentation page + Yocto Project documentation page and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -91,18 +95,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - Yocto Project documentation page + Yocto Project documentation page and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. - + + To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - yocto@yoctoproject.com or log into - the freenode #yocto channel. - + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + docs@lists.yoctoproject.org or + log into the freenode #yocto channel. + + diff --git a/poky/documentation/poky.ent b/poky/documentation/poky.ent old mode 100644 new mode 100755 index 7af47df72f..a54793911a --- a/poky/documentation/poky.ent +++ b/poky/documentation/poky.ent @@ -1,19 +1,21 @@ - - - - - - - - - - - + + + + + + + + + + + - - + + - + + + @@ -58,22 +60,30 @@ + python3-jinja2 SDL-devel xterm rpcgen"> - + + diff --git a/poky/documentation/profile-manual/profile-manual-usage.xml b/poky/documentation/profile-manual/profile-manual-usage.xml index 5999b29603..9a4273a0fe 100644 --- a/poky/documentation/profile-manual/profile-manual-usage.xml +++ b/poky/documentation/profile-manual/profile-manual-usage.xml @@ -2182,7 +2182,7 @@ meta-toolchain meta-ide-support - You can also run generated qemu images with a command like 'runqemu qemux86' + You can also run generated qemu images with a command like 'runqemu qemux86-64' Once you've done that, you can cd to whatever directory diff --git a/poky/documentation/profile-manual/profile-manual.xml b/poky/documentation/profile-manual/profile-manual.xml old mode 100644 new mode 100755 index c1f461f43a..fa1fa8ac80 --- a/poky/documentation/profile-manual/profile-manual.xml +++ b/poky/documentation/profile-manual/profile-manual.xml @@ -22,11 +22,10 @@ - Scott Rifenbark - Scotty's Documentation Services, INC + &ORGNAME; - srifenbark@gmail.com + &ORGEMAIL; @@ -34,18 +33,13 @@ 1.4 April 2013 - Released with the Yocto Project 1.4 Release. + The initial document released with the Yocto Project 1.4 Release. 1.5 October 2013 Released with the Yocto Project 1.5 Release. - - 1.5.1 - January 2014 - Released with the Yocto Project 1.5.1 Release. - 1.6 April 2014 @@ -103,9 +97,14 @@ 3.0 - &REL_MONTH_YEAR; + October 2019 Released with the Yocto Project 3.0 Release. + + 3.1 + &REL_MONTH_YEAR; + Released with the Yocto Project 3.1 Release. + @@ -129,7 +128,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - Yocto Project documentation page + Yocto Project documentation page and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -146,18 +145,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - Yocto Project documentation page + Yocto Project documentation page and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. - + + To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - yocto@yoctoproject.com or log into - the freenode #yocto channel. - + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + docs@lists.yoctoproject.org or + log into the freenode #yocto channel. + + diff --git a/poky/documentation/ref-manual/faq.xml b/poky/documentation/ref-manual/faq.xml index 49ff86261d..d94cb32a86 100644 --- a/poky/documentation/ref-manual/faq.xml +++ b/poky/documentation/ref-manual/faq.xml @@ -33,7 +33,7 @@ My development system does not meet the required Git, tar, and Python versions. - In particular, I do not have Python 3.4.0 or greater. + In particular, I do not have Python 3.5.0 or greater. Can I still use the Yocto Project? @@ -43,7 +43,7 @@ system a couple different ways (i.e. building a tarball or downloading a tarball). See the - "Required Git, tar, and Python Versions" + "Required Git, tar, Python and gcc Versions" section for steps on how to update your build tools. diff --git a/poky/documentation/ref-manual/migration.xml b/poky/documentation/ref-manual/migration.xml index 8d50ab9133..9422b5a277 100644 --- a/poky/documentation/ref-manual/migration.xml +++ b/poky/documentation/ref-manual/migration.xml @@ -680,7 +680,7 @@ For more information on this requirement, see the - "Required Git, tar, and Python Versions" + "Required Git, tar, Python and gcc Versions" section.
@@ -1754,7 +1754,7 @@ Git that meets this requirement, you can use the buildtools-tarball that does. See the - "Required Git, tar, and Python Versions" + "Required Git, tar, Python and gcc Versions" section for more information. @@ -2110,7 +2110,7 @@ such as the following: inherit bluetooth - PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)} + PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}" PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4" PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5" @@ -3215,7 +3215,7 @@ recent version, you can install the buildtools, which will provide it. See the - "Required Git, tar, and Python Versions" + "Required Git, tar, Python and gcc Versions" section for more information on the buildtools tarball. @@ -3624,7 +3624,7 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64. image types, this part of the kernel image base name as been removed leaving only the following: - KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME} + KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}" If you have recipes or classes that use KERNEL_IMAGE_BASE_NAME directly, you might @@ -5601,7 +5601,7 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message. creation time, use pkg_postinst_ontarget() or call - postinst-intercepts defer_to_first_boot + postinst_intercept delay_to_first_boot from pkg_postinst(). Any failure of a pkg_postinst() script (including exit 1) @@ -6192,7 +6192,7 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message. If you want to explicitly defer a postinstall to first boot on the target rather than at rootfs creation time, use pkg_postinst_ontarget() or call - postinst-intercepts defer_to_first_boot from + postinst_intercept delay_to_first_boot from pkg_postinst(). Any failure of a pkg_postinst() script (including exit 1) triggers an error during the @@ -7095,6 +7095,207 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message. + +
+ Moving to the Yocto Project 3.1 Release + + + This section provides migration information for moving to the + Yocto Project 3.1 Release from the prior release. + + +
+ Minimum system requirements + + + The following versions / requirements of build host components have been updated: + + gcc 5.0 + python 3.5 + tar 1.28 + rpcgen is now required on the host (part of the libc-dev-bin package on Ubuntu, Debian and related distributions, and the glibc package on RPM-based distributions). + + + Additionally, the makeinfo and pod2man + tools are no longer required on the host. + +
+ +
+ mpc8315e-rdb machine removed + + + The MPC8315E-RDB machine is old/obsolete and unobtainable, thus given the maintenance burden + the mpc8315e-rdb machine configuration that supported it has been removed + in this release. The removal does leave a gap in official PowerPC reference hardware + support; this may change in future if a suitable machine with accompanying support resources + is found. + +
+ +
+ Python 2 removed + + + Due to the expiration of upstream support in January 2020, support for Python 2 has now been removed; it is recommended that you use Python 3 instead. If absolutely needed there is a meta-python2 community layer containing Python 2, related classes and various Python 2-based modules, however it should not be considered as supported. + +
+ +
+ Reproducible builds now enabled by default + + + In order to avoid unnecessary differences in output files (aiding binary reproducibility), the Poky distribution configuration (DISTRO = "poky") now inherits the reproducible_build class by default. + +
+ +
+ Impact of ptest feature is now more significant + + + The Poky distribution configuration (DISTRO = "poky") enables ptests by default to enable runtime testing of various components. In this release, a dependency needed to be added that has resulted in a significant increase in the number of components that will be built just when building a simple image such as core-image-minimal. If you do not need runtime tests enabled for core components, then it is recommended that you remove "ptest" from DISTRO_FEATURES to save a significant amount of build time e.g. by adding the following in your configuration: + + + DISTRO_FEATURES_remove = "ptest" + + +
+ +
+ Removed recipes + + + The following recipes have been removed: + + + chkconfig: obsolete + console-tools: obsolete + enchant: replaced by enchant2 + foomatic-filters: obsolete + libidn: no longer needed, moved to meta-oe + libmodulemd: replaced by libmodulemd-v1 + linux-yocto: drop 4.19, 5.2 version recipes (5.4 now provided) + nspr: no longer needed, moved to meta-oe + nss: no longer needed, moved to meta-oe + python: Python 2 removed (Python 3 preferred) + python-setuptools: Python 2 version removed (python3-setuptools preferred) + sysprof: no longer needed, moved to meta-oe + texi2html: obsolete + u-boot-fw-utils: functionally replaced by libubootenv + + +
+ +
+ features_check class replaces distro_features_check + + + The distro_features_check class has had its functionality expanded, now supporting ANY_OF_MACHINE_FEATURES, REQUIRED_MACHINE_FEATURES, CONFLICT_MACHINE_FEATURES, ANY_OF_COMBINED_FEATURES, REQUIRED_COMBINED_FEATURES, CONFLICT_COMBINED_FEATURES. As a result the class has now been renamed to features_check; the distro_features_check class still exists but generates a warning and redirects to the new class. In preparation for a future removal of the old class it is recommended that you update recipes currently inheriting distro_features_check to inherit features_check instead. + +
+ +
+ Removed classes + + + The following classes have been removed: + + + distutils-base: moved to meta-python2 + distutils: moved to meta-python2 + libc-common: merged into the glibc recipe as nothing else used it. + python-dir: moved to meta-python2 + pythonnative: moved to meta-python2 + setuptools: moved to meta-python2 + tinderclient: dropped as it was obsolete. + + +
+ +
+ SRC_URI checksum behaviour + + + Previously, recipes by tradition included both SHA256 and MD5 checksums for remotely fetched files in SRC_URI, even though only one is actually mandated. However, the MD5 checksum does not add much given its inherent weakness; thus when a checksum fails only the SHA256 sum will now be printed. The md5sum will still be verified if it is specified. + +
+ + +
+ npm fetcher changes + + + The npm fetcher has been completely reworked in this release. The npm fetcher now only fetches the package source itself and no longer the dependencies; there is now also an npmsw fetcher which explicitly fetches the shrinkwrap file and the dependencies. This removes the slightly awkward NPM_LOCKDOWN and NPM_SHRINKWRAP variables which pointed to local files; the lockdown file is no longer needed at all. Additionally, the package name in npm:// entries in SRC_URI is now specified using a package parameter instead of the earlier name which overlapped with the generic name parameter. All recipes using the npm fetcher will need to be changed as a result. + + + An example of the new scheme: + +SRC_URI = "npm://registry.npmjs.org;package=array-flatten;version=1.1.1 \ + npmsw://${THISDIR}/npm-shrinkwrap.json" + + Another example where the sources are fetched from git rather than an npm repository: + +SRC_URI = "git://github.com/foo/bar.git;protocol=https \ + npmsw://${THISDIR}/npm-shrinkwrap.json" + + + + devtool and recipetool have also been updated to match with the npm fetcher changes. Other than producing working and more complete recipes for npm sources, there is also a minor change to the command line for devtool: the --fetch-dev option has been renamed to --npm-dev as it is npm-specific. + +
+ + +
+ Packaging changes + + + + intltool has been removed from packagegroup-core-sdk as it is rarely needed to build modern software - gettext can do most of the things it used to be needed for. intltool has also been removed from packagegroup-core-self-hosted as it is not needed to for standard builds. + git: git-am, git-difftool, git-submodule, and git-request-pull are no longer perl-based, so are now installed with the main git package instead of within git-perltools. + The ldconfig binary built as part of glibc has now been moved to its own ldconfig package (note no glibc- prefix). This package is in the RRECOMMENDS of the main glibc package if ldconfig is present in DISTRO_FEATURES. + libevent now splits each shared library into its own package (as Debian does). Since these are shared libraries and will be pulled in through the normal shared library dependency handling, there should be no impact to existing configurations other than less unnecessary libraries being installed in some cases. + linux-firmware now has a new package for bcm4366c and includes available NVRAM config files into the bcm43340, bcm43362, bcm43430 and bcm4356-pcie packages. + harfbuzz now splits the new libharfbuzz-subset.so library into its own package to reduce the main package size in cases where libharfbuzz-subset.so is not needed. + + +
+ +
+ Additional warnings + + + Warnings will now be shown at do_package_qa time in the following circumstances: + + + A recipe installs .desktop files containing MimeType keys but does not inherit the new mime-xdg class + A recipe installs .xml files into ${datadir}/mime/packages but does not inherit the mime class + + +
+ +
+ <filename>wic</filename> image type now used instead of <filename>live</filename> by default for x86 + + + conf/machine/include/x86-base.inc (inherited by most x86 machine configurations) now specifies wic instead of live by default in IMAGE_FSTYPES. The live image type will likely be removed in a future release so it is recommended that you use wic instead. + +
+ +
+ Miscellaneous changes + + + + The undocumented SRC_DISTRIBUTE_LICENSES variable has now been removed in favour of a new AVAILABLE_LICENSES variable which is dynamically set based upon license files found in ${COMMON_LICENSE_DIR} and ${LICENSE_PATH}. + The tune definition for big-endian microblaze machines is now microblaze instead of microblazeeb. + newlib no longer has built-in syscalls. libgloss should then provide the syscalls, crt0.o and other functions that are no longer part of newlib itself. If you are using TCLIBC = "newlib" this now means that you must link applications with both newlib and libgloss, whereas before newlib would run in many configurations by itself. + + +
+ +
+ + + + List of licenses found in the directories specified + by COMMON_LICENSE_DIR + and LICENSE_PATH. + + + It is assumed that all changes + to COMMON_LICENSE_DIR + and LICENSE_PATH have been done + before AVAILABLE_LICENSES is + defined + (in license.bbclass). + + + + + AVAILTUNES AVAILTUNES[doc] = "The list of defined CPU and Application Binary Interface (ABI) tunings (i.e. "tunes") available for use by the OpenEmbedded build system." @@ -1423,7 +1447,7 @@ Use the following format to export the variable to the BitBake environment: - export BBSERVER=localhost:$port" + export BBSERVER=localhost:$port @@ -3786,7 +3810,7 @@ It is not intended to be user-configurable. It is best to just reference the variable to see which distro features are being backfilled for all distro configurations. - See the Feature Backfilling section for + See the "Feature Backfilling" section for more information. @@ -6750,6 +6774,25 @@ components that are required to produce a functional system image. + + Tips + It is possible to define a list of licenses that are allowed + to be used instead of the licenses that are excluded. To do + this, define a + variable COMPATIBLE_LICENSES with the + names of the licences that are allowed. Then + define INCOMPATIBLE_LICENSE as: + + INCOMPATIBLE_LICENSE = "${@' '.join(sorted(set(d.getVar('AVAILABLE_LICENSES').split()) - set(d.getVar('COMPATIBLE_LICENSES').split())))}" + + This will result + in INCOMPATIBLE_LICENSE containing the + names of all licences + from AVAILABLE_LICENSES + except the ones specified + in COMPATIBLE_LICENSES, thus only + allowing the latter licences to be used. + @@ -7428,7 +7471,6 @@ KBRANCH_genericx86-64 = "standard/base" KBRANCH_edgerouter = "standard/edgerouter" KBRANCH_beaglebone = "standard/beaglebone" - KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb" The KBRANCH statements identify the kernel branch to use when building for each @@ -8746,7 +8788,6 @@ MACHINE ?= "genericx86" MACHINE ?= "genericx86-64" MACHINE ?= "beaglebone" - MACHINE ?= "mpc8315e-rdb" MACHINE ?= "edgerouter" The last five are Yocto Project reference hardware boards, which @@ -10376,12 +10417,20 @@ PACKAGECONFIG blocks are defined in recipes when you specify features and then arguments that define feature behaviors. - Here is the basic block structure: + Here is the basic block structure (broken over multiple + lines for readability): PACKAGECONFIG ??= "f1 f2 f3 ..." - PACKAGECONFIG[f1] = "--with-f1,--without-f1,build-deps-f1,rt-deps-f1,rt-recs-f1" - PACKAGECONFIG[f2] = "--with-f2,--without-f2,build-deps-f2,rt-deps-f2,rt-recs-f2" - PACKAGECONFIG[f3] = "--with-f3,--without-f3,build-deps-f3,rt-deps-f3,rt-recs-f3" + PACKAGECONFIG[f1] = "\ + --with-f1, \ + --without-f1, \ + build-deps-for-f1, \ + runtime-deps-for-f1, \ + runtime-recommends-for-f1, \ + packageconfig-conflicts-for-f1 \ + " + PACKAGECONFIG[f2] = "\ + ... and so on and so on ... @@ -10390,7 +10439,7 @@ variable itself specifies a space-separated list of the features to enable. Following the features, you can determine the behavior of - each feature by providing up to five order-dependent + each feature by providing up to six order-dependent arguments, which are separated by commas. You can omit any argument you like but must retain the separating commas. @@ -10420,6 +10469,10 @@ (RRECOMMENDS) that should be added if the feature is enabled. + Any conflicting (that is, mutually + exclusive) PACKAGECONFIG + settings for this feature. + @@ -10427,25 +10480,23 @@ Consider the following PACKAGECONFIG block taken from the librsvg recipe. - In this example the feature is croco, + In this example the feature is gtk, which has three arguments that determine the feature's behavior. - PACKAGECONFIG ??= "croco" - PACKAGECONFIG[croco] = "--with-croco,--without-croco,libcroco" + PACKAGECONFIG[gtk] = "--with-gtk3,--without-gtk3,gtk+3" - The --with-croco and - libcroco arguments apply only if + The --with-gtk3 and + gtk+3 arguments apply only if the feature is enabled. - In this case, --with-croco is + In this case, --with-gtk3 is added to the configure script argument list and - libcroco is added to + gtk+3 is added to DEPENDS. On the other hand, if the feature is disabled say through a .bbappend file in another layer, then - the second argument --without-croco is - added to the configure script rather than - --with-croco. + the second argument --without-gtk3 is + added to the configure script instead. @@ -11054,7 +11105,7 @@ PN - PN[doc] = "PN refers to a recipe name in the context of a file used by the OpenEmbedded build system as input to create a package. + PN[doc] = "PN refers to a recipe name in the context of a file used by the OpenEmbedded build system as input to create a package." @@ -11501,23 +11552,35 @@ By default, a recipe's own PN is implicitly already in its PROVIDES - list. + list and therefore does not need to mention that it provides itself. If a recipe uses PROVIDES, the additional aliases are synonyms for the recipe and can - be useful satisfying dependencies of other recipes during + be useful for satisfying dependencies of other recipes during the build as specified by DEPENDS. Consider the following example - PROVIDES statement from a recipe - file libav_0.8.11.bb: + PROVIDES statement from the recipe + file eudev_3.2.9.bb: - PROVIDES += "libpostproc" + PROVIDES = "udev" The PROVIDES statement results in - the "libav" recipe also being known as "libpostproc". + the "eudev" recipe also being available as simply "udev". + + + Given that a recipe's own recipe name is already + implicitly in its own PROVIDES list, + it is unnecessary to add aliases with the "+=" operator; + using a simple assignment will be sufficient. In other + words, while you could write: + + PROVIDES += "udev" + + in the above, the "+=" is overkill and unnecessary. + @@ -13383,8 +13446,7 @@ SKIP_FILEDEPS - SKIP_FILEDEPS[doc] = "Enables you to remove all files from - the "Provides" section of an RPM package." + SKIP_FILEDEPS[doc] = "Enables you to remove all files from the 'Provides' section of an RPM package." @@ -15331,7 +15393,7 @@ TCLIBC - TCLIBC[doc] = "Specifies GNU standard C library (libc) variant to use during the build process. You can select 'glibc', 'musl' or "newlib." + TCLIBC[doc] = "Specifies GNU standard C library (libc) variant to use during the build process. You can select 'glibc', 'musl' or 'newlib'." @@ -15646,9 +15708,9 @@ Specifies the target controller to use when running tests against a test image. - The default controller to use is "QemuTarget": + The default controller to use is "qemu": - TEST_TARGET = "QemuTarget" + TEST_TARGET = "qemu" @@ -15667,21 +15729,21 @@ You can provide the following arguments with TEST_TARGET: - "QemuTarget": + "qemu": Boots a QEMU image and runs the tests. See the "Enabling Runtime Tests on QEMU" section in the Yocto Project Development Tasks Manual for more information. - "SimpleRemoteTarget": + "simpleremote": Runs the tests on target hardware that is already up and running. The hardware can be on the network or it can be a device running an image on QEMU. You must also set TEST_TARGET_IP - when you use "SimpleRemoteTarget". + when you use "simpleremote". This argument is defined in meta/lib/oeqa/controllers/simpleremote.py. @@ -16473,7 +16535,7 @@ Appends a string to the name of the local version of the U-Boot image. For example, assuming the version of the U-Boot image - built was "2013.10, the full version string reported by + built was "2013.10", the full version string reported by U-Boot would be "2013.10-yocto" given the following statement: @@ -16771,18 +16833,21 @@ USERADD_ERROR_DYNAMIC - USERADD_ERROR_DYNAMIC[doc] = "If set to 'error', forces the OpenEmbedded build system to produce an error if the user identification (uid) and group identification (gid) values are not defined in files/passwd and files/group files. If set to 'warn', a warning will be issued instead." + USERADD_ERROR_DYNAMIC[doc] = "If set to 'error', forces the OpenEmbedded build system to produce an error if the user identification (uid) and group identification (gid) values are not defined in any of the files listed in USERADD_UID_TABLES and USERADD_GID_TABLES. If set to 'warn', a warning will be issued instead." - If set to "error", forces the OpenEmbedded build system to - produce an error if the user identification - (uid) and group identification - (gid) values are not defined - in files/passwd - and files/group files. - If set to "warn", a warning will be issued instead. + + If set to error, forces the + OpenEmbedded build system to produce an error if the user + identification (uid) and group + identification (gid) values are not + defined in any of the files listed + in USERADD_UID_TABLES + and USERADD_GID_TABLES. If + set to warn, a warning will be issued + instead. @@ -16809,6 +16874,20 @@ USERADD_GID_TABLES variables. + + + There is a difference in behavior between + setting USERADD_ERROR_DYNAMIC + to error and setting it + to warn. When it is set + to warn, the build system will report a + warning for every undefined uid and + gid in any recipe. But when it is set + to error, it will only report errors + for recipes that are actually built. This saves you from + having to add static IDs for recipes that you know will + never be built. + @@ -17108,7 +17187,7 @@ "Creating Partitioned Images Using Wic" section in the Yocto Project Development Tasks Manual. For details on the kickstart file format, see the - "OpenEmbedded Kickstart (.wks) Reference + "OpenEmbedded Kickstart (.wks) Reference" Chapter. @@ -17178,8 +17257,7 @@ XSERVER - XSERVER[doc] = "Specifies the packages that should be installed - to provide an X server and drivers for the current machine." + XSERVER[doc] = "Specifies the packages that should be installed to provide an X server and drivers for the current machine." diff --git a/poky/documentation/sdk-manual/sdk-appendix-obtain.xml b/poky/documentation/sdk-manual/sdk-appendix-obtain.xml index 765c0f218e..86b6d7dd07 100644 --- a/poky/documentation/sdk-manual/sdk-appendix-obtain.xml +++ b/poky/documentation/sdk-manual/sdk-appendix-obtain.xml @@ -297,8 +297,7 @@ arch is a string representing the target architecture: beaglebone-yocto, beaglebone-yocto-lsb, edgerouter, edgerouter-lsb, - genericx86, genericx86-64, genericx86-64-lsb, genericx86-lsb, - mpc8315e-rdb, mpc8315e-rdb-lsb, and qemu*. + genericx86, genericx86-64, genericx86-64-lsb, genericx86-lsb and qemu*. date_time is a date and time stamp. diff --git a/poky/documentation/sdk-manual/sdk-manual.xml b/poky/documentation/sdk-manual/sdk-manual.xml old mode 100644 new mode 100755 index 8d5f6ec4d6..537663dade --- a/poky/documentation/sdk-manual/sdk-manual.xml +++ b/poky/documentation/sdk-manual/sdk-manual.xml @@ -22,11 +22,10 @@ - Scott Rifenbark - Scotty's Documentation Services, INC + &ORGNAME; - srifenbark@gmail.com + &ORGEMAIL; @@ -34,7 +33,7 @@ 2.1 April 2016 - Released with the Yocto Project 2.1 Release. + The initial document released with the Yocto Project 2.1 Release. 2.2 @@ -68,9 +67,14 @@ 3.0 - &REL_MONTH_YEAR; + October 2019 Released with the Yocto Project 3.0 Release. + + 3.1 + &REL_MONTH_YEAR; + Released with the Yocto Project 3.1 Release. + @@ -92,7 +96,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - Yocto Project documentation page + Yocto Project documentation page and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -109,18 +113,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - Yocto Project documentation page + Yocto Project documentation page and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. - + + To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - yocto@yoctoproject.com or log into - the freenode #yocto channel. - + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + docs@lists.yoctoproject.org or + log into the freenode #yocto channel. + + diff --git a/poky/documentation/toaster-manual/toaster-manual.xml b/poky/documentation/toaster-manual/toaster-manual.xml old mode 100644 new mode 100755 index d7b4bcee61..e6d4245231 --- a/poky/documentation/toaster-manual/toaster-manual.xml +++ b/poky/documentation/toaster-manual/toaster-manual.xml @@ -22,11 +22,10 @@ - Kristi Rifenbark - Scotty's Documentation Services, INC + &ORGNAME; - kristi@buzzcollectivemarketing.com + &ORGEMAIL; @@ -34,7 +33,7 @@ 1.8 April 2015 - Released with the Yocto Project 1.8 Release. + The initial document released with the Yocto Project 1.8 Release. 2.0 @@ -78,9 +77,14 @@ 3.0 - &REL_MONTH_YEAR; + October 2019 Released with the Yocto Project 3.0 Release. + + 3.1 + &REL_MONTH_YEAR; + Released with the Yocto Project 3.1 Release. + @@ -102,7 +106,7 @@ Yocto Project. To be sure you have the latest version of the manual for this release, go to the - Yocto Project documentation page + Yocto Project documentation page and select the manual from that site. Manuals from the site are more up-to-date than manuals derived from the Yocto Project released TAR files. @@ -119,18 +123,20 @@ page. If you need a version of this manual for a different Yocto Project release, visit the - Yocto Project documentation page + Yocto Project documentation page and select the manual set by using the "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE" pull-down menus. - + + To report any inaccuracies or problems with this - manual, send an email to the Yocto Project - discussion group at - yocto@yoctoproject.com or log into - the freenode #yocto channel. - + (or any other Yocto Project) manual, send an email to + the Yocto Project documentation mailing list at + docs@lists.yoctoproject.org or + log into the freenode #yocto channel. + + diff --git a/poky/documentation/tools/mega-manual.sed b/poky/documentation/tools/mega-manual.sed index 374d8e7b00..b1ea9edb7b 100644 --- a/poky/documentation/tools/mega-manual.sed +++ b/poky/documentation/tools/mega-manual.sed @@ -1,36 +1,36 @@ # Processes bitbake-user-manual (-- style). # This style is for manual three-word folders, which currently is only the BitBake User Manual. # We used to have the "yocto-project-qs" and "poky-ref-manual" folders but no longer do. -# s@"ulink" href="http://www.yoctoproject.org/docs/3.0/[a-z]*-[a-z]*-[a-z]*/[a-z]*-[a-z]*-[a-z]*.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/3.0/bitbake-user-manual/bitbake-user-manual.html#@"link" href="#@g +# s@"ulink" href="http://www.yoctoproject.org/docs/3.1/[a-z]*-[a-z]*-[a-z]*/[a-z]*-[a-z]*-[a-z]*.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1/bitbake-user-manual/bitbake-user-manual.html#@"link" href="#@g # Processes all other manuals (- style). # This style is for manual folders that use two word, which is the standard now (e.g. "ref-manual"). # Here is the one-liner: -# s@"ulink" href="http://www.yoctoproject.org/docs/3.0/[a-z]*-[a-z]*/[a-z]*-[a-z]*.html#@"link" href="#@g +# s@"ulink" href="http://www.yoctoproject.org/docs/3.1/[a-z]*-[a-z]*/[a-z]*-[a-z]*.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/3.0/sdk-manual/sdk-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/3.0/bsp-guide/bsp-guide.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/3.0/dev-manual/dev-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/3.0/overview-manual/overview-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/3.0/brief-yoctoprojectqs/brief-yoctoprojectqs.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/3.0/kernel-dev/kernel-dev.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/3.0/profile-manual/profile-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/3.0/ref-manual/ref-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/3.0/toaster-manual/toaster-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1/sdk-manual/sdk-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1/bsp-guide/bsp-guide.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1/dev-manual/dev-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1/overview-manual/overview-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1/kernel-dev/kernel-dev.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1/profile-manual/profile-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/3.1/toaster-manual/toaster-manual.html#@"link" href="#@g # Process cases where just an external manual is referenced without an id anchor -s@Yocto Project Quick Build@Yocto Project Quick Build@g -s@BitBake User Manual@BitBake User Manual@g -s@Yocto Project Development Tasks Manual@Yocto Project Development Tasks Manual@g -s@Yocto Project Overview and Concepts Manual@Yocto project Overview and Concepts Manual@g -s@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@g -s@Yocto Project Board Support Package (BSP) Developer's Guide@Yocto Project Board Support Package (BSP) Developer's Guide@g -s@Yocto Project Profiling and Tracing Manual@Yocto Project Profiling and Tracing Manual@g -s@Yocto Project Linux Kernel Development Manual@Yocto Project Linux Kernel Development Manual@g -s@Yocto Project Reference Manual@Yocto Project Reference Manual@g -s@Toaster User Manual@Toaster User Manual@g +s@Yocto Project Quick Build@Yocto Project Quick Build@g +s@BitBake User Manual@BitBake User Manual@g +s@Yocto Project Development Tasks Manual@Yocto Project Development Tasks Manual@g +s@Yocto Project Overview and Concepts Manual@Yocto project Overview and Concepts Manual@g +s@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@g +s@Yocto Project Board Support Package (BSP) Developer's Guide@Yocto Project Board Support Package (BSP) Developer's Guide@g +s@Yocto Project Profiling and Tracing Manual@Yocto Project Profiling and Tracing Manual@g +s@Yocto Project Linux Kernel Development Manual@Yocto Project Linux Kernel Development Manual@g +s@Yocto Project Reference Manual@Yocto Project Reference Manual@g +s@Toaster User Manual@Toaster User Manual@g # Process a single, rouge occurrence of a linked reference to the Mega-Manual. -s@Yocto Project Mega-Manual@Yocto Project Mega-Manual@g +s@Yocto Project Mega-Manual@Yocto Project Mega-Manual@g -- cgit v1.2.3