diff options
author | Andrew Geissler <geissonator@yahoo.com> | 2020-12-13 17:44:15 +0300 |
---|---|---|
committer | Andrew Geissler <geissonator@yahoo.com> | 2020-12-15 21:53:47 +0300 |
commit | 09209eec235a35b7089db987561c12e9bd023237 (patch) | |
tree | 2d3580484ffacafe11b72e9abaab50a428dd617d /poky/documentation/ref-manual/system-requirements.rst | |
parent | f7ba29eda266e04f867e4338b6b8b10c1969419c (diff) | |
download | openbmc-09209eec235a35b7089db987561c12e9bd023237.tar.xz |
poky: subtree update:0ac99625bf..796be0593a
Alexander Kanavin (31):
netbase: upgrade 6.1 -> 6.2
meson: upgrade 0.55.1 -> 0.56.0
vulkan-samples: update to latest revision
libcap: update 2.44 -> 2.45
bind: upgrade 9.16.7 -> 9.16.9
quota: upgrade 4.05 -> 4.06
pango: upgrade 1.46.2 -> 1.48.0
elfutils: upgrade 0.181 -> 0.182
ifupdown: upgrade 0.8.35 -> 0.8.36
createrepo-c: upgrade 0.16.1 -> 0.16.2
acpica: upgrade 20200925 -> 20201113
grep: upgrade 3.5 -> 3.6
man-pages: upgrade 5.08 -> 5.09
stress-ng: upgrade 0.11.23 -> 0.11.24
libhandy: upgrade 1.0.1 -> 1.0.2
piglit: upgrade to latest revision
xkbcomp: upgrade 1.4.3 -> 1.4.4
lz4: upgrade 1.9.2 -> 1.9.3
bison: upgrade 3.7.3 -> 3.7.4
python3-setuptools-scm: fix upstream version check
cantarell-fonts: update 0.0.25 -> 0.201
meta/lib/oe/reproducible.py: gitsm:// works just as fine as git:// for timestamps
llvm: fix reproducibility
ruby: fix reproducibility
webkitgtk: fix reproducibility
ffmpeg: fix reproducibility
piglit: fix reproducibility
serf: do not install the static library
llvm: sort the lists in generated source reproducibibly
kea: fix reproducibility
poky.conf: do not write current date into distro version, use git hash instead
Andrej Valek (1):
kernel-dummy: fix executing unexpected tasks
Anuj Mittal (1):
releases.rst: add gatesgarth to current releases
Brett Warren (1):
libffi: add patch to revert clang VFP workaround
Chandana kalluri (1):
populate_sdk_ext: use SDK_CUSTOM_TEPLATECONF variable to enable custom templateconf.cfg
Changqing Li (1):
buildtools-tarball: add wic dependency into extended buildtools
Diego Sueiro (2):
modutils-initscripts: Fix modules.dep creation when USE_DEPMOD="0"
initscripts: Change execution order between checkroot and modutils
Dmitry Baryshkov (2):
linux-firmware: upgrade 20201022 -> 20201118
linux-firmware: package ath11k firmware
Fabio Berton (1):
mesa: Update 20.2.1 -> 20.2.4
Gratian Crisan (1):
kernel-module-split.bbclass: fix kernel modules getting marked as CONFFILES
Jack Mitchell (3):
Revert "connman: set service to conflict with systemd-networkd"
systemd-conf: add PACKAGECONFIG to enable/disable auto ethernet DHCP
systemd-conf: match ethernet interfaces by type rather than globbing
Joshua Watt (2):
bitbake: hashserv: client: Fix AF_UNIX path length limits
bitbake: hashserv: Fix broken AF_UNIX path length limit
Kai Kang (2):
systemd-systemctl-native: capable to call without argument
systemd.bbclass: update command to check systemctl available
Kevin Hao (1):
tune-octeontx2.inc: Add tune for Marvell OCTEON TX2 core
Li Wang (2):
qemu: CVE-2020-29129 CVE-2020-29130
qemu: CVE-2020-25624
Luca Boccassi (1):
dbus: move messagebus user to dbus-common package
Michael Halstead (1):
releases: conf: add link to 3.1.4, update to include 3.1.4
Nicolas Dechesne (19):
sphinx: add .vscode in .gitignore
{dev,kernel,sdk}-manual: replace hardcoded release version with &DISTRO;
sphinx: replace bitbake labels with references to corresponding title
brief-yoctoprojectqs: replace labels with references to section title
dev-manual: replace labels with references to section title
ref-manual: replace labels with references to section title
sdk-manual: replace labels with references to section title
overview-manual: remove unused labels
dev-manual: remove unused labels
sphinx: rename top level document in each manual
sphinx: use absolute paths for :doc: references
test-manual: remove 'test-manual' from filenames
toaster-manual: remove 'toaster-manual' from filenames
dev-manual: remove 'dev-manual' from filenames
kernel-dev: remove 'kernel-dev' from filenames
profile-manual: remove 'profile-manual' from filenames
overview-manual: remove 'overview-manual' from filenames
sdk-manual: remove 'sdk' from filenames
ref-manual: remove 'ref' from filenames
Paul Barker (5):
documentation: Simplify yocto_wiki links
documentation: Simplify yocto_git links
ref-manual: Simplify oe_git links
poky.conf: Add opensuseleap-15.2 and fedora-33 to tested distros
poky.conf: Drop fedora-30 from tested distros
Peter Kjellerstedt (2):
pseudo: Simplify pseudo_client_ignore_path_chroot()
bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS
Richard Purdie (8):
lz4: Use the new branch naming from upstream
Revert "bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS"
build-appliance-image: Update to master head revision
bitbake: Revert "fetch2: use relative symlinks for anything pulled from PREMIRRORS"
build-appliance-image: Update to master head revision
metadata_scm: Fix signature handling of METADATA_REVISION and METADATA_BRANCH
poky: Set SDK_VERSION explicitly
build-appliance-image: Update to master head revision
Ross Burton (9):
oeqa/devtool: use Yocto mirror for pv-1.5.3 tarball
image_types: remove obsolete tar comment
image_types: sort tarball file listings
package_manager/ipk: neaten OPKGLIBDIR logic
ldconfig-native: don't write auxiliary cache
package_manager/ipk: improve remove_packaging_data
oeqa/selftest/containerimage: update for improved cleanup
coreutils: add SUSE-specific issues to CVE whitelist
bitbake: msg: use safe YAML loader
Sinan Kaya (1):
poky-tiny: enable section removal
Tomasz Dziendzielski (1):
pseudo: Update to print PSEUDO_LOGFILE in abort message on path mismatches
sangeeta jain (1):
meta/lib/oeqa/manual/oe-core.json: Update test_bitbake_devshell
zangrc (3):
libinput: upgrade 1.16.3 -> 1.16.4
lighttpd: upgrade 1.4.55 -> 1.4.56
sysstat: upgrade 12.4.0 -> 12.4.1
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I65f2f1c9d44433f3e62609240012c42256679b51
Diffstat (limited to 'poky/documentation/ref-manual/system-requirements.rst')
-rw-r--r-- | poky/documentation/ref-manual/system-requirements.rst | 442 |
1 files changed, 442 insertions, 0 deletions
diff --git a/poky/documentation/ref-manual/system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst new file mode 100644 index 000000000..66afb0810 --- /dev/null +++ b/poky/documentation/ref-manual/system-requirements.rst @@ -0,0 +1,442 @@ +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK + +******************* +System Requirements +******************* + +Welcome to the Yocto Project Reference Manual! This manual provides +reference information for the current release of the Yocto Project, and +is most effectively used after you have an understanding of the basics +of the Yocto Project. The manual is neither meant to be read as a +starting point to the Yocto Project, nor read from start to finish. +Rather, use this manual to find variable definitions, class +descriptions, and so forth as needed during the course of using the +Yocto Project. + +For introductory information on the Yocto Project, see the +:yocto_home:`Yocto Project Website <>` and the +":ref:`overview-manual/development-environment:the yocto project development environment`" +chapter in the Yocto Project Overview and Concepts Manual. + +If you want to use the Yocto Project to quickly build an image without +having to understand concepts, work through the +:doc:`/brief-yoctoprojectqs/index` document. You can find "how-to" +information in the :doc:`/dev-manual/index`. You can find Yocto Project overview +and conceptual information in the :doc:`/overview-manual/index`. + +.. note:: + + For more information about the Yocto Project Documentation set, see + the :ref:`ref-manual/resources:links and related documentation` section. + +.. _detailed-supported-distros: + +Supported Linux Distributions +============================= + +Currently, the Yocto Project is supported on the following +distributions: + +- Ubuntu 16.04 (LTS) + +- Ubuntu 18.04 (LTS) + +- Ubuntu 20.04 + +- Fedora 30 + +- Fedora 31 + +- Fedora 32 + +- CentOS 7.x + +- CentOS 8.x + +- Debian GNU/Linux 8.x (Jessie) + +- Debian GNU/Linux 9.x (Stretch) + +- Debian GNU/Linux 10.x (Buster) + +- OpenSUSE Leap 15.1 + + +.. note:: + + - While the Yocto Project Team attempts to ensure all Yocto Project + releases are one hundred percent compatible with each officially + supported Linux distribution, instances might exist where you + encounter a problem while using the Yocto Project on a specific + distribution. + + - Yocto Project releases are tested against the stable Linux + distributions in the above list. The Yocto Project should work + on other distributions but validation is not performed against + them. + + - In particular, the Yocto Project does not support and currently + has no plans to support rolling-releases or development + distributions due to their constantly changing nature. We welcome + patches and bug reports, but keep in mind that our priority is on + the supported platforms listed below. + + - You may use Windows Subsystem For Linux v2 to set up a build host + using Windows 10, but validation is not performed against build + hosts using WSLv2. + + - 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. + + - If you encounter problems, please go to :yocto_bugs:`Yocto Project + Bugzilla <>` and submit a bug. We are + interested in hearing about your experience. For information on + how to submit a bug, see the Yocto Project + :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>` + and the ":ref:`dev-manual/common-tasks:submitting a defect against the yocto project`" + section in the Yocto Project Development Tasks Manual. + + +Required Packages for the Build Host +==================================== + +The list of packages you need on the host development system can be +large when covering all build scenarios using the Yocto Project. This +section describes required packages according to Linux distribution and +function. + +.. _ubuntu-packages: + +Ubuntu and Debian +----------------- + +The following list shows the required packages by function given a +supported Ubuntu or Debian Linux distribution: + +.. note:: + + - If your build system has the ``oss4-dev`` package installed, you + might experience QEMU build failures due to the package installing + its own custom ``/usr/include/linux/soundcard.h`` on the Debian + system. If you run into this situation, either of the following + solutions exist: + :: + + $ sudo apt-get build-dep qemu + $ sudo apt-get remove oss4-dev + + - For Debian-8, ``python3-git`` and ``pylint3`` are no longer + available via ``apt-get``. + :: + + $ sudo pip3 install GitPython pylint==1.9.5 + +- *Essentials:* Packages needed to build an image on a headless system: + :: + + $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL; + +- *Documentation:* Packages needed if you are going to build out the + Yocto Project documentation manuals: + :: + + $ sudo apt-get install make python3-pip + &PIP3_HOST_PACKAGES_DOC; + + .. note:: + + It is currently not possible to build out documentation from Debian 8 + (Jessie) because of outdated ``pip3`` and ``python3``. ``python3-sphinx`` + is too outdated. + +Fedora Packages +--------------- + +The following list shows the required packages by function given a +supported Fedora Linux distribution: + +- *Essentials:* Packages needed to build an image for a headless + system: + :: + + $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL; + +- *Documentation:* Packages needed if you are going to build out the + Yocto Project documentation manuals: + :: + + $ sudo dnf install make python3-pip which + &PIP3_HOST_PACKAGES_DOC; + +openSUSE Packages +----------------- + +The following list shows the required packages by function given a +supported openSUSE Linux distribution: + +- *Essentials:* Packages needed to build an image for a headless + system: + :: + + $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL; + +- *Documentation:* Packages needed if you are going to build out the + Yocto Project documentation manuals: + :: + + $ sudo zypper install make python3-pip which + &PIP3_HOST_PACKAGES_DOC; + + +CentOS-7 Packages +----------------- + +The following list shows the required packages by function given a +supported CentOS-7 Linux distribution: + +- *Essentials:* Packages needed to build an image for a headless + system: + :: + + $ sudo yum install &CENTOS7_HOST_PACKAGES_ESSENTIAL; + + .. note:: + + - Extra Packages for Enterprise Linux (i.e. ``epel-release``) is + a collection of packages from Fedora built on RHEL/CentOS for + easy installation of packages not included in enterprise Linux + by default. You need to install these packages separately. + + - The ``makecache`` command consumes additional Metadata from + ``epel-release``. + +- *Documentation:* Packages needed if you are going to build out the + Yocto Project documentation manuals: + :: + + $ sudo yum install make python3-pip which + &PIP3_HOST_PACKAGES_DOC; + +CentOS-8 Packages +----------------- + +The following list shows the required packages by function given a +supported CentOS-8 Linux distribution: + +- *Essentials:* Packages needed to build an image for a headless + system: + :: + + $ sudo dnf install &CENTOS8_HOST_PACKAGES_ESSENTIAL; + + .. note:: + + - Extra Packages for Enterprise Linux (i.e. ``epel-release``) is + a collection of packages from Fedora built on RHEL/CentOS for + easy installation of packages not included in enterprise Linux + by default. You need to install these packages separately. + + - The ``PowerTools`` repo provides additional packages such as + ``rpcgen`` and ``texinfo``. + + - The ``makecache`` command consumes additional Metadata from + ``epel-release``. + +- *Documentation:* Packages needed if you are going to build out the + Yocto Project documentation manuals: + :: + + $ sudo dnf install make python3-pip which + &PIP3_HOST_PACKAGES_DOC; + +Required Git, tar, Python and gcc Versions +========================================== + +In order to use the build system, your host development system must meet +the following version requirements for Git, tar, and Python: + +- Git 1.8.3.1 or greater + +- tar 1.28 or greater + +- Python 3.5.0 or greater + +If your host development system does not meet all these requirements, +you can resolve this by installing a ``buildtools`` tarball that +contains these tools. You can get the tarball one of two ways: download +a pre-built tarball or use BitBake to build the tarball. + +In addition, your host development system must meet the following +version requirement for gcc: + +- gcc 5.0 or greater + +If your host development system does not meet this requirement, you can +resolve this by installing a ``buildtools-extended`` tarball that +contains additional tools, the equivalent of ``buildtools-essential``. + +Installing a Pre-Built ``buildtools`` Tarball with ``install-buildtools`` script +-------------------------------------------------------------------------------- + +The ``install-buildtools`` script is the easiest of the three methods by +which you can get these tools. It downloads a pre-built buildtools +installer and automatically installs the tools for you: + +1. Execute the ``install-buildtools`` script. Here is an example: + :: + + $ cd poky + $ scripts/install-buildtools --without-extended-buildtools \ + --base-url &YOCTO_DL_URL;/releases/yocto \ + --release yocto-&DISTRO; \ + --installer-version &DISTRO; + + During execution, the buildtools tarball will be downloaded, the + checksum of the download will be verified, the installer will be run + for you, and some basic checks will be run to to make sure the + installation is functional. + + To avoid the need of ``sudo`` privileges, the ``install-buildtools`` + script will by default tell the installer to install in: + :: + + /path/to/poky/buildtools + + If your host development system needs the additional tools provided + in the ``buildtools-extended`` tarball, you can instead execute the + ``install-buildtools`` script with the default parameters: + :: + + $ cd poky + $ scripts/install-buildtools + +2. Source the tools environment setup script by using a command like the + following: + :: + + $ source /path/to/poky/buildtools/environment-setup-x86_64-pokysdk-linux + + Of course, you need to supply your installation directory and be sure to + use the right file (i.e. i586 or x86_64). + + After you have sourced the setup script, the tools are added to + ``PATH`` and any other environment variables required to run the + tools are initialized. The results are working versions versions of + Git, tar, Python and ``chrpath``. And in the case of the + ``buildtools-extended`` tarball, additional working versions of tools + including ``gcc``, ``make`` and the other tools included in + ``packagegroup-core-buildessential``. + +Downloading a Pre-Built ``buildtools`` Tarball +---------------------------------------------- + +Downloading and running a pre-built buildtools installer is the easiest +of the two methods by which you can get these tools: + +1. Locate and download the ``*.sh`` at &YOCTO_RELEASE_DL_URL;/buildtools/ + +2. Execute the installation script. Here is an example for the + traditional installer: + :: + + $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-DISTRO.sh + + Here is an example for the extended installer: + :: + + $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-DISTRO.sh + + During execution, a prompt appears that allows you to choose the + installation directory. For example, you could choose the following: + ``/home/your-username/buildtools`` + +3. Source the tools environment setup script by using a command like the + following: + :: + + $ source /home/your_username/buildtools/environment-setup-i586-poky-linux + + Of + course, you need to supply your installation directory and be sure to + use the right file (i.e. i585 or x86-64). + + After you have sourced the setup script, the tools are added to + ``PATH`` and any other environment variables required to run the + tools are initialized. The results are working versions versions of + Git, tar, Python and ``chrpath``. And in the case of the + ``buildtools-extended`` tarball, additional working versions of tools + including ``gcc``, ``make`` and the other tools included in + ``packagegroup-core-buildessential``. + +Building Your Own ``buildtools`` Tarball +---------------------------------------- + +Building and running your own buildtools installer applies only when you +have a build host that can already run BitBake. In this case, you use +that machine to build the ``.sh`` file and then take steps to transfer +and run it on a machine that does not meet the minimal Git, tar, and +Python (or gcc) requirements. + +Here are the steps to take to build and run your own buildtools +installer: + +1. On the machine that is able to run BitBake, be sure you have set up + your build environment with the setup script + (:ref:`structure-core-script`). + +2. Run the BitBake command to build the tarball: + :: + + $ bitbake buildtools-tarball + + or run the BitBake command to build the extended tarball: + :: + + $ bitbake buildtools-extended-tarball + + .. note:: + + The :term:`SDKMACHINE` variable in your ``local.conf`` file determines + whether you build tools for a 32-bit or 64-bit system. + + Once the build completes, you can find the ``.sh`` file that installs + the tools in the ``tmp/deploy/sdk`` subdirectory of the + :term:`Build Directory`. The installer file has the string + "buildtools" (or "buildtools-extended") in the name. + +3. Transfer the ``.sh`` file from the build host to the machine that + does not meet the Git, tar, or Python (or gcc) requirements. + +4. On the machine that does not meet the requirements, run the ``.sh`` + file to install the tools. Here is an example for the traditional + installer: + :: + + $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh + + Here is an example for the extended installer: + :: + + $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh + + During execution, a prompt appears that allows you to choose the + installation directory. For example, you could choose the following: + ``/home/your_username/buildtools`` + +5. Source the tools environment setup script by using a command like the + following: + :: + + $ source /home/your_username/buildtools/environment-setup-x86_64-poky-linux + + Of course, you need to supply your installation directory and be sure to + use the right file (i.e. i586 or x86_64). + + After you have sourced the setup script, the tools are added to + ``PATH`` and any other environment variables required to run the + tools are initialized. The results are working versions versions of + Git, tar, Python and ``chrpath``. And in the case of the + ``buildtools-extended`` tarball, additional working versions of tools + including ``gcc``, ``make`` and the other tools included in + ``packagegroup-core-buildessential``. |