build-appliance-image: Update to dunfell head revision

(From OE-Core rev: 8e81d38048c953d0823abf04d5b2506cd988f0bb)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

README.OE-Core

@@ -6,24 +6,24 @@ of OpenEmbedded. It is distro-less (can build a functional image with
 DISTRO = "nodistro") and contains only emulated machine support.
 
 For information about OpenEmbedded, see the OpenEmbedded website:
-    http://www.openembedded.org/
+    https://www.openembedded.org/
 
 The Yocto Project has extensive documentation about OE including a reference manual
 which can be found at:
-    http://yoctoproject.org/documentation
+    https://docs.yoctoproject.org/
 
 
 Contributing
 ------------
 
 Please refer to
-http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
+https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
 for guidelines on how to submit patches.
 
 Mailing list:
 
-    http://lists.openembedded.org/mailman/listinfo/openembedded-core
+    https://lists.openembedded.org/g/openembedded-core
 
 Source code:
 
-    http://git.openembedded.org/openembedded-core/
+    https://git.openembedded.org/openembedded-core/

bitbake/bin/bitbake-worker

@@ -413,9 +413,9 @@ class BitbakeWorker(object):
 
     def handle_workerdata(self, data):
         self.workerdata = pickle.loads(data)
+        bb.build.verboseShellLogging = self.workerdata["build_verbose_shell"]
+        bb.build.verboseStdoutLogging = self.workerdata["build_verbose_stdout"]
         bb.msg.loggerDefaultLogLevel = self.workerdata["logdefaultlevel"]
-        bb.msg.loggerDefaultVerbose = self.workerdata["logdefaultverbose"]
-        bb.msg.loggerVerboseLogs = self.workerdata["logdefaultverboselogs"]
         bb.msg.loggerDefaultDomains = self.workerdata["logdefaultdomain"]
         for mc in self.databuilder.mcdata:
             self.databuilder.mcdata[mc].setVar("PRSERV_HOST", self.workerdata["prhost"])
@@ -505,9 +505,11 @@ except BaseException as e:
         import traceback
         sys.stderr.write(traceback.format_exc())
         sys.stderr.write(str(e))
+finally:
+    worker_thread_exit = True
+    worker_thread.join()
 
-worker_thread_exit = True
-worker_thread.join()
-
-workerlog_write("exitting")
+workerlog_write("exiting")
+if not normalexit:
+    sys.exit(1)
 sys.exit(0)

bitbake/doc/.gitignore

@@ -0,0 +1 @@
+_build/

bitbake/doc/Makefile

@@ -1,91 +1,35 @@
-# This is a single Makefile to handle all generated BitBake documents.
-# The Makefile needs to live in the documentation directory and all figures used
-# in any manuals must be .PNG files and live in the individual book's figures
-# directory.
-#
-# The Makefile has these targets:
-#
-#    pdf:      generates a PDF version of a manual.
-#    html:     generates an HTML version of a manual.
-#    tarball:  creates a tarball for the doc files.
-#    validate: validates
-#    clean:    removes files
-#
-# The Makefile generates an HTML version of every document.  The
-# variable DOC indicates the folder name for a given manual.
-#
-# To build a manual, you must invoke 'make' with the DOC argument.
-#
-# Examples:
-#
-#     make DOC=bitbake-user-manual
-#     make pdf DOC=bitbake-user-manual
-#
-# The first example generates the HTML version of the User Manual.
-# The second example generates the PDF version of the User Manual.
+# Minimal makefile for Sphinx documentation
 #
 
-ifeq ($(DOC),bitbake-user-manual)
-XSLTOPTS = --stringparam html.stylesheet bitbake-user-manual-style.css \
-           --stringparam  chapter.autolabel 1 \
-           --stringparam  section.autolabel 1 \
-           --stringparam  section.label.includes.component.label 1 \
-           --xinclude
-ALLPREQ = html tarball
-TARFILES = bitbake-user-manual-style.css bitbake-user-manual.html figures/bitbake-title.png
-MANUALS = $(DOC)/$(DOC).html
-FIGURES = figures
-STYLESHEET = $(DOC)/*.css
+# You can set these variables from the command line, and also
+# from the environment for the first two.
+SPHINXOPTS    ?=
+SPHINXBUILD   ?= sphinx-build
+SOURCEDIR     = .
+BUILDDIR      = _build
+DESTDIR       = final
 
+ifeq ($(shell if which $(SPHINXBUILD) >/dev/null 2>&1; then echo 1; else echo 0; fi),0)
+$(error "The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed")
 endif
 
-##
-# These URI should be rewritten by your distribution's xml catalog to
-# match your localy installed XSL stylesheets.
-XSL_BASE_URI  = http://docbook.sourceforge.net/release/xsl/current
-XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
+# Put it first so that "make" without argument is like "make help".
+help:
+	@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
 
-all: $(ALLPREQ)
+.PHONY: help Makefile clean publish
 
-pdf:
-ifeq ($(DOC),bitbake-user-manual)
-	@echo " "
-	@echo "********** Building."$(DOC)
-	@echo " "
-	cd $(DOC); ../tools/docbook-to-pdf $(DOC).xml ../template; cd ..
-endif
-
-html:
-ifeq ($(DOC),bitbake-user-manual)
-#       See http://www.sagehill.net/docbookxsl/HtmlOutput.html
-	@echo " "
-	@echo "******** Building "$(DOC)
-	@echo " "
-	cd $(DOC); xsltproc $(XSLTOPTS) -o $(DOC).html $(DOC)-customization.xsl $(DOC).xml; cd ..
-endif
-
-tarball: html
-	@echo " "
-	@echo "******** Creating Tarball of document files"
-	@echo " "
-	cd $(DOC); tar -cvzf $(DOC).tgz $(TARFILES); cd ..
-
-validate:
-	cd $(DOC); xmllint --postvalid --xinclude --noout $(DOC).xml; cd ..
-
-publish:
-	@if test -f $(DOC)/$(DOC).html; \
-	  then \
-            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); \
-	else \
-          echo " "; \
-          echo $(DOC)".html missing.  Generate the file first then try again."; \
-          echo " "; \
-	fi
+publish: Makefile html singlehtml
+	rm -rf $(BUILDDIR)/$(DESTDIR)/
+	mkdir -p $(BUILDDIR)/$(DESTDIR)/
+	cp -r $(BUILDDIR)/html/* $(BUILDDIR)/$(DESTDIR)/
+	cp $(BUILDDIR)/singlehtml/index.html $(BUILDDIR)/$(DESTDIR)/singleindex.html
+	sed -i -e 's@index.html#@singleindex.html#@g' $(BUILDDIR)/$(DESTDIR)/singleindex.html
 
 clean:
-	rm -rf $(MANUALS); rm $(DOC)/$(DOC).tgz;
+	@rm -rf $(BUILDDIR)
+
+# Catch-all target: route all unknown targets to Sphinx using the new
+# "make mode" option.  $(O) is meant as a shortcut for $(SPHINXOPTS).
+%: Makefile
+	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

bitbake/doc/README

@@ -15,25 +15,41 @@ Each folder is self-contained regarding content and figures.
 If you want to find HTML versions of the BitBake manuals on the web, 
 go to http://www.openembedded.org/wiki/Documentation. 
 
-Makefile
-========
+Sphinx
+======
 
-The Makefile processes manual directories to create HTML, PDF,
-tarballs, etc.  Details on how the Makefile work are documented
-inside the Makefile.  See that file for more information.
+The BitBake documentation was migrated from the original DocBook
+format to Sphinx based documentation for the Yocto Project 3.2
+release.
 
-To build a manual, you run the make command and pass it the name
-of the folder containing the manual's contents. 
-For example, the following command run from the documentation directory 
-creates an HTML and a PDF version of the BitBake User Manual.
-The DOC variable specifies the manual you are making:
+Additional information related to the Sphinx migration, and guidelines
+for developers willing to contribute to the BitBake documentation can
+be found in the Yocto Project Documentation README file:
 
-     $ make DOC=bitbake-user-manual
+https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/tree/documentation/README
 
-template
-========
-Contains various templates, fonts, and some old PNG files.
+How to build the Yocto Project documentation
+============================================
 
-tools
-=====
-Contains a tool to convert the DocBook files to PDF format.
+Sphinx is written in Python. While it might work with Python2, for
+obvious reasons, we will only support building the BitBake
+documentation with Python3.
+
+Sphinx might be available in your Linux distro packages repositories,
+however it is not recommend using distro packages, as they might be
+old versions, especially if you are using an LTS version of your
+distro. The recommended method to install Sphinx and all required
+dependencies is to use the Python Package Index (pip).
+
+To install all required packages run:
+
+ $ pip3 install sphinx sphinx_rtd_theme pyyaml
+
+To build the documentation locally, run:
+
+ $ cd documentation
+ $ make html
+
+The resulting HTML index page will be _build/html/index.html, and you
+can browse your own copy of the locally generated documentation with
+your browser.

bitbake/doc/_templates/breadcrumbs.html

@@ -0,0 +1,14 @@
+{% extends "!breadcrumbs.html" %}
+
+{% block breadcrumbs %}
+    <li>
+      <span class="doctype_switcher_placeholder">{{ doctype or 'single' }}</span>
+      <span class="version_switcher_placeholder">{{ release }}</span>
+    </li>
+    <li> &raquo;</li>
+    {% for doc in parents %}
+      <li><a href="{{ doc.link|e }}">{{ doc.title }}</a> &raquo;</li>
+    {% endfor %}
+    <li>{{ title }}</li>
+{% endblock %}
+

bitbake/doc/_templates/layout.html

@@ -0,0 +1,7 @@
+{% extends "!layout.html" %}
+
+{% block extrabody %}
+<div id="outdated-warning" style="text-align: center; background-color: #FFBABA; color: #6A0E0E;">
+</div>
+{% endblock %}
+

bitbake/doc/bitbake-user-manual/bitbake-user-manual-customization.xsl

@@ -1,29 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
-
-  <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
-
-<!--
-
-  <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
-
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
-
--->
-
-  <xsl:include href="../template/permalinks.xsl"/>
-  <xsl:include href="../template/section.title.xsl"/>
-  <xsl:include href="../template/component.title.xsl"/>
-  <xsl:include href="../template/division.title.xsl"/>
-  <xsl:include href="../template/formal.object.heading.xsl"/>
-  <xsl:include href="../template/gloss-permalinks.xsl"/>
-
-  <xsl:param name="html.stylesheet" select="'user-manual-style.css'" />
-  <xsl:param name="chapter.autolabel" select="1" />
-  <xsl:param name="section.autolabel" select="1" />
-  <xsl:param name="section.label.includes.component.label" select="1" />
-  <xsl:param name="appendix.autolabel">A</xsl:param>
-
-<!--  <xsl:param name="generate.toc" select="'article nop'"></xsl:param>  -->
-
-</xsl:stylesheet>

bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.rst

@@ -0,0 +1,733 @@
+.. SPDX-License-Identifier: CC-BY-2.5
+
+=========
+Execution
+=========
+
+|
+
+The primary purpose for running BitBake is to produce some kind of
+output such as a single installable package, a kernel, a software
+development kit, or even a full, board-specific bootable Linux image,
+complete with bootloader, kernel, and root filesystem. Of course, you
+can execute the ``bitbake`` command with options that cause it to
+execute single tasks, compile single recipe files, capture or clear
+data, or simply return information about the execution environment.
+
+This chapter describes BitBake's execution process from start to finish
+when you use it to create an image. The execution process is launched
+using the following command form: ::
+
+  $ bitbake target
+
+For information on
+the BitBake command and its options, see ":ref:`The BitBake Command
+<bitbake-user-manual-command>`" section.
+
+.. note::
+
+   Prior to executing BitBake, you should take advantage of available
+   parallel thread execution on your build host by setting the
+   :term:`BB_NUMBER_THREADS` variable in
+   your project's ``local.conf`` configuration file.
+
+   A common method to determine this value for your build host is to run
+   the following: ::
+
+     $ grep processor /proc/cpuinfo
+
+   This command returns
+   the number of processors, which takes into account hyper-threading.
+   Thus, a quad-core build host with hyper-threading most likely shows
+   eight processors, which is the value you would then assign to
+   ``BB_NUMBER_THREADS``.
+
+   A possibly simpler solution is that some Linux distributions (e.g.
+   Debian and Ubuntu) provide the ``ncpus`` command.
+
+Parsing the Base Configuration Metadata
+=======================================
+
+The first thing BitBake does is parse base configuration metadata. Base
+configuration metadata consists of your project's ``bblayers.conf`` file
+to determine what layers BitBake needs to recognize, all necessary
+``layer.conf`` files (one from each layer), and ``bitbake.conf``. The
+data itself is of various types:
+
+-  **Recipes:** Details about particular pieces of software.
+
+-  **Class Data:** An abstraction of common build information (e.g. how to
+   build a Linux kernel).
+
+-  **Configuration Data:** Machine-specific settings, policy decisions,
+   and so forth. Configuration data acts as the glue to bind everything
+   together.
+
+The ``layer.conf`` files are used to construct key variables such as
+:term:`BBPATH` and :term:`BBFILES`.
+``BBPATH`` is used to search for configuration and class files under the
+``conf`` and ``classes`` directories, respectively. ``BBFILES`` is used
+to locate both recipe and recipe append files (``.bb`` and
+``.bbappend``). If there is no ``bblayers.conf`` file, it is assumed the
+user has set the ``BBPATH`` and ``BBFILES`` directly in the environment.
+
+Next, the ``bitbake.conf`` file is located using the ``BBPATH`` variable
+that was just constructed. The ``bitbake.conf`` file may also include
+other configuration files using the ``include`` or ``require``
+directives.
+
+Prior to parsing configuration files, BitBake looks at certain
+variables, including:
+
+-  :term:`BB_ENV_WHITELIST`
+-  :term:`BB_ENV_EXTRAWHITE`
+-  :term:`BB_PRESERVE_ENV`
+-  :term:`BB_ORIGENV`
+-  :term:`BITBAKE_UI`
+
+The first four variables in this list relate to how BitBake treats shell
+environment variables during task execution. By default, BitBake cleans
+the environment variables and provides tight control over the shell
+execution environment. However, through the use of these first four
+variables, you can apply your control regarding the environment
+variables allowed to be used by BitBake in the shell during execution of
+tasks. See the
+":ref:`bitbake-user-manual/bitbake-user-manual-metadata:Passing Information Into the Build Task Environment`"
+section and the information about these variables in the variable
+glossary for more information on how they work and on how to use them.
+
+The base configuration metadata is global and therefore affects all
+recipes and tasks that are executed.
+
+BitBake first searches the current working directory for an optional
+``conf/bblayers.conf`` configuration file. This file is expected to
+contain a :term:`BBLAYERS` variable that is a
+space-delimited list of 'layer' directories. Recall that if BitBake
+cannot find a ``bblayers.conf`` file, then it is assumed the user has
+set the ``BBPATH`` and ``BBFILES`` variables directly in the
+environment.
+
+For each directory (layer) in this list, a ``conf/layer.conf`` file is
+located and parsed with the :term:`LAYERDIR` variable
+being set to the directory where the layer was found. The idea is these
+files automatically set up :term:`BBPATH` and other
+variables correctly for a given build directory.
+
+BitBake then expects to find the ``conf/bitbake.conf`` file somewhere in
+the user-specified ``BBPATH``. That configuration file generally has
+include directives to pull in any other metadata such as files specific
+to the architecture, the machine, the local environment, and so forth.
+
+Only variable definitions and include directives are allowed in BitBake
+``.conf`` files. Some variables directly influence BitBake's behavior.
+These variables might have been set from the environment depending on
+the environment variables previously mentioned or set in the
+configuration files. The ":ref:`bitbake-user-manual/bitbake-user-manual-ref-variables:Variables Glossary`"
+chapter presents a full list of
+variables.
+
+After parsing configuration files, BitBake uses its rudimentary
+inheritance mechanism, which is through class files, to inherit some
+standard classes. BitBake parses a class when the inherit directive
+responsible for getting that class is encountered.
+
+The ``base.bbclass`` file is always included. Other classes that are
+specified in the configuration using the
+:term:`INHERIT` variable are also included. BitBake
+searches for class files in a ``classes`` subdirectory under the paths
+in ``BBPATH`` in the same way as configuration files.
+
+A good way to get an idea of the configuration files and the class files
+used in your execution environment is to run the following BitBake
+command: ::
+
+  $ bitbake -e > mybb.log
+
+Examining the top of the ``mybb.log``
+shows you the many configuration files and class files used in your
+execution environment.
+
+.. note::
+
+   You need to be aware of how BitBake parses curly braces. If a recipe
+   uses a closing curly brace within the function and the character has
+   no leading spaces, BitBake produces a parsing error. If you use a
+   pair of curly braces in a shell function, the closing curly brace
+   must not be located at the start of the line without leading spaces.
+
+   Here is an example that causes BitBake to produce a parsing error: ::
+
+      fakeroot create_shar() {
+         cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
+      usage()
+      {
+         echo "test"
+         ######  The following "}" at the start of the line causes a parsing error ######
+      }
+      EOF
+      }
+
+      Writing the recipe this way avoids the error:
+      fakeroot create_shar() {
+         cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
+      usage()
+      {
+         echo "test"
+         ###### The following "}" with a leading space at the start of the line avoids the error ######
+       }
+      EOF
+      }
+
+Locating and Parsing Recipes
+============================
+
+During the configuration phase, BitBake will have set
+:term:`BBFILES`. BitBake now uses it to construct a
+list of recipes to parse, along with any append files (``.bbappend``) to
+apply. ``BBFILES`` is a space-separated list of available files and
+supports wildcards. An example would be: ::
+
+  BBFILES = "/path/to/bbfiles/*.bb /path/to/appends/*.bbappend"
+
+BitBake parses each
+recipe and append file located with ``BBFILES`` and stores the values of
+various variables into the datastore.
+
+.. note::
+
+   Append files are applied in the order they are encountered in BBFILES.
+
+For each file, a fresh copy of the base configuration is made, then the
+recipe is parsed line by line. Any inherit statements cause BitBake to
+find and then parse class files (``.bbclass``) using
+:term:`BBPATH` as the search path. Finally, BitBake
+parses in order any append files found in ``BBFILES``.
+
+One common convention is to use the recipe filename to define pieces of
+metadata. For example, in ``bitbake.conf`` the recipe name and version
+are used to set the variables :term:`PN` and
+:term:`PV`: ::
+
+   PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}"
+   PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
+
+In this example, a recipe called "something_1.2.3.bb" would set
+``PN`` to "something" and ``PV`` to "1.2.3".
+
+By the time parsing is complete for a recipe, BitBake has a list of
+tasks that the recipe defines and a set of data consisting of keys and
+values as well as dependency information about the tasks.
+
+BitBake does not need all of this information. It only needs a small
+subset of the information to make decisions about the recipe.
+Consequently, BitBake caches the values in which it is interested and
+does not store the rest of the information. Experience has shown it is
+faster to re-parse the metadata than to try and write it out to the disk
+and then reload it.
+
+Where possible, subsequent BitBake commands reuse this cache of recipe
+information. The validity of this cache is determined by first computing
+a checksum of the base configuration data (see
+:term:`BB_HASHCONFIG_WHITELIST`) and
+then checking if the checksum matches. If that checksum matches what is
+in the cache and the recipe and class files have not changed, BitBake is
+able to use the cache. BitBake then reloads the cached information about
+the recipe instead of reparsing it from scratch.
+
+Recipe file collections exist to allow the user to have multiple
+repositories of ``.bb`` files that contain the same exact package. For
+example, one could easily use them to make one's own local copy of an
+upstream repository, but with custom modifications that one does not
+want upstream. Here is an example: ::
+
+  BBFILES = "/stuff/openembedded/*/*.bb /stuff/openembedded.modified/*/*.bb"
+  BBFILE_COLLECTIONS = "upstream local"
+  BBFILE_PATTERN_upstream = "^/stuff/openembedded/"
+  BBFILE_PATTERN_local = "^/stuff/openembedded.modified/"
+  BBFILE_PRIORITY_upstream = "5" BBFILE_PRIORITY_local = "10"
+
+.. note::
+
+   The layers mechanism is now the preferred method of collecting code.
+   While the collections code remains, its main use is to set layer
+   priorities and to deal with overlap (conflicts) between layers.
+
+.. _bb-bitbake-providers:
+
+Providers
+=========
+
+Assuming BitBake has been instructed to execute a target and that all
+the recipe files have been parsed, BitBake starts to figure out how to
+build the target. BitBake looks through the ``PROVIDES`` list for each
+of the recipes. A ``PROVIDES`` list is the list of names by which the
+recipe can be known. Each recipe's ``PROVIDES`` list is created
+implicitly through the recipe's :term:`PN` variable and
+explicitly through the recipe's :term:`PROVIDES`
+variable, which is optional.
+
+When a recipe uses ``PROVIDES``, that recipe's functionality can be
+found under an alternative name or names other than the implicit ``PN``
+name. As an example, suppose a recipe named ``keyboard_1.0.bb``
+contained the following: ::
+
+  PROVIDES += "fullkeyboard"
+
+The ``PROVIDES``
+list for this recipe becomes "keyboard", which is implicit, and
+"fullkeyboard", which is explicit. Consequently, the functionality found
+in ``keyboard_1.0.bb`` can be found under two different names.
+
+.. _bb-bitbake-preferences:
+
+Preferences
+===========
+
+The ``PROVIDES`` list is only part of the solution for figuring out a
+target's recipes. Because targets might have multiple providers, BitBake
+needs to prioritize providers by determining provider preferences.
+
+A common example in which a target has multiple providers is
+"virtual/kernel", which is on the ``PROVIDES`` list for each kernel
+recipe. Each machine often selects the best kernel provider by using a
+line similar to the following in the machine configuration file: ::
+
+  PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+
+The default :term:`PREFERRED_PROVIDER` is the provider
+with the same name as the target. BitBake iterates through each target
+it needs to build and resolves them and their dependencies using this
+process.
+
+Understanding how providers are chosen is made complicated by the fact
+that multiple versions might exist for a given provider. BitBake
+defaults to the highest version of a provider. Version comparisons are
+made using the same method as Debian. You can use the
+:term:`PREFERRED_VERSION` variable to
+specify a particular version. You can influence the order by using the
+:term:`DEFAULT_PREFERENCE` variable.
+
+By default, files have a preference of "0". Setting
+``DEFAULT_PREFERENCE`` to "-1" makes the recipe unlikely to be used
+unless it is explicitly referenced. Setting ``DEFAULT_PREFERENCE`` to
+"1" makes it likely the recipe is used. ``PREFERRED_VERSION`` overrides
+any ``DEFAULT_PREFERENCE`` setting. ``DEFAULT_PREFERENCE`` is often used
+to mark newer and more experimental recipe versions until they have
+undergone sufficient testing to be considered stable.
+
+When there are multiple "versions" of a given recipe, BitBake defaults
+to selecting the most recent version, unless otherwise specified. If the
+recipe in question has a
+:term:`DEFAULT_PREFERENCE` set lower than
+the other recipes (default is 0), then it will not be selected. This
+allows the person or persons maintaining the repository of recipe files
+to specify their preference for the default selected version.
+Additionally, the user can specify their preferred version.
+
+If the first recipe is named ``a_1.1.bb``, then the
+:term:`PN` variable will be set to "a", and the
+:term:`PV` variable will be set to 1.1.
+
+Thus, if a recipe named ``a_1.2.bb`` exists, BitBake will choose 1.2 by
+default. However, if you define the following variable in a ``.conf``
+file that BitBake parses, you can change that preference: ::
+
+  PREFERRED_VERSION_a = "1.1"
+
+.. note::
+
+   It is common for a recipe to provide two versions -- a stable,
+   numbered (and preferred) version, and a version that is automatically
+   checked out from a source code repository that is considered more
+   "bleeding edge" but can be selected only explicitly.
+
+   For example, in the OpenEmbedded codebase, there is a standard,
+   versioned recipe file for BusyBox, ``busybox_1.22.1.bb``, but there
+   is also a Git-based version, ``busybox_git.bb``, which explicitly
+   contains the line ::
+
+     DEFAULT_PREFERENCE = "-1"
+
+   to ensure that the
+   numbered, stable version is always preferred unless the developer
+   selects otherwise.
+
+.. _bb-bitbake-dependencies:
+
+Dependencies
+============
+
+Each target BitBake builds consists of multiple tasks such as ``fetch``,
+``unpack``, ``patch``, ``configure``, and ``compile``. For best
+performance on multi-core systems, BitBake considers each task as an
+independent entity with its own set of dependencies.
+
+Dependencies are defined through several variables. You can find
+information about variables BitBake uses in the
+:doc:`bitbake-user-manual-ref-variables` near the end of this manual. At a
+basic level, it is sufficient to know that BitBake uses the
+:term:`DEPENDS` and
+:term:`RDEPENDS` variables when calculating
+dependencies.
+
+For more information on how BitBake handles dependencies, see the
+:ref:`bitbake-user-manual/bitbake-user-manual-metadata:Dependencies`
+section.
+
+.. _ref-bitbake-tasklist:
+
+The Task List
+=============
+
+Based on the generated list of providers and the dependency information,
+BitBake can now calculate exactly what tasks it needs to run and in what
+order it needs to run them. The
+:ref:`bitbake-user-manual/bitbake-user-manual-execution:executing tasks`
+section has more information on how BitBake chooses which task to
+execute next.
+
+The build now starts with BitBake forking off threads up to the limit
+set in the :term:`BB_NUMBER_THREADS`
+variable. BitBake continues to fork threads as long as there are tasks
+ready to run, those tasks have all their dependencies met, and the
+thread threshold has not been exceeded.
+
+It is worth noting that you can greatly speed up the build time by
+properly setting the ``BB_NUMBER_THREADS`` variable.
+
+As each task completes, a timestamp is written to the directory
+specified by the :term:`STAMP` variable. On subsequent
+runs, BitBake looks in the build directory within ``tmp/stamps`` and
+does not rerun tasks that are already completed unless a timestamp is
+found to be invalid. Currently, invalid timestamps are only considered
+on a per recipe file basis. So, for example, if the configure stamp has
+a timestamp greater than the compile timestamp for a given target, then
+the compile task would rerun. Running the compile task again, however,
+has no effect on other providers that depend on that target.
+
+The exact format of the stamps is partly configurable. In modern
+versions of BitBake, a hash is appended to the stamp so that if the
+configuration changes, the stamp becomes invalid and the task is
+automatically rerun. This hash, or signature used, is governed by the
+signature policy that is configured (see the
+:ref:`bitbake-user-manual/bitbake-user-manual-execution:checksums (signatures)`
+section for information). It is also
+possible to append extra metadata to the stamp using the
+``[stamp-extra-info]`` task flag. For example, OpenEmbedded uses this
+flag to make some tasks machine-specific.
+
+.. note::
+
+   Some tasks are marked as "nostamp" tasks. No timestamp file is
+   created when these tasks are run. Consequently, "nostamp" tasks are
+   always rerun.
+
+For more information on tasks, see the
+:ref:`bitbake-user-manual/bitbake-user-manual-metadata:tasks` section.
+
+Executing Tasks
+===============
+
+Tasks can be either a shell task or a Python task. For shell tasks,
+BitBake writes a shell script to
+``${``\ :term:`T`\ ``}/run.do_taskname.pid`` and then
+executes the script. The generated shell script contains all the
+exported variables, and the shell functions with all variables expanded.
+Output from the shell script goes to the file
+``${T}/log.do_taskname.pid``. Looking at the expanded shell functions in
+the run file and the output in the log files is a useful debugging
+technique.
+
+For Python tasks, BitBake executes the task internally and logs
+information to the controlling terminal. Future versions of BitBake will
+write the functions to files similar to the way shell tasks are handled.
+Logging will be handled in a way similar to shell tasks as well.
+
+The order in which BitBake runs the tasks is controlled by its task
+scheduler. It is possible to configure the scheduler and define custom
+implementations for specific use cases. For more information, see these
+variables that control the behavior:
+
+-  :term:`BB_SCHEDULER`
+
+-  :term:`BB_SCHEDULERS`
+
+It is possible to have functions run before and after a task's main
+function. This is done using the ``[prefuncs]`` and ``[postfuncs]``
+flags of the task that lists the functions to run.
+
+.. _checksums:
+
+Checksums (Signatures)
+======================
+
+A checksum is a unique signature of a task's inputs. The signature of a
+task can be used to determine if a task needs to be run. Because it is a
+change in a task's inputs that triggers running the task, BitBake needs
+to detect all the inputs to a given task. For shell tasks, this turns
+out to be fairly easy because BitBake generates a "run" shell script for
+each task and it is possible to create a checksum that gives you a good
+idea of when the task's data changes.
+
+To complicate the problem, some things should not be included in the
+checksum. First, there is the actual specific build path of a given task
+- the working directory. It does not matter if the working directory
+changes because it should not affect the output for target packages. The
+simplistic approach for excluding the working directory is to set it to
+some fixed value and create the checksum for the "run" script. BitBake
+goes one step better and uses the
+:term:`BB_HASHBASE_WHITELIST` variable
+to define a list of variables that should never be included when
+generating the signatures.
+
+Another problem results from the "run" scripts containing functions that
+might or might not get called. The incremental build solution contains
+code that figures out dependencies between shell functions. This code is
+used to prune the "run" scripts down to the minimum set, thereby
+alleviating this problem and making the "run" scripts much more readable
+as a bonus.
+
+So far we have solutions for shell scripts. What about Python tasks? The
+same approach applies even though these tasks are more difficult. The
+process needs to figure out what variables a Python function accesses
+and what functions it calls. Again, the incremental build solution
+contains code that first figures out the variable and function
+dependencies, and then creates a checksum for the data used as the input
+to the task.
+
+Like the working directory case, situations exist where dependencies
+should be ignored. For these cases, you can instruct the build process
+to ignore a dependency by using a line like the following: ::
+
+  PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
+
+This example ensures that the
+``PACKAGE_ARCHS`` variable does not depend on the value of ``MACHINE``,
+even if it does reference it.
+
+Equally, there are cases where we need to add dependencies BitBake is
+not able to find. You can accomplish this by using a line like the
+following: ::
+
+  PACKAGE_ARCHS[vardeps] = "MACHINE"
+
+This example explicitly
+adds the ``MACHINE`` variable as a dependency for ``PACKAGE_ARCHS``.
+
+Consider a case with in-line Python, for example, where BitBake is not
+able to figure out dependencies. When running in debug mode (i.e. using
+``-DDD``), BitBake produces output when it discovers something for which
+it cannot figure out dependencies.
+
+Thus far, this section has limited discussion to the direct inputs into
+a task. Information based on direct inputs is referred to as the
+"basehash" in the code. However, there is still the question of a task's
+indirect inputs - the things that were already built and present in the
+build directory. The checksum (or signature) for a particular task needs
+to add the hashes of all the tasks on which the particular task depends.
+Choosing which dependencies to add is a policy decision. However, the
+effect is to generate a master checksum that combines the basehash and
+the hashes of the task's dependencies.
+
+At the code level, there are a variety of ways both the basehash and the
+dependent task hashes can be influenced. Within the BitBake
+configuration file, we can give BitBake some extra information to help
+it construct the basehash. The following statement effectively results
+in a list of global variable dependency excludes - variables never
+included in any checksum. This example uses variables from OpenEmbedded
+to help illustrate the concept: ::
+
+   BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
+       SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \
+       USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
+       PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
+       CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
+
+The previous example excludes the work directory, which is part of
+``TMPDIR``.
+
+The rules for deciding which hashes of dependent tasks to include
+through dependency chains are more complex and are generally
+accomplished with a Python function. The code in
+``meta/lib/oe/sstatesig.py`` shows two examples of this and also
+illustrates how you can insert your own policy into the system if so
+desired. This file defines the two basic signature generators
+OpenEmbedded-Core uses: "OEBasic" and "OEBasicHash". By default, there
+is a dummy "noop" signature handler enabled in BitBake. This means that
+behavior is unchanged from previous versions. ``OE-Core`` uses the
+"OEBasicHash" signature handler by default through this setting in the
+``bitbake.conf`` file: ::
+
+  BB_SIGNATURE_HANDLER ?= "OEBasicHash"
+
+The "OEBasicHash" ``BB_SIGNATURE_HANDLER`` is the same as the "OEBasic"
+version but adds the task hash to the stamp files. This results in any
+metadata change that changes the task hash, automatically causing the
+task to be run again. This removes the need to bump
+:term:`PR` values, and changes to metadata automatically
+ripple across the build.
+
+It is also worth noting that the end result of these signature
+generators is to make some dependency and hash information available to
+the build. This information includes:
+
+-  ``BB_BASEHASH_task-``\ *taskname*: The base hashes for each task in the
+   recipe.
+
+-  ``BB_BASEHASH_``\ *filename:taskname*: The base hashes for each
+   dependent task.
+
+-  ``BBHASHDEPS_``\ *filename:taskname*: The task dependencies for
+   each task.
+
+-  ``BB_TASKHASH``: The hash of the currently running task.
+
+It is worth noting that BitBake's "-S" option lets you debug BitBake's
+processing of signatures. The options passed to -S allow different
+debugging modes to be used, either using BitBake's own debug functions
+or possibly those defined in the metadata/signature handler itself. The
+simplest parameter to pass is "none", which causes a set of signature
+information to be written out into ``STAMPS_DIR`` corresponding to the
+targets specified. The other currently available parameter is
+"printdiff", which causes BitBake to try to establish the closest
+signature match it can (e.g. in the sstate cache) and then run
+``bitbake-diffsigs`` over the matches to determine the stamps and delta
+where these two stamp trees diverge.
+
+.. note::
+
+   It is likely that future versions of BitBake will provide other
+   signature handlers triggered through additional "-S" parameters.
+
+You can find more information on checksum metadata in the
+:ref:`bitbake-user-manual/bitbake-user-manual-metadata:task checksums and setscene`
+section.
+
+Setscene
+========
+
+The setscene process enables BitBake to handle "pre-built" artifacts.
+The ability to handle and reuse these artifacts allows BitBake the
+luxury of not having to build something from scratch every time.
+Instead, BitBake can use, when possible, existing build artifacts.
+
+BitBake needs to have reliable data indicating whether or not an
+artifact is compatible. Signatures, described in the previous section,
+provide an ideal way of representing whether an artifact is compatible.
+If a signature is the same, an object can be reused.
+
+If an object can be reused, the problem then becomes how to replace a
+given task or set of tasks with the pre-built artifact. BitBake solves
+the problem with the "setscene" process.
+
+When BitBake is asked to build a given target, before building anything,
+it first asks whether cached information is available for any of the
+targets it's building, or any of the intermediate targets. If cached
+information is available, BitBake uses this information instead of
+running the main tasks.
+
+BitBake first calls the function defined by the
+:term:`BB_HASHCHECK_FUNCTION` variable
+with a list of tasks and corresponding hashes it wants to build. This
+function is designed to be fast and returns a list of the tasks for
+which it believes in can obtain artifacts.
+
+Next, for each of the tasks that were returned as possibilities, BitBake
+executes a setscene version of the task that the possible artifact
+covers. Setscene versions of a task have the string "_setscene" appended
+to the task name. So, for example, the task with the name ``xxx`` has a
+setscene task named ``xxx_setscene``. The setscene version of the task
+executes and provides the necessary artifacts returning either success
+or failure.
+
+As previously mentioned, an artifact can cover more than one task. For
+example, it is pointless to obtain a compiler if you already have the
+compiled binary. To handle this, BitBake calls the
+:term:`BB_SETSCENE_DEPVALID` function for
+each successful setscene task to know whether or not it needs to obtain
+the dependencies of that task.
+
+Finally, after all the setscene tasks have executed, BitBake calls the
+function listed in
+:term:`BB_SETSCENE_VERIFY_FUNCTION2`
+with the list of tasks BitBake thinks has been "covered". The metadata
+can then ensure that this list is correct and can inform BitBake that it
+wants specific tasks to be run regardless of the setscene result.
+
+You can find more information on setscene metadata in the
+:ref:`bitbake-user-manual/bitbake-user-manual-metadata:task checksums and setscene`
+section.
+
+Logging
+=======
+
+In addition to the standard command line option to control how verbose
+builds are when execute, bitbake also supports user defined
+configuration of the `Python
+logging <https://docs.python.org/3/library/logging.html>`__ facilities
+through the :term:`BB_LOGCONFIG` variable. This
+variable defines a json or yaml `logging
+configuration <https://docs.python.org/3/library/logging.config.html>`__
+that will be intelligently merged into the default configuration. The
+logging configuration is merged using the following rules:
+
+-  The user defined configuration will completely replace the default
+   configuration if top level key ``bitbake_merge`` is set to the value
+   ``False``. In this case, all other rules are ignored.
+
+-  The user configuration must have a top level ``version`` which must
+   match the value of the default configuration.
+
+-  Any keys defined in the ``handlers``, ``formatters``, or ``filters``,
+   will be merged into the same section in the default configuration,
+   with the user specified keys taking replacing a default one if there
+   is a conflict. In practice, this means that if both the default
+   configuration and user configuration specify a handler named
+   ``myhandler``, the user defined one will replace the default. To
+   prevent the user from inadvertently replacing a default handler,
+   formatter, or filter, all of the default ones are named with a prefix
+   of "``BitBake.``"
+
+-  If a logger is defined by the user with the key ``bitbake_merge`` set
+   to ``False``, that logger will be completely replaced by user
+   configuration. In this case, no other rules will apply to that
+   logger.
+
+-  All user defined ``filter`` and ``handlers`` properties for a given
+   logger will be merged with corresponding properties from the default
+   logger. For example, if the user configuration adds a filter called
+   ``myFilter`` to the ``BitBake.SigGen``, and the default configuration
+   adds a filter called ``BitBake.defaultFilter``, both filters will be
+   applied to the logger
+
+As an example, consider the following user logging configuration file
+which logs all Hash Equivalence related messages of VERBOSE or higher to
+a file called ``hashequiv.log`` ::
+
+   {
+       "version": 1,
+       "handlers": {
+           "autobuilderlog": {
+               "class": "logging.FileHandler",
+               "formatter": "logfileFormatter",
+               "level": "DEBUG",
+               "filename": "hashequiv.log",
+               "mode": "w"
+           }
+       },
+       "formatters": {
+               "logfileFormatter": {
+                   "format": "%(name)s: %(levelname)s: %(message)s"
+               }
+       },
+       "loggers": {
+           "BitBake.SigGen.HashEquiv": {
+               "level": "VERBOSE",
+               "handlers": ["autobuilderlog"]
+           },
+           "BitBake.RunQueue.HashEquiv": {
+               "level": "VERBOSE",
+               "handlers": ["autobuilderlog"]
+           }
+       }
+   }

bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst

@@ -0,0 +1,621 @@
+.. SPDX-License-Identifier: CC-BY-2.5
+
+=====================
+File Download Support
+=====================
+
+|
+
+BitBake's fetch module is a standalone piece of library code that deals
+with the intricacies of downloading source code and files from remote
+systems. Fetching source code is one of the cornerstones of building
+software. As such, this module forms an important part of BitBake.
+
+The current fetch module is called "fetch2" and refers to the fact that
+it is the second major version of the API. The original version is
+obsolete and has been removed from the codebase. Thus, in all cases,
+"fetch" refers to "fetch2" in this manual.
+
+The Download (Fetch)
+====================
+
+BitBake takes several steps when fetching source code or files. The
+fetcher codebase deals with two distinct processes in order: obtaining
+the files from somewhere (cached or otherwise) and then unpacking those
+files into a specific location and perhaps in a specific way. Getting
+and unpacking the files is often optionally followed by patching.
+Patching, however, is not covered by this module.
+
+The code to execute the first part of this process, a fetch, looks
+something like the following: ::
+
+   src_uri = (d.getVar('SRC_URI') or "").split()
+   fetcher = bb.fetch2.Fetch(src_uri, d)
+   fetcher.download()
+
+This code sets up an instance of the fetch class. The instance uses a
+space-separated list of URLs from the :term:`SRC_URI`
+variable and then calls the ``download`` method to download the files.
+
+The instantiation of the fetch class is usually followed by: ::
+
+   rootdir = l.getVar('WORKDIR')
+   fetcher.unpack(rootdir)
+
+This code unpacks the downloaded files to the specified by ``WORKDIR``.
+
+.. note::
+
+   For convenience, the naming in these examples matches the variables
+   used by OpenEmbedded. If you want to see the above code in action,
+   examine the OpenEmbedded class file ``base.bbclass``
+   .
+
+The ``SRC_URI`` and ``WORKDIR`` variables are not hardcoded into the
+fetcher, since those fetcher methods can be (and are) called with
+different variable names. In OpenEmbedded for example, the shared state
+(sstate) code uses the fetch module to fetch the sstate files.
+
+When the ``download()`` method is called, BitBake tries to resolve the
+URLs by looking for source files in a specific search order:
+
+-  *Pre-mirror Sites:* BitBake first uses pre-mirrors to try and find
+   source files. These locations are defined using the
+   :term:`PREMIRRORS` variable.
+
+-  *Source URI:* If pre-mirrors fail, BitBake uses the original URL (e.g
+   from ``SRC_URI``).
+
+-  *Mirror Sites:* If fetch failures occur, BitBake next uses mirror
+   locations as defined by the :term:`MIRRORS` variable.
+
+For each URL passed to the fetcher, the fetcher calls the submodule that
+handles that particular URL type. This behavior can be the source of
+some confusion when you are providing URLs for the ``SRC_URI`` variable.
+Consider the following two URLs: ::
+
+   http://git.yoctoproject.org/git/poky;protocol=git
+   git://git.yoctoproject.org/git/poky;protocol=http
+
+In the former case, the URL is passed to the ``wget`` fetcher, which does not
+understand "git". Therefore, the latter case is the correct form since the Git
+fetcher does know how to use HTTP as a transport.
+
+Here are some examples that show commonly used mirror definitions: ::
+
+   PREMIRRORS ?= "\
+      bzr://.*/.\*  http://somemirror.org/sources/ \\n \
+      cvs://.*/.\*  http://somemirror.org/sources/ \\n \
+      git://.*/.\*  http://somemirror.org/sources/ \\n \
+      hg://.*/.\*   http://somemirror.org/sources/ \\n \
+      osc://.*/.\*  http://somemirror.org/sources/ \\n \
+      p4://.*/.\*   http://somemirror.org/sources/ \\n \
+     svn://.*/.\*   http://somemirror.org/sources/ \\n"
+
+   MIRRORS =+ "\
+      ftp://.*/.\*   http://somemirror.org/sources/ \\n \
+      http://.*/.\*  http://somemirror.org/sources/ \\n \
+      https://.*/.\* http://somemirror.org/sources/ \\n"
+
+It is useful to note that BitBake
+supports cross-URLs. It is possible to mirror a Git repository on an
+HTTP server as a tarball. This is what the ``git://`` mapping in the
+previous example does.
+
+Since network accesses are slow, BitBake maintains a cache of files
+downloaded from the network. Any source files that are not local (i.e.
+downloaded from the Internet) are placed into the download directory,
+which is specified by the :term:`DL_DIR` variable.
+
+File integrity is of key importance for reproducing builds. For
+non-local archive downloads, the fetcher code can verify SHA-256 and MD5
+checksums to ensure the archives have been downloaded correctly. You can
+specify these checksums by using the ``SRC_URI`` variable with the
+appropriate varflags as follows: ::
+
+   SRC_URI[md5sum] = "value"
+   SRC_URI[sha256sum] = "value"
+
+You can also specify the checksums as
+parameters on the ``SRC_URI`` as shown below: ::
+
+  SRC_URI = "http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d"
+
+If multiple URIs exist, you can specify the checksums either directly as
+in the previous example, or you can name the URLs. The following syntax
+shows how you name the URIs: ::
+
+   SRC_URI = "http://example.com/foobar.tar.bz2;name=foo"
+   SRC_URI[foo.md5sum] = 4a8e0f237e961fd7785d19d07fdb994d
+
+After a file has been downloaded and
+has had its checksum checked, a ".done" stamp is placed in ``DL_DIR``.
+BitBake uses this stamp during subsequent builds to avoid downloading or
+comparing a checksum for the file again.
+
+.. note::
+
+   It is assumed that local storage is safe from data corruption. If
+   this were not the case, there would be bigger issues to worry about.
+
+If :term:`BB_STRICT_CHECKSUM` is set, any
+download without a checksum triggers an error message. The
+:term:`BB_NO_NETWORK` variable can be used to
+make any attempted network access a fatal error, which is useful for
+checking that mirrors are complete as well as other things.
+
+.. _bb-the-unpack:
+
+The Unpack
+==========
+
+The unpack process usually immediately follows the download. For all
+URLs except Git URLs, BitBake uses the common ``unpack`` method.
+
+A number of parameters exist that you can specify within the URL to
+govern the behavior of the unpack stage:
+
+-  *unpack:* Controls whether the URL components are unpacked. If set to
+   "1", which is the default, the components are unpacked. If set to
+   "0", the unpack stage leaves the file alone. This parameter is useful
+   when you want an archive to be copied in and not be unpacked.
+
+-  *dos:* Applies to ``.zip`` and ``.jar`` files and specifies whether
+   to use DOS line ending conversion on text files.
+
+-  *basepath:* Instructs the unpack stage to strip the specified
+   directories from the source path when unpacking.
+
+-  *subdir:* Unpacks the specific URL to the specified subdirectory
+   within the root directory.
+
+The unpack call automatically decompresses and extracts files with ".Z",
+".z", ".gz", ".xz", ".zip", ".jar", ".ipk", ".rpm". ".srpm", ".deb" and
+".bz2" extensions as well as various combinations of tarball extensions.
+
+As mentioned, the Git fetcher has its own unpack method that is
+optimized to work with Git trees. Basically, this method works by
+cloning the tree into the final directory. The process is completed
+using references so that there is only one central copy of the Git
+metadata needed.
+
+.. _bb-fetchers:
+
+Fetchers
+========
+
+As mentioned earlier, the URL prefix determines which fetcher submodule
+BitBake uses. Each submodule can support different URL parameters, which
+are described in the following sections.
+
+.. _local-file-fetcher:
+
+Local file fetcher (``file://``)
+--------------------------------
+
+This submodule handles URLs that begin with ``file://``. The filename
+you specify within the URL can be either an absolute or relative path to
+a file. If the filename is relative, the contents of the
+:term:`FILESPATH` variable is used in the same way
+``PATH`` is used to find executables. If the file cannot be found, it is
+assumed that it is available in :term:`DL_DIR` by the
+time the ``download()`` method is called.
+
+If you specify a directory, the entire directory is unpacked.
+
+Here are a couple of example URLs, the first relative and the second
+absolute: ::
+
+   SRC_URI = "file://relativefile.patch"
+   SRC_URI = "file:///Users/ich/very_important_software"
+
+.. _http-ftp-fetcher:
+
+HTTP/FTP wget fetcher (``http://``, ``ftp://``, ``https://``)
+-------------------------------------------------------------
+
+This fetcher obtains files from web and FTP servers. Internally, the
+fetcher uses the wget utility.
+
+The executable and parameters used are specified by the
+``FETCHCMD_wget`` variable, which defaults to sensible values. The
+fetcher supports a parameter "downloadfilename" that allows the name of
+the downloaded file to be specified. Specifying the name of the
+downloaded file is useful for avoiding collisions in
+:term:`DL_DIR` when dealing with multiple files that
+have the same name.
+
+Some example URLs are as follows: ::
+
+   SRC_URI = "http://oe.handhelds.org/not_there.aac"
+   SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac"
+   SRC_URI = "ftp://you@oe.handhelds.org/home/you/secret.plan"
+
+.. note::
+
+   Because URL parameters are delimited by semi-colons, this can
+   introduce ambiguity when parsing URLs that also contain semi-colons,
+   for example:
+   ::
+
+           SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git;a=snapshot;h=a5dd47"
+
+
+   Such URLs should should be modified by replacing semi-colons with '&'
+   characters:
+   ::
+
+           SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47"
+
+
+   In most cases this should work. Treating semi-colons and '&' in
+   queries identically is recommended by the World Wide Web Consortium
+   (W3C). Note that due to the nature of the URL, you may have to
+   specify the name of the downloaded file as well:
+   ::
+
+           SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47;downloadfilename=myfile.bz2"
+
+
+.. _cvs-fetcher:
+
+CVS fetcher (``(cvs://``)
+-------------------------
+
+This submodule handles checking out files from the CVS version control
+system. You can configure it using a number of different variables:
+
+-  :term:`FETCHCMD_cvs <FETCHCMD>`: The name of the executable to use when running
+   the ``cvs`` command. This name is usually "cvs".
+
+-  :term:`SRCDATE`: The date to use when fetching the CVS source code. A
+   special value of "now" causes the checkout to be updated on every
+   build.
+
+-  :term:`CVSDIR`: Specifies where a temporary
+   checkout is saved. The location is often ``DL_DIR/cvs``.
+
+-  CVS_PROXY_HOST: The name to use as a "proxy=" parameter to the
+   ``cvs`` command.
+
+-  CVS_PROXY_PORT: The port number to use as a "proxyport="
+   parameter to the ``cvs`` command.
+
+As well as the standard username and password URL syntax, you can also
+configure the fetcher with various URL parameters:
+
+The supported parameters are as follows:
+
+-  *"method":* The protocol over which to communicate with the CVS
+   server. By default, this protocol is "pserver". If "method" is set to
+   "ext", BitBake examines the "rsh" parameter and sets ``CVS_RSH``. You
+   can use "dir" for local directories.
+
+-  *"module":* Specifies the module to check out. You must supply this
+   parameter.
+
+-  *"tag":* Describes which CVS TAG should be used for the checkout. By
+   default, the TAG is empty.
+
+-  *"date":* Specifies a date. If no "date" is specified, the
+   :term:`SRCDATE` of the configuration is used to
+   checkout a specific date. The special value of "now" causes the
+   checkout to be updated on every build.
+
+-  *"localdir":* Used to rename the module. Effectively, you are
+   renaming the output directory to which the module is unpacked. You
+   are forcing the module into a special directory relative to
+   :term:`CVSDIR`.
+
+-  *"rsh":* Used in conjunction with the "method" parameter.
+
+-  *"scmdata":* Causes the CVS metadata to be maintained in the tarball
+   the fetcher creates when set to "keep". The tarball is expanded into
+   the work directory. By default, the CVS metadata is removed.
+
+-  *"fullpath":* Controls whether the resulting checkout is at the
+   module level, which is the default, or is at deeper paths.
+
+-  *"norecurse":* Causes the fetcher to only checkout the specified
+   directory with no recurse into any subdirectories.
+
+-  *"port":* The port to which the CVS server connects.
+
+Some example URLs are as follows: ::
+
+   SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext"
+   SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat"
+
+.. _svn-fetcher:
+
+Subversion (SVN) Fetcher (``svn://``)
+-------------------------------------
+
+This fetcher submodule fetches code from the Subversion source control
+system. The executable used is specified by ``FETCHCMD_svn``, which
+defaults to "svn". The fetcher's temporary working directory is set by
+:term:`SVNDIR`, which is usually ``DL_DIR/svn``.
+
+The supported parameters are as follows:
+
+-  *"module":* The name of the svn module to checkout. You must provide
+   this parameter. You can think of this parameter as the top-level
+   directory of the repository data you want.
+
+-  *"path_spec":* A specific directory in which to checkout the
+   specified svn module.
+
+-  *"protocol":* The protocol to use, which defaults to "svn". If
+   "protocol" is set to "svn+ssh", the "ssh" parameter is also used.
+
+-  *"rev":* The revision of the source code to checkout.
+
+-  *"scmdata":* Causes the ".svn" directories to be available during
+   compile-time when set to "keep". By default, these directories are
+   removed.
+
+-  *"ssh":* An optional parameter used when "protocol" is set to
+   "svn+ssh". You can use this parameter to specify the ssh program used
+   by svn.
+
+-  *"transportuser":* When required, sets the username for the
+   transport. By default, this parameter is empty. The transport
+   username is different than the username used in the main URL, which
+   is passed to the subversion command.
+
+Following are three examples using svn: ::
+
+   SRC_URI = "svn://myrepos/proj1;module=vip;protocol=http;rev=667"
+   SRC_URI = "svn://myrepos/proj1;module=opie;protocol=svn+ssh"
+   SRC_URI = "svn://myrepos/proj1;module=trunk;protocol=http;path_spec=${MY_DIR}/proj1"
+
+.. _git-fetcher:
+
+Git Fetcher (``git://``)
+------------------------
+
+This fetcher submodule fetches code from the Git source control system.
+The fetcher works by creating a bare clone of the remote into
+:term:`GITDIR`, which is usually ``DL_DIR/git2``. This
+bare clone is then cloned into the work directory during the unpack
+stage when a specific tree is checked out. This is done using alternates
+and by reference to minimize the amount of duplicate data on the disk
+and make the unpack process fast. The executable used can be set with
+``FETCHCMD_git``.
+
+This fetcher supports the following parameters:
+
+-  *"protocol":* The protocol used to fetch the files. The default is
+   "git" when a hostname is set. If a hostname is not set, the Git
+   protocol is "file". You can also use "http", "https", "ssh" and
+   "rsync".
+
+-  *"nocheckout":* Tells the fetcher to not checkout source code when
+   unpacking when set to "1". Set this option for the URL where there is
+   a custom routine to checkout code. The default is "0".
+
+-  *"rebaseable":* Indicates that the upstream Git repository can be
+   rebased. You should set this parameter to "1" if revisions can become
+   detached from branches. In this case, the source mirror tarball is
+   done per revision, which has a loss of efficiency. Rebasing the
+   upstream Git repository could cause the current revision to disappear
+   from the upstream repository. This option reminds the fetcher to
+   preserve the local cache carefully for future use. The default value
+   for this parameter is "0".
+
+-  *"nobranch":* Tells the fetcher to not check the SHA validation for
+   the branch when set to "1". The default is "0". Set this option for
+   the recipe that refers to the commit that is valid for a tag instead
+   of the branch.
+
+-  *"bareclone":* Tells the fetcher to clone a bare clone into the
+   destination directory without checking out a working tree. Only the
+   raw Git metadata is provided. This parameter implies the "nocheckout"
+   parameter as well.
+
+-  *"branch":* The branch(es) of the Git tree to clone. If unset, this
+   is assumed to be "master". The number of branch parameters much match
+   the number of name parameters.
+
+-  *"rev":* The revision to use for the checkout. The default is
+   "master".
+
+-  *"tag":* Specifies a tag to use for the checkout. To correctly
+   resolve tags, BitBake must access the network. For that reason, tags
+   are often not used. As far as Git is concerned, the "tag" parameter
+   behaves effectively the same as the "rev" parameter.
+
+-  *"subpath":* Limits the checkout to a specific subpath of the tree.
+   By default, the whole tree is checked out.
+
+-  *"destsuffix":* The name of the path in which to place the checkout.
+   By default, the path is ``git/``.
+
+-  *"usehead":* Enables local ``git://`` URLs to use the current branch
+   HEAD as the revision for use with ``AUTOREV``. The "usehead"
+   parameter implies no branch and only works when the transfer protocol
+   is ``file://``.
+
+Here are some example URLs: ::
+
+   SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1"
+   SRC_URI = "git://git.oe.handhelds.org/git/vip.git;protocol=http"
+
+.. _gitsm-fetcher:
+
+Git Submodule Fetcher (``gitsm://``)
+------------------------------------
+
+This fetcher submodule inherits from the :ref:`Git
+fetcher<bitbake-user-manual/bitbake-user-manual-fetching:git fetcher
+(\`\`git://\`\`)>` and extends that fetcher's behavior by fetching a
+repository's submodules. :term:`SRC_URI` is passed to the Git fetcher as
+described in the :ref:`bitbake-user-manual/bitbake-user-manual-fetching:git
+fetcher (\`\`git://\`\`)` section.
+
+.. note::
+
+   You must clean a recipe when switching between '``git://``' and
+   '``gitsm://``' URLs.
+
+   The Git Submodules fetcher is not a complete fetcher implementation.
+   The fetcher has known issues where it does not use the normal source
+   mirroring infrastructure properly. Further, the submodule sources it
+   fetches are not visible to the licensing and source archiving
+   infrastructures.
+
+.. _clearcase-fetcher:
+
+ClearCase Fetcher (``ccrc://``)
+-------------------------------
+
+This fetcher submodule fetches code from a
+`ClearCase <http://en.wikipedia.org/wiki/Rational_ClearCase>`__
+repository.
+
+To use this fetcher, make sure your recipe has proper
+:term:`SRC_URI`, :term:`SRCREV`, and
+:term:`PV` settings. Here is an example: ::
+
+   SRC_URI = "ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module"
+   SRCREV = "EXAMPLE_CLEARCASE_TAG"
+   PV = "${@d.getVar("SRCREV", False).replace("/", "+")}"
+
+The fetcher uses the ``rcleartool`` or
+``cleartool`` remote client, depending on which one is available.
+
+Following are options for the ``SRC_URI`` statement:
+
+-  *vob*: The name, which must include the prepending "/" character,
+   of the ClearCase VOB. This option is required.
+
+-  *module*: The module, which must include the prepending "/"
+   character, in the selected VOB.
+
+   .. note::
+
+      The module and vob options are combined to create the load rule in the
+      view config spec. As an example, consider the vob and module values from
+      the SRC_URI statement at the start of this section. Combining those values
+      results in the following: ::
+
+         load /example_vob/example_module
+
+-  *proto*: The protocol, which can be either ``http`` or ``https``.
+
+By default, the fetcher creates a configuration specification. If you
+want this specification written to an area other than the default, use
+the ``CCASE_CUSTOM_CONFIG_SPEC`` variable in your recipe to define where
+the specification is written.
+
+.. note::
+
+   the SRCREV loses its functionality if you specify this variable. However,
+   SRCREV is still used to label the archive after a fetch even though it does
+   not define what is fetched.
+
+Here are a couple of other behaviors worth mentioning:
+
+-  When using ``cleartool``, the login of ``cleartool`` is handled by
+   the system. The login require no special steps.
+
+-  In order to use ``rcleartool`` with authenticated users, an
+   "rcleartool login" is necessary before using the fetcher.
+
+.. _perforce-fetcher:
+
+Perforce Fetcher (``p4://``)
+----------------------------
+
+This fetcher submodule fetches code from the
+`Perforce <https://www.perforce.com/>`__ source control system. The
+executable used is specified by ``FETCHCMD_p4``, which defaults to "p4".
+The fetcher's temporary working directory is set by
+:term:`P4DIR`, which defaults to "DL_DIR/p4".
+The fetcher does not make use of a perforce client, instead it
+relies on ``p4 files`` to retrieve a list of
+files and ``p4 print`` to transfer the content
+of those files locally.
+
+To use this fetcher, make sure your recipe has proper
+:term:`SRC_URI`, :term:`SRCREV`, and
+:term:`PV` values. The p4 executable is able to use the
+config file defined by your system's ``P4CONFIG`` environment variable
+in order to define the Perforce server URL and port, username, and
+password if you do not wish to keep those values in a recipe itself. If
+you choose not to use ``P4CONFIG``, or to explicitly set variables that
+``P4CONFIG`` can contain, you can specify the ``P4PORT`` value, which is
+the server's URL and port number, and you can specify a username and
+password directly in your recipe within ``SRC_URI``.
+
+Here is an example that relies on ``P4CONFIG`` to specify the server URL
+and port, username, and password, and fetches the Head Revision: ::
+
+   SRC_URI = "p4://example-depot/main/source/..."
+   SRCREV = "${AUTOREV}"
+   PV = "p4-${SRCPV}"
+   S = "${WORKDIR}/p4"
+
+Here is an example that specifies the server URL and port, username, and
+password, and fetches a Revision based on a Label: ::
+
+   P4PORT = "tcp:p4server.example.net:1666"
+   SRC_URI = "p4://user:passwd@example-depot/main/source/..."
+   SRCREV = "release-1.0"
+   PV = "p4-${SRCPV}"
+   S = "${WORKDIR}/p4"
+
+.. note::
+
+   You should always set S to "${WORKDIR}/p4" in your recipe.
+
+.. _repo-fetcher:
+
+Repo Fetcher (``repo://``)
+--------------------------
+
+This fetcher submodule fetches code from ``google-repo`` source control
+system. The fetcher works by initiating and syncing sources of the
+repository into :term:`REPODIR`, which is usually
+``${DL_DIR}/repo``.
+
+This fetcher supports the following parameters:
+
+-  *"protocol":* Protocol to fetch the repository manifest (default:
+   git).
+
+-  *"branch":* Branch or tag of repository to get (default: master).
+
+-  *"manifest":* Name of the manifest file (default: ``default.xml``).
+
+Here are some example URLs: ::
+
+   SRC_URI = "repo://REPOROOT;protocol=git;branch=some_branch;manifest=my_manifest.xml"
+   SRC_URI = "repo://REPOROOT;protocol=file;branch=some_branch;manifest=my_manifest.xml"
+
+Other Fetchers
+--------------
+
+Fetch submodules also exist for the following:
+
+-  Bazaar (``bzr://``)
+
+-  Mercurial (``hg://``)
+
+-  npm (``npm://``)
+
+-  OSC (``osc://``)
+
+-  Secure FTP (``sftp://``)
+
+-  Secure Shell (``ssh://``)
+
+-  Trees using Git Annex (``gitannex://``)
+
+No documentation currently exists for these lesser used fetcher
+submodules. However, you might find the code helpful and readable.
+
+Auto Revisions
+==============
+
+We need to document ``AUTOREV`` and ``SRCREV_FORMAT`` here.

bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml

@@ -1,868 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<chapter>
-<title>File Download Support</title>
-
-    <para>
-        BitBake's fetch module is a standalone piece of library code
-        that deals with the intricacies of downloading source code
-        and files from remote systems.
-        Fetching source code is one of the cornerstones of building software.
-        As such, this module forms an important part of BitBake.
-    </para>
-
-    <para>
-        The current fetch module is called "fetch2" and refers to the
-        fact that it is the second major version of the API.
-        The original version is obsolete and has been removed from the codebase.
-        Thus, in all cases, "fetch" refers to "fetch2" in this
-        manual.
-    </para>
-
-    <section id='the-download-fetch'>
-        <title>The Download (Fetch)</title>
-
-        <para>
-            BitBake takes several steps when fetching source code or files.
-            The fetcher codebase deals with two distinct processes in order:
-            obtaining the files from somewhere (cached or otherwise)
-            and then unpacking those files into a specific location and
-            perhaps in a specific way.
-            Getting and unpacking the files is often optionally followed
-            by patching.
-            Patching, however, is not covered by this module.
-        </para>
-
-        <para>
-            The code to execute the first part of this process, a fetch,
-            looks something like the following:
-            <literallayout class='monospaced'>
-     src_uri = (d.getVar('SRC_URI') or "").split()
-     fetcher = bb.fetch2.Fetch(src_uri, d)
-     fetcher.download()
-            </literallayout>
-            This code sets up an instance of the fetch class.
-            The instance uses a space-separated list of URLs from the
-            <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link>
-            variable and then calls the <filename>download</filename>
-            method to download the files.
-        </para>
-
-        <para>
-            The instantiation of the fetch class is usually followed by:
-            <literallayout class='monospaced'>
-     rootdir = l.getVar('WORKDIR')
-     fetcher.unpack(rootdir)
-            </literallayout>
-            This code unpacks the downloaded files to the
-            specified by <filename>WORKDIR</filename>.
-            <note>
-                For convenience, the naming in these examples matches
-                the variables used by OpenEmbedded.
-                If you want to see the above code in action, examine
-                the OpenEmbedded class file <filename>base.bbclass</filename>.
-            </note>
-            The <filename>SRC_URI</filename> and <filename>WORKDIR</filename>
-            variables are not hardcoded into the fetcher, since those fetcher
-            methods can be (and are) called with different variable names.
-            In OpenEmbedded for example, the shared state (sstate) code uses
-            the fetch module to fetch the sstate files.
-        </para>
-
-        <para>
-            When the <filename>download()</filename> method is called,
-            BitBake tries to resolve the URLs by looking for source files
-            in a specific search order:
-            <itemizedlist>
-                <listitem><para><emphasis>Pre-mirror Sites:</emphasis>
-                    BitBake first uses pre-mirrors to try and find source files.
-                    These locations are defined using the
-                    <link linkend='var-bb-PREMIRRORS'><filename>PREMIRRORS</filename></link>
-                    variable.
-                    </para></listitem>
-                <listitem><para><emphasis>Source URI:</emphasis>
-                    If pre-mirrors fail, BitBake uses the original URL (e.g from
-                    <filename>SRC_URI</filename>).
-                    </para></listitem>
-                <listitem><para><emphasis>Mirror Sites:</emphasis>
-                    If fetch failures occur, BitBake next uses mirror locations as
-                    defined by the
-                    <link linkend='var-bb-MIRRORS'><filename>MIRRORS</filename></link>
-                    variable.
-                    </para></listitem>
-            </itemizedlist>
-        </para>
-
-        <para>
-            For each URL passed to the fetcher, the fetcher
-            calls the submodule that handles that particular URL type.
-            This behavior can be the source of some confusion when you
-            are providing URLs for the <filename>SRC_URI</filename>
-            variable.
-            Consider the following two URLs:
-            <literallayout class='monospaced'>
-     http://git.yoctoproject.org/git/poky;protocol=git
-     git://git.yoctoproject.org/git/poky;protocol=http
-            </literallayout>
-            In the former case, the URL is passed to the
-            <filename>wget</filename> fetcher, which does not
-            understand "git".
-            Therefore, the latter case is the correct form since the
-            Git fetcher does know how to use HTTP as a transport.
-        </para>
-
-        <para>
-            Here are some examples that show commonly used mirror
-            definitions:
-            <literallayout class='monospaced'>
-     PREMIRRORS ?= "\
-         bzr://.*/.*   http://somemirror.org/sources/ \n \
-         cvs://.*/.*   http://somemirror.org/sources/ \n \
-         git://.*/.*   http://somemirror.org/sources/ \n \
-         hg://.*/.*    http://somemirror.org/sources/ \n \
-         osc://.*/.*   http://somemirror.org/sources/ \n \
-         p4://.*/.*    http://somemirror.org/sources/ \n \
-         svn://.*/.*   http://somemirror.org/sources/ \n"
-
-     MIRRORS =+ "\
-         ftp://.*/.*      http://somemirror.org/sources/ \n \
-         http://.*/.*     http://somemirror.org/sources/ \n \
-         https://.*/.*    http://somemirror.org/sources/ \n"
-            </literallayout>
-            It is useful to note that BitBake supports
-            cross-URLs.
-            It is possible to mirror a Git repository on an HTTP
-            server as a tarball.
-            This is what the <filename>git://</filename> mapping in
-            the previous example does.
-        </para>
-
-        <para>
-            Since network accesses are slow, BitBake maintains a
-            cache of files downloaded from the network.
-            Any source files that are not local (i.e.
-            downloaded from the Internet) are placed into the download
-            directory, which is specified by the
-            <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link>
-            variable.
-        </para>
-
-        <para>
-            File integrity is of key importance for reproducing builds.
-            For non-local archive downloads, the fetcher code can verify
-            SHA-256 and MD5 checksums to ensure the archives have been
-            downloaded correctly.
-            You can specify these checksums by using the
-            <filename>SRC_URI</filename> variable with the appropriate
-            varflags as follows:
-            <literallayout class='monospaced'>
-     SRC_URI[md5sum] = "<replaceable>value</replaceable>"
-     SRC_URI[sha256sum] = "<replaceable>value</replaceable>"
-            </literallayout>
-            You can also specify the checksums as parameters on the
-            <filename>SRC_URI</filename> as shown below:
-            <literallayout class='monospaced'>
-     SRC_URI = "http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d"
-            </literallayout>
-            If multiple URIs exist, you can specify the checksums either
-            directly as in the previous example, or you can name the URLs.
-            The following syntax shows how you name the URIs:
-            <literallayout class='monospaced'>
-     SRC_URI = "http://example.com/foobar.tar.bz2;name=foo"
-     SRC_URI[foo.md5sum] = 4a8e0f237e961fd7785d19d07fdb994d
-            </literallayout>
-            After a file has been downloaded and has had its checksum checked,
-            a ".done" stamp is placed in <filename>DL_DIR</filename>.
-            BitBake uses this stamp during subsequent builds to avoid
-            downloading or comparing a checksum for the file again.
-            <note>
-                It is assumed that local storage is safe from data corruption.
-                If this were not the case, there would be bigger issues to worry about.
-            </note>
-        </para>
-
-        <para>
-            If
-            <link linkend='var-bb-BB_STRICT_CHECKSUM'><filename>BB_STRICT_CHECKSUM</filename></link>
-            is set, any download without a checksum triggers an
-            error message.
-            The
-            <link linkend='var-bb-BB_NO_NETWORK'><filename>BB_NO_NETWORK</filename></link>
-            variable can be used to make any attempted network access a fatal
-            error, which is useful for checking that mirrors are complete
-            as well as other things.
-        </para>
-    </section>
-
-    <section id='bb-the-unpack'>
-        <title>The Unpack</title>
-
-        <para>
-            The unpack process usually immediately follows the download.
-            For all URLs except Git URLs, BitBake uses the common
-            <filename>unpack</filename> method.
-        </para>
-
-        <para>
-            A number of parameters exist that you can specify within the
-            URL to govern the behavior of the unpack stage:
-            <itemizedlist>
-                <listitem><para><emphasis>unpack:</emphasis>
-                    Controls whether the URL components are unpacked.
-                    If set to "1", which is the default, the components
-                    are unpacked.
-                    If set to "0", the unpack stage leaves the file alone.
-                    This parameter is useful when you want an archive to be
-                    copied in and not be unpacked.
-                    </para></listitem>
-                <listitem><para><emphasis>dos:</emphasis>
-                    Applies to <filename>.zip</filename> and
-                    <filename>.jar</filename> files and specifies whether to
-                    use DOS line ending conversion on text files.
-                    </para></listitem>
-                <listitem><para><emphasis>basepath:</emphasis>
-                    Instructs the unpack stage to strip the specified
-                    directories from the source path when unpacking.
-                    </para></listitem>
-                <listitem><para><emphasis>subdir:</emphasis>
-                    Unpacks the specific URL to the specified subdirectory
-                    within the root directory.
-                    </para></listitem>
-            </itemizedlist>
-            The unpack call automatically decompresses and extracts files
-            with ".Z", ".z", ".gz", ".xz", ".zip", ".jar", ".ipk", ".rpm".
-            ".srpm", ".deb" and ".bz2" extensions as well as various combinations
-            of tarball extensions.
-        </para>
-
-        <para>
-            As mentioned, the Git fetcher has its own unpack method that
-            is optimized to work with Git trees.
-            Basically, this method works by cloning the tree into the final
-            directory.
-            The process is completed using references so that there is
-            only one central copy of the Git metadata needed.
-        </para>
-    </section>
-
-    <section id='bb-fetchers'>
-        <title>Fetchers</title>
-
-        <para>
-            As mentioned earlier, the URL prefix determines which
-            fetcher submodule BitBake uses.
-            Each submodule can support different URL parameters,
-            which are described in the following sections.
-        </para>
-
-        <section id='local-file-fetcher'>
-            <title>Local file fetcher (<filename>file://</filename>)</title>
-
-            <para>
-                This submodule handles URLs that begin with
-                <filename>file://</filename>.
-                The filename you specify within the URL can be
-                either an absolute or relative path to a file.
-                If the filename is relative, the contents of the
-                <link linkend='var-bb-FILESPATH'><filename>FILESPATH</filename></link>
-                variable is used in the same way
-                <filename>PATH</filename> is used to find executables.
-                If the file cannot be found, it is assumed that it is available in
-                <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link>
-                by the time the <filename>download()</filename> method is called.
-            </para>
-
-            <para>
-                If you specify a directory, the entire directory is
-                unpacked.
-            </para>
-
-            <para>
-                Here are a couple of example URLs, the first relative and
-                the second absolute:
-                <literallayout class='monospaced'>
-     SRC_URI = "file://relativefile.patch"
-     SRC_URI = "file:///Users/ich/very_important_software"
-                </literallayout>
-            </para>
-        </section>
-
-        <section id='http-ftp-fetcher'>
-            <title>HTTP/FTP wget fetcher (<filename>http://</filename>, <filename>ftp://</filename>, <filename>https://</filename>)</title>
-
-            <para>
-                This fetcher obtains files from web and FTP servers.
-                Internally, the fetcher uses the wget utility.
-            </para>
-
-            <para>
-                The executable and parameters used are specified by the
-                <filename>FETCHCMD_wget</filename> variable, which defaults
-                to sensible values.
-                The fetcher supports a parameter "downloadfilename" that
-                allows the name of the downloaded file to be specified.
-                Specifying the name of the downloaded file is useful
-                for avoiding collisions in
-                <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link>
-                when dealing with multiple files that have the same name.
-            </para>
-
-            <para>
-                Some example URLs are as follows:
-                <literallayout class='monospaced'>
-     SRC_URI = "http://oe.handhelds.org/not_there.aac"
-     SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac"
-     SRC_URI = "ftp://you@oe.handhelds.org/home/you/secret.plan"
-                </literallayout>
-            </para>
-            <note>
-               Because URL parameters are delimited by semi-colons, this can
-               introduce ambiguity when parsing URLs that also contain semi-colons,
-               for example:
-                <literallayout class='monospaced'>
-     SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git;a=snapshot;h=a5dd47"
-                </literallayout>
-               Such URLs should should be modified by replacing semi-colons with '&amp;' characters:
-               <literallayout class='monospaced'>
-     SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&amp;a=snapshot&amp;h=a5dd47"
-                </literallayout>
-                In most cases this should work. Treating semi-colons and '&amp;' in queries
-                identically is recommended by the World Wide Web Consortium (W3C).
-                Note that due to the nature of the URL, you may have to specify the name
-                of the downloaded file as well:
-              <literallayout class='monospaced'>
-     SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&amp;a=snapshot&amp;h=a5dd47;downloadfilename=myfile.bz2"
-                </literallayout>
-            </note>
-        </section>
-
-        <section id='cvs-fetcher'>
-            <title>CVS fetcher (<filename>(cvs://</filename>)</title>
-
-            <para>
-                This submodule handles checking out files from the
-                CVS version control system.
-                You can configure it using a number of different variables:
-                <itemizedlist>
-                    <listitem><para><emphasis><filename>FETCHCMD_cvs</filename>:</emphasis>
-                        The name of the executable to use when running
-                        the <filename>cvs</filename> command.
-                        This name is usually "cvs".
-                        </para></listitem>
-                    <listitem><para><emphasis><filename>SRCDATE</filename>:</emphasis>
-                        The date to use when fetching the CVS source code.
-                        A special value of "now" causes the checkout to
-                        be updated on every build.
-                        </para></listitem>
-                    <listitem><para><emphasis><link linkend='var-bb-CVSDIR'><filename>CVSDIR</filename></link>:</emphasis>
-                        Specifies where a temporary checkout is saved.
-                        The location is often <filename>DL_DIR/cvs</filename>.
-                        </para></listitem>
-                    <listitem><para><emphasis><filename>CVS_PROXY_HOST</filename>:</emphasis>
-                        The name to use as a "proxy=" parameter to the
-                        <filename>cvs</filename> command.
-                        </para></listitem>
-                    <listitem><para><emphasis><filename>CVS_PROXY_PORT</filename>:</emphasis>
-                        The port number to use as a "proxyport=" parameter to
-                        the <filename>cvs</filename> command.
-                        </para></listitem>
-                </itemizedlist>
-                As well as the standard username and password URL syntax,
-                you can also configure the fetcher with various URL parameters:
-            </para>
-
-            <para>
-                The supported parameters are as follows:
-                <itemizedlist>
-                    <listitem><para><emphasis>"method":</emphasis>
-                        The protocol over which to communicate with the CVS
-                        server.
-                        By default, this protocol is "pserver".
-                        If "method" is set to "ext", BitBake examines the
-                        "rsh" parameter and sets <filename>CVS_RSH</filename>.
-                        You can use "dir" for local directories.
-                        </para></listitem>
-                    <listitem><para><emphasis>"module":</emphasis>
-                        Specifies the module to check out.
-                        You must supply this parameter.
-                        </para></listitem>
-                    <listitem><para><emphasis>"tag":</emphasis>
-                        Describes which CVS TAG should be used for
-                        the checkout.
-                        By default, the TAG is empty.
-                        </para></listitem>
-                    <listitem><para><emphasis>"date":</emphasis>
-                        Specifies a date.
-                        If no "date" is specified, the
-                        <link linkend='var-bb-SRCDATE'><filename>SRCDATE</filename></link>
-                        of the configuration is used to checkout a specific date.
-                        The special value of "now" causes the checkout to be
-                        updated on every build.
-                        </para></listitem>
-                    <listitem><para><emphasis>"localdir":</emphasis>
-                        Used to rename the module.
-                        Effectively, you are renaming the output directory
-                        to which the module is unpacked.
-                        You are forcing the module into a special
-                        directory relative to
-                        <link linkend='var-bb-CVSDIR'><filename>CVSDIR</filename></link>.
-                        </para></listitem>
-                    <listitem><para><emphasis>"rsh"</emphasis>
-                        Used in conjunction with the "method" parameter.
-                        </para></listitem>
-                    <listitem><para><emphasis>"scmdata":</emphasis>
-                        Causes the CVS metadata to be maintained in the tarball
-                        the fetcher creates when set to "keep".
-                        The tarball is expanded into the work directory.
-                        By default, the CVS metadata is removed.
-                        </para></listitem>
-                    <listitem><para><emphasis>"fullpath":</emphasis>
-                        Controls whether the resulting checkout is at the
-                        module level, which is the default, or is at deeper
-                        paths.
-                        </para></listitem>
-                    <listitem><para><emphasis>"norecurse":</emphasis>
-                        Causes the fetcher to only checkout the specified
-                        directory with no recurse into any subdirectories.
-                        </para></listitem>
-                    <listitem><para><emphasis>"port":</emphasis>
-                        The port to which the CVS server connects.
-                        </para></listitem>
-                </itemizedlist>
-                Some example URLs are as follows:
-                <literallayout class='monospaced'>
-     SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext"
-     SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat"
-                </literallayout>
-            </para>
-        </section>
-
-        <section id='svn-fetcher'>
-            <title>Subversion (SVN) Fetcher (<filename>svn://</filename>)</title>
-
-            <para>
-                This fetcher submodule fetches code from the
-                Subversion source control system.
-                The executable used is specified by
-                <filename>FETCHCMD_svn</filename>, which defaults
-                to "svn".
-                The fetcher's temporary working directory is set by
-                <link linkend='var-bb-SVNDIR'><filename>SVNDIR</filename></link>,
-                which is usually <filename>DL_DIR/svn</filename>.
-            </para>
-
-            <para>
-                The supported parameters are as follows:
-                <itemizedlist>
-                    <listitem><para><emphasis>"module":</emphasis>
-                        The name of the svn module to checkout.
-                        You must provide this parameter.
-                        You can think of this parameter as the top-level
-                        directory of the repository data you want.
-                        </para></listitem>
-                    <listitem><para><emphasis>"path_spec":</emphasis>
-                        A specific directory in which to checkout the
-                        specified svn module.
-                        </para></listitem>
-                    <listitem><para><emphasis>"protocol":</emphasis>
-                        The protocol to use, which defaults to "svn".
-                        If "protocol" is set to "svn+ssh", the "ssh"
-                        parameter is also used.
-                        </para></listitem>
-                    <listitem><para><emphasis>"rev":</emphasis>
-                        The revision of the source code to checkout.
-                        </para></listitem>
-                    <listitem><para><emphasis>"scmdata":</emphasis>
-                        Causes the “.svn” directories to be available during
-                        compile-time when set to "keep".
-                        By default, these directories are removed.
-                        </para></listitem>
-                    <listitem><para><emphasis>"ssh":</emphasis>
-                        An optional parameter used when "protocol" is set
-                        to "svn+ssh".
-                        You can use this parameter to specify the ssh
-                        program used by svn.
-                        </para></listitem>
-                    <listitem><para><emphasis>"transportuser":</emphasis>
-                        When required, sets the username for the transport.
-                        By default, this parameter is empty.
-                        The transport username is different than the username
-                        used in the main URL, which is passed to the subversion
-                        command.
-                        </para></listitem>
-                </itemizedlist>
-                Following are three examples using svn:
-                <literallayout class='monospaced'>
-     SRC_URI = "svn://myrepos/proj1;module=vip;protocol=http;rev=667"
-     SRC_URI = "svn://myrepos/proj1;module=opie;protocol=svn+ssh"
-     SRC_URI = "svn://myrepos/proj1;module=trunk;protocol=http;path_spec=${MY_DIR}/proj1"
-                </literallayout>
-            </para>
-        </section>
-
-        <section id='git-fetcher'>
-            <title>Git Fetcher (<filename>git://</filename>)</title>
-
-            <para>
-                This fetcher submodule fetches code from the Git
-                source control system.
-                The fetcher works by creating a bare clone of the
-                remote into
-                <link linkend='var-bb-GITDIR'><filename>GITDIR</filename></link>,
-                which is usually <filename>DL_DIR/git2</filename>.
-                This bare clone is then cloned into the work directory during the
-                unpack stage when a specific tree is checked out.
-                This is done using alternates and by reference to
-                minimize the amount of duplicate data on the disk and
-                make the unpack process fast.
-                The executable used can be set with
-                <filename>FETCHCMD_git</filename>.
-            </para>
-
-            <para>
-                This fetcher supports the following parameters:
-                <itemizedlist>
-                    <listitem><para><emphasis>"protocol":</emphasis>
-                        The protocol used to fetch the files.
-                        The default is "git" when a hostname is set.
-                        If a hostname is not set, the Git protocol is "file".
-                        You can also use "http", "https", "ssh" and "rsync".
-                        </para></listitem>
-                    <listitem><para><emphasis>"nocheckout":</emphasis>
-                        Tells the fetcher to not checkout source code when
-                        unpacking when set to "1".
-                        Set this option for the URL where there is a custom
-                        routine to checkout code.
-                        The default is "0".
-                        </para></listitem>
-                    <listitem><para><emphasis>"rebaseable":</emphasis>
-                        Indicates that the upstream Git repository can be rebased.
-                        You should set this parameter to "1" if
-                        revisions can become detached from branches.
-                        In this case, the source mirror tarball is done per
-                        revision, which has a loss of efficiency.
-                        Rebasing the upstream Git repository could cause the
-                        current revision to disappear from the upstream repository.
-                        This option reminds the fetcher to preserve the local cache
-                        carefully for future use.
-                        The default value for this parameter is "0".
-                        </para></listitem>
-                    <listitem><para><emphasis>"nobranch":</emphasis>
-                        Tells the fetcher to not check the SHA validation
-                        for the branch when set to "1".
-                        The default is "0".
-                        Set this option for the recipe that refers to
-                        the commit that is valid for a tag instead of
-                        the branch.
-                        </para></listitem>
-                    <listitem><para><emphasis>"bareclone":</emphasis>
-                        Tells the fetcher to clone a bare clone into the
-                        destination directory without checking out a working tree.
-                        Only the raw Git metadata is provided.
-                        This parameter implies the "nocheckout" parameter as well.
-                        </para></listitem>
-                    <listitem><para><emphasis>"branch":</emphasis>
-                        The branch(es) of the Git tree to clone.
-                        If unset, this is assumed to be "master".
-                        The number of branch parameters much match the number of
-                        name parameters.
-                        </para></listitem>
-                    <listitem><para><emphasis>"rev":</emphasis>
-                        The revision to use for the checkout.
-                        The default is "master".
-                        </para></listitem>
-                    <listitem><para><emphasis>"tag":</emphasis>
-                        Specifies a tag to use for the checkout.
-                        To correctly resolve tags, BitBake must access the
-                        network.
-                        For that reason, tags are often not used.
-                        As far as Git is concerned, the "tag" parameter behaves
-                        effectively the same as the "rev" parameter.
-                        </para></listitem>
-                    <listitem><para><emphasis>"subpath":</emphasis>
-                        Limits the checkout to a specific subpath of the tree.
-                        By default, the whole tree is checked out.
-                        </para></listitem>
-                    <listitem><para><emphasis>"destsuffix":</emphasis>
-                        The name of the path in which to place the checkout.
-                        By default, the path is <filename>git/</filename>.
-                        </para></listitem>
-                    <listitem><para><emphasis>"usehead":</emphasis>
-                        Enables local <filename>git://</filename> URLs to use the
-                        current branch HEAD as the revision for use with
-                        <filename>AUTOREV</filename>.
-                        The "usehead" parameter implies no branch and only works
-                        when the transfer protocol is
-                        <filename>file://</filename>.
-                        </para></listitem>
-                </itemizedlist>
-                Here are some example URLs:
-                <literallayout class='monospaced'>
-     SRC_URI = "git://git.oe.handhelds.org/git/vip.git;tag=version-1"
-     SRC_URI = "git://git.oe.handhelds.org/git/vip.git;protocol=http"
-                </literallayout>
-            </para>
-        </section>
-
-        <section id='gitsm-fetcher'>
-            <title>Git Submodule Fetcher (<filename>gitsm://</filename>)</title>
-
-            <para>
-                This fetcher submodule inherits from the
-                <link linkend='git-fetcher'>Git fetcher</link> and extends
-                that fetcher's behavior by fetching a repository's submodules.
-                <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link>
-                is passed to the Git fetcher as described in the
-                "<link linkend='git-fetcher'>Git Fetcher (<filename>git://</filename>)</link>"
-                section.
-                <note>
-                    <title>Notes and Warnings</title>
-                    <para>
-                        You must clean a recipe when switching between
-                        '<filename>git://</filename>' and
-                        '<filename>gitsm://</filename>' URLs.
-                    </para>
-
-                    <para>
-                        The Git Submodules fetcher is not a complete fetcher
-                        implementation.
-                        The fetcher has known issues where it does not use the
-                        normal source mirroring infrastructure properly. Further,
-                        the submodule sources it fetches are not visible to the
-                        licensing and source archiving infrastructures.
-                    </para>
-                </note>
-            </para>
-        </section>
-
-        <section id='clearcase-fetcher'>
-            <title>ClearCase Fetcher (<filename>ccrc://</filename>)</title>
-
-            <para>
-                This fetcher submodule fetches code from a
-                <ulink url='http://en.wikipedia.org/wiki/Rational_ClearCase'>ClearCase</ulink>
-                repository.
-            </para>
-
-            <para>
-                To use this fetcher, make sure your recipe has proper
-                <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link>,
-                <link linkend='var-bb-SRCREV'><filename>SRCREV</filename></link>, and
-                <link linkend='var-bb-PV'><filename>PV</filename></link> settings.
-                Here is an example:
-                <literallayout class='monospaced'>
-     SRC_URI = "ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module"
-     SRCREV = "EXAMPLE_CLEARCASE_TAG"
-     PV = "${@d.getVar("SRCREV", False).replace("/", "+")}"
-                </literallayout>
-                The fetcher uses the <filename>rcleartool</filename> or
-                <filename>cleartool</filename> remote client, depending on
-                which one is available.
-            </para>
-
-            <para>
-                Following are options for the <filename>SRC_URI</filename>
-                statement:
-                <itemizedlist>
-                    <listitem><para><emphasis><filename>vob</filename></emphasis>:
-                        The name, which must include the
-                        prepending "/" character, of the ClearCase VOB.
-                        This option is required.
-                        </para></listitem>
-                    <listitem><para><emphasis><filename>module</filename></emphasis>:
-                        The module, which must include the
-                        prepending "/" character, in the selected VOB.
-                        <note>
-                            The <filename>module</filename> and <filename>vob</filename>
-                            options are combined to create the <filename>load</filename> rule in
-                            the view config spec.
-                            As an example, consider the <filename>vob</filename> and
-                            <filename>module</filename> values from the
-                            <filename>SRC_URI</filename> statement at the start of this section.
-                            Combining those values results in the following:
-                            <literallayout class='monospaced'>
-     load /example_vob/example_module
-                            </literallayout>
-                        </note>
-                        </para></listitem>
-                    <listitem><para><emphasis><filename>proto</filename></emphasis>:
-                        The protocol, which can be either <filename>http</filename> or
-                        <filename>https</filename>.
-                        </para></listitem>
-                </itemizedlist>
-            </para>
-
-            <para>
-                By default, the fetcher creates a configuration specification.
-                If you want this specification written to an area other than the default,
-                use the <filename>CCASE_CUSTOM_CONFIG_SPEC</filename> variable
-                in your recipe to define where the specification is written.
-                <note>
-                    the <filename>SRCREV</filename> loses its functionality if you
-                    specify this variable.
-                    However, <filename>SRCREV</filename> is still used to label the
-                    archive after a fetch even though it does not define what is
-                    fetched.
-                </note>
-            </para>
-
-            <para>
-                Here are a couple of other behaviors worth mentioning:
-                <itemizedlist>
-                    <listitem><para>
-                        When using <filename>cleartool</filename>, the login of
-                        <filename>cleartool</filename> is handled by the system.
-                        The login require no special steps.
-                        </para></listitem>
-                    <listitem><para>
-                        In order to use <filename>rcleartool</filename> with authenticated
-                        users, an "rcleartool login" is necessary before using the fetcher.
-                        </para></listitem>
-                </itemizedlist>
-            </para>
-        </section>
-
-        <section id='perforce-fetcher'>
-            <title>Perforce Fetcher (<filename>p4://</filename>)</title>
-
-            <para>
-                This fetcher submodule fetches code from the
-                <ulink url='https://www.perforce.com/'>Perforce</ulink>
-                source control system.
-                The executable used is specified by
-                <filename>FETCHCMD_p4</filename>, which defaults
-                to "p4".
-                The fetcher's temporary working directory is set by
-                <link linkend='var-bb-P4DIR'><filename>P4DIR</filename></link>,
-                which defaults to "DL_DIR/p4".
-            </para>
-
-            <para>
-                To use this fetcher, make sure your recipe has proper
-                <link linkend='var-bb-SRC_URI'><filename>SRC_URI</filename></link>,
-                <link linkend='var-bb-SRCREV'><filename>SRCREV</filename></link>, and
-                <link linkend='var-bb-PV'><filename>PV</filename></link> values.
-                The p4 executable is able to use the config file defined by your
-                system's <filename>P4CONFIG</filename> environment variable in
-                order to define the Perforce server URL and port, username, and
-                password if you do not wish to keep those values in a recipe
-                itself.
-                If you choose not to use <filename>P4CONFIG</filename>,
-                or to explicitly set variables that <filename>P4CONFIG</filename>
-                can contain, you can specify the <filename>P4PORT</filename> value,
-                which is the server's URL and port number, and you can
-                specify a username and password directly in your recipe within
-                <filename>SRC_URI</filename>.
-            </para>
-
-            <para>
-                Here is an example that relies on <filename>P4CONFIG</filename>
-                to specify the server URL and port, username, and password, and
-                fetches the Head Revision:
-                <literallayout class='monospaced'>
-    SRC_URI = "p4://example-depot/main/source/..."
-    SRCREV = "${AUTOREV}"
-    PV = "p4-${SRCPV}"
-    S = "${WORKDIR}/p4"
-                </literallayout>
-            </para>
-
-            <para>
-                Here is an example that specifies the server URL and port,
-                username, and password, and fetches a Revision based on a Label:
-                <literallayout class='monospaced'>
-    P4PORT = "tcp:p4server.example.net:1666"
-    SRC_URI = "p4://user:passwd@example-depot/main/source/..."
-    SRCREV = "release-1.0"
-    PV = "p4-${SRCPV}"
-    S = "${WORKDIR}/p4"
-                </literallayout>
-                <note>
-                    You should always set <filename>S</filename>
-                    to <filename>"${WORKDIR}/p4"</filename> in your recipe.
-                </note>
-            </para>
-        </section>
-
-        <section id='repo-fetcher'>
-            <title>Repo Fetcher (<filename>repo://</filename>)</title>
-
-            <para>
-                This fetcher submodule fetches code from
-                <filename>google-repo</filename> source control system.
-                The fetcher works by initiating and syncing sources of the
-                repository into
-                <link linkend='var-bb-REPODIR'><filename>REPODIR</filename></link>,
-                which is usually
-                <link linkend='var-bb-DL_DIR'><filename>DL_DIR</filename></link><filename>/repo</filename>.
-            </para>
-
-            <para>
-                This fetcher supports the following parameters:
-                <itemizedlist>
-                    <listitem><para>
-                        <emphasis>"protocol":</emphasis>
-                        Protocol to fetch the repository manifest (default: git).
-                        </para></listitem>
-                    <listitem><para>
-                        <emphasis>"branch":</emphasis>
-                        Branch or tag of repository to get (default: master).
-                        </para></listitem>
-                    <listitem><para>
-                        <emphasis>"manifest":</emphasis>
-                        Name of the manifest file (default: <filename>default.xml</filename>).
-                        </para></listitem>
-                </itemizedlist>
-                Here are some example URLs:
-                <literallayout class='monospaced'>
-    SRC_URI = "repo://REPOROOT;protocol=git;branch=some_branch;manifest=my_manifest.xml"
-    SRC_URI = "repo://REPOROOT;protocol=file;branch=some_branch;manifest=my_manifest.xml"
-                </literallayout>
-            </para>
-        </section>
-
-        <section id='other-fetchers'>
-            <title>Other Fetchers</title>
-
-            <para>
-                Fetch submodules also exist for the following:
-                <itemizedlist>
-                    <listitem><para>
-                        Bazaar (<filename>bzr://</filename>)
-                        </para></listitem>
-                    <listitem><para>
-                        Mercurial (<filename>hg://</filename>)
-                        </para></listitem>
-                    <listitem><para>
-                        npm (<filename>npm://</filename>)
-                        </para></listitem>
-                    <listitem><para>
-                        OSC (<filename>osc://</filename>)
-                        </para></listitem>
-                    <listitem><para>
-                        Secure FTP (<filename>sftp://</filename>)
-                        </para></listitem>
-                    <listitem><para>
-                        Secure Shell (<filename>ssh://</filename>)
-                        </para></listitem>
-                    <listitem><para>
-                        Trees using Git Annex (<filename>gitannex://</filename>)
-                        </para></listitem>
-                </itemizedlist>
-                No documentation currently exists for these lesser used
-                fetcher submodules.
-                However, you might find the code helpful and readable.
-            </para>
-        </section>
-    </section>
-
-    <section id='auto-revisions'>
-        <title>Auto Revisions</title>
-
-        <para>
-            We need to document <filename>AUTOREV</filename> and
-            <filename>SRCREV_FORMAT</filename> here.
-        </para>
-    </section>
-</chapter>

bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.rst

@@ -0,0 +1,415 @@
+.. SPDX-License-Identifier: CC-BY-2.5
+
+===================
+Hello World Example
+===================
+
+BitBake Hello World
+===================
+
+The simplest example commonly used to demonstrate any new programming
+language or tool is the "`Hello
+World <http://en.wikipedia.org/wiki/Hello_world_program>`__" example.
+This appendix demonstrates, in tutorial form, Hello World within the
+context of BitBake. The tutorial describes how to create a new project
+and the applicable metadata files necessary to allow BitBake to build
+it.
+
+Obtaining BitBake
+=================
+
+See the :ref:`bitbake-user-manual/bitbake-user-manual-hello:obtaining bitbake` section for
+information on how to obtain BitBake. Once you have the source code on
+your machine, the BitBake directory appears as follows: ::
+
+   $ ls -al
+   total 100
+   drwxrwxr-x. 9 wmat wmat  4096 Jan 31 13:44 .
+   drwxrwxr-x. 3 wmat wmat  4096 Feb  4 10:45 ..
+   -rw-rw-r--. 1 wmat wmat   365 Nov 26 04:55 AUTHORS
+   drwxrwxr-x. 2 wmat wmat  4096 Nov 26 04:55 bin
+   drwxrwxr-x. 4 wmat wmat  4096 Jan 31 13:44 build
+   -rw-rw-r--. 1 wmat wmat 16501 Nov 26 04:55 ChangeLog
+   drwxrwxr-x. 2 wmat wmat  4096 Nov 26 04:55 classes
+   drwxrwxr-x. 2 wmat wmat  4096 Nov 26 04:55 conf
+   drwxrwxr-x. 3 wmat wmat  4096 Nov 26 04:55 contrib
+   -rw-rw-r--. 1 wmat wmat 17987 Nov 26 04:55 COPYING
+   drwxrwxr-x. 3 wmat wmat  4096 Nov 26 04:55 doc
+   -rw-rw-r--. 1 wmat wmat    69 Nov 26 04:55 .gitignore
+   -rw-rw-r--. 1 wmat wmat   849 Nov 26 04:55 HEADER
+   drwxrwxr-x. 5 wmat wmat  4096 Jan 31 13:44 lib
+   -rw-rw-r--. 1 wmat wmat   195 Nov 26 04:55 MANIFEST.in
+   -rw-rw-r--. 1 wmat wmat  2887 Nov 26 04:55 TODO
+
+At this point, you should have BitBake cloned to a directory that
+matches the previous listing except for dates and user names.
+
+Setting Up the BitBake Environment
+==================================
+
+First, you need to be sure that you can run BitBake. Set your working
+directory to where your local BitBake files are and run the following
+command: ::
+
+  $ ./bin/bitbake --version
+  BitBake Build Tool Core version 1.23.0, bitbake version 1.23.0
+
+The console output tells you what version
+you are running.
+
+The recommended method to run BitBake is from a directory of your
+choice. To be able to run BitBake from any directory, you need to add
+the executable binary to your binary to your shell's environment
+``PATH`` variable. First, look at your current ``PATH`` variable by
+entering the following: ::
+
+  $ echo $PATH
+
+Next, add the directory location
+for the BitBake binary to the ``PATH``. Here is an example that adds the
+``/home/scott-lenovo/bitbake/bin`` directory to the front of the
+``PATH`` variable: ::
+
+  $ export PATH=/home/scott-lenovo/bitbake/bin:$PATH
+
+You should now be able to enter the ``bitbake`` command from the command
+line while working from any directory.
+
+The Hello World Example
+=======================
+
+The overall goal of this exercise is to build a complete "Hello World"
+example utilizing task and layer concepts. Because this is how modern
+projects such as OpenEmbedded and the Yocto Project utilize BitBake, the
+example provides an excellent starting point for understanding BitBake.
+
+To help you understand how to use BitBake to build targets, the example
+starts with nothing but the ``bitbake`` command, which causes BitBake to
+fail and report problems. The example progresses by adding pieces to the
+build to eventually conclude with a working, minimal "Hello World"
+example.
+
+While every attempt is made to explain what is happening during the
+example, the descriptions cannot cover everything. You can find further
+information throughout this manual. Also, you can actively participate
+in the :oe_lists:`/g/bitbake-devel`
+discussion mailing list about the BitBake build tool.
+
+.. note::
+
+   This example was inspired by and drew heavily from
+   `Mailing List post - The BitBake equivalent of "Hello, World!"
+   <http://www.mail-archive.com/yocto@yoctoproject.org/msg09379.html>`_.
+
+As stated earlier, the goal of this example is to eventually compile
+"Hello World". However, it is unknown what BitBake needs and what you
+have to provide in order to achieve that goal. Recall that BitBake
+utilizes three types of metadata files:
+:ref:`bitbake-user-manual/bitbake-user-manual-intro:configuration files`,
+:ref:`bitbake-user-manual/bitbake-user-manual-intro:classes`, and
+:ref:`bitbake-user-manual/bitbake-user-manual-intro:recipes`.
+But where do they go? How does BitBake find
+them? BitBake's error messaging helps you answer these types of
+questions and helps you better understand exactly what is going on.
+
+Following is the complete "Hello World" example.
+
+#.  **Create a Project Directory:** First, set up a directory for the
+    "Hello World" project. Here is how you can do so in your home
+    directory: ::
+
+      $ mkdir ~/hello
+      $ cd ~/hello
+
+    This is the directory that
+    BitBake will use to do all of its work. You can use this directory
+    to keep all the metafiles needed by BitBake. Having a project
+    directory is a good way to isolate your project.
+
+#.  **Run BitBake:** At this point, you have nothing but a project
+    directory. Run the ``bitbake`` command and see what it does: ::
+
+       $ bitbake
+       The BBPATH variable is not set and bitbake did not
+       find a conf/bblayers.conf file in the expected location.
+       Maybe you accidentally invoked bitbake from the wrong directory?
+       DEBUG: Removed the following variables from the environment:
+       GNOME_DESKTOP_SESSION_ID, XDG_CURRENT_DESKTOP,
+       GNOME_KEYRING_CONTROL, DISPLAY, SSH_AGENT_PID, LANG, no_proxy,
+       XDG_SESSION_PATH, XAUTHORITY, SESSION_MANAGER, SHLVL,
+       MANDATORY_PATH, COMPIZ_CONFIG_PROFILE, WINDOWID, EDITOR,
+       GPG_AGENT_INFO, SSH_AUTH_SOCK, GDMSESSION, GNOME_KEYRING_PID,
+       XDG_SEAT_PATH, XDG_CONFIG_DIRS, LESSOPEN, DBUS_SESSION_BUS_ADDRESS,
+       _, XDG_SESSION_COOKIE, DESKTOP_SESSION, LESSCLOSE, DEFAULTS_PATH,
+       UBUNTU_MENUPROXY, OLDPWD, XDG_DATA_DIRS, COLORTERM, LS_COLORS
+
+    The majority of this output is specific to environment variables that
+    are not directly relevant to BitBake. However, the very first
+    message regarding the ``BBPATH`` variable and the
+    ``conf/bblayers.conf`` file is relevant.
+
+    When you run BitBake, it begins looking for metadata files. The
+    :term:`BBPATH` variable is what tells BitBake where
+    to look for those files. ``BBPATH`` is not set and you need to set
+    it. Without ``BBPATH``, BitBake cannot find any configuration files
+    (``.conf``) or recipe files (``.bb``) at all. BitBake also cannot
+    find the ``bitbake.conf`` file.
+
+#.  **Setting BBPATH:** For this example, you can set ``BBPATH`` in
+    the same manner that you set ``PATH`` earlier in the appendix. You
+    should realize, though, that it is much more flexible to set the
+    ``BBPATH`` variable up in a configuration file for each project.
+
+    From your shell, enter the following commands to set and export the
+    ``BBPATH`` variable: ::
+
+      $ BBPATH="projectdirectory"
+      $ export BBPATH
+
+    Use your actual project directory in the command. BitBake uses that
+    directory to find the metadata it needs for your project.
+
+    .. note::
+
+       When specifying your project directory, do not use the tilde
+       ("~") character as BitBake does not expand that character as the
+       shell would.
+
+#.  **Run BitBake:** Now that you have ``BBPATH`` defined, run the
+    ``bitbake`` command again: ::
+
+       $ bitbake
+       ERROR: Traceback (most recent call last):
+         File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped
+           return func(fn, *args)
+         File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 173, in parse_config_file
+           return bb.parse.handle(fn, data, include)
+         File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 99, in handle
+           return h['handle'](fn, data, include)
+         File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 120, in handle
+           abs_fn = resolve_file(fn, data)
+         File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 117, in resolve_file
+           raise IOError("file %s not found in %s" % (fn, bbpath))
+       IOError: file conf/bitbake.conf not found in /home/scott-lenovo/hello
+
+       ERROR: Unable to parse conf/bitbake.conf: file conf/bitbake.conf not found in /home/scott-lenovo/hello
+
+    This sample output shows that BitBake could not find the
+    ``conf/bitbake.conf`` file in the project directory. This file is
+    the first thing BitBake must find in order to build a target. And,
+    since the project directory for this example is empty, you need to
+    provide a ``conf/bitbake.conf`` file.
+
+#.  **Creating conf/bitbake.conf:** The ``conf/bitbake.conf`` includes
+    a number of configuration variables BitBake uses for metadata and
+    recipe files. For this example, you need to create the file in your
+    project directory and define some key BitBake variables. For more
+    information on the ``bitbake.conf`` file, see
+    http://git.openembedded.org/bitbake/tree/conf/bitbake.conf.
+
+    Use the following commands to create the ``conf`` directory in the
+    project directory: ::
+
+      $ mkdir conf
+
+    From within the ``conf`` directory,
+    use some editor to create the ``bitbake.conf`` so that it contains
+    the following: ::
+
+       PN  = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}"
+
+       TMPDIR  = "${TOPDIR}/tmp"
+       CACHE   = "${TMPDIR}/cache"
+       STAMP   = "${TMPDIR}/${PN}/stamps"
+       T       = "${TMPDIR}/${PN}/work"
+       B       = "${TMPDIR}/${PN}"
+
+    .. note::
+
+       Without a value for PN , the variables STAMP , T , and B , prevent more
+       than one recipe from working. You can fix this by either setting PN to
+       have a value similar to what OpenEmbedded and BitBake use in the default
+       bitbake.conf file (see previous example). Or, by manually updating each
+       recipe to set PN . You will also need to include PN as part of the STAMP
+       , T , and B variable definitions in the local.conf file.
+
+    The ``TMPDIR`` variable establishes a directory that BitBake uses
+    for build output and intermediate files other than the cached
+    information used by the
+    :ref:`bitbake-user-manual/bitbake-user-manual-execution:setscene`
+    process. Here, the ``TMPDIR`` directory is set to ``hello/tmp``.
+
+    .. tip::
+
+       You can always safely delete the tmp directory in order to rebuild a
+       BitBake target. The build process creates the directory for you when you
+       run BitBake.
+
+    For information about each of the other variables defined in this
+    example, check :term:`PN`, :term:`TOPDIR`, :term:`CACHE`, :term:`STAMP`,
+    :term:`T` or :term:`B` to take you to the definitions in the
+    glossary.
+
+#.  **Run BitBake:** After making sure that the ``conf/bitbake.conf`` file
+    exists, you can run the ``bitbake`` command again: ::
+
+       $ bitbake
+       ERROR: Traceback (most recent call last):
+         File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped
+           return func(fn, *args)
+         File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 177, in _inherit
+           bb.parse.BBHandler.inherit(bbclass, "configuration INHERITs", 0, data)
+         File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 92, in inherit
+           include(fn, file, lineno, d, "inherit")
+         File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 100, in include
+           raise ParseError("Could not %(error_out)s file %(fn)s" % vars(), oldfn, lineno)
+       ParseError: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
+
+       ERROR: Unable to parse base: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
+
+    In the sample output,
+    BitBake could not find the ``classes/base.bbclass`` file. You need
+    to create that file next.
+
+#.  **Creating classes/base.bbclass:** BitBake uses class files to
+    provide common code and functionality. The minimally required class
+    for BitBake is the ``classes/base.bbclass`` file. The ``base`` class
+    is implicitly inherited by every recipe. BitBake looks for the class
+    in the ``classes`` directory of the project (i.e ``hello/classes``
+    in this example).
+
+    Create the ``classes`` directory as follows: ::
+
+      $ cd $HOME/hello
+      $ mkdir classes
+
+    Move to the ``classes`` directory and then create the
+    ``base.bbclass`` file by inserting this single line: addtask build
+    The minimal task that BitBake runs is the ``do_build`` task. This is
+    all the example needs in order to build the project. Of course, the
+    ``base.bbclass`` can have much more depending on which build
+    environments BitBake is supporting.
+
+#.  **Run BitBake:** After making sure that the ``classes/base.bbclass``
+    file exists, you can run the ``bitbake`` command again: ::
+
+       $ bitbake
+       Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.
+
+    BitBake is finally reporting
+    no errors. However, you can see that it really does not have
+    anything to do. You need to create a recipe that gives BitBake
+    something to do.
+
+#.  **Creating a Layer:** While it is not really necessary for such a
+    small example, it is good practice to create a layer in which to
+    keep your code separate from the general metadata used by BitBake.
+    Thus, this example creates and uses a layer called "mylayer".
+
+    .. note::
+
+       You can find additional information on layers in the
+       ":ref:`bitbake-user-manual/bitbake-user-manual-intro:Layers`" section.
+
+    Minimally, you need a recipe file and a layer configuration file in
+    your layer. The configuration file needs to be in the ``conf``
+    directory inside the layer. Use these commands to set up the layer
+    and the ``conf`` directory: ::
+
+       $ cd $HOME
+       $ mkdir mylayer
+       $ cd mylayer
+       $ mkdir conf
+
+    Move to the ``conf`` directory and create a ``layer.conf`` file that has the
+    following: ::
+
+      BBPATH .= ":${LAYERDIR}"
+      BBFILES += "${LAYERDIR}/\*.bb"
+      BBFILE_COLLECTIONS += "mylayer"
+     `BBFILE_PATTERN_mylayer := "^${LAYERDIR_RE}/"
+
+    For information on these variables, click on :term:`BBFILES`,
+    :term:`LAYERDIR`, :term:`BBFILE_COLLECTIONS` or :term:`BBFILE_PATTERN_mylayer <BBFILE_PATTERN>`
+    to go to the definitions in the glossary.
+
+    You need to create the recipe file next. Inside your layer at the
+    top-level, use an editor and create a recipe file named
+    ``printhello.bb`` that has the following: ::
+
+       DESCRIPTION = "Prints Hello World"
+       PN = 'printhello'
+       PV = '1'
+
+       python do_build() {
+          bb.plain("********************");
+          bb.plain("*                  *");
+          bb.plain("*  Hello, World!   *");
+          bb.plain("*                  *");
+          bb.plain("********************");
+       }
+
+    The recipe file simply provides
+    a description of the recipe, the name, version, and the ``do_build``
+    task, which prints out "Hello World" to the console. For more
+    information on :term:`DESCRIPTION`, :term:`PN` or :term:`PV`
+    follow the links to the glossary.
+
+#. **Run BitBake With a Target:** Now that a BitBake target exists, run
+    the command and provide that target: ::
+
+      $ cd $HOME/hello
+      $ bitbake printhello
+      ERROR: no recipe files to build, check your BBPATH and BBFILES?
+
+      Summary: There was 1 ERROR message shown, returning a non-zero exit code.
+
+    We have created the layer with the recipe and
+    the layer configuration file but it still seems that BitBake cannot
+    find the recipe. BitBake needs a ``conf/bblayers.conf`` that lists
+    the layers for the project. Without this file, BitBake cannot find
+    the recipe.
+
+#. **Creating conf/bblayers.conf:** BitBake uses the
+    ``conf/bblayers.conf`` file to locate layers needed for the project.
+    This file must reside in the ``conf`` directory of the project (i.e.
+    ``hello/conf`` for this example).
+
+    Set your working directory to the ``hello/conf`` directory and then
+    create the ``bblayers.conf`` file so that it contains the following: ::
+
+       BBLAYERS ?= " \
+           /home/<you>/mylayer \
+       "
+
+    You need to provide your own information for ``you`` in the file.
+
+#. **Run BitBake With a Target:** Now that you have supplied the
+    ``bblayers.conf`` file, run the ``bitbake`` command and provide the
+    target: ::
+
+       $ bitbake printhello
+       Parsing recipes: 100% |##################################################################################|
+       Time: 00:00:00
+       Parsing of 1 .bb files complete (0 cached, 1 parsed). 1 targets, 0 skipped, 0 masked, 0 errors.
+       NOTE: Resolving any missing task queue dependencies
+       NOTE: Preparing RunQueue
+       NOTE: Executing RunQueue Tasks
+       ********************
+       *                  *
+       *  Hello, World!   *
+       *                  *
+       ********************
+       NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded.
+
+    .. note::
+
+       After the first execution, re-running bitbake printhello again will not
+       result in a BitBake run that prints the same console output. The reason
+       for this is that the first time the printhello.bb recipe's do_build task
+       executes successfully, BitBake writes a stamp file for the task. Thus,
+       the next time you attempt to run the task using that same bitbake
+       command, BitBake notices the stamp and therefore determines that the task
+       does not need to be re-run. If you delete the tmp directory or run
+       bitbake -c clean printhello and then re-run the build, the "Hello,
+       World!" message will be printed again.

bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.xml

@@ -1,513 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<appendix id='hello-world-example'>
-    <title>Hello World Example</title>
-
-    <section id='bitbake-hello-world'>
-        <title>BitBake Hello World</title>
-
-        <para>
-            The simplest example commonly used to demonstrate any new
-            programming language or tool is the
-            "<ulink url="http://en.wikipedia.org/wiki/Hello_world_program">Hello World</ulink>"
-            example.
-            This appendix demonstrates, in tutorial form, Hello
-            World within the context of BitBake.
-            The tutorial describes how to create a new project
-            and the applicable metadata files necessary to allow
-            BitBake to build it.
-        </para>
-    </section>
-
-    <section id='example-obtaining-bitbake'>
-        <title>Obtaining BitBake</title>
-
-        <para>
-            See the
-            "<link linkend='obtaining-bitbake'>Obtaining BitBake</link>"
-            section for information on how to obtain BitBake.
-            Once you have the source code on your machine, the BitBake directory
-            appears as follows:
-            <literallayout class='monospaced'>
-     $ ls -al
-     total 100
-     drwxrwxr-x. 9 wmat wmat  4096 Jan 31 13:44 .
-     drwxrwxr-x. 3 wmat wmat  4096 Feb  4 10:45 ..
-     -rw-rw-r--. 1 wmat wmat   365 Nov 26 04:55 AUTHORS
-     drwxrwxr-x. 2 wmat wmat  4096 Nov 26 04:55 bin
-     drwxrwxr-x. 4 wmat wmat  4096 Jan 31 13:44 build
-     -rw-rw-r--. 1 wmat wmat 16501 Nov 26 04:55 ChangeLog
-     drwxrwxr-x. 2 wmat wmat  4096 Nov 26 04:55 classes
-     drwxrwxr-x. 2 wmat wmat  4096 Nov 26 04:55 conf
-     drwxrwxr-x. 3 wmat wmat  4096 Nov 26 04:55 contrib
-     -rw-rw-r--. 1 wmat wmat 17987 Nov 26 04:55 COPYING
-     drwxrwxr-x. 3 wmat wmat  4096 Nov 26 04:55 doc
-     -rw-rw-r--. 1 wmat wmat    69 Nov 26 04:55 .gitignore
-     -rw-rw-r--. 1 wmat wmat   849 Nov 26 04:55 HEADER
-     drwxrwxr-x. 5 wmat wmat  4096 Jan 31 13:44 lib
-     -rw-rw-r--. 1 wmat wmat   195 Nov 26 04:55 MANIFEST.in
-     -rw-rw-r--. 1 wmat wmat  2887 Nov 26 04:55 TODO
-            </literallayout>
-        </para>
-
-        <para>
-            At this point, you should have BitBake cloned to
-            a directory that matches the previous listing except for
-            dates and user names.
-        </para>
-    </section>
-
-    <section id='setting-up-the-bitbake-environment'>
-        <title>Setting Up the BitBake Environment</title>
-
-        <para>
-            First, you need to be sure that you can run BitBake.
-            Set your working directory to where your local BitBake
-            files are and run the following command:
-            <literallayout class='monospaced'>
-     $ ./bin/bitbake --version
-     BitBake Build Tool Core version 1.23.0, bitbake version 1.23.0
-            </literallayout>
-            The console output tells you what version you are running.
-        </para>
-
-        <para>
-            The recommended method to run BitBake is from a directory of your
-            choice.
-            To be able to run BitBake from any directory, you need to add the
-            executable binary to your binary to your shell's environment
-            <filename>PATH</filename> variable.
-            First, look at your current <filename>PATH</filename> variable
-            by entering the following:
-            <literallayout class='monospaced'>
-     $ echo $PATH
-            </literallayout>
-            Next, add the directory location for the BitBake binary to the
-            <filename>PATH</filename>.
-            Here is an example that adds the
-            <filename>/home/scott-lenovo/bitbake/bin</filename> directory
-            to the front of the <filename>PATH</filename> variable:
-            <literallayout class='monospaced'>
-     $ export PATH=/home/scott-lenovo/bitbake/bin:$PATH
-            </literallayout>
-            You should now be able to enter the <filename>bitbake</filename>
-            command from the command line while working from any directory.
-        </para>
-    </section>
-
-    <section id='the-hello-world-example'>
-        <title>The Hello World Example</title>
-
-        <para>
-            The overall goal of this exercise is to build a
-            complete "Hello World" example utilizing task and layer
-            concepts.
-            Because this is how modern projects such as OpenEmbedded and
-            the Yocto Project utilize BitBake, the example
-            provides an excellent starting point for understanding
-            BitBake.
-        </para>
-
-        <para>
-            To help you understand how to use BitBake to build targets,
-            the example starts with nothing but the <filename>bitbake</filename>
-            command, which causes BitBake to fail and report problems.
-            The example progresses by adding pieces to the build to
-            eventually conclude with a working, minimal "Hello World"
-            example.
-        </para>
-
-        <para>
-            While every attempt is made to explain what is happening during
-            the example, the descriptions cannot cover everything.
-            You can find further information throughout this manual.
-            Also, you can actively participate in the
-            <ulink url='http://lists.openembedded.org/mailman/listinfo/bitbake-devel'></ulink>
-            discussion mailing list about the BitBake build tool.
-        </para>
-
-        <note>
-            This example was inspired by and drew heavily from
-            <ulink url="http://www.mail-archive.com/yocto@yoctoproject.org/msg09379.html">Mailing List post - The BitBake equivalent of "Hello, World!"</ulink>.
-        </note>
-
-        <para>
-            As stated earlier, the goal of this example
-            is to eventually compile "Hello World".
-            However, it is unknown what BitBake needs and what you have
-            to provide in order to achieve that goal.
-            Recall that BitBake utilizes three types of metadata files:
-            <link linkend='configuration-files'>Configuration Files</link>,
-            <link linkend='classes'>Classes</link>, and
-            <link linkend='recipes'>Recipes</link>.
-            But where do they go?
-            How does BitBake find them?
-            BitBake's error messaging helps you answer these types of questions
-            and helps you better understand exactly what is going on.
-        </para>
-
-        <para>
-            Following is the complete "Hello World" example.
-        </para>
-
-        <orderedlist>
-            <listitem><para><emphasis>Create a Project Directory:</emphasis>
-                First, set up a directory for the "Hello World" project.
-                Here is how you can do so in your home directory:
-                <literallayout class='monospaced'>
-     $ mkdir ~/hello
-     $ cd ~/hello
-                </literallayout>
-                This is the directory that BitBake will use to do all of
-                its work.
-                You can use this directory to keep all the metafiles needed
-                by BitBake.
-                Having a project directory is a good way to isolate your
-                project.
-                </para></listitem>
-            <listitem><para><emphasis>Run BitBake:</emphasis>
-                At this point, you have nothing but a project directory.
-                Run the <filename>bitbake</filename> command and see what
-                it does:
-                <literallayout class='monospaced'>
-     $ bitbake
-     The BBPATH variable is not set and bitbake did not
-     find a conf/bblayers.conf file in the expected location.
-     Maybe you accidentally invoked bitbake from the wrong directory?
-     DEBUG: Removed the following variables from the environment:
-     GNOME_DESKTOP_SESSION_ID, XDG_CURRENT_DESKTOP,
-     GNOME_KEYRING_CONTROL, DISPLAY, SSH_AGENT_PID, LANG, no_proxy,
-     XDG_SESSION_PATH, XAUTHORITY, SESSION_MANAGER, SHLVL,
-     MANDATORY_PATH, COMPIZ_CONFIG_PROFILE, WINDOWID, EDITOR,
-     GPG_AGENT_INFO, SSH_AUTH_SOCK, GDMSESSION, GNOME_KEYRING_PID,
-     XDG_SEAT_PATH, XDG_CONFIG_DIRS, LESSOPEN, DBUS_SESSION_BUS_ADDRESS,
-     _, XDG_SESSION_COOKIE, DESKTOP_SESSION, LESSCLOSE, DEFAULTS_PATH,
-     UBUNTU_MENUPROXY, OLDPWD, XDG_DATA_DIRS, COLORTERM, LS_COLORS
-                </literallayout>
-                The majority of this output is specific to environment variables
-                that are not directly relevant to BitBake.
-                However, the very first message regarding the
-                <filename>BBPATH</filename> variable and the
-                <filename>conf/bblayers.conf</filename> file
-                is relevant.</para>
-                <para>
-                When you run BitBake, it begins looking for metadata files.
-                The
-                <link linkend='var-bb-BBPATH'><filename>BBPATH</filename></link>
-                variable is what tells BitBake where to look for those files.
-                <filename>BBPATH</filename> is not set and you need to set it.
-                Without <filename>BBPATH</filename>, BitBake cannot
-                find any configuration files (<filename>.conf</filename>)
-                or recipe files (<filename>.bb</filename>) at all.
-                BitBake also cannot find the <filename>bitbake.conf</filename>
-                file.
-                </para></listitem>
-            <listitem><para><emphasis>Setting <filename>BBPATH</filename>:</emphasis>
-                For this example, you can set <filename>BBPATH</filename>
-                in the same manner that you set <filename>PATH</filename>
-                earlier in the appendix.
-                You should realize, though, that it is much more flexible to set the
-                <filename>BBPATH</filename> variable up in a configuration
-                file for each project.</para>
-                <para>From your shell, enter the following commands to set and
-                export the <filename>BBPATH</filename> variable:
-                <literallayout class='monospaced'>
-     $ BBPATH="<replaceable>projectdirectory</replaceable>"
-     $ export BBPATH
-                </literallayout>
-                Use your actual project directory in the command.
-                BitBake uses that directory to find the metadata it needs for
-                your project.
-                <note>
-                    When specifying your project directory, do not use the
-                    tilde ("~") character as BitBake does not expand that character
-                    as the shell would.
-                </note>
-                </para></listitem>
-            <listitem><para><emphasis>Run BitBake:</emphasis>
-                Now that you have <filename>BBPATH</filename> defined, run
-                the <filename>bitbake</filename> command again:
-                <literallayout class='monospaced'>
-     $ bitbake
-     ERROR: Traceback (most recent call last):
-       File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped
-         return func(fn, *args)
-       File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 173, in parse_config_file
-         return bb.parse.handle(fn, data, include)
-       File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 99, in handle
-         return h['handle'](fn, data, include)
-       File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 120, in handle
-         abs_fn = resolve_file(fn, data)
-       File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 117, in resolve_file
-         raise IOError("file %s not found in %s" % (fn, bbpath))
-     IOError: file conf/bitbake.conf not found in /home/scott-lenovo/hello
-
-     ERROR: Unable to parse conf/bitbake.conf: file conf/bitbake.conf not found in /home/scott-lenovo/hello
-                </literallayout>
-                This sample output shows that BitBake could not find the
-                <filename>conf/bitbake.conf</filename> file in the project
-                directory.
-                This file is the first thing BitBake must find in order
-                to build a target.
-                And, since the project directory for this example is
-                empty, you need to provide a <filename>conf/bitbake.conf</filename>
-                file.
-                </para></listitem>
-            <listitem><para><emphasis>Creating <filename>conf/bitbake.conf</filename>:</emphasis>
-                The <filename>conf/bitbake.conf</filename> includes a number of
-                configuration variables BitBake uses for metadata and recipe
-                files.
-                For this example, you need to create the file in your project directory
-                and define some key BitBake variables.
-                For more information on the <filename>bitbake.conf</filename> file,
-                see
-                <ulink url='http://git.openembedded.org/bitbake/tree/conf/bitbake.conf'></ulink>.
-                </para>
-                <para>Use the following commands to create the <filename>conf</filename>
-                directory in the project directory:
-                <literallayout class='monospaced'>
-     $ mkdir conf
-                </literallayout>
-                From within the <filename>conf</filename> directory, use
-                some editor to create the <filename>bitbake.conf</filename>
-                so that it contains the following:
-                <literallayout class='monospaced'>
-     <link linkend='var-bb-PN'>PN</link>  = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}"
-                </literallayout>
-                <literallayout class='monospaced'>
-     TMPDIR  = "${<link linkend='var-bb-TOPDIR'>TOPDIR</link>}/tmp"
-     <link linkend='var-bb-CACHE'>CACHE</link>   = "${TMPDIR}/cache"
-     <link linkend='var-bb-STAMP'>STAMP</link>   = "${TMPDIR}/${PN}/stamps"
-     <link linkend='var-bb-T'>T</link>       = "${TMPDIR}/${PN}/work"
-     <link linkend='var-bb-B'>B</link>       = "${TMPDIR}/${PN}"
-                </literallayout>
-                <note>
-                    Without a value for <filename>PN</filename>, the
-                    variables <filename>STAMP</filename>,
-                    <filename>T</filename>, and <filename>B</filename>,
-                    prevent more than one recipe from working. You can fix
-                    this by either setting <filename>PN</filename> to have
-                    a value similar to what OpenEmbedded and BitBake use
-                    in the default <filename>bitbake.conf</filename> file
-                    (see previous example). Or, by manually updating each
-                    recipe to set <filename>PN</filename>. You will also
-                    need to include <filename>PN</filename> as part of the
-                    <filename>STAMP</filename>, <filename>T</filename>, and
-                    <filename>B</filename> variable definitions in the
-                    <filename>local.conf</filename> file.
-                </note>
-                The <filename>TMPDIR</filename> variable establishes a directory
-                that BitBake uses for build output and intermediate files other
-                than the cached information used by the
-                <link linkend='setscene'>Setscene</link> process.
-                Here, the <filename>TMPDIR</filename> directory is set to
-                <filename>hello/tmp</filename>.
-                <note><title>Tip</title>
-                    You can always safely delete the <filename>tmp</filename>
-                    directory in order to rebuild a BitBake target.
-                    The build process creates the directory for you
-                    when you run BitBake.
-                </note></para>
-                <para>For information about each of the other variables defined in this
-                example, click on the links to take you to the definitions in
-                the glossary.
-                </para></listitem>
-            <listitem><para><emphasis>Run BitBake:</emphasis>
-                After making sure that the <filename>conf/bitbake.conf</filename>
-                file exists, you can run the <filename>bitbake</filename>
-                command again:
-                <literallayout class='monospaced'>
-     $ bitbake
-     ERROR: Traceback (most recent call last):
-       File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped
-         return func(fn, *args)
-       File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 177, in _inherit
-         bb.parse.BBHandler.inherit(bbclass, "configuration INHERITs", 0, data)
-       File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 92, in inherit
-         include(fn, file, lineno, d, "inherit")
-       File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 100, in include
-         raise ParseError("Could not %(error_out)s file %(fn)s" % vars(), oldfn, lineno)
-     ParseError: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
-
-     ERROR: Unable to parse base: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
-                </literallayout>
-                In the sample output, BitBake could not find the
-                <filename>classes/base.bbclass</filename> file.
-                You need to create that file next.
-                </para></listitem>
-            <listitem><para><emphasis>Creating <filename>classes/base.bbclass</filename>:</emphasis>
-                BitBake uses class files to provide common code and functionality.
-                The minimally required class for BitBake is the
-                <filename>classes/base.bbclass</filename> file.
-                The <filename>base</filename> class is implicitly inherited by
-                every recipe.
-                BitBake looks for the class in the <filename>classes</filename>
-                directory of the project (i.e <filename>hello/classes</filename>
-                in this example).
-                </para>
-                <para>Create the <filename>classes</filename> directory as follows:
-                <literallayout class='monospaced'>
-     $ cd $HOME/hello
-     $ mkdir classes
-                </literallayout>
-                Move to the <filename>classes</filename> directory and then
-                create the <filename>base.bbclass</filename> file by inserting
-                this single line:
-                <literallayout class='monospaced'>
-     addtask build
-                </literallayout>
-                The minimal task that BitBake runs is the
-                <filename>do_build</filename> task.
-                This is all the example needs in order to build the project.
-                Of course, the <filename>base.bbclass</filename> can have much
-                more depending on which build environments BitBake is
-                supporting.
-                </para></listitem>
-            <listitem><para><emphasis>Run BitBake:</emphasis>
-                After making sure that the <filename>classes/base.bbclass</filename>
-                file exists, you can run the <filename>bitbake</filename>
-                command again:
-                <literallayout class='monospaced'>
-     $ bitbake
-     Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.
-                </literallayout>
-                BitBake is finally reporting no errors.
-                However, you can see that it really does not have anything
-                to do.
-                You need to create a recipe that gives BitBake something to do.
-                </para></listitem>
-            <listitem><para><emphasis>Creating a Layer:</emphasis>
-                While it is not really necessary for such a small example,
-                it is good practice to create a layer in which to keep your
-                code separate from the general metadata used by BitBake.
-                Thus, this example creates and uses a layer called "mylayer".
-                <note>
-                    You can find additional information on layers in the
-                    "<link linkend='layers'>Layers</link>" section.
-                </note></para>
-
-                <para>Minimally, you need a recipe file and a layer configuration
-                file in your layer.
-                The configuration file needs to be in the <filename>conf</filename>
-                directory inside the layer.
-                Use these commands to set up the layer and the <filename>conf</filename>
-                directory:
-                <literallayout class='monospaced'>
-     $ cd $HOME
-     $ mkdir mylayer
-     $ cd mylayer
-     $ mkdir conf
-                </literallayout>
-                Move to the <filename>conf</filename> directory and create a
-                <filename>layer.conf</filename> file that has the following:
-                <literallayout class='monospaced'>
-     BBPATH .= ":${<link linkend='var-bb-LAYERDIR'>LAYERDIR</link>}"
-
-     <link linkend='var-bb-BBFILES'>BBFILES</link> += "${LAYERDIR}/*.bb"
-
-     <link linkend='var-bb-BBFILE_COLLECTIONS'>BBFILE_COLLECTIONS</link> += "mylayer"
-     <link linkend='var-bb-BBFILE_PATTERN'>BBFILE_PATTERN_mylayer</link> := "^${LAYERDIR_RE}/"
-                </literallayout>
-                For information on these variables, click the links
-                to go to the definitions in the glossary.</para>
-                <para>You need to create the recipe file next.
-                Inside your layer at the top-level, use an editor and create
-                a recipe file named <filename>printhello.bb</filename> that
-                has the following:
-                <literallayout class='monospaced'>
-     <link linkend='var-bb-DESCRIPTION'>DESCRIPTION</link> = "Prints Hello World"
-     <link linkend='var-bb-PN'>PN</link> = 'printhello'
-     <link linkend='var-bb-PV'>PV</link> = '1'
-
-     python do_build() {
-        bb.plain("********************");
-        bb.plain("*                  *");
-        bb.plain("*  Hello, World!   *");
-        bb.plain("*                  *");
-        bb.plain("********************");
-     }
-                </literallayout>
-                The recipe file simply provides a description of the
-                recipe, the name, version, and the <filename>do_build</filename>
-                task, which prints out "Hello World" to the console.
-                For more information on these variables, follow the links
-                to the glossary.
-                </para></listitem>
-            <listitem><para><emphasis>Run BitBake With a Target:</emphasis>
-                Now that a BitBake target exists, run the command and provide
-                that target:
-                <literallayout class='monospaced'>
-     $ cd $HOME/hello
-     $ bitbake printhello
-     ERROR: no recipe files to build, check your BBPATH and BBFILES?
-
-     Summary: There was 1 ERROR message shown, returning a non-zero exit code.
-                </literallayout>
-                We have created the layer with the recipe and the layer
-                configuration file but it still seems that BitBake cannot
-                find the recipe.
-                BitBake needs a <filename>conf/bblayers.conf</filename> that
-                lists the layers for the project.
-                Without this file, BitBake cannot find the recipe.
-                </para></listitem>
-            <listitem><para><emphasis>Creating <filename>conf/bblayers.conf</filename>:</emphasis>
-                BitBake uses the <filename>conf/bblayers.conf</filename> file
-                to locate layers needed for the project.
-                This file must reside in the <filename>conf</filename> directory
-                of the project (i.e. <filename>hello/conf</filename> for this
-                example).</para>
-                <para>Set your working directory to the <filename>hello/conf</filename>
-                directory and then create the <filename>bblayers.conf</filename>
-                file so that it contains the following:
-                <literallayout class='monospaced'>
-     BBLAYERS ?= " \
-       /home/&lt;you&gt;/mylayer \
-       "
-                </literallayout>
-                You need to provide your own information for
-                <filename>you</filename> in the file.
-                </para></listitem>
-            <listitem><para><emphasis>Run BitBake With a Target:</emphasis>
-                Now that you have supplied the <filename>bblayers.conf</filename>
-                file, run the <filename>bitbake</filename> command and provide
-                the target:
-                <literallayout class='monospaced'>
-     $ bitbake printhello
-     Parsing recipes: 100% |##################################################################################|
-     Time: 00:00:00
-     Parsing of 1 .bb files complete (0 cached, 1 parsed). 1 targets, 0 skipped, 0 masked, 0 errors.
-     NOTE: Resolving any missing task queue dependencies
-     NOTE: Preparing RunQueue
-     NOTE: Executing RunQueue Tasks
-     ********************
-     *                  *
-     *  Hello, World!   *
-     *                  *
-     ********************
-     NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded.
-                </literallayout>
-                BitBake finds the <filename>printhello</filename> recipe and
-                successfully runs the task.
-                <note>
-                    After the first execution, re-running
-                    <filename>bitbake printhello</filename> again will not
-                    result in a BitBake run that prints the same console
-                    output.
-                    The reason for this is that the first time the
-                    <filename>printhello.bb</filename> recipe's
-                    <filename>do_build</filename> task executes
-                    successfully, BitBake writes a stamp file for the task.
-                    Thus, the next time you attempt to run the task
-                    using that same <filename>bitbake</filename> command,
-                    BitBake notices the stamp and therefore determines
-                    that the task does not need to be re-run.
-                    If you delete the <filename>tmp</filename> directory
-                    or run <filename>bitbake -c clean printhello</filename>
-                    and then re-run the build, the "Hello, World!" message will
-                    be printed again.
-                </note>
-                </para></listitem>
-        </orderedlist>
-    </section>
-</appendix>

bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.rst

@@ -0,0 +1,651 @@
+.. SPDX-License-Identifier: CC-BY-2.5
+
+========
+Overview
+========
+
+|
+
+Welcome to the BitBake User Manual. This manual provides information on
+the BitBake tool. The information attempts to be as independent as
+possible regarding systems that use BitBake, such as OpenEmbedded and
+the Yocto Project. In some cases, scenarios or examples within the
+context of a build system are used in the manual to help with
+understanding. For these cases, the manual clearly states the context.
+
+.. _intro:
+
+Introduction
+============
+
+Fundamentally, BitBake is a generic task execution engine that allows
+shell and Python tasks to be run efficiently and in parallel while
+working within complex inter-task dependency constraints. One of
+BitBake's main users, OpenEmbedded, takes this core and builds embedded
+Linux software stacks using a task-oriented approach.
+
+Conceptually, BitBake is similar to GNU Make in some regards but has
+significant differences:
+
+-  BitBake executes tasks according to provided metadata that builds up
+   the tasks. Metadata is stored in recipe (``.bb``) and related recipe
+   "append" (``.bbappend``) files, configuration (``.conf``) and
+   underlying include (``.inc``) files, and in class (``.bbclass``)
+   files. The metadata provides BitBake with instructions on what tasks
+   to run and the dependencies between those tasks.
+
+-  BitBake includes a fetcher library for obtaining source code from
+   various places such as local files, source control systems, or
+   websites.
+
+-  The instructions for each unit to be built (e.g. a piece of software)
+   are known as "recipe" files and contain all the information about the
+   unit (dependencies, source file locations, checksums, description and
+   so on).
+
+-  BitBake includes a client/server abstraction and can be used from a
+   command line or used as a service over XML-RPC and has several
+   different user interfaces.
+
+History and Goals
+=================
+
+BitBake was originally a part of the OpenEmbedded project. It was
+inspired by the Portage package management system used by the Gentoo
+Linux distribution. On December 7, 2004, OpenEmbedded project team
+member Chris Larson split the project into two distinct pieces:
+
+-  BitBake, a generic task executor
+
+-  OpenEmbedded, a metadata set utilized by BitBake
+
+Today, BitBake is the primary basis of the
+`OpenEmbedded <http://www.openembedded.org/>`__ project, which is being
+used to build and maintain Linux distributions such as the `Angstrom
+Distribution <http://www.angstrom-distribution.org/>`__, and which is
+also being used as the build tool for Linux projects such as the `Yocto
+Project <http://www.yoctoproject.org>`__.
+
+Prior to BitBake, no other build tool adequately met the needs of an
+aspiring embedded Linux distribution. All of the build systems used by
+traditional desktop Linux distributions lacked important functionality,
+and none of the ad hoc Buildroot-based systems, prevalent in the
+embedded space, were scalable or maintainable.
+
+Some important original goals for BitBake were:
+
+-  Handle cross-compilation.
+
+-  Handle inter-package dependencies (build time on target architecture,
+   build time on native architecture, and runtime).
+
+-  Support running any number of tasks within a given package,
+   including, but not limited to, fetching upstream sources, unpacking
+   them, patching them, configuring them, and so forth.
+
+-  Be Linux distribution agnostic for both build and target systems.
+
+-  Be architecture agnostic.
+
+-  Support multiple build and target operating systems (e.g. Cygwin, the
+   BSDs, and so forth).
+
+-  Be self-contained, rather than tightly integrated into the build
+   machine's root filesystem.
+
+-  Handle conditional metadata on the target architecture, operating
+   system, distribution, and machine.
+
+-  Be easy to use the tools to supply local metadata and packages
+   against which to operate.
+
+-  Be easy to use BitBake to collaborate between multiple projects for
+   their builds.
+
+-  Provide an inheritance mechanism to share common metadata between
+   many packages.
+
+Over time it became apparent that some further requirements were
+necessary:
+
+-  Handle variants of a base recipe (e.g. native, sdk, and multilib).
+
+-  Split metadata into layers and allow layers to enhance or override
+   other layers.
+
+-  Allow representation of a given set of input variables to a task as a
+   checksum. Based on that checksum, allow acceleration of builds with
+   prebuilt components.
+
+BitBake satisfies all the original requirements and many more with
+extensions being made to the basic functionality to reflect the
+additional requirements. Flexibility and power have always been the
+priorities. BitBake is highly extensible and supports embedded Python
+code and execution of any arbitrary tasks.
+
+.. _Concepts:
+
+Concepts
+========
+
+BitBake is a program written in the Python language. At the highest
+level, BitBake interprets metadata, decides what tasks are required to
+run, and executes those tasks. Similar to GNU Make, BitBake controls how
+software is built. GNU Make achieves its control through "makefiles",
+while BitBake uses "recipes".
+
+BitBake extends the capabilities of a simple tool like GNU Make by
+allowing for the definition of much more complex tasks, such as
+assembling entire embedded Linux distributions.
+
+The remainder of this section introduces several concepts that should be
+understood in order to better leverage the power of BitBake.
+
+Recipes
+-------
+
+BitBake Recipes, which are denoted by the file extension ``.bb``, are
+the most basic metadata files. These recipe files provide BitBake with
+the following:
+
+-  Descriptive information about the package (author, homepage, license,
+   and so on)
+
+-  The version of the recipe
+
+-  Existing dependencies (both build and runtime dependencies)
+
+-  Where the source code resides and how to fetch it
+
+-  Whether the source code requires any patches, where to find them, and
+   how to apply them
+
+-  How to configure and compile the source code
+
+-  How to assemble the generated artifacts into one or more installable
+   packages
+
+-  Where on the target machine to install the package or packages
+   created
+
+Within the context of BitBake, or any project utilizing BitBake as its
+build system, files with the ``.bb`` extension are referred to as
+recipes.
+
+.. note::
+
+   The term "package" is also commonly used to describe recipes.
+   However, since the same word is used to describe packaged output from
+   a project, it is best to maintain a single descriptive term -
+   "recipes". Put another way, a single "recipe" file is quite capable
+   of generating a number of related but separately installable
+   "packages". In fact, that ability is fairly common.
+
+Configuration Files
+-------------------
+
+Configuration files, which are denoted by the ``.conf`` extension,
+define various configuration variables that govern the project's build
+process. These files fall into several areas that define machine
+configuration, distribution configuration, possible compiler tuning,
+general common configuration, and user configuration. The main
+configuration file is the sample ``bitbake.conf`` file, which is located
+within the BitBake source tree ``conf`` directory.
+
+Classes
+-------
+
+Class files, which are denoted by the ``.bbclass`` extension, contain
+information that is useful to share between metadata files. The BitBake
+source tree currently comes with one class metadata file called
+``base.bbclass``. You can find this file in the ``classes`` directory.
+The ``base.bbclass`` class files is special since it is always included
+automatically for all recipes and classes. This class contains
+definitions for standard basic tasks such as fetching, unpacking,
+configuring (empty by default), compiling (runs any Makefile present),
+installing (empty by default) and packaging (empty by default). These
+tasks are often overridden or extended by other classes added during the
+project development process.
+
+Layers
+------
+
+Layers allow you to isolate different types of customizations from each
+other. While you might find it tempting to keep everything in one layer
+when working on a single project, the more modular your metadata, the
+easier it is to cope with future changes.
+
+To illustrate how you can use layers to keep things modular, consider
+customizations you might make to support a specific target machine.
+These types of customizations typically reside in a special layer,
+rather than a general layer, called a Board Support Package (BSP) layer.
+Furthermore, the machine customizations should be isolated from recipes
+and metadata that support a new GUI environment, for example. This
+situation gives you a couple of layers: one for the machine
+configurations and one for the GUI environment. It is important to
+understand, however, that the BSP layer can still make machine-specific
+additions to recipes within the GUI environment layer without polluting
+the GUI layer itself with those machine-specific changes. You can
+accomplish this through a recipe that is a BitBake append
+(``.bbappend``) file.
+
+.. _append-bbappend-files:
+
+Append Files
+------------
+
+Append files, which are files that have the ``.bbappend`` file
+extension, extend or override information in an existing recipe file.
+
+BitBake expects every append file to have a corresponding recipe file.
+Furthermore, the append file and corresponding recipe file must use the
+same root filename. The filenames can differ only in the file type
+suffix used (e.g. ``formfactor_0.0.bb`` and
+``formfactor_0.0.bbappend``).
+
+Information in append files extends or overrides the information in the
+underlying, similarly-named recipe files.
+
+When you name an append file, you can use the "``%``" wildcard character
+to allow for matching recipe names. For example, suppose you have an
+append file named as follows: ::
+
+  busybox_1.21.%.bbappend
+
+That append file
+would match any ``busybox_1.21.``\ x\ ``.bb`` version of the recipe. So,
+the append file would match the following recipe names: ::
+
+  busybox_1.21.1.bb
+  busybox_1.21.2.bb
+  busybox_1.21.3.bb
+
+.. note::
+
+   The use of the " % " character is limited in that it only works directly in
+   front of the .bbappend portion of the append file's name. You cannot use the
+   wildcard character in any other location of the name.
+
+If the ``busybox`` recipe was updated to ``busybox_1.3.0.bb``, the
+append name would not match. However, if you named the append file
+``busybox_1.%.bbappend``, then you would have a match.
+
+In the most general case, you could name the append file something as
+simple as ``busybox_%.bbappend`` to be entirely version independent.
+
+Obtaining BitBake
+=================
+
+You can obtain BitBake several different ways:
+
+-  **Cloning BitBake:** Using Git to clone the BitBake source code
+   repository is the recommended method for obtaining BitBake. Cloning
+   the repository makes it easy to get bug fixes and have access to
+   stable branches and the master branch. Once you have cloned BitBake,
+   you should use the latest stable branch for development since the
+   master branch is for BitBake development and might contain less
+   stable changes.
+
+   You usually need a version of BitBake that matches the metadata you
+   are using. The metadata is generally backwards compatible but not
+   forward compatible.
+
+   Here is an example that clones the BitBake repository: ::
+
+     $ git clone git://git.openembedded.org/bitbake
+
+   This command clones the BitBake
+   Git repository into a directory called ``bitbake``. Alternatively,
+   you can designate a directory after the ``git clone`` command if you
+   want to call the new directory something other than ``bitbake``. Here
+   is an example that names the directory ``bbdev``: ::
+
+     $ git clone git://git.openembedded.org/bitbake bbdev
+
+-  **Installation using your Distribution Package Management System:**
+   This method is not recommended because the BitBake version that is
+   provided by your distribution, in most cases, is several releases
+   behind a snapshot of the BitBake repository.
+
+-  **Taking a snapshot of BitBake:** Downloading a snapshot of BitBake
+   from the source code repository gives you access to a known branch or
+   release of BitBake.
+
+      .. note::
+
+         Cloning the Git repository, as described earlier, is the preferred
+         method for getting BitBake. Cloning the repository makes it easier
+         to update as patches are added to the stable branches.
+
+   The following example downloads a snapshot of BitBake version 1.17.0: ::
+
+     $ wget http://git.openembedded.org/bitbake/snapshot/bitbake-1.17.0.tar.gz
+     $ tar zxpvf bitbake-1.17.0.tar.gz
+
+   After extraction of the tarball using
+   the tar utility, you have a directory entitled ``bitbake-1.17.0``.
+
+-  **Using the BitBake that Comes With Your Build Checkout:** A final
+   possibility for getting a copy of BitBake is that it already comes
+   with your checkout of a larger BitBake-based build system, such as
+   Poky. Rather than manually checking out individual layers and gluing
+   them together yourself, you can check out an entire build system. The
+   checkout will already include a version of BitBake that has been
+   thoroughly tested for compatibility with the other components. For
+   information on how to check out a particular BitBake-based build
+   system, consult that build system's supporting documentation.
+
+.. _bitbake-user-manual-command:
+
+The BitBake Command
+===================
+
+The ``bitbake`` command is the primary interface to the BitBake tool.
+This section presents the BitBake command syntax and provides several
+execution examples.
+
+Usage and syntax
+----------------
+
+Following is the usage and syntax for BitBake: ::
+
+   $ bitbake -h
+   Usage: bitbake [options] [recipename/target recipe:do_task ...]
+
+       Executes the specified task (default is 'build') for a given set of target recipes (.bb files).
+       It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which
+       will provide the layer, BBFILES and other configuration information.
+
+   Options:
+     --version             show program's version number and exit
+     -h, --help            show this help message and exit
+     -b BUILDFILE, --buildfile=BUILDFILE
+                           Execute tasks from a specific .bb recipe directly.
+                           WARNING: Does not handle any dependencies from other
+                           recipes.
+     -k, --continue        Continue as much as possible after an error. While the
+                           target that failed and anything depending on it cannot
+                           be built, as much as possible will be built before
+                           stopping.
+     -f, --force           Force the specified targets/task to run (invalidating
+                           any existing stamp file).
+     -c CMD, --cmd=CMD     Specify the task to execute. The exact options
+                           available depend on the metadata. Some examples might
+                           be 'compile' or 'populate_sysroot' or 'listtasks' may
+                           give a list of the tasks available.
+     -C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP
+                           Invalidate the stamp for the specified task such as
+                           'compile' and then run the default task for the
+                           specified target(s).
+     -r PREFILE, --read=PREFILE
+                           Read the specified file before bitbake.conf.
+     -R POSTFILE, --postread=POSTFILE
+                           Read the specified file after bitbake.conf.
+     -v, --verbose         Enable tracing of shell tasks (with 'set -x'). Also
+                           print bb.note(...) messages to stdout (in addition to
+                           writing them to ${T}/log.do_&lt;task&gt;).
+     -D, --debug           Increase the debug level. You can specify this more
+                           than once. -D sets the debug level to 1, where only
+                           bb.debug(1, ...) messages are printed to stdout; -DD
+                           sets the debug level to 2, where both bb.debug(1, ...)
+                           and bb.debug(2, ...) messages are printed; etc.
+                           Without -D, no debug messages are printed. Note that
+                           -D only affects output to stdout. All debug messages
+                           are written to ${T}/log.do_taskname, regardless of the
+                           debug level.
+     -q, --quiet           Output less log message data to the terminal. You can
+                           specify this more than once.
+     -n, --dry-run         Don't execute, just go through the motions.
+     -S SIGNATURE_HANDLER, --dump-signatures=SIGNATURE_HANDLER
+                           Dump out the signature construction information, with
+                           no task execution. The SIGNATURE_HANDLER parameter is
+                           passed to the handler. Two common values are none and
+                           printdiff but the handler may define more/less. none
+                           means only dump the signature, printdiff means compare
+                           the dumped signature with the cached one.
+     -p, --parse-only      Quit after parsing the BB recipes.
+     -s, --show-versions   Show current and preferred versions of all recipes.
+     -e, --environment     Show the global or per-recipe environment complete
+                           with information about where variables were
+                           set/changed.
+     -g, --graphviz        Save dependency tree information for the specified
+                           targets in the dot syntax.
+     -I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED
+                           Assume these dependencies don't exist and are already
+                           provided (equivalent to ASSUME_PROVIDED). Useful to
+                           make dependency graphs more appealing
+     -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
+                           Show debug logging for the specified logging domains
+     -P, --profile         Profile the command and save reports.
+     -u UI, --ui=UI        The user interface to use (knotty, ncurses or taskexp
+                           - default knotty).
+     --token=XMLRPCTOKEN   Specify the connection token to be used when
+                           connecting to a remote server.
+     --revisions-changed   Set the exit code depending on whether upstream
+                           floating revisions have changed or not.
+     --server-only         Run bitbake without a UI, only starting a server
+                           (cooker) process.
+     -B BIND, --bind=BIND  The name/address for the bitbake xmlrpc server to bind
+                           to.
+     -T SERVER_TIMEOUT, --idle-timeout=SERVER_TIMEOUT
+                           Set timeout to unload bitbake server due to
+                           inactivity, set to -1 means no unload, default:
+                           Environment variable BB_SERVER_TIMEOUT.
+     --no-setscene         Do not run any setscene tasks. sstate will be ignored
+                           and everything needed, built.
+     --setscene-only       Only run setscene tasks, don't run any real tasks.
+     --remote-server=REMOTE_SERVER
+                           Connect to the specified server.
+     -m, --kill-server     Terminate any running bitbake server.
+     --observe-only        Connect to a server as an observing-only client.
+     --status-only         Check the status of the remote bitbake server.
+     -w WRITEEVENTLOG, --write-log=WRITEEVENTLOG
+                           Writes the event log of the build to a bitbake event
+                           json file. Use '' (empty string) to assign the name
+                           automatically.
+     --runall=RUNALL       Run the specified task for any recipe in the taskgraph
+                           of the specified target (even if it wouldn't otherwise
+                           have run).
+     --runonly=RUNONLY     Run only the specified task within the taskgraph of
+                           the specified targets (and any task dependencies those
+                           tasks may have).
+
+.. _bitbake-examples:
+
+Examples
+--------
+
+This section presents some examples showing how to use BitBake.
+
+.. _example-executing-a-task-against-a-single-recipe:
+
+Executing a Task Against a Single Recipe
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Executing tasks for a single recipe file is relatively simple. You
+specify the file in question, and BitBake parses it and executes the
+specified task. If you do not specify a task, BitBake executes the
+default task, which is "build". BitBake obeys inter-task dependencies
+when doing so.
+
+The following command runs the build task, which is the default task, on
+the ``foo_1.0.bb`` recipe file: ::
+
+  $ bitbake -b foo_1.0.bb
+
+The following command runs the clean task on the ``foo.bb`` recipe file: ::
+
+  $ bitbake -b foo.bb -c clean
+
+.. note::
+
+   The "-b" option explicitly does not handle recipe dependencies. Other
+   than for debugging purposes, it is instead recommended that you use
+   the syntax presented in the next section.
+
+Executing Tasks Against a Set of Recipe Files
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There are a number of additional complexities introduced when one wants
+to manage multiple ``.bb`` files. Clearly there needs to be a way to
+tell BitBake what files are available and, of those, which you want to
+execute. There also needs to be a way for each recipe to express its
+dependencies, both for build-time and runtime. There must be a way for
+you to express recipe preferences when multiple recipes provide the same
+functionality, or when there are multiple versions of a recipe.
+
+The ``bitbake`` command, when not using "--buildfile" or "-b" only
+accepts a "PROVIDES". You cannot provide anything else. By default, a
+recipe file generally "PROVIDES" its "packagename" as shown in the
+following example: ::
+
+  $ bitbake foo
+
+This next example "PROVIDES" the
+package name and also uses the "-c" option to tell BitBake to just
+execute the ``do_clean`` task: ::
+
+  $ bitbake -c clean foo
+
+Executing a List of Task and Recipe Combinations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The BitBake command line supports specifying different tasks for
+individual targets when you specify multiple targets. For example,
+suppose you had two targets (or recipes) ``myfirstrecipe`` and
+``mysecondrecipe`` and you needed BitBake to run ``taskA`` for the first
+recipe and ``taskB`` for the second recipe: ::
+
+  $ bitbake myfirstrecipe:do_taskA mysecondrecipe:do_taskB
+
+Generating Dependency Graphs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+BitBake is able to generate dependency graphs using the ``dot`` syntax.
+You can convert these graphs into images using the ``dot`` tool from
+`Graphviz <http://www.graphviz.org>`__.
+
+When you generate a dependency graph, BitBake writes two files to the
+current working directory:
+
+-  ``task-depends.dot``: Shows dependencies between tasks. These
+   dependencies match BitBake's internal task execution list.
+
+-  ``pn-buildlist``: Shows a simple list of targets that are to be
+   built.
+
+To stop depending on common depends, use the "-I" depend option and
+BitBake omits them from the graph. Leaving this information out can
+produce more readable graphs. This way, you can remove from the graph
+``DEPENDS`` from inherited classes such as ``base.bbclass``.
+
+Here are two examples that create dependency graphs. The second example
+omits depends common in OpenEmbedded from the graph: ::
+
+  $ bitbake -g foo
+
+  $ bitbake -g -I virtual/kernel -I eglibc foo
+
+Executing a Multiple Configuration Build
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+BitBake is able to build multiple images or packages using a single
+command where the different targets require different configurations
+(multiple configuration builds). Each target, in this scenario, is
+referred to as a "multiconfig".
+
+To accomplish a multiple configuration build, you must define each
+target's configuration separately using a parallel configuration file in
+the build directory. The location for these multiconfig configuration
+files is specific. They must reside in the current build directory in a
+sub-directory of ``conf`` named ``multiconfig``. Following is an example
+for two separate targets:
+
+.. image:: figures/bb_multiconfig_files.png
+   :align: center
+
+The reason for this required file hierarchy is because the ``BBPATH``
+variable is not constructed until the layers are parsed. Consequently,
+using the configuration file as a pre-configuration file is not possible
+unless it is located in the current working directory.
+
+Minimally, each configuration file must define the machine and the
+temporary directory BitBake uses for the build. Suggested practice
+dictates that you do not overlap the temporary directories used during
+the builds.
+
+Aside from separate configuration files for each target, you must also
+enable BitBake to perform multiple configuration builds. Enabling is
+accomplished by setting the
+:term:`BBMULTICONFIG` variable in the
+``local.conf`` configuration file. As an example, suppose you had
+configuration files for ``target1`` and ``target2`` defined in the build
+directory. The following statement in the ``local.conf`` file both
+enables BitBake to perform multiple configuration builds and specifies
+the two extra multiconfigs: ::
+
+  BBMULTICONFIG = "target1 target2"
+
+Once the target configuration files are in place and BitBake has been
+enabled to perform multiple configuration builds, use the following
+command form to start the builds: ::
+
+  $ bitbake [mc:multiconfigname:]target [[[mc:multiconfigname:]target] ... ]
+
+Here is an example for two extra multiconfigs: ``target1`` and ``target2``: ::
+
+  $ bitbake mc::target mc:target1:target mc:target2:target
+
+.. _bb-enabling-multiple-configuration-build-dependencies:
+
+Enabling Multiple Configuration Build Dependencies
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sometimes dependencies can exist between targets (multiconfigs) in a
+multiple configuration build. For example, suppose that in order to
+build an image for a particular architecture, the root filesystem of
+another build for a different architecture needs to exist. In other
+words, the image for the first multiconfig depends on the root
+filesystem of the second multiconfig. This dependency is essentially
+that the task in the recipe that builds one multiconfig is dependent on
+the completion of the task in the recipe that builds another
+multiconfig.
+
+To enable dependencies in a multiple configuration build, you must
+declare the dependencies in the recipe using the following statement
+form: ::
+
+  task_or_package[mcdepends] = "mc:from_multiconfig:to_multiconfig:recipe_name:task_on_which_to_depend"
+
+To better show how to use this statement, consider an example with two
+multiconfigs: ``target1`` and ``target2``: ::
+
+  image_task[mcdepends] = "mc:target1:target2:image2:rootfs_task"
+
+In this example, the
+``from_multiconfig`` is "target1" and the ``to_multiconfig`` is "target2". The
+task on which the image whose recipe contains image_task depends on the
+completion of the rootfs_task used to build out image2, which is
+associated with the "target2" multiconfig.
+
+Once you set up this dependency, you can build the "target1" multiconfig
+using a BitBake command as follows: ::
+
+  $ bitbake mc:target1:image1
+
+This command executes all the tasks needed to create ``image1`` for the "target1"
+multiconfig. Because of the dependency, BitBake also executes through
+the ``rootfs_task`` for the "target2" multiconfig build.
+
+Having a recipe depend on the root filesystem of another build might not
+seem that useful. Consider this change to the statement in the image1
+recipe: ::
+
+  image_task[mcdepends] = "mc:target1:target2:image2:image_task"
+
+In this case, BitBake must create ``image2`` for the "target2" build since
+the "target1" build depends on it.
+
+Because "target1" and "target2" are enabled for multiple configuration
+builds and have separate configuration files, BitBake places the
+artifacts for each build in the respective temporary build directories.

bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.xml

@@ -1,891 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-    "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<chapter id="bitbake-user-manual-intro">
-    <title>Overview</title>
-
-    <para>
-        Welcome to the BitBake User Manual.
-        This manual provides information on the BitBake tool.
-        The information attempts to be as independent as possible regarding
-        systems that use BitBake, such as OpenEmbedded and the
-        Yocto Project.
-        In some cases, scenarios or examples within the context of
-        a build system are used in the manual to help with understanding.
-        For these cases, the manual clearly states the context.
-    </para>
-
-    <section id="intro">
-        <title>Introduction</title>
-
-        <para>
-            Fundamentally, BitBake is a generic task execution
-            engine that allows shell and Python tasks to be run
-            efficiently and in parallel while working within
-            complex inter-task dependency constraints.
-            One of BitBake's main users, OpenEmbedded, takes this core
-            and builds embedded Linux software stacks using
-            a task-oriented approach.
-        </para>
-
-        <para>
-            Conceptually, BitBake is similar to GNU Make in
-            some regards but has significant differences:
-            <itemizedlist>
-                <listitem><para>
-                    BitBake executes tasks according to provided
-                    metadata that builds up the tasks.
-                    Metadata is stored in recipe (<filename>.bb</filename>)
-                    and related recipe "append" (<filename>.bbappend</filename>)
-                    files, configuration (<filename>.conf</filename>) and
-                    underlying include (<filename>.inc</filename>) files, and
-                    in class (<filename>.bbclass</filename>) files.
-                    The metadata provides
-                    BitBake with instructions on what tasks to run and
-                    the dependencies between those tasks.
-                    </para></listitem>
-                <listitem><para>
-                    BitBake includes a fetcher library for obtaining source
-                    code from various places such as local files, source control
-                    systems, or websites.
-                    </para></listitem>
-                <listitem><para>
-                    The instructions for each unit to be built (e.g. a piece
-                    of software) are known as "recipe" files and
-                    contain all the information about the unit
-                    (dependencies, source file locations, checksums, description
-                    and so on).
-                    </para></listitem>
-                <listitem><para>
-                    BitBake includes a client/server abstraction and can
-                    be used from a command line or used as a service over
-                    XML-RPC and has several different user interfaces.
-                    </para></listitem>
-            </itemizedlist>
-        </para>
-    </section>
-
-    <section id="history-and-goals">
-        <title>History and Goals</title>
-
-        <para>
-            BitBake was originally a part of the OpenEmbedded project.
-            It was inspired by the Portage package management system
-            used by the Gentoo Linux distribution.
-            On December 7, 2004, OpenEmbedded project team member
-            Chris Larson split the project into two distinct pieces:
-            <itemizedlist>
-                <listitem><para>BitBake, a generic task executor</para></listitem>
-                <listitem><para>OpenEmbedded, a metadata set utilized by
-                    BitBake</para></listitem>
-            </itemizedlist>
-            Today, BitBake is the primary basis of the
-            <ulink url="http://www.openembedded.org/">OpenEmbedded</ulink>
-            project, which is being used to build and maintain Linux
-            distributions such as the
-            <ulink url='http://www.angstrom-distribution.org/'>Angstrom Distribution</ulink>,
-            and which is also being used as the build tool for Linux projects
-            such as the
-            <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink>.
-        </para>
-
-        <para>
-            Prior to BitBake, no other build tool adequately met the needs of
-            an aspiring embedded Linux distribution.
-            All of the build systems used by traditional desktop Linux
-            distributions lacked important functionality, and none of the
-            ad hoc Buildroot-based systems, prevalent in the
-            embedded space, were scalable or maintainable.
-        </para>
-
-        <para>
-            Some important original goals for BitBake were:
-            <itemizedlist>
-                <listitem><para>
-                    Handle cross-compilation.
-                    </para></listitem>
-                <listitem><para>
-                    Handle inter-package dependencies (build time on
-                    target architecture, build time on native
-                    architecture, and runtime).
-                    </para></listitem>
-                <listitem><para>
-                    Support running any number of tasks within a given
-                    package, including, but not limited to, fetching
-                    upstream sources, unpacking them, patching them,
-                    configuring them, and so forth.
-                    </para></listitem>
-                <listitem><para>
-                    Be Linux distribution agnostic for both build and
-                    target systems.
-                    </para></listitem>
-                <listitem><para>
-                    Be architecture agnostic.
-                    </para></listitem>
-                <listitem><para>
-                    Support multiple build and target operating systems
-                    (e.g. Cygwin, the BSDs, and so forth).
-                    </para></listitem>
-                <listitem><para>
-                    Be self-contained, rather than tightly
-                    integrated into the build machine's root
-                    filesystem.
-                    </para></listitem>
-                <listitem><para>
-                    Handle conditional metadata on the target architecture,
-                    operating system, distribution, and machine.
-                    </para></listitem>
-                <listitem><para>
-                    Be easy to use the tools to supply local metadata and packages
-                    against which to operate.
-                    </para></listitem>
-                <listitem><para>
-                    Be easy to use BitBake to collaborate between multiple
-                    projects for their builds.
-                    </para></listitem>
-                <listitem><para>
-                    Provide an inheritance mechanism to share
-                    common metadata between many packages.
-                    </para></listitem>
-            </itemizedlist>
-            Over time it became apparent that some further requirements
-            were necessary:
-            <itemizedlist>
-                <listitem><para>
-                    Handle variants of a base recipe (e.g. native, sdk,
-                    and multilib).
-                    </para></listitem>
-                <listitem><para>
-                    Split metadata into layers and allow layers
-                    to enhance or override other layers.
-                    </para></listitem>
-                <listitem><para>
-                    Allow representation of a given set of input variables
-                    to a task as a checksum.
-                    Based on that checksum, allow acceleration of builds
-                    with prebuilt components.
-                    </para></listitem>
-            </itemizedlist>
-            BitBake satisfies all the original requirements and many more
-            with extensions being made to the basic functionality to
-            reflect the additional requirements.
-            Flexibility and power have always been the priorities.
-            BitBake is highly extensible and supports embedded Python code and
-            execution of any arbitrary tasks.
-        </para>
-    </section>
-
-    <section id="Concepts">
-        <title>Concepts</title>
-
-        <para>
-            BitBake is a program written in the Python language.
-            At the highest level, BitBake interprets metadata, decides
-            what tasks are required to run, and executes those tasks.
-            Similar to GNU Make, BitBake controls how software is
-            built.
-            GNU Make achieves its control through "makefiles", while
-            BitBake uses "recipes".
-        </para>
-
-        <para>
-            BitBake extends the capabilities of a simple
-            tool like GNU Make by allowing for the definition of much more
-            complex tasks, such as assembling entire embedded Linux
-            distributions.
-        </para>
-
-        <para>
-            The remainder of this section introduces several concepts
-            that should be understood in order to better leverage
-            the power of BitBake.
-        </para>
-
-        <section id='recipes'>
-            <title>Recipes</title>
-
-            <para>
-                BitBake Recipes, which are denoted by the file extension
-                <filename>.bb</filename>, are the most basic metadata files.
-                These recipe files provide BitBake with the following:
-                <itemizedlist>
-                    <listitem><para>Descriptive information about the
-                        package (author, homepage, license, and so on)</para></listitem>
-                    <listitem><para>The version of the recipe</para></listitem>
-                    <listitem><para>Existing dependencies (both build
-                        and runtime dependencies)</para></listitem>
-                    <listitem><para>Where the source code resides and
-                        how to fetch it</para></listitem>
-                    <listitem><para>Whether the source code requires
-                        any patches, where to find them, and how to apply
-                        them</para></listitem>
-                    <listitem><para>How to configure and compile the
-                        source code</para></listitem>
-                    <listitem><para>How to assemble the generated artifacts into
-                        one or more installable packages</para></listitem>
-                    <listitem><para>Where on the target machine to install the
-                        package or packages created</para></listitem>
-                </itemizedlist>
-            </para>
-
-            <para>
-                Within the context of BitBake, or any project utilizing BitBake
-                as its build system, files with the <filename>.bb</filename>
-                extension are referred to as <firstterm>recipes</firstterm>.
-                <note>
-                    The term "package" is also commonly used to describe recipes.
-                    However, since the same word is used to describe packaged
-                    output from a project, it is best to maintain a single
-                    descriptive term - "recipes".
-                    Put another way, a single "recipe" file is quite capable
-                    of generating a number of related but separately installable
-                    "packages".
-                    In fact, that ability is fairly common.
-                </note>
-            </para>
-        </section>
-
-        <section id='configuration-files'>
-            <title>Configuration Files</title>
-
-            <para>
-                Configuration files, which are denoted by the
-                <filename>.conf</filename> extension, define
-                various configuration variables that govern the project's build
-                process.
-                These files fall into several areas that define
-                machine configuration, distribution configuration,
-                possible compiler tuning, general common
-                configuration, and user configuration.
-                The main configuration file is the sample
-                <filename>bitbake.conf</filename> file, which is
-                located within the BitBake source tree
-                <filename>conf</filename> directory.
-            </para>
-        </section>
-
-        <section id='classes'>
-            <title>Classes</title>
-
-            <para>
-                Class files, which are denoted by the
-                <filename>.bbclass</filename> extension, contain
-                information that is useful to share between metadata files.
-                The BitBake source tree currently comes with one class metadata file
-                called <filename>base.bbclass</filename>.
-                You can find this file in the
-                <filename>classes</filename> directory.
-                The <filename>base.bbclass</filename> class files is special since it
-                is always included automatically for all recipes
-                and classes.
-                This class contains definitions for standard basic tasks such
-                as fetching, unpacking, configuring (empty by default),
-                compiling (runs any Makefile present), installing (empty by
-                default) and packaging (empty by default).
-                These tasks are often overridden or extended by other classes
-                added during the project development process.
-            </para>
-        </section>
-
-        <section id='layers'>
-            <title>Layers</title>
-
-            <para>
-                Layers allow you to isolate different types of
-                customizations from each other.
-                While you might find it tempting to keep everything in one layer
-                when working on a single project, the more modular
-                your metadata, the easier it is to cope with future changes.
-            </para>
-
-            <para>
-                To illustrate how you can use layers to keep things modular,
-                consider customizations you might make to support a specific target machine.
-                These types of customizations typically reside in a special layer,
-                rather than a general layer, called a <firstterm>Board Support Package</firstterm> (BSP)
-                layer.
-                Furthermore, the machine customizations should be isolated from
-                recipes and metadata that support a new GUI environment, for
-                example.
-                This situation gives you a couple of layers: one for the machine
-                configurations and one for the GUI environment.
-                It is important to understand, however, that the BSP layer can still
-                make machine-specific additions to recipes within
-                the GUI environment layer without polluting the GUI layer itself
-                with those machine-specific changes.
-                You can accomplish this through a recipe that is a BitBake append
-                (<filename>.bbappend</filename>) file.
-            </para>
-        </section>
-
-        <section id='append-bbappend-files'>
-            <title>Append Files</title>
-
-            <para>
-                Append files, which are files that have the
-                <filename>.bbappend</filename> file extension, extend or
-                override information in an existing recipe file.
-            </para>
-
-            <para>
-                BitBake expects every append file to have a corresponding recipe file.
-                Furthermore, the append file and corresponding recipe file
-                must use the same root filename.
-                The filenames can differ only in the file type suffix used
-                (e.g. <filename>formfactor_0.0.bb</filename> and
-                <filename>formfactor_0.0.bbappend</filename>).
-            </para>
-
-            <para>
-                Information in append files extends or
-                overrides the information in the underlying,
-                similarly-named recipe files.
-            </para>
-
-            <para>
-                When you name an append file, you can use the
-                "<filename>%</filename>" wildcard character to allow for matching
-                recipe names.
-                For example, suppose you have an append file named
-                as follows:
-                <literallayout class='monospaced'>
-     busybox_1.21.%.bbappend
-                </literallayout>
-                That append file would match any <filename>busybox_1.21.</filename><replaceable>x</replaceable><filename>.bb</filename>
-                version of the recipe.
-                So, the append file would match the following recipe names:
-                <literallayout class='monospaced'>
-     busybox_1.21.1.bb
-     busybox_1.21.2.bb
-     busybox_1.21.3.bb
-                </literallayout>
-                <note><title>Important</title>
-                    The use of the "<filename>%</filename>" character
-                    is limited in that it only works directly in front of the
-                    <filename>.bbappend</filename> portion of the append file's
-                    name.
-                    You cannot use the wildcard character in any other
-                    location of the name.
-                </note>
-                If the <filename>busybox</filename> recipe was updated to
-                <filename>busybox_1.3.0.bb</filename>, the append name would not
-                match.
-                However, if you named the append file
-                <filename>busybox_1.%.bbappend</filename>, then you would have a match.
-            </para>
-
-            <para>
-                In the most general case, you could name the append file something as
-                simple as <filename>busybox_%.bbappend</filename> to be entirely
-                version independent.
-            </para>
-        </section>
-    </section>
-
-    <section id='obtaining-bitbake'>
-        <title>Obtaining BitBake</title>
-
-        <para>
-            You can obtain BitBake several different ways:
-            <itemizedlist>
-                <listitem><para><emphasis>Cloning BitBake:</emphasis>
-                    Using Git to clone the BitBake source code repository
-                    is the recommended method for obtaining BitBake.
-                    Cloning the repository makes it easy to get bug fixes
-                    and have access to stable branches and the master
-                    branch.
-                    Once you have cloned BitBake, you should use
-                    the latest stable
-                    branch for development since the master branch is for
-                    BitBake development and might contain less stable changes.
-                    </para>
-                    <para>You usually need a version of BitBake
-                    that matches the metadata you are using.
-                    The metadata is generally backwards compatible but
-                    not forward compatible.</para>
-                    <para>Here is an example that clones the BitBake repository:
-                    <literallayout class='monospaced'>
-     $ git clone git://git.openembedded.org/bitbake
-                    </literallayout>
-                    This command clones the BitBake Git repository into a
-                    directory called <filename>bitbake</filename>.
-                    Alternatively, you can
-                    designate a directory after the
-                    <filename>git clone</filename> command
-                    if you want to call the new directory something
-                    other than <filename>bitbake</filename>.
-                    Here is an example that names the directory
-                    <filename>bbdev</filename>:
-                    <literallayout class='monospaced'>
-     $ git clone git://git.openembedded.org/bitbake bbdev
-                    </literallayout></para></listitem>
-                <listitem><para><emphasis>Installation using your Distribution
-                    Package Management System:</emphasis>
-                    This method is not
-                    recommended because the BitBake version that is
-                    provided by your distribution, in most cases,
-                    is several
-                    releases behind a snapshot of the BitBake repository.
-                    </para></listitem>
-                <listitem><para><emphasis>Taking a snapshot of BitBake:</emphasis>
-                    Downloading a snapshot of BitBake from the
-                    source code repository gives you access to a known
-                    branch or release of BitBake.
-                    <note>
-                         Cloning the Git repository, as described earlier,
-                         is the preferred method for getting BitBake.
-                         Cloning the repository makes it easier to update as
-                         patches are added to the stable branches.
-                    </note></para>
-                    <para>The following example downloads a snapshot of
-                    BitBake version 1.17.0:
-                    <literallayout class='monospaced'>
-     $ wget http://git.openembedded.org/bitbake/snapshot/bitbake-1.17.0.tar.gz
-     $ tar zxpvf bitbake-1.17.0.tar.gz
-                    </literallayout>
-                    After extraction of the tarball using the tar utility,
-                    you have a directory entitled
-                    <filename>bitbake-1.17.0</filename>.
-                    </para></listitem>
-                <listitem><para><emphasis>Using the BitBake that Comes With Your
-                    Build Checkout:</emphasis>
-                    A final possibility for getting a copy of BitBake is that it
-                    already comes with your checkout of a larger BitBake-based build
-                    system, such as Poky.
-                    Rather than manually checking out individual layers and
-                    gluing them together yourself, you can check
-                    out an entire build system.
-                    The checkout will already include a version of BitBake that
-                    has been thoroughly tested for compatibility with the other
-                    components.
-                    For information on how to check out a particular BitBake-based
-                    build system, consult that build system's supporting documentation.
-                    </para></listitem>
-            </itemizedlist>
-        </para>
-    </section>
-
-    <section id="bitbake-user-manual-command">
-        <title>The BitBake Command</title>
-
-        <para>
-            The <filename>bitbake</filename> command is the primary interface
-            to the BitBake tool.
-            This section presents the BitBake command syntax and provides
-            several execution examples.
-        </para>
-
-        <section id='usage-and-syntax'>
-            <title>Usage and syntax</title>
-
-            <para>
-                Following is the usage and syntax for BitBake:
-                <literallayout class='monospaced'>
-     $ bitbake -h
-     Usage: bitbake [options] [recipename/target recipe:do_task ...]
-
-         Executes the specified task (default is 'build') for a given set of target recipes (.bb files).
-         It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which
-         will provide the layer, BBFILES and other configuration information.
-
-     Options:
-       --version             show program's version number and exit
-       -h, --help            show this help message and exit
-       -b BUILDFILE, --buildfile=BUILDFILE
-                             Execute tasks from a specific .bb recipe directly.
-                             WARNING: Does not handle any dependencies from other
-                             recipes.
-       -k, --continue        Continue as much as possible after an error. While the
-                             target that failed and anything depending on it cannot
-                             be built, as much as possible will be built before
-                             stopping.
-       -f, --force           Force the specified targets/task to run (invalidating
-                             any existing stamp file).
-       -c CMD, --cmd=CMD     Specify the task to execute. The exact options
-                             available depend on the metadata. Some examples might
-                             be 'compile' or 'populate_sysroot' or 'listtasks' may
-                             give a list of the tasks available.
-       -C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP
-                             Invalidate the stamp for the specified task such as
-                             'compile' and then run the default task for the
-                             specified target(s).
-       -r PREFILE, --read=PREFILE
-                             Read the specified file before bitbake.conf.
-       -R POSTFILE, --postread=POSTFILE
-                             Read the specified file after bitbake.conf.
-       -v, --verbose         Enable tracing of shell tasks (with 'set -x'). Also
-                             print bb.note(...) messages to stdout (in addition to
-                             writing them to ${T}/log.do_&lt;task&gt;).
-       -D, --debug           Increase the debug level. You can specify this more
-                             than once. -D sets the debug level to 1, where only
-                             bb.debug(1, ...) messages are printed to stdout; -DD
-                             sets the debug level to 2, where both bb.debug(1, ...)
-                             and bb.debug(2, ...) messages are printed; etc.
-                             Without -D, no debug messages are printed. Note that
-                             -D only affects output to stdout. All debug messages
-                             are written to ${T}/log.do_taskname, regardless of the
-                             debug level.
-       -q, --quiet           Output less log message data to the terminal. You can
-                             specify this more than once.
-       -n, --dry-run         Don't execute, just go through the motions.
-       -S SIGNATURE_HANDLER, --dump-signatures=SIGNATURE_HANDLER
-                             Dump out the signature construction information, with
-                             no task execution. The SIGNATURE_HANDLER parameter is
-                             passed to the handler. Two common values are none and
-                             printdiff but the handler may define more/less. none
-                             means only dump the signature, printdiff means compare
-                             the dumped signature with the cached one.
-       -p, --parse-only      Quit after parsing the BB recipes.
-       -s, --show-versions   Show current and preferred versions of all recipes.
-       -e, --environment     Show the global or per-recipe environment complete
-                             with information about where variables were
-                             set/changed.
-       -g, --graphviz        Save dependency tree information for the specified
-                             targets in the dot syntax.
-       -I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED
-                             Assume these dependencies don't exist and are already
-                             provided (equivalent to ASSUME_PROVIDED). Useful to
-                             make dependency graphs more appealing
-       -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
-                             Show debug logging for the specified logging domains
-       -P, --profile         Profile the command and save reports.
-       -u UI, --ui=UI        The user interface to use (knotty, ncurses or taskexp
-                             - default knotty).
-       --token=XMLRPCTOKEN   Specify the connection token to be used when
-                             connecting to a remote server.
-       --revisions-changed   Set the exit code depending on whether upstream
-                             floating revisions have changed or not.
-       --server-only         Run bitbake without a UI, only starting a server
-                             (cooker) process.
-       -B BIND, --bind=BIND  The name/address for the bitbake xmlrpc server to bind
-                             to.
-       -T SERVER_TIMEOUT, --idle-timeout=SERVER_TIMEOUT
-                             Set timeout to unload bitbake server due to
-                             inactivity, set to -1 means no unload, default:
-                             Environment variable BB_SERVER_TIMEOUT.
-       --no-setscene         Do not run any setscene tasks. sstate will be ignored
-                             and everything needed, built.
-       --setscene-only       Only run setscene tasks, don't run any real tasks.
-       --remote-server=REMOTE_SERVER
-                             Connect to the specified server.
-       -m, --kill-server     Terminate any running bitbake server.
-       --observe-only        Connect to a server as an observing-only client.
-       --status-only         Check the status of the remote bitbake server.
-       -w WRITEEVENTLOG, --write-log=WRITEEVENTLOG
-                             Writes the event log of the build to a bitbake event
-                             json file. Use '' (empty string) to assign the name
-                             automatically.
-       --runall=RUNALL       Run the specified task for any recipe in the taskgraph
-                             of the specified target (even if it wouldn't otherwise
-                             have run).
-       --runonly=RUNONLY     Run only the specified task within the taskgraph of
-                             the specified targets (and any task dependencies those
-                             tasks may have).
-                </literallayout>
-            </para>
-        </section>
-
-        <section id='bitbake-examples'>
-            <title>Examples</title>
-
-            <para>
-                This section presents some examples showing how to use BitBake.
-            </para>
-
-            <section id='example-executing-a-task-against-a-single-recipe'>
-                <title>Executing a Task Against a Single Recipe</title>
-
-                <para>
-                    Executing tasks for a single recipe file is relatively simple.
-                    You specify the file in question, and BitBake parses
-                    it and executes the specified task.
-                    If you do not specify a task, BitBake executes the default
-                    task, which is "build”.
-                    BitBake obeys inter-task dependencies when doing
-                    so.
-                </para>
-
-                <para>
-                    The following command runs the build task, which is
-                    the default task, on the <filename>foo_1.0.bb</filename>
-                    recipe file:
-                    <literallayout class='monospaced'>
-     $ bitbake -b foo_1.0.bb
-                    </literallayout>
-                    The following command runs the clean task on the
-                    <filename>foo.bb</filename> recipe file:
-                    <literallayout class='monospaced'>
-     $ bitbake -b foo.bb -c clean
-                    </literallayout>
-                    <note>
-                        The "-b" option explicitly does not handle recipe
-                        dependencies.
-                        Other than for debugging purposes, it is instead
-                        recommended that you use the syntax presented in the
-                        next section.
-                    </note>
-                </para>
-            </section>
-
-            <section id='executing-tasks-against-a-set-of-recipe-files'>
-                <title>Executing Tasks Against a Set of Recipe Files</title>
-
-                <para>
-                    There are a number of additional complexities introduced
-                    when one wants to manage multiple <filename>.bb</filename>
-                    files.
-                    Clearly there needs to be a way to tell BitBake what
-                    files are available and, of those, which you
-                    want to execute.
-                    There also needs to be a way for each recipe
-                    to express its dependencies, both for build-time and
-                    runtime.
-                    There must be a way for you to express recipe preferences
-                    when multiple recipes provide the same functionality, or when
-                    there are multiple versions of a recipe.
-                </para>
-
-                <para>
-                    The <filename>bitbake</filename> command, when not using
-                    "--buildfile" or "-b" only accepts a "PROVIDES".
-                    You cannot provide anything else.
-                    By default, a recipe file generally "PROVIDES" its
-                    "packagename" as shown in the following example:
-                    <literallayout class='monospaced'>
-     $ bitbake foo
-                    </literallayout>
-                    This next example "PROVIDES" the package name and also uses
-                    the "-c" option to tell BitBake to just execute the
-                    <filename>do_clean</filename> task:
-                    <literallayout class='monospaced'>
-     $ bitbake -c clean foo
-                    </literallayout>
-                </para>
-            </section>
-
-            <section id='executing-a-list-of-task-and-recipe-combinations'>
-                <title>Executing a List of Task and Recipe Combinations</title>
-
-                <para>
-                    The BitBake command line supports specifying different
-                    tasks for individual targets when you specify multiple
-                    targets.
-                    For example, suppose you had two targets (or recipes)
-                    <filename>myfirstrecipe</filename> and
-                    <filename>mysecondrecipe</filename> and you needed
-                    BitBake to run <filename>taskA</filename> for the first
-                    recipe and <filename>taskB</filename> for the second
-                    recipe:
-                    <literallayout class='monospaced'>
-     $ bitbake myfirstrecipe:do_taskA mysecondrecipe:do_taskB
-                    </literallayout>
-                </para>
-            </section>
-
-            <section id='generating-dependency-graphs'>
-                <title>Generating Dependency Graphs</title>
-
-                <para>
-                    BitBake is able to generate dependency graphs using
-                    the <filename>dot</filename> syntax.
-                    You can convert these graphs into images using the
-                    <filename>dot</filename> tool from
-                    <ulink url='http://www.graphviz.org'>Graphviz</ulink>.
-                </para>
-
-                <para>
-                    When you generate a dependency graph, BitBake writes two files
-                    to the current working directory:
-                    <itemizedlist>
-                        <listitem><para>
-                            <emphasis><filename>task-depends.dot</filename>:</emphasis>
-                            Shows dependencies between tasks.
-                            These dependencies match BitBake's internal task execution list.
-                            </para></listitem>
-                        <listitem><para>
-                            <emphasis><filename>pn-buildlist</filename>:</emphasis>
-                            Shows a simple list of targets that are to be built.
-                            </para></listitem>
-                    </itemizedlist>
-                </para>
-
-                <para>
-                    To stop depending on common depends, use the "-I" depend
-                    option and BitBake omits them from the graph.
-                    Leaving this information out can produce more readable graphs.
-                    This way, you can remove from the graph
-                    <filename>DEPENDS</filename> from inherited classes
-                    such as <filename>base.bbclass</filename>.
-                </para>
-
-                <para>
-                    Here are two examples that create dependency graphs.
-                    The second example omits depends common in OpenEmbedded from
-                    the graph:
-                    <literallayout class='monospaced'>
-     $ bitbake -g foo
-
-     $ bitbake -g -I virtual/kernel -I eglibc foo
-                    </literallayout>
-                </para>
-            </section>
-
-            <section id='executing-a-multiple-configuration-build'>
-                <title>Executing a Multiple Configuration Build</title>
-
-                <para>
-                    BitBake is able to build multiple images or packages
-                    using a single command where the different targets
-                    require different configurations (multiple configuration
-                    builds).
-                    Each target, in this scenario, is referred to as a
-                    "multiconfig".
-                </para>
-
-                <para>
-                    To accomplish a multiple configuration build, you must
-                    define each target's configuration separately using
-                    a parallel configuration file in the build directory.
-                    The location for these multiconfig configuration files
-                    is specific.
-                    They must reside in the current build directory in
-                    a sub-directory of <filename>conf</filename> named
-                    <filename>multiconfig</filename>.
-                    Following is an example for two separate targets:
-                    <imagedata fileref="figures/bb_multiconfig_files.png" align="center" width="4in" depth="3in" />
-                </para>
-
-                <para>
-                    The reason for this required file hierarchy
-                    is because the <filename>BBPATH</filename> variable
-                    is not constructed until the layers are parsed.
-                    Consequently, using the configuration file as a
-                    pre-configuration file is not possible unless it is
-                    located in the current working directory.
-                </para>
-
-                <para>
-                    Minimally, each configuration file must define the
-                    machine and the temporary directory BitBake uses
-                    for the build.
-                    Suggested practice dictates that you do not
-                    overlap the temporary directories used during the
-                    builds.
-                </para>
-
-                <para>
-                    Aside from separate configuration files for each
-                    target, you must also enable BitBake to perform multiple
-                    configuration builds.
-                    Enabling is accomplished by setting the
-                    <link linkend='var-bb-BBMULTICONFIG'><filename>BBMULTICONFIG</filename></link>
-                    variable in the <filename>local.conf</filename>
-                    configuration file.
-                    As an example, suppose you had configuration files
-                    for <filename>target1</filename> and
-                    <filename>target2</filename> defined in the build
-                    directory.
-                    The following statement in the
-                    <filename>local.conf</filename> file both enables
-                    BitBake to perform multiple configuration builds and
-                    specifies the two extra multiconfigs:
-                    <literallayout class='monospaced'>
-     BBMULTICONFIG = "target1 target2"
-                    </literallayout>
-                </para>
-
-                <para>
-                    Once the target configuration files are in place and
-                    BitBake has been enabled to perform multiple configuration
-                    builds, use the following command form to start the
-                    builds:
-                    <literallayout class='monospaced'>
-     $ bitbake [mc:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable> [[[mc:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable>] ... ]
-                    </literallayout>
-                    Here is an example for two extra multiconfigs:
-                    <filename>target1</filename> and
-                    <filename>target2</filename>:
-                    <literallayout class='monospaced'>
-     $ bitbake mc::<replaceable>target</replaceable> mc:target1:<replaceable>target</replaceable> mc:target2:<replaceable>target</replaceable>
-                    </literallayout>
-                </para>
-            </section>
-
-            <section id='bb-enabling-multiple-configuration-build-dependencies'>
-                <title>Enabling Multiple Configuration Build Dependencies</title>
-
-                <para>
-                    Sometimes dependencies can exist between targets
-                    (multiconfigs) in a multiple configuration build.
-                    For example, suppose that in order to build an image
-                    for a particular architecture, the root filesystem of
-                    another build for a different architecture needs to
-                    exist.
-                    In other words, the image for the first multiconfig depends
-                    on the root filesystem of the second multiconfig.
-                    This dependency is essentially that the task in the recipe
-                    that builds one multiconfig is dependent on the
-                    completion of the task in the recipe that builds
-                    another multiconfig.
-                </para>
-
-                <para>
-                    To enable dependencies in a multiple configuration
-                    build, you must declare the dependencies in the recipe
-                    using the following statement form:
-                    <literallayout class='monospaced'>
-     <replaceable>task_or_package</replaceable>[mcdepends] = "mc:<replaceable>from_multiconfig</replaceable>:<replaceable>to_multiconfig</replaceable>:<replaceable>recipe_name</replaceable>:<replaceable>task_on_which_to_depend</replaceable>"
-                    </literallayout>
-                    To better show how to use this statement, consider an
-                    example with two multiconfigs: <filename>target1</filename>
-                    and <filename>target2</filename>:
-                    <literallayout class='monospaced'>
-     <replaceable>image_task</replaceable>[mcdepends] = "mc:target1:target2:<replaceable>image2</replaceable>:<replaceable>rootfs_task</replaceable>"
-                    </literallayout>
-                    In this example, the
-                    <replaceable>from_multiconfig</replaceable> is "target1" and
-                    the <replaceable>to_multiconfig</replaceable> is "target2".
-                    The task on which the image whose recipe contains
-                    <replaceable>image_task</replaceable> depends on the
-                    completion of the <replaceable>rootfs_task</replaceable>
-                    used to build out <replaceable>image2</replaceable>, which
-                    is associated with the "target2" multiconfig.
-               </para>
-
-               <para>
-                   Once you set up this dependency, you can build the
-                   "target1" multiconfig using a BitBake command as follows:
-                   <literallayout class='monospaced'>
-     $ bitbake mc:target1:<replaceable>image1</replaceable>
-                   </literallayout>
-                   This command executes all the tasks needed to create
-                   <replaceable>image1</replaceable> for the "target1"
-                   multiconfig.
-                   Because of the dependency, BitBake also executes through
-                   the <replaceable>rootfs_task</replaceable> for the "target2"
-                   multiconfig build.
-               </para>
-
-               <para>
-                   Having a recipe depend on the root filesystem of another
-                   build might not seem that useful.
-                   Consider this change to the statement in the
-                   <replaceable>image1</replaceable> recipe:
-                   <literallayout class='monospaced'>
-     <replaceable>image_task</replaceable>[mcdepends] = "mc:target1:target2:<replaceable>image2</replaceable>:<replaceable>image_task</replaceable>"
-                   </literallayout>
-                   In this case, BitBake must create
-                   <replaceable>image2</replaceable> for the "target2"
-                   build since the "target1" build depends on it.
-               </para>
-
-               <para>
-                   Because "target1" and "target2" are enabled for multiple
-                   configuration builds and have separate configuration
-                   files, BitBake places the artifacts for each build in the
-                   respective temporary build directories.
-               </para>
-            </section>
-        </section>
-    </section>
-</chapter>

bitbake/doc/bitbake-user-manual/bitbake-user-manual-style.css

@@ -1,984 +0,0 @@
-/*
-   Generic XHTML / DocBook XHTML CSS Stylesheet.
-
-   Browser wrangling and typographic design by
-      Oyvind Kolas / pippin@gimp.org
-
-   Customised for Poky by
-      Matthew Allum / mallum@o-hand.com
-
-   Thanks to:
-     Liam R. E. Quin
-     William Skaggs
-     Jakub Steiner
-
-   Structure
-   ---------
-
-   The stylesheet is divided into the following sections:
-
-       Positioning
-          Margins, paddings, width, font-size, clearing.
-       Decorations
-          Borders, style
-       Colors
-          Colors
-       Graphics
-          Graphical backgrounds
-       Nasty IE tweaks
-          Workarounds needed to make it work in internet explorer,
-          currently makes the stylesheet non validating, but up until
-          this point it is validating.
-       Mozilla extensions
-          Transparency for footer
-	  Rounded corners on boxes
-
-*/
-
-
-  /*************** /
- /  Positioning   /
-/ ***************/
-
-body {
-  font-family: Verdana, Sans, sans-serif;
-
-  min-width: 640px;
-  width: 80%;
-  margin:  0em auto;
-  padding: 2em 5em 5em 5em;
-  color: #333;
-}
-
-h1,h2,h3,h4,h5,h6,h7 {
-  font-family: Arial, Sans;
-  color: #00557D;
-  clear: both;
-}
-
-h1 {
-  font-size: 2em;
-  text-align: left;
-  padding: 0em 0em 0em 0em;
-  margin: 2em 0em 0em 0em;
-}
-
-h2.subtitle {
-  margin: 0.10em 0em 3.0em 0em;
-  padding: 0em 0em 0em 0em;
-  font-size: 1.8em;
-  padding-left: 20%;
-  font-weight: normal;
-  font-style: italic;
-}
-
-h2 {
-  margin: 2em 0em 0.66em 0em;
-  padding: 0.5em 0em 0em 0em;
-  font-size: 1.5em;
-  font-weight: bold;
-}
-
-h3.subtitle {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-  font-size: 142.14%;
-  text-align: right;
-}
-
-h3 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 140%;
-  font-weight: bold;
-}
-
-h4 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 120%;
-  font-weight: bold;
-}
-
-h5 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
-}
-
-h6 {
-  margin: 1em 0em 0em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
-}
-
-.authorgroup {
-  background-color: transparent;
-  background-repeat: no-repeat;
-  padding-top: 256px;
-  background-image: url("figures/bitbake-title.png");
-  background-position: left top;
-  margin-top: -256px;
-  padding-right: 50px;
-  margin-left: 0px;
-  text-align: right;
-  width: 740px;
-}
-
-h3.author {
-  margin: 0em 0me 0em 0em;
-  padding: 0em 0em 0em 0em;
-  font-weight: normal;
-  font-size: 100%;
-  color: #333;
-  clear: both;
-}
-
-.author tt.email {
-  font-size: 66%;
-}
-
-.titlepage hr {
-  width: 0em;
-  clear: both;
-}
-
-.revhistory {
-  padding-top: 2em;
-  clear: both;
-}
-
-.toc,
-.list-of-tables,
-.list-of-examples,
-.list-of-figures {
-  padding: 1.33em 0em 2.5em 0em;
-  color: #00557D;
-}
-
-.toc p,
-.list-of-tables p,
-.list-of-figures p,
-.list-of-examples p {
-  padding: 0em 0em 0em 0em;
-  padding: 0em 0em 0.3em;
-  margin: 1.5em 0em 0em 0em;
-}
-
-.toc p b,
-.list-of-tables p b,
-.list-of-figures p b,
-.list-of-examples p b{
-  font-size: 100.0%;
-  font-weight: bold;
-}
-
-.toc dl,
-.list-of-tables dl,
-.list-of-figures dl,
-.list-of-examples dl {
-  margin: 0em 0em 0.5em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.toc dt {
-  margin: 0em 0em 0em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.toc dd {
-  margin: 0em 0em 0em 2.6em;
-  padding: 0em 0em 0em 0em;
-}
-
-div.glossary dl,
-div.variablelist dl {
-}
-
-.glossary dl dt,
-.variablelist dl dt,
-.variablelist dl dt span.term {
-  font-weight: normal;
-  width: 20em;
-  text-align: right;
-}
-
-.variablelist dl dt {
-  margin-top: 0.5em;
-}
-
-.glossary dl dd,
-.variablelist dl dd {
-  margin-top: -1em;
-  margin-left: 25.5em;
-}
-
-.glossary dd p,
-.variablelist dd p {
-  margin-top: 0em;
-  margin-bottom: 1em;
-}
-
-
-div.calloutlist table td {
-  padding: 0em 0em 0em 0em;
-  margin: 0em 0em 0em 0em;
-}
-
-div.calloutlist table td p {
-  margin-top: 0em;
-  margin-bottom: 1em;
-}
-
-div p.copyright {
-  text-align: left;
-}
-
-div.legalnotice p.legalnotice-title {
-  margin-bottom: 0em;
-}
-
-p {
-  line-height: 1.5em;
-  margin-top: 0em;
-
-}
-
-dl {
-  padding-top: 0em;
-}
-
-hr {
-  border: solid 1px;
-}
-
-
-.mediaobject,
-.mediaobjectco {
-  text-align: center;
-}
-
-img {
-  border: none;
-}
-
-ul {
-  padding: 0em 0em 0em 1.5em;
-}
-
-ul li {
-  padding: 0em 0em 0em 0em;
-}
-
-ul li p {
-  text-align: left;
-}
-
-table {
-  width :100%;
-}
-
-th {
-  padding: 0.25em;
-  text-align: left;
-  font-weight: normal;
-  vertical-align: top;
-}
-
-td {
-  padding: 0.25em;
-  vertical-align: top;
-}
-
-p a[id] {
-  margin: 0px;
-  padding: 0px;
-  display: inline;
-  background-image: none;
-}
-
-a {
-  text-decoration: underline;
-  color: #444;
-}
-
-pre {
-    overflow: auto;
-}
-
-a:hover {
-  text-decoration: underline;
-  /*font-weight: bold;*/
-}
-
-/* This style defines how the permalink character
-   appears by itself and when hovered over with
-   the mouse. */
-
-[alt='Permalink'] { color: #eee; }
-[alt='Permalink']:hover { color: black; }
-
-
-div.informalfigure,
-div.informalexample,
-div.informaltable,
-div.figure,
-div.table,
-div.example {
-  margin: 1em 0em;
-  padding: 1em;
-  page-break-inside: avoid;
-}
-
-
-div.informalfigure p.title b,
-div.informalexample p.title b,
-div.informaltable p.title b,
-div.figure p.title b,
-div.example p.title b,
-div.table p.title b{
-    padding-top: 0em;
-    margin-top: 0em;
-    font-size: 100%;
-    font-weight: normal;
-}
-
-.mediaobject .caption,
-.mediaobject .caption p  {
-  text-align: center;
-  font-size: 80%;
-  padding-top: 0.5em;
-  padding-bottom: 0.5em;
-}
-
-.epigraph {
-  padding-left: 55%;
-  margin-bottom: 1em;
-}
-
-.epigraph p {
-  text-align: left;
-}
-
-.epigraph .quote {
-  font-style: italic;
-}
-.epigraph .attribution {
-  font-style: normal;
-  text-align: right;
-}
-
-span.application {
-  font-style: italic;
-}
-
-.programlisting {
-  font-family: monospace;
-  font-size: 80%;
-  white-space: pre;
-  margin: 1.33em 0em;
-  padding: 1.33em;
-}
-
-.tip,
-.warning,
-.caution,
-.note {
-  margin-top: 1em;
-  margin-bottom: 1em;
-
-}
-
-/* force full width of table within div */
-.tip table,
-.warning table,
-.caution table,
-.note table {
-  border: none;
-  width: 100%;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  padding: 0.8em 0.0em 0.0em 0.0em;
-  margin : 0em 0em 0em 0em;
-}
-
-.tip p,
-.warning p,
-.caution p,
-.note p {
-  margin-top: 0.5em;
-  margin-bottom: 0.5em;
-  padding-right: 1em;
-  text-align: left;
-}
-
-.acronym {
-  text-transform: uppercase;
-}
-
-b.keycap,
-.keycap {
-  padding: 0.09em 0.3em;
-  margin: 0em;
-}
-
-.itemizedlist li {
-  clear: none;
-}
-
-.filename {
-  font-size: medium;
-  font-family: Courier, monospace;
-}
-
-
-div.navheader, div.heading{
-  position: absolute;
-  left: 0em;
-  top: 0em;
-  width: 100%;
-  background-color: #cdf;
-  width: 100%;
-}
-
-div.navfooter, div.footing{
-  position: fixed;
-  left: 0em;
-  bottom: 0em;
-  background-color: #eee;
-  width: 100%;
-}
-
-
-div.navheader td,
-div.navfooter td {
-  font-size: 66%;
-}
-
-div.navheader table th {
-  /*font-family: Georgia, Times, serif;*/
-  /*font-size: x-large;*/
-  font-size: 80%;
-}
-
-div.navheader table {
-  border-left: 0em;
-  border-right: 0em;
-  border-top: 0em;
-  width: 100%;
-}
-
-div.navfooter table {
-  border-left: 0em;
-  border-right: 0em;
-  border-bottom: 0em;
-  width: 100%;
-}
-
-div.navheader table td a,
-div.navfooter table td a {
-  color: #777;
-  text-decoration: none;
-}
-
-/* normal text in the footer */
-div.navfooter table td {
-  color: black;
-}
-
-div.navheader table td a:visited,
-div.navfooter table td a:visited {
-  color: #444;
-}
-
-
-/* links in header and footer */
-div.navheader table td a:hover,
-div.navfooter table td a:hover {
-  text-decoration: underline;
-  background-color: transparent;
-  color: #33a;
-}
-
-div.navheader hr,
-div.navfooter hr {
-  display: none;
-}
-
-
-.qandaset tr.question td p {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.qandaset tr.answer td p {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-}
-.answer td {
-  padding-bottom: 1.5em;
-}
-
-.emphasis {
-  font-weight: bold;
-}
-
-
-  /************* /
- / decorations  /
-/ *************/
-
-.titlepage {
-}
-
-.part .title {
-}
-
-.subtitle {
-    border: none;
-}
-
-/*
-h1 {
-  border: none;
-}
-
-h2 {
-  border-top: solid 0.2em;
-  border-bottom: solid 0.06em;
-}
-
-h3 {
-  border-top: 0em;
-  border-bottom: solid 0.06em;
-}
-
-h4 {
-  border: 0em;
-  border-bottom: solid 0.06em;
-}
-
-h5 {
-  border: 0em;
-}
-*/
-
-.programlisting {
-  border: solid 1px;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example {
-  border: 1px solid;
-}
-
-
-
-.tip,
-.warning,
-.caution,
-.note {
-  border: 1px solid;
-}
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  border-bottom: 1px solid;
-}
-
-.question td {
-  border-top: 1px solid black;
-}
-
-.answer {
-}
-
-
-b.keycap,
-.keycap {
-  border: 1px solid;
-}
-
-
-div.navheader, div.heading{
-  border-bottom: 1px solid;
-}
-
-
-div.navfooter, div.footing{
-  border-top: 1px solid;
-}
-
-  /********* /
- /  colors  /
-/ *********/
-
-body {
-  color: #333;
-  background: white;
-}
-
-a {
-  background: transparent;
-}
-
-a:hover {
-  background-color: #dedede;
-}
-
-
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7,
-h8 {
-  background-color: transparent;
-}
-
-hr {
-  border-color: #aaa;
-}
-
-
-.tip, .warning, .caution, .note {
-  border-color: #fff;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  border-bottom-color: #fff;
-}
-
-
-.warning {
-  background-color: #f0f0f2;
-}
-
-.caution {
-  background-color: #f0f0f2;
-}
-
-.tip {
-  background-color: #f0f0f2;
-}
-
-.note {
-  background-color: #f0f0f2;
-}
-
-.glossary dl dt,
-.variablelist dl dt,
-.variablelist dl dt span.term {
-  color: #044;
-}
-
-div.figure,
-div.table,
-div.example,
-div.informalfigure,
-div.informaltable,
-div.informalexample {
-  border-color: #aaa;
-}
-
-pre.programlisting {
-  color: black;
-  background-color: #fff;
-  border-color: #aaa;
-  border-width: 2px;
-}
-
-.guimenu,
-.guilabel,
-.guimenuitem {
-  background-color: #eee;
-}
-
-
-b.keycap,
-.keycap {
-  background-color: #eee;
-  border-color: #999;
-}
-
-
-div.navheader {
-  border-color: black;
-}
-
-
-div.navfooter {
-  border-color: black;
-}
-
-
-  /*********** /
- /  graphics  /
-/ ***********/
-
-/*
-body {
-  background-image: url("images/body_bg.jpg");
-  background-attachment: fixed;
-}
-
-.navheader,
-.note,
-.tip {
-  background-image: url("images/note_bg.jpg");
-  background-attachment: fixed;
-}
-
-.warning,
-.caution {
-  background-image: url("images/warning_bg.jpg");
-  background-attachment: fixed;
-}
-
-.figure,
-.informalfigure,
-.example,
-.informalexample,
-.table,
-.informaltable {
-  background-image: url("images/figure_bg.jpg");
-  background-attachment: fixed;
-}
-
-*/
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7{
-}
-
-/*
-Example of how to stick an image as part of the title.
-
-div.article .titlepage .title
-{
-  background-image: url("figures/white-on-black.png");
-  background-position: center;
-  background-repeat: repeat-x;
-}
-*/
-
-div.preface .titlepage .title,
-div.colophon .title,
-div.chapter .titlepage .title,
-div.article .titlepage .title
-{
-}
-
-div.section div.section .titlepage .title,
-div.sect2 .titlepage .title {
-    background: none;
-}
-
-
-h1.title {
-  background-color: transparent;
-  background-repeat: no-repeat;
-  height: 256px;
-  text-indent: -9000px;
-  overflow:hidden;
-}
-
-h2.subtitle {
-  background-color: transparent;
-  text-indent: -9000px;
-  overflow:hidden;
-  width: 0px;
-  display: none;
-}
-
-  /*************************************** /
- /  pippin.gimp.org specific alterations  /
-/ ***************************************/
-
-/*
-div.heading, div.navheader {
-  color: #777;
-  font-size: 80%;
-  padding: 0;
-  margin: 0;
-  text-align: left;
-  position: absolute;
-  top: 0px;
-  left: 0px;
-  width: 100%;
-  height: 50px;
-  background: url('/gfx/heading_bg.png') transparent;
-  background-repeat: repeat-x;
-  background-attachment: fixed;
-  border: none;
-}
-
-div.heading a {
-  color: #444;
-}
-
-div.footing, div.navfooter {
-  border: none;
-  color: #ddd;
-  font-size: 80%;
-  text-align:right;
-
-  width: 100%;
-  padding-top: 10px;
-  position: absolute;
-  bottom: 0px;
-  left: 0px;
-
-  background: url('/gfx/footing_bg.png') transparent;
-}
-*/
-
-
-
-  /****************** /
- /  nasty ie tweaks  /
-/ ******************/
-
-/*
-div.heading, div.navheader {
-  width:expression(document.body.clientWidth + "px");
-}
-
-div.footing, div.navfooter {
-  width:expression(document.body.clientWidth + "px");
-  margin-left:expression("-5em");
-}
-body {
-  padding:expression("4em 5em 0em 5em");
-}
-*/
-
-  /**************************************** /
- / mozilla vendor specific css extensions  /
-/ ****************************************/
-/*
-div.navfooter, div.footing{
-  -moz-opacity: 0.8em;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example,
-.tip,
-.warning,
-.caution,
-.note {
-  -moz-border-radius: 0.5em;
-}
-
-b.keycap,
-.keycap {
-  -moz-border-radius: 0.3em;
-}
-*/
-
-table tr td table tr td {
-  display: none;
-}
-
-
-hr {
-  display: none;
-}
-
-table {
-  border: 0em;
-}
-
- .photo {
-  float: right;
-  margin-left:   1.5em;
-  margin-bottom: 1.5em;
-  margin-top: 0em;
-  max-width:      17em;
-  border:     1px solid gray;
-  padding:    3px;
-  background: white;
-}
- .seperator {
-   padding-top: 2em;
-   clear: both;
-  }
-
-  #validators {
-      margin-top: 5em;
-      text-align: right;
-      color: #777;
-  }
-  @media print {
-      body {
-          font-size: 8pt;
-      }
-      .noprint {
-          display: none;
-      }
-  }
-
-
-.tip,
-.note {
-   background: #f0f0f2;
-   color: #333;
-   padding: 20px;
-   margin: 20px;
-}
-
-.tip h3,
-.note h3 {
-   padding: 0em;
-   margin: 0em;
-   font-size: 2em;
-   font-weight: bold;
-   color: #333;
-}
-
-.tip a,
-.note a {
-   color: #333;
-   text-decoration: underline;
-}
-
-.footnote {
-   font-size: small;
-   color: #333;
-}
-
-/* Changes the announcement text */
-.tip h3,
-.warning h3,
-.caution h3,
-.note h3 {
-   font-size:large;
-   color: #00557D;
-}

bitbake/doc/bitbake-user-manual/bitbake-user-manual.xml

@@ -1,88 +0,0 @@
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<book id='bitbake-user-manual' lang='en'
-        xmlns:xi="http://www.w3.org/2003/XInclude"
-        xmlns="http://docbook.org/ns/docbook"
-        >
-    <bookinfo>
-
-        <mediaobject>
-            <imageobject>
-                <imagedata fileref='figures/bitbake-title.png'
-                    format='SVG'
-                    align='left' scalefit='1' width='100%'/>
-            </imageobject>
-        </mediaobject>
-
-        <title>
-            BitBake User Manual
-        </title>
-
-        <authorgroup>
-            <author>
-                <firstname>Richard Purdie, Chris Larson, and </firstname> <surname>Phil Blundell</surname>
-                <affiliation>
-                    <orgname>BitBake Community</orgname>
-                </affiliation>
-                <email>bitbake-devel@lists.openembedded.org</email>
-            </author>
-        </authorgroup>
-
-<!--
-# Add in some revision history if we want it here.
-        <revhistory>
-            <revision>
-                <revnumber>x.x</revnumber>
-                <date>dd month year</date>
-                <revremark>Some relevent comment</revremark>
-            </revision>
-            <revision>
-                <revnumber>x.x</revnumber>
-                <date>dd month year</date>
-                <revremark>Some relevent comment</revremark>
-            </revision>
-            <revision>
-                <revnumber>x.x</revnumber>
-                <date>dd month year</date>
-                <revremark>Some relevent comment</revremark>
-            </revision>
-            <revision>
-                <revnumber>x.x</revnumber>
-                <date>dd month year</date>
-                <revremark>Some relevent comment</revremark>
-            </revision>
-       </revhistory>
--->
-
-        <copyright>
-            <year>2004-2018</year>
-            <holder>Richard Purdie</holder>
-            <holder>Chris Larson</holder>
-            <holder>and Phil Blundell</holder>
-        </copyright>
-
-        <legalnotice>
-            <para>
-                This work is licensed under the Creative Commons Attribution License.
-                To view a copy of this license, visit
-                <ulink url="http://creativecommons.org/licenses/by/2.5/">http://creativecommons.org/licenses/by/2.5/</ulink>
-                or send a letter to Creative Commons, 444 Castro Street,
-                Suite 900, Mountain View, California 94041, USA.
-            </para>
-        </legalnotice>
-    </bookinfo>
-
-    <xi:include href="bitbake-user-manual-intro.xml"/>
-
-    <xi:include href="bitbake-user-manual-execution.xml"/>
-
-    <xi:include href="bitbake-user-manual-metadata.xml"/>
-
-    <xi:include href="bitbake-user-manual-fetching.xml"/>
-
-    <xi:include href="bitbake-user-manual-ref-variables.xml"/>
-
-    <xi:include href="bitbake-user-manual-hello.xml"/>
-
-</book>

bitbake/doc/bitbake-user-manual/html.css

@@ -1,281 +0,0 @@
-/* Feuille de style DocBook du projet Traduc.org                */
-/* DocBook CSS stylesheet of the Traduc.org project             */
-
-/* (c) Jean-Philippe Gu<47>rard - 14 ao<61>t 2004                     */
-/* (c) Jean-Philippe Gu<47>rard - 14 August 2004                   */
-
-/* Cette feuille de style est libre, vous pouvez la             */
-/* redistribuer et la modifier selon les termes de la Licence   */
-/* Art Libre. Vous trouverez un exemplaire de cette Licence sur */
-/* http://tigreraye.org/Petit-guide-du-traducteur.html#licence-art-libre */
-
-/* This work of art is free, you can redistribute it and/or     */
-/* modify it according to terms of the Free Art license. You    */
-/* will find a specimen of this license on the Copyleft         */
-/* Attitude web site: http://artlibre.org as well as on other   */
-/* sites.                                                       */
-/* Please note that the French version of this licence as shown */
-/* on http://tigreraye.org/Petit-guide-du-traducteur.html#licence-art-libre */
-/* is only official licence of this document. The English       */
-/* is only provided to help you understand this licence.        */
-
-/* La derni<6E>re version de cette feuille de style est toujours   */
-/* disponible sur<75>: http://tigreraye.org/style.css              */
-/* Elle est <20>galement disponible sur<75>:                          */
-/* http://www.traduc.org/docs/HOWTO/lecture/style.css           */
-
-/* The latest version of this stylesheet is available from:     */
-/* http://tigreraye.org/style.css                               */
-/* It is also available on:                                     */
-/* http://www.traduc.org/docs/HOWTO/lecture/style.css           */
-
-/* N'h<>sitez pas <20> envoyer vos commentaires et corrections <20>    */
-/* Jean-Philippe Gu<47>rard <jean-philippe.guerard@tigreraye.org>  */
-
-/* Please send feedback and bug reports to                      */
-/* Jean-Philippe Gu<47>rard <jean-philippe.guerard@tigreraye.org>  */
-
-/* $Id: style.css,v 1.14 2004/09/10 20:12:09 fevrier Exp fevrier $ */
-
-/* Pr<50>sentation g<>n<EFBFBD>rale du document */
-/* Overall document presentation */
-
-body {
-    /*
-    font-family: Apolline, "URW Palladio L", Garamond, jGaramond,
-                 "Bitstream Cyberbit", "Palatino Linotype", serif;
-     */
-    margin: 7%;
-    background-color: white;
-}
-
-/* Taille du texte */
-/* Text size */
-
-* { font-size: 100%; }
-
-/* Gestion des textes mis en relief imbriqu<71>s */
-/* Embedded emphasis */
-
-em { font-style: italic; }
-em em { font-style: normal; }
-em em em { font-style: italic; }
-
-/* Titres */
-/* Titles */
-
-h1 { font-size: 200%; font-weight: 900; }
-h2 { font-size: 160%; font-weight: 900; }
-h3 { font-size: 130%; font-weight: bold; }
-h4 { font-size: 115%; font-weight: bold; }
-h5 { font-size: 108%; font-weight: bold; }
-h6 {                  font-weight: bold; }
-
-/* Nom de famille en petites majuscules (uniquement en fran<61>ais) */
-/* Last names in small caps (for French only) */
-
-*[class~="surname"]:lang(fr) { font-variant: small-caps; }
-
-/* Blocs de citation */
-/* Quotation blocs */
-
-div[class~="blockquote"] {
-  border: solid 2px #AAA;
-  padding: 5px;
-  margin: 5px;
-}
-
-div[class~="blockquote"] > table {
-  border: none;
-}
-
-/* Blocs lit<69>raux<75>: fond gris clair */
-/* Literal blocs: light gray background */
-
-*[class~="literallayout"] {
-  background: #f0f0f0;
-  padding: 5px;
-  margin: 5px;
-}
-
-/* Programmes et captures texte<74>: fond bleu clair */
-/* Listing and text screen snapshots: light blue background */
-
-*[class~="programlisting"], *[class~="screen"] {
-  background: #f0f0ff;
-  padding: 5px;
-  margin: 5px;
-}
-
-/* Les textes <20> remplacer sont surlign<67>s en vert p<>le */
-/* Replaceable text in highlighted in pale green */
-
-*[class~="replaceable"] { 
-    background-color: #98fb98;
-    font-style: normal; }
-
-/* Tables<65>: fonds gris clair & bords simples */
-/* Tables: light gray background and solid borders */
-
-*[class~="table"] *[class~="title"] { width:100%; border: 0px; }
-
-table {
-    border: 1px solid #aaa;
-    border-collapse: collapse;
-    padding: 2px;
-    margin: 5px;
-}
-
-/* Listes simples en style table */
-/* Simples lists in table presentation */
-
-table[class~="simplelist"] {
-    background-color: #F0F0F0;
-    margin: 5px;
-    border: solid 1px #AAA;
-}
-
-table[class~="simplelist"] td {
-    border: solid 1px #AAA;
-}
-
-/* Les tables */
-/* Tables */
-
-*[class~="table"] table {
-    background-color: #F0F0F0;
-    border: solid 1px #AAA;
-}
-*[class~="informaltable"] table { background-color: #F0F0F0; }
-
-th,td {
-    vertical-align: baseline;
-    text-align: left;
-    padding: 0.1em 0.3em;
-    empty-cells: show; 
-}
-
-/* Alignement des colonnes */
-/* Colunms alignment */
-
-td[align=center] ,  th[align=center]  { text-align: center; }
-td[align=right] ,   th[align=right]   { text-align: right; }
-td[align=left] ,    th[align=left]    { text-align: left; }
-td[align=justify] , th[align=justify] { text-align: justify; }
-
-/* Pas de marge autour des images */
-/* No inside margins for images */
-
-img { border: 0; }
-
-/* Les liens ne sont pas soulign<67>s */
-/* No underlines for links */
-
-:link , :visited , :active { text-decoration: none; }
-
-/* Prudence<63>: cadre jaune et fond jaune clair */
-/* Caution: yellow border and light yellow background */
-
-*[class~="caution"] {
-    border: solid 2px yellow;
-    background-color: #ffffe0;
-    padding: 1em 6px 1em ;
-    margin: 5px;
-}
-
-*[class~="caution"] th {
-    vertical-align: middle
-}
-
-*[class~="caution"] table {
-    background-color: #ffffe0;
-    border: none;
-}
-
-/* Note importante<74>: cadre jaune et fond jaune clair */
-/* Important: yellow border and light yellow background */
-
-*[class~="important"] {
-    border: solid 2px yellow;
-    background-color: #ffffe0;
-    padding: 1em 6px 1em;
-    margin: 5px;
-}
-
-*[class~="important"] th {
-    vertical-align: middle
-}
-
-*[class~="important"] table  {
-    background-color: #ffffe0;
-    border: none;
-}
-
-/* Mise en <20>vidence<63>: texte l<>g<EFBFBD>rement plus grand */
-/* Highlights: slightly larger texts */
-
-*[class~="highlights"] {
-    font-size:  110%;
-}
-
-/* Note<74>: cadre bleu et fond bleu clair */
-/* Notes: blue border and light blue background */
-
-*[class~="note"]   {
-    border: solid 2px #7099C5;
-    background-color: #f0f0ff;
-    padding: 1em 6px 1em ;
-    margin: 5px;
-}
-
-*[class~="note"] th {
-    vertical-align: middle
-}
-
-*[class~="note"] table {
-    background-color: #f0f0ff;
-    border: none;
-}
-
-/* Astuce<63>: cadre vert et fond vert clair */
-/* Tip: green border and light green background */
-
-*[class~="tip"] {
-    border: solid 2px #00ff00;
-    background-color: #f0ffff;
-    padding: 1em 6px 1em ;
-    margin: 5px;
-}
-
-*[class~="tip"] th {
-    vertical-align: middle;
-}
-
-*[class~="tip"] table {
-    background-color: #f0ffff;
-    border: none;
-}
-
-/* Avertissement<6E>: cadre rouge et fond rouge clair */
-/* Warning: red border and light red background */
-
-*[class~="warning"] {
-    border: solid 2px #ff0000;
-    background-color: #fff0f0; 
-    padding: 1em 6px 1em ;
-    margin: 5px;
-}
-
-*[class~="warning"] th {
-    vertical-align: middle;
-}
-                    
-
-*[class~="warning"] table {
-    background-color: #fff0f0;
-    border: none;
-}
-
-/* Fin */
-/* The End */
-

bitbake/doc/conf.py

@@ -0,0 +1,101 @@
+# Configuration file for the Sphinx documentation builder.
+#
+# This file only contains a selection of the most common options. For a full
+# list see the documentation:
+# https://www.sphinx-doc.org/en/master/usage/configuration.html
+
+# -- Path setup --------------------------------------------------------------
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#
+# import os
+# import sys
+# sys.path.insert(0, os.path.abspath('.'))
+
+import sys
+import datetime
+
+current_version = "dev"
+
+# String used in sidebar
+version = 'Version: ' + current_version
+if current_version == 'dev':
+    version = 'Version: Current Development'
+# Version seen in documentation_options.js and hence in js switchers code
+release = current_version
+
+# -- Project information -----------------------------------------------------
+
+project = 'Bitbake'
+copyright = '2004-%s, Richard Purdie, Chris Larson, and Phil Blundell' \
+    % datetime.datetime.now().year
+author = 'Richard Purdie, Chris Larson, and Phil Blundell'
+
+# external links and substitutions
+extlinks = {
+    'yocto_docs': ('https://docs.yoctoproject.org%s', None),
+    'oe_lists': ('https://lists.openembedded.org%s', None),
+}
+
+# -- General configuration ---------------------------------------------------
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = [
+    'sphinx.ext.autosectionlabel',
+    'sphinx.ext.extlinks',
+]
+autosectionlabel_prefix_document = True
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+# This pattern also affects html_static_path and html_extra_path.
+exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
+
+# master document name. The default changed from contents to index. so better
+# set it ourselves.
+master_doc = 'index'
+
+# create substitution for project configuration variables
+rst_prolog = """
+.. |project_name| replace:: %s
+.. |copyright| replace:: %s
+.. |author| replace:: %s
+""" % (project, copyright, author)
+
+# -- Options for HTML output -------------------------------------------------
+
+# The theme to use for HTML and HTML Help pages.  See the documentation for
+# a list of builtin themes.
+#
+try:
+    import sphinx_rtd_theme
+    html_theme = 'sphinx_rtd_theme'
+except ImportError:
+    sys.stderr.write("The Sphinx sphinx_rtd_theme HTML theme was not found.\
+    \nPlease make sure to install the sphinx_rtd_theme python package.\n")
+    sys.exit(1)
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['sphinx-static']
+
+# Add customm CSS and JS files
+html_css_files = ['theme_overrides.css']
+html_js_files = ['switchers.js']
+
+# Hide 'Created using Sphinx' text
+html_show_sphinx = False
+
+# Add 'Last updated' on each page
+html_last_updated_fmt = '%b %d, %Y'
+
+# Remove the trailing 'dot' in section numbers
+html_secnumber_suffix = " "

bitbake/doc/genindex.rst

@@ -0,0 +1,3 @@
+=====
+Index
+=====

bitbake/doc/index.rst

@@ -0,0 +1,38 @@
+.. SPDX-License-Identifier: CC-BY-2.5
+
+===================
+BitBake User Manual
+===================
+
+|
+
+.. toctree::
+   :caption: Table of Contents
+   :numbered:
+
+   bitbake-user-manual/bitbake-user-manual-intro
+   bitbake-user-manual/bitbake-user-manual-execution
+   bitbake-user-manual/bitbake-user-manual-metadata
+   bitbake-user-manual/bitbake-user-manual-fetching
+   bitbake-user-manual/bitbake-user-manual-ref-variables
+   bitbake-user-manual/bitbake-user-manual-hello
+
+.. toctree::
+   :maxdepth: 1
+   :hidden:
+
+   genindex
+   releases
+
+----
+
+.. include:: <xhtml1-lat1.txt>
+
+| BitBake Community
+| Copyright |copy| |copyright|
+| <bitbake-devel@lists.openembedded.org>
+
+This work is licensed under the Creative Commons Attribution License.  To view a
+copy of this license, visit http://creativecommons.org/licenses/by/2.5/ or send
+a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain View,
+California 94041, USA.

bitbake/doc/poky.ent

@@ -1,51 +0,0 @@
-<!ENTITY DISTRO "1.4">
-<!ENTITY DISTRO_NAME "tbd">
-<!ENTITY YOCTO_DOC_VERSION "1.4">
-<!ENTITY POKYVERSION "8.0">
-<!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
-<!ENTITY COPYRIGHT_YEAR "2010-2013">
-<!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
-<!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org">
-<!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org">
-<!ENTITY YOCTO_BUGZILLA_URL "http://bugzilla.yoctoproject.org">
-<!ENTITY YOCTO_WIKI_URL "https://wiki.yoctoproject.org">
-<!ENTITY YOCTO_AB_URL "http://autobuilder.yoctoproject.org">
-<!ENTITY YOCTO_GIT_URL "http://git.yoctoproject.org">
-<!ENTITY YOCTO_ADTREPO_URL "http://adtrepo.yoctoproject.org">
-<!ENTITY OE_HOME_URL "http://www.openembedded.org">
-<!ENTITY OE_LISTS_URL "http://lists.linuxtogo.org/cgi-bin/mailman">
-<!ENTITY OE_DOCS_URL "http://docs.openembedded.org">
-<!ENTITY OH_HOME_URL "http://o-hand.com">
-<!ENTITY BITBAKE_HOME_URL "http://developer.berlios.de/projects/bitbake/">
-<!ENTITY YOCTO_DOCS_URL "&YOCTO_HOME_URL;/docs">
-<!ENTITY YOCTO_SOURCES_URL "&YOCTO_HOME_URL;/sources/">
-<!ENTITY YOCTO_AB_PORT_URL "&YOCTO_AB_URL;:8010">
-<!ENTITY YOCTO_AB_NIGHTLY_URL "&YOCTO_AB_URL;/nightly/">
-<!ENTITY YOCTO_POKY_URL "&YOCTO_DL_URL;/releases/poky/">
-<!ENTITY YOCTO_RELEASE_DL_URL "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;">
-<!ENTITY YOCTO_TOOLCHAIN_DL_URL "&YOCTO_RELEASE_DL_URL;/toolchain/">
-<!ENTITY YOCTO_ADTINSTALLER_DL_URL "&YOCTO_RELEASE_DL_URL;/adt_installer">
-<!ENTITY YOCTO_POKY_DL_URL "&YOCTO_RELEASE_DL_URL;/&YOCTO_POKY;.tar.bz2">
-<!ENTITY YOCTO_MACHINES_DL_URL "&YOCTO_RELEASE_DL_URL;/machines">
-<!ENTITY YOCTO_QEMU_DL_URL "&YOCTO_MACHINES_DL_URL;/qemu">
-<!ENTITY YOCTO_PYTHON-i686_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-i686.tar.bz2">
-<!ENTITY YOCTO_PYTHON-x86_64_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-x86_64.tar.bz2">
-<!ENTITY YOCTO_DOCS_QS_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/yocto-project-qs/yocto-project-qs.html">
-<!ENTITY YOCTO_DOCS_ADT_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/adt-manual/adt-manual.html">
-<!ENTITY YOCTO_DOCS_REF_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/ref-manual/ref-manual.html">
-<!ENTITY YOCTO_DOCS_BSP_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/bsp-guide/bsp-guide.html">
-<!ENTITY YOCTO_DOCS_DEV_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/dev-manual/dev-manual.html">
-<!ENTITY YOCTO_DOCS_KERNEL_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/kernel-manual/kernel-manual.html">
-<!ENTITY YOCTO_ADTPATH_DIR "/opt/poky/&DISTRO;">
-<!ENTITY YOCTO_POKY_TARBALL "&YOCTO_POKY;.tar.bz2">
-<!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env">
-<!ENTITY OE_INIT_FILE "oe-init-build-env">
-<!ENTITY UBUNTU_HOST_PACKAGES_ESSENTIAL "gawk wget git-core diffstat unzip texinfo \
-     build-essential chrpath">
-<!ENTITY FEDORA_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
-     diffutils diffstat git cpp gcc gcc-c++ eglibc-devel texinfo chrpath \
-     ccache">
-<!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \
-     diffstat texinfo python-curses">
-<!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
-     diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath">

bitbake/doc/releases.rst

@@ -0,0 +1,130 @@
+.. SPDX-License-Identifier: CC-BY-2.5
+
+=========================
+ Current Release Manuals
+=========================
+
+****************************
+3.1 'dunfell' Release Series
+****************************
+
+- :yocto_docs:`3.1 BitBake User Manual </3.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`3.1.1 BitBake User Manual </3.1.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`3.1.2 BitBake User Manual </3.1.2/bitbake-user-manual/bitbake-user-manual.html>`
+
+==========================
+ Previous Release Manuals
+==========================
+
+*************************
+3.0 'zeus' Release Series
+*************************
+
+- :yocto_docs:`3.0 BitBake User Manual </3.0/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`3.0.1 BitBake User Manual </3.0.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`3.0.2 BitBake User Manual </3.0.2/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`3.0.3 BitBake User Manual </3.0.3/bitbake-user-manual/bitbake-user-manual.html>`
+
+****************************
+2.7 'warrior' Release Series
+****************************
+
+- :yocto_docs:`2.7 BitBake User Manual </2.7/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.7.1 BitBake User Manual </2.7.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.7.2 BitBake User Manual </2.7.2/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.7.3 BitBake User Manual </2.7.3/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.7.4 BitBake User Manual </2.7.4/bitbake-user-manual/bitbake-user-manual.html>`
+
+*************************
+2.6 'thud' Release Series
+*************************
+
+- :yocto_docs:`2.6 BitBake User Manual </2.6/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.6.1 BitBake User Manual </2.6.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.6.2 BitBake User Manual </2.6.2/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.6.3 BitBake User Manual </2.6.3/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.6.4 BitBake User Manual </2.6.4/bitbake-user-manual/bitbake-user-manual.html>`
+
+*************************
+2.5 'sumo' Release Series
+*************************
+
+- :yocto_docs:`2.5 BitBake User Manual </2.5/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.5.1 BitBake User Manual </2.5.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.5.2 BitBake User Manual </2.5.2/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.5.3 BitBake User Manual </2.5.3/bitbake-user-manual/bitbake-user-manual.html>`
+
+**************************
+2.4 'rocko' Release Series
+**************************
+
+- :yocto_docs:`2.4 BitBake User Manual </2.4/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.4.1 BitBake User Manual </2.4.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.4.2 BitBake User Manual </2.4.2/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.4.3 BitBake User Manual </2.4.3/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.4.4 BitBake User Manual </2.4.4/bitbake-user-manual/bitbake-user-manual.html>`
+
+*************************
+2.3 'pyro' Release Series
+*************************
+
+- :yocto_docs:`2.3 BitBake User Manual </2.3/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.3.1 BitBake User Manual </2.3.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.3.2 BitBake User Manual </2.3.2/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.3.3 BitBake User Manual </2.3.3/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.3.4 BitBake User Manual </2.3.4/bitbake-user-manual/bitbake-user-manual.html>`
+
+**************************
+2.2 'morty' Release Series
+**************************
+
+- :yocto_docs:`2.2 BitBake User Manual </2.2/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.2.1 BitBake User Manual </2.2.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.2.2 BitBake User Manual </2.2.2/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.2.3 BitBake User Manual </2.2.3/bitbake-user-manual/bitbake-user-manual.html>`
+
+****************************
+2.1 'krogoth' Release Series
+****************************
+
+- :yocto_docs:`2.1 BitBake User Manual </2.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.1.1 BitBake User Manual </2.1.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.1.2 BitBake User Manual </2.1.2/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.1.3 BitBake User Manual </2.1.3/bitbake-user-manual/bitbake-user-manual.html>`
+
+***************************
+2.0 'jethro' Release Series
+***************************
+
+- :yocto_docs:`1.9 BitBake User Manual </1.9/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.0 BitBake User Manual </2.0/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.0.1 BitBake User Manual </2.0.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.0.2 BitBake User Manual </2.0.2/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`2.0.3 BitBake User Manual </2.0.3/bitbake-user-manual/bitbake-user-manual.html>`
+
+*************************
+1.8 'fido' Release Series
+*************************
+
+- :yocto_docs:`1.8 BitBake User Manual </1.8/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`1.8.1 BitBake User Manual </1.8.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`1.8.2 BitBake User Manual </1.8.2/bitbake-user-manual/bitbake-user-manual.html>`
+
+**************************
+1.7 'dizzy' Release Series
+**************************
+
+- :yocto_docs:`1.7 BitBake User Manual </1.7/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`1.7.1 BitBake User Manual </1.7.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`1.7.2 BitBake User Manual </1.7.2/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`1.7.3 BitBake User Manual </1.7.3/bitbake-user-manual/bitbake-user-manual.html>`
+
+**************************
+1.6 'daisy' Release Series
+**************************
+
+- :yocto_docs:`1.6 BitBake User Manual </1.6/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`1.6.1 BitBake User Manual </1.6.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`1.6.2 BitBake User Manual </1.6.2/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`1.6.3 BitBake User Manual </1.6.3/bitbake-user-manual/bitbake-user-manual.html>`
+

bitbake/doc/sphinx-static/switchers.js

@@ -0,0 +1,233 @@
+(function() {
+  'use strict';
+
+  var all_versions = {
+    'dev': 'dev (3.2)',
+    '3.1.2': '3.1.2',
+    '3.0.3': '3.0.3',
+    '2.7.4': '2.7.4',
+  };
+
+  var all_doctypes = {
+      'single': 'Individual Webpages',
+      'mega': "All-in-one 'Mega' Manual",
+  };
+
+  // Simple version comparision
+  // Return 1 if a > b
+  // Return -1 if a < b
+  // Return 0 if a == b
+  function ver_compare(a, b) {
+    if (a == "dev") {
+       return 1;
+    }
+
+    if (a === b) {
+       return 0;
+    }
+
+    var a_components = a.split(".");
+    var b_components = b.split(".");
+
+    var len = Math.min(a_components.length, b_components.length);
+
+    // loop while the components are equal
+    for (var i = 0; i < len; i++) {
+        // A bigger than B
+        if (parseInt(a_components[i]) > parseInt(b_components[i])) {
+            return 1;
+        }
+
+        // B bigger than A
+        if (parseInt(a_components[i]) < parseInt(b_components[i])) {
+            return -1;
+        }
+    }
+
+    // If one's a prefix of the other, the longer one is greater.
+    if (a_components.length > b_components.length) {
+        return 1;
+    }
+
+    if (a_components.length < b_components.length) {
+        return -1;
+    }
+
+    // Otherwise they are the same.
+    return 0;
+  }
+
+  function build_version_select(current_series, current_version) {
+    var buf = ['<select>'];
+
+    $.each(all_versions, function(version, title) {
+      var series = version.substr(0, 3);
+      if (series == current_series) {
+        if (version == current_version)
+            buf.push('<option value="' + version + '" selected="selected">' + title + '</option>');
+        else
+            buf.push('<option value="' + version + '">' + title + '</option>');
+
+        if (version != current_version)
+            buf.push('<option value="' + current_version + '" selected="selected">' + current_version + '</option>');
+      } else {
+        buf.push('<option value="' + version + '">' + title + '</option>');
+      }
+    });
+
+    buf.push('</select>');
+    return buf.join('');
+  }
+
+  function build_doctype_select(current_doctype) {
+    var buf = ['<select>'];
+
+    $.each(all_doctypes, function(doctype, title) {
+      if (doctype == current_doctype)
+        buf.push('<option value="' + doctype + '" selected="selected">' +
+                 all_doctypes[current_doctype] + '</option>');
+      else
+        buf.push('<option value="' + doctype + '">' + title + '</option>');
+    });
+    if (!(current_doctype in all_doctypes)) {
+        // In case we're browsing a doctype that is not yet in all_doctypes.
+        buf.push('<option value="' + current_doctype + '" selected="selected">' +
+                 current_doctype + '</option>');
+        all_doctypes[current_doctype] = current_doctype;
+    }
+    buf.push('</select>');
+    return buf.join('');
+  }
+
+  function navigate_to_first_existing(urls) {
+    // Navigate to the first existing URL in urls.
+    var url = urls.shift();
+
+    // Web browsers won't redirect file:// urls to file urls using ajax but
+    // its useful for local testing
+    if (url.startsWith("file://")) {
+      window.location.href = url;
+      return;
+    }
+
+    if (urls.length == 0) {
+      window.location.href = url;
+      return;
+    }
+    $.ajax({
+      url: url,
+      success: function() {
+        window.location.href = url;
+      },
+      error: function() {
+        navigate_to_first_existing(urls);
+      }
+    });
+  }
+
+  function get_docroot_url() {
+    var url = window.location.href;
+    var root = DOCUMENTATION_OPTIONS.URL_ROOT;
+
+    var urlarray = url.split('/');
+    // Trim off anything after '/'
+    urlarray.pop();
+    var depth = (root.match(/\.\.\//g) || []).length;
+    for (var i = 0; i < depth; i++) {
+      urlarray.pop();
+    }
+
+    return urlarray.join('/') + '/';
+  }
+
+  function on_version_switch() {
+    var selected_version = $(this).children('option:selected').attr('value');
+    var url = window.location.href;
+    var current_version = DOCUMENTATION_OPTIONS.VERSION;
+    var docroot = get_docroot_url()
+
+    var new_versionpath = selected_version + '/';
+    if (selected_version == "dev")
+        new_versionpath = '';
+
+    // dev versions have no version prefix
+    if (current_version == "dev") {
+        var new_url = docroot + new_versionpath + url.replace(docroot, "");
+        var fallback_url = docroot + new_versionpath;
+    } else {
+        var new_url = url.replace('/' + current_version + '/', '/' + new_versionpath);
+        var fallback_url = new_url.replace(url.replace(docroot, ""), "");
+    }
+
+    console.log(get_docroot_url())
+    console.log(url + " to url " + new_url);
+    console.log(url + " to fallback " + fallback_url);
+
+    if (new_url != url) {
+      navigate_to_first_existing([
+        new_url,
+        fallback_url,
+        'https://www.yoctoproject.org/docs/',
+      ]);
+    }
+  }
+
+  function on_doctype_switch() {
+    var selected_doctype = $(this).children('option:selected').attr('value');
+    var url = window.location.href;
+    if (selected_doctype == 'mega') {
+      var docroot = get_docroot_url()
+      var current_version = DOCUMENTATION_OPTIONS.VERSION;
+      // Assume manuals before 3.2 are using old docbook mega-manual
+      if (ver_compare(current_version, "3.2") < 0) {
+        var new_url = docroot + "mega-manual/mega-manual.html";
+      } else {
+        var new_url = docroot + "singleindex.html";
+      }
+    } else {
+      var new_url = url.replace("singleindex.html", "index.html")
+    }
+
+    if (new_url != url) {
+      navigate_to_first_existing([
+        new_url,
+        'https://www.yoctoproject.org/docs/',
+      ]);
+    }
+  }
+
+  // Returns the current doctype based upon the url
+  function doctype_segment_from_url(url) {
+    if (url.includes("singleindex") || url.includes("mega-manual"))
+      return "mega";
+    return "single";
+  }
+
+  $(document).ready(function() {
+    var release = DOCUMENTATION_OPTIONS.VERSION;
+    var current_doctype = doctype_segment_from_url(window.location.href);
+    var current_series = release.substr(0, 3);
+    var version_select = build_version_select(current_series, release);
+
+    $('.version_switcher_placeholder').html(version_select);
+    $('.version_switcher_placeholder select').bind('change', on_version_switch);
+
+    var doctype_select = build_doctype_select(current_doctype);
+
+    $('.doctype_switcher_placeholder').html(doctype_select);
+    $('.doctype_switcher_placeholder select').bind('change', on_doctype_switch);
+
+    if (ver_compare(release, "3.1") < 0) {
+      $('#outdated-warning').html('Version ' + release + ' of the project is now considered obsolete, please select and use a more recent version');
+      $('#outdated-warning').css('padding', '.5em');
+    } else if (release != "dev") {
+      $.each(all_versions, function(version, title) {
+        var series = version.substr(0, 3);
+        if (series == current_series && version != release) {
+          $('#outdated-warning').html('This document is for outdated version ' + release + ', you should select the latest release version in this series, ' + version + '.');
+          $('#outdated-warning').css('padding', '.5em');
+        }
+      });
+    }
+  });
+})();

bitbake/doc/sphinx-static/theme_overrides.css

@@ -0,0 +1,162 @@
+/*
+    SPDX-License-Identifier: CC-BY-2.0-UK
+*/
+
+body {
+  font-family: Verdana, Sans, sans-serif;
+  margin:  0em auto;
+  color: #333;
+}
+
+h1,h2,h3,h4,h5,h6,h7 {
+  font-family: Arial, Sans;
+  color: #00557D;
+  clear: both;
+}
+
+h1 {
+  font-size: 2em;
+  text-align: left;
+  padding: 0em 0em 0em 0em;
+  margin: 2em 0em 0em 0em;
+}
+
+h2.subtitle {
+  margin: 0.10em 0em 3.0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 1.8em;
+  padding-left: 20%;
+  font-weight: normal;
+  font-style: italic;
+}
+
+h2 {
+  margin: 2em 0em 0.66em 0em;
+  padding: 0.5em 0em 0em 0em;
+  font-size: 1.5em;
+  font-weight: bold;
+}
+
+h3.subtitle {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 142.14%;
+  text-align: right;
+}
+
+h3 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 140%;
+  font-weight: bold;
+}
+
+h4 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 120%;
+  font-weight: bold;
+}
+
+h5 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+h6 {
+  margin: 1em 0em 0em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+em {
+  font-weight: bold;
+}
+
+.pre {
+  font-size: medium;
+  font-family: Courier, monospace;
+}
+
+.wy-nav-content a {
+  text-decoration: underline;
+  color: #444;
+  background: transparent;
+}
+
+.wy-nav-content a:hover {
+  text-decoration: underline;
+  background-color: #dedede;
+}
+
+.wy-nav-content a:visited {
+  color: #444;
+}
+
+[alt='Permalink'] { color: #eee; }
+[alt='Permalink']:hover { color: black; }
+
+@media screen {
+    /* content column
+     *
+     * RTD theme's default is 800px as max width for the content, but we have
+     * tables with tons of columns, which need the full width of the view-port.
+     */
+
+    .wy-nav-content{max-width: none; }
+
+    /* inline literal: drop the borderbox, padding and red color */
+    code, .rst-content tt, .rst-content code {
+        color: inherit;
+        border: none;
+        padding: unset;
+        background: inherit;
+        font-size: 85%;
+    }
+
+    .rst-content tt.literal,.rst-content tt.literal,.rst-content code.literal {
+        color: inherit;
+    }
+
+    /* Admonition should be gray, not blue or green */
+    .rst-content .note .admonition-title,
+    .rst-content .tip .admonition-title,
+    .rst-content .warning .admonition-title,
+    .rst-content .caution .admonition-title,
+    .rst-content .important .admonition-title {
+        background: #f0f0f2;
+        color: #00557D;
+
+    }
+
+    .rst-content .note,
+    .rst-content .tip,
+    .rst-content .important,
+    .rst-content .warning,
+    .rst-content .caution  {
+        background: #f0f0f2;
+    }
+
+    /* Remove the icon in front of note/tip element, and before the logo */
+    .icon-home:before, .rst-content .admonition-title:before {
+        display: none
+    }
+
+    /* a custom informalexample container is used in some doc */
+    .informalexample {
+        border: 1px solid;
+        border-color: #aaa;
+        margin: 1em 0em;
+        padding: 1em;
+        page-break-inside: avoid;
+    }
+
+    /* Remove the blue background in the top left corner, around the logo */
+    .wy-side-nav-search {
+        background: inherit;
+    }
+
+}

bitbake/doc/template/component.title.xsl

@@ -1,39 +0,0 @@
-<xsl:stylesheet version="1.0"
-  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
-  xmlns:d="http://docbook.org/ns/docbook"
-  xmlns="http://www.w3.org/1999/xhtml"
-  exclude-result-prefixes="d">
-  
-  <xsl:template name="component.title">
-    <xsl:param name="node" select="."/>
-    
-    <xsl:variable name="level">
-      <xsl:choose>
-        <xsl:when test="ancestor::d:section">
-          <xsl:value-of select="count(ancestor::d:section)+1"/>
-        </xsl:when>
-        <xsl:when test="ancestor::d:sect5">6</xsl:when>
-        <xsl:when test="ancestor::d:sect4">5</xsl:when>
-        <xsl:when test="ancestor::d:sect3">4</xsl:when>
-        <xsl:when test="ancestor::d:sect2">3</xsl:when>
-        <xsl:when test="ancestor::d:sect1">2</xsl:when>
-        <xsl:otherwise>1</xsl:otherwise>
-      </xsl:choose>
-    </xsl:variable>
-    <xsl:element name="h{$level+1}" namespace="http://www.w3.org/1999/xhtml">
-      <xsl:attribute name="class">title</xsl:attribute>
-      <xsl:if test="$generate.id.attributes = 0">
-        <xsl:call-template name="anchor">
-          <xsl:with-param name="node" select="$node"/>
-          <xsl:with-param name="conditional" select="0"/>
-        </xsl:call-template>
-      </xsl:if>
-      <xsl:apply-templates select="$node" mode="object.title.markup">
-        <xsl:with-param name="allow-anchors" select="1"/>
-      </xsl:apply-templates>
-      <xsl:call-template name="permalink">
-        <xsl:with-param name="node" select="$node"/>
-      </xsl:call-template>
-    </xsl:element>
-  </xsl:template>
-</xsl:stylesheet>

bitbake/doc/template/db-pdf.xsl

@@ -1,64 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
-  
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl" />
-
-  <!-- check project-plan.sh for how this is generated, needed to tweak 
-       the cover page     
-    -->
-  <xsl:include href="/tmp/titlepage.xsl"/> 
-
-  <!-- To force a page break in document, i.e per section add a 
-      <?hard-pagebreak?> tag.
-  -->
- <xsl:template match="processing-instruction('hard-pagebreak')">
-   <fo:block break-before='page' />
- </xsl:template>
-
-  <!--Fix for defualt indent getting TOC all wierd..
-      See http://sources.redhat.com/ml/docbook-apps/2005-q1/msg00455.html 
-      FIXME: must be a better fix
-    -->
-  <xsl:param name="body.start.indent" select="'0'"/>
-  <!--<xsl:param name="title.margin.left" select="'0'"/>-->
-
-  <!-- stop long-ish header titles getting wrapped -->
-  <xsl:param name="header.column.widths">1 10 1</xsl:param>
-
-  <!-- customise headers and footers a little --> 
-
-  <xsl:template name="head.sep.rule">
-   <xsl:if test="$header.rule != 0">
-     <xsl:attribute name="border-bottom-width">0.5pt</xsl:attribute>
-     <xsl:attribute name="border-bottom-style">solid</xsl:attribute>
-     <xsl:attribute name="border-bottom-color">#cccccc</xsl:attribute>
-   </xsl:if>
-  </xsl:template>
-
-  <xsl:template name="foot.sep.rule">
-    <xsl:if test="$footer.rule != 0">
-     <xsl:attribute name="border-top-width">0.5pt</xsl:attribute>
-     <xsl:attribute name="border-top-style">solid</xsl:attribute>
-     <xsl:attribute name="border-top-color">#cccccc</xsl:attribute>
-    </xsl:if>
-  </xsl:template>
-
-  <xsl:attribute-set name="header.content.properties">
-    <xsl:attribute name="color">#cccccc</xsl:attribute>
-  </xsl:attribute-set>
-
-  <xsl:attribute-set name="footer.content.properties">
-    <xsl:attribute name="color">#cccccc</xsl:attribute>
-  </xsl:attribute-set>
-
- 
-  <!-- general settings -->
-
-  <xsl:param name="fop1.extensions" select="1"></xsl:param>
-  <xsl:param name="paper.type" select="'A4'"></xsl:param>
-  <xsl:param name="section.autolabel" select="1"></xsl:param>
-  <xsl:param name="body.font.family" select="'verasans'"></xsl:param>
-  <xsl:param name="title.font.family" select="'verasans'"></xsl:param>
-  <xsl:param name="monospace.font.family" select="'veramono'"></xsl:param>
-
-</xsl:stylesheet>

bitbake/doc/template/division.title.xsl

@@ -1,25 +0,0 @@
-<xsl:stylesheet version="1.0"
-  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
-  xmlns:d="http://docbook.org/ns/docbook"
-  xmlns="http://www.w3.org/1999/xhtml"
-  exclude-result-prefixes="d">
-  
-  <xsl:template name="division.title">
-    <xsl:param name="node" select="."/>
-    
-    <h1>
-      <xsl:attribute name="class">title</xsl:attribute>
-      <xsl:call-template name="anchor">
-        <xsl:with-param name="node" select="$node"/>
-        <xsl:with-param name="conditional" select="0"/>
-      </xsl:call-template>
-      <xsl:apply-templates select="$node" mode="object.title.markup">
-        <xsl:with-param name="allow-anchors" select="1"/>
-      </xsl:apply-templates>
-      <xsl:call-template name="permalink">
-        <xsl:with-param name="node" select="$node"/>
-      </xsl:call-template>
-    </h1>
-  </xsl:template>
-</xsl:stylesheet>
-

bitbake/doc/template/fop-config.xml

@@ -1,58 +0,0 @@
-<fop version="1.0">
-
-  <!-- Strict user configuration -->
-  <strict-configuration>true</strict-configuration>
-
-  <!-- Strict FO validation -->
-  <strict-validation>true</strict-validation>
-
-   <!--
-    Set the baseDir so common/openedhand.svg references in plans still
-    work ok. Note, relative file references to current dir should still work.
-    -->	
-  <base>../template</base>
-  <font-base>../template</font-base>
- 
-  <!-- Source resolution in dpi (dots/pixels per inch) for determining the
-       size of pixels in SVG and bitmap images, default: 72dpi -->
-  <!-- <source-resolution>72</source-resolution> -->
-  <!-- Target resolution in dpi (dots/pixels per inch) for specifying the
-       target resolution for generated bitmaps, default: 72dpi -->
-  <!-- <target-resolution>72</target-resolution> -->
- 
-  <!-- default page-height and page-width, in case
-       value is specified as auto -->
-  <default-page-settings height="11in" width="8.26in"/> 
- 
-  <!-- <use-cache>false</use-cache> -->
- 
-  <renderers>
-    <renderer mime="application/pdf">
-      <fonts>
-        <font  metrics-file="VeraMono.xml"
-               kerning="yes" 
-               embed-url="VeraMono.ttf">
-          <font-triplet name="veramono" style="normal" weight="normal"/>
-        </font>
-
-        <font  metrics-file="VeraMoBd.xml"
-               kerning="yes" 
-               embed-url="VeraMoBd.ttf">
-          <font-triplet name="veramono" style="normal" weight="bold"/>
-        </font>
-
-        <font  metrics-file="Vera.xml"
-               kerning="yes" 
-               embed-url="Vera.ttf">
-          <font-triplet name="verasans" style="normal" weight="normal"/>
-          <font-triplet name="verasans" style="normal" weight="bold"/>
-          <font-triplet name="verasans" style="italic" weight="normal"/>
-          <font-triplet name="verasans" style="italic" weight="bold"/>
-        </font>
-        
-        <auto-detect/>
-      </fonts>
-    </renderer>
-  </renderers>
-</fop>
-

bitbake/doc/template/formal.object.heading.xsl

@@ -1,21 +0,0 @@
-<xsl:stylesheet version="1.0"
-  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
-  xmlns:d="http://docbook.org/ns/docbook"
-  xmlns="http://www.w3.org/1999/xhtml"
-  exclude-result-prefixes="d">
-  
-  <xsl:template name="formal.object.heading">
-    <xsl:param name="object" select="."/>
-    <xsl:param name="title">
-      <xsl:apply-templates select="$object" mode="object.title.markup">
-        <xsl:with-param name="allow-anchors" select="1"/>
-      </xsl:apply-templates>
-    </xsl:param>
-    <p class="title">
-      <b><xsl:copy-of select="$title"/></b>
-      <xsl:call-template name="permalink">
-        <xsl:with-param name="node" select="$object"/>
-      </xsl:call-template>
-    </p>
-  </xsl:template>
-</xsl:stylesheet>

bitbake/doc/template/gloss-permalinks.xsl

@@ -1,14 +0,0 @@
-<xsl:stylesheet version="1.0"
-  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
-  xmlns:d="http://docbook.org/ns/docbook"
-  xmlns="http://www.w3.org/1999/xhtml">
-
-  <xsl:template match="glossentry/glossterm">
-    <xsl:apply-imports/>
-    <xsl:if test="$generate.permalink != 0">
-      <xsl:call-template name="permalink">
-        <xsl:with-param name="node" select=".."/>
-      </xsl:call-template>
-    </xsl:if>
-  </xsl:template>
-</xsl:stylesheet>

bitbake/doc/template/permalinks.xsl

@@ -1,25 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<xsl:stylesheet version="1.0"
-  xmlns="http://www.w3.org/1999/xhtml"
-  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
-
-  <xsl:param name="generate.permalink" select="1"/>
-  <xsl:param name="permalink.text">¶</xsl:param>
-
-  <xsl:template name="permalink">
-    <xsl:param name="node"/>
-
-    <xsl:if test="$generate.permalink != '0'">
-      <span class="permalink">
-        <a alt="Permalink" title="Permalink">
-          <xsl:attribute name="href">
-            <xsl:call-template name="href.target">
-              <xsl:with-param name="object"  select="$node"/>
-            </xsl:call-template>
-          </xsl:attribute>
-          <xsl:copy-of select="$permalink.text"/>
-        </a>
-      </span>
-    </xsl:if>
-  </xsl:template>
-</xsl:stylesheet>

bitbake/doc/template/section.title.xsl

@@ -1,55 +0,0 @@
-<xsl:stylesheet version="1.0"
-  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
-  xmlns:d="http://docbook.org/ns/docbook"
-  xmlns="http://www.w3.org/1999/xhtml" exclude-result-prefixes="d">
-
-  <xsl:template name="section.title">
-    <xsl:variable name="section"
-      select="(ancestor::section |
-               ancestor::simplesect|
-               ancestor::sect1|
-               ancestor::sect2|
-               ancestor::sect3|
-               ancestor::sect4|
-               ancestor::sect5)[last()]"/>
-
-    <xsl:variable name="renderas">
-      <xsl:choose>
-        <xsl:when test="$section/@renderas = 'sect1'">1</xsl:when>
-        <xsl:when test="$section/@renderas = 'sect2'">2</xsl:when>
-        <xsl:when test="$section/@renderas = 'sect3'">3</xsl:when>
-        <xsl:when test="$section/@renderas = 'sect4'">4</xsl:when>
-        <xsl:when test="$section/@renderas = 'sect5'">5</xsl:when>
-        <xsl:otherwise><xsl:value-of select="''"/></xsl:otherwise>
-      </xsl:choose>
-    </xsl:variable>
-
-    <xsl:variable name="level">
-      <xsl:choose>
-        <xsl:when test="$renderas != ''">
-          <xsl:value-of select="$renderas"/>
-        </xsl:when>
-        <xsl:otherwise>
-          <xsl:call-template name="section.level">
-            <xsl:with-param name="node" select="$section"/>
-          </xsl:call-template>
-        </xsl:otherwise>
-      </xsl:choose>
-    </xsl:variable>
-
-    <xsl:call-template name="section.heading">
-      <xsl:with-param name="section" select="$section"/>
-      <xsl:with-param name="level" select="$level"/>
-      <xsl:with-param name="title">
-        <xsl:apply-templates select="$section" mode="object.title.markup">
-          <xsl:with-param name="allow-anchors" select="1"/>
-        </xsl:apply-templates>
-        <xsl:if test="$level &gt; 0">
-          <xsl:call-template name="permalink">
-            <xsl:with-param name="node" select="$section"/>
-          </xsl:call-template>
-        </xsl:if>
-      </xsl:with-param>
-    </xsl:call-template>
-  </xsl:template>
-</xsl:stylesheet>

bitbake/doc/tools/docbook-to-pdf

@@ -1,51 +0,0 @@
-#!/bin/sh
-	
-if [ -z "$1" -o -z "$2" ]; then
-   echo "usage: [-v] $0 <docbook file> <templatedir>"
-   echo
-   echo "*NOTE* you need xsltproc, fop and nwalsh docbook stylesheets" 
-   echo "       installed for this to work!"
-   echo
-   exit 0
-fi
-
-FO=`echo $1 | sed s/.xml/.fo/` || exit 1
-PDF=`echo $1 | sed s/.xml/.pdf/` || exit 1
-TEMPLATEDIR=$2
-
-##
-# These URI should be rewritten by your distribution's xml catalog to
-# match your localy installed XSL stylesheets.
-XSL_BASE_URI="http://docbook.sourceforge.net/release/xsl/current"
-
-# Creates a temporary XSL stylesheet based on titlepage.xsl
-xsltproc -o /tmp/titlepage.xsl                                           \
-	 --xinclude                                                      \
-         $XSL_BASE_URI/template/titlepage.xsl \
-         $TEMPLATEDIR/titlepage.templates.xml || exit 1
-
-# Creates the file needed for FOP
-xsltproc --xinclude                    \
-	 --stringparam hyphenate false \
-	 --stringparam formal.title.placement "figure after" \
-	 --stringparam ulink.show 1 \
-         --stringparam  body.font.master  9 \
-         --stringparam  title.font.master  11 \
-         --stringparam draft.watermark.image "$TEMPLATEDIR/draft.png" \
-         --stringparam  chapter.autolabel 1 \
-         --stringparam  appendix.autolabel A \
-         --stringparam  section.autolabel 1 \
-         --stringparam  section.label.includes.component.label 1 \
-         --output $FO               \
-         $TEMPLATEDIR/db-pdf.xsl    \
-	 $1                 || exit 1
-
-# Invokes the Java version of FOP.  Uses the additional configuration file common/fop-config.xml
-fop -c $TEMPLATEDIR/fop-config.xml -fo $FO -pdf $PDF       || exit 1
-
-rm -f $FO
-rm -f  /tmp/titlepage.xsl
-
-echo
-echo " #### Success! $PDF ready. ####"
-echo

bitbake/lib/bb/__init__.py

@@ -47,7 +47,7 @@ class BBLogger(Logger):
         if not bb.event.worker_pid:
             if self.name in bb.msg.loggerDefaultDomains and loglevel > (bb.msg.loggerDefaultDomains[self.name]):
                 return
-            if loglevel > bb.msg.loggerDefaultLogLevel:
+            if loglevel < bb.msg.loggerDefaultLogLevel:
                 return
         return self.log(loglevel, msg, *args, **kwargs)
 

bitbake/lib/bb/build.py

@@ -27,6 +27,9 @@ from bb import data, event, utils
 bblogger = logging.getLogger('BitBake')
 logger = logging.getLogger('BitBake.Build')
 
+verboseShellLogging = False
+verboseStdoutLogging = False
+
 __mtime_cache = {}
 
 def cached_mtime_noerror(f):
@@ -290,8 +293,8 @@ def exec_func_python(func, d, runfile, cwd=None):
         lineno = int(d.getVarFlag(func, "lineno", False))
         bb.methodpool.insert_method(func, text, fn, lineno - 1)
 
-        comp = utils.better_compile(code, func, "exec_python_func() autogenerated")
-        utils.better_exec(comp, {"d": d}, code, "exec_python_func() autogenerated")
+        comp = utils.better_compile(code, func, "exec_func_python() autogenerated")
+        utils.better_exec(comp, {"d": d}, code, "exec_func_python() autogenerated")
     finally:
         bb.debug(2, "Python function %s finished" % func)
 
@@ -371,7 +374,7 @@ def exec_func_shell(func, d, runfile, cwd=None):
 
         bb.data.emit_func(func, script, d)
 
-        if bb.msg.loggerVerboseLogs:
+        if verboseShellLogging or bb.utils.to_boolean(d.getVar("BB_VERBOSE_LOGS", False)):
             script.write("set -x\n")
         if cwd:
             script.write("cd '%s'\n" % cwd)
@@ -391,7 +394,7 @@ exit $ret
         if fakerootcmd:
             cmd = [fakerootcmd, runfile]
 
-    if bb.msg.loggerDefaultVerbose:
+    if verboseStdoutLogging:
         logfile = LogTee(logger, StdoutNoopContextManager())
     else:
         logfile = StdoutNoopContextManager()
@@ -587,11 +590,15 @@ def _exec_task(fn, task, d, quieterr):
         except bb.BBHandledException:
             event.fire(TaskFailed(task, fn, logfn, localdata, True), localdata)
             return 1
-        except Exception as exc:
+        except (Exception, SystemExit) as exc:
             if quieterr:
                 event.fire(TaskFailedSilent(task, fn, logfn, localdata), localdata)
             else:
                 errprinted = errchk.triggered
+                # If the output is already on stdout, we've printed the information in the
+                # logs once already so don't duplicate
+                if verboseStdoutLogging:
+                    errprinted = True
                 logger.error(str(exc))
                 event.fire(TaskFailed(task, fn, logfn, localdata, errprinted), localdata)
             return 1
@@ -901,6 +908,8 @@ def tasksbetween(task_start, task_end, d):
     def follow_chain(task, endtask, chain=None):
         if not chain:
             chain = []
+        if task in chain:
+            bb.fatal("Circular task dependencies as %s depends on itself via the chain %s" % (task, " -> ".join(chain)))
         chain.append(task)
         for othertask in tasks:
             if othertask == task:

bitbake/lib/bb/command.py

@@ -74,8 +74,12 @@ class Command:
                 result = command_method(self, commandline)
             except CommandError as exc:
                 return None, exc.args[0]
-            except (Exception, SystemExit):
+            except (Exception, SystemExit) as exc:
                 import traceback
+                if isinstance(exc, bb.BBHandledException):
+                    # We need to start returning real exceptions here. Until we do, we can't
+                    # tell if an exception is an instance of bb.BBHandledException
+                    return None, "bb.BBHandledException()\n" + traceback.format_exc()
                 return None, traceback.format_exc()
             else:
                 return result, None
@@ -620,6 +624,16 @@ class CommandsAsync:
         command.finishAsyncCommand()
     findFilesMatchingInDir.needcache = False
 
+    def testCookerCommandEvent(self, command, params):
+        """
+        Dummy command used by OEQA selftest to test tinfoil without IO
+        """
+        pattern = params[0]
+
+        command.cooker.testCookerCommandEvent(pattern)
+        command.finishAsyncCommand()
+    testCookerCommandEvent.needcache = False
+
     def findConfigFilePath(self, command, params):
         """
         Find the path of the requested configuration file

bitbake/lib/bb/compat.py

@@ -1,10 +0,0 @@
-#
-# SPDX-License-Identifier: GPL-2.0-only
-#
-
-"""Code pulled from future python versions, here for compatibility"""
-
-from collections import MutableMapping, KeysView, ValuesView, ItemsView, OrderedDict
-from functools import total_ordering
-
-

bitbake/lib/bb/cooker.py

@@ -411,10 +411,7 @@ class BBCooker:
             self.data.disableTracking()
 
     def parseConfiguration(self):
-        # Set log file verbosity
-        verboselogs = bb.utils.to_boolean(self.data.getVar("BB_VERBOSE_LOGS", False))
-        if verboselogs:
-            bb.msg.loggerVerboseLogs = True
+        self.updateCacheSync()
 
         # Change nice level if we're asked to
         nice = self.data.getVar("BB_NICE_LEVEL")
@@ -1022,6 +1019,11 @@ class BBCooker:
         if matches:
             bb.event.fire(bb.event.FilesMatchingFound(filepattern, matches), self.data)
 
+    def testCookerCommandEvent(self, filepattern):
+        # Dummy command used by OEQA selftest to test tinfoil without IO
+        matches = ["A", "B"]
+        bb.event.fire(bb.event.FilesMatchingFound(filepattern, matches), self.data)
+
     def findProviders(self, mc=''):
         return bb.providers.findProviders(self.databuilder.mcdata[mc], self.recipecaches[mc], self.recipecaches[mc].pkg_pn)
 
@@ -1636,6 +1638,7 @@ class BBCooker:
         return
 
     def post_serve(self):
+        self.shutdown(force=True)
         prserv.serv.auto_shutdown()
         if self.hashserv:
             self.hashserv.process.terminate()
@@ -1650,6 +1653,7 @@ class BBCooker:
 
         if self.parser:
             self.parser.shutdown(clean=not force, force=force)
+            self.parser.final_cleanup()
 
     def finishcommand(self):
         self.state = state.initial
@@ -1931,7 +1935,8 @@ class Parser(multiprocessing.Process):
             except queue.Empty:
                 pass
             else:
-                self.results.cancel_join_thread()
+                self.results.close()
+                self.results.join_thread()
                 break
 
             if pending:
@@ -1940,6 +1945,8 @@ class Parser(multiprocessing.Process):
                 try:
                     job = self.jobs.pop()
                 except IndexError:
+                    self.results.close()
+                    self.results.join_thread()
                     break
                 result = self.parse(*job)
                 # Clear the siggen cache after parsing to control memory usage, its huge
@@ -2015,6 +2022,7 @@ class CookerParser(object):
 
         self.start()
         self.haveshutdown = False
+        self.syncthread = None
 
     def start(self):
         self.results = self.load_cached()
@@ -2056,12 +2064,9 @@ class CookerParser(object):
                                             self.total)
 
             bb.event.fire(event, self.cfgdata)
-            for process in self.processes:
-                self.parser_quit.put(None)
-        else:
-            self.parser_quit.cancel_join_thread()
-            for process in self.processes:
-                self.parser_quit.put(None)
+
+        for process in self.processes:
+            self.parser_quit.put(None)
 
         # Cleanup the queue before call process.join(), otherwise there might be
         # deadlocks.
@@ -2078,9 +2083,13 @@ class CookerParser(object):
             else:
                 process.join()
 
+        self.parser_quit.close()
+        # Allow data left in the cancel queue to be discarded
+        self.parser_quit.cancel_join_thread()
+
         sync = threading.Thread(target=self.bb_cache.sync)
+        self.syncthread = sync
         sync.start()
-        multiprocessing.util.Finalize(None, sync.join, exitpriority=-100)
         bb.codeparser.parser_cache_savemerge()
         bb.fetch.fetcher_parse_done()
         if self.cooker.configuration.profile:
@@ -2094,6 +2103,10 @@ class CookerParser(object):
             bb.utils.process_profilelog(profiles, pout = pout)
             print("Processed parsing statistics saved to %s" % (pout))
 
+    def final_cleanup(self):
+        if self.syncthread:
+            self.syncthread.join()
+
     def load_cached(self):
         for filename, appends in self.fromcache:
             cached, infos = self.bb_cache.load(filename, appends)
@@ -2126,18 +2139,18 @@ class CookerParser(object):
         except bb.BBHandledException as exc:
             self.error += 1
             logger.error('Failed to parse recipe: %s' % exc.recipe)
-            self.shutdown(clean=False)
+            self.shutdown(clean=False, force=True)
             return False
         except ParsingFailure as exc:
             self.error += 1
             logger.error('Unable to parse %s: %s' %
                      (exc.recipe, bb.exceptions.to_string(exc.realexception)))
-            self.shutdown(clean=False)
+            self.shutdown(clean=False, force=True)
             return False
         except bb.parse.ParseError as exc:
             self.error += 1
             logger.error(str(exc))
-            self.shutdown(clean=False)
+            self.shutdown(clean=False, force=True)
             return False
         except bb.data_smart.ExpansionError as exc:
             self.error += 1
@@ -2146,7 +2159,7 @@ class CookerParser(object):
             tb = list(itertools.dropwhile(lambda e: e.filename.startswith(bbdir), exc.traceback))
             logger.error('ExpansionError during parsing %s', value.recipe,
                          exc_info=(etype, value, tb))
-            self.shutdown(clean=False)
+            self.shutdown(clean=False, force=True)
             return False
         except Exception as exc:
             self.error += 1
@@ -2158,7 +2171,7 @@ class CookerParser(object):
                 # Most likely, an exception occurred during raising an exception
                 import traceback
                 logger.error('Exception during parse: %s' % traceback.format_exc())
-            self.shutdown(clean=False)
+            self.shutdown(clean=False, force=True)
             return False
 
         self.current += 1

bitbake/lib/bb/cookerdata.py

@@ -58,11 +58,14 @@ class ConfigParameters(object):
     def updateToServer(self, server, environment):
         options = {}
         for o in ["abort", "force", "invalidate_stamp",
-                  "verbose", "debug", "dry_run", "dump_signatures",
+                  "debug", "dry_run", "dump_signatures",
                   "debug_domains", "extra_assume_provided", "profile",
                   "prefile", "postfile", "server_timeout"]:
             options[o] = getattr(self.options, o)
 
+        options['build_verbose_shell'] = self.options.verbose
+        options['build_verbose_stdout'] = self.options.verbose
+
         ret, error = server.runCommand(["updateConfig", options, environment, sys.argv])
         if error:
             raise Exception("Unable to update the server configuration with local parameters: %s" % error)
@@ -125,6 +128,8 @@ class CookerConfiguration(object):
         self.skipsetscene = False
         self.invalidate_stamp = False
         self.dump_signatures = []
+        self.build_verbose_shell = False
+        self.build_verbose_stdout = False
         self.dry_run = False
         self.tracking = False
         self.xmlrpcinterface = []
@@ -297,6 +302,8 @@ class CookerDataBuilder(object):
 
             multiconfig = (self.data.getVar("BBMULTICONFIG") or "").split()
             for config in multiconfig:
+                if config[0].isdigit():
+                    bb.fatal("Multiconfig name '%s' is invalid as multiconfigs cannot start with a digit" % config)
                 mcdata = self.parseConfigurationFiles(self.prefiles, self.postfiles, config)
                 bb.event.fire(bb.event.ConfigParsed(), mcdata)
                 self.mcdata[config] = mcdata
@@ -348,6 +355,9 @@ class CookerDataBuilder(object):
             layers = (data.getVar('BBLAYERS') or "").split()
             broken_layers = []
 
+            if not layers:
+                bb.fatal("The bblayers.conf file doesn't contain any BBLAYERS definition")
+
             data = bb.data.createCopy(data)
             approved = bb.utils.approved_variables()
 
@@ -399,6 +409,8 @@ class CookerDataBuilder(object):
                 if c in collections_tmp:
                     bb.fatal("Found duplicated BBFILE_COLLECTIONS '%s', check bblayers.conf or layer.conf to fix it." % c)
                 compat = set((data.getVar("LAYERSERIES_COMPAT_%s" % c) or "").split())
+                if compat and not layerseries:
+                    bb.fatal("No core layer found to work with layer '%s'. Missing entry in bblayers.conf?" % c)
                 if compat and not (compat & layerseries):
                     bb.fatal("Layer %s is not compatible with the core layer which only supports these series: %s (layer is compatible with %s)"
                               % (c, " ".join(layerseries), " ".join(compat)))

bitbake/lib/bb/data_smart.py

@@ -17,7 +17,7 @@ BitBake build tools.
 # Based on functions from the base bb module, Copyright 2003 Holger Schurig
 
 import copy, re, sys, traceback
-from collections import MutableMapping
+from collections.abc import MutableMapping
 import logging
 import hashlib
 import bb, bb.codeparser
@@ -28,7 +28,7 @@ logger = logging.getLogger("BitBake.Data")
 
 __setvar_keyword__ = ["_append", "_prepend", "_remove"]
 __setvar_regexp__ = re.compile(r'(?P<base>.*?)(?P<keyword>_append|_prepend|_remove)(_(?P<add>[^A-Z]*))?$')
-__expand_var_regexp__ = re.compile(r"\${[a-zA-Z0-9\-_+./~]+?}")
+__expand_var_regexp__ = re.compile(r"\${[a-zA-Z0-9\-_+./~:]+?}")
 __expand_python_regexp__ = re.compile(r"\${@.+?}")
 __whitespace_split__ = re.compile(r'(\s)')
 __override_regexp__ = re.compile(r'[a-z0-9]+')
@@ -403,7 +403,7 @@ class DataSmart(MutableMapping):
                     s = __expand_python_regexp__.sub(varparse.python_sub, s)
                 except SyntaxError as e:
                     # Likely unmatched brackets, just don't expand the expression
-                    if e.msg != "EOL while scanning string literal":
+                    if e.msg != "EOL while scanning string literal" and not e.msg.startswith("unterminated string literal"):
                         raise
                 if s == olds:
                     break
@@ -411,6 +411,8 @@ class DataSmart(MutableMapping):
                 raise
             except bb.parse.SkipRecipe:
                 raise
+            except bb.BBHandledException:
+                raise
             except Exception as exc:
                 tb = sys.exc_info()[2]
                 raise ExpansionError(varname, s, exc).with_traceback(tb) from exc
@@ -481,6 +483,7 @@ class DataSmart(MutableMapping):
 
     def setVar(self, var, value, **loginfo):
         #print("var=" + str(var) + "  val=" + str(value))
+        var = var.replace(":", "_")
         self.expand_cache = {}
         parsing=False
         if 'parsing' in loginfo:
@@ -589,6 +592,8 @@ class DataSmart(MutableMapping):
         """
         Rename the variable key to newkey
         """
+        key = key.replace(":", "_")
+        newkey = newkey.replace(":", "_")
         if key == newkey:
             bb.warn("Calling renameVar with equivalent keys (%s) is invalid" % key)
             return
@@ -637,6 +642,7 @@ class DataSmart(MutableMapping):
         self.setVar(var + "_prepend", value, ignore=True, parsing=True)
 
     def delVar(self, var, **loginfo):
+        var = var.replace(":", "_")
         self.expand_cache = {}
 
         loginfo['detail'] = ""
@@ -664,6 +670,7 @@ class DataSmart(MutableMapping):
                          override = None
 
     def setVarFlag(self, var, flag, value, **loginfo):
+        var = var.replace(":", "_")
         self.expand_cache = {}
 
         if 'op' not in loginfo:
@@ -687,6 +694,7 @@ class DataSmart(MutableMapping):
             self.dict["__exportlist"]["_content"].add(var)
 
     def getVarFlag(self, var, flag, expand=True, noweakdefault=False, parsing=False, retparser=False):
+        var = var.replace(":", "_")
         if flag == "_content":
             cachename = var
         else:
@@ -814,6 +822,7 @@ class DataSmart(MutableMapping):
         return value
 
     def delVarFlag(self, var, flag, **loginfo):
+        var = var.replace(":", "_")
         self.expand_cache = {}
 
         local_var, _ = self._findVar(var)
@@ -831,6 +840,7 @@ class DataSmart(MutableMapping):
             del self.dict[var][flag]
 
     def appendVarFlag(self, var, flag, value, **loginfo):
+        var = var.replace(":", "_")
         loginfo['op'] = 'append'
         loginfo['flag'] = flag
         self.varhistory.record(**loginfo)
@@ -838,6 +848,7 @@ class DataSmart(MutableMapping):
         self.setVarFlag(var, flag, newvalue, ignore=True)
 
     def prependVarFlag(self, var, flag, value, **loginfo):
+        var = var.replace(":", "_")
         loginfo['op'] = 'prepend'
         loginfo['flag'] = flag
         self.varhistory.record(**loginfo)
@@ -845,6 +856,7 @@ class DataSmart(MutableMapping):
         self.setVarFlag(var, flag, newvalue, ignore=True)
 
     def setVarFlags(self, var, flags, **loginfo):
+        var = var.replace(":", "_")
         self.expand_cache = {}
         infer_caller_details(loginfo)
         if not var in self.dict:
@@ -859,6 +871,7 @@ class DataSmart(MutableMapping):
             self.dict[var][i] = flags[i]
 
     def getVarFlags(self, var, expand = False, internalflags=False):
+        var = var.replace(":", "_")
         local_var, _ = self._findVar(var)
         flags = {}
 
@@ -875,6 +888,7 @@ class DataSmart(MutableMapping):
 
 
     def delVarFlags(self, var, **loginfo):
+        var = var.replace(":", "_")
         self.expand_cache = {}
         if not var in self.dict:
             self._makeShadowCopy(var)
@@ -1005,7 +1019,7 @@ class DataSmart(MutableMapping):
             else:
                 data.update({key:value})
 
-            varflags = d.getVarFlags(key, internalflags = True)
+            varflags = d.getVarFlags(key, internalflags = True, expand=["vardepvalue"])
             if not varflags:
                 continue
             for f in varflags:

bitbake/lib/bb/event.py

@@ -10,17 +10,17 @@ BitBake build tools.
 # SPDX-License-Identifier: GPL-2.0-only
 #
 
-import sys
-import pickle
-import logging
-import atexit
-import traceback
 import ast
+import atexit
+import collections
+import logging
+import pickle
+import sys
 import threading
+import traceback
 
-import bb.utils
-import bb.compat
 import bb.exceptions
+import bb.utils
 
 # This is the pid for which we should generate the event. This is set when
 # the runqueue forks off.
@@ -56,7 +56,7 @@ def set_class_handlers(h):
     _handlers = h
 
 def clean_class_handlers():
-    return bb.compat.OrderedDict()
+    return collections.OrderedDict()
 
 # Internal
 _handlers = clean_class_handlers()

bitbake/lib/bb/fetch2/__init__.py

@@ -562,6 +562,9 @@ def verify_checksum(ud, d, precomputed={}):
 
         checksum_expected = getattr(ud, "%s_expected" % checksum_id)
 
+        if checksum_expected == '':
+            checksum_expected = None
+
         return {
             "id": checksum_id,
             "name": checksum_name,
@@ -612,7 +615,7 @@ def verify_checksum(ud, d, precomputed={}):
 
     for ci in checksum_infos:
         if ci["expected"] and ci["expected"] != ci["data"]:
-            messages.append("File: '%s' has %s checksum %s when %s was " \
+            messages.append("File: '%s' has %s checksum '%s' when '%s' was " \
                             "expected" % (ud.localpath, ci["id"], ci["data"], ci["expected"]))
             bad_checksum = ci["data"]
 
@@ -853,11 +856,6 @@ def runfetchcmd(cmd, d, quiet=False, cleanup=None, log=None, workdir=None):
         if val:
             cmd = 'export ' + var + '=\"%s\"; %s' % (val, cmd)
 
-    # Ensure that a _PYTHON_SYSCONFIGDATA_NAME value set by a recipe
-    # (for example via python3native.bbclass since warrior) is not set for
-    # host Python (otherwise tools like git-make-shallow will fail)
-    cmd = 'unset _PYTHON_SYSCONFIGDATA_NAME; ' + cmd
-
     # Disable pseudo as it may affect ssh, potentially causing it to hang.
     cmd = 'export PSEUDO_DISABLED=1; ' + cmd
 

bitbake/lib/bb/fetch2/git.py

@@ -67,6 +67,7 @@ import subprocess
 import tempfile
 import bb
 import bb.progress
+from contextlib import contextmanager
 from   bb.fetch2 import FetchMethod
 from   bb.fetch2 import runfetchcmd
 from   bb.fetch2 import logger
@@ -140,6 +141,10 @@ class Git(FetchMethod):
             ud.proto = 'file'
         else:
             ud.proto = "git"
+        if ud.host == "github.com" and ud.proto == "git":
+            # github stopped supporting git protocol
+            # https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git
+            ud.proto = "https"
 
         if not ud.proto in ('git', 'file', 'ssh', 'http', 'https', 'rsync'):
             raise bb.fetch2.ParameterError("Invalid protocol type", ud.url)
@@ -236,7 +241,7 @@ class Git(FetchMethod):
                     ud.unresolvedrev[name] = ud.revisions[name]
                 ud.revisions[name] = self.latest_revision(ud, d, name)
 
-        gitsrcname = '%s%s' % (ud.host.replace(':', '.'), ud.path.replace('/', '.').replace('*', '.'))
+        gitsrcname = '%s%s' % (ud.host.replace(':', '.'), ud.path.replace('/', '.').replace('*', '.').replace(' ','_'))
         if gitsrcname.startswith('.'):
             gitsrcname = gitsrcname[1:]
 
@@ -342,7 +347,7 @@ class Git(FetchMethod):
             # We do this since git will use a "-l" option automatically for local urls where possible
             if repourl.startswith("file://"):
                 repourl = repourl[7:]
-            clone_cmd = "LANG=C %s clone --bare --mirror %s %s --progress" % (ud.basecmd, repourl, ud.clonedir)
+            clone_cmd = "LANG=C %s clone --bare --mirror \"%s\" %s --progress" % (ud.basecmd, repourl, ud.clonedir)
             if ud.proto.lower() != 'file':
                 bb.fetch2.check_network_access(d, clone_cmd, ud.url)
             progresshandler = GitProgressHandler(d)
@@ -354,8 +359,8 @@ class Git(FetchMethod):
             if "origin" in output:
               runfetchcmd("%s remote rm origin" % ud.basecmd, d, workdir=ud.clonedir)
 
-            runfetchcmd("%s remote add --mirror=fetch origin %s" % (ud.basecmd, repourl), d, workdir=ud.clonedir)
-            fetch_cmd = "LANG=C %s fetch -f --progress %s refs/*:refs/*" % (ud.basecmd, repourl)
+            runfetchcmd("%s remote add --mirror=fetch origin \"%s\"" % (ud.basecmd, repourl), d, workdir=ud.clonedir)
+            fetch_cmd = "LANG=C %s fetch -f --progress \"%s\" refs/*:refs/*" % (ud.basecmd, repourl)
             if ud.proto.lower() != 'file':
                 bb.fetch2.check_network_access(d, fetch_cmd, ud.url)
             progresshandler = GitProgressHandler(d)
@@ -378,7 +383,50 @@ class Git(FetchMethod):
             if missing_rev:
                 raise bb.fetch2.FetchError("Unable to find revision %s even from upstream" % missing_rev)
 
+        if self._contains_lfs(ud, d, ud.clonedir) and self._need_lfs(ud):
+            # Unpack temporary working copy, use it to run 'git checkout' to force pre-fetching
+            # of all LFS blobs needed at the the srcrev.
+            #
+            # It would be nice to just do this inline here by running 'git-lfs fetch'
+            # on the bare clonedir, but that operation requires a working copy on some
+            # releases of Git LFS.
+            tmpdir = tempfile.mkdtemp(dir=d.getVar('DL_DIR'))
+            try:
+                # Do the checkout. This implicitly involves a Git LFS fetch.
+                Git.unpack(self, ud, tmpdir, d)
+
+                # Scoop up a copy of any stuff that Git LFS downloaded. Merge them into
+                # the bare clonedir.
+                #
+                # As this procedure is invoked repeatedly on incremental fetches as
+                # a recipe's SRCREV is bumped throughout its lifetime, this will
+                # result in a gradual accumulation of LFS blobs in <ud.clonedir>/lfs
+                # corresponding to all the blobs reachable from the different revs
+                # fetched across time.
+                #
+                # Only do this if the unpack resulted in a .git/lfs directory being
+                # created; this only happens if at least one blob needed to be
+                # downloaded.
+                if os.path.exists(os.path.join(tmpdir, "git", ".git", "lfs")):
+                    runfetchcmd("tar -cf - lfs | tar -xf - -C %s" % ud.clonedir, d, workdir="%s/git/.git" % tmpdir)
+            finally:
+                bb.utils.remove(tmpdir, recurse=True)
+
     def build_mirror_data(self, ud, d):
+
+        # Create as a temp file and move atomically into position to avoid races
+        @contextmanager
+        def create_atomic(filename):
+            fd, tfile = tempfile.mkstemp(dir=os.path.dirname(filename))
+            try:
+                yield tfile
+                umask = os.umask(0o666)
+                os.umask(umask)
+                os.chmod(tfile, (0o666 & ~umask))
+                os.rename(tfile, filename)
+            finally:
+                os.close(fd)
+
         if ud.shallow and ud.write_shallow_tarballs:
             if not os.path.exists(ud.fullshallow):
                 if os.path.islink(ud.fullshallow):
@@ -389,7 +437,8 @@ class Git(FetchMethod):
                     self.clone_shallow_local(ud, shallowclone, d)
 
                     logger.info("Creating tarball of git repository")
-                    runfetchcmd("tar -czf %s ." % ud.fullshallow, d, workdir=shallowclone)
+                    with create_atomic(ud.fullshallow) as tfile:
+                        runfetchcmd("tar -czf %s ." % tfile, d, workdir=shallowclone)
                     runfetchcmd("touch %s.done" % ud.fullshallow, d)
                 finally:
                     bb.utils.remove(tempdir, recurse=True)
@@ -398,7 +447,8 @@ class Git(FetchMethod):
                 os.unlink(ud.fullmirror)
 
             logger.info("Creating tarball of git repository")
-            runfetchcmd("tar -czf %s ." % ud.fullmirror, d, workdir=ud.clonedir)
+            with create_atomic(ud.fullmirror) as tfile:
+                runfetchcmd("tar -czf %s ." % tfile, d, workdir=ud.clonedir)
             runfetchcmd("touch %s.done" % ud.fullmirror, d)
 
     def clone_shallow_local(self, ud, dest, d):
@@ -473,7 +523,10 @@ class Git(FetchMethod):
         if os.path.exists(destdir):
             bb.utils.prunedir(destdir)
 
-        need_lfs = ud.parm.get("lfs", "1") == "1"
+        need_lfs = self._need_lfs(ud)
+
+        if not need_lfs:
+            ud.basecmd = "GIT_LFS_SKIP_SMUDGE=1 " + ud.basecmd
 
         source_found = False
         source_error = []
@@ -501,12 +554,12 @@ class Git(FetchMethod):
             raise bb.fetch2.UnpackError("No up to date source found: " + "; ".join(source_error), ud.url)
 
         repourl = self._get_repo_url(ud)
-        runfetchcmd("%s remote set-url origin %s" % (ud.basecmd, repourl), d, workdir=destdir)
+        runfetchcmd("%s remote set-url origin \"%s\"" % (ud.basecmd, repourl), d, workdir=destdir)
 
         if self._contains_lfs(ud, d, destdir):
             if need_lfs and not self._find_git_lfs(d):
                 raise bb.fetch2.FetchError("Repository %s has LFS content, install git-lfs on host to download (or set lfs=0 to ignore it)" % (repourl))
-            else:
+            elif not need_lfs:
                 bb.note("Repository %s has LFS content but it is not being fetched" % (repourl))
 
         if not ud.nocheckout:
@@ -559,12 +612,28 @@ class Git(FetchMethod):
             raise bb.fetch2.FetchError("The command '%s' gave output with more then 1 line unexpectedly, output: '%s'" % (cmd, output))
         return output.split()[0] != "0"
 
+    def _need_lfs(self, ud):
+        return ud.parm.get("lfs", "1") == "1"
+
     def _contains_lfs(self, ud, d, wd):
         """
         Check if the repository has 'lfs' (large file) content
         """
-        cmd = "%s grep lfs HEAD:.gitattributes | wc -l" % (
-                ud.basecmd)
+
+        if not ud.nobranch:
+            branchname = ud.branches[ud.names[0]]
+        else:
+            branchname = "master"
+
+        # The bare clonedir doesn't use the remote names; it has the branch immediately.
+        if wd == ud.clonedir:
+            refname = ud.branches[ud.names[0]]
+        else:
+            refname = "origin/%s" % ud.branches[ud.names[0]]
+
+        cmd = "%s grep lfs %s:.gitattributes | wc -l" % (
+            ud.basecmd, refname)
+
         try:
             output = runfetchcmd(cmd, d, quiet=True, workdir=wd)
             if int(output) > 0:
@@ -613,7 +682,7 @@ class Git(FetchMethod):
         d.setVar('_BB_GIT_IN_LSREMOTE', '1')
         try:
             repourl = self._get_repo_url(ud)
-            cmd = "%s ls-remote %s %s" % \
+            cmd = "%s ls-remote \"%s\" %s" % \
                 (ud.basecmd, repourl, search)
             if ud.proto.lower() != 'file':
                 bb.fetch2.check_network_access(d, cmd, repourl)

bitbake/lib/bb/fetch2/wget.py

@@ -319,7 +319,7 @@ class Wget(FetchMethod):
             except (TypeError, ImportError, IOError, netrc.NetrcParseError):
                 pass
 
-            with opener.open(r) as response:
+            with opener.open(r, timeout=30) as response:
                 pass
         except urllib.error.URLError as e:
             if try_again:

bitbake/lib/bb/msg.py

@@ -146,18 +146,12 @@ class LogFilterLTLevel(logging.Filter):
 #
 
 loggerDefaultLogLevel = BBLogFormatter.NOTE
-loggerDefaultVerbose = False
-loggerVerboseLogs = False
 loggerDefaultDomains = {}
 
 def init_msgconfig(verbose, debug, debug_domains=None):
     """
     Set default verbosity and debug levels config the logger
     """
-    bb.msg.loggerDefaultVerbose = verbose
-    if verbose:
-        bb.msg.loggerVerboseLogs = True
-
     if debug:
         bb.msg.loggerDefaultLogLevel = BBLogFormatter.DEBUG - debug + 1
     elif verbose:

bitbake/lib/bb/parse/ast.py

@@ -97,6 +97,7 @@ class DataNode(AstNode):
     def eval(self, data):
         groupd = self.groupd
         key = groupd["var"]
+        key = key.replace(":", "_")
         loginfo = {
             'variable': key,
             'file': self.filename,
@@ -207,6 +208,7 @@ class ExportFuncsNode(AstNode):
     def eval(self, data):
 
         for func in self.n:
+            func = func.replace(":", "_")
             calledfunc = self.classname + "_" + func
 
             if data.getVar(func, False) and not data.getVarFlag(func, 'export_func', False):

bitbake/lib/bb/parse/parse_py/BBHandler.py

@@ -22,7 +22,7 @@ from .ConfHandler import include, init
 # For compatibility
 bb.deprecate_import(__name__, "bb.parse", ["vars_from_file"])
 
-__func_start_regexp__    = re.compile(r"(((?P<py>python)|(?P<fr>fakeroot))\s*)*(?P<func>[\w\.\-\+\{\}\$]+)?\s*\(\s*\)\s*{$" )
+__func_start_regexp__    = re.compile(r"(((?P<py>python(?=(\s|\()))|(?P<fr>fakeroot(?=\s)))\s*)*(?P<func>[\w\.\-\+\{\}\$:]+)?\s*\(\s*\)\s*{$" )
 __inherit_regexp__       = re.compile(r"inherit\s+(.+)" )
 __export_func_regexp__   = re.compile(r"EXPORT_FUNCTIONS\s+(.+)" )
 __addtask_regexp__       = re.compile(r"addtask\s+(?P<func>\w+)\s*((before\s*(?P<before>((.*(?=after))|(.*))))|(after\s*(?P<after>((.*(?=before))|(.*)))))*")

bitbake/lib/bb/parse/parse_py/ConfHandler.py

@@ -20,7 +20,7 @@ from bb.parse import ParseError, resolve_file, ast, logger, handle
 __config_regexp__  = re.compile( r"""
     ^
     (?P<exp>export\s+)?
-    (?P<var>[a-zA-Z0-9\-_+.${}/~]+?)
+    (?P<var>[a-zA-Z0-9\-_+.${}/~:]+?)
     (\[(?P<flag>[a-zA-Z0-9\-_+.]+)\])?
 
     \s* (

bitbake/lib/bb/persist_data.py

@@ -12,14 +12,15 @@ currently, providing a key/value store accessed by 'domain'.
 #
 
 import collections
+import collections.abc
+import contextlib
+import functools
 import logging
 import os.path
+import sqlite3
 import sys
 import warnings
-from bb.compat import total_ordering
-from collections import Mapping
-import sqlite3
-import contextlib
+from collections.abc import Mapping
 
 sqlversion = sqlite3.sqlite_version_info
 if sqlversion[0] < 3 or (sqlversion[0] == 3 and sqlversion[1] < 3):
@@ -28,8 +29,8 @@ if sqlversion[0] < 3 or (sqlversion[0] == 3 and sqlversion[1] < 3):
 
 logger = logging.getLogger("BitBake.PersistData")
 
-@total_ordering
-class SQLTable(collections.MutableMapping):
+@functools.total_ordering
+class SQLTable(collections.abc.MutableMapping):
     class _Decorators(object):
         @staticmethod
         def retry(*, reconnect=True):

bitbake/lib/bb/process.py

@@ -179,5 +179,8 @@ def run(cmd, input=None, log=None, extrafiles=None, **options):
             stderr = stderr.decode("utf-8")
 
     if pipe.returncode != 0:
+        if log:
+            # Don't duplicate the output in the exception if logging it
+            raise ExecutionError(cmd, pipe.returncode, None, None)
         raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
     return stdout, stderr

bitbake/lib/bb/providers.py

@@ -151,7 +151,7 @@ def findPreferredProvider(pn, cfgData, dataCache, pkg_pn = None, item = None):
         if item:
             itemstr = " (for item %s)" % item
         if preferred_file is None:
-            logger.info("preferred version %s of %s not available%s", pv_str, pn, itemstr)
+            logger.warning("preferred version %s of %s not available%s", pv_str, pn, itemstr)
             available_vers = []
             for file_set in pkg_pn:
                 for f in file_set:
@@ -163,7 +163,7 @@ def findPreferredProvider(pn, cfgData, dataCache, pkg_pn = None, item = None):
                         available_vers.append(ver_str)
             if available_vers:
                 available_vers.sort()
-                logger.info("versions of %s available: %s", pn, ' '.join(available_vers))
+                logger.warning("versions of %s available: %s", pn, ' '.join(available_vers))
         else:
             logger.debug(1, "selecting %s as PREFERRED_VERSION %s of package %s%s", preferred_file, pv_str, pn, itemstr)
 

bitbake/lib/bb/runqueue.py

@@ -1256,8 +1256,8 @@ class RunQueue:
             "fakerootnoenv" : self.rqdata.dataCaches[mc].fakerootnoenv,
             "sigdata" : bb.parse.siggen.get_taskdata(),
             "logdefaultlevel" : bb.msg.loggerDefaultLogLevel,
-            "logdefaultverbose" : bb.msg.loggerDefaultVerbose,
-            "logdefaultverboselogs" : bb.msg.loggerVerboseLogs,
+            "build_verbose_shell" : self.cooker.configuration.build_verbose_shell,
+            "build_verbose_stdout" : self.cooker.configuration.build_verbose_stdout,
             "logdefaultdomain" : bb.msg.loggerDefaultDomains,
             "prhost" : self.cooker.prhost,
             "buildname" : self.cfgData.getVar("BUILDNAME"),
@@ -1934,6 +1934,10 @@ class RunQueueExecute:
             logger.error("Scenequeue had holdoff tasks: %s" % pprint.pformat(self.holdoff_tasks))
             err = True
 
+        for tid in self.scenequeue_covered.intersection(self.scenequeue_notcovered):
+            # No task should end up in both covered and uncovered, that is a bug.
+            logger.error("Setscene task %s in both covered and notcovered." % tid)
+
         for tid in self.rqdata.runq_setscene_tids:
             if tid not in self.scenequeue_covered and tid not in self.scenequeue_notcovered:
                 err = True
@@ -2421,6 +2425,9 @@ class RunQueueExecute:
 
         for dep in sorted(self.sqdata.sq_deps[task]):
             if fail and task in self.sqdata.sq_harddeps and dep in self.sqdata.sq_harddeps[task]:
+                if dep in self.scenequeue_covered or dep in self.scenequeue_notcovered:
+                    # dependency could be already processed, e.g. noexec setscene task
+                    continue
                 logger.debug(2, "%s was unavailable and is a hard dependency of %s so skipping" % (task, dep))
                 self.sq_task_failoutright(dep)
                 continue
@@ -2782,6 +2789,7 @@ def update_scenequeue_data(tids, sqdata, rqdata, rq, cooker, stampcache, sqrq, s
     sqdata.valid |= rq.validate_hashes(tocheck, cooker.data, len(sqdata.stamppresent), False, summary=summary)
 
     sqdata.hashes = {}
+    sqrq.sq_deferred = {}
     for mc in sorted(sqdata.multiconfigs):
         for tid in sorted(sqdata.sq_revdeps):
             if mc_from_tid(tid) != mc:
@@ -2794,6 +2802,9 @@ def update_scenequeue_data(tids, sqdata, rqdata, rq, cooker, stampcache, sqrq, s
                 continue
             if tid in sqrq.scenequeue_notcovered:
                 continue
+            if tid in sqrq.scenequeue_covered:
+                continue
+
             sqdata.outrightfail.add(tid)
 
             h = pending_hash_index(tid, rqdata)

bitbake/lib/bb/server/process.py

@@ -25,6 +25,7 @@ import subprocess
 import errno
 import re
 import datetime
+import gc
 import bb.server.xmlrpcserver
 from bb import daemonize
 from multiprocessing import queues
@@ -152,7 +153,8 @@ class ProcessServer(multiprocessing.Process):
                 conn = newconnections.pop(-1)
                 fds.append(conn)
                 self.controllersock = conn
-            elif self.timeout is None and not ready:
+
+            elif not self.timeout and not ready:
                 print("No timeout, exiting.")
                 self.quit = True
 
@@ -220,6 +222,7 @@ class ProcessServer(multiprocessing.Process):
                 try:
                     print("Running command %s" % command)
                     self.command_channel_reply.send(self.cooker.command.runCommand(command))
+                    print("Command Completed")
                 except Exception as e:
                    logger.exception('Exception in server main event loop running command %s (%s)' % (command, str(e)))
 
@@ -347,7 +350,12 @@ class ServerCommunicator():
             logger.info("No reply from server in 30s")
             if not self.recv.poll(30):
                 raise ProcessTimeout("Timeout while waiting for a reply from the bitbake server (60s)")
-        return self.recv.get()
+        ret, exc = self.recv.get()
+        # Should probably turn all exceptions in exc back into exceptions?
+        # For now, at least handle BBHandledException
+        if exc and "BBHandledException" in exc:
+            raise bb.BBHandledException()
+        return ret, exc
 
     def updateFeatureSet(self, featureset):
         _, error = self.runCommand(["setFeatures", featureset])
@@ -586,7 +594,7 @@ class BBUIEventQueue:
         self.reader = ConnectionReader(readfd)
 
         self.t = threading.Thread()
-        self.t.setDaemon(True)
+        self.t.daemon = True
         self.t.run = self.startCallbackHandler
         self.t.start()
 
@@ -664,8 +672,10 @@ class ConnectionWriter(object):
 
     def send(self, obj):
         obj = multiprocessing.reduction.ForkingPickler.dumps(obj)
+        gc.disable()
         with self.wlock:
             self.writer.send_bytes(obj)
+        gc.enable()
 
     def fileno(self):
         return self.writer.fileno()

bitbake/lib/bb/tests/codeparser.py

@@ -111,9 +111,9 @@ ${D}${libdir}/pkgconfig/*.pc
         self.assertExecs(set(["sed"]))
 
     def test_parameter_expansion_modifiers(self):
-        # - and + are also valid modifiers for parameter expansion, but are
+        # -,+ and : are also valid modifiers for parameter expansion, but are
         # valid characters in bitbake variable names, so are not included here
-        for i in ('=', ':-', ':=', '?', ':?', ':+', '#', '%', '##', '%%'):
+        for i in ('=', '?', '#', '%', '##', '%%'):
             name = "foo%sbar" % i
             self.parseExpression("${%s}" % name)
             self.assertNotIn(name, self.references)

bitbake/lib/bb/tests/event.py

@@ -6,17 +6,18 @@
 # SPDX-License-Identifier: GPL-2.0-only
 #
 
-import unittest
-import bb
-import logging
-import bb.compat
-import bb.event
+import collections
 import importlib
+import logging
+import pickle
 import threading
 import time
-import pickle
+import unittest
 from unittest.mock import Mock
 from unittest.mock import call
+
+import bb
+import bb.event
 from bb.msg import BBLogFormatter
 
 
@@ -75,7 +76,7 @@ class EventHandlingTest(unittest.TestCase):
 
     def _create_test_handlers(self):
         """ Method used to create a test handler ordered dictionary """
-        test_handlers = bb.compat.OrderedDict()
+        test_handlers = collections.OrderedDict()
         test_handlers["handler1"] = self._test_process.handler1
         test_handlers["handler2"] = self._test_process.handler2
         return test_handlers
@@ -96,7 +97,7 @@ class EventHandlingTest(unittest.TestCase):
 
     def test_clean_class_handlers(self):
         """ Test clean_class_handlers method """
-        cleanDict = bb.compat.OrderedDict()
+        cleanDict = collections.OrderedDict()
         self.assertEqual(cleanDict,
                          bb.event.clean_class_handlers())
 

bitbake/lib/bb/tests/fetch.py

@@ -223,6 +223,21 @@ class URITest(unittest.TestCase):
             'query': {},
             'relative': False
         },
+        "git://tfs-example.org:22/tfs/example%20path/example.git": {
+            'uri': 'git://tfs-example.org:22/tfs/example%20path/example.git',
+            'scheme': 'git',
+            'hostname': 'tfs-example.org',
+            'port': 22,
+            'hostport': 'tfs-example.org:22',
+            'path': '/tfs/example path/example.git',
+            'userinfo': '',
+            'userinfo': '',
+            'username': '',
+            'password': '',
+            'params': {},
+            'query': {},
+            'relative': False
+        },
         "http://somesite.net;someparam=1": {
             'uri': 'http://somesite.net;someparam=1',
             'scheme': 'http',
@@ -356,6 +371,7 @@ class FetcherTest(unittest.TestCase):
         if os.environ.get("BB_TMPDIR_NOCLEAN") == "yes":
             print("Not cleaning up %s. Please remove manually." % self.tempdir)
         else:
+            bb.process.run('chmod u+rw -R %s' % self.tempdir)
             bb.utils.prunedir(self.tempdir)
 
 class MirrorUriTest(FetcherTest):
@@ -456,7 +472,7 @@ class GitDownloadDirectoryNamingTest(FetcherTest):
         super(GitDownloadDirectoryNamingTest, self).setUp()
         self.recipe_url = "git://git.openembedded.org/bitbake"
         self.recipe_dir = "git.openembedded.org.bitbake"
-        self.mirror_url = "git://github.com/openembedded/bitbake.git"
+        self.mirror_url = "git://github.com/openembedded/bitbake.git;protocol=https"
         self.mirror_dir = "github.com.openembedded.bitbake.git"
 
         self.d.setVar('SRCREV', '82ea737a0b42a8b53e11c9cde141e9e9c0bd8c40')
@@ -504,7 +520,7 @@ class TarballNamingTest(FetcherTest):
         super(TarballNamingTest, self).setUp()
         self.recipe_url = "git://git.openembedded.org/bitbake"
         self.recipe_tarball = "git2_git.openembedded.org.bitbake.tar.gz"
-        self.mirror_url = "git://github.com/openembedded/bitbake.git"
+        self.mirror_url = "git://github.com/openembedded/bitbake.git;protocol=https"
         self.mirror_tarball = "git2_github.com.openembedded.bitbake.git.tar.gz"
 
         self.d.setVar('BB_GENERATE_MIRROR_TARBALLS', '1')
@@ -538,7 +554,7 @@ class GitShallowTarballNamingTest(FetcherTest):
         super(GitShallowTarballNamingTest, self).setUp()
         self.recipe_url = "git://git.openembedded.org/bitbake"
         self.recipe_tarball = "gitshallow_git.openembedded.org.bitbake_82ea737-1_master.tar.gz"
-        self.mirror_url = "git://github.com/openembedded/bitbake.git"
+        self.mirror_url = "git://github.com/openembedded/bitbake.git;protocol=https"
         self.mirror_tarball = "gitshallow_github.com.openembedded.bitbake.git_82ea737-1_master.tar.gz"
 
         self.d.setVar('BB_GIT_SHALLOW', '1')
@@ -830,6 +846,8 @@ class FetcherNetworkTest(FetcherTest):
                                    prefix='gitfetch_localusehead_')
         src_dir = os.path.abspath(src_dir)
         bb.process.run("git init", cwd=src_dir)
+        bb.process.run("git config user.email 'you@example.com'", cwd=src_dir)
+        bb.process.run("git config user.name 'Your Name'", cwd=src_dir)
         bb.process.run("git commit --allow-empty -m'Dummy commit'",
                        cwd=src_dir)
         # Use other branch than master
@@ -903,7 +921,7 @@ class FetcherNetworkTest(FetcherTest):
     def test_git_submodule_dbus_broker(self):
         # The following external repositories have show failures in fetch and unpack operations
         # We want to avoid regressions!
-        url = "gitsm://github.com/bus1/dbus-broker;protocol=git;rev=fc874afa0992d0c75ec25acb43d344679f0ee7d2"
+        url = "gitsm://github.com/bus1/dbus-broker;protocol=https;rev=fc874afa0992d0c75ec25acb43d344679f0ee7d2;branch=main"
         fetcher = bb.fetch.Fetch([url], self.d)
         fetcher.download()
         # Previous cwd has been deleted
@@ -919,7 +937,7 @@ class FetcherNetworkTest(FetcherTest):
 
     @skipIfNoNetwork()
     def test_git_submodule_CLI11(self):
-        url = "gitsm://github.com/CLIUtils/CLI11;protocol=git;rev=bd4dc911847d0cde7a6b41dfa626a85aab213baf"
+        url = "gitsm://github.com/CLIUtils/CLI11;protocol=https;rev=bd4dc911847d0cde7a6b41dfa626a85aab213baf;branch=main"
         fetcher = bb.fetch.Fetch([url], self.d)
         fetcher.download()
         # Previous cwd has been deleted
@@ -934,12 +952,12 @@ class FetcherNetworkTest(FetcherTest):
     @skipIfNoNetwork()
     def test_git_submodule_update_CLI11(self):
         """ Prevent regression on update detection not finding missing submodule, or modules without needed commits """
-        url = "gitsm://github.com/CLIUtils/CLI11;protocol=git;rev=cf6a99fa69aaefe477cc52e3ef4a7d2d7fa40714"
+        url = "gitsm://github.com/CLIUtils/CLI11;protocol=https;rev=cf6a99fa69aaefe477cc52e3ef4a7d2d7fa40714;branch=main"
         fetcher = bb.fetch.Fetch([url], self.d)
         fetcher.download()
 
         # CLI11 that pulls in a newer nlohmann-json
-        url = "gitsm://github.com/CLIUtils/CLI11;protocol=git;rev=49ac989a9527ee9bb496de9ded7b4872c2e0e5ca"
+        url = "gitsm://github.com/CLIUtils/CLI11;protocol=https;rev=49ac989a9527ee9bb496de9ded7b4872c2e0e5ca;branch=main"
         fetcher = bb.fetch.Fetch([url], self.d)
         fetcher.download()
         # Previous cwd has been deleted
@@ -953,7 +971,7 @@ class FetcherNetworkTest(FetcherTest):
 
     @skipIfNoNetwork()
     def test_git_submodule_aktualizr(self):
-        url = "gitsm://github.com/advancedtelematic/aktualizr;branch=master;protocol=git;rev=d00d1a04cc2366d1a5f143b84b9f507f8bd32c44"
+        url = "gitsm://github.com/advancedtelematic/aktualizr;branch=master;protocol=https;rev=d00d1a04cc2366d1a5f143b84b9f507f8bd32c44"
         fetcher = bb.fetch.Fetch([url], self.d)
         fetcher.download()
         # Previous cwd has been deleted
@@ -973,7 +991,7 @@ class FetcherNetworkTest(FetcherTest):
         """ Prevent regression on deeply nested submodules not being checked out properly, even though they were fetched. """
 
         # This repository also has submodules where the module (name), path and url do not align
-        url = "gitsm://github.com/azure/iotedge.git;protocol=git;rev=d76e0316c6f324345d77c48a83ce836d09392699"
+        url = "gitsm://github.com/azure/iotedge.git;protocol=https;rev=d76e0316c6f324345d77c48a83ce836d09392699;branch=main"
         fetcher = bb.fetch.Fetch([url], self.d)
         fetcher.download()
         # Previous cwd has been deleted
@@ -1031,7 +1049,7 @@ class SVNTest(FetcherTest):
 
         bb.process.run("svn co %s svnfetch_co" % self.repo_url, cwd=self.tempdir)
         # Github will emulate SVN.  Use this to check if we're downloding...
-        bb.process.run("svn propset svn:externals 'bitbake svn://vcs.pcre.org/pcre2/code' .",
+        bb.process.run("svn propset svn:externals 'bitbake https://github.com/PhilipHazel/pcre2.git' .",
                        cwd=os.path.join(self.tempdir, 'svnfetch_co', 'trunk'))
         bb.process.run("svn commit --non-interactive -m 'Add external'",
                        cwd=os.path.join(self.tempdir, 'svnfetch_co', 'trunk'))
@@ -1149,7 +1167,7 @@ class FetchLatestVersionTest(FetcherTest):
 
     test_git_uris = {
         # version pattern "X.Y.Z"
-        ("mx-1.0", "git://github.com/clutter-project/mx.git;branch=mx-1.4", "9b1db6b8060bd00b121a692f942404a24ae2960f", "")
+        ("mx-1.0", "git://github.com/clutter-project/mx.git;branch=mx-1.4;protocol=https", "9b1db6b8060bd00b121a692f942404a24ae2960f", "")
             : "1.99.4",
         # version pattern "vX.Y"
         # mirror of git.infradead.org since network issues interfered with testing
@@ -1160,7 +1178,7 @@ class FetchLatestVersionTest(FetcherTest):
         ("presentproto", "git://git.yoctoproject.org/bbfetchtests-presentproto", "24f3a56e541b0a9e6c6ee76081f441221a120ef9", "")
             : "1.0",
         # version pattern "pkg_name-vX.Y.Z"
-        ("dtc", "git://git.qemu.org/dtc.git", "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf", "")
+        ("dtc", "git://git.yoctoproject.org/bbfetchtests-dtc.git", "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf", "")
             : "1.4.0",
         # combination version pattern
         ("sysprof", "git://gitlab.gnome.org/GNOME/sysprof.git;protocol=https", "cd44ee6644c3641507fb53b8a2a69137f2971219", "")
@@ -1172,13 +1190,13 @@ class FetchLatestVersionTest(FetcherTest):
             : "20120614",
         # packages with a valid UPSTREAM_CHECK_GITTAGREGEX
                 # mirror of git://anongit.freedesktop.org/xorg/driver/xf86-video-omap since network issues interfered with testing
-        ("xf86-video-omap", "git://git.yoctoproject.org/bbfetchtests-xf86-video-omap", "ae0394e687f1a77e966cf72f895da91840dffb8f", "(?P<pver>(\d+\.(\d\.?)*))")
+        ("xf86-video-omap", "git://git.yoctoproject.org/bbfetchtests-xf86-video-omap", "ae0394e687f1a77e966cf72f895da91840dffb8f", r"(?P<pver>(\d+\.(\d\.?)*))")
             : "0.4.3",
-        ("build-appliance-image", "git://git.yoctoproject.org/poky", "b37dd451a52622d5b570183a81583cc34c2ff555", "(?P<pver>(([0-9][\.|_]?)+[0-9]))")
+        ("build-appliance-image", "git://git.yoctoproject.org/poky", "b37dd451a52622d5b570183a81583cc34c2ff555", r"(?P<pver>(([0-9][\.|_]?)+[0-9]))")
             : "11.0.0",
-        ("chkconfig-alternatives-native", "git://github.com/kergoth/chkconfig;branch=sysroot", "cd437ecbd8986c894442f8fce1e0061e20f04dee", "chkconfig\-(?P<pver>((\d+[\.\-_]*)+))")
+        ("chkconfig-alternatives-native", "git://github.com/kergoth/chkconfig;branch=sysroot;protocol=https", "cd437ecbd8986c894442f8fce1e0061e20f04dee", r"chkconfig\-(?P<pver>((\d+[\.\-_]*)+))")
             : "1.3.59",
-        ("remake", "git://github.com/rocky/remake.git", "f05508e521987c8494c92d9c2871aec46307d51d", "(?P<pver>(\d+\.(\d+\.)*\d*(\+dbg\d+(\.\d+)*)*))")
+        ("remake", "git://github.com/rocky/remake.git;protocol=https", "f05508e521987c8494c92d9c2871aec46307d51d", r"(?P<pver>(\d+\.(\d+\.)*\d*(\+dbg\d+(\.\d+)*)*))")
             : "3.82+dbg0.9",
     }
 
@@ -1218,11 +1236,11 @@ class FetchLatestVersionTest(FetcherTest):
         #
         # http://www.cups.org/software/1.7.2/cups-1.7.2-source.tar.bz2
         # https://github.com/apple/cups/releases
-        ("cups", "/software/1.7.2/cups-1.7.2-source.tar.bz2", "/apple/cups/releases", "(?P<name>cups\-)(?P<pver>((\d+[\.\-_]*)+))\-source\.tar\.gz")
+        ("cups", "/software/1.7.2/cups-1.7.2-source.tar.bz2", "/apple/cups/releases", r"(?P<name>cups\-)(?P<pver>((\d+[\.\-_]*)+))\-source\.tar\.gz")
             : "2.0.0",
         # http://download.oracle.com/berkeley-db/db-5.3.21.tar.gz
         # http://ftp.debian.org/debian/pool/main/d/db5.3/
-        ("db", "/berkeley-db/db-5.3.21.tar.gz", "/debian/pool/main/d/db5.3/", "(?P<name>db5\.3_)(?P<pver>\d+(\.\d+)+).+\.orig\.tar\.xz")
+        ("db", "/berkeley-db/db-5.3.21.tar.gz", "/debian/pool/main/d/db5.3/", r"(?P<name>db5\.3_)(?P<pver>\d+(\.\d+)+).+\.orig\.tar\.xz")
             : "5.3.10",
     }
 
@@ -1272,9 +1290,6 @@ class FetchCheckStatusTest(FetcherTest):
                       "http://downloads.yoctoproject.org/releases/opkg/opkg-0.1.7.tar.gz",
                       "http://downloads.yoctoproject.org/releases/opkg/opkg-0.3.0.tar.gz",
                       "ftp://sourceware.org/pub/libffi/libffi-1.20.tar.gz",
-                      "http://ftp.gnu.org/gnu/autoconf/autoconf-2.60.tar.gz",
-                      "https://ftp.gnu.org/gnu/chess/gnuchess-5.08.tar.gz",
-                      "https://ftp.gnu.org/gnu/gmp/gmp-4.0.tar.gz",
                       # GitHub releases are hosted on Amazon S3, which doesn't support HEAD
                       "https://github.com/kergoth/tslib/releases/download/1.1/tslib-1.1.tar.xz"
                       ]
@@ -1313,6 +1328,8 @@ class GitMakeShallowTest(FetcherTest):
         self.gitdir = os.path.join(self.tempdir, 'gitshallow')
         bb.utils.mkdirhier(self.gitdir)
         bb.process.run('git init', cwd=self.gitdir)
+        bb.process.run('git config user.email "you@example.com"', cwd=self.gitdir)
+        bb.process.run('git config user.name "Your Name"', cwd=self.gitdir)
 
     def assertRefs(self, expected_refs):
         actual_refs = self.git(['for-each-ref', '--format=%(refname)']).splitlines()
@@ -1436,6 +1453,8 @@ class GitShallowTest(FetcherTest):
 
         bb.utils.mkdirhier(self.srcdir)
         self.git('init', cwd=self.srcdir)
+        self.git('config user.email "you@example.com"', cwd=self.srcdir)
+        self.git('config user.name "Your Name"', cwd=self.srcdir)
         self.d.setVar('WORKDIR', self.tempdir)
         self.d.setVar('S', self.gitdir)
         self.d.delVar('PREMIRRORS')
@@ -1517,6 +1536,7 @@ class GitShallowTest(FetcherTest):
 
         # fetch and unpack, from the shallow tarball
         bb.utils.remove(self.gitdir, recurse=True)
+        bb.process.run('chmod u+w -R "%s"' % ud.clonedir)
         bb.utils.remove(ud.clonedir, recurse=True)
         bb.utils.remove(ud.clonedir.replace('gitsource', 'gitsubmodule'), recurse=True)
 
@@ -1669,6 +1689,8 @@ class GitShallowTest(FetcherTest):
         smdir = os.path.join(self.tempdir, 'gitsubmodule')
         bb.utils.mkdirhier(smdir)
         self.git('init', cwd=smdir)
+        self.git('config user.email "you@example.com"', cwd=smdir)
+        self.git('config user.name "Your Name"', cwd=smdir)
         # Make this look like it was cloned from a remote...
         self.git('config --add remote.origin.url "%s"' % smdir, cwd=smdir)
         self.git('config --add remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"', cwd=smdir)
@@ -1699,6 +1721,8 @@ class GitShallowTest(FetcherTest):
         smdir = os.path.join(self.tempdir, 'gitsubmodule')
         bb.utils.mkdirhier(smdir)
         self.git('init', cwd=smdir)
+        self.git('config user.email "you@example.com"', cwd=smdir)
+        self.git('config user.name "Your Name"', cwd=smdir)
         # Make this look like it was cloned from a remote...
         self.git('config --add remote.origin.url "%s"' % smdir, cwd=smdir)
         self.git('config --add remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"', cwd=smdir)
@@ -1741,8 +1765,8 @@ class GitShallowTest(FetcherTest):
             self.git('annex init', cwd=self.srcdir)
             open(os.path.join(self.srcdir, 'c'), 'w').close()
             self.git('annex add c', cwd=self.srcdir)
-            self.git('commit -m annex-c -a', cwd=self.srcdir)
-            bb.process.run('chmod u+w -R %s' % os.path.join(self.srcdir, '.git', 'annex'))
+            self.git('commit --author "Foo Bar <foo@bar>" -m annex-c -a', cwd=self.srcdir)
+            bb.process.run('chmod u+w -R %s' % self.srcdir)
 
             uri = 'gitannex://%s;protocol=file;subdir=${S}' % self.srcdir
             fetcher, ud = self.fetch_shallow(uri)
@@ -1956,7 +1980,7 @@ class GitShallowTest(FetcherTest):
 
     @skipIfNoNetwork()
     def test_bitbake(self):
-        self.git('remote add --mirror=fetch origin git://github.com/openembedded/bitbake', cwd=self.srcdir)
+        self.git('remote add --mirror=fetch origin https://github.com/openembedded/bitbake', cwd=self.srcdir)
         self.git('config core.bare true', cwd=self.srcdir)
         self.git('fetch', cwd=self.srcdir)
 
@@ -2017,6 +2041,8 @@ class GitLfsTest(FetcherTest):
 
         bb.utils.mkdirhier(self.srcdir)
         self.git('init', cwd=self.srcdir)
+        self.git('config user.email "you@example.com"', cwd=self.srcdir)
+        self.git('config user.name "Your Name"', cwd=self.srcdir)
         with open(os.path.join(self.srcdir, '.gitattributes'), 'wt') as attrs:
             attrs.write('*.mp3 filter=lfs -text')
         self.git(['add', '.gitattributes'], cwd=self.srcdir)
@@ -2031,13 +2057,14 @@ class GitLfsTest(FetcherTest):
             cwd = self.gitdir
         return bb.process.run(cmd, cwd=cwd)[0]
 
-    def fetch(self, uri=None):
+    def fetch(self, uri=None, download=True):
         uris = self.d.getVar('SRC_URI').split()
         uri = uris[0]
         d = self.d
 
         fetcher = bb.fetch2.Fetch(uris, d)
-        fetcher.download()
+        if download:
+            fetcher.download()
         ud = fetcher.ud[uri]
         return fetcher, ud
 
@@ -2047,16 +2074,21 @@ class GitLfsTest(FetcherTest):
         uri = 'git://%s;protocol=file;subdir=${S};lfs=1' % self.srcdir
         self.d.setVar('SRC_URI', uri)
 
-        fetcher, ud = self.fetch()
+        # Careful: suppress initial attempt at downloading until
+        # we know whether git-lfs is installed.
+        fetcher, ud = self.fetch(uri=None, download=False)
         self.assertIsNotNone(ud.method._find_git_lfs)
 
-        # If git-lfs can be found, the unpack should be successful
-        ud.method._find_git_lfs = lambda d: True
-        shutil.rmtree(self.gitdir, ignore_errors=True)
-        fetcher.unpack(self.d.getVar('WORKDIR'))
+        # If git-lfs can be found, the unpack should be successful. Only
+        # attempt this with the real live copy of git-lfs installed.
+        if ud.method._find_git_lfs(self.d):
+            fetcher.download()
+            shutil.rmtree(self.gitdir, ignore_errors=True)
+            fetcher.unpack(self.d.getVar('WORKDIR'))
 
         # If git-lfs cannot be found, the unpack should throw an error
         with self.assertRaises(bb.fetch2.FetchError):
+            fetcher.download()
             ud.method._find_git_lfs = lambda d: False
             shutil.rmtree(self.gitdir, ignore_errors=True)
             fetcher.unpack(self.d.getVar('WORKDIR'))
@@ -2067,10 +2099,16 @@ class GitLfsTest(FetcherTest):
         uri = 'git://%s;protocol=file;subdir=${S};lfs=0' % self.srcdir
         self.d.setVar('SRC_URI', uri)
 
+        # In contrast to test_lfs_enabled(), allow the implicit download
+        # done by self.fetch() to occur here. The point of this test case
+        # is to verify that the fetcher can survive even if the source
+        # repository has Git LFS usage configured.
         fetcher, ud = self.fetch()
         self.assertIsNotNone(ud.method._find_git_lfs)
 
-        # If git-lfs can be found, the unpack should be successful
+        # If git-lfs can be found, the unpack should be successful. A
+        # live copy of git-lfs is not required for this case, so
+        # unconditionally forge its presence.
         ud.method._find_git_lfs = lambda d: True
         shutil.rmtree(self.gitdir, ignore_errors=True)
         fetcher.unpack(self.d.getVar('WORKDIR'))
@@ -2080,6 +2118,38 @@ class GitLfsTest(FetcherTest):
         shutil.rmtree(self.gitdir, ignore_errors=True)
         fetcher.unpack(self.d.getVar('WORKDIR'))
 
+class GitURLWithSpacesTest(FetcherTest):
+    test_git_urls = {
+        "git://tfs-example.org:22/tfs/example%20path/example.git" : {
+            'url': 'git://tfs-example.org:22/tfs/example%20path/example.git',
+            'gitsrcname': 'tfs-example.org.22.tfs.example_path.example.git',
+            'path': '/tfs/example path/example.git'
+        },
+        "git://tfs-example.org:22/tfs/example%20path/example%20repo.git" : {
+            'url': 'git://tfs-example.org:22/tfs/example%20path/example%20repo.git',
+            'gitsrcname': 'tfs-example.org.22.tfs.example_path.example_repo.git',
+            'path': '/tfs/example path/example repo.git'
+        }
+    }
+
+    def test_urls(self):
+
+        # Set fake SRCREV to stop git fetcher from trying to contact non-existent git repo
+        self.d.setVar('SRCREV', '82ea737a0b42a8b53e11c9cde141e9e9c0bd8c40')
+
+        for test_git_url, ref in self.test_git_urls.items():
+
+            fetcher = bb.fetch.Fetch([test_git_url], self.d)
+            ud = fetcher.ud[fetcher.urls[0]]
+
+            self.assertEqual(ud.url, ref['url'])
+            self.assertEqual(ud.path, ref['path'])
+            self.assertEqual(ud.localfile, os.path.join(self.dldir, "git2", ref['gitsrcname']))
+            self.assertEqual(ud.localpath, os.path.join(self.dldir, "git2", ref['gitsrcname']))
+            self.assertEqual(ud.lockfile, os.path.join(self.dldir, "git2", ref['gitsrcname'] + '.lock'))
+            self.assertEqual(ud.clonedir, os.path.join(self.dldir, "git2", ref['gitsrcname']))
+            self.assertEqual(ud.fullmirror, os.path.join(self.dldir, "git2_" + ref['gitsrcname'] + '.tar.gz'))
+
 class NPMTest(FetcherTest):
     def skipIfNoNpm():
         import shutil

bitbake/lib/bb/tinfoil.py

@@ -448,7 +448,7 @@ class Tinfoil:
         self.run_actions(config_params)
         self.recipes_parsed = True
 
-    def run_command(self, command, *params):
+    def run_command(self, command, *params, handle_events=True):
         """
         Run a command on the server (as implemented in bb.command).
         Note that there are two types of command - synchronous and
@@ -465,7 +465,16 @@ class Tinfoil:
         commandline = [command]
         if params:
             commandline.extend(params)
-        result = self.server_connection.connection.runCommand(commandline)
+        try:
+            result = self.server_connection.connection.runCommand(commandline)
+        finally:
+            while handle_events:
+                event = self.wait_event()
+                if not event:
+                    break
+                if isinstance(event, logging.LogRecord):
+                    if event.taskpid == 0 or event.levelno > logging.INFO:
+                        self.logger.handle(event)
         if result[1]:
             raise TinfoilCommandFailed(result[1])
         return result[0]

bitbake/lib/bb/ui/knotty.py

@@ -380,14 +380,27 @@ _evt_list = [ "bb.runqueue.runQueueExitWait", "bb.event.LogExecTTY", "logging.Lo
               "bb.event.BuildBase", "bb.build.TaskStarted", "bb.build.TaskSucceeded", "bb.build.TaskFailedSilent",
               "bb.build.TaskProgress", "bb.event.ProcessStarted", "bb.event.ProcessProgress", "bb.event.ProcessFinished"]
 
+def drain_events_errorhandling(eventHandler):
+    # We don't have logging setup, we do need to show any events we see before exiting
+    event = True
+    logger = bb.msg.logger_create('bitbake', sys.stdout)
+    while event:
+        event = eventHandler.waitEvent(0)
+        if isinstance(event, logging.LogRecord):
+            logger.handle(event)
+
 def main(server, eventHandler, params, tf = TerminalFilter):
 
-    if not params.observe_only:
-        params.updateToServer(server, os.environ.copy())
+    try:
+        if not params.observe_only:
+            params.updateToServer(server, os.environ.copy())
 
-    includelogs, loglines, consolelogfile, logconfigfile = _log_settings_from_server(server, params.observe_only)
+        includelogs, loglines, consolelogfile, logconfigfile = _log_settings_from_server(server, params.observe_only)
 
-    loglevel, _ = bb.msg.constructLogOptions()
+        loglevel, _ = bb.msg.constructLogOptions()
+    except bb.BBHandledException:
+        drain_events_errorhandling(eventHandler)
+        return 1
 
     if params.options.quiet == 0:
         console_loglevel = loglevel

bitbake/lib/bb/ui/taskexp.py

@@ -8,6 +8,7 @@
 #
 
 import sys
+import traceback
 
 try:
     import gi
@@ -58,7 +59,12 @@ class PackageReverseDepView(Gtk.TreeView):
         self.current = None
         self.filter_model = model.filter_new()
         self.filter_model.set_visible_func(self._filter)
-        self.sort_model = self.filter_model.sort_new_with_model()
+        # The introspected API was fixed but we can't rely on a pygobject that hides this.
+        # https://gitlab.gnome.org/GNOME/pygobject/-/commit/9cdbc56fbac4db2de78dc080934b8f0a7efc892a
+        if hasattr(Gtk.TreeModelSort, "new_with_model"):
+            self.sort_model = Gtk.TreeModelSort.new_with_model(self.filter_model)
+        else:
+            self.sort_model = self.filter_model.sort_new_with_model()
         self.sort_model.set_sort_column_id(COL_DEP_PARENT, Gtk.SortType.ASCENDING)
         self.set_model(self.sort_model)
         self.append_column(Gtk.TreeViewColumn(label, Gtk.CellRendererText(), text=COL_DEP_PARENT))
@@ -191,6 +197,7 @@ def main(server, eventHandler, params):
     gtkgui.start()
 
     try:
+        params.updateToServer(server, os.environ.copy())
         params.updateFromServer(server)
         cmdline = params.parseActions()
         if not cmdline:
@@ -213,6 +220,9 @@ def main(server, eventHandler, params):
     except client.Fault as x:
         print("XMLRPC Fault getting commandline:\n %s" % x)
         return
+    except Exception as e:
+        print("Exception in startup:\n %s" % traceback.format_exc())
+        return
 
     if gtkthread.quit.isSet():
         return

bitbake/lib/bb/utils.py

@@ -16,7 +16,8 @@ import bb.msg
 import multiprocessing
 import fcntl
 import importlib
-from importlib import machinery
+import importlib.machinery
+import importlib.util
 import itertools
 import subprocess
 import glob
@@ -1584,7 +1585,9 @@ def load_plugins(logger, plugins, pluginpath):
         logger.debug(1, 'Loading plugin %s' % name)
         spec = importlib.machinery.PathFinder.find_spec(name, path=[pluginpath] )
         if spec:
-            return spec.loader.load_module()
+            mod = importlib.util.module_from_spec(spec)
+            spec.loader.exec_module(mod)
+            return mod
 
     logger.debug(1, 'Loading plugins from %s...' % pluginpath)
 

bitbake/lib/bblayers/action.py

@@ -50,10 +50,10 @@ class ActionPlugin(LayerPlugin):
             if not (args.force or notadded):
                 try:
                     self.tinfoil.run_command('parseConfiguration')
-                except bb.tinfoil.TinfoilUIException:
+                except (bb.tinfoil.TinfoilUIException, bb.BBHandledException):
                     # Restore the back up copy of bblayers.conf
                     shutil.copy2(backup, bblayers_conf)
-                    bb.fatal("Parse failure with the specified layer added")
+                    bb.fatal("Parse failure with the specified layer added, aborting.")
                 else:
                     for item in notadded:
                         sys.stderr.write("Specified layer %s is already in BBLAYERS\n" % item)

bitbake/lib/bblayers/query.py

@@ -150,7 +150,7 @@ skipped recipes will also be listed, with a " (skipped)" suffix.
         def print_item(f, pn, ver, layer, ispref):
             if not selected_layer or layer == selected_layer:
                 if not bare and f in skiplist:
-                    skipped = ' (skipped)'
+                    skipped = ' (skipped: %s)' % self.tinfoil.cooker.skiplist[f].skipreason
                 else:
                     skipped = ''
                 if show_filenames:
@@ -433,10 +433,10 @@ NOTE: .bbappend files can impact the dependencies.
                     line = fnfile.readline()
 
         # The "require/include xxx" in conf/machine/*.conf, .inc and .bbclass
-        conf_re = re.compile(".*/conf/machine/[^\/]*\.conf$")
-        inc_re = re.compile(".*\.inc$")
+        conf_re = re.compile(r".*/conf/machine/[^\/]*\.conf$")
+        inc_re = re.compile(r".*\.inc$")
         # The "inherit xxx" in .bbclass
-        bbclass_re = re.compile(".*\.bbclass$")
+        bbclass_re = re.compile(r".*\.bbclass$")
         for layerdir in self.bblayers:
             layername = self.get_layer_name(layerdir)
             for dirpath, dirnames, filenames in os.walk(layerdir):

bitbake/lib/hashserv/server.py

@@ -12,6 +12,7 @@ import math
 import os
 import signal
 import socket
+import sys
 import time
 from . import chunkify, DEFAULT_MAX_CHUNK
 
@@ -419,9 +420,14 @@ class Server(object):
         self._cleanup_socket = None
 
     def start_tcp_server(self, host, port):
-        self.server = self.loop.run_until_complete(
-            asyncio.start_server(self.handle_client, host, port, loop=self.loop)
-        )
+        if sys.version_info[0] == 3 and sys.version_info[1] < 6:
+            self.server = self.loop.run_until_complete(
+                asyncio.start_server(self.handle_client, host, port, loop=self.loop)
+            )
+        else:
+            self.server = self.loop.run_until_complete(
+                asyncio.start_server(self.handle_client, host, port)
+            )
 
         for s in self.server.sockets:
             logger.info('Listening on %r' % (s.getsockname(),))
@@ -444,9 +450,14 @@ class Server(object):
         try:
             # Work around path length limits in AF_UNIX
             os.chdir(os.path.dirname(path))
-            self.server = self.loop.run_until_complete(
-                asyncio.start_unix_server(self.handle_client, os.path.basename(path), loop=self.loop)
-            )
+            if sys.version_info[0] == 3 and sys.version_info[1] < 6:
+                self.server = self.loop.run_until_complete(
+                    asyncio.start_unix_server(self.handle_client, os.path.basename(path), loop=self.loop)
+                )
+            else:
+                self.server = self.loop.run_until_complete(
+                    asyncio.start_unix_server(self.handle_client, os.path.basename(path))
+                )
         finally:
             os.chdir(cwd)
 

bitbake/lib/layerindexlib/__init__.py

@@ -6,7 +6,6 @@
 import datetime
 
 import logging
-import imp
 
 from collections import OrderedDict
 from layerindexlib.plugin import LayerIndexPluginUrlError

documentation/.gitignore

@@ -0,0 +1,2 @@
+_build/
+Pipfile.lock

documentation/Makefile

@@ -1,431 +1,35 @@
-# This is a single Makefile to handle all generated Yocto Project documents,
-# which includes the BitBake User Manual and the Toaster User Manual.
-# The Makefile needs to live in the documents directory and all figures used
-# in any manuals must be .PNG files and live in the individual book's figures
-# directory as well as in the figures directory for the mega-manual.
+# Minimal makefile for Sphinx documentation
 #
-# Note that the figures for the Yocto Project Development Tasks Manual
-# differ depending on the BRANCH being built.
-#
-# The Makefile has these targets:
-#    all:       If you leave off the target then "all" is implied.
-#               You will generate HTML and a tarball of files.
-#
-#    pdf:	generates a PDF version of a manual.  Not valid for the
-#		Quick Start or the mega-manual (single, large HTML file
-#		comprised of all Yocto Project manuals).
-#    html:	generates an HTML version of a manual.
-#    tarball:	creates a tarball for the doc files.
-#    validate:	validates
-#    publish:	pushes generated files to the Yocto Project website
-#    clean:	removes files
-#
-# The Makefile can generate an HTML and PDF version of every document except the
-# Yocto Project Quick Start and the single, HTML mega-manual, which is comprised
-# of all the individual Yocto Project manuals.  You can generate these two manuals
-# in HTML form only.  The variable DOC indicates the folder name for a given manual.
-# The variable VER represents the distro version of the Yocto Release for which the
-# manuals are being generated.  The variable BRANCH is used to indicate the
-# branch (edison or denzil) and is used only when DOC=dev-manual or
-# DOC=mega-manual.  If you do not specify a BRANCH, the default branch used
-# will be for the latest Yocto Project release.  If you build for either
-# edison or denzil, you must use BRANCH. You do not need to use BRANCH for
-# any release beyond denzil.
-#
-# To build a manual, you must invoke Makefile with the DOC argument.  If you
-# are going to publish the manual, then you must invoke Makefile with both the
-# DOC and the VER argument.  Furthermore, if you are building or publishing
-# the edison or denzil versions of the Yocto Project Development Tasks Manual or
-# the mega-manual, you must also use the BRANCH argument.
-#
-# Examples:
-#
-#     make DOC=bsp-guide
-#     make html DOC=brief-yoctoprojectqs
-#     make pdf DOC=ref-manual
-#     make DOC=dev-manual BRANCH=edison
-#     make DOC=mega-manual BRANCH=denzil
-#
-# The first example generates the HTML version of the BSP Guide.
-# The second example generates the HTML version only of the Quick Start.  Note
-# that the Quick Start only has an HTML version available.  So, the
-# 'make DOC=brief-yoctoprojectqs' command would be equivalent. The third example
-# generates just the PDF version of the Yocto Project Reference Manual.
-# The fourth example generates the HTML 'edison' version of the YP Development
-# Tasks Manual.  The last example
-# generates the HTML version of the mega-manual and uses the 'denzil'
-# branch when choosing figures for the tarball of figures.  Any example that does
-# not use the BRANCH argument builds the current version of the manual set.
-#
-# The publish target pushes the generated manuals to the Yocto Project
-# website.  Unless you are a developer on the YP team, you will not succeed in
-# pushing manuals to this server.  All files needed for the manual's HTML form are
-# pushed.
-#
-# Examples:
-#
-#    make publish DOC=bsp-guide VER=1.7
-#    make publish DOC=adt-manual VER=1.6
-#    make publish DOC=dev-manual VER=1.1.1 BRANCH=edison
-#    make publish DOC=dev-manual VER=1.2 BRANCH=denzil
-#
-# The first example publishes the 1.7 version of both the PDF and HTML versions of
-# the BSP Guide.  The second example publishes the 1.6 version of both the PDF and
-# HTML versions of the ADT Manual. The third example publishes the 1.1.1 version of
-# the PDF and HTML YP Development Tasks Manual for the 'edison' branch.  The fourth
-# 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 \
-           --stringparam  chapter.autolabel 0 \
-           --stringparam  section.autolabel 0 \
-           --stringparam  section.label.includes.component.label 0 \
-           --xinclude
-ALLPREQ = html tarball
-TARFILES = brief-yoctoprojectqs-style.css brief-yoctoprojectqs.html figures/bypqs-title.png \
-           figures/yocto-project-transp.png
-MANUALS = $(DOC)/$(DOC).html
-FIGURES = figures
-STYLESHEET = $(DOC)/*.css
+# You can set these variables from the command line, and also
+# from the environment for the first two.
+SPHINXOPTS    ?= -j auto
+SPHINXBUILD   ?= sphinx-build
+SOURCEDIR     = .
+BUILDDIR      = _build
+DESTDIR       = final
 
+ifeq ($(shell if which $(SPHINXBUILD) >/dev/null 2>&1; then echo 1; else echo 0; fi),0)
+$(error "The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed")
 endif
 
-ifeq ($(DOC),overview-manual)
-XSLTOPTS = --xinclude
-ALLPREQ = html tarball
-TARFILES = overview-manual-style.css overview-manual.html figures/overview-manual-title.png \
-           figures/git-workflow.png figures/source-repos.png figures/index-downloads.png \
-           figures/yp-download.png figures/YP-flow-diagram.png figures/key-dev-elements.png \
-           figures/poky-reference-distribution.png figures/cross-development-toolchains.png \
-           figures/user-configuration.png figures/layer-input.png figures/source-input.png \
-           figures/package-feeds.png figures/patching.png figures/source-fetching.png \
-           figures/configuration-compile-autoreconf.png figures/analysis-for-package-splitting.png \
-           figures/image-generation.png figures/sdk-generation.png figures/images.png \
-           figures/sdk.png
-MANUALS = $(DOC)/$(DOC).html
-FIGURES = figures
-STYLESHEET = $(DOC)/*.css
+# Put it first so that "make" without argument is like "make help".
+help:
+	@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
 
-endif
+.PHONY: help Makefile clean publish
 
-ifeq ($(DOC),bsp-guide)
-XSLTOPTS = --xinclude
-ALLPREQ = html tarball
-TARFILES = bsp-style.css bsp-guide.html figures/bsp-title.png \
-           figures/bsp-dev-flow.png
-MANUALS = $(DOC)/$(DOC).html
-FIGURES = figures
-STYLESHEET = $(DOC)/*.css
-
-endif
-
-ifeq ($(DOC),dev-manual)
-XSLTOPTS = --xinclude
-ALLPREQ = html tarball
-#
-# Note that the tarfile might produce the "Cannot stat: No such file or
-# directory" error message for .PNG files that are not present when building
-# a particular branch.  The list of files is all-inclusive for all branches.
-# Note, if you don't provide a BRANCH option, it defaults to the latest stuff.
-# This would be appropriate for "master" branch.
-#
-
-	ifeq ($(BRANCH),edison)
-TARFILES = dev-style.css dev-manual.html \
-           figures/app-dev-flow.png figures/bsp-dev-flow.png \
-           figures/dev-title.png figures/git-workflow.png \
-           figures/index-downloads.png figures/kernel-dev-flow.png \
-           figures/kernel-example-repos-edison.png \
-           figures/kernel-overview-1.png figures/kernel-overview-2.png \
-           figures/kernel-overview-3-edison.png \
-           figures/source-repos.png figures/yp-download.png \
-           figures/wip.png
-	else ifeq ($(BRANCH),denzil)
-TARFILES = dev-style.css dev-manual.html \
-           figures/app-dev-flow.png figures/bsp-dev-flow.png \
-           figures/dev-title.png figures/git-workflow.png \
-           figures/index-downloads.png figures/kernel-dev-flow.png \
-           figures/kernel-example-repos-denzil.png \
-           figures/kernel-overview-1.png figures/kernel-overview-2.png \
-           figures/kernel-overview-3-denzil.png \
-           figures/source-repos.png figures/yp-download.png \
-           figures/wip.png
-        else
-TARFILES = dev-style.css dev-manual.html figures/buildhistory-web.png \
-           figures/dev-title.png figures/buildhistory.png \
-           figures/recipe-workflow.png figures/bitbake-build-flow.png \
-           figures/multiconfig_files.png figures/cute-files-npm-example.png
-	endif
-
-MANUALS = $(DOC)/$(DOC).html
-FIGURES = figures
-STYLESHEET = $(DOC)/*.css
-
-endif
-
-ifeq ($(DOC),mega-manual)
-XSLTOPTS = --stringparam html.stylesheet mega-style.css \
-           --stringparam  chapter.autolabel 1 \
-           --stringparam  section.autolabel 1 \
-           --stringparam  section.label.includes.component.label 1 \
-           --xinclude
-ALLPREQ = html tarball
-
-	ifeq ($(BRANCH),edison)
-TARFILES = mega-manual.html mega-style.css figures/yocto-environment.png \
-        figures/building-an-image.png  \
-	figures/using-a-pre-built-image.png \
-	figures/poky-title.png \
-	figures/adt-title.png figures/bsp-title.png \
-	figures/kernel-title.png figures/kernel-architecture-overview.png \
-	figures/app-dev-flow.png figures/bsp-dev-flow.png \
-        figures/dev-title.png figures/git-workflow.png \
-        figures/index-downloads.png figures/kernel-dev-flow.png \
-	figures/kernel-example-repos-edison.png \
-	figures/kernel-overview-1.png figures/kernel-overview-2.png \
-	figures/kernel-overview-3-edison.png \
-	figures/source-repos.png figures/yp-download.png \
-	figures/wip.png
-	else ifeq ($(BRANCH),denzil)
-TARFILES = mega-manual.html mega-style.css figures/yocto-environment.png \
-        figures/building-an-image.png  \
-	figures/using-a-pre-built-image.png \
-	figures/poky-title.png \
-	figures/adt-title.png figures/bsp-title.png \
-	figures/kernel-title.png figures/kernel-architecture-overview.png \
-	figures/app-dev-flow.png figures/bsp-dev-flow.png \
-        figures/dev-title.png figures/git-workflow.png \
-        figures/index-downloads.png figures/kernel-dev-flow.png \
-	figures/kernel-example-repos-denzil.png \
-	figures/kernel-overview-1.png figures/kernel-overview-2.png \
-	figures/kernel-overview-3-denzil.png \
-	figures/source-repos.png figures/yp-download.png \
-	figures/wip.png
-        else
-TARFILES = mega-manual.html mega-style.css \
-        figures/YP-flow-diagram.png \
-	figures/using-a-pre-built-image.png \
-	figures/poky-title.png figures/buildhistory.png \
-        figures/buildhistory-web.png \
-	figures/sdk-title.png figures/bsp-title.png \
-	figures/kernel-dev-title.png figures/kernel-architecture-overview.png \
-	figures/bsp-dev-flow.png \
-        figures/dev-title.png \
-	figures/git-workflow.png figures/index-downloads.png \
-        figures/kernel-dev-flow.png \
-	figures/kernel-overview-2-generic.png \
-	figures/source-repos.png figures/yp-download.png \
-        figures/profile-title.png figures/kernelshark-all.png \
-        figures/kernelshark-choose-events.png \
-        figures/kernelshark-i915-display.png \
-        figures/kernelshark-output-display.png \
-        figures/oprofileui-busybox.png figures/oprofileui-copy-to-user.png \
-        figures/oprofileui-downloading.png figures/oprofileui-processes.png \
-        figures/perf-probe-do_fork-profile.png \
-        figures/perf-report-cycles-u.png \
-        figures/perf-systemwide.png figures/perf-systemwide-libc.png \
-        figures/perf-wget-busybox-annotate-menu.png \
-        figures/perf-wget-busybox-annotate-udhcpc.png \
-        figures/perf-wget-busybox-debuginfo.png \
-        figures/perf-wget-busybox-dso-zoom.png \
-        figures/perf-wget-busybox-dso-zoom-menu.png \
-        figures/perf-wget-busybox-expanded-stripped.png \
-        figures/perf-wget-flat-stripped.png \
-        figures/perf-wget-g-copy-from-user-expanded-stripped.png \
-        figures/perf-wget-g-copy-to-user-expanded-debuginfo.png \
-        figures/perf-wget-g-copy-to-user-expanded-stripped.png \
-        figures/perf-wget-g-copy-to-user-expanded-stripped-unresolved-hidden.png \
-        figures/pybootchartgui-linux-yocto.png \
-        figures/pychart-linux-yocto-rpm.png \
-        figures/pychart-linux-yocto-rpm-nostrip.png \
-        figures/sched-wakeup-profile.png figures/sysprof-callers.png \
-        figures/sysprof-copy-from-user.png figures/sysprof-copy-to-user.png \
-        figures/cross-development-toolchains.png \
-	figures/user-configuration.png \
-        figures/source-input.png figures/package-feeds.png \
-        figures/layer-input.png figures/images.png figures/sdk.png \
-	figures/source-fetching.png figures/patching.png \
-        figures/configuration-compile-autoreconf.png \
-	figures/analysis-for-package-splitting.png \
-        figures/image-generation.png figures/key-dev-elements.png\
-	figures/sdk-generation.png figures/recipe-workflow.png \
-	figures/build-workspace-directory.png figures/mega-title.png \
-	figures/toaster-title.png figures/hosted-service.png figures/multiconfig_files.png \
-	figures/simple-configuration.png figures/poky-reference-distribution.png \
-	figures/compatible-layers.png figures/import-layer.png figures/new-project.png \
-	figures/sdk-environment.png figures/sdk-installed-standard-sdk-directory.png \
-	figures/sdk-devtool-add-flow.png figures/sdk-installed-extensible-sdk-directory.png \
-	figures/sdk-devtool-modify-flow.png \
-	figures/sdk-devtool-upgrade-flow.png figures/bitbake-build-flow.png figures/bypqs-title.png \
-	figures/overview-manual-title.png figures/sdk-autotools-flow.png figures/sdk-makefile-flow.png \
-	figures/bb_multiconfig_files.png figures/bitbake-title.png figures/cute-files-npm-example.png
-	endif
-
-MANUALS = $(DOC)/$(DOC).html
-FIGURES = figures
-STYLESHEET = $(DOC)/*.css
-
-endif
-
-ifeq ($(DOC),ref-manual)
-XSLTOPTS = --xinclude
-ALLPREQ = html tarball
-TARFILES = ref-manual.html ref-style.css figures/poky-title.png \
-	figures/build-workspace-directory.png
-MANUALS = $(DOC)/$(DOC).html
-FIGURES = figures
-STYLESHEET = $(DOC)/*.css
-endif
-
-ifeq ($(DOC),sdk-manual)
-XSLTOPTS = --xinclude
-ALLPREQ = html tarball
-TARFILES = sdk-manual.html sdk-style.css figures/sdk-title.png \
-           figures/sdk-environment.png figures/sdk-installed-standard-sdk-directory.png \
-	   figures/sdk-installed-extensible-sdk-directory.png figures/sdk-devtool-add-flow.png \
-	   figures/sdk-devtool-modify-flow.png \
-	   figures/sdk-devtool-upgrade-flow.png figures/sdk-autotools-flow.png figures/sdk-makefile-flow.png
-MANUALS = $(DOC)/$(DOC).html
-FIGURES = figures
-STYLESHEET = $(DOC)/*.css
-endif
-
-ifeq ($(DOC),profile-manual)
-XSLTOPTS = --xinclude
-ALLPREQ = html tarball
-TARFILES = profile-manual.html profile-manual-style.css \
-           figures/profile-title.png figures/kernelshark-all.png \
-           figures/kernelshark-choose-events.png \
-           figures/kernelshark-i915-display.png \
-           figures/kernelshark-output-display.png \
-           figures/oprofileui-busybox.png figures/oprofileui-copy-to-user.png \
-           figures/oprofileui-downloading.png figures/oprofileui-processes.png \
-           figures/perf-probe-do_fork-profile.png \
-           figures/perf-report-cycles-u.png \
-           figures/perf-systemwide.png figures/perf-systemwide-libc.png \
-           figures/perf-wget-busybox-annotate-menu.png \
-           figures/perf-wget-busybox-annotate-udhcpc.png \
-           figures/perf-wget-busybox-debuginfo.png \
-           figures/perf-wget-busybox-dso-zoom.png \
-           figures/perf-wget-busybox-dso-zoom-menu.png \
-           figures/perf-wget-busybox-expanded-stripped.png \
-           figures/perf-wget-flat-stripped.png \
-           figures/perf-wget-g-copy-from-user-expanded-stripped.png \
-           figures/perf-wget-g-copy-to-user-expanded-debuginfo.png \
-           figures/perf-wget-g-copy-to-user-expanded-stripped.png \
-           figures/perf-wget-g-copy-to-user-expanded-stripped-unresolved-hidden.png \
-           figures/pybootchartgui-linux-yocto.png \
-           figures/pychart-linux-yocto-rpm.png \
-           figures/pychart-linux-yocto-rpm-nostrip.png \
-           figures/sched-wakeup-profile.png figures/sysprof-callers.png \
-           figures/sysprof-copy-from-user.png figures/sysprof-copy-to-user.png
-MANUALS = $(DOC)/$(DOC).html
-FIGURES = figures
-STYLESHEET = $(DOC)/*.css
-endif
-
-ifeq ($(DOC),kernel-dev)
-XSLTOPTS = --xinclude
-ALLPREQ = html tarball
-TARFILES = kernel-dev.html kernel-dev-style.css \
-           figures/kernel-dev-title.png figures/kernel-overview-2-generic.png \
-           figures/kernel-architecture-overview.png figures/kernel-dev-flow.png
-MANUALS = $(DOC)/$(DOC).html
-FIGURES = figures
-STYLESHEET = $(DOC)/*.css
-endif
-
-ifeq ($(DOC),toaster-manual)
-XSLTOPTS = --xinclude
-ALLPREQ = html tarball
-TARFILES = toaster-manual.html toaster-manual-style.css \
-	   figures/toaster-title.png figures/simple-configuration.png \
-	   figures/hosted-service.png \
-	   figures/compatible-layers.png figures/import-layer.png figures/new-project.png
-MANUALS = $(DOC)/$(DOC).html
-FIGURES = figures
-STYLESHEET = $(DOC)/*.css
-endif
-
-
-##
-# These URI should be rewritten by your distribution's xml catalog to
-# match your locally installed XSL stylesheets.
-XSL_BASE_URI  = http://docbook.sourceforge.net/release/xsl/1.76.1
-XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
-
-all: $(ALLPREQ)
-
-pdf:
-ifeq ($(DOC),brief-yoctoprojectqs)
-	@echo " "
-	@echo "ERROR: You cannot generate a PDF file for brief-yoctoprojectqs."
-	@echo " "
-
-else ifeq ($(DOC),mega-manual)
-	@echo " "
-	@echo "ERROR: You cannot generate a mega-manual PDF file."
-	@echo " "
-
-else
-
-	cd $(DOC); ../tools/poky-docbook-to-pdf $(DOC).xml ../template; cd ..
-endif
-
-html:
-ifeq ($(DOC),mega-manual)
-#       See http://www.sagehill.net/docbookxsl/HtmlOutput.html
-	@echo " "
-	@echo "******** Building "$(DOC)
-	@echo " "
-	cd $(DOC); xsltproc $(XSLTOPTS) -o $(DOC).html $(DOC)-customization.xsl $(DOC).xml; cd ..
-	@echo " "
-	@echo "******** Using mega-manual.sed to process external links"
-	@echo " "
-	cd $(DOC); sed -f ../tools/mega-manual.sed < mega-manual.html > mega-output.html; cd ..
-	@echo " "
-	@echo "******** Cleaning up transient file mega-output.html"
-	@echo " "
-	cd $(DOC); rm mega-manual.html; mv mega-output.html mega-manual.html; cd ..
-else
-#       See http://www.sagehill.net/docbookxsl/HtmlOutput.html
-	@echo " "
-	@echo "******** Building "$(DOC)
-	@echo " "
-	cd $(DOC); xsltproc $(XSLTOPTS) -o $(DOC).html $(DOC)-customization.xsl $(DOC).xml; cd ..
-endif
-
-
-tarball: html
-	@echo " "
-	@echo "******** Creating Tarball of document files"
-	@echo " "
-	cd $(DOC); tar -cvzf $(DOC).tgz $(TARFILES); cd ..
-
-validate:
-	cd $(DOC); xmllint --postvalid --xinclude --noout $(DOC).xml; cd ..
-
-
-publish:
-	@if test -f $(DOC)/$(DOC).html; \
-	  then \
-            echo " "; \
-            echo "******** Publishing "$(DOC)".html"; \
-            echo " "; \
-            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."; \
-          echo " "; \
-	fi
+publish: Makefile html singlehtml
+	rm -rf $(BUILDDIR)/$(DESTDIR)/
+	mkdir -p $(BUILDDIR)/$(DESTDIR)/
+	cp -r $(BUILDDIR)/html/* $(BUILDDIR)/$(DESTDIR)/
+	cp $(BUILDDIR)/singlehtml/index.html $(BUILDDIR)/$(DESTDIR)/singleindex.html
+	sed -i -e 's@index.html#@singleindex.html#@g' $(BUILDDIR)/$(DESTDIR)/singleindex.html
 
 clean:
-	rm -rf $(MANUALS); rm $(DOC)/$(DOC).tgz;
+	@rm -rf $(BUILDDIR)
+
+# Catch-all target: route all unknown targets to Sphinx using the new
+# "make mode" option.  $(O) is meant as a shortcut for $(SPHINXOPTS).
+%: Makefile
+	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

documentation/Pipfile

@@ -0,0 +1,14 @@
+[[source]]
+name = "pypi"
+url = "https://pypi.org/simple"
+verify_ssl = true
+
+[dev-packages]
+
+[packages]
+sphinx = "*"
+sphinx-rtd-theme = "*"
+pyyaml = "*"
+
+[requires]
+python_version = "3"

documentation/README

@@ -34,22 +34,17 @@ Manual Organization
 
 Folders exist for individual manuals as follows:
 
-* sdk-manual       - The Yocto Project Software Development Kit (SDK) Developer's Guide.
-* bsp-guide        - The Yocto Project Board Support Package (BSP) Developer's Guide
-* dev-manual       - The Yocto Project Development Tasks Manual
-* kernel-dev       - The Yocto Project Linux Kernel Development Tasks Manual
-* ref-manual       - The Yocto Project Reference Manual
-* yocto-project-qs - The Yocto Project Quick Start
-* mega-manual      - The Yocto Project Mega-Manual, which is an aggregated manual comprised
-                     of all YP manuals and guides
-* profile-manual   - The Yocto Project Profile and Tracing Manual
-* toaster-manual   - The Toaster Manual
+* sdk-manual           - The Yocto Project Software Development Kit (SDK) Developer's Guide.
+* bsp-guide            - The Yocto Project Board Support Package (BSP) Developer's Guide
+* dev-manual           - The Yocto Project Development Tasks Manual
+* kernel-dev           - The Yocto Project Linux Kernel Development Tasks Manual
+* ref-manual           - The Yocto Project Reference Manual
+* brief-yoctoprojectqs - The Yocto Project Quick Start
+* profile-manual       - The Yocto Project Profile and Tracing Manual
+* toaster-manual       - The Toaster Manual
+* test-manual          - The Test Environment Manual
 
-Each folder is self-contained regarding content and figures.  Note that there
-is a sed file needed to process the links of the mega-manual.  The sed file
-is located in the tools directory.  Also note that the figures folder in the
-mega-manual directory contains duplicates of all the figures in the YP folders
-directories for all YP manuals and guides.
+Each folder is self-contained regarding content and figures.
 
 If you want to find HTML versions of the Yocto Project manuals on the web,
 go to http://www.yoctoproject.org and click on the "Documentation" tab.  From
@@ -60,23 +55,8 @@ currently being developed.
 In general, the Yocto Project site (http://www.yoctoproject.org) is a great
 reference for both information and downloads.
 
-Makefile
-========
-
-The Makefile processes manual directories to create HTML, PDF,
-tarballs, etc.  Details on how the Makefile work are documented
-inside the Makefile.  See that file for more information.
-
-To build a manual, you run the make command and pass it the name
-of the folder containing the manual's contents.
-For example, the following command run from the documentation directory
-creates an HTML version of the SDK manual.
-The DOC variable specifies the manual you are making:
-
-     $ make DOC=sdk-manual
-
-poky.ent
-========
+poky.yaml
+=========
 
 This file defines variables used for documentation production.  The variables
 are used to define release pathnames, URLs for the published manuals, etc.
@@ -85,9 +65,263 @@ template
 ========
 Contains various templates, fonts, and some old PNG files.
 
-tools
-=====
-Contains a tool to convert the DocBook files to PDF format.  This folder also
-contains the mega-manual.sed file, which is used by Makefile to process
-cross-references from within the manual that normally go to an external
-manual.
+Sphinx
+======
+
+The Yocto Project documentation was migrated from the original DocBook
+format to Sphinx based documentation for the Yocto Project 3.2
+release. This section will provide additional information related to
+the Sphinx migration, and guidelines for developers willing to
+contribute to the Yocto Project documentation.
+
+   Sphinx is a tool that makes it easy to create intelligent and
+   beautiful documentation, written by Georg Brandl and licensed under
+   the BSD license. It was originally created for the Python
+   documentation.
+
+Extensive documentation is available on the Sphinx website:
+https://www.sphinx-doc.org/en/master/. Sphinx is designed to be
+extensible thanks to the ability to write our own custom extensions,
+as Python modules, which will be executed during the generation of the
+documentation.
+
+Yocto Project documentation website
+===================================
+
+A new website has been created to host the Yocto Project
+documentation, it can be found at: https://docs.yoctoproject.org/.
+
+The entire Yocto Project documentation, as well as the BitBake manual
+is published on this website, including all previously released
+versions. A version switcher was added, as a drop-down menu on the top
+of the page to switch back and forth between the various versions of
+the current active Yocto Project releases.
+
+Transition pages have been added (as rst file) to show links to old
+versions of the Yocto Project documentation with links to each manual
+generated with DocBook.
+
+How to build the Yocto Project documentation
+============================================
+
+Sphinx is written in Python. While it might work with Python2, for
+obvious reasons, we will only support building the Yocto Project
+documentation with Python3.
+
+Sphinx might be available in your Linux distro packages repositories,
+however it is not recommend using distro packages, as they might be
+old versions, especially if you are using an LTS version of your
+distro. The recommended method to install Sphinx and all required
+dependencies is to use the Python Package Index (pip).
+
+To install all required packages run:
+
+ $ pip3 install sphinx sphinx_rtd_theme pyyaml
+
+To build the documentation locally, run:
+
+ $ cd documentation
+ $ make html
+
+The resulting HTML index page will be _build/html/index.html, and you
+can browse your own copy of the locally generated documentation with
+your browser.
+
+Alternatively, you can use Pipenv to automatically install all required
+dependencies in a virtual environment:
+
+ $ cd documentation
+ $ pipenv install
+ $ pipenv run make html
+
+Sphinx theme and CSS customization
+==================================
+
+The Yocto Project documentation is currently based on the "Read the
+Docs" Sphinx theme, with a few changes to make sure the look and feel
+of the project documentation is preserved.
+
+Most of the theme changes can be done using the file
+'sphinx-static/theme_overrides.css'. Most CSS changes in this file
+were inherited from the DocBook CSS stylesheets.
+
+Sphinx design guidelines and principles
+=======================================
+
+The initial Docbook to Sphinx migration was done with an automated
+tool called Pandoc (https://pandoc.org/). The tool produced some clean
+output markdown text files. After the initial automated conversion
+additional changes were done to fix up headings, images and links. In
+addition Sphinx has built in mechanisms (directives) which were used
+to replace similar functions implemented in Docbook such as glossary,
+variables substitutions, notes and references.
+
+Headings
+========
+
+The layout of the Yocto Project manuals is organized as follows
+
+    Book
+      Chapter
+        Section
+          Section
+            Section
+
+The following headings styles are defined in Sphinx:
+
+    Book              => overline ===
+      Chapter         => overline ***
+        Section       => ====
+          Section     => ----
+            Section   => ^^^^
+              Section => """" or ~~~~
+
+With this proposal, we preserve the same TOCs between Sphinx and Docbook.
+
+Built-in glossary
+=================
+
+Sphinx has a glossary directive. From
+https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#glossary:
+
+    This directive must contain a reST definition list with terms and
+    definitions. The definitions will then be referencable with the
+    [https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-term
+    'term' role].
+
+So anywhere in any of the Yocto Project manuals, :term:`VAR` can be
+used to refer to an item from the glossary, and a link is created
+automatically. A general index of terms is also generated by Sphinx
+automatically.
+
+Global substitutions
+====================
+
+The Yocto Project documentation makes heavy use of global
+variables. In Docbook these variables are stored in the file
+poky.ent. This Docbook feature is not handled automatically with
+Pandoc. Sphinx has builtin support for substitutions
+(https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#substitutions),
+however there are important shortcomings. For example they cannot be
+used/nested inside code-block sections.
+
+A Sphinx extension was implemented to support variable substitutions
+to mimic the DocBook based documentation behavior. Variabes
+substitutions are done while reading/parsing the .rst files. The
+pattern for variables substitutions is the same as with DocBook,
+e.g. `&VAR;`.
+
+The implementation of the extension can be found here in the file
+documentation/sphinx/yocto-vars.py, this extension is enabled by
+default when building the Yocto Project documentation.  All variables
+are set in a file call poky.yaml, which was initially generated from
+poky.ent. The file was converted into YAML so that it is easier to
+process by the custom Sphinx extension (which is a Python module).
+
+For example, the following .rst content will produce the 'expected'
+content:
+
+  .. code-block::
+      $ mkdir ~/poky-&DISTRO;
+      or
+      $ git clone &YOCTO_GIT_URL;/git/poky -b &DISTRO_NAME_NO_CAP;
+
+Variables can be nested, like it was the case for DocBook:
+
+  YOCTO_HOME_URL : "http://www.yoctoproject.org"
+  YOCTO_DOCS_URL : "&YOCTO_HOME_URL;/docs"
+
+Note directive
+==============
+
+Sphinx has a builtin 'note' directive that produces clean Note section
+in the output file. There are various types of directives such as
+"attention", "caution", "danger", "error", "hint", "important", "tip",
+"warning", "admonition" that are supported, and additional directive
+can be added as Sphinx extension if needed.
+
+Figures
+=======
+
+The Yocto Project documentation has many figures/images. Sphinx has a
+'figure' directive which is straight forward to use. To include a
+figure in the body of the documentation:
+
+  .. image:: figures/YP-flow-diagram.png
+
+Links and References
+====================
+
+The following types of links can be used: links to other locations in
+the same document, to locations in other documents and to external
+websites.
+
+More information can be found here:
+https://sublime-and-sphinx-guide.readthedocs.io/en/latest/references.html.
+
+References
+==========
+
+The following extension is enabed by default:
+sphinx.ext.autosectionlabel
+(https://www.sphinx-doc.org/en/master/usage/extensions/autosectionlabel.html).
+
+This extension allows you to refer sections by their titles. Note that
+autosectionlabel_prefix_document is enabled by default, so that we can
+insert references from any document.
+
+For example, to insert an HTML link to a section from
+documentaion/manual/intro.rst, use:
+
+  Please check this :ref:`manual/intro:Cross-References to Locations in the Same Document`
+
+Alternatively a custom text can be used instead of using the section
+text:
+
+  Please check this :ref:`section <manual/intro:Cross-References to Locations in the Same Document>`
+
+TIP: The following command can be used to dump all the references that
+     are defined in the project documentation:
+
+       python -msphinx.ext.intersphinx <path to build folder>/html/objects.inv
+
+This dump contains all links and for each link it shows the default
+"Link Text" that Sphinx would use. If the default link text is not
+appropriate, a custom link text can be used in the ':ref:' directive.
+
+Extlinks
+========
+
+The sphinx.ext.extlinks extension is enabled by default
+(https://sublime-and-sphinx-guide.readthedocs.io/en/latest/references.html#use-the-external-links-extension),
+and it is configured with:
+
+  'yocto_home': ('https://yoctoproject.org%s', None),
+  'yocto_wiki': ('https://wiki.yoctoproject.org%s', None),
+  'yocto_dl': ('https://downloads.yoctoproject.org%s', None),
+  'yocto_lists': ('https://lists.yoctoproject.org%s', None),
+  'yocto_bugs': ('https://bugzilla.yoctoproject.org%s', None),
+  'yocto_ab': ('https://autobuilder.yoctoproject.org%s', None),
+  'yocto_docs': ('https://docs.yoctoproject.org%s', None),
+  'yocto_git': ('https://git.yoctoproject.org%s', None),
+  'oe_home': ('https://www.openembedded.org%s', None),
+  'oe_lists': ('https://lists.openembedded.org%s', None),
+
+It creates convenient shortcuts which can be used throughout the
+documentation rst files, as:
+
+  Please check this :yocto_wiki:`wiki page </Weekly_Status>`
+
+Intersphinx links
+=================
+
+The sphinx.ext.intersphinx extension is enabled by default
+(https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html),
+so that we can cross reference content from other Sphinx based
+documentation projects, such as the BitBake manual.
+
+References to the bitbake manual can be done like this:
+
+  See the ":ref:`-D <bitbake:bitbake-user-manual/bitbake-user-manual-intro:usage and syntax>`" option
+or
+  :term:`bitbake:BB_NUMBER_PARSE_THREADS`

documentation/_templates/breadcrumbs.html

@@ -0,0 +1,14 @@
+{% extends "!breadcrumbs.html" %}
+
+{% block breadcrumbs %}
+    <li>
+      <span class="doctype_switcher_placeholder">{{ doctype or 'single' }}</span>
+      <span class="version_switcher_placeholder">{{ release }}</span>
+    </li>
+    <li> &raquo;</li>
+    {% for doc in parents %}
+      <li><a href="{{ doc.link|e }}">{{ doc.title }}</a> &raquo;</li>
+    {% endfor %}
+    <li>{{ title }}</li>
+{% endblock %}
+

documentation/_templates/footer.html

@@ -0,0 +1,12 @@
+<footer>
+  <hr/>
+  <div role="contentinfo">
+    <p> A Linux Foundation Collaborative Project.
+        <br> All Rights Reserved. Linux Foundation&reg; and Yocto Project&reg; are registered trademarks of the Linux Foundation.
+        <br>Linux&reg; is a registered trademark of Linus Torvalds.
+        <br>&copy; Copyright {{ copyright }}
+        <br>Last updated on {{ last_updated }}
+    </p>
+  </div>
+</footer>
+

documentation/_templates/layout.html

@@ -0,0 +1,7 @@
+{% extends "!layout.html" %}
+
+{% block extrabody %}
+<div id="outdated-warning" style="text-align: center; background-color: #FFBABA; color: #6A0E0E;">
+</div>
+{% endblock %}
+

documentation/adt-manual/adt-command.xml

@@ -1,265 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
-[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
-
-<chapter id='using-the-command-line'>
-<title>Using the Command Line</title>
-
-    <para>
-        Recall that earlier the manual discussed how to use an existing toolchain
-        tarball that had been installed into the default installation
-        directory, <filename>/opt/poky/&DISTRO;</filename>, which is outside of the
-        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
-        (see the section "<link linkend='using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball)</link>".
-        And, that sourcing your architecture-specific environment setup script
-        initializes a suitable cross-toolchain development environment.
-    </para>
-
-    <para>
-        During this setup, locations for the compiler, QEMU scripts, QEMU binary,
-        a special version of <filename>pkgconfig</filename> and other useful
-        utilities are added to the <filename>PATH</filename> variable.
-        Also, variables to assist
-        <filename>pkgconfig</filename> and <filename>autotools</filename>
-        are also defined so that, for example, <filename>configure.sh</filename>
-        can find pre-generated test results for tests that need target hardware
-        on which to run.
-        You can see the
-        "<link linkend='setting-up-the-cross-development-environment'>Setting Up the Cross-Development Environment</link>"
-        section for the list of cross-toolchain environment variables
-        established by the script.
-    </para>
-
-    <para>
-        Collectively, these conditions allow you to easily use the toolchain
-        outside of the OpenEmbedded build environment on both Autotools-based
-        projects and Makefile-based projects.
-        This chapter provides information for both these types of projects.
-    </para>
-
-
-<section id='autotools-based-projects'>
-<title>Autotools-Based Projects</title>
-
-    <para>
-        Once you have a suitable cross-toolchain installed, it is very easy to
-        develop a project outside of the OpenEmbedded build system.
-        This section presents a simple "Helloworld" example that shows how
-        to set up, compile, and run the project.
-    </para>
-
-    <section id='creating-and-running-a-project-based-on-gnu-autotools'>
-        <title>Creating and Running a Project Based on GNU Autotools</title>
-
-        <para>
-            Follow these steps to create a simple Autotools-based project:
-            <orderedlist>
-                <listitem><para><emphasis>Create your directory:</emphasis>
-                    Create a clean directory for your project and then make
-                    that directory your working location:
-                    <literallayout class='monospaced'>
-     $ mkdir $HOME/helloworld
-     $ cd $HOME/helloworld
-                    </literallayout></para></listitem>
-                <listitem><para><emphasis>Populate the directory:</emphasis>
-                    Create <filename>hello.c</filename>, <filename>Makefile.am</filename>,
-                    and <filename>configure.in</filename> files as follows:
-                    <itemizedlist>
-                        <listitem><para>For <filename>hello.c</filename>, include
-                            these lines:
-                            <literallayout class='monospaced'>
-     #include &lt;stdio.h&gt;
-
-     main()
-        {
-           printf("Hello World!\n");
-        }
-                            </literallayout></para></listitem>
-                        <listitem><para>For <filename>Makefile.am</filename>,
-                            include these lines:
-                            <literallayout class='monospaced'>
-     bin_PROGRAMS = hello
-     hello_SOURCES = hello.c
-                            </literallayout></para></listitem>
-                        <listitem><para>For <filename>configure.in</filename>,
-                            include these lines:
-                            <literallayout class='monospaced'>
-     AC_INIT(hello.c)
-     AM_INIT_AUTOMAKE(hello,0.1)
-     AC_PROG_CC
-     AC_PROG_INSTALL
-     AC_OUTPUT(Makefile)
-                            </literallayout></para></listitem>
-                    </itemizedlist></para></listitem>
-                <listitem><para><emphasis>Source the cross-toolchain
-                    environment setup file:</emphasis>
-                    Installation of the cross-toolchain creates a cross-toolchain
-                    environment setup script in the directory that the ADT
-                    was installed.
-                    Before you can use the tools to develop your project, you must
-                    source this setup script.
-                    The script begins with the string "environment-setup" and contains
-                    the machine architecture, which is followed by the string
-                    "poky-linux".
-                    Here is an example that sources a script from the
-                    default ADT installation directory that uses the
-                    32-bit Intel x86 Architecture and the
-                    &DISTRO_NAME; Yocto Project release:
-                    <literallayout class='monospaced'>
-     $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
-                    </literallayout></para></listitem>
-                <listitem><para><emphasis>Generate the local aclocal.m4
-                    files and create the configure script:</emphasis>
-                    The following GNU Autotools generate the local
-                    <filename>aclocal.m4</filename> files and create the
-                    configure script:
-                    <literallayout class='monospaced'>
-     $ aclocal
-     $ autoconf
-                    </literallayout></para></listitem>
-                <listitem><para><emphasis>Generate files needed by GNU
-                    coding standards:</emphasis>
-                    GNU coding standards require certain files in order for the
-                    project to be compliant.
-                    This command creates those files:
-                    <literallayout class='monospaced'>
-     $ touch NEWS README AUTHORS ChangeLog
-                    </literallayout></para></listitem>
-                <listitem><para><emphasis>Generate the configure
-                    file:</emphasis>
-                    This command generates the <filename>configure</filename>:
-                    <literallayout class='monospaced'>
-     $ automake -a
-                    </literallayout></para></listitem>
-                <listitem><para><emphasis>Cross-compile the project:</emphasis>
-                    This command compiles the project using the cross-compiler.
-                    The
-                    <ulink url='&YOCTO_DOCS_REF_URL;#var-CONFIGURE_FLAGS'><filename>CONFIGURE_FLAGS</filename></ulink>
-                    environment variable provides the minimal arguments for
-                    GNU configure:
-                    <literallayout class='monospaced'>
-     $ ./configure ${CONFIGURE_FLAGS}
-                    </literallayout></para></listitem>
-                <listitem><para><emphasis>Make and install the project:</emphasis>
-                    These two commands generate and install the project into the
-                    destination directory:
-                    <literallayout class='monospaced'>
-     $ make
-     $ make install DESTDIR=./tmp
-                    </literallayout></para></listitem>
-                <listitem><para><emphasis>Verify the installation:</emphasis>
-                    This command is a simple way to verify the installation
-                    of your project.
-                    Running the command prints the architecture on which
-                    the binary file can run.
-                    This architecture should be the same architecture that
-                    the installed cross-toolchain supports.
-                    <literallayout class='monospaced'>
-     $ file ./tmp/usr/local/bin/hello
-                    </literallayout></para></listitem>
-                <listitem><para><emphasis>Execute your project:</emphasis>
-                    To execute the project in the shell, simply enter the name.
-                    You could also copy the binary to the actual target hardware
-                    and run the project there as well:
-                    <literallayout class='monospaced'>
-     $ ./hello
-                    </literallayout>
-                    As expected, the project displays the "Hello World!" message.
-                    </para></listitem>
-            </orderedlist>
-        </para>
-    </section>
-
-    <section id='passing-host-options'>
-        <title>Passing Host Options</title>
-
-        <para>
-            For an Autotools-based project, you can use the cross-toolchain by just
-            passing the appropriate host option to <filename>configure.sh</filename>.
-            The host option you use is derived from the name of the environment setup
-            script found in the directory in which you installed the cross-toolchain.
-            For example, the host option for an ARM-based target that uses the GNU EABI
-            is <filename>armv5te-poky-linux-gnueabi</filename>.
-            You will notice that the name of the script is
-            <filename>environment-setup-armv5te-poky-linux-gnueabi</filename>.
-            Thus, the following command works to update your project and
-            rebuild it using the appropriate cross-toolchain tools:
-            <literallayout class='monospaced'>
-     $ ./configure --host=armv5te-poky-linux-gnueabi \
-        --with-libtool-sysroot=<replaceable>sysroot_dir</replaceable>
-            </literallayout>
-            <note>
-                If the <filename>configure</filename> script results in problems recognizing the
-                <filename>--with-libtool-sysroot=</filename><replaceable>sysroot-dir</replaceable> option,
-                regenerate the script to enable the support by doing the following and then
-                run the script again:
-                <literallayout class='monospaced'>
-     $ libtoolize --automake
-     $ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \
-        [-I <replaceable>dir_containing_your_project-specific_m4_macros</replaceable>]
-     $ autoconf
-     $ autoheader
-     $ automake -a
-                </literallayout>
-            </note>
-        </para>
-    </section>
-</section>
-
-<section id='makefile-based-projects'>
-<title>Makefile-Based Projects</title>
-
-    <para>
-        For Makefile-based projects, the cross-toolchain environment variables
-        established by running the cross-toolchain environment setup script
-        are subject to general <filename>make</filename> rules.
-    </para>
-
-    <para>
-        To illustrate this, consider the following four cross-toolchain
-        environment variables:
-        <literallayout class='monospaced'>
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-CC'>CC</ulink>=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-LD'>LD</ulink>=i586-poky-linux-ld --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-CFLAGS'>CFLAGS</ulink>=-O2 -pipe -g -feliminate-unused-debug-types
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-CXXFLAGS'>CXXFLAGS</ulink>=-O2 -pipe -g -feliminate-unused-debug-types
-        </literallayout>
-        Now, consider the following three cases:
-        <itemizedlist>
-            <listitem><para><emphasis>Case 1 - No Variables Set in the <filename>Makefile</filename>:</emphasis>
-                Because these variables are not specifically set in the
-                <filename>Makefile</filename>, the variables retain their
-                values based on the environment.
-                </para></listitem>
-            <listitem><para><emphasis>Case 2 - Variables Set in the <filename>Makefile</filename>:</emphasis>
-                Specifically setting variables in the
-                <filename>Makefile</filename> during the build results in the
-                environment settings of the variables being overwritten.
-                </para></listitem>
-            <listitem><para><emphasis>Case 3 - Variables Set when the <filename>Makefile</filename> is Executed from the Command Line:</emphasis>
-                Executing the <filename>Makefile</filename> from the command
-                line results in the variables being overwritten with
-                command-line content regardless of what is being set in the
-                <filename>Makefile</filename>.
-                In this case, environment variables are not considered unless
-                you use the "-e" flag during the build:
-                <literallayout class='monospaced'>
-     $ make -e <replaceable>file</replaceable>
-                </literallayout>
-                If you use this flag, then the environment values of the
-                variables override any variables specifically set in the
-                <filename>Makefile</filename>.
-                </para></listitem>
-        </itemizedlist>
-        <note>
-            For the list of variables set up by the cross-toolchain environment
-            setup script, see the
-            "<link linkend='setting-up-the-cross-development-environment'>Setting Up the Cross-Development Environment</link>"
-            section.
-        </note>
-    </para>
-</section>
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->

documentation/adt-manual/adt-intro.xml

@@ -1,180 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
-[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
-
-<chapter id='adt-intro'>
-    <title>The Application Development Toolkit (ADT)</title>
-
-    <para>
-        Part of the Yocto Project development solution is an Application Development
-        Toolkit (ADT).
-        The ADT provides you with a custom-built, cross-development
-        platform suited for developing a user-targeted product application.
-    </para>
-
-    <para>
-        Fundamentally, the ADT consists of the following:
-        <itemizedlist>
-            <listitem><para>An architecture-specific cross-toolchain and matching
-                sysroot both built by the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#build-system-term'>OpenEmbedded build system</ulink>.
-                The toolchain and sysroot are based on a
-                <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
-                configuration and extensions,
-                which allows you to cross-develop on the host machine for the target hardware.
-                </para></listitem>
-            <listitem><para>The Eclipse IDE Yocto Plug-in.</para></listitem>
-            <listitem><para>The Quick EMUlator (QEMU), which lets you simulate target hardware.
-                </para></listitem>
-            <listitem><para>Various user-space tools that greatly enhance your application
-                development experience.</para></listitem>
-        </itemizedlist>
-    </para>
-
-    <section id='the-cross-development-toolchain'>
-        <title>The Cross-Development Toolchain</title>
-
-        <para>
-            The
-            <ulink url='&YOCTO_DOCS_DEV_URL;#cross-development-toolchain'>Cross-Development Toolchain</ulink>
-            consists of a cross-compiler, cross-linker, and cross-debugger
-            that are used to develop user-space applications for targeted
-            hardware.
-            This toolchain is created either by running the ADT Installer
-            script, a toolchain installer script, or through a
-            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
-            that is based on your Metadata configuration or extension for
-            your targeted device.
-            The cross-toolchain works with a matching target sysroot.
-        </para>
-    </section>
-
-    <section id='sysroot'>
-        <title>Sysroot</title>
-
-        <para>
-            The matching target sysroot contains needed headers and libraries for generating
-            binaries that run on the target architecture.
-            The sysroot is based on the target root filesystem image that is built by
-            the OpenEmbedded build system and uses the same Metadata configuration
-            used to build the cross-toolchain.
-        </para>
-    </section>
-
-    <section id='eclipse-overview'>
-        <title>Eclipse Yocto Plug-in</title>
-
-        <para>
-            The Eclipse IDE is a popular development environment and it fully supports
-            development using the Yocto Project.
-            When you install and configure the Eclipse Yocto Project Plug-in into
-            the Eclipse IDE, you maximize your Yocto Project experience.
-            Installing and configuring the Plug-in results in an environment that
-            has extensions specifically designed to let you more easily develop software.
-            These extensions allow for cross-compilation, deployment, and execution of
-            your output into a QEMU emulation session.
-            You can also perform cross-debugging and profiling.
-            The environment also supports a suite of tools that allows you to perform
-            remote profiling, tracing, collection of power data, collection of
-            latency data, and collection of performance data.
-        </para>
-
-        <para>
-            For information about the application development workflow that uses the Eclipse
-            IDE and for a detailed example of how to install and configure the Eclipse
-            Yocto Project Plug-in, see the
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#adt-eclipse'>Working Within Eclipse</ulink>" section
-            of the Yocto Project Development Manual.
-        </para>
-    </section>
-
-    <section id='the-qemu-emulator'>
-        <title>The QEMU Emulator</title>
-
-        <para>
-            The QEMU emulator allows you to simulate your hardware while running your
-            application or image.
-            QEMU is made available a number of ways:
-            <itemizedlist>
-                <listitem><para>
-                    If you use the ADT Installer script to install ADT, you can
-                    specify whether or not to install QEMU.
-                    </para></listitem>
-                <listitem><para>
-                    If you have cloned the <filename>poky</filename> Git
-                    repository to create a
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
-                    and you have sourced the environment setup script, QEMU is
-                    installed and automatically available.
-                    </para></listitem>
-                <listitem><para>
-                    If you have downloaded a Yocto Project release and unpacked
-                    it to create a
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
-                    and you have sourced the environment setup script, QEMU is
-                    installed and automatically available.
-                    </para></listitem>
-                <listitem><para>
-                    If you have installed the cross-toolchain tarball and you
-                    have sourced the toolchain's setup environment script, QEMU
-                    is also installed and automatically available.
-                    </para></listitem>
-            </itemizedlist>
-        </para>
-    </section>
-
-    <section id='user-space-tools'>
-        <title>User-Space Tools</title>
-
-        <para>
-            User-space tools are included as part of the Yocto Project.
-            You will find these tools helpful during development.
-            The tools include LatencyTOP, PowerTOP, OProfile, Perf, SystemTap, and Lttng-ust.
-            These tools are common development tools for the Linux platform.
-            <itemizedlist>
-                <listitem><para><emphasis>LatencyTOP:</emphasis> LatencyTOP focuses on latency
-                    that causes skips in audio,
-                    stutters in your desktop experience, or situations that overload your server
-                    even when you have plenty of CPU power left.
-                    </para></listitem>
-                <listitem><para><emphasis>PowerTOP:</emphasis> Helps you determine what
-                    software is using the most power.
-                    You can find out more about PowerTOP at
-                    <ulink url='https://01.org/powertop/'></ulink>.</para></listitem>
-                <listitem><para><emphasis>OProfile:</emphasis> A system-wide profiler for Linux
-                    systems that is capable of profiling all running code at low overhead.
-                    You can find out more about OProfile at
-                    <ulink url='http://oprofile.sourceforge.net/about/'></ulink>.
-                    For examples on how to setup and use this tool, see the
-                    "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-oprofile'>OProfile</ulink>"
-                    section in the Yocto Project Profiling and Tracing Manual.
-                    </para></listitem>
-                <listitem><para><emphasis>Perf:</emphasis> Performance counters for Linux used
-                    to keep track of certain types of hardware and software events.
-                    For more information on these types of counters see
-                    <ulink url='https://perf.wiki.kernel.org/'></ulink>.
-                    For examples on how to setup and use this tool, see the
-                    "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-perf'>perf</ulink>"
-                    section in the Yocto Project Profiling and Tracing Manual.
-                    </para></listitem>
-                <listitem><para><emphasis>SystemTap:</emphasis> A free software infrastructure
-                    that simplifies information gathering about a running Linux system.
-                    This information helps you diagnose performance or functional problems.
-                    SystemTap is not available as a user-space tool through the Eclipse IDE Yocto Plug-in.
-                    See <ulink url='http://sourceware.org/systemtap'></ulink> for more information
-                    on SystemTap.
-                    For examples on how to setup and use this tool, see the
-                    "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-systemtap'>SystemTap</ulink>"
-                    section in the Yocto Project Profiling and Tracing Manual.</para></listitem>
-                <listitem><para><emphasis>Lttng-ust:</emphasis> A User-space Tracer designed to
-                    provide detailed information on user-space activity.
-                    See <ulink url='http://lttng.org/ust'></ulink> for more information on Lttng-ust.
-                    </para></listitem>
-            </itemizedlist>
-        </para>
-    </section>
-
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->

documentation/adt-manual/adt-manual-customization.xsl

@@ -1,27 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
-
-  <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
-
-<!--
-
-  <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
-
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
-
--->
-
-  <xsl:include href="../template/permalinks.xsl"/>
-  <xsl:include href="../template/section.title.xsl"/>
-  <xsl:include href="../template/component.title.xsl"/>
-  <xsl:include href="../template/division.title.xsl"/>
-  <xsl:include href="../template/formal.object.heading.xsl"/>
-
-  <xsl:param name="html.stylesheet" select="'adt-style.css'" />
-  <xsl:param name="chapter.autolabel" select="1" />
-  <xsl:param name="appendix.autolabel" select="A" />
-  <xsl:param name="section.autolabel" select="1" />
-  <xsl:param name="section.label.includes.component.label" select="1" />
-  <xsl:param name="generate.id.attributes" select="1" />
-
-</xsl:stylesheet>

documentation/adt-manual/adt-manual-eclipse-customization.xsl

@@ -1,35 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet
-	xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
-	xmlns="http://www.w3.org/1999/xhtml"
-	xmlns:fo="http://www.w3.org/1999/XSL/Format"
-	version="1.0">
-
-  <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" />
-
-<!--
-
-  <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" />
-
-  <xsl:import
-	  href="http://docbook.sourceforge.net/release/xsl/1.76.1/eclipse/eclipse3.xsl" />
-
--->
-
-  <xsl:param name="chunker.output.indent" select="'yes'"/>
-  <xsl:param name="chunk.quietly" select="1"/>
-  <xsl:param name="chunk.first.sections" select="1"/>
-  <xsl:param name="chunk.section.depth" select="10"/>
-  <xsl:param name="use.id.as.filename" select="1"/>
-  <xsl:param name="ulink.target" select="'_self'" />
-  <xsl:param name="base.dir" select="'html/adt-manual/'"/>
-  <xsl:param name="html.stylesheet" select="'../book.css'"/>
-  <xsl:param name="eclipse.manifest" select="0"/>
-  <xsl:param name="create.plugin.xml" select="0"/>
-  <xsl:param name="suppress.navigation" select="1"/>
-  <xsl:param name="generate.index" select="0"/>
-  <xsl:param name="chapter.autolabel" select="1" />
-  <xsl:param name="appendix.autolabel" select="1" />
-  <xsl:param name="section.autolabel" select="1" />
-  <xsl:param name="section.label.includes.component.label" select="1" />
-</xsl:stylesheet>

documentation/adt-manual/adt-manual-intro.xml

@@ -1,33 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
-[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
-
-<chapter id='adt-manual-intro'>
-<title>Introduction</title>
-
-    <para>
-        Welcome to the Yocto Project Application Developer's Guide.
-        This manual provides information that lets you begin developing applications
-        using the Yocto Project.
-    </para>
-
-    <para>
-        The Yocto Project provides an application development environment based on
-        an Application Development Toolkit (ADT) and the availability of stand-alone
-        cross-development toolchains and other tools.
-        This manual describes the ADT and how you can configure and install it,
-        how to access and use the cross-development toolchains, how to
-        customize the development packages installation,
-        how to use command-line development for both Autotools-based and
-        Makefile-based projects, and an introduction to the
-        <trademark class='trade'>Eclipse</trademark> IDE Yocto Plug-in.
-        <note>
-            The ADT is distribution-neutral and does not require the Yocto
-            Project reference distribution, which is called Poky.
-            This manual, however, uses examples that use the Poky distribution.
-        </note>
-    </para>
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->

documentation/adt-manual/adt-manual.xml

@@ -1,140 +0,0 @@
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
-[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
-
-<book id='adt-manual' lang='en'
-      xmlns:xi="http://www.w3.org/2003/XInclude"
-      xmlns="http://docbook.org/ns/docbook"
-      >
-    <bookinfo>
-
-        <mediaobject>
-            <imageobject>
-                <imagedata fileref='figures/adt-title.png'
-                    format='SVG'
-                    align='left' scalefit='1' width='100%'/>
-            </imageobject>
-        </mediaobject>
-
-        <title>
-            Yocto Project Application Developer's Guide
-        </title>
-
-        <authorgroup>
-            <author>
-                <firstname>Jessica</firstname> <surname>Zhang</surname>
-                <affiliation>
-                    <orgname>Intel Corporation</orgname>
-                </affiliation>
-                <email>jessica.zhang@intel.com</email>
-            </author>
-        </authorgroup>
-
-        <revhistory>
-            <revision>
-                <revnumber>1.0</revnumber>
-                <date>6 April 2011</date>
-                <revremark>Released with the Yocto Project 1.0 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.0.1</revnumber>
-                <date>23 May 2011</date>
-                <revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.1</revnumber>
-                <date>6 October 2011</date>
-                <revremark>Released with the Yocto Project 1.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.2</revnumber>
-                <date>April 2012</date>
-                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.3</revnumber>
-                <date>October 2012</date>
-                <revremark>Released with the Yocto Project 1.3 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.4</revnumber>
-                <date>April 2013</date>
-                <revremark>Released with the Yocto Project 1.4 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.5</revnumber>
-                <date>October 2013</date>
-                <revremark>Released with the Yocto Project 1.5 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.5.1</revnumber>
-                <date>January 2014</date>
-                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.6</revnumber>
-                <date>April 2014</date>
-                <revremark>Released with the Yocto Project 1.6 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.7</revnumber>
-                <date>October 2014</date>
-                <revremark>Released with the Yocto Project 1.7 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.8</revnumber>
-                <date>April 2015</date>
-                <revremark>Released with the Yocto Project 1.8 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.0</revnumber>
-                <date>October 2015</date>
-                <revremark>Released with the Yocto Project 2.0 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.1</revnumber>
-                <date>Sometime in 2016</date>
-                <revremark>Released with the future Yocto Project 2.1 Release.</revremark>
-            </revision>
-       </revhistory>
-
-    <copyright>
-      <year>&COPYRIGHT_YEAR;</year>
-      <holder>Linux Foundation</holder>
-    </copyright>
-
-    <legalnotice>
-      <para>
-        Permission is granted to copy, distribute and/or modify this document under
-        the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
-      </para>
-      <note>
-          For the latest version of this manual associated with this
-          Yocto Project release, see the
-          <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>
-          from the Yocto Project website.
-      </note>
-
-    </legalnotice>
-
-    </bookinfo>
-
-    <xi:include href="adt-manual-intro.xml"/>
-
-    <xi:include href="adt-intro.xml"/>
-
-    <xi:include href="adt-prepare.xml"/>
-
-    <xi:include href="adt-package.xml"/>
-
-    <xi:include href="adt-command.xml"/>
-
-<!--    <index id='index'>
-      <title>Index</title>
-    </index>
--->
-
-</book>
-<!--
-vim: expandtab tw=80 ts=4
--->

documentation/adt-manual/adt-package.xml

@@ -1,102 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
-[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
-
-<chapter id='adt-package'>
-<title>Optionally Customizing the Development Packages Installation</title>
-
-    <para>
-        Because the Yocto Project is suited for embedded Linux development, it is
-        likely that you will need to customize your development packages installation.
-        For example, if you are developing a minimal image, then you might not need
-        certain packages (e.g. graphics support packages).
-        Thus, you would like to be able to remove those packages from your target sysroot.
-    </para>
-
-<section id='package-management-systems'>
-    <title>Package Management Systems</title>
-
-    <para>
-        The OpenEmbedded build system supports the generation of sysroot files using
-        three different Package Management Systems (PMS):
-        <itemizedlist>
-            <listitem><para><emphasis>OPKG:</emphasis> A less well known PMS whose use
-                originated in the OpenEmbedded and OpenWrt embedded Linux projects.
-                This PMS works with files packaged in an <filename>.ipk</filename> format.
-                See <ulink url='http://en.wikipedia.org/wiki/Opkg'></ulink> for more
-                information about OPKG.</para></listitem>
-            <listitem><para><emphasis>RPM:</emphasis> A more widely known PMS intended for GNU/Linux
-                distributions.
-                This PMS works with files packaged in an <filename>.rpm</filename> format.
-                The build system currently installs through this PMS by default.
-                See <ulink url='http://en.wikipedia.org/wiki/RPM_Package_Manager'></ulink>
-                for more information about RPM.</para></listitem>
-            <listitem><para><emphasis>Debian:</emphasis> The PMS for Debian-based systems
-                is built on many PMS tools.
-                The lower-level PMS tool <filename>dpkg</filename> forms the base of the Debian PMS.
-                For information on dpkg see
-                <ulink url='http://en.wikipedia.org/wiki/Dpkg'></ulink>.</para></listitem>
-        </itemizedlist>
-    </para>
-</section>
-
-<section id='configuring-the-pms'>
-    <title>Configuring the PMS</title>
-
-    <para>
-        Whichever PMS you are using, you need to be sure that the
-        <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink>
-        variable in the <filename>conf/local.conf</filename>
-        file is set to reflect that system.
-        The first value you choose for the variable specifies the package file format for the root
-        filesystem at sysroot.
-        Additional values specify additional formats for convenience or testing.
-        See the <filename>conf/local.conf</filename> configuration file for
-        details.
-    </para>
-
-    <note>
-        For build performance information related to the PMS, see the
-        "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'><filename>package.bbclass</filename></ulink>"
-        section in the Yocto Project Reference Manual.
-    </note>
-
-    <para>
-        As an example, consider a scenario where you are using OPKG and you want to add
-        the <filename>libglade</filename> package to the target sysroot.
-    </para>
-
-    <para>
-        First, you should generate the IPK file for the
-        <filename>libglade</filename> package and add it
-        into a working <filename>opkg</filename> repository.
-        Use these commands:
-        <literallayout class='monospaced'>
-     $ bitbake libglade
-     $ bitbake package-index
-        </literallayout>
-    </para>
-
-    <para>
-        Next, source the cross-toolchain environment setup script found in the
-        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
-        Follow that by setting up the installation destination to point to your
-        sysroot as <replaceable>sysroot_dir</replaceable>.
-        Finally, have an OPKG configuration file <replaceable>conf_file</replaceable>
-        that corresponds to the <filename>opkg</filename> repository you have just created.
-        The following command forms should now work:
-        <literallayout class='monospaced'>
-     $ opkg-cl –f <replaceable>conf_file</replaceable> -o <replaceable>sysroot_dir</replaceable> update
-     $ opkg-cl –f <replaceable>cconf_file</replaceable> -o <replaceable>sysroot_dir</replaceable> \
-        --force-overwrite install libglade
-     $ opkg-cl –f <replaceable>cconf_file</replaceable> -o <replaceable>sysroot_dir</replaceable> \
-        --force-overwrite install libglade-dbg
-     $ opkg-cl –f <replaceable>conf_file&gt; -o </replaceable>sysroot_dir&gt; \
-        --force-overwrite install libglade-dev
-        </literallayout>
-    </para>
-</section>
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->

documentation/adt-manual/adt-prepare.xml

@@ -1,999 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
-[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
-
-<chapter id='adt-prepare'>
-
-<title>Preparing for Application Development</title>
-
-<para>
-    In order to develop applications, you need set up your host development system.
-    Several ways exist that allow you to install cross-development tools, QEMU, the
-    Eclipse Yocto Plug-in, and other tools.
-    This chapter describes how to prepare for application development.
-</para>
-
-<section id='installing-the-adt'>
-    <title>Installing the ADT and Toolchains</title>
-
-    <para>
-        The following list describes installation methods that set up varying
-        degrees of tool availability on your system.
-        Regardless of the installation method you choose,
-        you must <filename>source</filename> the cross-toolchain
-        environment setup script, which establishes several key
-        environment variables, before you use a toolchain.
-        See the
-        "<link linkend='setting-up-the-cross-development-environment'>Setting Up the Cross-Development Environment</link>"
-        section for more information.
-    </para>
-
-    <note>
-        <para>
-            Avoid mixing installation methods when installing toolchains for
-            different architectures.
-            For example, avoid using the ADT Installer to install some
-            toolchains and then hand-installing cross-development toolchains
-            by running the toolchain installer for different architectures.
-            Mixing installation methods can result in situations where the
-            ADT Installer becomes unreliable and might not install the
-            toolchain.
-        </para>
-
-        <para>
-            If you must mix installation methods, you might avoid problems by
-            deleting <filename>/var/lib/opkg</filename>, thus purging the
-            <filename>opkg</filename> package metadata.
-        </para>
-    </note>
-
-    <para>
-        <itemizedlist>
-            <listitem><para><emphasis>Use the ADT installer script:</emphasis>
-                This method is the recommended way to install the ADT because it
-                automates much of the process for you.
-                For example, you can configure the installation to install the QEMU emulator
-                and the user-space NFS, specify which root filesystem profiles to download,
-                and define the target sysroot location.</para></listitem>
-            <listitem><para><emphasis>Use an existing toolchain:</emphasis>
-                Using this method, you select and download an architecture-specific
-                toolchain installer and then run the script to hand-install the toolchain.
-                If you use this method, you just get the cross-toolchain and QEMU - you do not
-                get any of the other mentioned benefits had you run the ADT Installer script.</para></listitem>
-            <listitem><para><emphasis>Use the toolchain from within the Build Directory:</emphasis>
-                If you already have a
-                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
-                you can build the cross-toolchain within the directory.
-                However, like the previous method mentioned, you only get the cross-toolchain and QEMU - you
-                do not get any of the other benefits without taking separate steps.</para></listitem>
-        </itemizedlist>
-    </para>
-
-    <section id='using-the-adt-installer'>
-        <title>Using the ADT Installer</title>
-
-        <para>
-            To run the ADT Installer, you need to get the ADT Installer tarball, be sure
-            you have the necessary host development packages that support the ADT Installer,
-            and then run the ADT Installer Script.
-        </para>
-
-        <para>
-            For a list of the host packages needed to support ADT installation and use, see the
-            "ADT Installer Extras" lists in the
-            "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>" section
-            of the Yocto Project Reference Manual.
-        </para>
-
-        <section id='getting-the-adt-installer-tarball'>
-            <title>Getting the ADT Installer Tarball</title>
-
-            <para>
-                The ADT Installer is contained in the ADT Installer tarball.
-                You can get the tarball using either of these methods:
-                <itemizedlist>
-                    <listitem><para><emphasis>Download the Tarball:</emphasis>
-                        You can download the tarball from
-                        <ulink url='&YOCTO_ADTINSTALLER_DL_URL;'></ulink> into
-                        any directory.</para></listitem>
-                    <listitem><para><emphasis>Build the Tarball:</emphasis>
-                        You can use
-                        <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
-                        to generate the tarball inside an existing
-                        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
-                        </para>
-                        <para>If you use BitBake to generate the ADT Installer
-                        tarball, you must <filename>source</filename> the
-                        environment setup script
-                        (<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
-                        or
-                        <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
-                        located in the Source Directory before running the
-                        <filename>bitbake</filename> command that creates the
-                        tarball.</para>
-                        <para>The following example commands establish
-                        the
-                        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
-                        check out the current release branch, set up the
-                        build environment while also creating the default
-                        Build Directory, and run the
-                        <filename>bitbake</filename> command that results in the
-                        tarball
-                        <filename>poky/build/tmp/deploy/sdk/adt_installer.tar.bz2</filename>:
-                        <note>
-                            Before using BitBake to build the ADT tarball, be
-                            sure to make sure your
-                            <filename>local.conf</filename> file is properly
-                            configured.
-                            See the
-                            "<ulink url='&YOCTO_DOCS_REF_URL;#user-configuration'>User Configuration</ulink>"
-                            section in the Yocto Project Reference Manual for
-                            general configuration information.
-                        </note>
-                        <literallayout class='monospaced'>
-     $ cd ~
-     $ git clone git://git.yoctoproject.org/poky
-     $ cd poky
-     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
-     $ source &OE_INIT_FILE;
-     $ bitbake adt-installer
-                        </literallayout></para></listitem>
-                </itemizedlist>
-            </para>
-        </section>
-
-        <section id='configuring-and-running-the-adt-installer-script'>
-            <title>Configuring and Running the ADT Installer Script</title>
-
-            <para>
-                Before running the ADT Installer script, you need to unpack the tarball.
-                You can unpack the tarball in any directory you wish.
-                For example, this command copies the ADT Installer tarball from where
-                it was built into the home directory and then unpacks the tarball into
-                a top-level directory named <filename>adt-installer</filename>:
-                <literallayout class='monospaced'>
-     $ cd ~
-     $ cp poky/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME
-     $ tar -xjf adt_installer.tar.bz2
-                </literallayout>
-                Unpacking it creates the directory <filename>adt-installer</filename>,
-                which contains the ADT Installer script (<filename>adt_installer</filename>)
-                and its configuration file (<filename>adt_installer.conf</filename>).
-            </para>
-
-            <para>
-                Before you run the script, however, you should examine the ADT Installer configuration
-                file and be sure you are going to get what you want.
-                Your configurations determine which kernel and filesystem image are downloaded.
-            </para>
-
-            <para>
-                The following list describes the configurations you can define for the ADT Installer.
-                For configuration values and restrictions, see the comments in
-                the <filename>adt-installer.conf</filename> file:
-
-                <itemizedlist>
-                    <listitem><para><filename>YOCTOADT_REPO</filename>: This area
-                        includes the IPKG-based packages and the root filesystem upon which
-                        the installation is based.
-                        If you want to set up your own IPKG repository pointed to by
-                        <filename>YOCTOADT_REPO</filename>, you need to be sure that the
-                        directory structure follows the same layout as the reference directory
-                        set up at <ulink url='http://adtrepo.yoctoproject.org'></ulink>.
-                        Also, your repository needs to be accessible through HTTP.</para></listitem>
-                    <listitem><para><filename>YOCTOADT_TARGETS</filename>: The machine
-                        target architectures for which you want to set up cross-development
-                        environments.</para></listitem>
-                    <listitem><para><filename>YOCTOADT_QEMU</filename>: Indicates whether
-                        or not to install the emulator QEMU.</para></listitem>
-                    <listitem><para><filename>YOCTOADT_NFS_UTIL</filename>: Indicates whether
-                        or not to install user-mode NFS.
-                        If you plan to use the Eclipse IDE Yocto plug-in against QEMU,
-                        you should install NFS.
-                        <note>To boot QEMU images using our userspace NFS server, you need
-                            to be running <filename>portmap</filename> or <filename>rpcbind</filename>.
-                            If you are running <filename>rpcbind</filename>, you will also need to add the
-                            <filename>-i</filename> option when <filename>rpcbind</filename> starts up.
-                            Please make sure you understand the security implications of doing this.
-                            You might also have to modify your firewall settings to allow
-                            NFS booting to work.</note></para></listitem>
-                    <listitem><para><filename>YOCTOADT_ROOTFS_</filename><replaceable>arch</replaceable>: The root
-                        filesystem images you want to download from the
-                        <filename>YOCTOADT_IPKG_REPO</filename> repository.</para></listitem>
-                    <listitem><para><filename>YOCTOADT_TARGET_SYSROOT_IMAGE_</filename><replaceable>arch</replaceable>: The
-                        particular root filesystem used to extract and create the target sysroot.
-                        The value of this variable must have been specified with
-                        <filename>YOCTOADT_ROOTFS_</filename><replaceable>arch</replaceable>.
-                        For example, if you downloaded both <filename>minimal</filename> and
-                        <filename>sato-sdk</filename> images by setting
-                        <filename>YOCTOADT_ROOTFS_</filename><replaceable>arch</replaceable>
-                        to "minimal sato-sdk", then <filename>YOCTOADT_ROOTFS_</filename><replaceable>arch</replaceable>
-                        must be set to either "minimal" or "sato-sdk".
-                        </para></listitem>
-                    <listitem><para><filename>YOCTOADT_TARGET_SYSROOT_LOC_</filename><replaceable>arch</replaceable>: The
-                        location on the development host where the target sysroot is created.
-                        </para></listitem>
-                </itemizedlist>
-            </para>
-
-            <para>
-                After you have configured the <filename>adt_installer.conf</filename> file,
-                run the installer using the following command:
-                <literallayout class='monospaced'>
-     $ cd adt-installer
-     $ ./adt_installer
-                </literallayout>
-                Once the installer begins to run, you are asked to enter the
-                location for cross-toolchain installation.
-                The default location is
-                <filename>/opt/poky/</filename><replaceable>release</replaceable>.
-                After either accepting the default location or selecting your
-                own location, you are prompted to run the installation script
-                interactively or in silent mode.
-                If you want to closely monitor the installation,
-                choose “I” for interactive mode rather than “S” for silent mode.
-                Follow the prompts from the script to complete the installation.
-            </para>
-
-            <para>
-                Once the installation completes, the ADT, which includes the
-                cross-toolchain, is installed in the selected installation
-                directory.
-                You will notice environment setup files for the cross-toolchain
-                in the installation directory, and image tarballs in the
-                <filename>adt-installer</filename> directory according to your
-                installer configurations, and the target sysroot located
-                according to the
-                <filename>YOCTOADT_TARGET_SYSROOT_LOC_</filename><replaceable>arch</replaceable>
-                variable also in your configuration file.
-            </para>
-         </section>
-    </section>
-
-    <section id='using-an-existing-toolchain-tarball'>
-        <title>Using a Cross-Toolchain Tarball</title>
-
-        <para>
-            If you want to simply install a cross-toolchain by hand, you can
-            do so by running the toolchain installer.
-            The installer includes the pre-built cross-toolchain, the
-            <filename>runqemu</filename> script, and support files.
-            If you use this method to install the cross-toolchain, you
-            might still need to install the target sysroot by installing and
-            extracting it separately.
-            For information on how to install the sysroot, see the
-            "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>" section.
-        </para>
-
-        <para>
-            Follow these steps:
-            <orderedlist>
-                <listitem><para><emphasis>Get your toolchain installer using one of the following methods:</emphasis>
-                    <itemizedlist>
-                        <listitem><para>Go to
-                            <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>
-                            and find the folder that matches your host
-                            development system (i.e. <filename>i686</filename>
-                            for 32-bit machines or <filename>x86_64</filename>
-                            for 64-bit machines).</para>
-                            <para>Go into that folder and download the toolchain
-                            installer whose name includes the appropriate target
-                            architecture.
-                            The toolchains provided by the Yocto Project
-                            are based off of the
-                            <filename>core-image-sato</filename> image and
-                            contain libraries appropriate for developing
-                            against that image.
-                            For example, if your host development system is a
-                            64-bit x86 system and you are going to use
-                            your cross-toolchain for a 32-bit x86
-                            target, go into the <filename>x86_64</filename>
-                            folder and download the following installer:
-                            <literallayout class='monospaced'>
-     poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
-                            </literallayout></para></listitem>
-                        <listitem><para>Build your own toolchain installer.
-                            For cases where you cannot use an installer
-                            from the download area, you can build your own as
-                            described in the
-                            "<link linkend='optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</link>"
-                            section.</para></listitem>
-                    </itemizedlist></para></listitem>
-                <listitem><para><emphasis>Once you have the installer, run it to install the toolchain:</emphasis>
-                    <note>
-                        You must change the permissions on the toolchain
-                        installer script so that it is executable.
-                    </note></para>
-                    <para>The following command shows how to run the installer
-                    given a toolchain tarball for a 64-bit x86 development host
-                    system and a 32-bit x86 target architecture.
-                    The example assumes the toolchain installer is located
-                    in <filename>~/Downloads/</filename>.
-                    <literallayout class='monospaced'>
-     $ ~/Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
-                    </literallayout>
-                    The first thing the installer prompts you for is the
-                    directory into which you want to install the toolchain.
-                    The default directory used is
-                    <filename>/opt/poky/&DISTRO;</filename>.
-                    If you do not have write permissions for the directory
-                    into which you are installing the toolchain, the
-                    toolchain installer notifies you and exits.
-                    Be sure you have write permissions in the directory and
-                    run the installer again.</para>
-                    <para>When the script finishes, the cross-toolchain is
-                    installed.
-                    You will notice environment setup files for the
-                    cross-toolchain in the installation directory.
-                    </para></listitem>
-            </orderedlist>
-        </para>
-    </section>
-
-    <section id='using-the-toolchain-from-within-the-build-tree'>
-        <title>Using BitBake and the Build Directory</title>
-
-        <para>
-            A final way of making the cross-toolchain available is to use BitBake
-            to generate the toolchain within an existing
-            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
-            This method does not install the toolchain into the default
-            <filename>/opt</filename> directory.
-            As with the previous method, if you need to install the target sysroot, you must
-            do that separately as well.
-        </para>
-
-        <para>
-            Follow these steps to generate the toolchain into the Build Directory:
-            <orderedlist>
-                <listitem><para><emphasis>Set up the Build Environment:</emphasis>
-                    Source the OpenEmbedded build environment setup
-                    script (i.e.
-                    <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
-                    or
-                    <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
-                    located in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
-                    </para></listitem>
-                <listitem><para><emphasis>Check your Local Configuration File:</emphasis>
-                    At this point, you should be sure that the
-                    <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> variable
-                    in the <filename>local.conf</filename> file found in the
-                    <filename>conf</filename> directory of the Build Directory
-                    is set for the target architecture.
-                    Comments within the <filename>local.conf</filename> file
-                    list the values you can use for the
-                    <filename>MACHINE</filename> variable.
-                    If you do not change the <filename>MACHINE</filename>
-                    variable, the OpenEmbedded build system uses
-                    <filename>qemux86</filename> as the default target
-                    machine when building the cross-toolchain.
-                    <note>
-                        You can populate the Build Directory with the
-                        cross-toolchains for more than a single architecture.
-                        You just need to edit the <filename>MACHINE</filename>
-                        variable in the <filename>local.conf</filename> file and
-                        re-run the <filename>bitbake</filename> command.
-                    </note></para></listitem>
-                <listitem><para><emphasis>Make Sure Your Layers are Enabled:</emphasis>
-                    Examine the <filename>conf/bblayers.conf</filename> file
-                    and make sure that you have enabled all the compatible
-                    layers for your target machine.
-                    The OpenEmbedded build system needs to be aware of each
-                    layer you want included when building images and
-                    cross-toolchains.
-                    For information on how to enable a layer, see the
-                    "<ulink url='&YOCTO_DOCS_DEV_URL;#enabling-your-layer'>Enabling Your Layer</ulink>"
-                    section in the Yocto Project Development Manual.
-                    </para></listitem>
-                <listitem><para><emphasis>Generate the Cross-Toolchain:</emphasis>
-                    Run <filename>bitbake meta-ide-support</filename> to
-                    complete the cross-toolchain generation.
-                    Once the <filename>bitbake</filename> command finishes,
-                    the cross-toolchain is
-                    generated and populated within the Build Directory.
-                    You will notice environment setup files for the
-                    cross-toolchain that contain the string
-                    "<filename>environment-setup</filename>" in the
-                    Build Directory's <filename>tmp</filename> folder.</para>
-                    <para>Be aware that when you use this method to install the
-                    toolchain, you still need to separately extract and install
-                    the sysroot filesystem.
-                    For information on how to do this, see the
-                    "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>" section.
-                    </para></listitem>
-            </orderedlist>
-        </para>
-    </section>
-</section>
-
-<section id='setting-up-the-cross-development-environment'>
-    <title>Setting Up the Cross-Development Environment</title>
-
-    <para>
-        Before you can develop using the cross-toolchain, you need to set up the
-        cross-development environment by sourcing the toolchain's environment setup script.
-        If you used the ADT Installer or hand-installed cross-toolchain,
-        then you can find this script in the directory you chose for installation.
-        For this release, the default installation directory is
-        <filename>&YOCTO_ADTPATH_DIR;</filename>.
-        If you installed the toolchain in the
-        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
-        you can find the environment setup
-        script for the toolchain in the Build Directory's <filename>tmp</filename> directory.
-    </para>
-
-    <para>
-        Be sure to run the environment setup script that matches the
-        architecture for which you are developing.
-        Environment setup scripts begin with the string
-        "<filename>environment-setup</filename>" and include as part of their
-        name the architecture.
-        For example, the toolchain environment setup script for a 64-bit
-        IA-based architecture installed in the default installation directory
-        would be the following:
-        <literallayout class='monospaced'>
-     &YOCTO_ADTPATH_DIR;/environment-setup-x86_64-poky-linux
-        </literallayout>
-        When you run the setup script, many environment variables are
-        defined:
-        <literallayout class='monospaced'>
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKTARGETSYSROOT'><filename>SDKTARGETSYSROOT</filename></ulink> - The path to the sysroot used for cross-compilation
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-PKG_CONFIG_PATH'><filename>PKG_CONFIG_PATH</filename></ulink> - The path to the target pkg-config files
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-CONFIG_SITE'><filename>CONFIG_SITE</filename></ulink> - A GNU autoconf site file preconfigured for the target
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-CC'><filename>CC</filename></ulink> - The minimal command and arguments to run the C compiler
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-CXX'><filename>CXX</filename></ulink> - The minimal command and arguments to run the C++ compiler
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-CPP'><filename>CPP</filename></ulink> - The minimal command and arguments to run the C preprocessor
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-AS'><filename>AS</filename></ulink> - The minimal command and arguments to run the assembler
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-LD'><filename>LD</filename></ulink> - The minimal command and arguments to run the linker
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-GDB'><filename>GDB</filename></ulink> - The minimal command and arguments to run the GNU Debugger
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-STRIP'><filename>STRIP</filename></ulink> - The minimal command and arguments to run 'strip', which strips symbols
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-RANLIB'><filename>RANLIB</filename></ulink> - The minimal command and arguments to run 'ranlib'
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-OBJCOPY'><filename>OBJCOPY</filename></ulink> - The minimal command and arguments to run 'objcopy'
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-OBJDUMP'><filename>OBJDUMP</filename></ulink> - The minimal command and arguments to run 'objdump'
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-AR'><filename>AR</filename></ulink> - The minimal command and arguments to run 'ar'
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-NM'><filename>NM</filename></ulink> - The minimal command and arguments to run 'nm'
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-TARGET_PREFIX'><filename>TARGET_PREFIX</filename></ulink> - The toolchain binary prefix for the target tools
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-CROSS_COMPILE'><filename>CROSS_COMPILE</filename></ulink> - The toolchain binary prefix for the target tools
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-CONFIGURE_FLAGS'><filename>CONFIGURE_FLAGS</filename></ulink> - The minimal arguments for GNU configure
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-CFLAGS'><filename>CFLAGS</filename></ulink> - Suggested C flags
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-CXXFLAGS'><filename>CXXFLAGS</filename></ulink> - Suggested C++ flags
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-LDFLAGS'><filename>LDFLAGS</filename></ulink> - Suggested linker flags when you use CC to link
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-CPPFLAGS'><filename>CPPFLAGS</filename></ulink> - Suggested preprocessor flags
-        </literallayout>
-    </para>
-</section>
-
-<section id='securing-kernel-and-filesystem-images'>
-    <title>Securing Kernel and Filesystem Images</title>
-
-    <para>
-        You will need to have a kernel and filesystem image to boot using your
-        hardware or the QEMU emulator.
-        Furthermore, if you plan on booting your image using NFS or you want to use the root filesystem
-        as the target sysroot, you need to extract the root filesystem.
-    </para>
-
-    <section id='getting-the-images'>
-        <title>Getting the Images</title>
-
-        <para>
-            To get the kernel and filesystem images, you either have to build them or download
-            pre-built versions.
-            For an example of how to build these images, see the
-            "<ulink url='&YOCTO_DOCS_QS_URL;#qs-buiding-images'>Buiding Images</ulink>"
-            section of the Yocto Project Quick Start.
-            For an example of downloading pre-build versions, see the
-            "<link linkend='using-pre-built'>Example Using Pre-Built Binaries and QEMU</link>"
-            section.
-        </para>
-
-        <para>
-            The Yocto Project ships basic kernel and filesystem images for several
-            architectures (<filename>x86</filename>, <filename>x86-64</filename>,
-            <filename>mips</filename>, <filename>powerpc</filename>, and <filename>arm</filename>)
-            that you can use unaltered in the QEMU emulator.
-            These kernel images reside in the release
-            area - <ulink url='&YOCTO_MACHINES_DL_URL;'></ulink>
-            and are ideal for experimentation using Yocto Project.
-            For information on the image types you can build using the OpenEmbedded build system,
-            see the
-            "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
-            chapter in the Yocto Project Reference Manual.
-        </para>
-
-        <para>
-            If you are planning on developing against your image and you are not
-            building or using one of the Yocto Project development images
-            (e.g. <filename>core-image-*-dev</filename>), you must be sure to
-            include the development packages as part of your image recipe.
-        </para>
-
-        <para>
-            If you plan on remotely deploying and debugging your
-            application from within the Eclipse IDE, you must have an image
-            that contains the Yocto Target Communication Framework (TCF) agent
-            (<filename>tcf-agent</filename>).
-            You can do this by including the <filename>eclipse-debug</filename>
-            image feature.
-            <note>
-                See the
-                "<ulink url='&YOCTO_DOCS_REF_URL;#ref-features-image'>Image Features</ulink>"
-                section in the Yocto Project Reference Manual for information on
-                image features.
-            </note>
-            To include the <filename>eclipse-debug</filename> image feature,
-            modify your <filename>local.conf</filename> file in the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
-            so that the
-            <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES'><filename>EXTRA_IMAGE_FEATURES</filename></ulink>
-            variable includes the "eclipse-debug" feature.
-            After modifying the configuration file, you can rebuild the image.
-            Once the image is rebuilt, the <filename>tcf-agent</filename>
-            will be included in the image and is launched automatically after
-            the boot.
-        </para>
-    </section>
-
-    <section id='extracting-the-root-filesystem'>
-        <title>Extracting the Root Filesystem</title>
-
-        <para>
-            If you install your toolchain by hand or build it using BitBake and
-            you need a root filesystem, you need to extract it separately.
-            If you use the ADT Installer to install the ADT, the root
-            filesystem is automatically extracted and installed.
-        </para>
-
-        <para>
-            Here are some cases where you need to extract the root filesystem:
-            <itemizedlist>
-                <listitem><para>You want to boot the image using NFS.
-                    </para></listitem>
-                <listitem><para>You want to use the root filesystem as the
-                    target sysroot.
-                    For example, the Eclipse IDE environment with the Eclipse
-                    Yocto Plug-in installed allows you to use QEMU to boot
-                    under NFS.</para></listitem>
-                <listitem><para>You want to develop your target application
-                    using the root filesystem as the target sysroot.
-                    </para></listitem>
-            </itemizedlist>
-        </para>
-
-        <para>
-            To extract the root filesystem, first <filename>source</filename>
-            the cross-development environment setup script to establish
-            necessary environment variables.
-            If you built the toolchain in the Build Directory, you will find
-            the toolchain environment script in the
-            <filename>tmp</filename> directory.
-            If you installed the toolchain by hand, the environment setup
-            script is located in <filename>/opt/poky/&DISTRO;</filename>.
-        </para>
-
-        <para>
-            After sourcing the environment script, use the
-            <filename>runqemu-extract-sdk</filename> command and provide the
-            filesystem image.
-        </para>
-
-        <para>
-            Following is an example.
-            The second command sets up the environment.
-            In this case, the setup script is located in the
-            <filename>/opt/poky/&DISTRO;</filename> directory.
-            The third command extracts the root filesystem from a previously
-            built filesystem that is located in the
-            <filename>~/Downloads</filename> directory.
-            Furthermore, this command extracts the root filesystem into the
-            <filename>qemux86-sato</filename> directory:
-            <literallayout class='monospaced'>
-     $ cd ~
-     $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
-     $ runqemu-extract-sdk \
-        ~/Downloads/core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2 \
-        $HOME/qemux86-sato
-            </literallayout>
-            You could now point to the target sysroot at
-            <filename>qemux86-sato</filename>.
-        </para>
-    </section>
-</section>
-
-<section id='optionally-building-a-toolchain-installer'>
-    <title>Optionally Building a Toolchain Installer</title>
-
-    <para>
-        As an alternative to locating and downloading a toolchain installer,
-        you can build the toolchain installer if you have a
-        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
-        <note>
-            Although not the preferred method, it is also possible to use
-            <filename>bitbake meta-toolchain</filename> to build the toolchain
-            installer.
-            If you do use this method, you must separately install and extract
-            the target sysroot.
-            For information on how to install the sysroot, see the
-            "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>"
-            section.
-        </note>
-    </para>
-
-    <para>
-        To build the toolchain installer and populate the SDK image, use the
-        following command:
-        <literallayout class='monospaced'>
-     $ bitbake <replaceable>image</replaceable> -c populate_sdk
-        </literallayout>
-        The command results in a toolchain installer that contains the sysroot
-        that matches your target root filesystem.
-    </para>
-
-    <para>
-        Another powerful feature is that the toolchain is completely
-        self-contained.
-        The binaries are linked against their own copy of
-        <filename>libc</filename>, which results in no dependencies
-        on the target system.
-        To achieve this, the pointer to the dynamic loader is
-        configured at install time since that path cannot be dynamically
-        altered.
-        This is the reason for a wrapper around the
-        <filename>populate_sdk</filename> archive.
-    </para>
-
-    <para>
-        Another feature is that only one set of cross-canadian toolchain
-        binaries are produced per architecture.
-        This feature takes advantage of the fact that the target hardware can
-        be passed to <filename>gcc</filename> as a set of compiler options.
-        Those options are set up by the environment script and contained in
-        variables such as
-        <ulink url='&YOCTO_DOCS_REF_URL;#var-CC'><filename>CC</filename></ulink>
-        and
-        <ulink url='&YOCTO_DOCS_REF_URL;#var-LD'><filename>LD</filename></ulink>.
-        This reduces the space needed for the tools.
-        Understand, however, that a sysroot is still needed for every target
-        since those binaries are target-specific.
-    </para>
-
-    <para>
-         Remember, before using any BitBake command, you
-         must source the build environment setup script
-         (i.e.
-         <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
-         or
-         <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
-         located in the Source Directory and you must make sure your
-         <filename>conf/local.conf</filename> variables are correct.
-         In particular, you need to be sure the
-         <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
-         variable matches the architecture for which you are building and that
-         the
-         <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>
-         variable is correctly set if you are building a toolchain designed to
-         run on an architecture that differs from your current development host
-         machine (i.e. the build machine).
-    </para>
-
-    <para>
-        When the <filename>bitbake</filename> command completes, the toolchain
-        installer will be in
-        <filename>tmp/deploy/sdk</filename> in the Build Directory.
-        <note>
-            By default, this toolchain does not build static binaries.
-            If you want to use the toolchain to build these types of libraries,
-            you need to be sure your image has the appropriate static
-            development libraries.
-            Use the
-            <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></ulink>
-            variable inside your <filename>local.conf</filename> file to
-            install the appropriate library packages.
-            Following is an example using <filename>glibc</filename> static
-            development libraries:
-            <literallayout class='monospaced'>
-     IMAGE_INSTALL_append = " glibc-staticdev"
-            </literallayout>
-        </note>
-    </para>
-</section>
-
-<section id='optionally-using-an-external-toolchain'>
-    <title>Optionally Using an External Toolchain</title>
-
-    <para>
-        You might want to use an external toolchain as part of your
-        development.
-        If this is the case, the fundamental steps you need to accomplish
-        are as follows:
-        <itemizedlist>
-            <listitem><para>
-                Understand where the installed toolchain resides.
-                For cases where you need to build the external toolchain, you
-                would need to take separate steps to build and install the
-                toolchain.
-                </para></listitem>
-            <listitem><para>
-                Make sure you add the layer that contains the toolchain to
-                your <filename>bblayers.conf</filename> file through the
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
-                variable.
-                </para></listitem>
-            <listitem><para>
-                Set the
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTERNAL_TOOLCHAIN'><filename>EXTERNAL_TOOLCHAIN</filename></ulink>
-                variable in your <filename>local.conf</filename> file
-                to the location in which you installed the toolchain.
-                </para></listitem>
-        </itemizedlist>
-        A good example of an external toolchain used with the Yocto Project
-        is <trademark class='registered'>Mentor Graphics</trademark>
-        Sourcery G++ Toolchain.
-        You can see information on how to use that particular layer in the
-        <filename>README</filename> file at
-        <ulink url='http://github.com/MentorEmbedded/meta-sourcery/'></ulink>.
-        You can find further information by reading about the
-        <ulink url='&YOCTO_DOCS_REF_URL;#var-TCMODE'><filename>TCMODE</filename></ulink>
-        variable in the Yocto Project Reference Manual's variable glossary.
-    </para>
-</section>
-
-    <section id='using-pre-built'>
-        <title>Example Using Pre-Built Binaries and QEMU</title>
-
-        <para>
-            If hardware, libraries and services are stable, you can get started by using a pre-built binary
-            of the filesystem image, kernel, and toolchain and run it using the QEMU emulator.
-            This scenario is useful for developing application software.
-        </para>
-
-        <mediaobject>
-            <imageobject>
-            <imagedata fileref="figures/using-a-pre-built-image.png" format="PNG" align='center' scalefit='1'/>
-            </imageobject>
-            <caption>
-                <para>Using a Pre-Built Image</para>
-            </caption>
-        </mediaobject>
-
-        <para>
-            For this scenario, you need to do several things:
-        </para>
-
-        <itemizedlist>
-            <listitem><para>Install the appropriate stand-alone toolchain tarball.</para></listitem>
-            <listitem><para>Download the pre-built image that will boot with QEMU.
-                You need to be sure to get the QEMU image that matches your target machine’s
-                architecture (e.g. x86, ARM, etc.).</para></listitem>
-            <listitem><para>Download the filesystem image for your target machine's architecture.
-                </para></listitem>
-            <listitem><para>Set up the environment to emulate the hardware and then start the QEMU emulator.
-                </para></listitem>
-        </itemizedlist>
-
-        <section id='installing-the-toolchain'>
-            <title>Installing the Toolchain</title>
-
-            <para>
-                You can download a tarball installer, which includes the
-                pre-built toolchain, the <filename>runqemu</filename>
-                script, and support files from the appropriate directory under
-                <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>.
-                Toolchains are available for 32-bit and 64-bit x86 development
-                systems from the <filename>i686</filename> and
-                <filename>x86_64</filename> directories, respectively.
-                The toolchains the Yocto Project provides are based off the
-                <filename>core-image-sato</filename> image and contain
-                libraries appropriate for developing against that image.
-                Each type of development system supports five or more target
-                architectures.
-            </para>
-
-            <para>
-                The names of the tarball installer scripts are such that a
-                string representing the host system appears first in the
-                filename and then is immediately followed by a string
-                representing the target architecture.
-            </para>
-
-            <literallayout class='monospaced'>
-     poky-glibc-<replaceable>host_system</replaceable>-<replaceable>image_type</replaceable>-<replaceable>arch</replaceable>-toolchain-<replaceable>release_version</replaceable>.sh
-
-     Where:
-         <replaceable>host_system</replaceable> is a string representing your development system:
-
-                    i686 or x86_64.
-
-         <replaceable>image_type</replaceable> is a string representing the image you wish to
-                develop a Software Development Toolkit (SDK) for use against.
-                The Yocto Project builds toolchain installers using the
-                following BitBake command:
-
-                    bitbake core-image-sato -c populate_sdk
-
-         <replaceable>arch</replaceable> is a string representing the tuned target architecture:
-
-                    i586, x86_64, powerpc, mips, armv7a or armv5te
-
-         <replaceable>release_version</replaceable> is a string representing the release number of the
-                Yocto Project:
-
-                    &DISTRO;, &DISTRO;+snapshot
-            </literallayout>
-
-            <para>
-                For example, the following toolchain installer is for a 64-bit
-                development host system and a i586-tuned target architecture
-                based off the SDK for <filename>core-image-sato</filename>:
-                <literallayout class='monospaced'>
-     poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
-                </literallayout>
-            </para>
-
-            <para>
-                Toolchains are self-contained and by default are installed into
-                <filename>/opt/poky</filename>.
-                However, when you run the toolchain installer, you can choose an
-                installation directory.
-            </para>
-
-            <para>
-                The following command shows how to run the installer given a toolchain tarball
-                for a 64-bit x86 development host system and a 32-bit x86 target architecture.
-                You must change the permissions on the toolchain
-                installer script so that it is executable.
-            </para>
-
-            <para>
-                The example assumes the toolchain installer is located in <filename>~/Downloads/</filename>.
-                <note>
-                    If you do not have write permissions for the directory into which you are installing
-                    the toolchain, the toolchain installer notifies you and exits.
-                    Be sure you have write permissions in the directory and run the installer again.
-                </note>
-            </para>
-
-            <para>
-                <literallayout class='monospaced'>
-     $ ~/Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
-                </literallayout>
-            </para>
-
-            <para>
-                For more information on how to install tarballs, see the
-                "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" and
-                "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree'>Using BitBake and the Build Directory</ulink>" sections in the Yocto Project Application Developer's Guide.
-            </para>
-        </section>
-
-        <section id='downloading-the-pre-built-linux-kernel'>
-            <title>Downloading the Pre-Built Linux Kernel</title>
-
-            <para>
-                You can download the pre-built Linux kernel suitable for running in the QEMU emulator from
-                <ulink url='&YOCTO_QEMU_DL_URL;'></ulink>.
-                Be sure to use the kernel that matches the architecture you want to simulate.
-                Download areas exist for the five supported machine architectures:
-                <filename>qemuarm</filename>, <filename>qemumips</filename>, <filename>qemuppc</filename>,
-                <filename>qemux86</filename>, and <filename>qemux86-64</filename>.
-            </para>
-
-            <para>
-                Most kernel files have one of the following forms:
-                <literallayout class='monospaced'>
-     *zImage-qemu<replaceable>arch</replaceable>.bin
-     vmlinux-qemu<replaceable>arch</replaceable>.bin
-
-     Where:
-         <replaceable>arch</replaceable> is a string representing the target architecture:
-                x86, x86-64, ppc, mips, or arm.
-                </literallayout>
-            </para>
-
-            <para>
-                You can learn more about downloading a Yocto Project kernel in the
-                "<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Yocto Project Kernel</ulink>"
-                bulleted item in the Yocto Project Development Manual.
-            </para>
-        </section>
-
-        <section id='downloading-the-filesystem'>
-            <title>Downloading the Filesystem</title>
-
-            <para>
-                You can also download the filesystem image suitable for your target architecture from
-                <ulink url='&YOCTO_QEMU_DL_URL;'></ulink>.
-                Again, be sure to use the filesystem that matches the architecture you want
-                to simulate.
-            </para>
-
-            <para>
-                The filesystem image has two tarball forms: <filename>ext3</filename> and
-                <filename>tar</filename>.
-                You must use the <filename>ext3</filename> form when booting an image using the
-                QEMU emulator.
-                The <filename>tar</filename> form can be flattened out in your host development system
-                and used for build purposes with the Yocto Project.
-                <literallayout class='monospaced'>
-     core-image-<replaceable>profile</replaceable>-qemu<replaceable>arch</replaceable>.ext3
-     core-image-<replaceable>profile</replaceable>-qemu<replaceable>arch</replaceable>.tar.bz2
-
-     Where:
-         <replaceable>profile</replaceable> is the filesystem image's profile:
-                   lsb, lsb-dev, lsb-sdk, lsb-qt3, minimal, minimal-dev, sato,
-                   sato-dev, or sato-sdk. For information on these types of image
-                   profiles, see the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
-                   chapter in the Yocto Project Reference Manual.
-
-         <replaceable>arch</replaceable> is a string representing the target architecture:
-                x86, x86-64, ppc, mips, or arm.
-                </literallayout>
-            </para>
-        </section>
-
-        <section id='setting-up-the-environment-and-starting-the-qemu-emulator'>
-            <title>Setting Up the Environment and Starting the QEMU Emulator</title>
-
-            <para>
-                Before you start the QEMU emulator, you need to set up the emulation environment.
-                The following command form sets up the emulation environment.
-                <literallayout class='monospaced'>
-     $ source &YOCTO_ADTPATH_DIR;/environment-setup-<replaceable>arch</replaceable>-poky-linux-<replaceable>if</replaceable>
-
-     Where:
-         <replaceable>arch</replaceable> is a string representing the target architecture:
-                i586, x86_64, ppc603e, mips, or armv5te.
-
-         <replaceable>if</replaceable> is a string representing an embedded application binary interface.
-              Not all setup scripts include this string.
-                </literallayout>
-            </para>
-
-            <para>
-                Finally, this command form invokes the QEMU emulator
-                <literallayout class='monospaced'>
-     $ runqemu <replaceable>qemuarch</replaceable> <replaceable>kernel-image</replaceable> <replaceable>filesystem-image</replaceable>
-
-     Where:
-         <replaceable>qemuarch</replaceable> is a string representing the target architecture: qemux86, qemux86-64,
-                    qemuppc, qemumips, or qemuarm.
-
-         <replaceable>kernel-image</replaceable> is the architecture-specific kernel image.
-
-         <replaceable>filesystem-image</replaceable> is the .ext3 filesystem image.
-
-                </literallayout>
-            </para>
-
-            <para>
-                Continuing with the example, the following two commands setup the emulation
-                environment and launch QEMU.
-                This example assumes the root filesystem (<filename>.ext3</filename> file) and
-                the pre-built kernel image file both reside in your home directory.
-                The kernel and filesystem are for a 32-bit target architecture.
-                <literallayout class='monospaced'>
-     $ cd $HOME
-     $ source &YOCTO_ADTPATH_DIR;/environment-setup-i586-poky-linux
-     $ runqemu qemux86 bzImage-qemux86.bin \
-     core-image-sato-qemux86.ext3
-                </literallayout>
-            </para>
-
-            <para>
-                The environment in which QEMU launches varies depending on the filesystem image and on the
-                target architecture.
-                For example, if you source the environment for the ARM target
-                architecture and then boot the minimal QEMU image, the emulator comes up in a new
-                shell in command-line mode.
-                However, if you boot the SDK image, QEMU comes up with a GUI.
-                <note>Booting the PPC image results in QEMU launching in the same shell in
-                command-line mode.</note>
-            </para>
-        </section>
-</section>
-
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->

documentation/adt-manual/adt-style.css

@@ -1,984 +0,0 @@
-/*
-   Generic XHTML / DocBook XHTML CSS Stylesheet.
-
-   Browser wrangling and typographic design by
-      Oyvind Kolas / pippin@gimp.org
-
-   Customised for Poky by
-      Matthew Allum / mallum@o-hand.com
-
-   Thanks to:
-     Liam R. E. Quin
-     William Skaggs
-     Jakub Steiner
-
-   Structure
-   ---------
-
-   The stylesheet is divided into the following sections:
-
-       Positioning
-          Margins, paddings, width, font-size, clearing.
-       Decorations
-          Borders, style
-       Colors
-          Colors
-       Graphics
-          Graphical backgrounds
-       Nasty IE tweaks
-          Workarounds needed to make it work in internet explorer,
-          currently makes the stylesheet non validating, but up until
-          this point it is validating.
-       Mozilla extensions
-          Transparency for footer
-	  Rounded corners on boxes
-
-*/
-
-
-  /*************** /
- /  Positioning   /
-/ ***************/
-
-body {
-  font-family: Verdana, Sans, sans-serif;
-
-  min-width: 640px;
-  width: 80%;
-  margin:  0em auto;
-  padding: 2em 5em 5em 5em;
-  color: #333;
-}
-
-h1,h2,h3,h4,h5,h6,h7 {
-  font-family: Arial, Sans;
-  color: #00557D;
-  clear: both;
-}
-
-h1 {
-  font-size: 2em;
-  text-align: left;
-  padding: 0em 0em 0em 0em;
-  margin: 2em 0em 0em 0em;
-}
-
-h2.subtitle {
-  margin: 0.10em 0em 3.0em 0em;
-  padding: 0em 0em 0em 0em;
-  font-size: 1.8em;
-  padding-left: 20%;
-  font-weight: normal;
-  font-style: italic;
-}
-
-h2 {
-  margin: 2em 0em 0.66em 0em;
-  padding: 0.5em 0em 0em 0em;
-  font-size: 1.5em;
-  font-weight: bold;
-}
-
-h3.subtitle {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-  font-size: 142.14%;
-  text-align: right;
-}
-
-h3 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 140%;
-  font-weight: bold;
-}
-
-h4 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 120%;
-  font-weight: bold;
-}
-
-h5 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
-}
-
-h6 {
-  margin: 1em 0em 0em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
-}
-
-.authorgroup {
-  background-color: transparent;
-  background-repeat: no-repeat;
-  padding-top: 256px;
-  background-image: url("figures/adt-title.png");
-  background-position: left top;
-  margin-top: -256px;
-  padding-right: 50px;
-  margin-left: 0px;
-  text-align: right;
-  width: 740px;
-}
-
-h3.author {
-  margin: 0em 0me 0em 0em;
-  padding: 0em 0em 0em 0em;
-  font-weight: normal;
-  font-size: 100%;
-  color: #333;
-  clear: both;
-}
-
-.author tt.email {
-  font-size: 66%;
-}
-
-.titlepage hr {
-  width: 0em;
-  clear: both;
-}
-
-.revhistory {
-  padding-top: 2em;
-  clear: both;
-}
-
-.toc,
-.list-of-tables,
-.list-of-examples,
-.list-of-figures {
-  padding: 1.33em 0em 2.5em 0em;
-  color: #00557D;
-}
-
-.toc p,
-.list-of-tables p,
-.list-of-figures p,
-.list-of-examples p {
-  padding: 0em 0em 0em 0em;
-  padding: 0em 0em 0.3em;
-  margin: 1.5em 0em 0em 0em;
-}
-
-.toc p b,
-.list-of-tables p b,
-.list-of-figures p b,
-.list-of-examples p b{
-  font-size: 100.0%;
-  font-weight: bold;
-}
-
-.toc dl,
-.list-of-tables dl,
-.list-of-figures dl,
-.list-of-examples dl {
-  margin: 0em 0em 0.5em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.toc dt {
-  margin: 0em 0em 0em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.toc dd {
-  margin: 0em 0em 0em 2.6em;
-  padding: 0em 0em 0em 0em;
-}
-
-div.glossary dl,
-div.variablelist dl {
-}
-
-.glossary dl dt,
-.variablelist dl dt,
-.variablelist dl dt span.term {
-  font-weight: normal;
-  width: 20em;
-  text-align: right;
-}
-
-.variablelist dl dt {
-  margin-top: 0.5em;
-}
-
-.glossary dl dd,
-.variablelist dl dd {
-  margin-top: -1em;
-  margin-left: 25.5em;
-}
-
-.glossary dd p,
-.variablelist dd p {
-  margin-top: 0em;
-  margin-bottom: 1em;
-}
-
-
-div.calloutlist table td {
-  padding: 0em 0em 0em 0em;
-  margin: 0em 0em 0em 0em;
-}
-
-div.calloutlist table td p {
-  margin-top: 0em;
-  margin-bottom: 1em;
-}
-
-div p.copyright {
-  text-align: left;
-}
-
-div.legalnotice p.legalnotice-title {
-  margin-bottom: 0em;
-}
-
-p {
-  line-height: 1.5em;
-  margin-top: 0em;
-
-}
-
-dl {
-  padding-top: 0em;
-}
-
-hr {
-  border: solid 1px;
-}
-
-
-.mediaobject,
-.mediaobjectco {
-  text-align: center;
-}
-
-img {
-  border: none;
-}
-
-ul {
-  padding: 0em 0em 0em 1.5em;
-}
-
-ul li {
-  padding: 0em 0em 0em 0em;
-}
-
-ul li p {
-  text-align: left;
-}
-
-table {
-  width :100%;
-}
-
-th {
-  padding: 0.25em;
-  text-align: left;
-  font-weight: normal;
-  vertical-align: top;
-}
-
-td {
-  padding: 0.25em;
-  vertical-align: top;
-}
-
-p a[id] {
-  margin: 0px;
-  padding: 0px;
-  display: inline;
-  background-image: none;
-}
-
-a {
-  text-decoration: underline;
-  color: #444;
-}
-
-pre {
-    overflow: auto;
-}
-
-a:hover {
-  text-decoration: underline;
-  /*font-weight: bold;*/
-}
-
-/* This style defines how the permalink character
-   appears by itself and when hovered over with
-   the mouse. */
-
-[alt='Permalink'] { color: #eee; }
-[alt='Permalink']:hover { color: black; }
-
-
-div.informalfigure,
-div.informalexample,
-div.informaltable,
-div.figure,
-div.table,
-div.example {
-  margin: 1em 0em;
-  padding: 1em;
-  page-break-inside: avoid;
-}
-
-
-div.informalfigure p.title b,
-div.informalexample p.title b,
-div.informaltable p.title b,
-div.figure p.title b,
-div.example p.title b,
-div.table p.title b{
-    padding-top: 0em;
-    margin-top: 0em;
-    font-size: 100%;
-    font-weight: normal;
-}
-
-.mediaobject .caption,
-.mediaobject .caption p  {
-  text-align: center;
-  font-size: 80%;
-  padding-top: 0.5em;
-  padding-bottom: 0.5em;
-}
-
-.epigraph {
-  padding-left: 55%;
-  margin-bottom: 1em;
-}
-
-.epigraph p {
-  text-align: left;
-}
-
-.epigraph .quote {
-  font-style: italic;
-}
-.epigraph .attribution {
-  font-style: normal;
-  text-align: right;
-}
-
-span.application {
-  font-style: italic;
-}
-
-.programlisting {
-  font-family: monospace;
-  font-size: 80%;
-  white-space: pre;
-  margin: 1.33em 0em;
-  padding: 1.33em;
-}
-
-.tip,
-.warning,
-.caution,
-.note {
-  margin-top: 1em;
-  margin-bottom: 1em;
-
-}
-
-/* force full width of table within div */
-.tip table,
-.warning table,
-.caution table,
-.note table {
-  border: none;
-  width: 100%;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  padding: 0.8em 0.0em 0.0em 0.0em;
-  margin : 0em 0em 0em 0em;
-}
-
-.tip p,
-.warning p,
-.caution p,
-.note p {
-  margin-top: 0.5em;
-  margin-bottom: 0.5em;
-  padding-right: 1em;
-  text-align: left;
-}
-
-.acronym {
-  text-transform: uppercase;
-}
-
-b.keycap,
-.keycap {
-  padding: 0.09em 0.3em;
-  margin: 0em;
-}
-
-.itemizedlist li {
-  clear: none;
-}
-
-.filename {
-  font-size: medium;
-  font-family: Courier, monospace;
-}
-
-
-div.navheader, div.heading{
-  position: absolute;
-  left: 0em;
-  top: 0em;
-  width: 100%;
-  background-color: #cdf;
-  width: 100%;
-}
-
-div.navfooter, div.footing{
-  position: fixed;
-  left: 0em;
-  bottom: 0em;
-  background-color: #eee;
-  width: 100%;
-}
-
-
-div.navheader td,
-div.navfooter td {
-  font-size: 66%;
-}
-
-div.navheader table th {
-  /*font-family: Georgia, Times, serif;*/
-  /*font-size: x-large;*/
-  font-size: 80%;
-}
-
-div.navheader table {
-  border-left: 0em;
-  border-right: 0em;
-  border-top: 0em;
-  width: 100%;
-}
-
-div.navfooter table {
-  border-left: 0em;
-  border-right: 0em;
-  border-bottom: 0em;
-  width: 100%;
-}
-
-div.navheader table td a,
-div.navfooter table td a {
-  color: #777;
-  text-decoration: none;
-}
-
-/* normal text in the footer */
-div.navfooter table td {
-  color: black;
-}
-
-div.navheader table td a:visited,
-div.navfooter table td a:visited {
-  color: #444;
-}
-
-
-/* links in header and footer */
-div.navheader table td a:hover,
-div.navfooter table td a:hover {
-  text-decoration: underline;
-  background-color: transparent;
-  color: #33a;
-}
-
-div.navheader hr,
-div.navfooter hr {
-  display: none;
-}
-
-
-.qandaset tr.question td p {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.qandaset tr.answer td p {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-}
-.answer td {
-  padding-bottom: 1.5em;
-}
-
-.emphasis {
-  font-weight: bold;
-}
-
-
-  /************* /
- / decorations  /
-/ *************/
-
-.titlepage {
-}
-
-.part .title {
-}
-
-.subtitle {
-    border: none;
-}
-
-/*
-h1 {
-  border: none;
-}
-
-h2 {
-  border-top: solid 0.2em;
-  border-bottom: solid 0.06em;
-}
-
-h3 {
-  border-top: 0em;
-  border-bottom: solid 0.06em;
-}
-
-h4 {
-  border: 0em;
-  border-bottom: solid 0.06em;
-}
-
-h5 {
-  border: 0em;
-}
-*/
-
-.programlisting {
-  border: solid 1px;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example {
-  border: 1px solid;
-}
-
-
-
-.tip,
-.warning,
-.caution,
-.note {
-  border: 1px solid;
-}
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  border-bottom: 1px solid;
-}
-
-.question td {
-  border-top: 1px solid black;
-}
-
-.answer {
-}
-
-
-b.keycap,
-.keycap {
-  border: 1px solid;
-}
-
-
-div.navheader, div.heading{
-  border-bottom: 1px solid;
-}
-
-
-div.navfooter, div.footing{
-  border-top: 1px solid;
-}
-
-  /********* /
- /  colors  /
-/ *********/
-
-body {
-  color: #333;
-  background: white;
-}
-
-a {
-  background: transparent;
-}
-
-a:hover {
-  background-color: #dedede;
-}
-
-
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7,
-h8 {
-  background-color: transparent;
-}
-
-hr {
-  border-color: #aaa;
-}
-
-
-.tip, .warning, .caution, .note {
-  border-color: #fff;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  border-bottom-color: #fff;
-}
-
-
-.warning {
-  background-color: #f0f0f2;
-}
-
-.caution {
-  background-color: #f0f0f2;
-}
-
-.tip {
-  background-color: #f0f0f2;
-}
-
-.note {
-  background-color: #f0f0f2;
-}
-
-.glossary dl dt,
-.variablelist dl dt,
-.variablelist dl dt span.term {
-  color: #044;
-}
-
-div.figure,
-div.table,
-div.example,
-div.informalfigure,
-div.informaltable,
-div.informalexample {
-  border-color: #aaa;
-}
-
-pre.programlisting {
-  color: black;
-  background-color: #fff;
-  border-color: #aaa;
-  border-width: 2px;
-}
-
-.guimenu,
-.guilabel,
-.guimenuitem {
-  background-color: #eee;
-}
-
-
-b.keycap,
-.keycap {
-  background-color: #eee;
-  border-color: #999;
-}
-
-
-div.navheader {
-  border-color: black;
-}
-
-
-div.navfooter {
-  border-color: black;
-}
-
-
-  /*********** /
- /  graphics  /
-/ ***********/
-
-/*
-body {
-  background-image: url("images/body_bg.jpg");
-  background-attachment: fixed;
-}
-
-.navheader,
-.note,
-.tip {
-  background-image: url("images/note_bg.jpg");
-  background-attachment: fixed;
-}
-
-.warning,
-.caution {
-  background-image: url("images/warning_bg.jpg");
-  background-attachment: fixed;
-}
-
-.figure,
-.informalfigure,
-.example,
-.informalexample,
-.table,
-.informaltable {
-  background-image: url("images/figure_bg.jpg");
-  background-attachment: fixed;
-}
-
-*/
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7{
-}
-
-/*
-Example of how to stick an image as part of the title.
-
-div.article .titlepage .title
-{
-  background-image: url("figures/white-on-black.png");
-  background-position: center;
-  background-repeat: repeat-x;
-}
-*/
-
-div.preface .titlepage .title,
-div.colophon .title,
-div.chapter .titlepage .title,
-div.article .titlepage .title
-{
-}
-
-div.section div.section .titlepage .title,
-div.sect2 .titlepage .title {
-    background: none;
-}
-
-
-h1.title {
-  background-color: transparent;
-  background-repeat: no-repeat;
-  height: 256px;
-  text-indent: -9000px;
-  overflow:hidden;
-}
-
-h2.subtitle {
-  background-color: transparent;
-  text-indent: -9000px;
-  overflow:hidden;
-  width: 0px;
-  display: none;
-}
-
-  /*************************************** /
- /  pippin.gimp.org specific alterations  /
-/ ***************************************/
-
-/*
-div.heading, div.navheader {
-  color: #777;
-  font-size: 80%;
-  padding: 0;
-  margin: 0;
-  text-align: left;
-  position: absolute;
-  top: 0px;
-  left: 0px;
-  width: 100%;
-  height: 50px;
-  background: url('/gfx/heading_bg.png') transparent;
-  background-repeat: repeat-x;
-  background-attachment: fixed;
-  border: none;
-}
-
-div.heading a {
-  color: #444;
-}
-
-div.footing, div.navfooter {
-  border: none;
-  color: #ddd;
-  font-size: 80%;
-  text-align:right;
-
-  width: 100%;
-  padding-top: 10px;
-  position: absolute;
-  bottom: 0px;
-  left: 0px;
-
-  background: url('/gfx/footing_bg.png') transparent;
-}
-*/
-
-
-
-  /****************** /
- /  nasty ie tweaks  /
-/ ******************/
-
-/*
-div.heading, div.navheader {
-  width:expression(document.body.clientWidth + "px");
-}
-
-div.footing, div.navfooter {
-  width:expression(document.body.clientWidth + "px");
-  margin-left:expression("-5em");
-}
-body {
-  padding:expression("4em 5em 0em 5em");
-}
-*/
-
-  /**************************************** /
- / mozilla vendor specific css extensions  /
-/ ****************************************/
-/*
-div.navfooter, div.footing{
-  -moz-opacity: 0.8em;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example,
-.tip,
-.warning,
-.caution,
-.note {
-  -moz-border-radius: 0.5em;
-}
-
-b.keycap,
-.keycap {
-  -moz-border-radius: 0.3em;
-}
-*/
-
-table tr td table tr td {
-  display: none;
-}
-
-
-hr {
-  display: none;
-}
-
-table {
-  border: 0em;
-}
-
- .photo {
-  float: right;
-  margin-left:   1.5em;
-  margin-bottom: 1.5em;
-  margin-top: 0em;
-  max-width:      17em;
-  border:     1px solid gray;
-  padding:    3px;
-  background: white;
-}
- .seperator {
-   padding-top: 2em;
-   clear: both;
-  }
-
-  #validators {
-      margin-top: 5em;
-      text-align: right;
-      color: #777;
-  }
-  @media print {
-      body {
-          font-size: 8pt;
-      }
-      .noprint {
-          display: none;
-      }
-  }
-
-
-.tip,
-.note {
-   background: #f0f0f2;
-   color: #333;
-   padding: 20px;
-   margin: 20px;
-}
-
-.tip h3,
-.note h3 {
-   padding: 0em;
-   margin: 0em;
-   font-size: 2em;
-   font-weight: bold;
-   color: #333;
-}
-
-.tip a,
-.note a {
-   color: #333;
-   text-decoration: underline;
-}
-
-.footnote {
-   font-size: small;
-   color: #333;
-}
-
-/* Changes the announcement text */
-.tip h3,
-.warning h3,
-.caution h3,
-.note h3 {
-   font-size:large;
-   color: #00557D;
-}

documentation/boilerplate.rst

@@ -0,0 +1,18 @@
+.. include:: <xhtml1-lat1.txt>
+.. include:: <xhtml1-symbol.txt>
+
+----
+
+| |project_name|
+| <docs@lists.yoctoproject.org>
+
+Permission is granted to copy, distribute and/or modify this document under the
+terms of the `Creative Commons Attribution-Share Alike 2.0 UK: England & Wales
+<http://creativecommons.org/licenses/by-sa/2.0/uk/>`_ as published by Creative
+Commons.
+
+To report any inaccuracies or problems with this (or any other Yocto Project)
+manual, or to send additions or changes, please send email/patches to the Yocto
+Project documentation mailing list at ``docs@lists.yoctoproject.org`` or
+log into the freenode ``#yocto`` channel.
+

documentation/brief-yoctoprojectqs/brief-yoctoprojectqs-customization.xsl

@@ -1,24 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
-
-  <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
-
-<!--
-
-  <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
-
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
-
--->
-
-  <xsl:import href="brief-yoctoprojectqs-titlepage.xsl"/>
-
-  <xsl:include href="../template/permalinks.xsl"/>
-  <xsl:include href="../template/section.title.xsl"/>
-  <xsl:include href="../template/component.title.xsl"/>
-  <xsl:include href="../template/division.title.xsl"/>
-  <xsl:include href="../template/formal.object.heading.xsl"/>
-
-  <xsl:param name="generate.toc" select="'article nop'"></xsl:param>
-  <xsl:param name="html.stylesheet" select="'brief-yoctoprojectqs-style.css'" />
-</xsl:stylesheet>

documentation/brief-yoctoprojectqs/brief-yoctoprojectqs-style.css

@@ -1,989 +0,0 @@
-/*
-   Generic XHTML / DocBook XHTML CSS Stylesheet.
-
-   Browser wrangling and typographic design by
-      Oyvind Kolas / pippin@gimp.org
-
-   Customised for Poky by
-      Matthew Allum / mallum@o-hand.com
-
-   Thanks to:
-     Liam R. E. Quin
-     William Skaggs
-     Jakub Steiner
-
-   Structure
-   ---------
-
-   The stylesheet is divided into the following sections:
-
-       Positioning
-          Margins, paddings, width, font-size, clearing.
-       Decorations
-          Borders, style
-       Colors
-          Colors
-       Graphics
-          Graphical backgrounds
-       Nasty IE tweaks
-          Workarounds needed to make it work in internet explorer,
-          currently makes the stylesheet non validating, but up until
-          this point it is validating.
-       Mozilla extensions
-          Transparency for footer
-	  Rounded corners on boxes
-
-*/
-
-
-  /*************** /
- /  Positioning   /
-/ ***************/
-
-body {
-  font-family: Verdana, Sans, sans-serif;
-
-  min-width: 640px;
-  width: 80%;
-  margin:  0em auto;
-  padding: 2em 5em 5em 5em;
-  color: #333;
-}
-
-h1,h2,h3,h4,h5,h6,h7 {
-  font-family: Arial, Sans;
-  color: #00557D;
-  clear: both;
-}
-
-h1 {
-  font-size: 2em;
-  text-align: left;
-  padding: 0em 0em 0em 0em;
-  margin: 2em 0em 0em 0em;
-}
-
-h2.subtitle {
-  margin: 0.10em 0em 3.0em 0em;
-  padding: 0em 0em 0em 0em;
-  font-size: 1.8em;
-  padding-left: 20%;
-  font-weight: normal;
-  font-style: italic;
-}
-
-h2 {
-  margin: 2em 0em 0.66em 0em;
-  padding: 0.5em 0em 0em 0em;
-  font-size: 1.5em;
-  font-weight: bold;
-}
-
-h3.subtitle {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-  font-size: 142.14%;
-  text-align: right;
-}
-
-h3 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 140%;
-  font-weight: bold;
-}
-
-h4 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 120%;
-  font-weight: bold;
-}
-
-h5 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
-}
-
-h6 {
-  margin: 1em 0em 0em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
-}
-
-.authorgroup {
-  background-color: transparent;
-  background-repeat: no-repeat;
-  padding-top: 256px;
-  background-image: url("figures/bypqs-title.png");
-  background-position: left top;
-  margin-top: -256px;
-  padding-right: 50px;
-  margin-left: 0px;
-  text-align: right;
-  width: 740px;
-}
-
-h3.author {
-  margin: 0em 0me 0em 0em;
-  padding: 0em 0em 0em 0em;
-  font-weight: normal;
-  font-size: 100%;
-  color: #333;
-  clear: both;
-}
-
-.author tt.email {
-  font-size: 66%;
-}
-
-.titlepage hr {
-  width: 0em;
-  clear: both;
-}
-
-.revhistory {
-  padding-top: 2em;
-  clear: both;
-}
-
-.toc,
-.list-of-tables,
-.list-of-examples,
-.list-of-figures {
-  padding: 1.33em 0em 2.5em 0em;
-  color: #00557D;
-}
-
-.toc p,
-.list-of-tables p,
-.list-of-figures p,
-.list-of-examples p {
-  padding: 0em 0em 0em 0em;
-  padding: 0em 0em 0.3em;
-  margin: 1.5em 0em 0em 0em;
-}
-
-.toc p b,
-.list-of-tables p b,
-.list-of-figures p b,
-.list-of-examples p b{
-  font-size: 100.0%;
-  font-weight: bold;
-}
-
-.toc dl,
-.list-of-tables dl,
-.list-of-figures dl,
-.list-of-examples dl {
-  margin: 0em 0em 0.5em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.toc dt {
-  margin: 0em 0em 0em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.toc dd {
-  margin: 0em 0em 0em 2.6em;
-  padding: 0em 0em 0em 0em;
-}
-
-div.glossary dl,
-div.variablelist dl {
-}
-
-.glossary dl dt,
-.variablelist dl dt,
-.variablelist dl dt span.term {
-  font-weight: normal;
-  width: 20em;
-  text-align: right;
-}
-
-.variablelist dl dt {
-  margin-top: 0.5em;
-}
-
-.glossary dl dd,
-.variablelist dl dd {
-  margin-top: -1em;
-  margin-left: 25.5em;
-}
-
-.glossary dd p,
-.variablelist dd p {
-  margin-top: 0em;
-  margin-bottom: 1em;
-}
-
-
-div.calloutlist table td {
-  padding: 0em 0em 0em 0em;
-  margin: 0em 0em 0em 0em;
-}
-
-div.calloutlist table td p {
-  margin-top: 0em;
-  margin-bottom: 1em;
-}
-
-div p.copyright {
-  text-align: left;
-}
-
-div.legalnotice p.legalnotice-title {
-  margin-bottom: 0em;
-}
-
-p {
-  line-height: 1.5em;
-  margin-top: 0em;
-
-}
-
-dl {
-  padding-top: 0em;
-}
-
-hr {
-  border: solid 1px;
-}
-
-
-.mediaobject,
-.mediaobjectco {
-  text-align: center;
-}
-
-img {
-  border: none;
-}
-
-ul {
-  padding: 0em 0em 0em 1.5em;
-}
-
-ul li {
-  padding: 0em 0em 0em 0em;
-}
-
-ul li p {
-  text-align: left;
-}
-
-table {
-  width :100%;
-}
-
-th {
-  padding: 0.25em;
-  text-align: left;
-  font-weight: normal;
-  vertical-align: top;
-}
-
-td {
-  padding: 0.25em;
-  vertical-align: top;
-}
-
-p a[id] {
-  margin: 0px;
-  padding: 0px;
-  display: inline;
-  background-image: none;
-}
-
-a {
-  text-decoration: underline;
-  color: #444;
-}
-
-pre {
-    overflow: auto;
-}
-
-a:hover {
-  text-decoration: underline;
-  /*font-weight: bold;*/
-}
-
-/* This style defines how the permalink character
-   appears by itself and when hovered over with
-   the mouse. */
-
-[alt='Permalink'] { color: #eee; }
-[alt='Permalink']:hover { color: black; }
-
-
-div.informalfigure,
-div.informalexample,
-div.informaltable,
-div.figure,
-div.table,
-div.example {
-  margin: 1em 0em;
-  padding: 1em;
-  page-break-inside: avoid;
-}
-
-
-div.informalfigure p.title b,
-div.informalexample p.title b,
-div.informaltable p.title b,
-div.figure p.title b,
-div.example p.title b,
-div.table p.title b{
-    padding-top: 0em;
-    margin-top: 0em;
-    font-size: 100%;
-    font-weight: normal;
-}
-
-.mediaobject .caption,
-.mediaobject .caption p  {
-  text-align: center;
-  font-size: 80%;
-  padding-top: 0.5em;
-  padding-bottom: 0.5em;
-}
-
-.epigraph {
-  padding-left: 55%;
-  margin-bottom: 1em;
-}
-
-.epigraph p {
-  text-align: left;
-}
-
-.epigraph .quote {
-  font-style: italic;
-}
-.epigraph .attribution {
-  font-style: normal;
-  text-align: right;
-}
-
-span.application {
-  font-style: italic;
-}
-
-.programlisting {
-  font-family: monospace;
-  font-size: 80%;
-  white-space: pre;
-  margin: 1.33em 0em;
-  padding: 1.33em;
-}
-
-.tip,
-.warning,
-.caution,
-.note {
-  margin-top: 1em;
-  margin-bottom: 1em;
-
-}
-
-/* force full width of table within div */
-.tip table,
-.warning table,
-.caution table,
-.note table {
-  border: none;
-  width: 100%;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  padding: 0.8em 0.0em 0.0em 0.0em;
-  margin : 0em 0em 0em 0em;
-}
-
-.tip p,
-.warning p,
-.caution p,
-.note p {
-  margin-top: 0.5em;
-  margin-bottom: 0.5em;
-  padding-right: 1em;
-  text-align: left;
-}
-
-.acronym {
-  text-transform: uppercase;
-}
-
-b.keycap,
-.keycap {
-  padding: 0.09em 0.3em;
-  margin: 0em;
-}
-
-.itemizedlist li {
-  clear: none;
-}
-
-.filename {
-  font-size: medium;
-  font-family: Courier, monospace;
-}
-
-
-div.navheader, div.heading{
-  position: absolute;
-  left: 0em;
-  top: 0em;
-  width: 100%;
-  background-color: #cdf;
-  width: 100%;
-}
-
-div.navfooter, div.footing{
-  position: fixed;
-  left: 0em;
-  bottom: 0em;
-  background-color: #eee;
-  width: 100%;
-}
-
-
-div.navheader td,
-div.navfooter td {
-  font-size: 66%;
-}
-
-div.navheader table th {
-  /*font-family: Georgia, Times, serif;*/
-  /*font-size: x-large;*/
-  font-size: 80%;
-}
-
-div.navheader table {
-  border-left: 0em;
-  border-right: 0em;
-  border-top: 0em;
-  width: 100%;
-}
-
-div.navfooter table {
-  border-left: 0em;
-  border-right: 0em;
-  border-bottom: 0em;
-  width: 100%;
-}
-
-div.navheader table td a,
-div.navfooter table td a {
-  color: #777;
-  text-decoration: none;
-}
-
-/* normal text in the footer */
-div.navfooter table td {
-  color: black;
-}
-
-div.navheader table td a:visited,
-div.navfooter table td a:visited {
-  color: #444;
-}
-
-
-/* links in header and footer */
-div.navheader table td a:hover,
-div.navfooter table td a:hover {
-  text-decoration: underline;
-  background-color: transparent;
-  color: #33a;
-}
-
-div.navheader hr,
-div.navfooter hr {
-  display: none;
-}
-
-
-.qandaset tr.question td p {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.qandaset tr.answer td p {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-}
-.answer td {
-  padding-bottom: 1.5em;
-}
-
-.emphasis {
-  font-weight: bold;
-}
-
-
-  /************* /
- / decorations  /
-/ *************/
-
-.titlepage {
-}
-
-.part .title {
-}
-
-.subtitle {
-    border: none;
-}
-
-/*
-h1 {
-  border: none;
-}
-
-h2 {
-  border-top: solid 0.2em;
-  border-bottom: solid 0.06em;
-}
-
-h3 {
-  border-top: 0em;
-  border-bottom: solid 0.06em;
-}
-
-h4 {
-  border: 0em;
-  border-bottom: solid 0.06em;
-}
-
-h5 {
-  border: 0em;
-}
-*/
-
-.programlisting {
-  border: solid 1px;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example {
-  border: 1px solid;
-}
-
-
-
-.tip,
-.warning,
-.caution,
-.note {
-  border: 1px solid;
-}
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  border-bottom: 1px solid;
-}
-
-.question td {
-  border-top: 1px solid black;
-}
-
-.answer {
-}
-
-
-b.keycap,
-.keycap {
-  border: 1px solid;
-}
-
-
-div.navheader, div.heading{
-  border-bottom: 1px solid;
-}
-
-
-div.navfooter, div.footing{
-  border-top: 1px solid;
-}
-
-  /********* /
- /  colors  /
-/ *********/
-
-body {
-  color: #333;
-  background: white;
-}
-
-a {
-  background: transparent;
-}
-
-a:hover {
-  background-color: #dedede;
-}
-
-
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7,
-h8 {
-  background-color: transparent;
-}
-
-hr {
-  border-color: #aaa;
-}
-
-
-.tip, .warning, .caution, .note {
-  border-color: #fff;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  border-bottom-color: #fff;
-}
-
-
-.warning {
-  background-color: #f0f0f2;
-}
-
-.caution {
-  background-color: #f0f0f2;
-}
-
-.tip {
-  background-color: #f0f0f2;
-}
-
-.note {
-  background-color: #f0f0f2;
-}
-
-.glossary dl dt,
-.variablelist dl dt,
-.variablelist dl dt span.term {
-  color: #044;
-}
-
-div.figure,
-div.table,
-div.example,
-div.informalfigure,
-div.informaltable,
-div.informalexample {
-  border-color: #aaa;
-}
-
-pre.programlisting {
-  color: black;
-  background-color: #fff;
-  border-color: #aaa;
-  border-width: 2px;
-}
-
-.guimenu,
-.guilabel,
-.guimenuitem {
-  background-color: #eee;
-}
-
-
-b.keycap,
-.keycap {
-  background-color: #eee;
-  border-color: #999;
-}
-
-
-div.navheader {
-  border-color: black;
-}
-
-
-div.navfooter {
-  border-color: black;
-}
-
-
-.writernotes {
-  color: red;
-}
-
-
-  /*********** /
- /  graphics  /
-/ ***********/
-
-/*
-body {
-  background-image: url("images/body_bg.jpg");
-  background-attachment: fixed;
-}
-
-.navheader,
-.note,
-.tip {
-  background-image: url("images/note_bg.jpg");
-  background-attachment: fixed;
-}
-
-.warning,
-.caution {
-  background-image: url("images/warning_bg.jpg");
-  background-attachment: fixed;
-}
-
-.figure,
-.informalfigure,
-.example,
-.informalexample,
-.table,
-.informaltable {
-  background-image: url("images/figure_bg.jpg");
-  background-attachment: fixed;
-}
-
-*/
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7{
-}
-
-/*
-Example of how to stick an image as part of the title.
-
-div.article .titlepage .title
-{
-  background-image: url("figures/white-on-black.png");
-  background-position: center;
-  background-repeat: repeat-x;
-}
-*/
-
-div.preface .titlepage .title,
-div.colophon .title,
-div.chapter .titlepage .title {
-  background-position: bottom;
-  background-repeat: repeat-x;
-}
-
-div.section div.section .titlepage .title,
-div.sect2 .titlepage .title {
-    background: none;
-}
-
-
-h1.title {
-  background-color: transparent;
-  background-repeat: no-repeat;
-  height: 256px;
-  text-indent: -9000px;
-  overflow:hidden;
-}
-
-h2.subtitle {
-  background-color: transparent;
-  text-indent: -9000px;
-  overflow:hidden;
-  width: 0px;
-  display: none;
-}
-
-  /*************************************** /
- /  pippin.gimp.org specific alterations  /
-/ ***************************************/
-
-/*
-div.heading, div.navheader {
-  color: #777;
-  font-size: 80%;
-  padding: 0;
-  margin: 0;
-  text-align: left;
-  position: absolute;
-  top: 0px;
-  left: 0px;
-  width: 100%;
-  height: 50px;
-  background: url('/gfx/heading_bg.png') transparent;
-  background-repeat: repeat-x;
-  background-attachment: fixed;
-  border: none;
-}
-
-div.heading a {
-  color: #444;
-}
-
-div.footing, div.navfooter {
-  border: none;
-  color: #ddd;
-  font-size: 80%;
-  text-align:right;
-
-  width: 100%;
-  padding-top: 10px;
-  position: absolute;
-  bottom: 0px;
-  left: 0px;
-
-  background: url('/gfx/footing_bg.png') transparent;
-}
-*/
-
-
-
-  /****************** /
- /  nasty ie tweaks  /
-/ ******************/
-
-/*
-div.heading, div.navheader {
-  width:expression(document.body.clientWidth + "px");
-}
-
-div.footing, div.navfooter {
-  width:expression(document.body.clientWidth + "px");
-  margin-left:expression("-5em");
-}
-body {
-  padding:expression("4em 5em 0em 5em");
-}
-*/
-
-  /**************************************** /
- / mozilla vendor specific css extensions  /
-/ ****************************************/
-/*
-div.navfooter, div.footing{
-  -moz-opacity: 0.8em;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example,
-.tip,
-.warning,
-.caution,
-.note {
-  -moz-border-radius: 0.5em;
-}
-
-b.keycap,
-.keycap {
-  -moz-border-radius: 0.3em;
-}
-*/
-
-table tr td table tr td {
-  display: none;
-}
-
-
-hr {
-  display: none;
-}
-
-table {
-  border: 0em;
-}
-
- .photo {
-  float: right;
-  margin-left:   1.5em;
-  margin-bottom: 1.5em;
-  margin-top: 0em;
-  max-width:      17em;
-  border:     1px solid gray;
-  padding:    3px;
-  background: white;
-}
- .seperator {
-   padding-top: 2em;
-   clear: both;
-  }
-
-  #validators {
-      margin-top: 5em;
-      text-align: right;
-      color: #777;
-  }
-  @media print {
-      body {
-          font-size: 8pt;
-      }
-      .noprint {
-          display: none;
-      }
-  }
-
-
-.tip,
-.note {
-   background: #f0f0f2;
-   color: #333;
-   padding: 20px;
-   margin: 20px;
-}
-
-.tip h3,
-.note h3 {
-   padding: 0em;
-   margin: 0em;
-   font-size: 2em;
-   font-weight: bold;
-   color: #333;
-}
-
-.tip a,
-.note a {
-   color: #333;
-   text-decoration: underline;
-}
-
-.footnote {
-   font-size: small;
-   color: #333;
-}
-
-/* Changes the announcement text */
-.tip h3,
-.warning h3,
-.caution h3,
-.note h3 {
-   font-size:large;
-   color: #00557D;
-}

documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst

@@ -0,0 +1,430 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+=========================
+Yocto Project Quick Build
+=========================
+
+Welcome!
+========
+
+This short document steps you through the process for a typical
+image build using the Yocto Project. The document also introduces how to
+configure a build for specific hardware. You will use Yocto Project to
+build a reference embedded OS called Poky.
+
+.. note::
+
+   -  The examples in this paper assume you are using a native Linux
+      system running a recent Ubuntu Linux distribution. If the machine
+      you want to use Yocto Project on to build an image
+      (:term:`Build Host`) is not
+      a native Linux system, you can still perform these steps by using
+      CROss PlatformS (CROPS) and setting up a Poky container. See the
+      :ref:`dev-manual/dev-manual-start:setting up to use cross platforms (crops)`
+      section
+      in the Yocto Project Development Tasks Manual for more
+      information.
+
+   -  You may use Windows Subsystem For Linux v2 to set up a build host
+      using Windows 10.
+
+      .. note::
+
+         The Yocto Project is not compatible with WSLv1, it is
+         compatible but not officially supported nor validated with
+         WSLv2, if you still decide to use WSL please upgrade to WSLv2.
+
+      See the :ref:`dev-manual/dev-manual-start:setting up to use windows
+      subsystem for linux (wslv2)` section in the Yocto Project Development
+      Tasks Manual for more information.
+
+If you want more conceptual or background information on the Yocto
+Project, see the :doc:`../overview-manual/overview-manual`.
+
+Compatible Linux Distribution
+=============================
+
+Make sure your :term:`Build Host` meets the
+following requirements:
+
+-  50 Gbytes of free disk space
+
+-  Runs a supported Linux distribution (i.e. recent releases of Fedora,
+   openSUSE, CentOS, Debian, or Ubuntu). For a list of Linux
+   distributions that support the Yocto Project, see the
+   :ref:`ref-manual/ref-system-requirements:supported linux distributions`
+   section in the Yocto Project Reference Manual. For detailed
+   information on preparing your build host, see the
+   :ref:`dev-manual/dev-manual-start:preparing the build host`
+   section in the Yocto Project Development Tasks Manual.
+
+-
+
+   -  Git 1.8.3.1 or greater
+   -  tar 1.28 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
+:ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`
+section in the Yocto Project Reference Manual for information.
+
+Build Host Packages
+===================
+
+You must install essential host packages on your build host. The
+following command installs the host packages based on an Ubuntu
+distribution:
+
+.. code-block:: shell
+
+  $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
+
+.. note::
+
+   For host package requirements on all supported Linux distributions,
+   see the :ref:`ref-manual/ref-system-requirements:required packages for the build host`
+   section in the Yocto Project Reference Manual.
+
+Use Git to Clone Poky
+=====================
+
+Once you complete the setup instructions for your machine, you need to
+get a copy of the Poky repository on your build host. Use the following
+commands to clone the Poky repository.
+
+.. code-block:: shell
+
+   $ git clone git://git.yoctoproject.org/poky
+   Cloning into 'poky'...
+   remote: Counting
+   objects: 432160, done. remote: Compressing objects: 100%
+   (102056/102056), done. remote: Total 432160 (delta 323116), reused
+   432037 (delta 323000) Receiving objects: 100% (432160/432160), 153.81 MiB | 8.54 MiB/s, done.
+   Resolving deltas: 100% (323116/323116), done.
+   Checking connectivity... done.
+
+Move to the ``poky`` directory and take a look at the tags:
+
+.. code-block:: shell
+
+   $ cd poky
+   $ git fetch --tags
+   $ git tag
+   1.1_M1.final
+   1.1_M1.rc1
+   1.1_M1.rc2
+   1.1_M2.final
+   1.1_M2.rc1
+   .
+   .
+   .
+   yocto-2.5
+   yocto-2.5.1
+   yocto-2.5.2
+   yocto-2.6
+   yocto-2.6.1
+   yocto-2.6.2
+   yocto-2.7
+   yocto_1.5_M5.rc8
+
+For this example, check out the branch based on the
+``&DISTRO_REL_TAG;`` release:
+
+.. code-block:: shell
+
+   $ git checkout tags/&DISTRO_REL_TAG; -b my-&DISTRO_REL_TAG;
+   Switched to a new branch 'my-&DISTRO_REL_TAG;'
+
+The previous Git checkout command creates a local branch named
+``my-&DISTRO_REL_TAG;``. The files available to you in that branch exactly
+match the repository's files in the ``&DISTRO_NAME_NO_CAP;`` development
+branch at the time of the Yocto Project &DISTRO_REL_TAG; release.
+
+For more options and information about accessing Yocto Project related
+repositories, see the
+:ref:`dev-manual/dev-manual-start:locating yocto project source files`
+section in the Yocto Project Development Tasks Manual.
+
+Building Your Image
+===================
+
+Use the following steps to build your image. The build process creates
+an entire Linux distribution, including the toolchain, from source.
+
+.. note::
+
+   -  If you are working behind a firewall and your build host is not
+      set up for proxies, you could encounter problems with the build
+      process when fetching source code (e.g. fetcher failures or Git
+      failures).
+
+   -  If you do not know your proxy settings, consult your local network
+      infrastructure resources and get that information. A good starting
+      point could also be to check your web browser settings. Finally,
+      you can find more information on the
+      ":yocto_wiki:`Working Behind a Network Proxy </wiki/Working_Behind_a_Network_Proxy>`"
+      page of the Yocto Project Wiki.
+
+#. **Initialize the Build Environment:** From within the ``poky``
+   directory, run the :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\``
+   environment
+   setup script to define Yocto Project's build environment on your
+   build host.
+
+   .. code-block:: shell
+
+      $ cd ~/poky
+      $ source oe-init-build-env
+      You had no conf/local.conf file. This configuration file has therefore been
+      created for you with some default values. You may wish to edit it to, for
+      example, select a different MACHINE (target hardware). See conf/local.conf
+      for more information as common configuration options are commented.
+
+      You had no conf/bblayers.conf file. This configuration file has therefore
+      been created for you with some default values. To add additional metadata
+      layers into your configuration please add entries to conf/bblayers.conf.
+
+      The Yocto Project has extensive documentation about OE including a reference
+      manual which can be found at:
+          http://yoctoproject.org/documentation
+
+      For more information about OpenEmbedded see their website:
+          http://www.openembedded.org/
+
+      ### Shell environment set up for builds. ###
+
+      You can now run 'bitbake <target>'
+
+      Common targets are:
+          core-image-minimal
+          core-image-sato
+          meta-toolchain
+          meta-ide-support
+
+      You can also run generated qemu images with a command like 'runqemu qemux86-64'
+
+   Among other things, the script creates the :term:`Build Directory`, which is
+   ``build`` in this case and is located in the :term:`Source Directory`.  After
+   the script runs, your current working directory is set to the Build
+   Directory. Later, when the build completes, the Build Directory contains all the
+   files created during the build.
+
+#. **Examine Your Local Configuration File:** When you set up the build
+   environment, a local configuration file named ``local.conf`` becomes
+   available in a ``conf`` subdirectory of the Build Directory. For this
+   example, the defaults are set to build for a ``qemux86`` target,
+   which is suitable for emulation. The package manager used is set to
+   the RPM package manager.
+
+   .. tip::
+
+      You can significantly speed up your build and guard against fetcher
+      failures by using mirrors. To use mirrors, add these lines to your
+      local.conf file in the Build directory: ::
+
+         SSTATE_MIRRORS = "\
+         file://.* http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH \n \
+         file://.* http://sstate.yoctoproject.org/&YOCTO_DOC_VERSION_MINUS_ONE;/PATH;downloadfilename=PATH \n \
+         file://.* http://sstate.yoctoproject.org/&YOCTO_DOC_VERSION;/PATH;downloadfilename=PATH \n \
+         "
+
+
+      The previous examples showed how to add sstate paths for Yocto Project
+      &YOCTO_DOC_VERSION_MINUS_ONE;, &YOCTO_DOC_VERSION;, and a development
+      area. For a complete index of sstate locations, see http://sstate.yoctoproject.org/.
+
+#. **Start the Build:** Continue with the following command to build an OS
+   image for the target, which is ``core-image-sato`` in this example:
+
+   .. code-block:: shell
+
+      $ bitbake core-image-sato
+
+   For information on using the ``bitbake`` command, see the
+   :ref:`usingpoky-components-bitbake` section in the Yocto Project Overview and
+   Concepts Manual, or see the ":ref:`BitBake Command
+   <bitbake:bitbake-user-manual-command>`" section in the BitBake User Manual.
+
+#. **Simulate Your Image Using QEMU:** Once this particular image is
+   built, you can start QEMU, which is a Quick EMUlator that ships with
+   the Yocto Project:
+
+   .. code-block:: shell
+
+      $ runqemu qemux86-64
+
+   If you want to learn more about running QEMU, see the
+   :ref:`dev-manual/dev-manual-qemu:using the quick emulator (qemu)` chapter in
+   the Yocto Project Development Tasks Manual.
+
+#. **Exit QEMU:** Exit QEMU by either clicking on the shutdown icon or by typing
+   ``Ctrl-C`` in the QEMU transcript window from which you evoked QEMU.
+
+Customizing Your Build for Specific Hardware
+============================================
+
+So far, all you have done is quickly built an image suitable for
+emulation only. This section shows you how to customize your build for
+specific hardware by adding a hardware layer into the Yocto Project
+development environment.
+
+In general, layers are repositories that contain related sets of
+instructions and configurations that tell the Yocto Project what to do.
+Isolating related metadata into functionally specific layers facilitates
+modular development and makes it easier to reuse the layer metadata.
+
+.. note::
+
+   By convention, layer names start with the string "meta-".
+
+Follow these steps to add a hardware layer:
+
+#. **Find a Layer:** Lots of hardware layers exist. The Yocto Project
+   :yocto_git:`Source Repositories <>` has many hardware layers.
+   This example adds the
+   `meta-altera <https://github.com/kraj/meta-altera>`__ hardware layer.
+
+#. **Clone the Layer:** Use Git to make a local copy of the layer on your
+   machine. You can put the copy in the top level of the copy of the
+   Poky repository created earlier:
+
+   .. code-block:: shell
+
+      $ cd ~/poky
+      $ git clone https://github.com/kraj/meta-altera.git
+      Cloning into 'meta-altera'...
+      remote: Counting objects: 25170, done.
+      remote: Compressing objects: 100% (350/350), done.
+      remote: Total 25170 (delta 645), reused 719 (delta 538), pack-reused 24219
+      Receiving objects: 100% (25170/25170), 41.02 MiB | 1.64 MiB/s, done.
+      Resolving deltas: 100% (13385/13385), done.
+      Checking connectivity... done.
+
+   The hardware layer now exists
+   with other layers inside the Poky reference repository on your build
+   host as ``meta-altera`` and contains all the metadata needed to
+   support hardware from Altera, which is owned by Intel.
+
+   .. note::
+
+      It is recommended for layers to have a branch per Yocto Project release.
+      Please make sure to checkout the layer branch supporting the Yocto Project
+      release you're using.
+
+#. **Change the Configuration to Build for a Specific Machine:** The
+   :term:`MACHINE` variable in the
+   ``local.conf`` file specifies the machine for the build. For this
+   example, set the ``MACHINE`` variable to ``cyclone5``. These
+   configurations are used:
+   https://github.com/kraj/meta-altera/blob/master/conf/machine/cyclone5.conf.
+
+   .. note::
+
+      See the "Examine Your Local Configuration File" step earlier for more
+      information on configuring the build.
+
+#. **Add Your Layer to the Layer Configuration File:** Before you can use
+   a layer during a build, you must add it to your ``bblayers.conf``
+   file, which is found in the
+   :term:`Build Directory` ``conf``
+   directory.
+
+   Use the ``bitbake-layers add-layer`` command to add the layer to the
+   configuration file:
+
+   .. code-block:: shell
+
+      $ cd ~/poky/build
+      $ bitbake-layers add-layer ../meta-altera
+      NOTE: Starting bitbake server...
+      Parsing recipes: 100% |##################################################################| Time: 0:00:32
+      Parsing of 918 .bb files complete (0 cached, 918 parsed). 1401 targets,
+      123 skipped, 0 masked, 0 errors.
+
+   You can find
+   more information on adding layers in the
+   :ref:`dev-manual/dev-manual-common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`
+   section.
+
+Completing these steps has added the ``meta-altera`` layer to your Yocto
+Project development environment and configured it to build for the
+``cyclone5`` machine.
+
+.. note::
+
+   The previous steps are for demonstration purposes only. If you were
+   to attempt to build an image for the ``cyclone5`` machine, you should
+   read the Altera ``README``.
+
+Creating Your Own General Layer
+===============================
+
+Maybe you have an application or specific set of behaviors you need to
+isolate. You can create your own general layer using the
+``bitbake-layers create-layer`` command. The tool automates layer
+creation by setting up a subdirectory with a ``layer.conf``
+configuration file, a ``recipes-example`` subdirectory that contains an
+``example.bb`` recipe, a licensing file, and a ``README``.
+
+The following commands run the tool to create a layer named
+``meta-mylayer`` in the ``poky`` directory:
+
+.. code-block:: shell
+
+   $ cd ~/poky
+   $ bitbake-layers create-layer meta-mylayer
+   NOTE: Starting bitbake server...
+   Add your new layer with 'bitbake-layers add-layer meta-mylayer'
+
+For more information
+on layers and how to create them, see the
+:ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`
+section in the Yocto Project Development Tasks Manual.
+
+Where To Go Next
+================
+
+Now that you have experienced using the Yocto Project, you might be
+asking yourself "What now?". The Yocto Project has many sources of
+information including the website, wiki pages, and user manuals:
+
+-  **Website:** The :yocto_home:`Yocto Project Website <>` provides
+   background information, the latest builds, breaking news, full
+   development documentation, and access to a rich Yocto Project
+   Development Community into which you can tap.
+
+-  **Developer Screencast:** The `Getting Started with the Yocto Project -
+   New Developer Screencast Tutorial <http://vimeo.com/36450321>`__
+   provides a 30-minute video created for users unfamiliar with the
+   Yocto Project but familiar with Linux build hosts. While this
+   screencast is somewhat dated, the introductory and fundamental
+   concepts are useful for the beginner.
+
+-  **Yocto Project Overview and Concepts Manual:** The
+   :doc:`../overview-manual/overview-manual` is a great
+   place to start to learn about the Yocto Project. This manual
+   introduces you to the Yocto Project and its development environment.
+   The manual also provides conceptual information for various aspects
+   of the Yocto Project.
+
+-  **Yocto Project Wiki:** The :yocto_wiki:`Yocto Project Wiki <>`
+   provides additional information on where to go next when ramping up
+   with the Yocto Project, release information, project planning, and QA
+   information.
+
+-  **Yocto Project Mailing Lists:** Related mailing lists provide a forum
+   for discussion, patch submission and announcements. Several mailing
+   lists exist and are grouped according to areas of concern. See the
+   :ref:`ref-manual/resources:mailing lists`
+   section in the Yocto Project Reference Manual for a complete list of
+   Yocto Project mailing lists.
+
+-  **Comprehensive List of Links and Other Documentation:** The
+   :ref:`ref-manual/resources:links and related documentation`
+   section in the Yocto Project Reference Manual provides a
+   comprehensive list of all related links and other user documentation.
+
+.. include:: /boilerplate.rst

documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml

@@ -1,576 +0,0 @@
-<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
-[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
-
-<article id='brief-yocto-project-qs-intro'>
-    <articleinfo>
-        <title>Yocto Project Quick Build</title>
-
-        <copyright>
-            <year>&COPYRIGHT_YEAR;</year>
-            <holder>Linux Foundation</holder>
-        </copyright>
-
-        <legalnotice>
-            <para>
-                Permission is granted to copy, distribute and/or modify this document under
-                the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
-            </para>
-        </legalnotice>
-
-
-        <abstract>
-            <imagedata fileref="figures/yocto-project-transp.png"
-                        width="6in" depth="1in"
-                        align="right" scale="25" />
-        </abstract>
-    </articleinfo>
-
-    <section id='brief-welcome'>
-        <title>Welcome!</title>
-
-        <para>
-            Welcome!
-            This short document steps you through the process for a typical
-            image build using the Yocto Project.
-            The document also introduces how to configure a build for specific
-            hardware.
-            You will use Yocto Project to build a reference embedded OS
-            called Poky.
-            <note><title>Notes</title>
-                <itemizedlist>
-                    <listitem><para>
-                        The examples in this paper assume you are using a
-                        native Linux system running a recent Ubuntu Linux
-                        distribution.
-                        If the machine you want to use Yocto Project on to
-                        build an image
-                        (<ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>)
-                        is not a native Linux system, you can
-                        still perform these steps by using CROss PlatformS
-                        (CROPS) and setting up a Poky container.
-                        See the
-                        <ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-crops'>Setting Up to Use CROss PlatformS (CROPS)</ulink>"
-                        section in the Yocto Project Development Tasks Manual for more
-                        information.
-                        </para></listitem>
-                    <listitem><para>
-                        You may use Windows Subsystem For Linux v2 to set up a build
-                        host using Windows 10.
-                        <note>
-                          The Yocto Project is not compatible with WSLv1, it is
-                          compatible but not officially supported nor validated
-                          with WSLv2, if you still decide to use WSL please upgrade
-                          to WSLv2.
-                        </note>
-                        See the
-                        <ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-wsl'>Setting Up to Use Windows Subsystem For Linux</ulink>"
-                        section in the Yocto Project Development Tasks Manual for more
-                        information.
-                        </para></listitem>
-                </itemizedlist>
-            </note>
-        </para>
-
-        <para>
-            If you want more conceptual or background information on the
-            Yocto Project, see the
-            <ulink url='&YOCTO_DOCS_OM_URL;'>Yocto Project Overview and Concepts Manual</ulink>.
-        </para>
-    </section>
-
-    <section id='brief-compatible-distro'>
-        <title>Compatible Linux Distribution</title>
-
-        <para>
-            Make sure your
-            <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>
-            meets the following requirements:
-            <itemizedlist>
-                <listitem><para>
-                    50 Gbytes of free disk space
-                    </para></listitem>
-                <listitem><para>
-                    Runs a supported Linux distribution (i.e. recent releases of
-                    Fedora, openSUSE, CentOS, Debian, or Ubuntu). For a list of
-                    Linux distributions that support the Yocto Project, see the
-                    "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>"
-                    section in the Yocto Project Reference Manual.
-                    For detailed information on preparing your build host, see
-                    the
-                    "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-preparing-the-build-host'>Preparing the Build Host</ulink>"
-                    section in the Yocto Project Development Tasks Manual.
-                    </para></listitem>
-                <listitem><para>
-                    <itemizedlist>
-                        <listitem><para>
-                            Git 1.8.3.1 or greater
-                            </para></listitem>
-                        <listitem><para>
-                            tar 1.28 or greater
-                            </para></listitem>
-                        <listitem><para>
-                            Python 3.5.0 or greater.
-                        </para></listitem>
-                        <listitem><para>
-                            gcc 5.0 or greater.
-                        </para></listitem>
-                    </itemizedlist>
-                    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
-                    "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</ulink>"
-                    section in the Yocto Project Reference Manual for information.
-                    </para></listitem>
-            </itemizedlist>
-        </para>
-    </section>
-
-    <section id='brief-build-system-packages'>
-        <title>Build Host Packages</title>
-
-        <para>
-            You must install essential host packages on your
-            build host.
-            The following command installs the host packages based on an
-            Ubuntu distribution:
-            <note>
-                For host package requirements on all supported Linux
-                distributions, see the
-                "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-build-host'>Required Packages for the Build Host</ulink>"
-                section in the Yocto Project Reference Manual.
-            </note>
-            <literallayout class='monospaced'>
-     $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
-            </literallayout>
-        </para>
-    </section>
-
-    <section id='brief-use-git-to-clone-poky'>
-        <title>Use Git to Clone Poky</title>
-
-        <para>
-            Once you complete the setup instructions for your machine,
-            you need to get a copy of the Poky repository on your build
-            host.
-            Use the following commands to clone the Poky
-            repository.
-            <literallayout class='monospaced'>
-     $ git clone git://git.yoctoproject.org/poky
-     Cloning into 'poky'...
-     remote: Counting objects: 432160, done.
-     remote: Compressing objects: 100% (102056/102056), done.
-     remote: Total 432160 (delta 323116), reused 432037 (delta 323000)
-     Receiving objects: 100% (432160/432160), 153.81 MiB | 8.54 MiB/s, done.
-     Resolving deltas: 100% (323116/323116), done.
-     Checking connectivity... done.
-            </literallayout>
-            Move to the <filename>poky</filename> directory and take a look
-            at the tags:
-            <literallayout class='monospaced'>
-     $ cd poky
-     $ git fetch --tags
-     $ git tag
-     1.1_M1.final
-     1.1_M1.rc1
-     1.1_M1.rc2
-     1.1_M2.final
-     1.1_M2.rc1
-        .
-        .
-        .
-     yocto-2.5
-     yocto-2.5.1
-     yocto-2.5.2
-     yocto-2.6
-     yocto-2.6.1
-     yocto-2.6.2
-     yocto-2.7
-     yocto_1.5_M5.rc8
-            </literallayout>
-            For this example, check out the branch based on the
-            &DISTRO_REL_TAG; release:
-            <literallayout class='monospaced'>
-     $ git checkout tags/&DISTRO_REL_TAG; -b my-&DISTRO_REL_TAG;
-     Switched to a new branch 'my-&DISTRO_REL_TAG;'
-            </literallayout>
-            The previous Git checkout command creates a local branch
-            named my-&DISTRO_REL_TAG;. The files available to you in that
-            branch exactly match the repository's files in the
-            "&DISTRO_NAME_NO_CAP;" development branch at the time of the
-            Yocto Project &DISTRO_REL_TAG; release.
-        </para>
-
-        <para>
-            For more options and information about accessing Yocto
-            Project related repositories, see the
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#locating-yocto-project-source-files'>Locating Yocto Project Source Files</ulink>"
-            section in the Yocto Project Development Tasks Manual.
-        </para>
-    </section>
-
-    <section id='brief-building-your-image'>
-        <title>Building Your Image</title>
-
-        <para>
-            Use the following steps to build your image.
-            The build process creates an entire Linux distribution, including
-            the toolchain, from source.
-            <note>
-                <itemizedlist>
-                    <listitem><para>
-                        If you are working behind a firewall and your build
-                        host is not set up for proxies, you could encounter
-                        problems with the build process when fetching source
-                        code (e.g. fetcher failures or Git failures).
-                        </para></listitem>
-                    <listitem><para>
-                        If you do not know your proxy settings, consult your
-                        local network infrastructure resources and get that
-                        information.
-                        A good starting point could also be to check your
-                        web browser settings.
-                        Finally, you can find more information on the
-                        "<ulink url='https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy'>Working Behind a Network Proxy</ulink>"
-                        page of the Yocto Project Wiki.
-                        </para></listitem>
-                </itemizedlist>
-            </note>
-        </para>
-
-        <para>
-            <orderedlist>
-                <listitem><para>
-                    <emphasis>Initialize the Build Environment:</emphasis>
-                    From within the <filename>poky</filename> directory, run the
-                    <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
-                    environment setup script to define Yocto Project's
-                    build environment on your build host.
-                    <literallayout class='monospaced'>
-     $ cd ~/poky
-     $ source &OE_INIT_FILE;
-     You had no conf/local.conf file. This configuration file has therefore been
-     created for you with some default values. You may wish to edit it to, for
-     example, select a different MACHINE (target hardware). See conf/local.conf
-     for more information as common configuration options are commented.
-
-     You had no conf/bblayers.conf file. This configuration file has therefore been
-     created for you with some default values. To add additional metadata layers
-     into your configuration please add entries to conf/bblayers.conf.
-
-     The Yocto Project has extensive documentation about OE including a reference
-     manual which can be found at:
-         http://yoctoproject.org/documentation
-
-     For more information about OpenEmbedded see their website:
-         http://www.openembedded.org/
-
-
-     ### Shell environment set up for builds. ###
-
-     You can now run 'bitbake &lt;target&gt;'
-
-     Common targets are:
-         core-image-minimal
-         core-image-sato
-         meta-toolchain
-         meta-ide-support
-
-     You can also run generated qemu images with a command like 'runqemu qemux86-64'
-                    </literallayout>
-                    Among other things, the script creates the
-                    <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>,
-                    which is <filename>build</filename> in this case
-                    and is located in the
-                    <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>.
-                    After the script runs, your current working directory
-                    is set to the Build Directory.
-                    Later, when the build completes, the Build Directory
-                    contains all the files created during the build.
-                    </para></listitem>
-                <listitem><para id='conf-file-step'>
-                    <emphasis>Examine Your Local Configuration File:</emphasis>
-                    When you set up the build environment, a local
-                    configuration file named
-                    <filename>local.conf</filename> becomes available in
-                    a <filename>conf</filename> subdirectory of the
-                    Build Directory.
-                    For this example, the defaults are set to build
-                    for a <filename>qemux86</filename> target, which is
-                    suitable for emulation.
-                    The package manager used is set to the RPM package
-                    manager.
-                    <tip>
-                        You can significantly speed up your build and guard
-                        against fetcher failures by using mirrors.
-                        To use mirrors, add these lines to your
-                        <filename>local.conf</filename> file in the Build
-                        directory:
-                        <literallayout class='monospaced'>
-     SSTATE_MIRRORS = "\
-     file://.* http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH \n \
-     file://.* http://sstate.yoctoproject.org/&YOCTO_DOC_VERSION_MINUS_ONE;/PATH;downloadfilename=PATH \n \
-     file://.* http://sstate.yoctoproject.org/&YOCTO_DOC_VERSION;/PATH;downloadfilename=PATH \n \
-     "
-                        </literallayout>
-                        The previous examples showed how to add sstate
-                        paths for Yocto Project &YOCTO_DOC_VERSION_MINUS_ONE;,
-                        &YOCTO_DOC_VERSION;, and a development area.
-                        For a complete index of sstate locations, see
-                        <ulink url='http://sstate.yoctoproject.org/'></ulink>.
-                    </tip>
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Start the Build:</emphasis>
-                    Continue with the following command to build an OS image
-                    for the target, which is
-                    <filename>core-image-sato</filename> in this example:
-                    <literallayout class='monospaced'>
-     $ bitbake core-image-sato
-                    </literallayout>
-                    For information on using the
-                    <filename>bitbake</filename> command, see the
-                    "<ulink url='&YOCTO_DOCS_OM_URL;#usingpoky-components-bitbake'>BitBake</ulink>"
-                    section in the Yocto Project Overview and Concepts Manual,
-                    or see the
-                    "<ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual-command'>BitBake Command</ulink>"
-                    section in the BitBake User Manual.
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Simulate Your Image Using QEMU:</emphasis>
-                    Once this particular image is built, you can start
-                    QEMU, which is a Quick EMUlator that ships with
-                    the Yocto Project:
-                    <literallayout class='monospaced'>
-     $ runqemu qemux86-64
-                    </literallayout>
-                    If you want to learn more about running QEMU, see the
-                    "<ulink url="&YOCTO_DOCS_DEV_URL;#dev-manual-qemu">Using the Quick EMUlator (QEMU)</ulink>"
-                    chapter in the Yocto Project Development Tasks Manual.
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Exit QEMU:</emphasis>
-                    Exit QEMU by either clicking on the shutdown icon or by
-                    typing <filename>Ctrl-C</filename> in the QEMU
-                    transcript window from which you evoked QEMU.
-                    </para></listitem>
-            </orderedlist>
-        </para>
-    </section>
-
-    <section id='customizing-your-build-for-specific-hardware'>
-        <title>Customizing Your Build for Specific Hardware</title>
-
-        <para>
-            So far, all you have done is quickly built an image suitable
-            for emulation only.
-            This section shows you how to customize your build for specific
-            hardware by adding a hardware layer into the Yocto Project
-            development environment.
-        </para>
-
-        <para>
-            In general, layers are repositories that contain related sets of
-            instructions and configurations that tell the Yocto Project what
-            to do.
-            Isolating related metadata into functionally specific layers
-            facilitates modular development and makes it easier to reuse the
-            layer metadata.
-            <note>
-                By convention, layer names start with the string "meta-".
-            </note>
-        </para>
-
-        <para>
-            Follow these steps to add a hardware layer:
-            <orderedlist>
-                <listitem><para>
-                    <emphasis>Find a Layer:</emphasis>
-                    Lots of hardware layers exist.
-                    The Yocto Project
-                    <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>
-                    has many hardware layers.
-                    This example adds the
-                    <ulink url='https://github.com/kraj/meta-altera'>meta-altera</ulink>
-                    hardware layer.
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Clone the Layer</emphasis>
-                    Use Git to make a local copy of the layer on your machine.
-                    You can put the copy in the top level of the copy of the
-                    Poky repository created earlier:
-                    <literallayout class='monospaced'>
-     $ cd ~/poky
-     $ git clone https://github.com/kraj/meta-altera.git
-     Cloning into 'meta-altera'...
-     remote: Counting objects: 25170, done.
-     remote: Compressing objects: 100% (350/350), done.
-     remote: Total 25170 (delta 645), reused 719 (delta 538), pack-reused 24219
-     Receiving objects: 100% (25170/25170), 41.02 MiB | 1.64 MiB/s, done.
-     Resolving deltas: 100% (13385/13385), done.
-     Checking connectivity... done.
-                    </literallayout>
-                    The hardware layer now exists with other layers inside
-                    the Poky reference repository on your build host as
-                    <filename>meta-altera</filename> and contains all the
-                    metadata needed to support hardware from Altera, which
-                    is owned by Intel.
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Change the Configuration to Build for a Specific Machine:</emphasis>
-                    The
-                    <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
-                    variable in the <filename>local.conf</filename> file
-                    specifies the machine for the build.
-                    For this example, set the <filename>MACHINE</filename>
-                    variable to "cyclone5".
-                    These configurations are used:
-                    <ulink url='https://github.com/kraj/meta-altera/blob/master/conf/machine/cyclone5.conf'></ulink>.
-                    <note>
-                        See the
-                        "<link linkend='conf-file-step'>Examine Your Local Configuration File</link>"
-                        step earlier for more information on configuring the
-                        build.
-                    </note>
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Add Your Layer to the Layer Configuration File:</emphasis>
-                    Before you can use a layer during a build, you must add it
-                    to your <filename>bblayers.conf</filename> file, which
-                    is found in the
-                    <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory's</ulink>
-                    <filename>conf</filename> directory.</para>
-
-                    <para>Use the <filename>bitbake-layers add-layer</filename>
-                    command to add the layer to the configuration file:
-                    <literallayout class='monospaced'>
-     $ cd ~/poky/build
-     $ bitbake-layers add-layer ../meta-altera
-     NOTE: Starting bitbake server...
-     Parsing recipes: 100% |##################################################################| Time: 0:00:32
-     Parsing of 918 .bb files complete (0 cached, 918 parsed). 1401 targets, 123 skipped, 0 masked, 0 errors.
-                    </literallayout>
-                    You can find more information on adding layers in the
-                    "<ulink url='&YOCTO_DOCS_DEV_URL;#adding-a-layer-using-the-bitbake-layers-script'>Adding a Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
-                    section.
-                    </para></listitem>
-            </orderedlist>
-            Completing these steps has added the
-            <filename>meta-altera</filename> layer to your Yocto Project
-            development environment and configured it to build for the
-            "cyclone5" machine.
-            <note>
-                The previous steps are for demonstration purposes only.
-                If you were to attempt to build an image for the
-                "cyclone5" build, you should read the Altera
-                <filename>README</filename>.
-            </note>
-        </para>
-    </section>
-
-    <section id='creating-your-own-general-layer'>
-        <title>Creating Your Own General Layer</title>
-
-        <para>
-            Maybe you have an application or specific set of behaviors you
-            need to isolate.
-            You can create your own general layer using the
-            <filename>bitbake-layers create-layer</filename> command.
-            The tool automates layer creation by setting up a
-            subdirectory with a <filename>layer.conf</filename>
-            configuration file, a <filename>recipes-example</filename>
-            subdirectory that contains an <filename>example.bb</filename>
-            recipe, a licensing file, and a <filename>README</filename>.
-        </para>
-
-        <para>
-            The following commands run the tool to create a layer named
-            <filename>meta-mylayer</filename> in the
-            <filename>poky</filename> directory:
-            <literallayout class='monospaced'>
-     $ cd ~/poky
-     $ bitbake-layers create-layer meta-mylayer
-     NOTE: Starting bitbake server...
-     Add your new layer with 'bitbake-layers add-layer meta-mylayer'
-            </literallayout>
-            For more information on layers and how to create them, see the
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-general-layer-using-the-bitbake-layers-script'>Creating a General Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
-            section in the Yocto Project Development Tasks Manual.
-        </para>
-    </section>
-
-    <section id='brief-where-to-go-next'>
-        <title>Where To Go Next</title>
-
-        <para>
-            Now that you have experienced using the Yocto Project, you might
-            be asking yourself "What now?"
-            The Yocto Project has many sources of information including
-            the website, wiki pages, and user manuals:
-            <itemizedlist>
-                <listitem><para>
-                    <emphasis>Website:</emphasis>
-                    The
-                    <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>
-                    provides background information, the latest builds,
-                    breaking news, full development documentation, and
-                    access to a rich Yocto Project Development Community
-                    into which you can tap.
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Developer Screencast:</emphasis>
-                    The
-                    <ulink url='http://vimeo.com/36450321'>Getting Started with the Yocto Project - New Developer Screencast Tutorial</ulink>
-                    provides a 30-minute video created for users unfamiliar
-                    with the Yocto Project but familiar with Linux build
-                    hosts.
-                    While this screencast is somewhat dated, the
-                    introductory and fundamental concepts are useful for
-                    the beginner.
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Yocto Project Overview and Concepts Manual:</emphasis>
-                    The
-                    <ulink url='&YOCTO_DOCS_OM_URL;'>Yocto Project Overview and Concepts Manual</ulink>
-                    is a great place to start to learn about the
-                    Yocto Project.
-                    This manual introduces you to the Yocto Project and its
-                    development environment.
-                    The manual also provides conceptual information for
-                    various aspects of the Yocto Project.
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Yocto Project Wiki:</emphasis>
-                    The
-                    <ulink url='&YOCTO_WIKI_URL;'>Yocto Project Wiki</ulink>
-                    provides additional information on where to go next
-                    when ramping up with the Yocto Project, release
-                    information, project planning, and QA information.
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Yocto Project Mailing Lists:</emphasis>
-                    Related mailing lists provide a forum for discussion,
-                    patch submission and announcements.
-                    Several mailing lists exist and are grouped according
-                    to areas of concern.
-                    See the
-                    "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing lists</ulink>"
-                    section in the Yocto Project Reference Manual for a
-                    complete list of Yocto Project mailing lists.
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Comprehensive List of Links and Other Documentation:</emphasis>
-                    The
-                    "<ulink url='&YOCTO_DOCS_REF_URL;#resources-links-and-related-documentation'>Links and Related Documentation</ulink>"
-                    section in the Yocto Project Reference Manual provides a
-                    comprehensive list of all related links and other
-                    user documentation.
-                    </para></listitem>
-            </itemizedlist>
-        </para>
-    </section>
-</article>
-<!--
-vim: expandtab tw=80 ts=4
--->

documentation/bsp-guide/bsp-guide-customization.xsl

@@ -1,27 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
-
-  <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
-
-<!--
-
-  <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
-
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
-
--->
-
-  <xsl:include href="../template/permalinks.xsl"/>
-  <xsl:include href="../template/section.title.xsl"/>
-  <xsl:include href="../template/component.title.xsl"/>
-  <xsl:include href="../template/division.title.xsl"/>
-  <xsl:include href="../template/formal.object.heading.xsl"/>
-
-  <xsl:param name="html.stylesheet" select="'bsp-style.css'" />
-  <xsl:param name="chapter.autolabel" select="1" />
-  <xsl:param name="appendix.autolabel" select="A" />
-  <xsl:param name="section.autolabel" select="1" />
-  <xsl:param name="section.label.includes.component.label" select="1" />
-  <xsl:param name="generate.id.attributes" select="1" />
-
-</xsl:stylesheet>

documentation/bsp-guide/bsp-guide.rst

@@ -0,0 +1,16 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+=====================================================
+Yocto Project Board Support Package Developer's Guide
+=====================================================
+
+|
+
+.. toctree::
+   :caption: Table of Contents
+   :numbered:
+
+   bsp
+   history
+
+.. include:: /boilerplate.rst