dev-manual: Miscellaneous fixes in the newbie chapter.

(From yocto-docs rev: 34d6bd814e813591631b336f6247c300381fd309)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Robert P. J. Day 2014-08-01 09:01:45 +03:00 committed by Richard Purdie
parent 3152e69383
commit f937e05b44
1 changed files with 21 additions and 21 deletions

View File

@ -41,7 +41,7 @@
</para> </para>
<para> <para>
A benchmark example of an open source project is the Linux Kernel, which was initially conceived A benchmark example of an open source project is the Linux kernel, which was initially conceived
and created by Finnish computer science student Linus Torvalds in 1991. and created by Finnish computer science student Linus Torvalds in 1991.
Conversely, a good example of a non-open source project is the Conversely, a good example of a non-open source project is the
<trademark class='registered'>Windows</trademark> family of operating <trademark class='registered'>Windows</trademark> family of operating
@ -443,7 +443,7 @@
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
Be sure to always work in matching branches for both Be sure to always work in matching branches for both
the <filename>meta-intel</filename> repository and the the selected BSP repository and the
<link linkend='source-directory'>Source Directory</link> <link linkend='source-directory'>Source Directory</link>
(i.e. <filename>poky</filename>) repository. (i.e. <filename>poky</filename>) repository.
For example, if you have checked out the "master" branch For example, if you have checked out the "master" branch
@ -508,7 +508,8 @@
The filenames can differ only in the file type suffix used (e.g. The filenames can differ only in the file type suffix used (e.g.
<filename>formfactor_0.0.bb</filename> and <filename>formfactor_0.0.bbappend</filename>). <filename>formfactor_0.0.bb</filename> and <filename>formfactor_0.0.bbappend</filename>).
</para> </para>
<para>Information in append files overrides the information in the similarly-named recipe file. <para>Information in append files extends or overrides the
information in the similarly-named recipe file.
For an example of an append file in use, see the For an example of an append file in use, see the
"<link linkend='using-bbappend-files'>Using .bbappend Files</link>" section. "<link linkend='using-bbappend-files'>Using .bbappend Files</link>" section.
<note> <note>
@ -669,7 +670,7 @@
chapter in the Yocto Project Reference Manual.</para></listitem> chapter in the Yocto Project Reference Manual.</para></listitem>
<listitem><para id='layer'><emphasis>Layer:</emphasis> A collection of recipes representing the core, <listitem><para id='layer'><emphasis>Layer:</emphasis> A collection of recipes representing the core,
a BSP, or an application stack. a BSP, or an application stack.
For a discussion on BSP Layers, see the For a discussion specifically on BSP Layers, see the
"<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>" "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
section in the Yocto Project Board Support Packages (BSP) section in the Yocto Project Board Support Packages (BSP)
Developer's Guide.</para></listitem> Developer's Guide.</para></listitem>
@ -699,7 +700,7 @@
<para>It is worth noting that the term "package" can, in general, have subtle <para>It is worth noting that the term "package" can, in general, have subtle
meanings. For example, the packages referred to in the meanings. For example, the packages referred to in the
"<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" section are "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" section are
compiled binaries that when installed add functionality to your Linux compiled binaries that, when installed, add functionality to your Linux
distribution.</para> distribution.</para>
<para>Another point worth noting is that historically within the Yocto Project, <para>Another point worth noting is that historically within the Yocto Project,
recipes were referred to as packages - thus, the existence of several BitBake recipes were referred to as packages - thus, the existence of several BitBake
@ -733,12 +734,11 @@
the Yocto Project.</para></listitem> the Yocto Project.</para></listitem>
<listitem><para><emphasis>Recipe:</emphasis> <listitem><para><emphasis>Recipe:</emphasis>
A set of instructions for building packages. A set of instructions for building packages.
A recipe describes where you get source code and which patches A recipe describes where you get source code, which patches
to apply. to apply, how to configure the source, how to compile it and so on.
Recipes describe dependencies for libraries or for other Recipes also describe dependencies for libraries or for other
recipes, and they also contain configuration and compilation recipes.
options. Recipes represent the logical unit of execution, the software
Recipes contain the logical unit of execution, the software
to build, the images to build, and use the to build, the images to build, and use the
<filename>.bb</filename> file extension. <filename>.bb</filename> file extension.
</para></listitem> </para></listitem>
@ -778,7 +778,7 @@
folder is also named "poky".</para> folder is also named "poky".</para>
<para>While it is not recommended that you use tarball expansion <para>While it is not recommended that you use tarball expansion
to setup the Source Directory, if you do, the top-level to set up the Source Directory, if you do, the top-level
directory name of the Source Directory is derived from the directory name of the Source Directory is derived from the
Yocto Project release tarball. Yocto Project release tarball.
For example, downloading and unpacking For example, downloading and unpacking
@ -844,7 +844,7 @@
license is distributed with that software. license is distributed with that software.
MIT is also compatible with the GNU General Public License (GPL). MIT is also compatible with the GNU General Public License (GPL).
Patches to the Yocto Project follow the upstream licensing scheme. Patches to the Yocto Project follow the upstream licensing scheme.
You can find information on the MIT license at You can find information on the MIT license
<ulink url='http://www.opensource.org/licenses/mit-license.php'>here</ulink>. <ulink url='http://www.opensource.org/licenses/mit-license.php'>here</ulink>.
You can find information on the GNU GPL <ulink url='http://www.opensource.org/licenses/LGPL-3.0'> You can find information on the GNU GPL <ulink url='http://www.opensource.org/licenses/LGPL-3.0'>
here</ulink>. here</ulink>.
@ -976,7 +976,7 @@
Each of these branches represents a specific area of development. Each of these branches represents a specific area of development.
The <filename>master</filename> branch represents the current or most recent The <filename>master</filename> branch represents the current or most recent
development. development.
All other branches represent off-shoots of the <filename>master</filename> All other branches represent offshoots of the <filename>master</filename>
branch. branch.
</para> </para>
@ -1029,7 +1029,7 @@
<para> <para>
Some key tags are <filename>dylan-9.0.0</filename>, Some key tags are <filename>dylan-9.0.0</filename>,
<filename>dora-10.0.0</filename>, <filename>dora-10.0.0</filename>, <filename>daisy-11.0.0</filename>,
and <filename>&DISTRO_NAME;-&POKYVERSION;</filename>. and <filename>&DISTRO_NAME;-&POKYVERSION;</filename>.
These tags represent Yocto Project releases. These tags represent Yocto Project releases.
</para> </para>
@ -1175,10 +1175,10 @@
For the Yocto Project, a key individual called the "maintainer" is responsible for the "master" For the Yocto Project, a key individual called the "maintainer" is responsible for the "master"
branch of a given Git repository. branch of a given Git repository.
The "master" branch is the “upstream” repository where the final builds of the project occur. The "master" branch is the “upstream” repository where the final builds of the project occur.
The maintainer is responsible for allowing changes in from other developers and for The maintainer is responsible for accepting changes from other developers and for
organizing the underlying branch structure to reflect release strategies and so forth. organizing the underlying branch structure to reflect release strategies and so forth.
<note>For information on finding out who is responsible (maintains) <note>For information on finding out who is responsible for (maintains)
for a particular area of code, see the a particular area of code, see the
"<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
section. section.
</note> </note>
@ -1332,9 +1332,9 @@
a bug.</para></listitem> a bug.</para></listitem>
<listitem><para>When submitting a new bug, be sure to choose the appropriate <listitem><para>When submitting a new bug, be sure to choose the appropriate
Classification, Product, and Component for which the issue was found. Classification, Product, and Component for which the issue was found.
Defects for the Yocto Project fall into one of six classifications: Yocto Project Defects for the Yocto Project fall into one of seven classifications:
Components, Infrastructure, Build System &amp; Metadata, Documentation, Yocto Project Components, Infrastructure, Build System &amp; Metadata,
QA/Testing, and Runtime. Documentation, QA/Testing, Runtime and Hardware.
Each of these Classifications break down into multiple Products and, in some Each of these Classifications break down into multiple Products and, in some
cases, multiple Components.</para></listitem> cases, multiple Components.</para></listitem>
<listitem><para>Use the bug form to choose the correct Hardware and Architecture <listitem><para>Use the bug form to choose the correct Hardware and Architecture