From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from vms173003pub.verizon.net ([206.46.173.3]) by linuxtogo.org with esmtp (Exim 4.69) (envelope-from ) id 1OHJZO-0004WC-0M for openembedded-devel@lists.openembedded.org; Wed, 26 May 2010 18:35:03 +0200 Received: from gandalf.denix.org ([unknown] [71.255.238.44]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L31005J2CJ10514@vms173003.mailsrvcs.net> for openembedded-devel@lists.openembedded.org; Wed, 26 May 2010 11:30:43 -0500 (CDT) Received: by gandalf.denix.org (Postfix, from userid 1000) id B25E514AF60; Wed, 26 May 2010 12:30:36 -0400 (EDT) Date: Wed, 26 May 2010 12:30:36 -0400 From: Denys Dmytriyenko To: openembedded-devel@lists.openembedded.org Message-id: <20100526163036.GI23464@denix.org> References: <1274879375-19626-1-git-send-email-chase.maupin@ti.com> <1274879375-19626-2-git-send-email-chase.maupin@ti.com> <1274879375-19626-3-git-send-email-chase.maupin@ti.com> <1274879375-19626-4-git-send-email-chase.maupin@ti.com> <1274879375-19626-5-git-send-email-chase.maupin@ti.com> <1274879375-19626-6-git-send-email-chase.maupin@ti.com> MIME-version: 1.0 In-reply-to: <1274879375-19626-6-git-send-email-chase.maupin@ti.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-SA-Exim-Connect-IP: 206.46.173.3 X-SA-Exim-Mail-From: denis@denix.org X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on discovery X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:20:07 +0000) X-SA-Exim-Scanned: Yes (on linuxtogo.org) Cc: Chase Maupin Subject: Re: [PATCHv2 6/7] recipes: Fix documentation errors X-BeenThere: openembedded-devel@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: openembedded-devel@lists.openembedded.org List-Id: Using the OpenEmbedded metadata to build Distributions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 16:35:03 -0000 Content-type: text/plain; charset=us-ascii Content-disposition: inline On Wed, May 26, 2010 at 08:09:34AM -0500, Chase Maupin wrote: > * Fixed up typos and other errors in the documentation. > > Signed-off-by: Chase Maupin Acked-by: Denys Dmytriyenko > --- > docs/usermanual/chapters/recipes.xml | 66 +++++++++++++++++----------------- > 1 files changed, 33 insertions(+), 33 deletions(-) > > diff --git a/docs/usermanual/chapters/recipes.xml b/docs/usermanual/chapters/recipes.xml > index 6a574d8..0bbc05f 100644 > --- a/docs/usermanual/chapters/recipes.xml > +++ b/docs/usermanual/chapters/recipes.xml > @@ -154,7 +154,7 @@ VAR2 = "The version is ${PV}" > > The following example:VAR1 ?= "New value"will > set VAR1 to "New > - value" if its currently empty. However if it was already > + value" if it is currently empty. However if it was already > set it would be unchanged. In the following role="bold">VAR1 is left with the value > "Original value":VAR1 = "Original value" > @@ -290,7 +290,7 @@ mv fixed.recipe.bb myrecipe.bb > > > For a detailed description of the syntax for the bitbake recipe > - files you should refer to the bitbake use manual. > + files you should refer to the bitbake user manual. > > >
> @@ -418,7 +418,7 @@ mv fixed.recipe.bb myrecipe.bb >
> Variables > > - One of the most confusing part of bitbake recipes for new users is > + One of the most confusing parts of bitbake recipes for new users is > the large amount of variables that appear to be available to change and/or > control the behaviour of some aspect of the recipe. Some variables, such > as those derived from the file name are reasonably obvious, others are not > @@ -503,7 +503,7 @@ mv fixed.recipe.bb myrecipe.bb > Practically all recipes start with a header section which describes > various aspects of the package that is being built. This information is > typically used directly by the package format (such as ipkg or deb) as > - its meta data used to describe the package. > + meta data used to describe the package. > > Variables used in the header include: > > @@ -536,7 +536,7 @@ mv fixed.recipe.bb myrecipe.bb > SECTION > > > - The section is used to categorise the application into a > + The section is used to categorize the application into a > specific group. Often used by GUI based installers to help users > when searching for software. > > @@ -625,7 +625,7 @@ mv fixed.recipe.bb myrecipe.bb > file or a compressed archive file, such as .tar.gz or .zip, then the files > will be uncompressed and extracted from the archive automatically. > > - Archive files will be extracted from with the working directory, > + Archive files will be extracted from within the working directory, > ${WORKDIR} and plain files will be copied > into the same directory. Patches will be applied from within the unpacked > source directory, ${S}. (Details on these > @@ -722,7 +722,7 @@ mv fixed.recipe.bb myrecipe.bb > > > This is where patches are applied and where the program is > - expected to be compiled in. > + expected to be compiled. > > > > @@ -790,7 +790,7 @@ mv fixed.recipe.bb myrecipe.bb > file://watchquagga.default"The recipe has two init files > and two configuration files, which are not patches, but are actually > files that it wants to include in the generated packages. Bitbake will > - copy these files into the work directory. So to access them during the > + copy these files into the working directory. So to access them during the > install task we refer to them via the role="bold">WORKDIR variable:do_install () { > # Install init script and default settings > @@ -809,7 +809,7 @@ mv fixed.recipe.bb myrecipe.bb > directory called role="bold"><packagename>-<version> in the > WORKDIR directory. This is the > - directory in which it will change into before patching, compiling and > + directory it will change into before patching, compiling and > installing the package. > > For example, we have a package called @@ -875,7 +875,7 @@ S = "${WORKDIR}/widgets" > Staging directories > > Staging is used to make libraries, headers and binaries available > - for the build of one recipe for use by another recipe. Building a > + from the build of one recipe for use by another recipe. Building a > library for example requires that packages be created containing the > libraries and headers for development on the target as well as making > them available on the host for building other packages that need the > @@ -1339,7 +1339,7 @@ $This shows us that the helloworld program is for an SH > programs that you need to run a configure script for, passing various > parameters, and then make. To make these work when cross-compiling you > need to provides a lot of variables to the configure script. But all the > - hard work as already been done for you. There's an + hard work has already been done for you. There's an linkend="autotools_class" /> which takes care of most of the complexity > of building an autotools based package. > > @@ -1387,7 +1387,7 @@ inherit autotools > > > > - Make modifications to prevent the configure script from tying > + Make modifications to prevent the configure script from trying > to compile and run programs - any programs it compiles will be for > the target and not the host and so cannot be run. > > @@ -1519,7 +1519,7 @@ inherit autotools > role="bold">.so, .a and > associated libtool .la libraries. > It will determine the appropriate libraries to install and take care > - of any modifications that may be require for + of any modifications that may be required for role="bold">.la files. > > This function supports the following options: > @@ -1839,7 +1839,7 @@ NOTE: package helloworld-0.1-r0: task do_package_write: completedWe >
> Default packages and files > > - The defaults package settings are defined in + The default package settings are defined in role="bold">conf/bitbake.conf and are suitable for a lot of > recipes without any changes. The following list shows the default values > for the packaging related variables: > @@ -2363,7 +2363,7 @@ addtask unpack_extra after do_unpack before do_patch > Often a certain pattern is followed in more than one recipe, or > maybe some complex python based functionality is required to achieve the > desired end result. This is achieved through the use of classes, which can > - be found in the classes subdirectory at the top-level of on OE > + be found in the classes subdirectory at the top-level of an OE > checkout. > > Being aware of the available classes and understanding their > @@ -2390,7 +2390,7 @@ addtask unpack_extra after do_unpack before do_patch > A class is used via the inherit method. The following is an example > for the curl recipe showing that it uses three > classes:inherit autotools pkgconfig binconfigIn this case > - it is utilising the services of three separate classes: > + it is utilizing the services of three separate classes: > > > > @@ -2443,7 +2443,7 @@ addtask unpack_extra after do_unpack before do_patch > libraries, available for use by other recipes. This is different to > installing because installing is about making things available for > packaging and then eventually for use on the target device. Staging on the > - other hand is about making things available on the host system for use by > + other hand is about making things available on the host system for use in > building later applications. > > Taking bzip2 as an example you can see that it stages a header file > @@ -2463,7 +2463,7 @@ addtask unpack_extra after do_unpack before do_patch > STAGING_INCDIR > > > - The directory into which staged headers files should be > + The directory into which staged header files should be > installed. This is the equivalent of the standard role="bold">/usr/include directory. > > @@ -2531,7 +2531,7 @@ EXTRA_OECONF = "--disable-ldap \ > script of the package. In the gnupg case it needs to be told where > the bzip2 headers and libraries are, and this is done via the > --with-bzip2 option. In this case it points to > - the directory which include the lib and include subdirectories. > + the directory which includes the lib and include subdirectories. > Since OE doesn't define a variable for one level above the include > and lib directories .. is used to > indicate one directory up. Without this, gnupg would search the host > @@ -2717,9 +2717,9 @@ pkg_postinst_${PN}-rdisc6 () { > > > This class is used when installing and/or removing qpf fonts. > - It register scripts to update the font paths and font cache > + It registers scripts to update the font paths and font cache > information to ensure that the font information is kept up to date > - as fonts and installed and removed. > + as fonts are installed and removed. > > > > @@ -2972,7 +2972,7 @@ fi > > > > - How do handle incrementally creating patches > + How to handle incrementally creating patches > > > > @@ -3025,7 +3025,7 @@ fi > > > This results in the packaging system, such as ipkg, considering > - the released version to be older then the rc version. > + the released version to be older than the rc version. > > In OpenEmbedded the correct naming of pre and rc versions is to use > the previous version number followed by a + followed by the new version > @@ -3138,7 +3138,7 @@ do_configure() { > role="bold">0_9_0. > > Some of the more common python code in use in existing recipes is > - shown in the following table: > + shown in the following list: > > > > @@ -3389,7 +3389,7 @@ $then we would expect it to select version > (since all of the existing versions have a preference of 0). Note that you > can still call bitbake directly on the recipe:bitbake -b recipes/procps/procps_4.0.0.bbThis > enables you to test, and fix the package manually without having bitbake > - automatically select normally. > + automatically select it normally. > > By using this feature in conjunction with overrides you can also > disable (or select) specific versions based on the override. The following > @@ -3418,7 +3418,7 @@ $then we would expect it to select version > > > > - samlpe/standard script? > + sample/standard script? > > > > @@ -3445,13 +3445,13 @@ $then we would expect it to select version > from other packages. > > The most common reason for alternatives is to reduce the size of the > - binaries. But cutting down on features, built in help and error messages > + binaries. By cutting down on features, built in help, error messages > and combining multiple binaries into one large binary it's possible to > save considerable space. Often users are not expected to use the commands > interactively in embedded appliances and therefore these changes have no > visible effect to the user. In some situations users may have interactive > access, or they may be more advanced users who want shell access on > - appliances that normal don't provide it, and in these cases they should be > + appliances that normally don't provide it, and in these cases they should be > able to install the full functional version if they desire. > >
> @@ -3478,7 +3478,7 @@ update-alternatives: Linking //usr/bin/find to find.findutils > update-alternatives: Linking //usr/bin/xargs to xargs.findutils > > Then we see that the standard version of find changes to the full > - featured implement ion:root@titan:~$ find --version > + featured implementation:root@titan:~$ find --version > find --version > GNU find version 4.2.29 > Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION > @@ -3576,7 +3576,7 @@ which find > > > > - even if your distro don't use /var in tmpfs, others do > + even if your distro doesn't use /var in tmpfs, others do > > > > @@ -3588,7 +3588,7 @@ which find >
> Logging and log files > > - As a consequence of the non-volatile and/or small capacity of the > + As a consequence of the volatile and/or small capacity of the > /var file system some distributions > choose methods of logging other than writing to a file. The most typical > is the use of an in-memory circular log buffer which can be read using > @@ -3616,7 +3616,7 @@ which find > > > > - Don't include any /var directories, file or > + Don't include any /var directories, files or > symlinks in packages. They would be lost on a reboot and so should > not be included in packages. > > @@ -3643,7 +3643,7 @@ which find > > > > - about optimisation > + about optimization > > > > -- > 1.6.0.4 > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel