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