X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=89ba78fc4c9ba549ac895c674fd54deb284c4f5d;hb=ecee6551e1df491ff228a896721ec116182f64f7;hp=e793cda7be86a5523e26fb9edabe546fa7ca8694;hpb=d17416fdfdea7cc9a962f4b6cc7913477a863908;p=developers-reference.git

diff --git a/developers-reference.sgml b/developers-reference.sgml
index e793cda..89ba78f 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.218 $">
+  <!ENTITY cvs-rev "$Revision: 1.221 $">
   <!-- if you are translating this document, please notate the CVS
        revision of the developers reference here -->
   <!--
@@ -221,7 +221,7 @@ To apply as a new maintainer, you need an existing Debian maintainer
 to verify your application (an <em>advocate</em>).  After you have
 contributed to Debian for a while, and you want to apply to become a
 registered developer, an existing developer with whom you
-have worked over the past months has to express his belief that you
+have worked over the past months has to express their belief that you
 can contribute to Debian successfully.
 	<p>
 When you have found an advocate, have your GnuPG key signed and have
@@ -715,7 +715,7 @@ Those features are documented at <url id="&url-debian-db-mail-gw;">.
 	<p>
 The &debian-formal; distribution consists of a lot of packages
 (<file>.deb</file>'s, currently around &number-of-pkgs;) and a few
-additional files (such documentation and installation disk images).
+additional files (such as documentation and installation disk images).
 	<p>
 Here is an example directory tree of a complete Debian archive:
 	<p>
@@ -740,7 +740,7 @@ In each of the areas, there is a directory for the source packages
 (<file>source</file>) and a directory for each supported architecture
 (<file>binary-i386</file>, <file>binary-m68k</file>, etc.).
 	<p>
-The <file>main</file> area contains additional directories which holds
+The <file>main</file> area contains additional directories which hold
 the disk images and some essential pieces of documentation required
 for installing the Debian distribution on a specific architecture
 (<file>disks-i386</file>, <file>disks-m68k</file>, etc.).
@@ -808,7 +808,7 @@ The Linux 2.0 kernel supports Intel x86, DEC Alpha, SPARC, Motorola
 Linux 2.2 kernel supports even more architectures, including ARM and
 UltraSPARC.  Since Linux supports these platforms, Debian decided that
 it should, too.  Therefore, Debian has ports underway; in fact, we
-also have ports underway to non-Linux kernel.  Aside from
+also have ports underway to non-Linux kernels.  Aside from
 <em>i386</em> (our name for Intel x86), there is <em>m68k</em>,
 <em>alpha</em>, <em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>,
 <em>arm</em>, <em>ia64</em>, <em>hppa</em>, <em>s390</em>, <em>mips</em>,
@@ -822,7 +822,7 @@ ships for the <em>i386</em>, <em>m68k</em>, <em>alpha</em>, and
 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
+Information for developers and users about the specific ports are
 available at the <url id="&url-debian-ports;" name="Debian Ports web
 pages">.
 
@@ -887,11 +887,11 @@ distribution changes from day-to-day. Since no special effort is done
 to make sure everything in this distribution is working properly, it is
 sometimes literally unstable.
 	<p>
-<ref id="testing"> is generated automatically by taking
+<qref id="testing">"testing"</qref> is generated automatically by taking
 packages from unstable if they satisfy certain criteria. Those
 criteria should ensure a good quality for packages within testing.
 The update to testing is launched each day after the
-new packages have been installed.
+new packages have been installed. See <ref id="testing">.
 	<p>
 After a period of development, once the release manager deems fit, the
 <em>testing</em> distribution is frozen, meaning that the policies
@@ -957,7 +957,7 @@ in <em>testing</em>;
     <item>
 The packages on which it depends must either be available in <em>testing</em>
 or they must be accepted into <em>testing</em> at the same time (and they will
-if they respect themselves all the criteria);
+if they respect all the necessary criteria);
 </list>
 	<p>
 To find out whether a package is progressing into testing or not, see the
@@ -969,12 +969,12 @@ informed of the progression of their packages into <em>testing</em>.
 	<p>
 The <file>update_excuses</file> file does not always give the precise reason
 why the package is refused, one may have to find it on their own by looking
-what would break with the inclusion of the package. The <url
-id="&url-testing-maint;" name="testing web page"> gives some more information
-about the usual problems which may be causing such troubles.
+for what would break with the inclusion of the package. The
+<url id="&url-testing-maint;" name="testing web page"> gives some more
+information about the usual problems which may be causing such troubles.
 	<p>
 Sometimes, some packages never enter <em>testing</em> because the set of
-inter-relationship is too complicated and can not be sorted out
+inter-relationship is too complicated and cannot be sorted out
 by the scripts. In that case, the release manager must be
 contacted, and he will force the inclusion of the packages.
 	<p>
@@ -1011,7 +1011,7 @@ into <em>experimental</em>.
 Whenever there is a new upstream version of a package that introduces new
 features but breaks a lot of old ones, it should either not be uploaded, or
 be uploaded to <em>experimental</em>. A new, beta, version of some software
-which uses completely different configuration can go into
+which uses a completely different configuration can go into
 <em>experimental</em>, at the maintainer's discretion. If you are working
 on an incompatible or complex upgrade situation, you can also use
 <em>experimental</em> as a staging area, so that testers can get early
@@ -1074,8 +1074,8 @@ symbolic links for <em>stable</em>, <em>testing</em>, and
 	<p>
 The various download archives and the web site have several mirrors
 available in order to relieve our canonical servers from heavy load.
-In fact, some of the canonical servers aren't public, and instead a
-first tier of mirrors balances the load. That way, users always access
+In fact, some of the canonical servers aren't public &mdash; a first tier
+of mirrors balances the load instead. That way, users always access
 the mirrors and get used to using them, which allows Debian to better
 spread its bandwidth requirements over several servers and networks,
 and basically makes users avoid hammering on one primary location.
@@ -1097,15 +1097,16 @@ have accounts on these machines.
     <sect id="incoming-system">
 	<heading>The Incoming system
 	<p>
-The Incoming system is responsible of collecting updated packages and
+The Incoming system is responsible for collecting updated packages and
 installing them in the Debian archive. It consists of a set of
 directories and scripts that are installed both on <tt>&ftp-master-host;</tt>
 and <tt>&non-us-host;</tt>.
 	<p>
 Packages are uploaded by all the maintainers into a directory called
 <file>unchecked</file>. This directory is scanned every 15 minutes by
-the <prgn>katie</prgn> script, which verifies the integrity of the uploaded packages and the cryptographic
-signatures.  If the package is considered ready to be installed, it
+the <prgn>katie</prgn> script, which verifies the integrity of the uploaded
+packages and their cryptographic signatures.
+If the package is considered ready to be installed, it
 is moved into the <file>accepted</file> directory. If this is the first upload of
 the package, it is moved in the <file>new</file> directory, where it waits
 for an approval of the ftpmasters. If the package contains files to be installed
@@ -1192,8 +1193,8 @@ available in the various distributions.  Each version links to a page
 which provides information, including the package description,
 the dependencies and package download links.
 	<p>
-The bug tracking system track bugs for each package.  You can
-view the bugs of a given package at the URL
+The bug tracking system tracks bugs for each package.
+You can view the bugs of a given package at the URL
 <tt>http://&bugs-host;/<var>package-name</var></tt>.
 
       <sect1 id="madison">The <prgn>madison</prgn> utility
@@ -1225,7 +1226,7 @@ the activity of a source package. This really means that you can
 get the same emails that the package maintainer gets, simply by
 subscribing to the package in the PTS.
 	<p>
-Each email sent through the PTS is classified and associated to one of
+Each email sent through the PTS is classified under one of
 the keywords listed below. This will let you select the mails that
 you want to receive.
 	<p>
@@ -1338,7 +1339,7 @@ various commands to <email>pts@qa.debian.org</email>.
 
 <tag><tt>keyword [&lt;email&gt;] {+|-|=} &lt;list of keywords&gt;</tt>
 <item>
-  Accept (+) or refuse (-) mails associated to the given keyword(s).
+  Accept (+) or refuse (-) mails classified under the given keyword(s).
   Define the list (=) of accepted keywords.
 
 <tag><tt>keyword &lt;sourcepackage&gt; [&lt;email&gt;] {+|-|=} &lt;list of keywords&gt;</tt>
@@ -1420,7 +1421,7 @@ Usual news items may be used to announce that:
 <item>something important will affect the package
 </list>
 	<p>
-Both kind of news are generated in a similar manner: you just have to send
+Both kinds of news are generated in a similar manner: you just have to send
 an email either to <email>pts-static-news@qa.debian.org</email> or to
 <email>pts-news@qa.debian.org</email>. The mail should indicate which
 package is concerned by having the name of the source package in a
@@ -1573,7 +1574,7 @@ Changelog entries can be used to automatically close Debian bugs when
 the package is installed into the archive.  See <ref
 id="upload-bugfix">.
 	  <p>
-It is conventional that the changelog entry notating of a package that
+It is conventional that the changelog entry of a package that
 contains a new upstream version of the software looks like this:
 <example>
   * new upstream version
@@ -1704,8 +1705,8 @@ appropriate <file>proposed-updates</file> archive when the advisory is
 released.  See <ref id="bug-security"> for detailed information on
 handling security problems.
 	  <p>
-It is discouraged to change anything else in the package that isn't
-important, because even trivial fixes can cause bugs later on.
+Changing anything else in the package that isn't important is discouraged,
+because even trivial fixes can cause bugs later on.
 	  <p>
 Packages uploaded to <em>stable</em> need to be compiled on systems running
 <em>stable</em>, so that their dependencies are limited to the libraries
@@ -1753,7 +1754,7 @@ to transfer the files, place them into &us-upload-dir;;
 if you use anonymous FTP to upload, place them into
 &upload-queue;.
 	  <p>
-If you want to use feature described in <ref id="delayed-incoming">,
+If you want to use the feature described in <ref id="delayed-incoming">,
 you'll have to upload to <tt>ftp-master</tt>.  It is the only upload
 point that supports delayed incoming.
 	  <p>
@@ -2042,14 +2043,14 @@ Here's a list of steps that you may follow to handle a bug report:
 Decide whether the report corresponds to a real bug or not. Sometimes
 users are just calling a program in the wrong way because they haven't
 read the documentation. If you diagnose this, just close the bug with
-enough information to let the user correct his problem (give pointers
+enough information to let the user correct their 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 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,
+If the bug submitter disagrees with your decision to close the bug,
 they 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.
@@ -2060,10 +2061,10 @@ the BTS if you wish to keep it reported against your package). Before
 doing so, please read the <url id="&url-tech-ctte;" name="recommended procedure">.
     <item>
 If the bug is real but it's caused by another package, just reassign
-the bug the right package. If you don't know which package it should
+the bug to the right package. If you don't know which package it should
 be reassigned to, you may either ask for help on &email-debian-devel; or
 reassign it to <package>debian-policy</package> to let them decide which
-package is in fault.
+package is at fault.
     <p>
 Sometimes you also have to adjust the severity of the bug so that it
 matches our definition of the severity. That's because people tend to
@@ -2071,8 +2072,8 @@ inflate the severity of bugs to make sure their bugs are fixed quickly.
 Some bugs may even be dropped to wishlist severity when the requested
 change is just cosmetic.
     <item>
-The bug submitter may have forgotten to provide some information, in that
-case you have to ask him the information required. You may use the
+The bug submitter may have forgotten to provide some information, in which
+case you have to ask them the required information. You may use the
 <tt>moreinfo</tt> tag to mark the bug as such. Moreover if you can't
 reproduce the bug, you tag it <tt>unreproducible</tt>. Anyone who
 can reproduce the bug is then invited to provide more information
@@ -2148,7 +2149,7 @@ changelog as described above.  If you simply want to close bugs that
 don't have anything to do with an upload you made, do it by emailing
 an explanation to <email>XXX-done@&bugs-host;</email>.  Do
 <strong>not</strong> close bugs in the changelog entry of a version if
-the changes in that version of the package doesn't have any bearing on
+the changes in that version of the package don't have any bearing on
 the bug.
 	  <p>
 For general information on how to write your changelog entries, see
@@ -2208,7 +2209,7 @@ There are a few ways a developer can learn of a security problem:
 <list compact>
     <item>he notices it on a public forum (mailing list, web site, etc.)
     <item>someone files a bug report
-    <item>someone informs him via private email
+    <item>someone informs them via private email
 </list>
 
  In the first two cases, the information is public and it is important
@@ -2242,7 +2243,7 @@ itself is public, and can (and will) be examined by the general public.
 
 <p>
 There are two reasons for releasing information even though secrecy is
-requested: the problem has been known for a while, or that the problem
+requested: the problem has been known for a while, or the problem
 or exploit has become public.
 
         <sect2 id="bug-security-advisories">Security Advisories
@@ -2462,9 +2463,9 @@ avoid unwanted removals and to keep a trace of why a package has been
 removed. For example, you can provide the name of the package that
 supersedes the one to be removed.
 	<p>
-Usually you only ask the removal of a package maintained by yourself.
+Usually you only ask for the removal of a package maintained by yourself.
 If you want to remove another package, you have to get the approval
-of its last maintainer.
+of its maintainer.
 	<p>
 If in doubt concerning whether a package is disposable, email
 &email-debian-devel; asking for opinions.  Also of interest is the
@@ -2472,6 +2473,7 @@ If in doubt concerning whether a package is disposable, email
 package.  When invoked as <tt>apt-cache showpkg
 <var>package</var></tt>, the program will show details for
 <var>package</var>, including reverse depends.
+Removal of orphaned packages is discussed on &email-debian-qa;.
 	<p>
 Once the package has been removed, the package's bugs should be handled.
 They should either be reassigned to another package in the case where
@@ -2484,7 +2486,7 @@ software is simply no more part of Debian.
 In the past, it was possible to remove packages from <file>incoming</file>.
 However, with the introduction of the new incoming system, this is no longer
 possible.  Instead, you have to upload a new revision of your package with
-a higher version as the package you want to replace.  Both versions will be
+a higher version than the package you want to replace.  Both versions will be
 installed in the archive but only the higher version will actually be
 available in <em>unstable</em> since the previous version will immediately
 be replaced by the higher.  However, if you do proper testing of your
@@ -2492,8 +2494,8 @@ packages, the need to replace a package should not occur too often anyway.
 
       <sect1>Replacing or renaming packages
 	<p>
-Sometimes you made a mistake naming the package and you need to rename
-it.  In this case, you need to follow a two-step process.  First, set
+When you make a mistake naming your package, you should follow a two-step
+process to rename it. First, set
 your <file>debian/control</file> file to replace and conflict with the
 obsolete name of the package (see the <url id="&url-debian-policy;"
 name="Debian Policy Manual"> for details).  Once you've uploaded
@@ -2578,7 +2580,7 @@ portability.  Therefore, even if you are not a porter, you should read
 most of this chapter.
       <p>
 Porting is the act of building Debian packages for architectures that
-is different from the original architecture of the package
+are different from the original architecture of the package
 maintainer's binary package.  It is a unique and essential activity.
 In fact, porters do most of the actual compiling of Debian packages.
 For instance, for a single <em>i386</em> binary package, there must be
@@ -2595,7 +2597,7 @@ the case.  This section contains a checklist of ``gotchas'' often
 committed by Debian maintainers &mdash; common problems which often stymie
 porters, and make their jobs unnecessarily difficult.
 	<p>
-The first and most important watchword is to respond quickly to bug or
+The first and most important thing is to respond quickly to bug or
 issues raised by porters.  Please treat porters with courtesy, as if
 they were in fact co-maintainers of your package (which in a way, they
 are).  Please be tolerant of succinct or even unclear bug reports,
@@ -2644,7 +2646,7 @@ They should be removed by the `clean' target of
 Make sure you don't rely on locally installed or hacked configurations
 or programs.  For instance, you should never be calling programs in
 <file>/usr/local/bin</file> or the like.  Try not to rely on programs
-be setup in a special way.  Try building your package on another
+being setup in a special way.  Try building your package on another
 machine, even if it's the same architecture.
 	    <item>
 Don't depend on the package you're building already being installed (a
@@ -2757,7 +2759,7 @@ Porters may also have an unofficial location where they can put the
 results of their work during the waiting period.  This helps others
 running the port have the benefit of the porter's work, even during
 the waiting period.  Of course, such locations have no official
-blessing or status, so buyer, beware.
+blessing or status, so buyer beware.
 
 
       <sect1 id="porter-automation">
@@ -2831,7 +2833,7 @@ called a non-maintainer upload, or NMU.
 Debian porters, who compile packages for different architectures,
 occasionally do binary-only NMUs as part of their porting activity
 (see <ref id="porting">).  Another reason why NMUs are done is when a
-Debian developers needs to fix another developers' packages in order to
+Debian developer needs to fix another developer's packages in order to
 address serious security problems or crippling bugs, especially during
 the freeze, or when the package maintainer is unable to release a fix
 in a timely fashion.
@@ -2912,12 +2914,12 @@ Make sure that the package's bugs that the NMU is meant to address are all
 filed in the Debian Bug Tracking System (BTS).
 If they are not, submit them immediately.
 	    <item>
-Wait a few days the response from the maintainer. If you don't get
-any response, you may want to help him by sending the patch that fixes
+Wait a few days for the response from the maintainer. If you don't get
+any response, you may want to help them by sending the patch that fixes
 the bug. Don't forget to tag the bug with the "patch" keyword.
 	    <item>
 Wait a few more days. If you still haven't got an answer from the
-maintainer, send him a mail announcing your intent to NMU the package.
+maintainer, send them a mail announcing your intent to NMU the package.
 Prepare an NMU as described in <ref id="nmu-guidelines">, test it
 carefully on your machine (cf. <ref id="sanitycheck">).
 Double check that your patch doesn't have any unexpected side effects.
@@ -2945,8 +2947,8 @@ and act later.
 	<p>
 The following applies to porters insofar as they are playing the dual
 role of being both package bug-fixers and package porters.  If a
-porter has to change the Debian source archive, automatically their
-upload is a source NMU and is subject to its rules.  If a porter is
+porter has to change the Debian source archive, their upload is
+automatically a source NMU and is subject to its rules.  If a porter is
 simply uploading a recompiled binary package, the rules are different;
 see <ref id="porter-guidelines">.
 	<p>
@@ -3072,7 +3074,7 @@ In any case, you should not be upset by the NMU. An NMU is not a
 personal attack against the maintainer. It is a proof that
 someone cares enough about the package and that they were willing to help
 you in your work, so you should be thankful. You may also want to
-ask them if they would be interested to help you on a more frequent
+ask them if they would be interested in helping you on a more frequent
 basis as co-maintainer or backup maintainer
 (see <ref id="collaborative-maint">).
 
@@ -3088,7 +3090,7 @@ packages in which a priority of <tt>Standard</tt> or which are part of
 the base set have co-maintainers.</p>
         <p>
 Generally there is a primary maintainer and one or more
-co-maintainers.  The primary maintainer is the whose name is listed in
+co-maintainers.  The primary maintainer is the person whose name is listed in
 the <tt>Maintainer</tt> field of the <file>debian/control</file> file.
 Co-maintainers are all the other maintainers.</p>
         <p>
@@ -3260,7 +3262,7 @@ this using an hand-crafted <file>debian/rules</file> file.
         <p>
 The following practices are relevant to the
 <file>debian/control</file> file.  They supplement the <url
-id="&url-debian-policy;ch-miscellaneous.html#s-descriptions"
+id="&url-debian-policy;ch-binary.html#s-descriptions"
 name="Policy on package descriptions">.
         <p>
 The description of the package, as defined by the corresponding field