mirror of
git://git.yoctoproject.org/poky.git
synced 2025-07-19 21:09:03 +02:00
manuals: Spellcheck and capitalization fixes
- Spelling fixes found using Emacs' spelling checker configured for US English - Fixes for some capitalization issues, especially some project names (QEMU, openSUSE, BusyBox), that were not consistently used with the same capitalization anyway. - A few whitespace fixes too (From yocto-docs rev: 05d69f17490dcc4933dcd85e57d9db53b912084a) Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com> Reviewed-by: Nicolas Dechesne <nicolas.dechesne@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Michael Opdenacker
Richard Purdie
parent
07c7bdc6c2
commit
c643a4749c
|
|
@ -14,5 +14,5 @@ Commons.
|
|||
To report any inaccuracies or problems with this (or any other Yocto Project)
|
||||
manual, or to send additions or changes, please send email/patches to the Yocto
|
||||
Project documentation mailing list at ``docs@lists.yoctoproject.org`` or
|
||||
log into the freenode ``#yocto`` channel.
|
||||
log into the Freenode ``#yocto`` channel.
|
||||
|
||||
|
|
|
|||
|
|
@ -204,7 +204,7 @@ an entire Linux distribution, including the toolchain, from source.
|
|||
meta-toolchain
|
||||
meta-ide-support
|
||||
|
||||
You can also run generated qemu images with a command like 'runqemu qemux86-64'
|
||||
You can also run generated QEMU images with a command like 'runqemu qemux86-64'
|
||||
|
||||
Among other things, the script creates the :term:`Build Directory`, which is
|
||||
``build`` in this case and is located in the :term:`Source Directory`. After
|
||||
|
|
|
|||
|
|
@ -289,7 +289,7 @@ individual BSPs could differ. ::
|
|||
meta-bsp_root_name/recipes-kernel/linux/linux-yocto_kernel_rev.bbappend
|
||||
|
||||
Below is an example of the Raspberry Pi BSP layer that is available from
|
||||
the :yocto_git:`Source Respositories <>`:
|
||||
the :yocto_git:`Source Repositories <>`:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
|
|
|
|||
|
|
@ -5362,7 +5362,7 @@ command to return the available Wic images as follows:
|
|||
genericx86 Create an EFI disk image for genericx86*
|
||||
beaglebone-yocto Create SD card image for Beaglebone
|
||||
edgerouter Create SD card image for Edgerouter
|
||||
qemux86-directdisk Create a qemu machine 'pcbios' direct disk image
|
||||
qemux86-directdisk Create a QEMU machine 'pcbios' direct disk image
|
||||
directdisk-gpt Create a 'pcbios' direct disk image
|
||||
mkefidisk Create an EFI disk image
|
||||
directdisk Create a 'pcbios' direct disk image
|
||||
|
|
@ -5509,7 +5509,7 @@ Use the following command to list the available kickstart files:
|
|||
genericx86 Create an EFI disk image for genericx86*
|
||||
beaglebone-yocto Create SD card image for Beaglebone
|
||||
edgerouter Create SD card image for Edgerouter
|
||||
qemux86-directdisk Create a qemu machine 'pcbios' direct disk image
|
||||
qemux86-directdisk Create a QEMU machine 'pcbios' direct disk image
|
||||
directdisk-gpt Create a 'pcbios' direct disk image
|
||||
mkefidisk Create an EFI disk image
|
||||
directdisk Create a 'pcbios' direct disk image
|
||||
|
|
@ -8522,7 +8522,7 @@ In order to run tests, you need to do the following:
|
|||
|
||||
- Ubuntu and Debian: ``sysstat`` and ``iproute2``
|
||||
|
||||
- OpenSUSE: ``sysstat`` and ``iproute2``
|
||||
- openSUSE: ``sysstat`` and ``iproute2``
|
||||
|
||||
- Fedora: ``sysstat`` and ``iproute``
|
||||
|
||||
|
|
@ -8648,7 +8648,7 @@ perform a one-time setup of your master image by doing the following:
|
|||
|
||||
- Inherits ``core-image`` so that kernel modules are installed.
|
||||
|
||||
- Installs normal linux utilities not busybox ones (e.g. ``bash``,
|
||||
- Installs normal linux utilities not BusyBox ones (e.g. ``bash``,
|
||||
``coreutils``, ``tar``, ``gzip``, and ``kmod``).
|
||||
|
||||
- Uses a custom Initial RAM Disk (initramfs) image with a custom
|
||||
|
|
|
|||
|
|
@ -100,8 +100,8 @@ Using perf to do Basic Profiling
|
|||
As a simple test case, we'll profile the 'wget' of a fairly large file,
|
||||
which is a minimally interesting case because it has both file and
|
||||
network I/O aspects, and at least in the case of standard Yocto images,
|
||||
it's implemented as part of busybox, so the methods we use to analyze it
|
||||
can be used in a very similar way to the whole host of supported busybox
|
||||
it's implemented as part of BusyBox, so the methods we use to analyze it
|
||||
can be used in a very similar way to the whole host of supported BusyBox
|
||||
applets in Yocto. ::
|
||||
|
||||
root@crownbay:~# rm linux-2.6.19.2.tar.bz2; \
|
||||
|
|
@ -251,7 +251,7 @@ As a bit of background explanation for these callchains, think about
|
|||
what happens at a high level when you run wget to get a file out on the
|
||||
network. Basically what happens is that the data comes into the kernel
|
||||
via the network connection (socket) and is passed to the userspace
|
||||
program 'wget' (which is actually a part of busybox, but that's not
|
||||
program 'wget' (which is actually a part of BusyBox, but that's not
|
||||
important for now), which takes the buffers the kernel passes to it and
|
||||
writes it to a disk file to save it.
|
||||
|
||||
|
|
@ -277,16 +277,16 @@ Now that we've seen the basic layout of the profile data and the basics
|
|||
of how to extract useful information out of it, let's get back to the
|
||||
task at hand and see if we can get some basic idea about where the time
|
||||
is spent in the program we're profiling, wget. Remember that wget is
|
||||
actually implemented as an applet in busybox, so while the process name
|
||||
is 'wget', the executable we're actually interested in is busybox. So
|
||||
let's expand the first entry containing busybox:
|
||||
actually implemented as an applet in BusyBox, so while the process name
|
||||
is 'wget', the executable we're actually interested in is BusyBox. So
|
||||
let's expand the first entry containing BusyBox:
|
||||
|
||||
.. image:: figures/perf-wget-busybox-expanded-stripped.png
|
||||
:align: center
|
||||
|
||||
Again, before we expanded we saw that the function was labeled with a
|
||||
hex value instead of a symbol as with most of the kernel entries.
|
||||
Expanding the busybox entry doesn't make it any better.
|
||||
Expanding the BusyBox entry doesn't make it any better.
|
||||
|
||||
The problem is that perf can't find the symbol information for the
|
||||
busybox binary, which is actually stripped out by the Yocto build
|
||||
|
|
@ -299,7 +299,7 @@ when you build the image: ::
|
|||
|
||||
However, we already have an image with the binaries stripped, so
|
||||
what can we do to get perf to resolve the symbols? Basically we need to
|
||||
install the debuginfo for the busybox package.
|
||||
install the debuginfo for the BusyBox package.
|
||||
|
||||
To generate the debug info for the packages in the image, we can add
|
||||
``dbg-pkgs`` to :term:`EXTRA_IMAGE_FEATURES` in ``local.conf``. For example: ::
|
||||
|
|
@ -314,7 +314,7 @@ in the ``local.conf`` file: ::
|
|||
PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory'
|
||||
|
||||
Once we've done that, we can install the
|
||||
debuginfo for busybox. The debug packages once built can be found in
|
||||
debuginfo for BusyBox. The debug packages once built can be found in
|
||||
``build/tmp/deploy/rpm/*`` on the host system. Find the busybox-dbg-...rpm
|
||||
file and copy it to the target. For example: ::
|
||||
|
||||
|
|
@ -325,7 +325,7 @@ Now install the debug rpm on the target: ::
|
|||
|
||||
root@crownbay:~# rpm -i busybox-dbg-1.20.2-r2.core2_32.rpm
|
||||
|
||||
Now that the debuginfo is installed, we see that the busybox entries now display
|
||||
Now that the debuginfo is installed, we see that the BusyBox entries now display
|
||||
their functions symbolically:
|
||||
|
||||
.. image:: figures/perf-wget-busybox-debuginfo.png
|
||||
|
|
@ -345,11 +345,11 @@ expanded all the nodes using the 'E' key):
|
|||
.. image:: figures/perf-wget-busybox-dso-zoom.png
|
||||
:align: center
|
||||
|
||||
Finally, we can see that now that the busybox debuginfo is installed,
|
||||
Finally, we can see that now that the BusyBox debuginfo is installed,
|
||||
the previously unresolved symbol in the ``sys_clock_gettime()`` entry
|
||||
mentioned previously is now resolved, and shows that the
|
||||
sys_clock_gettime system call that was the source of 6.75% of the
|
||||
copy-to-user overhead was initiated by the ``handle_input()`` busybox
|
||||
copy-to-user overhead was initiated by the ``handle_input()`` BusyBox
|
||||
function:
|
||||
|
||||
.. image:: figures/perf-wget-g-copy-to-user-expanded-debuginfo.png
|
||||
|
|
@ -1900,7 +1900,7 @@ the target: ::
|
|||
meta-toolchain
|
||||
meta-ide-support
|
||||
|
||||
You can also run generated qemu images with a command like 'runqemu qemux86-64'
|
||||
You can also run generated QEMU images with a command like 'runqemu qemux86-64'
|
||||
|
||||
Once you've done that, you can cd to whatever
|
||||
directory contains your scripts and use 'crosstap' to run the script: ::
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ must also provide one of the ``--ondrive``, ``--ondisk``, or
|
|||
.. note::
|
||||
|
||||
The mount program must understand the PARTUUID syntax you use with
|
||||
``--use-uuid`` and non-root *mountpoint*, including swap. The busybox
|
||||
``--use-uuid`` and non-root *mountpoint*, including swap. The BusyBox
|
||||
versions of these application are currently excluded.
|
||||
|
||||
Here is an example that uses "/" as the mountpoint. The command uses
|
||||
|
|
|
|||
|
|
@ -308,6 +308,6 @@ Miscellaneous changes
|
|||
- Erroneous use of ``inherit +=`` (instead of ``INHERIT +=``) in a configuration file now triggers an error instead of silently being ignored.
|
||||
- ptest support has been removed from the ``kbd`` recipe, as upstream has moved to autotest which is difficult to work with in a cross-compilation environment.
|
||||
- ``oe.utils.is_machine_specific()`` and ``oe.utils.machine_paths()`` have been removed as their utility was questionable. In the unlikely event that you have references to these in your own code, then the code will need to be reworked.
|
||||
- The ``i2ctransfer`` module is now disabled by default when building ``busybox`` in order to be consistent with disabling the other i2c tools there. If you do wish the i2ctransfer module to be built in busybox then add ``CONFIG_I2CTRANSFER=y`` to your custom busybox configuration.
|
||||
- The ``i2ctransfer`` module is now disabled by default when building ``busybox`` in order to be consistent with disabling the other i2c tools there. If you do wish the i2ctransfer module to be built in BusyBox then add ``CONFIG_I2CTRANSFER=y`` to your custom BusyBox configuration.
|
||||
- In the ``Upstream-Status`` header convention for patches, ``Accepted`` has been replaced with ``Backport`` as these almost always mean the same thing i.e. the patch is already upstream and may need to be removed in a future recipe upgrade. If you are adding these headers to your own patches then use ``Backport`` to indicate that the patch has been sent upstream.
|
||||
- The ``tune-supersparc.inc`` tune file has been removed as it does not appear to be widely used and no longer works.
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ For more Yocto Project-related mailing lists, see the
|
|||
Internet Relay Chat (IRC)
|
||||
=========================
|
||||
|
||||
Two IRC channels on freenode are available for the Yocto Project and
|
||||
Two IRC channels on Freenode are available for the Yocto Project and
|
||||
Poky discussions:
|
||||
|
||||
- ``#yocto``
|
||||
|
|
@ -189,7 +189,7 @@ Here is a list of resources you might find helpful:
|
|||
implementation of Bugzilla for logging and tracking Yocto Project
|
||||
defects.
|
||||
|
||||
- *Internet Relay Chat (IRC):* Two IRC channels on freenode are
|
||||
- *Internet Relay Chat (IRC):* Two IRC channels on Freenode are
|
||||
available for Yocto Project and Poky discussions: ``#yocto`` and
|
||||
``#poky``, respectively.
|
||||
|
||||
|
|
|
|||
|
|
@ -168,7 +168,7 @@ possible targets to build. Here is an example:
|
|||
meta-toolchain
|
||||
meta-ide-support
|
||||
|
||||
You can also run generated qemu images with a command like 'runqemu qemux86-64'
|
||||
You can also run generated QEMU images with a command like 'runqemu qemux86-64'
|
||||
|
||||
The default output of the ``oe-init-build-env`` script is from the
|
||||
``conf-notes.txt`` file, which is found in the ``meta-poky`` directory
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ distributions:
|
|||
|
||||
- Debian GNU/Linux 10.x (Buster)
|
||||
|
||||
- OpenSUSE Leap 15.1
|
||||
- openSUSE Leap 15.1
|
||||
|
||||
|
||||
.. note::
|
||||
|
|
|
|||
|
|
@ -2582,7 +2582,7 @@ system and gives an overview of their function and contents.
|
|||
and new for generating new keys.
|
||||
|
||||
:term:`FIT_KEY_SIGN_PKCS`
|
||||
Format for public key ceritifcate used in signing fitImage.
|
||||
Format for public key certificate used in signing fitImage.
|
||||
The default value is "x509".
|
||||
|
||||
:term:`FIT_SIGN_ALG`
|
||||
|
|
@ -3449,7 +3449,7 @@ system and gives an overview of their function and contents.
|
|||
|
||||
It is possible to define a list of licenses that are allowed to be
|
||||
used instead of the licenses that are excluded. To do this, define
|
||||
a variable ``COMPATIBLE_LICENSES`` with the names of the licences
|
||||
a variable ``COMPATIBLE_LICENSES`` with the names of the licenses
|
||||
that are allowed. Then define ``INCOMPATIBLE_LICENSE`` as:
|
||||
::
|
||||
|
||||
|
|
@ -3457,8 +3457,8 @@ system and gives an overview of their function and contents.
|
|||
|
||||
|
||||
This will result in ``INCOMPATIBLE_LICENSE`` containing the names of
|
||||
all licences from :term:`AVAILABLE_LICENSES` except the ones specified
|
||||
in ``COMPATIBLE_LICENSES`` , thus only allowing the latter licences to
|
||||
all licenses from :term:`AVAILABLE_LICENSES` except the ones specified
|
||||
in ``COMPATIBLE_LICENSES`` , thus only allowing the latter licenses to
|
||||
be used.
|
||||
|
||||
:term:`INHERIT`
|
||||
|
|
@ -5011,7 +5011,7 @@ system and gives an overview of their function and contents.
|
|||
${PN}-${PV}
|
||||
|
||||
:term:`PACKAGE_ADD_METADATA`
|
||||
This variable defines additional metdata to add to packages.
|
||||
This variable defines additional metadata to add to packages.
|
||||
|
||||
You may find you need to inject additional metadata into packages.
|
||||
This variable allows you to do that by setting the injected data as
|
||||
|
|
@ -7092,7 +7092,7 @@ system and gives an overview of their function and contents.
|
|||
- ``git://`` - Fetches files from a Git revision control
|
||||
repository.
|
||||
|
||||
- ``osc://`` - Fetches files from an OSC (OpenSUSE Build service)
|
||||
- ``osc://`` - Fetches files from an OSC (openSUSE Build service)
|
||||
revision control repository.
|
||||
|
||||
- ``repo://`` - Fetches files from a repo (Git) repository.
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ engineers:
|
|||
|
||||
- *yocto-autobuilder2:* This
|
||||
:yocto_git:`README.md </yocto-autobuilder2/tree/README.md>`
|
||||
is the main README which detials how to set up the Yocto Project
|
||||
is the main README which details how to set up the Yocto Project
|
||||
Autobuilder. The ``yocto-autobuilder2`` repository represents the
|
||||
Yocto Project's console UI plugin to Buildbot and the configuration
|
||||
necessary to configure Buildbot to perform the testing the project
|
||||
|
|
@ -88,7 +88,7 @@ Yocto Project Tests - Types of Testing Overview
|
|||
===============================================
|
||||
|
||||
The Autobuilder tests different elements of the project by using
|
||||
thefollowing types of tests:
|
||||
the following types of tests:
|
||||
|
||||
- *Build Testing:* Tests whether specific configurations build by
|
||||
varying :term:`MACHINE`,
|
||||
|
|
@ -124,7 +124,7 @@ thefollowing types of tests:
|
|||
The tests utilize the ``testsdkext`` class and the ``do_testsdkext`` task.
|
||||
|
||||
- *Feature Testing:* Various scenario-based tests are run through the
|
||||
:ref:`OpenEmbedded Self test (oe-selftest) <ref-manual/release-process:Testing and Quality Assurance>`. We test oe-selftest on each of the main distrubutions
|
||||
:ref:`OpenEmbedded Self test (oe-selftest) <ref-manual/release-process:Testing and Quality Assurance>`. We test oe-selftest on each of the main distributions
|
||||
we support.
|
||||
|
||||
- *Image Testing:* Image tests initiated through the following command::
|
||||
|
|
@ -474,7 +474,7 @@ correctly. The test would only run if python3 is installed in the SDK.
|
|||
----------------------
|
||||
|
||||
The performance tests usually measure how long operations take and the
|
||||
resource utilisation as that happens. An example from
|
||||
resource utilization as that happens. An example from
|
||||
``meta/lib/oeqa/buildperf/test_basic.py`` contains the following::
|
||||
|
||||
class Test3(BuildPerfTestCase):
|
||||
|
|
@ -524,5 +524,5 @@ This is particularly true for oe-selftests since these can run in
|
|||
parallel and changing metadata leads to changing checksums, which
|
||||
confuses BitBake while running in parallel. If this is necessary, copy
|
||||
layers to a temporary location and modify them. Some tests need to
|
||||
change metadata, such as the devtool tests. To prevent the metadate from
|
||||
change metadata, such as the devtool tests. To protect the metadata from
|
||||
changes, set up temporary copies of that data first.
|
||||
|
|
|
|||
|
|
@ -59,13 +59,13 @@ Release Builds
|
|||
|
||||
The project typically has two major releases a year with a six month
|
||||
cadence in April and October. Between these there would be a number of
|
||||
milestone releases (usually four) with the final one being stablization
|
||||
milestone releases (usually four) with the final one being stabilization
|
||||
only along with point releases of our stable branches.
|
||||
|
||||
The build and release process for these project releases is similar to
|
||||
that in `Day to Day Development <#test-daily-devel>`__, in that the
|
||||
a-full target of the Autobuilder is used but in addition the form is
|
||||
configured to generate and publish artefacts and the milestone number,
|
||||
configured to generate and publish artifacts and the milestone number,
|
||||
version, release candidate number and other information is entered. The
|
||||
box to "generate an email to QA"is also checked.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,14 +9,14 @@ Execution Flow within the Autobuilder
|
|||
|
||||
The "a-full" and "a-quick" targets are the usual entry points into the
|
||||
Autobuilder and it makes sense to follow the process through the system
|
||||
starting there. This is best visualised from the Autobuilder Console
|
||||
starting there. This is best visualized from the Autobuilder Console
|
||||
view (:yocto_ab:`/typhoon/#/console`).
|
||||
|
||||
Each item along the top of that view represents some "target build" and
|
||||
these targets are all run in parallel. The 'full' build will trigger the
|
||||
majority of them, the "quick" build will trigger some subset of them.
|
||||
The Autobuilder effectively runs whichever configuration is defined for
|
||||
each of those targets on a seperate buildbot worker. To understand the
|
||||
each of those targets on a separate buildbot worker. To understand the
|
||||
configuration, you need to look at the entry on ``config.json`` file
|
||||
within the ``yocto-autobuilder-helper`` repository. The targets are
|
||||
defined in the ‘overrides' section, a quick example could be qemux86-64
|
||||
|
|
@ -64,10 +64,10 @@ While not every detail of this is covered here, you can see how the
|
|||
template mechanism allows quite complex configurations to be built up
|
||||
yet allows duplication and repetition to be kept to a minimum.
|
||||
|
||||
The different build targets are designed to allow for parallelisation,
|
||||
The different build targets are designed to allow for parallelization,
|
||||
so different machines are usually built in parallel, operations using
|
||||
the same machine and metadata are built sequentially, with the aim of
|
||||
trying to optimise build efficiency as much as possible.
|
||||
trying to optimize build efficiency as much as possible.
|
||||
|
||||
The ``config.json`` file is processed by the scripts in the Helper
|
||||
repository in the ``scripts`` directory. The following section details
|
||||
|
|
@ -164,7 +164,7 @@ Autobuilder Worker Janitor
|
|||
|
||||
This is a process running on each Worker that performs two basic
|
||||
operations, including background file deletion at IO idle (see :ref:`test-manual/understand-autobuilder:Autobuilder Target Execution Overview`: Run clobberdir) and
|
||||
maintainenance of a cache of cloned repositories to improve the speed
|
||||
maintenance of a cache of cloned repositories to improve the speed
|
||||
the system can checkout repositories.
|
||||
|
||||
Shared DL_DIR
|
||||
|
|
@ -250,7 +250,7 @@ Deploying Yocto Autobuilder
|
|||
===========================
|
||||
|
||||
The most up to date information about how to setup and deploy your own
|
||||
Autbuilder can be found in README.md in the ``yocto-autobuilder2``
|
||||
Autobuilder can be found in README.md in the ``yocto-autobuilder2``
|
||||
repository.
|
||||
|
||||
We hope that people can use the ``yocto-autobuilder2`` code directly but
|
||||
|
|
|
|||
|
|
@ -362,7 +362,7 @@ Perform the following steps to install Toaster:
|
|||
|
||||
/etc/httpd/conf.d/toaster.conf
|
||||
|
||||
If you are using OpenSUSE, put it here::
|
||||
If you are using openSUSE, put it here::
|
||||
|
||||
/etc/apache2/conf.d/toaster.conf
|
||||
|
||||
|
|
@ -402,7 +402,7 @@ Perform the following steps to install Toaster:
|
|||
$ chmod +x bitbake/lib/toaster/toastermain/wsgi.py
|
||||
|
||||
Finally, restart Apache to make sure all new configuration is loaded. For Ubuntu,
|
||||
Debian, and OpenSUSE use::
|
||||
Debian, and openSUSE use::
|
||||
|
||||
$ sudo service apache2 restart
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user