From: aph <aph@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Date: Fri, 14 Jun 2002 05:15:40 +0000 (+0000)
Subject: spelling fixes and some awkward wordings fixed
X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=commitdiff_plain;h=a1eeb504b4a88c497b26ecec50fda13340b3d284

spelling fixes and some awkward wordings fixed


git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@1713 313b444b-1b9f-4f58-a734-7bb04f332e8d
---

diff --git a/developers-reference.sgml b/developers-reference.sgml
index 811fa69..4f13608 100644
--- a/developers-reference.sgml
+++ b/developers-reference.sgml
@@ -6,7 +6,7 @@
   <!entity % commondata  SYSTEM "common.ent" > %commondata;
 
   <!-- CVS revision of this document -->
-  <!entity cvs-rev "$Revision: 1.110 $">
+  <!entity cvs-rev "$Revision: 1.111 $">
   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
@@ -317,7 +317,7 @@ there. If you want to follow the debate preceding a vote, you
 may want to subscribe to &email-debian-vote;.
 	<p>
 The list of all the proposals (past and current) is available on the
-web at <url id="url-vote">. You will find there additionnal information
+web at <url id="url-vote">. You will find there additional information
 about how to make a vote proposal.
 
 
@@ -434,7 +434,7 @@ other mailing lists available for a variety of special topics; see
 	<p>
 &email-debian-private; is a special mailing list for private
 discussions amongst Debian developers.  It is meant to be used for
-posts which for whatever reason should not be published publically.
+posts which for whatever reason should not be published publicly.
 As such, it is a low volume list, and users are urged not to use
 &email-debian-private; unless it is really necessary.  Moreover, do
 <em>not</em> forward email from that list to anyone.  Archives of this
@@ -472,18 +472,18 @@ should not speak there of issues that are discussed in
 in the archives of debian-private in <file>&master-host;:&file-debian-private-archive;</file>, just <prgn>zgrep</prgn> for <em>#debian-private</em> in
 all the files.
 	<p>
-There are other additionnal channels dedicated to specific subjects.
+There are other additional channels dedicated to specific subjects.
 <em>#debian-bugs</em> is used for coordinating bug squash parties.
 <em>#debian-boot</em> is used to coordinate the work on the boot
 floppies (i.e. the installer). <em>#debian-doc</em> is
-occasionnaly used to work on documentation like the one you are
+occasionally used to work on documentation like the one you are
 reading. Other channels are dedicated to an architecture or a set of
-packages : <em>#debian-bsd</em>, <em>#debian-kde</em>,
+packages: <em>#debian-bsd</em>, <em>#debian-kde</em>,
 <em>#debian-sf</em> (SourceForge package), <em>#debian-oo</em> (OpenOffice
 package) ...
 	<p>
-Some non-english channels exist, for example <em>#debian-devel-fr</em> for
-french speaking people interested in Debian's development.
+Some non-English channels exist, for example <em>#debian-devel-fr</em> for
+French speaking people interested in Debian's development.
 
 
       <sect id="doc-rsrcs">Documentation
@@ -564,7 +564,7 @@ else has already reported the problem on the
       <sect1 id="servers-cvs">The CVS server
 	<p>
 <tt>cvs.debian.org</tt> is also known as <tt>klecker.debian.org</tt>,
-discussed above.  If you need to use a publically accessible CVS
+discussed above.  If you need to use a publicly accessible CVS
 server, for instance, to help coordinate work on a package between
 many different developers, you can request a CVS area on the server.
 	  <p>
@@ -726,7 +726,7 @@ shipped for <em>i386</em> and <em>m68k</em> architectures.  Debian 2.1
 ships for the <em>i386</em>, <em>m68k</em>, <em>alpha</em>, and
 <em>sparc</em> architectures.  Debian 2.2 added support for the
 <em>powerpc</em> and <em>arm</em> architectures. Debian 3.0 adds
-support of five new architectures : <em>ia64</em>, <em>hppa</em>,
+support of five new architectures: <em>ia64</em>, <em>hppa</em>,
 <em>s390</em>, <em>mips</em> and <em>mipsel</em>.
 	<p>
 Information for developers or uses about the specific ports are
@@ -948,7 +948,7 @@ the package is refused and is moved in the <file>reject</file> directory.
 	<p>
 Once the package is accepted the system sends a confirmation
 mail to the maintainer, closes all the bugs marked as fixed by the upload
-and the autobuilders may start recompiling it. The package is now publically
+and the auto-builders may start recompiling it. The package is now publicly
 accessible at <url id="&url-incoming;"> (there is no
 such URL for packages in the non-US archive) until it is really installed
 in the Debian archive. This happens only once a day, the package
@@ -968,7 +968,7 @@ why you can not remove an upload once it has been accepted.
       <sect1 id="delayed-incoming">Delayed incoming
 	<p>	
 The <file>unchecked</file> directory has a special <file>DELAYED</file>
-subdirectory. It is itself subdivised in nine directories
+subdirectory. It is itself subdivided in nine directories
 called <file>1-day</file> to <file>9-day</file>. Packages which are uploaded in
 one of those directories will be moved in the real unchecked
 directory after the corresponding number of days.
@@ -1014,11 +1014,11 @@ updated packages. They generate the <file>Packages</file> files for
 the <em>testing</em> distribution, but they do so in an intelligent manner
 trying to avoid any inconsistency and trying to use only
 non-buggy packages.
-	<p>The inclusion of a package from <em>unstable</em> is conditionned:
+	<p>The inclusion of a package from <em>unstable</em> is conditional on the following:
 <list>
     <item>
 The package must have been available in <em>unstable</em> for several days;
-the precise number depends on the urgency field's value of the upload. It
+the precise number depends on the upload's urgency field. It
 is 10 days for low urgency, 5 days for medium urgency and 2 days for high
 urgency. Those delays may be doubled during a freeze;
     <item>
@@ -1103,7 +1103,7 @@ sent through the PTS is classified and associated to one of
 the keyword listed below. This will let you select the mails that
 you want to receive.
 	<p>
-By default you will get :
+By default you will get:
 <taglist>
     <tag><tt>bts</tt>
     <item>
@@ -1135,7 +1135,7 @@ informed of the package's status (bug statistics, porting overview,
 progression in testing, ...).
 </taglist>
 	<p>
-You can also decide to receive some more information :
+You can also decide to receive some more information:
 <taglist>
     <tag><tt>upload-binary</tt>
     <item>
@@ -1180,19 +1180,19 @@ various commands to <email>pts@qa.debian.org</email>.
   Tells you the keywords that you are accepting. Each mail sent through
   the Package Tracking System is associated to a keyword and you receive
   only the mails associated to keywords that you are accepting. Here is
-  the list of available keywords :
+  the list of available keywords:
   <list>
-  <item><tt>bts</tt> : mails coming from the Debian Bug Tracking System
-  <item><tt>bts-control</tt> : reply to mails sent to
+  <item><tt>bts</tt>: mails coming from the Debian Bug Tracking System
+  <item><tt>bts-control</tt>: reply to mails sent to
         <email>control@bugs.debian.org</email>
-  <item><tt>summary</tt> : automatic summary mails about the state of a package
-  <item><tt>cvs</tt> : notification of cvs commits
-  <item><tt>upload-source</tt> : announce of a new source upload that
+  <item><tt>summary</tt>: automatic summary mails about the state of a package
+  <item><tt>cvs</tt>: notification of CVS commits
+  <item><tt>upload-source</tt>: announce of a new source upload that
         has been accepted
-  <item><tt>upload-binary</tt> : announce of a new binary-only upload (porting)
-  <item><tt>katie-other</tt> : other mails from ftpmasters
+  <item><tt>upload-binary</tt>: announce of a new binary-only upload (porting)
+  <item><tt>katie-other</tt>: other mails from ftpmasters
         (override disparity, etc.)
-  <item><tt>default</tt> : all the other mails (those which aren't "automatic")
+  <item><tt>default</tt>: all the other mails (those which aren't "automatic")
   </list>
 
 <tag><tt>keyword &lt;srcpackage&gt; [&lt;email&gt;]</tt>
@@ -1226,7 +1226,7 @@ mailbox with <prgn>procmail</prgn>. The added headers are
 <tt>X-Unsubscribe</tt>.
 	<p>
 Here is an example of added headers for a source upload notification
-on the <package>dpkg</package> package :
+on the <package>dpkg</package> package:
 <example>
 X-Loop: dpkg@&pts-host;
 X-PTS-Package: dpkg
@@ -1236,12 +1236,12 @@ X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org
 
 	<sect1 id="pts-cvs-commit">Forwarding CVS commits in the PTS
 	<p>
-If you use a publically accessible CVS repository for maintaining
+If you use a publicly accessible CVS repository for maintaining
 your Debian package you may want to forward the commit notification
 to the PTS so that the subscribers (possible co-maintainers) can
 closely follow the package's evolution.
 	<p>
-It's very easy to setup. Once your cvs repository generates commit
+It's very easy to setup. Once your CVS repository generates commit
 notifications, you just have to make sure it sends a copy of those mails
 to <tt><var>srcpackage</var>_cvs@&pts-host;</tt>. Only people who
 accepts the <em>cvs</em> keyword will receive the notifications.
@@ -1557,7 +1557,7 @@ As discussed above, export controlled software should not be uploaded
 to <tt>ftp-master</tt>.  Instead, upload the package to
 <ftpsite>non-us.debian.org</ftpsite>, placing the files in
 &non-us-upload-dir; (again, both <ref id="dupload"> and <ref
-id="dput"> can do this for you if invocated properly). By default,
+id="dput"> can do this for you if invoked properly). By default,
 you can use the same account/password that works on
 <tt>ftp-master</tt>.  If you use anonymous FTP to upload, place the
 files into &upload-queue;.
@@ -1814,7 +1814,7 @@ id="nmu-guidelines"> need to be followed.
 	<p>
 Bug fixes to unstable by non-maintainers are also acceptable, but only
 as a last resort or with permission.  The following protocol should
-be respected to do an NMU :
+be respected to do an NMU:
 	<p>
 <list>
 	    <item>
@@ -2195,7 +2195,7 @@ conjunction with <em>auto-builders</em>, which are ``slave'' hosts
 which simply check out and attempt to auto-build packages which need
 to be ported.  There is also an email interface to the system, which
 allows porters to ``check out'' a source package (usually one which
-cannot yet be autobuilt) and work on it.
+cannot yet be auto-built) and work on it.
 	  <p>
 <package>buildd</package> is not yet available as a package; however,
 most porting efforts are either using it currently or planning to use
@@ -2372,7 +2372,7 @@ automatically once you upload a new version with an updated
 <tt>Maintainer:</tt> field, although it can take a few hours after the
 upload is done. If you do not expect to upload a new version for a while,
 you can use <ref id="pkg-tracking-system"> to get the bug reports. However,
-make sure that the old maintainer is not embarassed by the fact that
+make sure that the old maintainer is not embarrassed by the fact that
 he will continue to receive the bugs during that time.
 
 
@@ -2449,14 +2449,14 @@ enough information to let the user correct his problem (give pointers
 to the good documentation and so on). If the same report comes up
 again and again you may ask yourself if the documentation is good
 enough or if the program shouldn't detect its misuse in order to
-give an informatory error message. This is an issue that may need
+give an informative error message. This is an issue that may need
 to be brought to the upstream author.
     <p>
 If the bug submitter disagree with your decision to close the bug,
 he may reopen it until you find an agreement on how to handle it.
 If you don't find any, you may want to tag the bug <tt>wontfix</tt>
 to let people know that the bug exists but that it won't be corrected.
-If this situation is inacceptable, you (or the submitter) may want to
+If this situation is unacceptable, you (or the submitter) may want to
 require a decision of the technical committee by reassigning the bug
 to <package>tech-ctte</package> (you may use the clone command of
 the BTS if you wish to keep it reported against your package).
@@ -2501,7 +2501,7 @@ it will be closed with the next upload (add the <tt>closes:</tt> in
 the <file>changelog</file>). This is particularly useful if you
 are several developers working on the same package.
     <item>
-Once a corrected package is availabe in the <em>unstable</em>
+Once a corrected package is available in the <em>unstable</em>
 distribution, you can close the bug. This can be done automatically,
 read <ref id="upload-bugfix">.
 </enumlist>
@@ -2615,11 +2615,11 @@ The good solution is to keep separate patches within the
 <file>debian/patches</file> directory and to apply them on the fly at
 build time. The package <package>dbs</package> provides an
 implementation of such a system, you just have to build-depend on dbs to
-be able to use its functionnalities. The package
+be able to use its functionalities. The package
 <package>hello-dbs</package> is a simple example that demonstrates how to
 use <package>dbs</package>.
 	<p>
-Additionnaly, dbs provides facilities to create the patches and to keep
+Additionally, dbs provides facilities to create the patches and to keep
 track of what they are for.
 
 	<sect1 id="multiple-binary">Multiple binary packages
@@ -2628,7 +2628,7 @@ A single source package will often build several binary packages, either
 to provide several flavors of the same software (examples are the
 vim-* packages) or to make several small packages instead of a big one
 (it's interesting if the user doesn't need all the packages and can thus
-save some diskspace).
+save some disk space).
 	<p>
 The second case can be easily managed by <prgn>dh_install</prgn> (from
 <package>debhelper</package>) to move files from the build directory to
@@ -2697,8 +2697,8 @@ Good practices for library packaging have been grouped in
 	
 	<sect1 id="bpp-other-specific-practices">Other specific packages
 	<p>
-Several subsets of packages have special subpolicies and corresponding
-packaging rules and practices :
+Several subsets of packages have special sub-policies and corresponding
+packaging rules and practices:
 <list>
     <item>
 Perl related packages have a <url name="perl policy" id="&url-perl-policy;">,
@@ -2706,7 +2706,7 @@ some examples of packages following that policy are
 <package>libdbd-pg-perl</package> (binary perl module) or 
 <package>libmldbm-perl</package> (arch independent perl module).
     <item>
-Python related packages have their python policy :
+Python related packages have their python policy:
 &file-python-policy; (in the python package).
     <item>
 Emacs related packages have the <url id="&url-emacs-policy;"
@@ -2715,8 +2715,8 @@ name="emacs policy">.
 Java related packages have their <url id="&url-java-policy;"
 name="java policy">.
     <item>
-Ocaml related packages have their ocaml policy : &file-ocaml-policy; (in
-the ocaml package). A good example is the <package>camlzip</package>
+Ocaml related packages have their ocaml policy: &file-ocaml-policy; (in
+the <package>ocaml</package> package). A good example is the <package>camlzip</package>
 source package.
 </list>
 
@@ -2732,7 +2732,7 @@ must now be avoided in favor of debconf interaction. This will enable
 non-interactive installations in the future.
 	<p>
 Debconf is a great tool but it is often badly used ... many common mistakes
-are listed in the <manref name="debconf-devel" section="8"> manpage. 
+are listed in the <manref name="debconf-devel" section="8"> man page. 
 It is something that you must have read if you decide to use debconf.
 
 <!--
@@ -2751,7 +2751,7 @@ It is something that you must have read if you decide to use debconf.
 -->	
 
     <sect id="misc-advice">
-	<heading>Miscellaenous advice</heading>
+	<heading>Miscellaneous advice</heading>
 
 	<sect1 id="writing-desc">
 	    <heading>Writing useful descriptions</heading>
@@ -2764,14 +2764,14 @@ to install the package.
 	    <p>
 For example, apart from the usual description that you adapt from the
 upstream <file>README</file>, you should include the URL of the
-website if there's any. If the package is not yet considered stable
+web site if there's any. If the package is not yet considered stable
 by the author, you may also want to warn the user that the
 package is not ready for production use.
 	    <p>
 Last but not least, since the first user impression is based on
-that description, you should be careful to avoid english
+that description, you should be careful to avoid English
 mistakes. Ensure that you spell check it.
-<prgn>ispell</prgn> has a special option (<tt>-g</tt>) for that :
+<prgn>ispell</prgn> has a special option (<tt>-g</tt>) for that:
 <example>ispell -d american -g debian/control</example>
 
 
@@ -2907,7 +2907,7 @@ id="&url-sponsors;">.
 New maintainers usually have certain difficulties creating Debian packages
 &mdash; this is quite understandable. That is why the sponsor is there, to check
 the package and verify that it is good enough for inclusion in Debian.
-(Note that if the sponsored package is new, the FTP admins will also have to
+(Note that if the sponsored package is new, the ftpmasters will also have to
 inspect it before letting it in.)
 	<p>
 Sponsoring merely by signing the upload or just recompiling is