The poky repository master branch is no longer being updated.

You can either:

a) switch to individual clones of bitbake, openembedded-core, meta-yocto and yocto-docs

b) use the new bitbake-setup

You can find information about either approach in our documentation:
https://docs.yoctoproject.org/

Note that "poky" the distro setting is still available in meta-yocto as
before and we continue to use and maintain that.

Long live Poky!

Some further information on the background of this change can be found
in: https://lists.openembedded.org/g/openembedded-architecture/message/2179

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

1 files changed, 0 insertions, 73 deletions

diff --git a/documentation/dev-manual/temporary-source-code.rst b/documentation/dev-manual/temporary-source-code.rst
deleted file mode 100644
index 9a7cd0f771..0000000000
--- a/documentation/dev-manual/temporary-source-code.rst
+++ /dev/null
@@ -1,73 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-Finding Temporary Source Code
-*****************************
-
-You might find it helpful during development to modify the temporary
-source code used by recipes to build packages. For example, suppose you
-are developing a patch and you need to experiment a bit to figure out
-your solution. After you have initially built the package, you can
-iteratively tweak the source code, which is located in the
-:term:`Build Directory`, and then you can force a re-compile and quickly
-test your altered code. Once you settle on a solution, you can then preserve
-your changes in the form of patches.
-
-During a build, the unpacked temporary source code used by recipes to
-build packages is available in the :term:`Build Directory` as defined by the
-:term:`S` variable. Below is the default value for the :term:`S` variable as
-defined in the ``meta/conf/bitbake.conf`` configuration file in the
-:term:`Source Directory`::
-
-   S = "${UNPACKDIR}/${BP}"
-
-You should be aware that many recipes override the
-:term:`S` variable when the default isn't accurate.
-
-.. note::
-
-   The :term:`BP` represents the base recipe name, which consists of the name
-   and version::
-
-           BP = "${BPN}-${PV}"
-
-   This matches the location that the git fetcher unpacks to, and usually
-   matches unpacked content of release tarballs (e.g. they contain a single
-   directory which matches value of ${BP} exactly).
-
-The path to the unpack directory for the recipe
-(:term:`UNPACKDIR`) is defined as follows::
-
-   ${WORKDIR}/sources
-
-In turn, the path to the work directory for the recipe
-(:term:`WORKDIR`) is defined as
-follows::
-
-   ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
-
-The actual directory depends on several things:
-
--  :term:`TMPDIR`: The top-level build
-   output directory.
-
--  :term:`MULTIMACH_TARGET_SYS`:
-   The target system identifier.
-
--  :term:`PN`: The recipe name.
-
--  :term:`EXTENDPE`: The epoch --- if
-   :term:`PE` is not specified, which is
-   usually the case for most recipes, then :term:`EXTENDPE` is blank.
-
--  :term:`PV`: The recipe version.
-
--  :term:`PR`: The recipe revision.
-
-As an example, assume a Source Directory top-level folder named
-``poky``, a default :term:`Build Directory` at ``poky/build``, and a
-``qemux86-poky-linux`` machine target system. Furthermore, suppose your
-recipe is named ``foo_1.3.0.bb``. In this case, the work directory the
-build system uses to build the package would be as follows::
-
-   poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
-