fix examples

[developers-reference.git] / developers-reference.sgml

diff --git a/developers-reference.sgml b/developers-reference.sgml
index 5351168ce3a010a76a7ae8d98b4de207276b9384..07be5f87550db3ce0c2a54a9337e69576fc98858 100644 (file)
--- 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.235 $">
+  <!ENTITY cvs-rev "$Revision: 1.239 $">
 
   <!-- if you are translating this document, please notate the CVS
        revision of the original developer's reference in cvs-en-rev -->
@@ -3100,6 +3100,7 @@ This way, `testing' should always be close to being a release candidate.
 Please see below for details.
        <sect1 id="testing-unstable">
        <heading>Updates from unstable</heading>
+       <p>
 The scripts that update the <em>testing</em> distribution are run each
 day after the installation of the updated packages. They generate the
 <file>Packages</file> files for the <em>testing</em> distribution, but
@@ -3165,12 +3166,12 @@ has in testing.
        <p>
 Consider this example:
        <p>
-       <tt>
-       foo      | alpha | arm 
+       <example>
+foo      | alpha | arm 
 ---------+-------+----
 testing  |   1   |  -
 unstable |   1   |  2
-</tt>
+</example>
        <p>
 The package is out of date on alpha in unstable, and will not go to
 testing. And removing foo from testing would not help at all, the package
@@ -3178,12 +3179,12 @@ is still out of date on alpha, and will not propagate to testing.
        <p>
 However, if ftp-master removes a package in unstable (here on arm):
        <p>
-       <tt>
+       <example>
 foo      | alpha | arm | hurd-i386
 ---------+-------+-----+----------
 testing  |   1   |  1  |    -
 unstable |   2   |  -  |    1
-       </tt>
+       </example>
        <p>
 In this case, the package is up to date on all release architectures in
 unstable (and the extra hurd-i386 doesn't matter, as it's not a release
@@ -3304,7 +3305,7 @@ through testing-proposed-updates of the package version 1.2.
          <p>
 
        <sect2 id="rc">
-       <heading>What are release-critical bugs, and how do they get counted?</headin>
+       <heading>What are release-critical bugs, and how do they get counted?</heading>
          <p>
 All bugs of some higher severities are by default considered release-critical; currently, these are critical, grave and serious bugs.
          <p>
@@ -4106,17 +4107,17 @@ LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
           <heading>Make transition packages deborphan compliant</heading>
           <p>
 Deborphan is a program helping users to detect which packages can be safely
-removed from the system, ie the ones that have no packages depending on
+removed from the system, i.e. the ones that have no packages depending on
 them. The default operation is to search only within the libs and oldlibs
 sections, to hunt down unused libraries. But when passed the right argument,
 it tries to catch other useless packages. 
           <p>
-For example, with --guess-dummy, tries to search all transitionnal packages
+For example, with --guess-dummy, tries to search all transitional packages
 which were needed for upgrade but which can now safely be removed. For that,
 it looks for the string "dummy" or "transitional" in their short
 description.
           <p>
-So, when you are creating ssuch a package, please make sure to add this text
+So, when you are creating such a package, please make sure to add this text
 to your short description. If you are looking for example, just run: 
   <example>apt-cache search .|grep dummy</example> or
   <example>apt-cache search .|grep transitional</example>.