fix

3 files changed, 62 insertions, 99 deletions

diff --git a/eclass/doc/eclass-howto.lyx b/eclass/doc/eclass-howto.lyx
index 6a5661a3192b..ad52b1478922 100644
--- a/eclass/doc/eclass-howto.lyx
+++ b/eclass/doc/eclass-howto.lyx
@@ -43,13 +43,13 @@ eclasses are parts of ebuilds; that is, they have the same syntax ebuilds
  As in OOP, this is used to ensure maximum code reuse among similar ebuilds.
 \layout Standard
 
-This inheritance is implmented via simple bash sourcing.
+This inheritance is implemented via simple bash sourcing.
  So, when you 'inherit
 \begin_inset Quotes erd
 \end_inset 
 
  something its functions and variables override your own.
- For this reason, variables and funcitons are usually extended and not just
+ For this reason, variables and functions are usually extended and not just
  set (more on this later).
 \layout Standard
 
@@ -60,7 +60,7 @@ The most similar group of ebuilds is the kde apps.
  as of this time.
 \layout Standard
 
-Because of the current customizable KDEDIR (KDE?DIR, KDE?LIBSDIR) scheme,
+Because of the current customisable KDEDIR (KDE?DIR, KDE?LIBSDIR) scheme,
  all kde ebuilds (including ebuilds for apps with optional kde support)
  
 \emph on 
@@ -88,7 +88,7 @@ inherit.eclass
 This is the basic eclass.
  It should always be present (i.e.
  inherited).
- No other eclass iherits from it, however: an inheriting ebuild needs to
+ No other eclass inherits from it, however: an inheriting ebuild needs to
  inherit it explicitly before it does anything else, by saying:
 \layout Code
 
@@ -157,66 +157,29 @@ So, every eclass adds to the functions that it defines a prefix.
 \layout Standard
 
 This raises a new problem: we need a function called src_compile so that
- the ebuild doesn't need to explicitly call something_src_comiple.
+ the ebuild doesn't need to explicitly call something_src_compile.
  This is where EXPORT_FUNCTIONS() comes into play:
 \layout Code
 
 EXPORT_FUNCTIONS() {
 \layout Code
 
-\SpecialChar ~
-
+ 
 \layout Code
 
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-while [ "$1" ]; do
+        while [ "$1" ]; do
 \layout Code
 
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
- eval "$1() { ${ECLASS}_$1 ; }" > /dev/null
+            eval "$1() { ${ECLASS}_$1 ; }" > /dev/null
 \layout Code
 
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-shift
+        shift
 \layout Code
 
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-\SpecialChar ~
-done
+        done
 \layout Code
 
-\SpecialChar ~
-
+ 
 \layout Code
 
 }
@@ -250,7 +213,7 @@ ECLASS=foo
 EXPORT_FUNCTIONS src_unpack
 \layout Standard
 
-The EXPORT_FUNCTIONS will call eval on the followin string:
+The EXPORT_FUNCTIONS will call eval on the following string:
 \layout Code
 
 src_unpack() { foo_src_unpack() ; }
@@ -433,7 +396,7 @@ src_compile() {
 }
 \layout Standard
 
-Where myfunc{1,2} is any code you want to execute btween the sections.
+Where myfunc{1,2} is any code you want to execute between the sections.
 \layout Standard
 
 The only way to know what functions contain what sections is to read the
@@ -459,9 +422,9 @@ debug.eclass
 
 Adds verbose output debugging functions.
  Is inherited by virtual.eclass.
- All eclasses call these functions a lot, which makes them look ugky but
- helps a geat deal in tracing stuff, snice there is no bash script debugger/ide/
-step-by-step interpreter AFAIK (if you know of one, tell me!).
+ All eclasses call these functions a lot, which makes them look ugly but
+ helps a great deal in tracing stuff, since there is no bash script debugger/ide
+/step-by-step interpreter AFAIK (if you know of one, tell me!).
 \layout Standard
 
 Look at it to see the functions it provides, they are simplistic.
@@ -475,7 +438,7 @@ You can export ECLASS_DEBUG_OUTPUT=
 \begin_inset Quotes erd
 \end_inset 
 
- to get the output with your other msgs while megring.
+ to get the output with your other msgs while merging.
  Unfortunately opening /dev/stdout for writing violates the sandbox.
  I'm not sure how to bypass this (FIXME!).
 \layout Standard
@@ -612,7 +575,7 @@ This is made and maintained by Azarah.
  To quote his comments:
 \layout Standard
 
-This eclass was made to bridge the incompadibility problem of autoconf-2.13,
+This eclass was made to bridge the incompatibility problem of autoconf-2.13,
  autoconf-2.5x and automake-1.4x, automake-1.5x.
  Most packages needs autoconf-2.13 and automake-1.4x, but cannot work with
  the latest versions of these packages due to incompatibility, thus when
@@ -621,7 +584,7 @@ This eclass was made to bridge the incompadibility problem of autoconf-2.13,
 \layout Standard
 
 Read the eclass for more info.
- AFAIK it has no relatinship whatsoever to an of the other eclasses.
+ AFAIK it has no relationship whatsoever to an of the other eclasses.
  Contact Azarah for any further info.
  (Azarah, you're welcome to feel in here).
 \layout Subsection
@@ -667,7 +630,7 @@ kde-dirs.eclass
 A short explanation about the current multi-kdedir scheme:
 \layout Standard
 
-$KDE{2,3}DIR and $KDELIBS{2,3}DIR are set in make.globals (and can be overriden
+$KDE{2,3}DIR and $KDELIBS{2,3}DIR are set in make.globals (and can be overridden
  in make.conf).
  Their default values are /usr/kde/{2,3}.
 \layout Standard
@@ -682,9 +645,9 @@ A package that identifies itself as a kde2 package (see below) will use
 As for qt, the latest 2.x, 3.x version lives in /usr/qt/2,3 respectively.
 \layout Standard
 
-The inner works of the sytem needn't be described here.
+The inner works of the system needn't be described here.
  A few weeks ago all this scheme was changed out of recognition, but no
- ebulds needed to be changed, only eclasses.
+ ebuilds needed to be changed, only eclasses.
  That speaks for their success.
 \layout Standard
 
@@ -714,7 +677,7 @@ The set-* dir functions are both called from the beginning of the configure
  That's all your ebuild should need.
 \layout Standard
 
-In a euild with optional kde support, you inherit kde-dirs directly (and
+In a ebuild with optional kde support, you inherit kde-dirs directly (and
  no other eclass).
  You should then call both need-* and set-* yourself.
 \layout Standard
@@ -806,13 +769,13 @@ This is only included with the kde3-pre ebuilds, and doesn't live in portage.
 .
 \layout Standard
 
-For prerelease ebuilds, which have underscores in their portage names (3.0_beta1)
- but not in their source archives' names (3.0beta1.tar.gz).
+For pre-release ebuilds, which have underscores in their portage names (3.0_beta1
+) but not in their source archives' names (3.0beta1.tar.gz).
  Removes any underscores from $SRC_URI and $S.
 \layout Standard
 
 I'll probably add this to portage if there'll be a reason to do it (i.e.
- a prrelease kde ebuild in portage).
+ a pre-release kde ebuild in portage).
 \layout Section
 
 The inheriting ebuilds
diff --git a/eclass/doc/eclass-howto.sgml b/eclass/doc/eclass-howto.sgml
index b1e74e26cb3d..bce30285b43e 100644
--- a/eclass/doc/eclass-howto.sgml
+++ b/eclass/doc/eclass-howto.sgml
@@ -20,13 +20,13 @@
    eclasses are parts of ebuilds; that is, they have the same syntax ebuilds do, but do not define all the required variables and functions. ebuilds can inherit from eclasses, and eclasses can inherit from other eclasses. As in OOP, this is used to ensure maximum code reuse among similar ebuilds.
   </para>
   <para>
-   This inheritance is implmented via simple bash sourcing. So, when you 'inherit&rdquo; something its functions and variables override your own. For this reason, variables and funcitons are usually extended and not just set (more on this later).
+   This inheritance is implemented via simple bash sourcing. So, when you 'inherit&rdquo; something its functions and variables override your own. For this reason, variables and functions are usually extended and not just set (more on this later).
   </para>
   <para>
    The most similar group of ebuilds is the kde apps. These were accordingly selected to be the test case for eclasses, and I believe I can now say the test has been successful. Eclasses for non-kde ebuilds may follow, but there are no concrete plans as of this time.
   </para>
   <para>
-   Because of the current customizable KDEDIR (KDE?DIR, KDE?LIBSDIR) scheme, all kde ebuilds (including ebuilds for apps with optional kde support) <emphasis>must </emphasis>use the eclasses. As a minimum, inherit kde-dirs to get the set-qtdir(), set-kdedir() functions.
+   Because of the current customisable KDEDIR (KDE?DIR, KDE?LIBSDIR) scheme, all kde ebuilds (including ebuilds for apps with optional kde support) <emphasis>must </emphasis>use the eclasses. As a minimum, inherit kde-dirs to get the set-qtdir(), set-kdedir() functions.
   </para>
   <para>
    Section two explains how eclasses work; section three gives an example of a typical inheriting ebuild, and another of an ebuild for an app with optional kde functionality.
@@ -44,7 +44,7 @@
     inherit.eclass
    </title>
    <para>
-    This is the basic eclass. It should always be present (i.e. inherited). No other eclass iherits from it, however: an inheriting ebuild needs to inherit it explicitly before it does anything else, by saying:
+    This is the basic eclass. It should always be present (i.e. inherited). No other eclass inherits from it, however: an inheriting ebuild needs to inherit it explicitly before it does anything else, by saying:
    </para>
    <programlisting>
 <![ CDATA [. /usr/portage/eclass/inherit.eclass || die
@@ -88,7 +88,7 @@
     So, every eclass adds to the functions that it defines a prefix. For example, A.eclass will define A_src_compile(), and B.eclass will define a B_src_compile(). That way, the ebuild can call either function and know what it'll get.
    </para>
    <para>
-    This raises a new problem: we need a function called src_compile so that the ebuild doesn't need to explicitly call something_src_comiple. This is where EXPORT_FUNCTIONS() comes into play:
+    This raises a new problem: we need a function called src_compile so that the ebuild doesn't need to explicitly call something_src_compile. This is where EXPORT_FUNCTIONS() comes into play:
    </para>
    <programlisting>
 <![ CDATA [EXPORT_FUNCTIONS() {
@@ -108,7 +108,7 @@
 ]]><![ CDATA [EXPORT_FUNCTIONS src_unpack
 ]]>   </programlisting>
    <para>
-    The EXPORT_FUNCTIONS will call eval on the followin string:
+    The EXPORT_FUNCTIONS will call eval on the following string:
    </para>
    <programlisting>
 <![ CDATA [src_unpack() { foo_src_unpack() ; }
@@ -184,7 +184,7 @@
 ]]><![ CDATA [}
 ]]>   </programlisting>
    <para>
-    Where myfunc&lcub;1,2&rcub; is any code you want to execute btween the sections.
+    Where myfunc&lcub;1,2&rcub; is any code you want to execute between the sections.
    </para>
    <para>
     The only way to know what functions contain what sections is to read the eclasses.
@@ -198,13 +198,13 @@
     debug.eclass
    </title>
    <para>
-    Adds verbose output debugging functions. Is inherited by virtual.eclass. All eclasses call these functions a lot, which makes them look ugky but helps a geat deal in tracing stuff, snice there is no bash script debugger/ide/step-by-step interpreter AFAIK (if you know of one, tell me!).
+    Adds verbose output debugging functions. Is inherited by virtual.eclass. All eclasses call these functions a lot, which makes them look ugly but helps a great deal in tracing stuff, since there is no bash script debugger/ide/step-by-step interpreter AFAIK (if you know of one, tell me!).
    </para>
    <para>
     Look at it to see the functions it provides, they are simplistic.
    </para>
    <para>
-    You can export ECLASS_DEBUG_OUTPUT=&rdquo;/dev/stdout&rdquo; to get the output with your other msgs while megring. Unfortunately opening /dev/stdout for writing violates the sandbox. I'm not sure how to bypass this (FIXME!).
+    You can export ECLASS_DEBUG_OUTPUT=&rdquo;/dev/stdout&rdquo; to get the output with your other msgs while merging. Unfortunately opening /dev/stdout for writing violates the sandbox. I'm not sure how to bypass this (FIXME!).
    </para>
    <para>
     Let's add typical debug output statements to our sample function from the function sections explanation:
@@ -282,10 +282,10 @@
     This is made and maintained by Azarah. To quote his comments:
    </para>
    <para>
-    This eclass was made to bridge the incompadibility problem of autoconf-2.13, autoconf-2.5x and automake-1.4x, automake-1.5x. Most packages needs autoconf-2.13 and automake-1.4x, but cannot work with the latest versions of these packages due to incompatibility, thus when we have a package that needs the latest versions of automake and autoconf, it begins to get a problem.
+    This eclass was made to bridge the incompatibility problem of autoconf-2.13, autoconf-2.5x and automake-1.4x, automake-1.5x. Most packages needs autoconf-2.13 and automake-1.4x, but cannot work with the latest versions of these packages due to incompatibility, thus when we have a package that needs the latest versions of automake and autoconf, it begins to get a problem.
    </para>
    <para>
-    Read the eclass for more info. AFAIK it has no relatinship whatsoever to an of the other eclasses. Contact Azarah for any further info. (Azarah, you're welcome to feel in here).
+    Read the eclass for more info. AFAIK it has no relationship whatsoever to an of the other eclasses. Contact Azarah for any further info. (Azarah, you're welcome to feel in here).
    </para>
    </sect2>
    <sect2>
@@ -316,7 +316,7 @@
     A short explanation about the current multi-kdedir scheme:
    </para>
    <para>
-    &dollar;KDE&lcub;2,3&rcub;DIR and &dollar;KDELIBS&lcub;2,3&rcub;DIR are set in make.globals (and can be overriden in make.conf). Their default values are /usr/kde/&lcub;2,3&rcub;.
+    &dollar;KDE&lcub;2,3&rcub;DIR and &dollar;KDELIBS&lcub;2,3&rcub;DIR are set in make.globals (and can be overridden in make.conf). Their default values are /usr/kde/&lcub;2,3&rcub;.
    </para>
    <para>
     A package that identifies itself as a kde2 package (see below) will use the kdelibs installed in &dollar;KDELIBS2DIR and install itself into &dollar;KDE2DIR. Same goes for kde3. NOTE: separating kdelibs from kde apps and any other non-default KDEDIR stuff is untested and unsupported.
@@ -325,7 +325,7 @@
     As for qt, the latest 2.x, 3.x version lives in /usr/qt/2,3 respectively.
    </para>
    <para>
-    The inner works of the sytem needn't be described here. A few weeks ago all this scheme was changed out of recognition, but no ebulds needed to be changed, only eclasses. That speaks for their success.
+    The inner works of the system needn't be described here. A few weeks ago all this scheme was changed out of recognition, but no ebuilds needed to be changed, only eclasses. That speaks for their success.
    </para>
    <para>
     This eclass provides two pairs of functions: need-kde(), need-qt() and set-kdedir(), set-qtdir(). These functions handle the details of the multi-qt and multi-kdelibs schemes.
@@ -340,7 +340,7 @@
     The set-* dir functions are both called from the beginning of the configure section of the kde_src_compile() function. They set KDEDIR and QTDIR appropriately. That's all your ebuild should need.
    </para>
    <para>
-    In a euild with optional kde support, you inherit kde-dirs directly (and no other eclass). You should then call both need-* and set-* yourself.
+    In a ebuild with optional kde support, you inherit kde-dirs directly (and no other eclass). You should then call both need-* and set-* yourself.
    </para>
    <para>
     kde-dirs.eclass also contains several helper functions you shouldn't need to use directly.
@@ -406,10 +406,10 @@
     This is only included with the kde3-pre ebuilds, and doesn't live in portage. See <ulink url="http://www.gentoo.org/~danarmak/kde3-pre.html">http://www.gentoo.org/~danarmak/kde3-pre.html</ulink>.
    </para>
    <para>
-    For prerelease ebuilds, which have underscores in their portage names (3.0_beta1) but not in their source archives' names (3.0beta1.tar.gz). Removes any underscores from &dollar;SRC_URI and &dollar;S.
+    For pre-release ebuilds, which have underscores in their portage names (3.0_beta1) but not in their source archives' names (3.0beta1.tar.gz). Removes any underscores from &dollar;SRC_URI and &dollar;S.
    </para>
    <para>
-    I'll probably add this to portage if there'll be a reason to do it (i.e. a prrelease kde ebuild in portage).
+    I'll probably add this to portage if there'll be a reason to do it (i.e. a pre-release kde ebuild in portage).
    </para>
    </sect2>
   </sect1>
diff --git a/eclass/doc/eclass-howto.txt b/eclass/doc/eclass-howto.txt
index 114c3e454c9d..bcca20274ccd 100644
--- a/eclass/doc/eclass-howto.txt
+++ b/eclass/doc/eclass-howto.txt
@@ -14,10 +14,10 @@ and functions. ebuilds can inherit from eclasses, and eclasses
 can inherit from other eclasses. As in OOP, this is used
 to ensure maximum code reuse among similar ebuilds.
 
-This inheritance is implmented via simple bash sourcing.
+This inheritance is implemented via simple bash sourcing.
 So, when you 'inherit" something its
 functions and variables override your own. For this reason,
-variables and funcitons are usually extended and not just
+variables and functions are usually extended and not just
 set (more on this later).
 
 The most similar group of ebuilds is the kde apps. These
@@ -26,7 +26,7 @@ and I believe I can now say the test has been successful.
 Eclasses for non-kde ebuilds may follow, but there are no
 concrete plans as of this time.
 
-Because of the current customizable KDEDIR (KDE?DIR, KDE?LIBSDIR)
+Because of the current customisable KDEDIR (KDE?DIR, KDE?LIBSDIR)
 scheme, all kde ebuilds (including ebuilds for apps with
 optional kde support) must use the eclasses. As a minimum,
 inherit kde-dirs to get the set-qtdir(), set-kdedir() functions.
@@ -43,7 +43,7 @@ structure is an explanation of what each eclass does.
 2.1 inherit.eclass
 
 This is the basic eclass. It should always be present (i.e.
-inherited). No other eclass iherits from it, however: an
+inherited). No other eclass inherits from it, however: an
 inheriting ebuild needs to inherit it explicitly before
 it does anything else, by saying:
 
@@ -96,7 +96,7 @@ and B.eclass will define a B_src_compile(). That way, the
 ebuild can call either function and know what it'll get.
 
 This raises a new problem: we need a function called src_compile
-so that the ebuild doesn't need to explicitly call something_src_comiple.
+so that the ebuild doesn't need to explicitly call something_src_compile.
 This is where EXPORT_FUNCTIONS() comes into play:
 
 EXPORT_FUNCTIONS() {
@@ -124,7 +124,7 @@ ECLASS=foo
 
 EXPORT_FUNCTIONS src_unpack
 
-The EXPORT_FUNCTIONS will call eval on the followin string:
+The EXPORT_FUNCTIONS will call eval on the following string:
 
 src_unpack() { foo_src_unpack() ; }
 
@@ -230,7 +230,7 @@ src_compile() {
 
 }
 
-Where myfunc{1,2} is any code you want to execute btween
+Where myfunc{1,2} is any code you want to execute between
 the sections.
 
 The only way to know what functions contain what sections
@@ -245,14 +245,14 @@ such section right now is base_src_compile patch.
 
 Adds verbose output debugging functions. Is inherited by
 virtual.eclass. All eclasses call these functions a lot,
-which makes them look ugky but helps a geat deal in tracing
-stuff, snice there is no bash script debugger/ide/step-by-step
+which makes them look ugly but helps a great deal in tracing
+stuff, since there is no bash script debugger/ide/step-by-step
 interpreter AFAIK (if you know of one, tell me!).
 
 Look at it to see the functions it provides, they are simplistic.
 
 You can export ECLASS_DEBUG_OUTPUT="/dev/stdout"
-to get the output with your other msgs while megring. Unfortunately
+to get the output with your other msgs while merging. Unfortunately
 opening /dev/stdout for writing violates the sandbox. I'm
 not sure how to bypass this (FIXME!).
 
@@ -338,7 +338,7 @@ Adds make/automake/autoconf to DEPEND.
 
 This is made and maintained by Azarah. To quote his comments:
 
-This eclass was made to bridge the incompadibility problem
+This eclass was made to bridge the incompatibility problem
 of autoconf-2.13, autoconf-2.5x and automake-1.4x, automake-1.5x.
 Most packages needs autoconf-2.13 and automake-1.4x, but
 cannot work with the latest versions of these packages due
@@ -346,7 +346,7 @@ to incompatibility, thus when we have a package that needs
 the latest versions of automake and autoconf, it begins
 to get a problem.
 
-Read the eclass for more info. AFAIK it has no relatinship
+Read the eclass for more info. AFAIK it has no relationship
 whatsoever to an of the other eclasses. Contact Azarah for
 any further info. (Azarah, you're welcome to feel in here).
 
@@ -381,7 +381,7 @@ should inherit from kde-base.eclass.
 A short explanation about the current multi-kdedir scheme:
 
 $KDE{2,3}DIR and $KDELIBS{2,3}DIR are set in make.globals
-(and can be overriden in make.conf). Their default values
+(and can be overridden in make.conf). Their default values
 are /usr/kde/{2,3}.
 
 A package that identifies itself as a kde2 package (see below)
@@ -393,9 +393,9 @@ is untested and unsupported.
 As for qt, the latest 2.x, 3.x version lives in /usr/qt/2,3
 respectively.
 
-The inner works of the sytem needn't be described here. A
-few weeks ago all this scheme was changed out of recognition,
-but no ebulds needed to be changed, only eclasses. That
+The inner works of the system needn't be described here.
+A few weeks ago all this scheme was changed out of recognition,
+but no ebuilds needed to be changed, only eclasses. That
 speaks for their success.
 
 This eclass provides two pairs of functions: need-kde(),
@@ -419,7 +419,7 @@ of the configure section of the kde_src_compile() function.
 They set KDEDIR and QTDIR appropriately. That's all your
 ebuild should need.
 
-In a euild with optional kde support, you inherit kde-dirs
+In a ebuild with optional kde support, you inherit kde-dirs
 directly (and no other eclass). You should then call both
 need-* and set-* yourself.
 
@@ -472,13 +472,13 @@ eclass. Useful if you have a local copy of the kde cvs modules.
 This is only included with the kde3-pre ebuilds, and doesn't
 live in portage. See [http://www.gentoo.org/~danarmak/kde3-pre.html||http://www.gentoo.org/~danarmak/kde3-pre.html].
 
-For prerelease ebuilds, which have underscores in their portage
-names (3.0_beta1) but not in their source archives' names
-(3.0beta1.tar.gz). Removes any underscores from $SRC_URI
+For pre-release ebuilds, which have underscores in their
+portage names (3.0_beta1) but not in their source archives'
+names (3.0beta1.tar.gz). Removes any underscores from $SRC_URI
 and $S.
 
 I'll probably add this to portage if there'll be a reason
-to do it (i.e. a prrelease kde ebuild in portage).
+to do it (i.e. a pre-release kde ebuild in portage).
 
 3 The inheriting ebuilds