chiark / gitweb /
fix examples
[developers-reference.git] / developers-reference.sgml
index 5f55eacaa86f95efea21b3004b66d0a3a71dc99d..07be5f87550db3ce0c2a54a9337e69576fc98858 100644 (file)
@@ -6,7 +6,7 @@
   <!ENTITY % commondata  SYSTEM "common.ent" > %commondata;
 
   <!-- CVS revision of this document -->
-  <!ENTITY cvs-rev "$Revision: 1.236 $">
+  <!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>