poky: subtree update:1203d1f24d..2dcd1f2a21

Alejandro Enedino Hernandez Samaniego (2):
      python3: Improve logging, syntax and update deprecated modules to create_manifest
      python3: Upgrade 3.9.2 -> 3.9.4

Alexander Kanavin (22):
      scripts/oe-debuginfod: correct several issues
      libmicrohttpd: add a recipe from meta-oe
      maintainers.inc: add libmicrohttpd entry
      xwayland: add a standalone recipe
      weston: use standalone xwayland instead of outdated xserver-xorg version
      elfutils: correct debuginfod builds on x32
      elfutils: adjust ptests for correct debuginfod testing
      default-distrovars.inc: add debuginfod to default DISTRO_FEATURES
      oeqa: tear down oeqa decorators if one of them raises an exception in setup
      meta/lib/oeqa/core/tests/cases/timeout.py: add a testcase for the previous fix
      core-image-weston: add sdk/ptest images
      oeqa/core/tests/test_data.py: use weston image instead of sato
      oeqa/selftest: transition to weston images
      core-image-multilib-example: base on weston, and not sato
      dev-manual/common-tasks.rst: correct the documentation for debuginfod
      diffoscope: add native libraries to LD_LIBRARY_PATH
      Revert "oeqa: Set LD_LIBRARY_PATH when executing native commands"
      boost: correct upstream version check
      vte: use tarballs again
      gdk-pixbuf: update 2.40.0 -> 2.42.6
      glib-2.0: update 2.68.0 -> 2.68.1
      gnu-config: update to latest revision

Anatol Belski (1):
      cross-canadian: Whitelist "mingw32" as TARGET_OS

Anders Wallin (3):
      lttng-tools: Fix missing legacy test files
      lttng-tools: Fix path for test_python_looging
      scripts/contrib/image-manifest: add new script

Andreas Müller (1):
      xwayland: remove protocol.txt - it clashes with xserver-xorg

Anthony Bagwell (1):
      systemd: upgrade 247.4 -> 247.6

Anuj Mittal (2):
      Revert "qemu: fix CVE-2021-3392"
      qemu: fix CVE-2021-3392

Armin Kuster (6):
      binutils: rename BRANCH var
      libseccomp: move recipe from meta-security to core
      gnutls: Enable seccomp if FEATURE is set
      systemd: Enable seccomp if FEATURE is set
      qemu: Enable seccomp if FEATURE is set
      default-distrovars.inc: Add seccomp to DISTRO_FEATURES_DEFAULT

Bastian Krause (1):
      ccache: add packageconfig docs option

Bruce Ashfield (20):
      kern-tools: add dropped options to audit output
      linux-yocto/5.4: update to v5.4.109
      linux-yocto/5.10: update to v5.10.27
      linux-yocto/5.10: BSP configuration fixes
      linux-yocto/5.10: update to v5.10.29
      linux-yocto/5.4: update to v5.4.111
      linux-yocto/5.10: update to v5.10.30
      linux-yocto-rt/5.10: update to -rt34
      linux-yocto/5.4: update to v5.4.112
      linux-yocto/5.4: fix arm defconfig warnings
      linux-yocto/5.10: fix arm defconfig warnings
      linux-yocto/5.10: aufs fixes
      linux-yocto/5.10: qemuriscv32.cfg: RV32 only supports 1G physical memory
      linux-yocto/5.10: update to v5.10.32
      perf: fix python-audit RDEPENDS
      linux-yocto/5.4: update to v5.4.114
      linux-yocto/5.10: update to v5.10.34
      linux-yocto/5.4: update to v5.4.116
      linux-yocto/5.10: qemuppc32: reduce serial shutdown issues
      yocto-check-layer: Only note a layer without a conf/layer.conf (versus error)

Changqing Li (2):
      libpam: make volatile files created successfully
      gcr: fix one parallel build failure

Chen Qi (3):
      busybox: fix CVE-2021-28831
      weston: fix build failure due to race condition
      rsync: fix CVE-2020-14387

Christophe Chapuis (1):
      rootfs.py: find .ko.gz and .ko.xz kernel modules as well

Daniel Ammann (1):
      archiver: Fix typos

Devendra Tewari (2):
      bitbake: lib/bb: Add bb.utils.rename() helper function and use for renaming
      classes/lib/scripts: Use bb.utils.rename() instead of os.rename()

Diego Sueiro (3):
      oeqa/selftest/bblayers: Add test case for bitbake-layers layerindex-show-depends
      bitbake: layerindex: Fix bitbake-layers layerindex-show-depends command
      bitbake: layerindex: Add --fetchdir parameter to layerindex-fetch

Douglas Royds (2):
      Revert "externalsrc: Detect code changes in submodules"
      externalsrc: Detect code changes in submodules

Gavin Li (1):
      kmod: do not symlink config.guess/config.sub during autoreconf

Harald Brinkmann (1):
      bitbake: fetch/svn: Fix parsing revision of SVN repos with redirects

He Zhe (1):
      linux-yocto-dev: add features/scsi/scsi-debug.scc features/gpio/mockup.scc to KERNEL_FEATURES

Henning Schild (3):
      bitbake: fetch/git: add support for disabling shared clones on unpack
      bitbake: tests/fetch: deduplicate local git testing code
      bitbake: tests/fetch: add tests for local and remote "noshared" git fetching

Jon Mason (1):
      oeqa/runtime: space needed

Jonas Höppner (1):
      ltp: fix empty ltp-dev package

Jose Quaresma (4):
      gstreamer1.0: update patch upstream status
      ptest-runner: libgcc must be installed for pthread_cancel to work
      gstreamer1.0: rename patches
      gstreamer1.0: update ptest patch

Joshua Watt (2):
      bitbake: knotty: Re-enable command line logging levels
      classes/image: Use xargs to set file timestamps

Kai Kang (2):
      cmake.bbclass: remove ${B} before cmake_do_configure
      kernel-yocto.bbclass: chdir to ${WORKDIR} for do_kernel_checkout

Kevin Hao (3):
      modutils-initscripts: Bail out when no module is installed
      sysvinit-inittab/start_getty: Check /sys for the tty device existence
      Revert "inittab: Add getty launch on hvc0 for qemuppc64"

Khairul Rohaizzat Jamaluddin (1):
      qemu: Fix CVE-2020-35517

Khem Raj (54):
      gcc: Upgrade to 10.3.0 bug-fix release
      glibc: Rename glibc src package
      gcc-runtime: Make DEBUG_PREFIX_MAP relative to S
      valgrind: Delete trailing whitespaces
      valgrind: Add glibc-src to ptest rdeps
      valgrind: Add libstdc++ debug symbols for ptest
      vte: Upgrade to 0.64.0 release
      systemd: Fix build on mips/musl
      epiphany: Add missing dependency on gnutls
      cups: Turn gnutls into a packageconfig knob
      wpa-supplicant: Enable openssl
      curl: Use openssl backend
      libpsl: Add config knobs for runtime/builtin conversion choices
      glib-networking: Prefer openssl backend instead of gnutls
      gstreamer1.0-plugins-bad: Add packageconfigs for hls crypto backends
      ca-certificates: Fix openssl runtime cert dependencies
      weston: Drop loading xwayland.so module
      elfutils: Make 64bit time_t fix generic
      binutils: Fix linking failures when using dwarf-5
      go: Use dl.google.com for SRC_URI
      musl: Update to latest master
      llvm: Upgrade to LLVM 12 release
      python3-docutils: Upgrade to 0.17.1
      python3-markupsafe: Enable ptests
      python3-jinja2: Enable ptests
      python3-pyyaml: Add recipe
      apt: Fix build on musl when seccomp is enabled
      default-distrovars.inc: Remove seccomp for riscv32
      gcc-target: Create a LTO plugin symlink in bfd-plugins directory
      bitbake.conf: Use gcc-nm as default NM
      gcc-cross: Install linker LTO plugin for binutils tools
      gcc-cross-canadian: Install LTO linker plugin to BFD searchable location
      gnutls: Point to staging area for finding seccomp libs and includes
      libjpeg-turbo: Use --reproducible option for nasm
      libid3tag: Filter -ffile-prefix-map too
      openssl: Filter out -ffile-prefix-map as well
      ltp: Filter out -ffile-prefix-map
      gcc-runtime: Fix __FILE__ related reproducablity issues
      reproducible_build.bbclass: Enable -Wdate-time
      pkgconfig: Fix nativesdk builds for mingw sdk hosts
      m4: Do not use SIGSTKSZ
      bluez: Fix shadowing of pause function from libc
      valgrind: Disable leak_cpp_interior test
      findutils: Do not use SIGSTKSZ
      bash: Include files needed for run-heredoc ptest
      libpam: Provide needed env for tst-pam_start_confdir ptest
      cml1.bbclass: Return sorted list of cfg files
      busybox: Enable long options for enabled applets
      webkitgtk: Fix reproducibility in minibrowser
      webkitgtk: Update patch status
      libgcc-initial: Do not build fp128 to decimal ppc functions
      gcc: Upgrade to GCC 11
      busybox: Fix reproducibility
      strace: Upgrade to 5.12

Konrad Weihmann (2):
      cpan-base: set default UPSTREAM_CHECK_REGEX
      cve-update-db-native: skip on empty cpe23Uri

Marek Vasut (1):
      linux-firmware: Package RSI 911x WiFi firmware

Martin Jansa (2):
      xwayland: add opengl to REQUIRED_DISTRO_FEATURES
      ofono: prevent using bundled ell headers and fix build with ell-0.39

Michael Halstead (1):
      releases: update to include 3.3

Michael Opdenacker (7):
      dev-manual: fix code insertion
      manuals: simplify code insertion
      manuals: code insertion simplification over two lines
      bitbake: doc: bitbake-user-manual: simplify colon usage
      bitbake: doc: bitbake-user-manual: code insertion simplification over two lines
      dev-manual: update references to Docker installation instructions
      sanity.bbclass: mention CONNECTIVITY_CHECK_URIS in network failure message

Mikko Rapeli (4):
      bitbake: bitbake: tests/fetch: fix test execution without .gitconfig
      bitbake: bitbake: tests/fetch: remove write protected files too
      lz4: use CFLAGS from bitbake
      unzip: use optimization from bitbake

Mingli Yu (6):
      libxshmfence: Build fixes for riscv32
      packagegroup-core-tools-profile: Remove valgrind for riscv32
      packagegroup-core-tools-testapps.bb: Remove kexec for riscv32
      libtool: make sure autoheader run before automake
      groff: not ship /usr/bin/grap2graph
      rpm: Upgrade to 4.16.1.3

Minjae Kim (1):
      qemu: fix CVE-2021-3392

Nicolas Dechesne (1):
      bitbake: doc: bitbake-user-manual: fix typo left over from Sphinx migration

Niels Avonds (1):
      bitbake: fetch/gitsm: Fix crash when using git LFS and submodules

Oleksandr Kravchuk (2):
      python3-setuptools: update to 56.0.0
      autoconf-archive: update to 2021.02.19

Otavio Salvador (2):
      gstreamer1.0-plugins-base: Add 'viv-fb' OpenGL Window System option
      gstreamer1.0-plugins-base: Use bb.utils.filter to reduce code

Paul Barker (10):
      bitbake: hashserv: Use generic ConnectionError
      bitbake: asyncrpc: Common implementation of RPC using json & asyncio
      bitbake: hashserv: Refactor to use asyncrpc
      bitbake: prserv: Drop obsolete python version check
      bitbake: prserv: Drop unused dump_db method
      bitbake: prserv: Add connect function
      prservice: Use new connect API
      bitbake: prserv: Use multiprocessing to auto start prserver
      bitbake: prserv: Extract daemonization from PRServer class
      bitbake: prserv: Handle requests in main thread

Paulo Cesar Zaneti (1):
      perl: fix startperl configuration option for perl-native

Peter Budny (1):
      lib/oe/terminal: Fix tmux new-session on older tmux versions (<1.9)

Petr Vorel (1):
      ltp: Replace musl patches with do_patch[postfuncs]

Przemyslaw Gorszkowski (2):
      bitbake: progress: LineFilterProgressHandler - Handle parsing line which ends with CR only
      bitbake: fetch/s3: Add progress handler for S3 cp command

Randy MacLeod (2):
      sqlite3: upgrade 3.35.0 -> 3.35.3
      oe-time-dd-test.sh: increase timeout to 15 sec

Reto Schneider (2):
      license_image.bbclass: Detect broken symlinks
      license_image.bbclass: Fix symlink to generic license files

Richard Purdie (32):
      oeqa/selftest: Hardcode test assumptions about heartbeat event timings
      pseudo: Upgrade to add trailing slashes ignore path fix
      oeqa/selftest: Ensure packages classes are set correctly for maintainers test
      layer.conf: Update to add post 3.3 release honister series
      sanity: Add error check for '%' in build path
      bitbake: runqueue: Fix deferred task issues
      bitbake: tinfoil/data_smart: Allow variable history emit() to function remotely
      sanity: Further improve directory sanity tests
      bitbake: bitbake-server: Remove now unneeded code
      bitbake: doc/user-manual-fetching: Remove basepath unpack parameter docs
      poky.conf: Post release version bump
      runqemu: Ensure we cleanup snapshot files after image run
      patchelf: Backport fix from upstream for note section overlap error
      pyyaml: Add missing HOMEPAGE
      yocto-check-layer: Avoid bug when iterating and autoadding dependencies
      libseccomp: Add MAINTAINERS entry and HOMEPAGE
      libseccomp: Fix reproducibility issue
      apt: Disable libseccomp
      libxcrypt: Update to 4.4.19 release and fix symbol version issues
      patchelf: Fix note section alignment issues
      bitbake: runqueue: Fix multiconfig deferred task sstate validity caching issue
      bitbake: runqueue: Handle deferred task rehashing in multiconfig builds
      patchelf: Fix alignment patch
      pybootchart/draw: Avoid divide by zero error
      yocto-uninative: Update to 3.1 which includes a patchelf fix
      Revert "perl: fix startperl configuration option for perl-native"
      bitbake: bin/bitbake-getvar: Add a new command to query a variable value (with history)
      bitbake: bitbake: Switch to post release version number 1.51.0
      sanity.conf: Require bitbake 1.51.0
      oeqa/qemurunner: Improve logging thread exit handling for qemu shutdown test
      oeqa/qemurunner: Handle path length issues for qmp socket
      lib/package_manager: Use shutil.copy instead of bb.utils.copyfile for intercepts

Robert Joslyn (3):
      btrfs-tools: Update to 5.11.1
      btrfs-tools: Add PACKAGECONFIG options
      btrfs-tools: Try to follow style guide

Robert P. J. Day (3):
      sdk-manual: "beablebone" -> "beaglebone"
      sdk-manual: fix broken formatting of sample command
      bitbake.conf: sort MIRROR list, add missing SAMBA_MIRROR

Ross Burton (4):
      glslang: strip whitespace in pkgconfig file
      insane: clean up some more warning messages
      bitbake: bitbake-server: ensure server timeout is a float
      oe-buildenv-internal: add BitBake's library to PYTHONPATH

Sakib Sajal (12):
      oe-time-dd-test.sh: make executable
      oe-time-dd-test.sh: provide more information from "top"
      qemu: fix CVE-2021-20181
      qemu: fix CVE-2020-29443
      qemu: fix CVE-2021-20221
      qemu: fix CVE-2021-3409
      qemu: fix CVE-2021-3416
      qemu: fix CVE-2021-20257
      oe-time-dd-test.sh: collect cooker log when timeout is exceeded
      buildstats.bbclass: collect data in the same file.
      qemu: fix CVE-2020-27821
      qemu: fix CVE-2021-20263

Samuli Piippo (1):
      assimp: BBCLASSEXTEND to native and nativesdk

Saul Wold (4):
      pango: re-enable ptest
      qemu-system-native: install qmp python module
      qemurunner: Add support for qmp commands
      qemurunner: change warning to info

Stefan Ghinea (3):
      wpa-supplicant: fix CVE-2021-30004
      libssh2: fix build failure with option no-ecdsa
      xserver-xorg: fix CVE-2021-3472

Stefano Babic (1):
      libubootenv: upgrade 0.3.1 -> 0.3.2

Teoh Jay Shen (6):
      oeqa/manual/bsp-hw.json : remove boot_from_runlevel_3 and boot_from_runlevel_5 manual test
      oeqa/manual/bsp-hw.json : remove ethernet_static_ip_set_in_connman and ethernet_get_IP_in_connman_via_DHCP manual test
      oeqa/manual/bsp-hw.json : remove standby and Test_if_LAN_device_works_well_after_resume_from_suspend_state manual test
      oeqa/manual/bsp-hw.json : remove click_terminal_icon_on_X_desktop manual test
      oeqa/manual/bsp-hw.json :remove Check_if_RTC_(Real_Time_Clock)_can_work_correctly manual test
      oeqa/manual/bsp-hw.json : remove Test_if_usb_hid_device_works_well_after_resume_from_suspend_state manual test

Trevor Gamblin (2):
      nettle: upgrade 3.7.1 -> 3.7.2
      ref-manual/variables.rst: Add incompatibility warning for SERIAL_CONSOLES_CHECK

Ulrich Ölmann (1):
      arch-armv6m.inc: fix access rights

Vinay Kumar (1):
      binutils: Fix CVE-2021-20197

Vineela Tummalapalli (1):
      Adding dunfell 3.1.7 to the switcher and release list.

Wang Mingyu (6):
      at-spi2-core: upgrade 2.38.0 -> 2.40.0
      babeltrace2: upgrade 2.0.3 -> 2.0.4
      boost-build-native: upgrade 4.3.0 -> 4.4.1
      libassuan: upgrade 2.5.4 -> 2.5.5
      webkitgtk: upgrade 2.30.5 -> 2.30.6
      vte: upgrade 0.62.2 -> 0.62.3

Wes Lindauer (1):
      oeqa/runtime/cases: Only disable/enable for current boot

Yanfei Xu (1):
      parselogs: ignore floppy error on qemu-system-x86 at boot stage

Yi Fan Yu (7):
      valgrind: update 3.16.1 -> 3.17.0
      valgrind: Disable ptest swapcontext.vgtest
      valgrind: Fix ptest swapcontext.vgtest
      Revert "glib-2.0: add workaround to fix codegen.py.test failing"
      re2c: Upgrade 2.0.3 -> 2.1.1
      valgrind: Enable drd/tests/bar_bad* ptest
      libevent: Increase ptest timing tolerance 50 ms -> 100 ms

Zqiang (1):
      rt-tests: Update rt-tests

hongxu (1):
      deb: apply postinstall on sdk

wangmy (34):
      ell: upgrade 0.38 -> 0.39
      dbus-glib: upgrade 0.110 -> 0.112
      ccache: upgrade 4.2 -> 4.2.1
      gcr: upgrade 3.38.1 -> 3.40.0
      ghostscript: upgrade 9.53.3 -> 9.54.0
      libsolv: upgrade 0.7.17 -> 0.7.18
      glib-2.0: upgrade 2.66.7 -> 2.68.0
      file: upgrade 5.39 -> 5.40
      curl: upgrade 7.75.0 -> 7.76.0
      acpica: upgrade 20210105 -> 20210331
      help2man: upgrade 1.48.2 -> 1.48.3
      libportal: upgrade 0.3 -> 0.4
      libksba: upgrade 1.5.0 -> 1.5.1
      go: upgrade 1.16.2 -> 1.16.3
      libcap: upgrade 2.48 -> 2.49
      libcomps: upgrade 0.1.15 -> 0.1.16
      icu: upgrade 68.2 -> 69.1
      mpg123: upgrade 1.26.4 -> 1.26.5
      man-pages: upgrade 5.10 -> 5.11
      go: update SRC_URI to use https protocol
      mesa: upgrade 21.0.1 -> 21.0.2
      openssh: upgrade 8.5p1 -> 8.6p1
      mtools: upgrade 4.0.26 -> 4.0.27
      python3-cython: upgrade 0.29.22 -> 0.29.23
      tiff: upgrade 4.2.0 -> 4.3.0
      boost: upgrade 1.75.0 -> 1.76.0
      wpebackend-fdo: upgrade 1.8.2 -> 1.8.3
      mesa: upgrade 21.0.2 -> 21.0.3
      gdb: upgrade 10.1 -> 10.2
      glib-networking: upgrade 2.66.0 -> 2.68.1
      glslang: upgrade 11.2.0 -> 11.4.0
      hdparm: upgrade 9.60 -> 9.61
      libhandy: upgrade 1.2.1 -> 1.2.2
      libjitterentropy: upgrade 3.0.1 -> 3.0.2

zangrc (1):
      maintainers.inc: Modify email address

zhengruoqin (19):
      epiphany: upgrade 3.38.2 -> 3.38.3
      wpebackend-fdo: upgrade 1.8.0 -> 1.8.2
      netbase: upgrade 6.2 -> 6.3
      python3-dbusmock: upgrade 0.22.0 -> 0.23.0
      python3-gitdb: upgrade 4.0.5 -> 4.0.7
      libva: upgrade 2.10.0 -> 2.11.0
      ruby: upgrade 3.0.0 -> 3.0.1
      libva-utils: upgrade 2.10.0 -> 2.11.1
      libdazzle: upgrade 3.38.0 -> 3.40.0
      librepo: upgrade 1.13.0 -> 1.14.0
      libdrm: upgrade 2.4.104 -> 2.4.105
      python3-pygobject: upgrade 3.38.0 -> 3.40.1
      libedit: upgrade 20210216-3.1 -> 20210419-3.1
      libhandy: upgrade 1.2.0 -> 1.2.1
      libical: upgrade 3.0.9 -> 3.0.10
      libsolv: upgrade 0.7.18 -> 0.7.19
      libmicrohttpd: upgrade 0.9.72 -> 0.9.73
      python3-numpy: upgrade 1.20.1 -> 1.20.2
      wireless-regdb: upgrade 2020.11.20 -> 2021.04.21

Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: Ibdaea694cae40b0749d472bf08b53002a45b31d7

5 files changed, 73 insertions, 139 deletions

diff --git a/poky/documentation/sdk-manual/appendix-customizing.rst b/poky/documentation/sdk-manual/appendix-customizing.rst
index 8e7115046..fb2d78452 100644
--- a/poky/documentation/sdk-manual/appendix-customizing.rst
+++ b/poky/documentation/sdk-manual/appendix-customizing.rst
@@ -149,8 +149,7 @@ from the :term:`DISTRO` variable.
 The
 :ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
 class defines the default value of the ``SDK_TITLE`` variable as
-follows:
-::
+follows::
 
    SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK"
 
@@ -162,8 +161,7 @@ an example, assume you have your own layer for your distribution named
 does the default "poky" distribution. If so, you could update the
 ``SDK_TITLE`` variable in the
 ``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following
-form:
-::
+form::
 
    SDK_TITLE = "your_title"
 
@@ -194,8 +192,7 @@ the installed SDKs to update the installed SDKs by using the
 3. Build the extensible SDK normally (i.e., use the
    ``bitbake -c populate_sdk_ext`` imagename command).
 
-4. Publish the SDK using the following command:
-   ::
+4. Publish the SDK using the following command::
 
       $ oe-publish-sdk some_path/sdk-installer.sh path_to_shared_http_directory
 
@@ -218,8 +215,7 @@ installation directory for the SDK is based on the
 :term:`SDKEXTPATH` variables from
 within the
 :ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
-class as follows:
-::
+class as follows::
 
    SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk"
 
@@ -236,8 +232,7 @@ assume you have your own layer for your distribution named
 does the default "poky" distribution. If so, you could update the
 ``SDKEXTPATH`` variable in the
 ``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following
-form:
-::
+form::
 
    SDKEXTPATH = "some_path_for_your_installed_sdk"
 
@@ -272,8 +267,7 @@ source, you need to do a number of things:
 
 3. Set the appropriate configuration so that the produced SDK knows how
    to find the configuration. The variable you need to set is
-   :term:`SSTATE_MIRRORS`:
-   ::
+   :term:`SSTATE_MIRRORS`::
 
       SSTATE_MIRRORS = "file://.* http://example.com/some_path/sstate-cache/PATH"
 
@@ -287,8 +281,7 @@ source, you need to do a number of things:
       side, and its contents will not interfere with the build), then
       you can set the variable in your ``local.conf`` or custom distro
       configuration file. You can then "whitelist" the variable through
-      to the SDK by adding the following:
-      ::
+      to the SDK by adding the following::
 
          SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"
 
@@ -313,8 +306,7 @@ everything needed to reconstruct the image for which the SDK was built.
 This bundling can lead to an SDK installer file that is a Gigabyte or
 more in size. If the size of this file causes a problem, you can build
 an SDK that has just enough in it to install and provide access to the
-``devtool command`` by setting the following in your configuration:
-::
+``devtool command`` by setting the following in your configuration::
 
    SDK_EXT_TYPE = "minimal"
 
@@ -336,8 +328,7 @@ information enables the ``devtool search`` command to return useful
 results.
 
 To facilitate this wider range of information, you would need to set the
-following:
-::
+following::
 
    SDK_INCLUDE_PKGDATA = "1"
 
diff --git a/poky/documentation/sdk-manual/appendix-obtain.rst b/poky/documentation/sdk-manual/appendix-obtain.rst
index 3c1dc52d1..fc6b8b9d5 100644
--- a/poky/documentation/sdk-manual/appendix-obtain.rst
+++ b/poky/documentation/sdk-manual/appendix-obtain.rst
@@ -25,8 +25,7 @@ Follow these steps to locate and hand-install the toolchain:
    download the installer appropriate for your build host, target
    hardware, and image type.
 
-   The installer files (``*.sh``) follow this naming convention:
-   ::
+   The installer files (``*.sh``) follow this naming convention::
 
       poky-glibc-host_system-core-image-type-arch-toolchain[-ext]-release.sh
 
@@ -55,15 +54,13 @@ Follow these steps to locate and hand-install the toolchain:
 
    For example, if your build host is a 64-bit x86 system and you need
    an extended SDK for a 64-bit core2 target, go into the ``x86_64``
-   folder and download the following installer:
-   ::
+   folder and download the following installer::
 
       poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
 
 4. *Run the Installer:* Be sure you have execution privileges and run
    the installer. Following is an example from the ``Downloads``
-   directory:
-   ::
+   directory::
 
       $ ~/Downloads/poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
 
@@ -132,8 +129,7 @@ build the SDK installer. Follow these steps:
       using to build the installer. If
       SDKMACHINE
       is not set appropriately, the build fails and provides an error
-      message similar to the following:
-      ::
+      message similar to the following::
 
               The extensible SDK can currently only be built for the same architecture as the machine being built on - SDK_ARCH is
               set to i686 (likely via setting SDKMACHINE) which is different from the architecture of the build machine (x86_64).
@@ -142,10 +138,11 @@ build the SDK installer. Follow these steps:
 
 6. *Build the SDK Installer:* To build the SDK installer for a standard
    SDK and populate the SDK image, use the following command form. Be
-   sure to replace image with an image (e.g. "core-image-sato"): $
-   bitbake image -c populate_sdk You can do the same for the extensible
-   SDK using this command form:
-   ::
+   sure to replace ``image`` with an image (e.g. "core-image-sato")::
+
+      $ bitbake image -c populate_sdk
+
+   You can do the same for the extensible SDK using this command form::
 
       $ bitbake image -c populate_sdk_ext
 
@@ -170,8 +167,7 @@ build the SDK installer. Follow these steps:
          libc-staticdev"
 
 7. *Run the Installer:* You can now run the SDK installer from
-   ``tmp/deploy/sdk`` in the Build Directory. Following is an example:
-   ::
+   ``tmp/deploy/sdk`` in the Build Directory. Following is an example::
 
       $ cd poky/build/tmp/deploy/sdk
       $ ./poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
@@ -211,8 +207,7 @@ Follow these steps to extract the root filesystem:
    which you can use with QEMU directly.
 
    The pre-built root filesystem image files follow these naming
-   conventions:
-   ::
+   conventions::
 
       core-image-profile-arch.tar.bz2
 
@@ -233,8 +228,7 @@ Follow these steps to extract the root filesystem:
 
    For example, if you plan on using a BeagleBone device as your target
    hardware and your image is a ``core-image-sato-sdk`` image, you can
-   download the following file:
-   ::
+   download the following file::
 
       core-image-sato-sdk-beaglebone-yocto.tar.bz2
 
@@ -246,8 +240,7 @@ Follow these steps to extract the root filesystem:
    installed the toolchain (e.g. ``poky_sdk``).
 
    Following is an example based on the toolchain installed in the
-   ":ref:`sdk-manual/appendix-obtain:locating pre-built sdk installers`" section:
-   ::
+   ":ref:`sdk-manual/appendix-obtain:locating pre-built sdk installers`" section::
 
       $ source poky_sdk/environment-setup-core2-64-poky-linux
 
@@ -258,12 +251,11 @@ Follow these steps to extract the root filesystem:
    from a previously built root filesystem image that was downloaded
    from the :yocto_dl:`Index of Releases </releases/yocto/yocto-&DISTRO;/machines/>`.
    This command extracts the root filesystem into the ``core2-64-sato``
-   directory:
-   ::
+   directory::
 
       $ runqemu-extract-sdk ~/Downloads/core-image-sato-sdk-beaglebone-yocto.tar.bz2 ~/beaglebone-sato
 
-   You could now point to the target sysroot at ``beablebone-sato``.
+   You could now point to the target sysroot at ``beaglebone-sato``.
 
 Installed Standard SDK Directory Structure
 ==========================================
diff --git a/poky/documentation/sdk-manual/extensible.rst b/poky/documentation/sdk-manual/extensible.rst
index baa432ef3..04bafaed9 100644
--- a/poky/documentation/sdk-manual/extensible.rst
+++ b/poky/documentation/sdk-manual/extensible.rst
@@ -59,8 +59,7 @@ 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.
 An extensible SDK has the string "-ext" as part of the name. Following
-is the general form:
-::
+is the general form::
 
    poky-glibc-host_system-image_type-arch-toolchain-ext-release_version.sh
 
@@ -83,8 +82,7 @@ is the general form:
 
 For example, the following SDK installer is for a 64-bit
 development host system and a i586-tuned target architecture based off
-the SDK for ``core-image-sato`` and using the current &DISTRO; snapshot:
-::
+the SDK for ``core-image-sato`` and using the current &DISTRO; snapshot::
 
    poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-&DISTRO;.sh
 
@@ -150,8 +148,7 @@ begin with the string "``environment-setup``" and include as part of
 their name the tuned target architecture. As an example, the following
 commands set the working directory to where the SDK was installed and
 then source the environment setup script. In this example, the setup
-script is for an IA-based target machine using i586 tuning:
-::
+script is for an IA-based target machine using i586 tuning::
 
    $ cd /home/scottrif/poky_sdk
    $ source environment-setup-core2-64-poky-linux
@@ -258,8 +255,7 @@ command:
       to be extracted. In this situation, the source code is extracted
       to the default workspace - you do not want the files in some
       specific location outside of the workspace. Thus, everything you
-      need will be located in the workspace:
-      ::
+      need will be located in the workspace::
 
          $ devtool add recipe fetchuri
 
@@ -283,8 +279,7 @@ command:
       Furthermore, the first positional argument srctree in this case
       identifies where the ``devtool add`` command will locate the
       extracted code outside of the workspace. You need to specify an
-      empty directory:
-      ::
+      empty directory::
 
          $ devtool add recipe srctree fetchuri
 
@@ -300,8 +295,7 @@ command:
       ``devtool`` workspace.
 
       The following command provides a new recipe name and identifies
-      the existing source tree location:
-      ::
+      the existing source tree location::
 
          $ devtool add recipe srctree
 
@@ -317,8 +311,7 @@ command:
 
 2. *Edit the Recipe*: You can use ``devtool edit-recipe`` to open up the
    editor as defined by the ``$EDITOR`` environment variable and modify
-   the file:
-   ::
+   the file::
 
       $ devtool edit-recipe recipe
 
@@ -338,8 +331,7 @@ command:
    On the other hand, if you want an image to contain the recipe's
    packages from the workspace for immediate deployment onto a device
    (e.g. for testing purposes), you can use the ``devtool build-image``
-   command:
-   ::
+   command::
 
       $ devtool build-image image
 
@@ -435,8 +427,7 @@ command:
       outside the workspace (i.e. ``meta-``\ layername).
 
       The following command identifies the recipe and, by default,
-      extracts the source files:
-      ::
+      extracts the source files::
 
          $ devtool modify recipe
 
@@ -474,8 +465,7 @@ command:
       The following command tells ``devtool`` the recipe with which to
       work and, in this case, identifies a local area for the extracted
       source files that exists outside of the default ``devtool``
-      workspace:
-      ::
+      workspace::
 
          $ devtool modify recipe srctree
 
@@ -508,8 +498,7 @@ command:
       The following command tells ``devtool`` the recipe with which to
       work, uses the "-n" option to indicate source does not need to be
       extracted, and uses srctree to point to the previously extracted
-      source files:
-      ::
+      source files::
 
          $ devtool modify -n recipe srctree
 
@@ -532,8 +521,7 @@ command:
    depends on what you are going to do with the new code.
 
    If you need to eventually move the build output to the target
-   hardware, use the following ``devtool`` command:
-   ::
+   hardware, use the following ``devtool`` command::
 
       $ devtool build recipe
 
@@ -556,8 +544,7 @@ command:
       development machine.
 
    You can deploy your build output to that target hardware by using the
-   ``devtool deploy-target`` command:
-   ::
+   ``devtool deploy-target`` command::
 
       $ devtool deploy-target recipe target
 
@@ -651,8 +638,7 @@ The following diagram shows the common development flow used with the
    A common situation is where third-party software has undergone a
    revision so that it has been upgraded. The recipe you have access to
    is likely in your own layer. Thus, you need to upgrade the recipe to
-   use the newer version of the software:
-   ::
+   use the newer version of the software::
 
       $ devtool upgrade -V version recipe
 
@@ -703,16 +689,14 @@ The following diagram shows the common development flow used with the
    depends on what you are going to do with the new code.
 
    If you need to eventually move the build output to the target
-   hardware, use the following ``devtool`` command:
-   ::
+   hardware, use the following ``devtool`` command::
 
       $ devtool build recipe
 
    On the other hand, if you want an image to contain the recipe's
    packages from the workspace for immediate deployment onto a device
    (e.g. for testing purposes), you can use the ``devtool build-image``
-   command:
-   ::
+   command::
 
       $ devtool build-image image
 
@@ -828,8 +812,7 @@ name and version, just the name, or just the version as part of the
 command line.
 
 Sometimes the name or version determined from the source tree might be
-incorrect. For such a case, you must reset the recipe:
-::
+incorrect. For such a case, you must reset the recipe::
 
    $ devtool reset -n recipename
 
@@ -853,8 +836,7 @@ the ``DEPENDS`` variable in the original recipe to include the new
 recipe.
 
 If you need to add runtime dependencies, you can do so by adding the
-following to your recipe:
-::
+following to your recipe::
 
    RDEPENDS_${PN} += "dependency1 dependency2 ..."
 
@@ -938,8 +920,7 @@ mind:
    the command line, add the variable setting to
    :term:`EXTRA_OEMAKE` or
    :term:`PACKAGECONFIG_CONFARGS`
-   within the recipe. Here is an example using ``EXTRA_OEMAKE``:
-   ::
+   within the recipe. Here is an example using ``EXTRA_OEMAKE``::
 
       EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'"
 
@@ -993,8 +974,7 @@ You can use the ``devtool add`` command two different ways to add
 Node.js modules: 1) Through ``npm`` and, 2) from a repository or local
 source.
 
-Use the following form to add Node.js modules through ``npm``:
-::
+Use the following form to add Node.js modules through ``npm``::
 
    $ devtool add "npm://registry.npmjs.org;name=forever;version=0.15.1"
 
@@ -1018,8 +998,7 @@ these behaviors ensure the reproducibility and integrity of the build.
 
 As mentioned earlier, you can also add Node.js modules directly from a
 repository or local source tree. To add modules this way, use
-``devtool add`` in the following form:
-::
+``devtool add`` in the following form::
 
    $ devtool add https://github.com/diversario/node-ssdp
 
@@ -1196,15 +1175,13 @@ need to restore the original files that existed prior to running the
 ``devtool deploy-target`` command. Because the ``devtool deploy-target``
 command backs up any files it overwrites, you can use the
 ``devtool undeploy-target`` command to restore those files and remove
-any other files the recipe deployed. Consider the following example:
-::
+any other files the recipe deployed. Consider the following example::
 
    $ devtool undeploy-target lighttpd root@192.168.7.2
 
 If you have deployed
 multiple applications, you can remove them all using the "-a" option
-thus restoring the target device to its original state:
-::
+thus restoring the target device to its original state::
 
    $ devtool undeploy-target -a root@192.168.7.2
 
@@ -1235,22 +1212,19 @@ populated on-demand. Sometimes you must explicitly install extra items
 into the SDK. If you need these extra items, you can first search for
 the items using the ``devtool search`` command. For example, suppose you
 need to link to libGL but you are not sure which recipe provides libGL.
-You can use the following command to find out:
-::
+You can use the following command to find out::
 
    $ devtool search libGL mesa
 
 A free implementation of the OpenGL API Once you know the recipe
-(i.e. ``mesa`` in this example), you can install it:
-::
+(i.e. ``mesa`` in this example), you can install it::
 
    $ devtool sdk-install mesa
 
 By default, the ``devtool sdk-install`` command assumes
 the item is available in pre-built form from your SDK provider. If the
 item is not available and it is acceptable to build the item from
-source, you can add the "-s" option as follows:
-::
+source, you can add the "-s" option as follows::
 
    $ devtool sdk-install -s mesa
 
@@ -1266,8 +1240,7 @@ If you are working with an installed extensible SDK that gets
 occasionally updated (e.g. a third-party SDK), then you will need to
 manually "pull down" the updates into the installed SDK.
 
-To update your installed SDK, use ``devtool`` as follows:
-::
+To update your installed SDK, use ``devtool`` as follows::
 
    $ devtool sdk-update
 
diff --git a/poky/documentation/sdk-manual/using.rst b/poky/documentation/sdk-manual/using.rst
index 62967f557..fa0e8d409 100644
--- a/poky/documentation/sdk-manual/using.rst
+++ b/poky/documentation/sdk-manual/using.rst
@@ -77,8 +77,7 @@ immediately followed by a string representing the target architecture.
 
 For example, the following SDK installer is for a 64-bit
 development host system and a i586-tuned target architecture based off
-the SDK for ``core-image-sato`` and using the current DISTRO snapshot:
-::
+the SDK for ``core-image-sato`` and using the current DISTRO snapshot::
 
    poky-glibc-x86_64-core-image-sato-i586-toolchain-DISTRO.sh
 
@@ -141,8 +140,7 @@ begin with the string "``environment-setup``" and include as part of
 their name the tuned target architecture. As an example, the following
 commands set the working directory to where the SDK was installed and
 then source the environment setup script. In this example, the setup
-script is for an IA-based target machine using i586 tuning:
-::
+script is for an IA-based target machine using i586 tuning::
 
    $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
 
diff --git a/poky/documentation/sdk-manual/working-projects.rst b/poky/documentation/sdk-manual/working-projects.rst
index f880cbe0d..ad84ce2b8 100644
--- a/poky/documentation/sdk-manual/working-projects.rst
+++ b/poky/documentation/sdk-manual/working-projects.rst
@@ -45,16 +45,14 @@ project:
    respectively.
 
    Use the following command to create an empty README file, which is
-   required by GNU Coding Standards:
-   ::
+   required by GNU Coding Standards::
 
       $ touch README
 
    Create the remaining
    three files as follows:
 
-   -  ``hello.c``:
-      ::
+   -  ``hello.c``::
 
          #include <stdio.h>
 
@@ -63,8 +61,7 @@ project:
                  printf("Hello World!\n");
              }
 
-   -  ``configure.ac``:
-      ::
+   -  ``configure.ac``::
 
          AC_INIT(hello,0.1)
          AM_INIT_AUTOMAKE([foreign])
@@ -72,8 +69,7 @@ project:
          AC_CONFIG_FILES(Makefile)
          AC_OUTPUT
 
-   -  ``Makefile.am``:
-      ::
+   -  ``Makefile.am``::
 
          bin_PROGRAMS = hello
          hello_SOURCES = hello.c
@@ -87,8 +83,7 @@ project:
    which is followed by the string "poky-linux". For this example, the
    command sources a script from the default SDK installation directory
    that uses the 32-bit Intel x86 Architecture and the &DISTRO; Yocto
-   Project release:
-   ::
+   Project release::
 
       $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
 
@@ -113,8 +108,7 @@ project:
    the cross-compiler. The
    :term:`CONFIGURE_FLAGS`
    environment variable provides the minimal arguments for GNU
-   configure:
-   ::
+   configure::
 
       $ ./configure ${CONFIGURE_FLAGS}
 
@@ -127,14 +121,12 @@ project:
    ``armv5te-poky-linux-gnueabi``. You will notice that the name of the
    script is ``environment-setup-armv5te-poky-linux-gnueabi``. Thus, the
    following command works to update your project and rebuild it using
-   the appropriate cross-toolchain tools:
-   ::
+   the appropriate cross-toolchain tools::
 
      $ ./configure --host=armv5te-poky-linux-gnueabi --with-libtool-sysroot=sysroot_dir
 
 5. *Make and Install the Project:* These two commands generate and
-   install the project into the destination directory:
-   ::
+   install the project into the destination directory::
 
       $ make
       $ make install DESTDIR=./tmp
@@ -157,8 +149,7 @@ project:
 
 6. *Execute Your Project:* To execute the project, you would need to run
    it on your target hardware. If your target hardware happens to be
-   your build host, you could run the project as follows:
-   ::
+   your build host, you could run the project as follows::
 
       $ ./tmp/usr/local/bin/hello
 
@@ -203,8 +194,7 @@ regarding variable behavior:
 .. note::
 
    Regardless of how you set your variables, if you use the "-e" option
-   with ``make``, the variables from the SDK setup script take precedence:
-   ::
+   with ``make``, the variables from the SDK setup script take precedence::
 
       $ make -e target
 
@@ -226,8 +216,7 @@ Running the
 SDK setup script for a 64-bit build host and an i586-tuned target
 architecture for a ``core-image-sato`` image using the current &DISTRO;
 Yocto Project release and then echoing that variable shows the value
-established through the script:
-::
+established through the script::
 
    $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
    $ echo ${CC}
@@ -252,8 +241,7 @@ example:
 
    Create the three files as follows:
 
-   -  ``main.c``:
-      ::
+   -  ``main.c``::
 
          #include "module.h"
          void sample_func();
@@ -263,14 +251,12 @@ example:
              return 0;
          }
 
-   -  ``module.h``:
-      ::
+   -  ``module.h``::
 
          #include <stdio.h>
          void sample_func();
 
-   -  ``module.c``:
-      ::
+   -  ``module.c``::
 
          #include "module.h"
          void sample_func()
@@ -288,8 +274,7 @@ example:
    which is followed by the string "poky-linux". For this example, the
    command sources a script from the default SDK installation directory
    that uses the 32-bit Intel x86 Architecture and the &DISTRO_NAME; Yocto
-   Project release:
-   ::
+   Project release::
 
       $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
 
@@ -297,8 +282,7 @@ example:
    two lines that can be used to set the ``CC`` variable. One line is
    identical to the value that is set when you run the SDK environment
    setup script, and the other line sets ``CC`` to "gcc", the default
-   GNU compiler on the build host:
-   ::
+   GNU compiler on the build host::
 
       # CC=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux
       # CC="gcc"
@@ -315,8 +299,7 @@ example:
 4. *Make the Project:* Use the ``make`` command to create the binary
    output file. Because variables are commented out in the Makefile, the
    value used for ``CC`` is the value set when the SDK environment setup
-   file was run:
-   ::
+   file was run::
 
       $ make
       i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c main.c
@@ -351,8 +334,7 @@ example:
    variable as part of the command line. Go into the Makefile and
    re-insert the comment character so that running ``make`` uses the
    established SDK compiler. However, when you run ``make``, use a
-   command-line argument to set ``CC`` to "gcc":
-   ::
+   command-line argument to set ``CC`` to "gcc"::
 
       $ make clean
       rm -rf *.o
@@ -376,8 +358,7 @@ example:
    environment variable.
 
    In this last case, edit Makefile again to use the "gcc" compiler but
-   then use the "-e" option on the ``make`` command line:
-   ::
+   then use the "-e" option on the ``make`` command line::
 
       $ make clean
       rm -rf *.o
@@ -402,8 +383,7 @@ example:
    Makefile.
 
 5. *Execute Your Project:* To execute the project (i.e. ``target_bin``),
-   use the following command:
-   ::
+   use the following command::
 
       $ ./target_bin
       Hello World!