mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-06-01 13:09:50 +00:00
Code Issues Projects Releases Wiki Activity

sphinx: replace special quotes with single and double quotes

Browse Source 
(From yocto-docs rev: 0aeb7a94abcef3cb3850c753dd0a243f381e6675)

Signed-off-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Quentin Schulz
2020-09-17 01:58:59 +02:00
committed by Richard Purdie
parent 6813141743
commit c387f0c254
26 changed files with 106 additions and 106 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/overview-manual/overview-manual-development-environment.rst
+6 -6
View File
@@ -238,7 +238,7 @@ open source projects do so.
For the Yocto Project, a key individual called the "maintainer" is
responsible for the integrity of the "master" branch of a given Git
repository. The "master" branch is the “upstream” repository from which
repository. The "master" branch is the "upstream" repository from which
final or most recent builds of a project occur. The maintainer is
responsible for accepting changes from other developers and for
organizing the underlying branch structure to reflect release strategies
@@ -273,19 +273,19 @@ with whatever upstream branch they are working against. They are also
responsible for straightening out any conflicts that might arise within
files that are being worked on simultaneously by more than one person.
All this work is done locally on the development host before anything is
pushed to a "contrib" area and examined at the maintainer’s level.
pushed to a "contrib" area and examined at the maintainer's level.
A somewhat formal method exists by which developers commit changes and
push them into the "contrib" area and subsequently request that the
maintainer include them into an upstream branch. This process is called
“submitting a patch” or "submitting a change." For information on
"submitting a patch" or "submitting a change." For information on
submitting patches and changes, see the
":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
section in the Yocto Project Development Tasks Manual.
In summary, a single point of entry exists for changes into a "master"
or development branch of the Git repository, which is controlled by the
project’s maintainer. And, a set of developers exist who independently
project's maintainer. And, a set of developers exist who independently
develop, test, and submit changes to "contrib" areas for the maintainer
to examine. The maintainer then chooses which changes are going to
become a permanent part of the project.
@@ -526,7 +526,7 @@ descriptions and strategies on how to use these commands:
Git commands unless you have a ``.git`` repository.
- *git clone:* Creates a local clone of a Git repository that is on
equal footing with a fellow developer’s Git repository or an upstream
equal footing with a fellow developer's Git repository or an upstream
repository.
- *git add:* Locally stages updated file contents to the index that
@@ -537,7 +537,7 @@ descriptions and strategies on how to use these commands:
you made. Only changes that have been staged can be committed.
Commits are used for historical purposes, for determining if a
maintainer of a project will allow the change, and for ultimately
pushing the change from your local Git repository into the project’s
pushing the change from your local Git repository into the project's
upstream repository.
- *git status:* Reports any modified files that possibly need to be
documentation/overview-manual/overview-manual-development-environment.xml
+6 -6
View File
@@ -327,7 +327,7 @@
For the Yocto Project, a key individual called the "maintainer" is
responsible for the integrity of the "master" branch of a given Git
repository.
The "master" branch is the “upstream” repository from which final or
The "master" branch is the "upstream" repository from which final or
most recent builds of a project occur.
The maintainer is responsible for accepting changes from other
developers and for organizing the underlying branch structure to
@@ -372,7 +372,7 @@
might arise within files that are being worked on simultaneously by
more than one person.
All this work is done locally on the development host before
anything is pushed to a "contrib" area and examined at the maintainer’s
anything is pushed to a "contrib" area and examined at the maintainer's
level.
</para>
@@ -380,7 +380,7 @@
A somewhat formal method exists by which developers commit changes
and push them into the "contrib" area and subsequently request that
the maintainer include them into an upstream branch.
This process is called “submitting a patch” or "submitting a change."
This process is called "submitting a patch" or "submitting a change."
For information on submitting patches and changes, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>"
section in the Yocto Project Development Tasks Manual.
@@ -389,7 +389,7 @@
<para>
In summary, a single point of entry
exists for changes into a "master" or development branch of the
Git repository, which is controlled by the project’s maintainer.
Git repository, which is controlled by the project's maintainer.
And, a set of developers exist who independently develop, test, and
submit changes to "contrib" areas for the maintainer to examine.
The maintainer then chooses which changes are going to become a
@@ -734,7 +734,7 @@
<listitem><para id='git-commands-clone'>
<emphasis><filename>git clone</filename>:</emphasis>
Creates a local clone of a Git repository that is on
equal footing with a fellow developer’s Git repository
equal footing with a fellow developer's Git repository
or an upstream repository.
</para></listitem>
<listitem><para>
@@ -752,7 +752,7 @@
Commits are used for historical purposes, for determining
if a maintainer of a project will allow the change,
and for ultimately pushing the change from your local
Git repository into the project’s upstream repository.
Git repository into the project's upstream repository.
</para></listitem>
<listitem><para>
<emphasis><filename>git status</filename>:</emphasis>
documentation/overview-manual/overview-manual-yp-intro.rst
+6 -6
View File
@@ -319,14 +319,14 @@ applications using the Yocto Project:
The ``devtool`` command employs a number of sub-commands that allow
you to add, modify, and upgrade recipes. As with the OpenEmbedded
build system, “recipes” represent software packages within
build system, "recipes" represent software packages within
``devtool``. When you use ``devtool add``, a recipe is automatically
created. When you use ``devtool modify``, the specified existing
recipe is used in order to determine where to get the source code and
how to patch it. In both cases, an environment is set up so that when
you build the recipe a source tree that is under your control is used
in order to allow you to make changes to the source as desired. By
default, both new recipes and the source go into a “workspace”
default, both new recipes and the source go into a "workspace"
directory under the eSDK. The ``devtool upgrade`` command updates an
existing recipe so that you can build it for an updated set of source
files.
@@ -417,7 +417,7 @@ activities using the Yocto Project:
years ago. Both prelink and cross-prelink are maintained in the same
repository albeit on separate branches. By providing an emulated
runtime dynamic linker (i.e. ``glibc``-derived ``ld.so`` emulation),
the cross-prelink project extends the prelink software’s ability to
the cross-prelink project extends the prelink software's ability to
prelink a sysroot environment. Additionally, the cross-prelink
software enables the ability to work in sysroot style environments.
@@ -432,7 +432,7 @@ activities using the Yocto Project:
library code can be re-used from shared Copy-On-Write (COW) pages.
The original upstream prelink project only supports running prelink
on the end target device due to the reliance on the target device’s
on the end target device due to the reliance on the target device's
dynamic linker. This restriction causes issues when developing a
cross-compiled system. The cross-prelink adds a synthesized dynamic
loader that runs on the host, thus permitting cross-prelinking
@@ -495,7 +495,7 @@ The following list consists of components associated with the
Sharing a core set of metadata results in Poky as an integration
layer on top of OE-Core. You can see that in this
`figure <#yp-key-dev-elements>`__. The Yocto Project combines various
components such as BitBake, OE-Core, script “glue”, and documentation
components such as BitBake, OE-Core, script "glue", and documentation
for its build system.
.. _gs-reference-distribution-poky:
@@ -556,7 +556,7 @@ targets:
.. note::
As best it can, opkg maintains backwards compatibility with ipkg
and conforms to a subset of Debian’s policy manual regarding
and conforms to a subset of Debian's policy manual regarding
control files.
.. _gs-archived-components:
documentation/overview-manual/overview-manual-yp-intro.xml
+6 -6
View File
@@ -459,7 +459,7 @@
<para>The <filename>devtool</filename> command employs
a number of sub-commands that allow you to add, modify,
and upgrade recipes.
As with the OpenEmbedded build system, “recipes”
As with the OpenEmbedded build system, "recipes"
represent software packages within
<filename>devtool</filename>.
When you use <filename>devtool add</filename>, a recipe
@@ -472,7 +472,7 @@
control is used in order to allow you to make changes
to the source as desired.
By default, both new recipes and the source go into
a “workspace” directory under the eSDK.
a "workspace" directory under the eSDK.
The <filename>devtool upgrade</filename> command
updates an existing recipe so that you can build it
for an updated set of source files.</para>
@@ -598,7 +598,7 @@
By providing an emulated runtime dynamic linker
(i.e. <filename>glibc</filename>-derived
<filename>ld.so</filename> emulation), the
cross-prelink project extends the prelink software’s
cross-prelink project extends the prelink software's
ability to prelink a sysroot environment.
Additionally, the cross-prelink software enables the
ability to work in sysroot style environments.</para>
@@ -620,7 +620,7 @@
<para>The original upstream prelink project only
supports running prelink on the end target device
due to the reliance on the target device’s dynamic
due to the reliance on the target device's dynamic
linker.
This restriction causes issues when developing a
cross-compiled system.
@@ -713,7 +713,7 @@
You can see that in this
<link linkend='yp-key-dev-elements'>figure</link>.
The Yocto Project combines various components such as
BitBake, OE-Core, script “glue”, and documentation
BitBake, OE-Core, script "glue", and documentation
for its build system.
</para></listitem>
</itemizedlist>
@@ -791,7 +791,7 @@
<note>
As best it can, opkg maintains backwards
compatibility with ipkg and conforms to a subset
of Debian’s policy manual regarding control files.
of Debian's policy manual regarding control files.
</note>
</para></listitem>
</itemizedlist>